Este documento describe la importancia de la especificación de requerimientos en el desarrollo de sistemas de software. Explica los principios básicos del análisis y especificación de requerimientos, incluyendo los protagonistas involucrados, las características de una buena especificación de requerimientos y los enfoques comunes como las tarjetas CRC. Finalmente, presenta una actividad para que los estudiantes apliquen estos conceptos al desarrollar documentos de requerimientos para su proyecto de medio término.

1. Análisis y Especificación de Requerimientos Maestría en Administración de Tecnologías de Información Sesion 5a Dr. Juan Frausto Solís ITESM, Campus Cuernavaca Septiembre-diciembre del 2002

2. Contenido Importancia de la Especificación de Requerimientos Principios sobre Análisis y Especificación de Requerimientos. Documento de Especificación de Requerimientos IEEE Std 830, 1998 Protagonistas en el Análisis y Especificación de Requerimientos Características y Atributos de una buena Especificación de Requerimientos. Enfoques para la Especificación de Requerimientos VIA Tarjetas CRC Actividad via Proyecto de Medio Término

3. Importancia de la Especificación de Requerimientos I

4. Especificación de Requerimientos Requerimiento: Característica o Restricción de un Sistema. Ingeniería de Requerimientos: Proceso sistemático utilizado para derivar una definición del sistema de software a ser desarrollado.

5. Especificación de Requerimientos Especificación Análisis Definición Solicitud

6. Identificación de Requerimientos Por su origen: Funcionales : Comportamiento de los distintos módulos . No Funcionales : Re stricciones del sistema (tiempo de respuesta, almacenamiento, casos de uso, logística). Por su aparición cronológica: De análisis ( descubrimiento ) y diseño . De mantenimiento .

7. Errores de una mala ER Encontrar soluciones sin haber entendido los problemas . Problemas de gran escala : Los s istemas multi-versión y multi-programador deben trata rse diferente que sistemas pequeños . Teléfono descompuesto . Requerimientos cambiantes .

8. Errores de una mala ER Frecuentemente el cliente no sabe que quiere ; se le invent an necesidades falsas. Tareas mal identificadas . Establecimiento de requerimientos como mero trámite .

9. Costos Asociados por su Reparación Software Engineerign Economics, Boehm 1981 100 -200 Mantenimiento 50 Pruebas de Sistema 20 Pruebas de Módulo 10 Codificación 5 Diseño 1-2 Requerimientos COSTO DE REPARACIÓN ETAPA

10. Análisis del Problema Algunas Preguntas Útiles ¿ Qué hacer para obtener una ER completa ? ¿Cómo descomponer el problema en fragmentos manejables? ¿Cómo organizar la información para que sea entendida? ¿Cómo comunicar se con todas las partes involucradas? ¿Cómo se resolverán las necesidades en conflicto? ¿ C u án do detener el an á li sis ?

11. Captura y Especificación de Requerimientos 1 Entrevista con Usuarios / Cliente Identificar necesidades y deseos Modelado de casos de negocios, de uso,.. Bosquejo de interfaces Identificación de hardware 2 Escritura de requerimientos en modo estándar 3 Revisión, inspección y validación de requerimientos

12. Beneficios de la Especificación de Requerimientos Establecimiento de acuerdos entre proveedores y usuarios sobre la funcionalidad de l software. B ase para estimación de costos y calendarizaciones . B ase para validaciones y verificaciones . Facilita n transferencia y portabilidad . B ase para mejora continua del software.

13. Buenas Prácticas en la Especificación de Requerimientos S eguir guía s adecuadas para mejorar la práctica de especificación de requerimientos en forma objetiva. S eguir estándares reconocidos y aceptados .

14. Principios sobre Análisis y Especificación de Requerimientos II

15. Proceso de Ingeniería de Requerimientos Reporte de Factibilidad Estudio de Factibilidad Análisis de Requerimientos Modelos del Sistema Definición de Requerimientos Definición de Requerimientos Documento de Especificación de Requerimientos de Software Especificación de Requerimientos Especificación de Requerimientos

16. Especificación de Requerimientos de Software (SRS) ESPECIFICACION Descripción Técnica de las características del Sistema DEFINICIÓN Lo que el usuario espera que el sistema haga

17. Tipos de Requerimientos Requerimientos Ambiente Físico Interfaz Factores Humanos Funcionabilidad Documentación Datos Recursos Seguridad Aseguramiento de Calidad

18. Documento de especificación de requerimientos de Software IEEE Std. 830-1998 III

19. Std. IEEE 830-1998 Objetivo: Brindar una colección de buenas prácticas para escribir especificaciones de requerimientos de software (SRS). Se describ e n los contenidos y las cualidades de una buena especificación de requerimientos ; se m ue stran ejemplos de especificaciones.

20. Aspectos básicos de ER Funcionalidad ¿Qué debe hacer el software ? Interfaces Externas ¿Cómo interactuará el software con el medio externo (gente, hardware, otro s oftware )? Rendimiento Velocidad, disponibilidad, tiempo de respuesta, etc. Atributos Portabilidad, seguridad, mantenibilidad, eficiencia Restricciones de Diseño Estándares requeridos, lenguaje, límite de recursos, etc.

21. Partes del documento de E R Introducción Descripción Requerimientos Específicos Apéndices Índice

22. Partes del documento de E R Introducción Propósito Alcance Definiciones, acrónimos y abreviaciones Referencias Panorama General

23. Partes del documento de E R 2. Descripción Perspectiva del producto . Funciones del producto . Características de los usuarios . Restricciones . Suposiciones y dependencias .

24. Partes del documento de E R 3 Requerimientos Específicos Requerimientos Funcionales Requerimientos de Interfaz externa Requerimientos de desempeño Restricciones de diseño Atributos Otros

25. Evolución de una ER Los requerimientos deben ser establecidos tan completamente como sea posible desde las etapas iniciales  Refinamiento Posterior. Establecer procesos formales para cambios y modificaciones que permitan controlar, rastrear y reportar cambios futuros y pasados.

26. Protagonistas en el Análisis y Especificación de Requerimientos IV

27. Definición y Analisis de Requerimientos Usuarios finales del sistema, clientes Administradores e ingenieros Administradores de los contratos Arquitectos del sistema Desarrolladores de Software

28. Características y Atributos de una Buena Especificación de Requerimientos V

29. Características de las Especificaciones De Forma Modificabilidad Legilibilidad Organizada por referencia Organizada por revisión De fondo Completez Independendencia de Plataforma Consistencia Precisión Verificabilidad

30. Características y Atributos Documentación Correctez Completez Consistencia Estabilidad Verificable Modificable Rastreable

31. Enfoques para la Especificación de Requerimientos VI

32. Enfoques para SRS Tarjetas CRC Modelado Operacional: DFD’s,Redes de Petri, Máquinas de Estado. Logicos y Algebráicos: Z, LOTOS Modelado de Sistemas Modelo de Objetos Modelo de Rumbaugh Modelo de Booch Modelo de Jacobson Modelo Unificado

33. Tarjetas CRC Un método informal para modelado de software VI-A

34. Diseño Preliminar y Detallado Modelado a pequeña escala Para aplicaciones relativamente limitadas y poco complejas Modelado a gran escala Para aplicaciones complejas Dos tipos de orienta ción. Por descomposición. Se p arte de un modelo global del sistema (top down) Por composición.- Se modela partiendo de lo que se conoce de las distintas partes del sistema. (bottom-up) S e incluyen los tipos de diagramas que describen el sistema (clases, objetos, transiciones, etc.)

35. Verificación y Validación Identificación de defectos De ambigüidad De consistencia De completez Definición de equipo de revisión del proyecto Diseño de pruebas Diseño de prototipos (Versiones Beta) Verificaciones Iniciales e Intermedias

36. Verificación y Validación Administración de Riesgos Algunos errores comunes: Desuso de variables Anidaciones y bifurcaciones impropias Variables no definidas Recursiones no autorizadas Cálculos erróneos Ciclos infinitos potenciales Violación de estándares Inconsistencias etc.

37. Tarjetas CRC - ¿Qué son? Tarjeta indexada que información de un objeto, una clase, su comportamiento y sus interacciones. CRC – Class Responsabilities Collaborators Introducidas por Kent Beck and Ward Cunningham

38. ¿Porqué son útiles? Son portables Visualizar el funcionamiento del proyecto sin necesidad de software Son útiles para el proceso de enseñanza del enfoque orientado a objetos Pueden utilizarse como una metodología en sí mismo o como el “front-end” de una metodología en particular (Booch, OMT, etc)

39. ¿Cómo son? Normalmente miden 3x5 ó 4x6 pulgadas. Tienen la siguiene forma:

40. ¿Cómo se usan ? Se usan normalmente en sesiones de experto del área/desarrollador o desarrollador/desarrollador en grupos no mayores a 6 personas para discutir sobre las características de la implementación.

41. Sesión CRC Orden de la Sesión: Análisis del problema Definición de clases Tormenta de ideas Filtrado de clases Definición de superclases y subclases Definición de responsabilidades. Definición de atributos. Operación en escenarios determinados.

42. Actividad Para tu proyectos de Medio término elabora los siguientes reportes: Documento de Especificación de requerimientos de acuerdo con el estándar de la IEEE. Reporte de Factibilidad de requerimientos. Identifica los riesgós a que se enfrentará el sistema (incluyendo nuevas tecnologías o nuevo uso de ellas). Evalúa la factibilidad de realización, de buen uso del sistema. Reporte del Proceso de Ingeniería de requerimientos en formato libre, describiendo el proceso para lograr los documentos anteriores.