¿Qué es Ingeniería de Requerimientos?
“Ciencia y disciplina interesada en establecer y documentar los requerimientos de software” (Thayer)
Definición de requerimiento (IEEE Std Glossary Engineering Terminology)
Una condición o capacidad necesitada por un usuario para resolver un problema o cumplir un objetivo
Una condición o capacidad que debe ser reunida por un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto
Representación documentada de una condición o capacidad como en 1 y 2
Supuestos equivocados acerca de la Ingeniería de requerimientos
● Cualquier persona puede llegar a ser ingeniero de requerimientos con una semana o dos de entrenamiento.
● Requerimientos funcionales y no funcionales deben ser obtenidos usando personas y procesos separados.
● Procesos que funcionan para un pequeño número de requerimientos puede ser escalable
Tipos de requerimientos
Una condición o capacidad que debe ser reunida por un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto
Representación documentada de una condición o capacidad como en 1 y 2
Supuestos equivocados acerca de la Ingeniería de requerimientos
● Cualquier persona puede llegar a ser ingeniero de requerimientos con una semana o dos de entrenamiento.
● Requerimientos funcionales y no funcionales deben ser obtenidos usando personas y procesos separados.
● Procesos que funcionan para un pequeño número de requerimientos puede ser escalable
Tipos de requerimientos
- Requerimientos del negocio
- Requerimientos de usuario
- Requerimientos Funcionales
- Requerimientos no funcionales
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
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
Elicitación:
La elicitación de requerimientos es el proceso que consiste en adquirir todo el conocimiento relevante, necesario para producir un modelo de requerimientos (especificación) de un dominio de problema.
Técnicas de elicitación
Entrevistas
Escenarios
Prototipos
Storyboarding Lluvia de ideas Reuniones Talleres
Observación
- Análisis
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solución que está buscando
Detectar conflictos entre requerimientos
Cómo el software debe interactuar con el ambiente
Elaborar requerimientos del sistema para derivar requerimientos de software
Es necesario escribir requerimientos suficientemente precisos para que puedan ser validados, su implementación verificada y sus costos estimados.
Clasificación de requerimientos
Funcional o no funcional
Derivado de un requerimiento de alto nivel, propiedad emergente o impuesto directamente por un stakeholder o alguna otra fuente.
Si el requerimiento es del producto o del proceso.
Prioridad del requerimiento: obligatorio, altamente deseable, deseable, opcional. Generalmente es un balance entre el costo de desarrollo y la implementación.
Alcance del requerimiento: cuánto afecta el software y sus componentes
Volatilidad y estabilidad: durante el ciclo de vida del software.
Diseño de arquitectura y requerimientos
En algunos casos los ingenieros de requerimientos actúan como arquitectos pues el proceso de análisis y elaboración de los requerimientos demanda identificar los componentes requeridos para responder a las necesidades planteadas
Requerimientos pueden ser nuevamente analizados ya que los componentes necesitan interactuar con otros componentes de requerimientos ya establecidos
Negociación de requerimientos
● Resolución de conflictos entre
- dos stakeholder
- características mutuamente incompatibles
- requerimientos y recursos
- requerimientos funcionales y no funcionales
● Se presenta generalmente en el análisis de requerimientos sin embargo puede darse en la validación
- Especificación:
Una especificación puede ser vista como un contrato entre usuarios y desarrolladores de software, el cual define el comportamiento funcional del artefacto de software (y otras propiedades tales como performance, confiabilidad, seguridad, etc.), sin mostrar cómo será obtenido ese comportamiento.
Es importante ver la especificación como un proceso complejo que requiere “feedback” desde el analista al usuario y viceversa. El proceso es analítico debido a que diferentes clases de conocimiento que el analista elicita de un dominio de problema, debe ser examinado y posteriormente vinculado de algún modo. También es sintético debido a que conocimiento heterogéneo debe ser combinado para producir una especificación de requerimientos coherente.
Tipo de documentos:
● Definición del sistema
● Especificación de requerimientos del sistema
● Especificación de requerimientos del software (SRS)
- Validación / Verificación
Los requerimientos deben ser validados para:
● asegurar que el ingeniero de software ha entendido los requerimientos
● Verificar que el documento de requerimientos cumple con los estándares de la compañía
● Verificar que el documento es entendible, consistente y completo
● Es común que en el cronograma el proyecto se incluyan de manera explicita puntos donde se valida el documento
Validación de modelos
● Depende de la notación utilizada
● Validar las interrelaciones entre los componentes de los modelos y entre los modelos
● Pruebas de aceptación
● Previamente se debe planear la forma de validar ● Por lo que los criterios de aceptación deben ser definidos previamente y de manera cuantitativa
Revisión de requerimientos
● Se conforma un grupo con usuarios y desarrolladores
● Determinar si hay errores, supuestos equivocados, pérdida de claridad y desviación de los estándares
● Prototipos
● Valida la interpretación de los requerimientos por parte del ingeniero de software
● Existe el riesgo de que se desvíe la atención en problemas cosméticos o problemas de calidad del prototipo
● Se debe de evaluar los costos de su desarrollo contra los beneficios esperados
-Priorización
La estrategia de priorización es como un proceso iterativo que conlleva varios participantes. En cada iteración para cada requerimiento se analizan los valores finales asignados a dicho requerimiento. Esto es que para cada requerimiento se determina un valor final, el cual es la media de los valores finales asignados por cada participante a ese requerimiento. Utilizando una técnica de asignación de valores sobre cada uno de los requerimientos, cada persona tendrá un valor numérico más el valor cognitivo correspondiente para cada uno de los requerimientos de un conjunto de requerimientos.
Para que un participante asigne un valor a un requerimiento se consideran tres variables: • Conocimiento del individuo sobre el requerimiento • Categorización del individuo • Valor asignado por el individuo
- Soporte a la planificación
- Conducción del Diseño Desarrollo : Es la fase enfocada a diseñar todos los componentes que intervienen en el nuevo sistema y que deben cumplir con los requerimientos de los usuarios:
- Precisión, flexibilidad.
- Proporcionar al usuario lo que requiere.
- Traducir las demandas de usuarios a modelo.
El proceso del diseño tiene 6 puntos principales:
· Diagrama del flujo de sistema
· Diseño de salidas del sistema
· Diseño de entradas del sistema
· Diseño de los archivos del sistema
· Diseño de los procedimientos del proceso
· Diseño de los controles del sistema.
- Administración de Cambios
Quien recibe las solicitudes del cambio al producto.
Aprobación y rechazo de los cambios
Valoración de costo y riesgo de los cambios.
Responsable de las solicitudes del cambio desde su inicio hasta su resolución.
Aplicación del cambio.
Manejo de un control de versiones del producto
La elicitación de requerimientos es el proceso que consiste en adquirir todo el conocimiento relevante, necesario para producir un modelo de requerimientos (especificación) de un dominio de problema.
Técnicas de elicitación
Entrevistas
Escenarios
Prototipos
Storyboarding Lluvia de ideas Reuniones Talleres
Observación
- Análisis
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solución que está buscando
Detectar conflictos entre requerimientos
Cómo el software debe interactuar con el ambiente
Elaborar requerimientos del sistema para derivar requerimientos de software
Es necesario escribir requerimientos suficientemente precisos para que puedan ser validados, su implementación verificada y sus costos estimados.
Clasificación de requerimientos
Funcional o no funcional
Derivado de un requerimiento de alto nivel, propiedad emergente o impuesto directamente por un stakeholder o alguna otra fuente.
Si el requerimiento es del producto o del proceso.
Prioridad del requerimiento: obligatorio, altamente deseable, deseable, opcional. Generalmente es un balance entre el costo de desarrollo y la implementación.
Alcance del requerimiento: cuánto afecta el software y sus componentes
Volatilidad y estabilidad: durante el ciclo de vida del software.
Diseño de arquitectura y requerimientos
En algunos casos los ingenieros de requerimientos actúan como arquitectos pues el proceso de análisis y elaboración de los requerimientos demanda identificar los componentes requeridos para responder a las necesidades planteadas
Requerimientos pueden ser nuevamente analizados ya que los componentes necesitan interactuar con otros componentes de requerimientos ya establecidos
Negociación de requerimientos
● Resolución de conflictos entre
- dos stakeholder
- características mutuamente incompatibles
- requerimientos y recursos
- requerimientos funcionales y no funcionales
● Se presenta generalmente en el análisis de requerimientos sin embargo puede darse en la validación
- Especificación:
Una especificación puede ser vista como un contrato entre usuarios y desarrolladores de software, el cual define el comportamiento funcional del artefacto de software (y otras propiedades tales como performance, confiabilidad, seguridad, etc.), sin mostrar cómo será obtenido ese comportamiento.
Es importante ver la especificación como un proceso complejo que requiere “feedback” desde el analista al usuario y viceversa. El proceso es analítico debido a que diferentes clases de conocimiento que el analista elicita de un dominio de problema, debe ser examinado y posteriormente vinculado de algún modo. También es sintético debido a que conocimiento heterogéneo debe ser combinado para producir una especificación de requerimientos coherente.
Tipo de documentos:
● Definición del sistema
● Especificación de requerimientos del sistema
● Especificación de requerimientos del software (SRS)
- Validación / Verificación
Los requerimientos deben ser validados para:
● asegurar que el ingeniero de software ha entendido los requerimientos
● Verificar que el documento de requerimientos cumple con los estándares de la compañía
● Verificar que el documento es entendible, consistente y completo
● Es común que en el cronograma el proyecto se incluyan de manera explicita puntos donde se valida el documento
Validación de modelos
● Depende de la notación utilizada
● Validar las interrelaciones entre los componentes de los modelos y entre los modelos
● Pruebas de aceptación
● Previamente se debe planear la forma de validar ● Por lo que los criterios de aceptación deben ser definidos previamente y de manera cuantitativa
Revisión de requerimientos
● Se conforma un grupo con usuarios y desarrolladores
● Determinar si hay errores, supuestos equivocados, pérdida de claridad y desviación de los estándares
● Prototipos
● Valida la interpretación de los requerimientos por parte del ingeniero de software
● Existe el riesgo de que se desvíe la atención en problemas cosméticos o problemas de calidad del prototipo
● Se debe de evaluar los costos de su desarrollo contra los beneficios esperados
-Priorización
La estrategia de priorización es como un proceso iterativo que conlleva varios participantes. En cada iteración para cada requerimiento se analizan los valores finales asignados a dicho requerimiento. Esto es que para cada requerimiento se determina un valor final, el cual es la media de los valores finales asignados por cada participante a ese requerimiento. Utilizando una técnica de asignación de valores sobre cada uno de los requerimientos, cada persona tendrá un valor numérico más el valor cognitivo correspondiente para cada uno de los requerimientos de un conjunto de requerimientos.
Para que un participante asigne un valor a un requerimiento se consideran tres variables: • Conocimiento del individuo sobre el requerimiento • Categorización del individuo • Valor asignado por el individuo
- Soporte a la planificación
- Conducción del Diseño Desarrollo : Es la fase enfocada a diseñar todos los componentes que intervienen en el nuevo sistema y que deben cumplir con los requerimientos de los usuarios:
- Precisión, flexibilidad.
- Proporcionar al usuario lo que requiere.
- Traducir las demandas de usuarios a modelo.
El proceso del diseño tiene 6 puntos principales:
· Diagrama del flujo de sistema
· Diseño de salidas del sistema
· Diseño de entradas del sistema
· Diseño de los archivos del sistema
· Diseño de los procedimientos del proceso
· Diseño de los controles del sistema.
- Administración de Cambios
Quien recibe las solicitudes del cambio al producto.
Aprobación y rechazo de los cambios
Valoración de costo y riesgo de los cambios.
Responsable de las solicitudes del cambio desde su inicio hasta su resolución.
Aplicación del cambio.
Manejo de un control de versiones del producto
Reflexiones!
A lo largo de varios proyectos de desarrollo de software se empieza a tomar experiencia en el área de recolección de requerimientos, y una de las funciones más importantes dentro del proceso de elicitación es no dejar por fuera ninguna persona involucrada con el sistema, ya que esa persona puede ser clave en el desarrollo del sistema.
Por ejemplo en un caso particular, en el desarrollo de una aplicación para una empresa X, la recolección de los requerimientos se realizaron en conjunto con los jefes de cada área y sub áreas y según esa directriz del proyecto así se realizó todo el proceso, hasta llegar al proceso de pruebas técnicas e integración con los usuarios y los usuarios empezaron a preguntar sobre ciertos puntos que para ellos eran importantes y nos dirigimos a los encargados y lo que nos dijeron fue ¨Es cierto falta tal o cual cosa¨, esto implica hacer cambios en la aplicación y volver iniciar desde cero tomando en cuenta a todas las personas de la empresa y conllevo retrasar la salida a producción y que el cliente asumiera su responsabilidad.
El caso es que un fallo al inicio puede provocar una catástrofe al final, como una bola de nieve incontrolable.
Por ejemplo en un caso particular, en el desarrollo de una aplicación para una empresa X, la recolección de los requerimientos se realizaron en conjunto con los jefes de cada área y sub áreas y según esa directriz del proyecto así se realizó todo el proceso, hasta llegar al proceso de pruebas técnicas e integración con los usuarios y los usuarios empezaron a preguntar sobre ciertos puntos que para ellos eran importantes y nos dirigimos a los encargados y lo que nos dijeron fue ¨Es cierto falta tal o cual cosa¨, esto implica hacer cambios en la aplicación y volver iniciar desde cero tomando en cuenta a todas las personas de la empresa y conllevo retrasar la salida a producción y que el cliente asumiera su responsabilidad.
El caso es que un fallo al inicio puede provocar una catástrofe al final, como una bola de nieve incontrolable.
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