¿Que son Táctica de requerimientos?
Involucra un proceso complejo donde las relaciones entre las tareas no necesariamente son secuenciales.
No es una actividad discreta, inicia con el proyecto y continúa para ser refinada a través del ciclo de vida.
Utiliza prácticas de gestión como otros productos en el proceso del ciclo de vida.
Necesita ser adaptado a la organización y al contexto del proyecto.
No es una actividad discreta, inicia con el proyecto y continúa para ser refinada a través del ciclo de vida.
Utiliza prácticas de gestión como otros productos en el proceso del ciclo de vida.
Necesita ser adaptado a la organización y al contexto del proyecto.
Proceso de requerimientos
Actores del proceso:
Usuarios: utiliza el software
Clientes: encargados de que el software funcione o el mercado meta
Analista del mercado: establecen las necesidades del mercado y actúan como “representantes” del cliente
Reguladores: autoridades que de alguna forman regulan el quehacer del negocio la construcción del productos.
Se deben balancear las necesidades de los involucrados.
Soporte y Gestión del proceso: Se relaciona con las actividades de iniciación y definición del alcance, así como con el costo, recursos humanos, entrenamiento y herramientas.
Calidad y mejoramiento del proceso: enfatiza la necesidad de lograr un adecuado balance entre tiempo, costo y satisfacción del cliente.
Se relaciona con
Estándares y modelos de mejoramiento continuo
Métricas y benchmarking
Planificación e implementación de mejoras
Desarrollo de requerimientos
Identificar expectativas y obtener necesidades de individuos a quienes representan cada usuario
Entender las tareas del usuario y como se relacionan con los objetivos del negocio
Analizar la información para definir requerimientos funcionales, no funcionales, reglas de negocio, soluciones sugeridas e información externa
Transformando requerimientos de alto nivel a componentes de software
Entender la importancia de los atributos de calidad
Negociando prioridades de implementación
Traducir las necesidades en especificaciones escritas y modelos
Revisar los requerimientos documentados para asegurar un entendimiento común entre los involucrados
Administración de requerimientos
Definir la línea base de requerimientos (una fotografía en el tiempo de los requerimientos de una versión)
Revisar y evaluar los requerimientos y el impacto de cada cambio antes de aprobarlos
Utilizar controles adecuados de los cambios aprobados Mantener actualizado el Plan del proyecto
Negociar acuerdos basados en el impacto estimado de los cambios
Trazando requerimientos a los diseños, código fuente y casos de prueba
Seguimiento del estado y cambio de requerimientos a través del proyecto
Características de un buen requerimiento
Completo: Contiene la información necesaria para el desarrollador
Correcto: debe describir la funcionalidad que construirá
Factible: debe ser posible implementarlo dentro de las capacidades y limitaciones conocidas
Necesario: lo que realmente el cliente necesita
Priorizado: debe indicar que tan esencial es para la versión del producto.
No ambiguo: comprensible, cada lector debe entender que es lo que cada requerimiento dice.
Verificable: a través de inspección o demostración
Requerimientos cuantificables: deben de especificarse claramente y sin ambigüedad.
Evitar que los requerimientos dependan de la interpretación o juicio subjetivo
Actores del proceso:
Usuarios: utiliza el software
Clientes: encargados de que el software funcione o el mercado meta
Analista del mercado: establecen las necesidades del mercado y actúan como “representantes” del cliente
Reguladores: autoridades que de alguna forman regulan el quehacer del negocio la construcción del productos.
Se deben balancear las necesidades de los involucrados.
Soporte y Gestión del proceso: Se relaciona con las actividades de iniciación y definición del alcance, así como con el costo, recursos humanos, entrenamiento y herramientas.
Calidad y mejoramiento del proceso: enfatiza la necesidad de lograr un adecuado balance entre tiempo, costo y satisfacción del cliente.
Se relaciona con
Estándares y modelos de mejoramiento continuo
Métricas y benchmarking
Planificación e implementación de mejoras
Desarrollo de requerimientos
Identificar expectativas y obtener necesidades de individuos a quienes representan cada usuario
Entender las tareas del usuario y como se relacionan con los objetivos del negocio
Analizar la información para definir requerimientos funcionales, no funcionales, reglas de negocio, soluciones sugeridas e información externa
Transformando requerimientos de alto nivel a componentes de software
Entender la importancia de los atributos de calidad
Negociando prioridades de implementación
Traducir las necesidades en especificaciones escritas y modelos
Revisar los requerimientos documentados para asegurar un entendimiento común entre los involucrados
Administración de requerimientos
Definir la línea base de requerimientos (una fotografía en el tiempo de los requerimientos de una versión)
Revisar y evaluar los requerimientos y el impacto de cada cambio antes de aprobarlos
Utilizar controles adecuados de los cambios aprobados Mantener actualizado el Plan del proyecto
Negociar acuerdos basados en el impacto estimado de los cambios
Trazando requerimientos a los diseños, código fuente y casos de prueba
Seguimiento del estado y cambio de requerimientos a través del proyecto
Características de un buen requerimiento
Completo: Contiene la información necesaria para el desarrollador
Correcto: debe describir la funcionalidad que construirá
Factible: debe ser posible implementarlo dentro de las capacidades y limitaciones conocidas
Necesario: lo que realmente el cliente necesita
Priorizado: debe indicar que tan esencial es para la versión del producto.
No ambiguo: comprensible, cada lector debe entender que es lo que cada requerimiento dice.
Verificable: a través de inspección o demostración
Requerimientos cuantificables: deben de especificarse claramente y sin ambigüedad.
Evitar que los requerimientos dependan de la interpretación o juicio subjetivo
Características de una buena especificación de requerimiento
Completa: para lograrlo es necesario enfocarse en la tarea del usuario más que en la función del sistema.
Consistente: que no existan conflictos de requerimientos entre requerimientos del mismo tipo o con los requerimientos del negocio
Modificable: debe ser posible revisar la especificación cuando lo requiera , llevar un historial de cambios.
Cada requerimiento debe ser etiquetado de manera única, y expresado separadamente de otros requerimientos
Trazable: es necesario conocer desde el origen del requerimiento hasta los elementos de diseño y código fuente.
Priorizado: debe indicar que tan esencial es para la versión del producto.
Cite 2 beneficios de aplicar estas actividades en el levantamiento de requerimientos
Permite una clara comprensión del dominio del problema
Requerimientos del problema en un contexto mayor
Se logran considerar todas las soluciones potenciales
Debemos enfocar la revisión de los requerimientos en las siguientes preguntas:
¿cada requerimiento consiste con el objetivo general?
¿todos los requerimientos han sido especificados en el grado adecuando de abstracción?
¿el requerimiento es necesario?
¿cada requerimiento está limitado y no es ambiguo?
¿existe una fuente para cada requerimiento?
¿algunos requerimientos entran en conflictos con otros?
¿cada requerimiento es alcanzable en el ambiente técnico?
¿cada requerimiento se puede probar una vez que se haya implementado?
¿el modelado de requerimientos refleja de manera apropiada la información, la función y el comportamiento del sistema?
Completa: para lograrlo es necesario enfocarse en la tarea del usuario más que en la función del sistema.
Consistente: que no existan conflictos de requerimientos entre requerimientos del mismo tipo o con los requerimientos del negocio
Modificable: debe ser posible revisar la especificación cuando lo requiera , llevar un historial de cambios.
Cada requerimiento debe ser etiquetado de manera única, y expresado separadamente de otros requerimientos
Trazable: es necesario conocer desde el origen del requerimiento hasta los elementos de diseño y código fuente.
Priorizado: debe indicar que tan esencial es para la versión del producto.
Cite 2 beneficios de aplicar estas actividades en el levantamiento de requerimientos
Permite una clara comprensión del dominio del problema
Requerimientos del problema en un contexto mayor
Se logran considerar todas las soluciones potenciales
Debemos enfocar la revisión de los requerimientos en las siguientes preguntas:
¿cada requerimiento consiste con el objetivo general?
¿todos los requerimientos han sido especificados en el grado adecuando de abstracción?
¿el requerimiento es necesario?
¿cada requerimiento está limitado y no es ambiguo?
¿existe una fuente para cada requerimiento?
¿algunos requerimientos entran en conflictos con otros?
¿cada requerimiento es alcanzable en el ambiente técnico?
¿cada requerimiento se puede probar una vez que se haya implementado?
¿el modelado de requerimientos refleja de manera apropiada la información, la función y el comportamiento del sistema?
Reflexiones!
Después de desarrollar la tarea y lo aprendido a lo largo del proyecto uno se percata de que siempre se queda algo de lado y es muy importante definir una estrategia para sopesar todos los imprevistos que sucedan durante las diferentes etapas de elicitacion.
Y es importante aprender a confiar en el equipo de trabajo que está trabajando en el proyecto ya que la comunicación es un punto clave en este proceso.
Y es importante aprender a confiar en el equipo de trabajo que está trabajando en el proyecto ya que la comunicación es un punto clave en este proceso.
Bibliografia
- Requerimientos del software. (2012). Tomado de http://es.slideshare.net/maryme/2-requerimientos-del-software
- Ruiz, A. (2011). Importancia de los requisitos en un proyecto de software. Tomado de http://www.blogtrw.com/2011/07/la-importancia-de-los-requisitos-en-un-proyecto-de-software/
- Alegsa, L. (s.f.). Definición de requerimientos. Tomado de http://www.alegsa.com.ar/Dic/requerimientos.php
- Administración de Cambios. (2015)Consultado el 22 abril 2015 de: http://materias.fi.uba.ar/7546/material/03_Administracion_de_Cambios.pdf
- Pressman, R. (2005). Ingeniería del Software: Un Enfoque Práctico. Sexta Edición. USA:Mc Graw Hill