Importancia
► Los errores en la fase de requerimientos son los más
numerosos:
▪ Boehm afirma que el 10% de los errores se producen en la fase de requerimientos.
▪ Estudios más recientes afirman que entre el 44% y el 80% de los errores proceden de IR.
► El costo crece exponencialmente con el retraso en
subsanarlo:
▪ Boehm afirma que la reparación de un error en la fase de codificación cuesta entre 5 y 10 veces más.
3
Costo de Correcciones a Errores
¿Qué es un requerimiento de
software?
Concepto de requerimiento
► El IEEE define:
▪ Requisito o Requerimiento como:
►Una condición o necesidad de un usuario para
resolver un problema o alcanzar un objetivo
►Una condición o capacidad que debe estar presente
en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal
7
Requerimientos
► Diferentes niveles de detalle, perspectivas y tipos
de requerimientos ►De usuario ►De sistema ►De negocio ►Técnicos ►Funcionales ►No funcionales
Requerimientos
► De negocio
▪ Objetivos generales de la organización o los clientes
que solicitan el sistema
▪ ¿Por qué se está implementando el sistema?
9
Requerimientos
► Del usuario
▪ Objetivos del usuario
▪ Tareas que el usuario debe poder hacer con la
aplicación
► Del sistema
▪ Incluyen elementos de software, hardware e incluso
Requerimientos funcionales
► Describen la funcionalidad o los servicios del
sistema
► Depende del tipo de software, Los usuarios
esperados y el tipo de sistema en que el software se va a usarse.
► Los requerimientos del usuario funcional pueden
ser declaraciones de muy alto nivel sobre lo que el sistema debería hacer, pero los requerimientos
Requerimientos no funcionales
► Estos definen las propiedades y restricciones del sistema,
p.Ej.: confiabilidad, tiempo de respuesta y requerimientos de almacenamiento.
► Los requerimientos también pueden ser especificados
asignando sistemas CASE particulares, programando un lenguaje o desarrollando un método.
► Los requerimientos no funcionales pueden ser más críticos
que los funcionales. Si estos no se cumplen, el sistema es inservible.
Clasificaciones no funcionales
► Requerimientos del producto▪ Requerimientos que especifican que el producto entregado debe comportarse de una manera determinada. P.Ej.: Velocidad de ejecución, confiabilidad, etc.
► Requerimientos organizacionales
▪ Requerimientos que son una consecuencia de las políticas y procedimientos organizacionales. P.Ej.: estándares de proceso usados, requerimientos de implementación, etc.
► Requerimientos externos
▪ Los requerimientos que surgen de los factores que son externos al sistema y su proceso de desarrollo. P.Ej.: interoperabilidad,
Tipos de requerimientos no funcionales
Requerimientos de desempeño Requerimientos de espacio Requerimientos de utilidad Requerimientoseficiencia Requerimientosde fiabilidad Requerimientos de portabilidad interoperabilidadRequerimientos Requerimientoséticos
Requerimiento s legislativos Requerimientos implementación Requerimientos de estándares Requerimiento s de entrega Requerimientos de seguridad Requerimientos privacidad Requerimientos Del producto Requerimientos organizacionale s Requerimiento s externos Requerimientos No funcionales
Requerimientos
► Funcionales
▪ Especifican la funcionalidad que se debe construir –
Comportamiento
► No funcionales
▪ Estándares, regulaciones
▪ Interfaces externas, desempeño, restricciones de
15
Características de los requerimientos
►
Necesario
►Conciso
►Completo
►Consistente
►No ambiguo
►Verificable
Dificultades para definir requerimientos
► Los requerimientos no son obvios y vienen de
muchas fuentes
► Son difíciles de expresar en palabras (el lenguaje
es ambiguo).
► Existen muchos tipos de requerimientos y
17
► La cantidad de requerimientos en un proyecto
puede ser difícil de manejar.
► Los requerimientos están relacionados unos con
otros, y a su vez se relacionan con otras partes del proceso.
► Un requerimiento puede cambiar a lo largo del ciclo
de desarrollo.
Dificultades para definir requerimientos
► Los Stakeholders no saben lo que realmente
quieren.
► Los Stakeholders expresan los requerimientos con
sus propios términos
► D i f e r e n t e s s t a k e h o l d e r s p u e d e n t e n e r
requerimientos conflictivos
► Los requerimientos cambian durante el proceso de
Guía para escribir requerimientos
► Definir un formato estándar y usarlo para todos los
requerimientos.
► Distinguir entre los requerimientos deseables y
obligatorios.
► Resaltar el texto para identificar partes importantes
del requerimiento
Documento de los requerimientos
► El documento de requerimientos es la exposición
oficial de lo que se pide a los desarrolladores del sistema.
► Debería incluir tanto la definición de los
requerimientos del usuario como la especificación de los requerimientos del sistema.
21
Especificación de Requerimientos
de Software (ERS)
► Constituye la línea de base para el diseño del
producto y la referencia oficial para determinar si el producto de software es lo que el usuario solicito.
► Normalmente se trata de un documento expresado
en lenguaje natural, de modo que funcione como instrumento de comunicación con el cliente y
► Punto de vista del cliente: es una descripción
comprensiva de lo que el sistema debe resolver
► Punto de vista del administrador del proyecto: es la
base para asignar recursos, estimar preliminarmente esfuerzo - costo y establecer hitos del proyecto.
23
► Punto de vista del programador: es la “autoridad”
definitiva de lo que debe hacer el sistema, no el diseño.
► Punto de vista de los ingenieros de Pruebas: es la
base para construir planes de pruebas.
Puntos Clave
► Los requerimientos para un sistema determinan lo
que debe de hacer el sistema y definen las restricciones en el funcionamiento.
► Los requerimientos funcionales son declaraciones
de los servicios que el sistema debe proporcionar o son descripciones de cómo se deben de llevar a cabo algunos cálculos.
► Los requerimientos no funcionales restringen el
sistema en desarrollo y el proceso de desarrollo que se debe de utilizar.
► Los requerimientos del usuario son para el uso por
la gente relacionada con la utilización del sistema, se deben de redactar con lenguaje natural, tablas y diagramas fáciles de entender.
25
Informática Empresarial, UCR IF 7100 Ingeniería de Software
► Los requerimientos del sistema se utilizan para
comunicar de forma precisa las funciones que debe de proporcionar el sistema.
► Los documentos de requerimientos de software son
la declaración acordada de los requerimientos del sistema, se debe de organizar para que lo utilicen clientes del sistema y desarrolladores del software.
¿Qué es ingeniería de
requerimientos?
Ingeniería de Requerimientos
► El IEEE define:
► Proceso de estudio de las necesidades de los
usuarios con el objeto de llegar a una definición del sistema hw/sw.
► El proceso de estudio y refinamiento de un
IF 7201 - Gestion de Proyectos de Software I 2006 29
Ingeniería de Requerimientos
► ( Zave )
▪ Rama de la ingeniería del software que trata con el establecimiento de los objetivos,
funciones y restricciones de los sistemas software.
▪ Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer
Procesos de ingeniería de requerimientos
► Los procesos usados para los Requerimientos varían
ampliamente dependiendo del dominio de la aplicación, de las personas involucradas y de la organización que
desarrolla los requerimientos.
► No obstante, hay varias actividades comunes a todos los
procesos
▪ Obtención de requerimientos;
▪ Análisis de requerimientos;
▪ Validación de requerimientos;
El proceso de ingeniería de requerimientos
Estudio de factibilidad Obtención y Análisis de requerimientos Especificación de requerimientos Validación de requerimientos Informe de factibilidad Modelos de sistemas Requerimientos del usuario y del sistemaDocumento de requerimientos
Ingeniería de requerimientos
Especificación de requerimientos Modelación y especificación
De los requerimientos del sistema
Obtención de requerimientos del sistema Especificación de los Requerimientos del usuario Obtención de Requerimientos Del usuario Especificación de requerimientos Del negocio Creación de prototipos Estudio de factibilidad
Estudios de factibilidad
► Un estudio de factibilidad decide si el sistema propuesto
merece o no la pena.
► un estudio corto y orientado a resolver varias preguntas
▪ si el sistema contribuye a los objetivos de la organización;
▪ Si el sistema puede ser implementado utilizando la tecnología actual y dentro del presupuesto;
Factibilidad e implementación
► Basado en la valoración (lo que se necesita) de la
recolección de información y redacción de un informe.
► Preguntas para las personas de la organización
▪ ¿cómo se las arreglaría la organización si no se llevase a cabo este sistema?
▪ ¿Cuáles son los problemas con los procesos actuales?
▪ ¿cómo ayudaría el nuevo sistema a resolverlos?
▪ ¿cuáles serían los problemas de integración?
▪ ¿se necesita nueva tecnología?¿qué capacidades?
Obtención y análisis
► A veces llamado obtención de requerimientos o
descubrimiento de requerimientos.
► Implica el trabajo de personal técnico con los clientes para
informarse del dominio de la aplicación, los servicios que el sistema debería proporcionar y las restricciones operacionales del sistema.
► Debe implicar a los usuarios finales, administradores,
ingenieros implicados en el mantenimiento, expertos del dominio, sindicatos, etc. Todos estos son designados como stakeholders.
Espiral de los requerimientos
Organización y clasificación de los requerimientos Negociación y priorización de requerimientos Documentación de requerimientos Descubrimiento de requerimientosActividades del proceso
► Descubrimiento de los requerimientos
▪ Interactuar con los stakeholders para descubrir sus requerimientos. También son descubiertos los requerimientos del dominio en esta etapa.
► Organización y clasificación de los requerimientos
▪ Agrupa los requerimientos relacionados y los organiza en grupos coherentes
► Priorización y negociación
▪ Priorizar los requerimientos y resolver los conflictos de los requerimientos.
► Documentación de los requerimientos
▪ Los requerimientos se documentan y son introducidos en la siguiente ronda de la espiral
Técnicas y herramientas utilizadas en la IR
► Entrevistas y Cuestionarios
► Lluvia de Ideas (Brainstorm)
► Prototipos
► Proceso de Análisis Jerárquico (AHP)
► Administración de Requerimientos con casos de
39
Técnica Ventajas Desventajas
Entrevistas y
Cuestionarios • Mediante ellas se obtiene una gran cantidad de información correcta a través del usuario. • Pueden ser usadas para obtener un pantallazo
del dominio del problema. • Son flexibles.
• Permiten combinarse con otras técnicas.
• La información obtenida al principio puede ser redundante o incompleta.
• Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.
Lluvia de Ideas • Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclaradas por expertos.
• Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.
• Es necesaria una buena compenetración del grupo participante.
Prototipos • Ayudan a validar y desarrollar nuevos requerimientos.
• Permite comprender aquellos requerimientos que no están muy claros y que son de alta volatilidad.
• El cliente puede llegar a pensar que el prototipo es una versión del software que será
desarrollado.
• A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo
Análisis Jerárquico • Permite determinar el grado de importancia de cada requerimiento.
• Ayuda a identificar conflictos en los requerimientos.
• Muestra el orden en que deben ser implementados los requerimientos.
• Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.
Casos de Uso • Representan los requerimientos desde el punto de vista del usuario.
• Permiten representar más de un rol para cada afectado.
• Identifica requerimientos estancados, dentro de un conjunto de requerimientos.
• En sistemas grandes, toma mucho tiempo definir todos los casos de uso.
• El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.
Técnicas que pueden ser utilizadas en las
actividades de IR
Análisis del Problema Evaluación y negociación Especificación de Requisitos Validación Evolución Entrevistas y Cuestionarios X X Lluvia de Ideas X X Prototipos X Análisis Jerárquico X XValidación de requerimientos
► Se ocupa de demostrar que los requerimientos
definen el sistema que el cliente realmente quiere.
► Los costes de los errores de requerimientos son
altos así que la validación es muy importante.
▪ Arreglar un error de requerimientos después de la
entrega puede costar unas 100 veces el coste de arreglar un error de implementación.
Comprobación de requerimientos
► Validez.
¿Proporciona el sistema las funciones que mejor sostienen las necesidades del cliente?
► Consistencia
¿hay algún conflicto entre requerimientos?
► Integridad
¿Se incluyen todas las funciones requeridas por el cliente?
► Realismo
¿Pueden los requerimientos ser implementados, dotados de presupuesto y tecnología disponibles?
Técnicas de validación de requerimientos
► Revisión de requerimientos
▪ Análisis sistemático manual de los requerimientos
► Creación de prototipos
▪ Utilizar un modelo ejecutable del sistema para
comprobar los requerimientos. Tratado en el tema 17.
► Generación de casos de prueba
▪ Desarrollar pruebas ayuda a verificar la claridad de
Revisión de requerimientos
► Deberían ser realizadas revisiones regulares mientras está
siendo formulada la definición de los requerimientos
► Tanto el cliente como el contratista deberían estar
involucrados en las revisiones.
► Las revisiones pueden ser formales (con documentos
completos) o informales. Las buenas comunicaciones entre los desarrolladores, el cliente y los usuarios puede resolver
45
Evolución de requerimientos
► Los requerimientos evolucionan constantemente con
dos objetivos básicos:
▪ Entender mejor las necesidades de los usuarios.
▪ Para adaptarse a las necesidades cambiantes de los usuarios.
► Es esencial tener en cuenta estos cambios, tanto del
Evolución de requerimientos
Entendimiento inicial del problema
Cambios en el entendimiento del problema Requerimientos Iniciales Requerimientos Cambiados
Control de la evolución
Documento de Requerimientos V1 Implementación Sistema V1 Implementación Sistema V1 Documento de Requerimientos V1 Implementación Sistema V2 Documento de Requerimientos V2 Implementación Sistema V2 Cambio de RequerimientosRequerimientos y Sistema Inconsistentes
LA INGENIERÍA DE REQUISITOS
EN LOS MÉTODOS DE
Métodos Agiles
Informática Empresarial, UCR IF 7100 Ingeniería de Software
49
► Métodos que dan soporte a los valores incluidos en el
Manifiesto Ágil.
► Iterativos de ciclo corto y flexibles.
► Se centran más en el código que en la documentación,
debido a:
▪ Son más adaptativos que predictivos: poca planificación.
▪ Orientados a las personas: confian en la experiencia, competencia y colaboración
► Extreme Programming (XP)
▪ No habla explicitamente de técnicas de IR.
▪ Usa entrevistas, brainstroming, priorización e historias de usuario.
► Scrum
▪ Los requisitos se recolectan en el backlog (lista priorizada de características a implementar)
▪ En cada sprint se implementan las más prioritarias.
► Metodologías Crystal
▪ Alguna de las técnicas pueden ser comparadas con las de IR (prototipado, revisiones, pruebas)
► Desarrollo dirigido por características (FDD)
▪ La lista de características recogen de algún modo los requisitos.
➢ Desarrollo dirigido por pruebas (TDD)
▪ La lista de características se documenta en los casos de prueba automatizados y la validación se da
corriendo dichas pruebas contra el código fuente.
51
Informática Empresarial, UCR IF 7100 Ingeniería de Software
► Método de desarrollo de sistemas dinámico (DSDM)
▪ Los requisitos se elicitan en las dos primeras fases (viabilidad y estudio del negocio)
▪No hay técnicas especificas, se pueden usar varias.
► Desarrollo adaptativo de software (ASD)
▪Desarrollo iterativo e incremental con prototipos.
Técnicas de IR en los MA
IF 7201 - Gestion de
Proyectos de Software I 2006
53
►
Implicación de los usuarios:
▪ Suponen “cliente ideal” con todo el conocimiento.
▪ La IR tradicional evitan esta suposición con técnicas para confrontar y validar.
▪ En estos métodos los clientes sólo se implican en las primeras fases.
►
Entrevistas
▪ Es la principal técnica de elicitación de los MA (orientación al cliente)
Técnicas de IR en los MA
►
Priorización:
▪ Practica común de los MA
▪ Implementan primero los requisitos más valiosos para el cliente.
▪ Se re prioriza muy frecuentemente: adaptación al entorno.
►
Reuniones de análisis
▪ Son frecuentes durante todo el proceso.
▪ La documentación es menos extensa pero altamente disciplinada (por ejemplo todas las historias a
implementar deben cumplir con un criterio de aceptación con un formato estándar)
Técnicas de IR en los MA
55
►
Modelado
▪ A diferencia de la IR tradicional, en los MA solo se usan para facilitar la comprensión.
▪ Son de usar y tirar
►
Documentación
▪ No se pretende generar una documentación completa del proyecto.
Técnicas de IR en los MA
►
Validación
▪ Usan reuniones de revisión para la validación de requisitos.
►
Gestión de los Requisitos
▪ No es posible la trazabilidad total de los requisitos como en la IR tradicional.
▪ Sin embargo, proporcionan una buena base: backlog, lista de características, ...
Historias
de Usuario
57
► Una de las técnicas más usadas en los MA.
► Escritas por el usuario en su lenguaje, no contienen
aspectos técnicos.
► Sirven para estimar tiempos de desarrollo (casos de
uso), no necesitan más detalle.
► Tres frases aproximadamente y entre una y tres
semanas de desarrollo.
Puntos Clave
► Las fases de la IR están presentes en los MA, pero
no claramente separadas.
► Las técnicas están vagamente descritas, confian en
la capacidad de los técnicos, lo que requiere buen entrenamiento de los equipos
► Documentación poco extensa
▪ Perdida de conocimientos
▪ Más compacta y fácil de mantener
Puntos Clave
59
► Estimación de coste y tiempo difíciles, por la
aproximación perezosa.
► Los MA proporcionan muchas ventajas en el
desarrollo en comunicación y eficiencia.
► Requiere una alta disciplina y automatización de
procesos (como la trazabilidad) para poder ser realmente agiles.
