Requisitos -

1. Ingeniería delSoftware
   Requerimientos del Software.
   Lic. Maria Segovia

2. ¿Qué son los requisitos o requerimientos?
   Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .
• 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.
• Una representación documentada de una condición o necesidad.
3. Que se considera como un requisito
• Una facilidad a nivel usuario Ej.: ‘el procesador de palabras debe incluir un verificador de ortografía y un comando de corrección’
• Una propiedad muy general del sistemaEj.: ‘el sistema debe asegurar que la información personal nunca se haga disponible sin autorización’
• Una restricción específica del sistema Ej.: ‘el sensor debe ser activado 10 veces por segundo’
• Una restricción para el desarrollo del sistema Ej.: ‘el sistema debe ser desarrollado usando Ada’
• Cómo llevar a cabo algún cálculo Ej.: ‘la nota final debe ser calculada sumando las notas del examen, proyecto y cursada del estudiante basado en la siguiente fórmula nota final = nota_exam + 2 * nota_proy + 2/3 * nota_cursada’
4. Que se considera como un requisito
• Propiedades del dominio: “Cosas” en el dominio de aplicación que son verdaderas independientemente que se construya o no el sistema de software
• Requisitos: “Cosas” en el dominio de aplicación que se desean sean verdaderas mediante la construcción del sistema de software
• Especificación: descripción de comportamiento (y datos) que el programa tiene que tener para cumplir los requisitos
• Sólo puede ser descrito en términos de los fenómenos compartidos por la máquina y el dominio de aplicación
5. Actores relacionados con el sistema
   Llamados Stakeholder. Entidad que será afectada por el sistema y que tienen una influencia directa o indirecta sobre los requisitos del sistema.
• Usuarios finales del sistema
• Gerentes involucrados en los procesos organizacionales influenciados o que influencian al sistema
• Ingenieros responsables por el desarrollo y mantenimiento del sistema,
• Clientes de la organización
• Cuerpos externos tales como autoridades reguladoras o de certificación.
6. Levantamiento de requisitos
   Definición de requisitos
• Expresa en lenguaje natural o con diagramas los servicios y restricciones operacionales del sistema. Se genera con la información proporcionada por el cliente.

Especificación de Requisitos

• Documento estructurado que describe con detalle los servicios del sistema. A veces llamado especificación funcional. Escrito como contrato con el cliente.

Especificación de software

• Escrito para los diseñadores. Sirve de base para el diseño y desarrollo del sistema.
6. Documento de requisitos
   El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software.
   Nombres:
   Especificación funcional,
   Definición de requisitos,
   Especificación de los requisitos de software
7. Documento de requisitos
   El documento describe:
• Los servicios y funciones que el sistema debería proveer.
• Las restricciones bajo las cuales el sistema debe operar
• Las propiedades generales del sistema, es decir, restricciones sobre las propiedades emergentes del sistema
• Definiciones de otros sistemas con los cuales el sistema se debe integrar.
• Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos.
• Restricciones sobre el proceso usado para desarrollar el sistema
• glosario
8. Usuarios del documento de requisitos
   Especifican los requisitos y los leen para chequear que atienden sus necesidades. Especifican cambios en los requisitos.
   Clientes del sistema
   Usan los documentos de requisitos para planificar una propuesta (oferta) para el sistema y planificar el proceso de desarrollo.
   Gerentes
   Usan los requisitos para entender qué sistema tiene que ser desarrollado.
   Ingenieros de sistemas
   Usan los requisitos para desarrollar pruebas de validación para el sistema.
   Ingenieros de prueba de sistemas
   Usan los requisitos para ayudar a entender los sistemas y las relaciones entre sus partes.
   Ing. de mantenimiento de sistemas
9. Modelo IEEE/ANSI 830-1998
   Introducción
• 1.1.Propósito del documento de requisitos
• 1.2.Alcance del proyecto
• 1.3.Definiciones, acrónimos y abreviaturas
• 1.4.Resumen del resto del documento

DescripciónGeneral

• 2.1.Perspectiva del producto
• 2.2.Funciones del producto
• 2.3.Características de los usuarios
• 2.4.Limitaciones generales
• 2.5.Suposiciones y dependencias

Requisitos Específicos

• 3.1.Requisitos funcionales, no funcionales

Apéndices
Índice

11. Ingeniería de requisitos (RE)
• RE trata la identificación del propósito de un sistema de software y el contexto en el cual será usado.
• RE actúa como un puente entre las necesidades del mundo real de los clientes y otros actores afectados
• Trata sobre los objetivos del mundo real para los sistemas de software, servicios provistos y restricciones.
• Trata sobre el comportamiento del sistema y su evolución a través del tiempo.
12. Importancia de la RE en el desarrollo de Software
    Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta repararlo.
    Muchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron. Muchos podrían detectarse tempranamente
    Se cometen muchos errores de requisitos
    Impacto de los errores en la etapa de requisitos
    El software resultante puede no satisfacer a los usuarios.
    Las interpretaciones múltiples de los requisitos pueden causar desacuerdos entre clientes y desarrolladores.
    Es imposible que a través del testeo el software satisfaga sus requisitos.
    Puede gastarse tiempo y dinero construyendo el sistema erróneo.
13. Actividades del proceso de la RE
14. Técnica JAD (JointAplicationDesigner)
• Permite a los usuarios, diseñar sistemas en forma conjunta, en sesiones grupales.
• Gibson y Jackson afirman que los resultados aumentan de un 20% a un 60%.
• Promueve la cooperación, el entendimiento y el trabajo grupal entre distintos grupos de usuarios.
15. Roles del JAD
• Líder de la sesión.
• Representante de los usuarios.
• Especialista.
• Analista.
• Representante de SS.
• Patrocinador (sponsor) ejecutivo o dueño del sistema.
16. Líder de Sesión
• Facilitador de JAD.
• Dirige el proceso.
• Facilita el debate y la preparación de documentos.
• Trata con el sponsor de JAD para acordar quién debe asistir las reuniones.
• Acordar la agenda con los participantes.
17. Plan JAD
• Dura entre uno y cinco días.
• El líder de la sesión guía a los participantes a lo largo de ocho tareas predefinidas. Ellas son:

Orientación.
Definición de requerimientos de alto nivel .
Límites y alcances del sistema .
Identificar y estimar tiempos de los Diseños JAD.
Identificar los participantes de los Diseños JAD.
Programar días y horarios para los Diseños JAD.
Acordar los puntos y consideraciones de la documentación a generar del Plan JAD.
Concluir la sesión.

18. Diseño JAD. Sesión de Diseño
• Dura aproximadamente entre tres y diez días.
• El líder de la sesión guía a los participantes a lo largo de las siguientes tareas:

Orientación.
Revisión y refinación de los requerimientos y alcance del Plan JAD.
Desarrollar diagrama de flujo del trabajo.
Desarrollar descripción del flujo de trabajo.
Identificar funciones y grupos de datos del sistema.
Especificar los requerimientos de procesamiento.
Acordar los puntos y consideraciones de la documentación a generar del Diseño JAD.
Concluir la fase de sesión.

19. Libros de Trabajo
• Formas predefinidas para los grupos, para que sean completadas durante la sesión.
• Formularios de participantes.
• Formularios de resultados.
• Formularios de estimaciones.
• Formularios de salidas por pantalla.
• Formularios de reportes.
• Formularios de descripción de interfaces y de descripción de funciones.
20. JAD y el proceso de Requerimientos
• La articulación del concepto de producto, requerimientos, medición de resultados.
• Análisis de problemas.
• Estudios de factibilidad y análisis de opciones de costo-beneficio.
• Análisis y modelado.
• La documentación de requerimientos.
21. JAD y la comunicación humana
    La identificación de varios puntos de vista.
    La conciliación de los puntos de vista.
    La revisión por parte del usuario de los modelos desarrollados.
    El análisis de los propios problemas del usuario y la identificación de la necesidad de cambio.
22. Análisis de puntos de función (FPA)
• Mide el tamaño del software desde el punto de vista del usuario. Medir la funcionalidad del producto.
• Es independiente de la tecnología usada para el desarrollo e implementación.
• Se aplica a partir de los documentos de requerimientos y a lo largo del ciclo de vida del software.
• Los enfoques para estimar Puntos Función (FunctionPoints - FP) facilitan la estimación temprana de un proyecto de software (costo, esfuerzo, cronograma) cuando los requerimientos no están completamente definidos.
23. Medición
• Es una práctica de administración Probada en el tiempo.
• No se puede administrar lo que no se puede medir.
• Un 40% de proyectos fracasan por falta de administración,
• Herramienta para determinar el tamaño del requerimiento, extrapolar la productividad y la calidad.
• Se mide para entender y mejorar procesos.
24. Clases de medición
• Medición: Cuantificación directa.

Estatura de una persona.

• Cálculo: Cuantificación indirecta.

A partir de la combinación de medidas se obtiene el valor del atributo de interés.
Ejemplo: medir la velocidad a partir de la distancia y el tiempo.

25. Medición del Software
• Se miden las características para saber si los requerimientos son consistentes y completos.
• Los administradores de proyectos miden procesos y productos para determinar tiempos de entrega y costos.
• Incluyen las siguientes actividades:

Estimación de costo y esfuerzo.
Medidas de productividad.
Recolección de datos.
Medidas de calidad y confiabilidad.
Performance.
Complejidad.
Métodos y herramientas.

26. Beneficios de la medición
• Entender que está ocurriendo en el desarrollo y mantenimiento para mejorar las relaciones entre actividades.
• Control de lo que ocurre en el proyecto, para predecir lo que ocurrirá y los cambios a realizar.
• Mejorar los procesos y productos, aumentando las revisiones del diseño se incrementa la calidad.
27. Medición del tamaño del sistema
    Tamaño del procesamiento de información
• Entradas
• Salidas.
• Otros

Requerimientos técnicos.

• Performance.
• Facilidad de uso.
• otros

Tamaño del sistema desde los requerimientos del usuario

28. Beneficios del FPA
• Mejorará la definición de los requerimientos.
• Comunicar requerimientos funcionales.
• Estimar esfuerzo, agenda y costos basado en requerimientos.
• Evaluar la factibilidad de un proyecto.
• Administrar los cambios.
• Mejorará el mantenimiento y soporte.
• Medir la productividad.
• Verificar la completitud.
29. Resumen de Objetivos
    ¿Qué son los requerimientos o Requisitos?
    Necesidades, objetivos y actores relacionados con los requerimientos
    Importancia de la Ingeniería de Requisitos en la práctica
    Levantamiento y Recolección de Requerimientos.
    Técnicas más usadas: Método JAD y FPA