Seminario de Actualización Docente Tema: Ingeniería de Requerimientos

Presentación del tema: "Seminario de Actualización Docente Tema: Ingeniería de Requerimientos"— Transcripción de la presentación:

1 Seminario de Actualización Docente Tema: Ingeniería de Requerimientos
Universidad Tecnológica Nacional Facultad Regional Córdoba Cátedra de Análisis de Sistemas Seminario de Actualización Docente Tema: Ingeniería de Requerimientos Disertante: Ing. Judith Meles Abril de 2001

2 El Problema de los Requerimientos
1) Lo que el usuario necesita 2) Lo que el usuario cree necesitar 3) Lo que le transmitió al profesional

3 El Problema de los Requerimientos
4) Lo que el profesional entendió 5) Lo que se entregó al principio 6) Lo que al final resultó

4 ESPECIFICACIÓN DE REQUERIMIENTOS
Introducción La efectividad y flexibilidad de un sistema está extrechamente relacionada a la correcta comprensión de las necesidades de los clientes y/o usuarios del sistema, hay un componente clave en todo proceso de desarrollo , que juega un papel central, llamado.... ESPECIFICACIÓN DE REQUERIMIENTOS

5 ¿ Qué es un Requerimiento? (Definición IEEE-Std-610 - 1990)
Condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. Condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto. Representación documentada de una condición o capacidad como las expresadas anteriormente.

6 Requerimientos: Categorías
En general, caen en dos grandes categorías: orientado al mercado específico para un cliente

7 Requerimientos Orientados al Mercado
Bocetados e informales Técnicas más de manufactura que de Ingeniería de Software Especificación en forma de presentación comercial “Cliente” no fácilmente identificable Se basan en Consultores para aspectos deseables Enfoque poco estructurado.

8 Requerimientos Específicos para un cliente
Voluminosos y más “formales” Uso de técnicas de Ingeniería de Software Largas especificaciones Uso del conocimiento del dominio Proyectos basados en personal propio Método estructurado siguiendo un enfoque particular

9 Una Perspectiva Organizacional
Requerimientos: Una Perspectiva Organizacional La contribución de los SI a las organizaciones Automatizar reduciendo costos de proceso Informar a los tomadores de decisiones Transformar la organización Prerequisitos Visión del negocio y la organización Alineación de los SI con la estrategia corporativa El desarrollo de los SI tiene que ver con: Necesidades de los involucrados Requerimientos del usuario y estrategia de negocios

10 De la automatización de la rutina a los procesos críticos
La especificación de requerimientos debe atender a: mejorar la gestión del cambio integrar visiones dentro de la empresa vincular la estrategia empresaria con los SI ER como camino para gerenciar el cambio: comprensión conceptual del status actual definición del cambio implementación del cambio integración de esta nueva implementación

11 Una Perspectiva del Software
Requerimientos: Una Perspectiva del Software Los errores en la definición de requerimientos resulta en un mantenimiento costo de los sistemas de software. Surge la Ingeniería de Requerimientos como un sub-campo de la Ingeniería de Software

12 Importancia de los requerimientos
Premisa Hacer un mejor trabajo definiendo y especificando software no sólo vale la pena sino que tambien es posible y ventajoso en costo Soporte: 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 Los errores de requerimientos son comúnmente: hechos, incorrectos, omisiones, inconsistencias y ambigüedades Los errores en los requerimientos pueden detectarse

13 Catarata de Errores de Mizuno
corregibles errores no funciones correctas ocultos especificación correcta incorrecta diseño correcto diseño basado en especificación incorrecto Especificación de Requerimientos Diseño Implementación Testing PROBLEMA REAL programas basados en diseño programas correctos errores de programación Diseño correcto Errores

14 Impacto de los errores en la etapa de requerimientos
El software resultante puede no satisfacer a los usuarios Las interpretaciones múltiples de los requerimientos pueden causar desacuerdos entre clientes y desarrolladores Es imposible que a través del testeo el software satisfaga sus requerimientos Puede gastarse tiempo y dinero construyendo el sistema erróneo

15 Evolución de Requerimientos
Comprensión inicial del problema Cambios en la comprensión del problema Requerimientos Cambiados Requerimientos iniciales Tiempo

16 Clases de Requerimientos
Requerimientos Durables: son relativamente estables, derivan de las actividades centrales del negocio, los cuales se relacionan directamente con el dominio del sistema. Requerimientos Volátiles: son aquellos que tienen probabilidad de cambiar durante el desarrollo del sistema o después que el sistema se haya puesto en producción.

17 Clasificación de Requerimientos Volátiles
Mutables: los requerimientos cambian debido al entorno en el cual la organización opera. Emergentes: surgen con la comprensión de los clientes del sistema, durante su desarrollo. El diseño puede relevar nuevos requerimientos. Consecuentes: resultan de la introducción del sistema de computación, cambiando los procesos del negocio y abriendo nuevas formas de trabajo que generan nuevos requerimientos De Compatibilidad: dependen de un sistema o proceso en particular dentro del negocio, si cambian, los requerimientos relacionados deberán cambiar.

18 Especificación de Requerimientos
La documentación de Requerimientos para la construcción de Software es la actividad que tradicionalmente se ha llamado Especificación de Requerimientos. La Especificación de Requerimientos representa ambos: un modelo de lo que se necesita y una definición del problema bajo consideración.

19 Especificación de Requerimientos
Razones para esforzarse en su desarrollo.... Focaliza el proceso comunicacional en la comprensión a cerca del dominio, el negocio y el sistema propuesto. Puede ser parte de un arreglo contractual. Puede usarse para la evaluación del producto final, y tener unrol crucial en las pruebas de aceptación del sistema.

20 Especificación de Requerimientos
Una nueva visión para su desarrollo... Requerimientos Empresariales Especificación de Requerimientos Requerimientos No Funcionales Requerimientos Funcionales Evaluación

21 Requerimientos Funcionales
Relacionados con la descripción del comportamiento fundamental de los componentes del software. Las funciones son especificacdas en términos de entradas, procesos y salidas. Una vista dinámica podría considerar aspectos como el con trol, el tiempo de las funciones (de comienzo a fin) y su comportamiento en situaciones excepcionales.

22 Requerimientos No Funcionales
Juegan un papel crucial en el diseño y desarrollo del sistema de información. Pueden definirse como consideraciones o restricciones asociadas a un servicio del sistema. Sueles llamerse también requerimientos de calidad o no comportamentales en contraste con los comportamentales. Pueden ser tan críticos con los funcionales.

23 Dificultades asociadas a los Requerimientos No Funcionales
No hay reglas ni lineamientos para determinar cuando se obtuvo una solución óptima. Tiene buenas y malas soluciones, no soluciones correctas e incorrectas Problemas relacionados con requerimientos no funcionales pueden ser síntomas de problemas mayores. Hay dos atributos que deben poseer: deben ser objetivos y testeables.

24 Requerimientos No Funcionales: Tipos
Requerimientos del Producto Requerimientos Organizacionales Requerimientos Externos Requerimientos de Eficiencia Requerimientos de Confiabilidad Requerimientos de Portabilidad Requerimientos Interoperatibidad Requerimientos Eticos Requerimientos de Usabilidad Requerimientos de Entrega Requerimientos de Entrega Requerimientos de Estándares Requerimientos Legales Requerimientos De Performance Requerimientos De Espacio Requerimientos de Privacidad Requerimientos de Seguridad

25 Ingeniería de Requerimientos
“Es el proceso sistemático de desarrollar requerimientos a través de un proceso cooperativo e iterativo de analizar el problema, documentar las observaciones resultantes en una variedad de formatos de representación y chequear la precisión de la comprensión obtenida”

26 Características del proceso
Representación, aspecto social y aspecto cognitivo De una formulación informal a una especificación formal Proceso no determinístico y no lineal Elicitar, especificar y validar requerimientos, no son actividades predominantemente técnicas Típica actividad de resolución de problemas.

27 Aspectos principales de la Ingeniería de Requerimientos
Comprender el problema Describir el problema Acordar sobre la naturaleza del problema

28 Propuesta de la Ingeniería de Requerimientos
Validación Especificación Elicitación RASTREABILIDAD HACIA DELANTE Y HACIA ATRAS

29 Interacción entre Procesos de la Ingeniería de Requerimientos
Elicitación Especifica ción Validación Usuario Dominio del Problema Feedback del usuario Requerimientos del usuario Modelos a validar por el usuario Especificación de Requerimientos Modelos de Requerimientos Conocimiento Necesidad de más conocimiento Resultados de la validación Conocimiento del dominio

30 Productos entregables
Modelos ... Del dominio del problema De los requerimientos funcionales De los requerimientos no funcionales

31 Elicitación: Propósito
Ganar conocimiento relevante del problema, para producir una especificación rigurosa del software necesario para resolver el problema. Al final del proceso el analista podría ser un “experto” en el dominio del problema.

32 Elicitación: Entradas
Fuentes del conocimiento del dominio: Expertos del dominio Literatura sobre el dominio Software existente en el dominio Software similar en otros dominios Standards nacionales e internacionales Otros “involucrados”

33 Elicitación: Actividades
Tareas a encarar por el analista: Identificar fuentes de conocimiento Adquirir el conocimiento Decidir sobre la relevancia de un conocimiento Comprender la significación del conocimiento y su impacto

34 Elicitación: Actividades
Técnicas más usadas : Entrevistas Torbellino de Ideas Escenarios Reuso de conocimiento Análisis de Documentación Observación Análisis de Objetivo / Meta

35 Elicitación: Productos
Es un proceso de creación de modelos El analista comienza con modelos mentales con conocimiento dependiente del domino Al avanzar, los modelos son más orientados al software No se produce ningún modelo formal Sucesión de modelos mentales del dominio del problema

36 Especificación: Propósito
Acuerdo usuarios-desarrolladores sobre el problema a resolver Pauta para el desarrollo de un sistema de software

37 Especificación: Entradas
Conocimiento sobre el dominio del problema Lo provee el proceso de elicitación

38 Especificación: Actividades
Análisis y asimilación del conocimiento de los requerimientos Síntesis y organización del conocimiento en un modelo de requerimientos coherente y lógico

39 Especificación: Productos
Se producen una variedad de modelos: modelos orientados al usuario, que especifican comportamiento, características no funcionales, etc. modelos orientados al desarrollador, que especifican propiedades funcionales y no funcionales del software y restricciones

40 El Problema... A partir del Modelo de requerimientos se puede establecer que no contiene definiciones contradictorias, pero... Un modelo correcto de requerimientos no es necesariamente el modelo de requerimientos correcto. No existen los REQUERIMIENTOS de los requerimientos El peligro está en hacer el esfuerzo de analizar el problema erróneo.

41 Causas de los errores Dificultades en la elicitación de los requerimientos del usuario. Dificultad en establecer un esquema de comprensión común entre analista y usuario.

42 Validación: Propósito
Certifica la consistencia del modelo (de requerimientos) con las intensiones de clientes y usuarios Ayuda a hacer el artefacto correcto La necesidad aparece cuando se modifica el modelo actual Se aplica también a los modelos intermedios

43 Validación: Entradas Todo modelo está sujeto a validación, por lo tanto cada modelo es input El conocimiento sobre el dominio del problema debe ser validado Algunas partes del modelo formal

44 Validación: Actividades
Interacción entre analistas, clientes del sistema y usuarios en el dominio del problema. Similar a formular una nueva teoría científica y posteriormente testearla Caracterizada por: preparación del experimento ejecución del experimento y análisis de los resultados

45 Validación: Técnicas Prototipos Animación Enfoque de Sistemas Expertos

46 Prototipos Proceso de construcción y evaluación de modelos de trabajo de un sistema para aprender de ciertos aspectos del sistema requerido y/o su solución potencial. Técnica común de la ingeniería. En Ingeniería de Software: es el paradigma de producir software tan rápido y económicamente como sea posible en alguna etapa del desarrollo. Un modelo es considerado un prototipo si: es posible obtener información sobre el comportamiento y performance del sistema que se “prototipea” construir el prototipo debería ser un proceso rápido

47 Tipos de prototipos Prototipo de comportamiento, es un modelo en caja negra del sistema que muestra como responde a los estímulos. En un modelo funcional Prototipo estructural, muestra como el sistema “prototipeado” cumplirá con este comportamiento. Es un modelo de caja de cristal que muestra la estructura interna y la organización del sistema. Modela los requerimientos no funcionales

48 Animación Visión gráfica múltiple de un proceso en acción. Se representan gráficamente los principales objetos y se interactúa con ellos (tiempo real) En el contexto de desarrollo de IS es un enfoque que provee un ambiente visual para validar y ejecutar simbólicamente especificaciones conceptuales (en términos de modelos de entidades, reglas y procesos) de un IS. “En el contexto de especificaciones conceptuales, visualización involucra la animación del comportamiento de un sistema y una interfase visual que refleja los resultados de eventos bajo la componente gráfica -cuando es apropiado la textual- de la especificación”

49 Animación: Características
Ventaja sobre prototipos: no impone decisiones de diseño muy tempranas Provee una indicación de la dinámica del sistema mediante una recorrida Permite determinar relaciones causales escondidas en la especificación

50 Enfoque de sistemas expertos
Algunas herramientas CASE reciben el calificativo de sistemas expertos por el conocimientos de algunos aspectos del proceso que ellos corporizan. Este puede ser: conocimiento del método, conocimiento de cómo aplicar un método de RE conocimiento del dominio, conocimiento sobre el dominio el cual se supone se modeló

51 Modos de acción de un Sistema Experto
Comportamiento de un sistema experto en RV experto, lleva a cabo el proceso de validación, asistente, asiste al analista en la validación aprendiz, ejecutar las actividades de bajo nivel de la validación

52 Validación: Salidas Modelo de requerimientos en línea con las expectativas de los usuarios No significa que el modelo sea correcto Compromiso entre lo deseado y lo posible y factible

53 Validación Interacción con otros procesos
LLa validación está presente en todos los procesos de la IR, la dispara: nuevo conocimiento sobre el dominio del problema (elicitación) formulación de un modelo de requerimientos (especificación) La validación se requiere en las etapas de análisis y síntesis (pues debe chequearse la corrección de la información)

54 Verificabilidad de los Requerimientos
Los requerimientos deberían ser escritos de manera tal que puedan ser objetivamente verificables. El problema con el requerimientos es el uso de términos vagos. El ratio de errores debería ser cuantificado.

55 Medidas de los Requerimientos
Propiedad Medida Velocidad Transacciones / Segundo Procecesadas Tiempo de Respuesta de Evento / Usuario Tiempo de barrido de la pantalla Tamaño K Bytes Número de chips de RAM Facilidad de Uso Tiempo de capacitación Número de entornos de ayuda Confiabilidad Tiempo medio entre fallas Probabilidad de indisponibilidad Ratio de Ocurrencia de Fallas Disponibilidad Robustez Tiempo de reinicio después de fallas Porcentaje de Eventos que causan fallas Probabilidad de corrupción de datos durante una falla. Portabilidad Número de Sistemas destino Porcentaje de definiciones dependientes del destino

56 Propiedades Deseables para la Especificaicón de Requerimientos
Consistencia Interna No ambigüedad Consistencia Externa Minimalidad Completitud Rastreabilidad

57 Indice del Standard de IEEE para la Especificación de Req. de Software
1. Introducción 1.1. Propósito 1.2. Alcance 1.3. Definiciones, acrónimos y abreviaturas 1.4. Referencias 1.5. Overview 2. Descripción general 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Características del usuario 2.4. Restricciones generales 2.5. Supuestos y dependencias 3. Requerimientos específicos Apéndices

58 1.Introducción 1.1. Propósito
Delinear el propósito de la SRS y especificar a quién se dirige 1.2. Alcance Identificar los productos de SW, explicar que hará y que no hará cada uno, describir la aplicación 1.3. Definiciones, acrónimos y abreviaturas Incluir las definiciones de los términos, acrónimos y abreviaturas requeridas para interpretar la SRS. 1.4. Referencias Proveer una lista completa de todos los documentos referenciados 1.5. Overview Describir qué contiene el resto de la SRS y explicar cómo está organizada la SRS 1.1. Propósito 1. Delinear el propósito de la SRS en particular 2. Especificar la audiencia a la que se dirige la SRS 1.2. Alcance 1. Identificar los productos de software ha ser producidos por nombre, por ejemplo: DBMS del Host, Report Generator, etc. 2. Explicar que hará y, si es necesario, que no hará el producto de software 3. Describir la aplicación del software a ser especificado. Como parte de este, debería: · Describir todos los beneficios relevantes, objetivos y metas tan precisamente como sea posible · Ser consistente con especificaciones de mayor nivel (como un análisis del dominio o un plan de sistemas) 1.3. Definiciones, acrónimos y abreviaturas Debería incluir las definiciones de todos los términos, acrónimos y abreviaturas requeridas para interpretar la SRS. Esta información puede proveerse por referencia a apéndices de la SRS o a otros documentos. 1.4. Referencias 1. Proveer una lista completa de todos los documentos referenciados en otra parte de la SRS o en un documento, separado, especifico. 2. Identificar cada documento por título, numero de informe (si corresponde), fecha y organización que lo publicó. 3. Especificar las fuentes de dónde se obtuvieron las referencias. Esta información puede darse por referencia a un apéndice o a un documento por separado. 1.5. Overview 1. Describir qué contiene el resto de la SRS 2. Explicar cómo está organizada la SRS

59 2.Descripción General Describe los factores generales que afectan al producto y a los requerimientos, facilita su comprensión 2.1. Perspectiva del producto Relación con otros productos o proyectos Productos independientes Componentes de un sistema o de un proyecto: Hardware y equipamiento periférico Diagrama de bloques Restricciones de diseño 2.2. Funciones del producto Resumen de las funciones que ejecutará el software. Comprensibilidad No establece requerimientos específicos, 2. Descripción General Esta sección describe los factores generales que afectan al producto y a los requerimientos. No tiene como meta establecer requerimientos específicos, sólo hace que esos requerimientos sean más fáciles de comprender. 2.1. Perspectiva del producto Esta subsección de la SRS pone al producto en perspectiva con otros productos o proyectos. 1. Si el producto es independiente y totalmente autocontenido, aquí debe establecerse. 2. Si la SRS define un producto que es una componente de un sistema o de un proyecto mayor, en esta sección debería: · Describir las componentes del sistema o proyecto mayor e identificar las interfases · Identificar las principales interfases externas del producto de software que se está especificando (la descripción no debe ser detallada) · Describir el hardware de computadoras y equipamiento periférico a ser usado (esta es una descripción global) Puede ser útil un diagrama de bloques del sistema o proyecto mayor con las interconexiones e interfases externas. Esta subsección debería proveer las razones por las que ciertas restricciones de diseño serán especificadas más adelante en la SRS. 2.2. Funciones del producto Es un resumen de las funciones que ejecutará el software, sin mencionar los detalles que requieren esas funciones. Muchas veces este resumen puede extraerse de la especificación de mayor nivel. A los efectos de claridad: 1. Las funciones deberían organizarse haciendo que la lista de funciones sea comprensible al cliente o a cualquiera que lea el documento por primera vez 2. Diagramas de bloques que muestran las funciones y sus relaciones pueden ser útiles. Esta sección no debería establecer requerimientos específicos, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos.

60 2.Descripción General - II
2.3. Características del usuario Características generales del usuario Restricciones impuestas por los interactuantes Requerimientos específicos o restricciones sobre la solución 2.4. Restricciones generales Límites al desarrollador 2.5. Supuestos y dependencias Factores que afectan los requerimientos Restricciones de diseño Cambios quepueden afectar los requerimientos en la SRS. 2.3. Características del usuario Describe las características generales del usuario que afectarían los requerimientos específicos. De las muchas personas que interactúan con un producto, algunas características tales como nivel educacional, experiencia y expertise técnico imponen restricciones importantes en el ambiente operacional del sistema. Esta subsección no debería establecer requerimientos específicos ni restricciones sobre la solución, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos o restricciones de diseño. 2.4. Restricciones generales Describe en términos generales cualquier ítem que limite al desarrollador las opciones para diseñar el sistema. Estas incluyen: 1. Políticas regulatorias 2. Limitaciones de hardware 3. Interfases con otras aplicaciones 4. Operaciones paralelas 5. Funciones de auditoría 6. Funciones de control 7. Requerimientos de lenguajes de alto nivel 8. Protocolos de “signal handshake” (ej: XON/XOFF) 9. Criticalidad de la aplicación 10. Consideraciones de seguridad (Safety and Security) 2.5. Supuestos y dependencias Esta subsección debería listar cada uno de los factores que afectan los requerimientos establecidos en la SRS. Estos factores no imponen restricciones de diseño sobre el software, pero cada cambio en ellos puede afectar los requerimientos en la SRS.

61 Descripción General - III
2.4. Restricciones generales Límites a las opciones para diseñar el sistema: Políticas regulatorias Limitaciones de hardware Interfases con otras aplicaciones Operaciones paralelas Funciones de auditoría Funciones de control Requerimientos de lenguajes de alto nivel Protocolos de “signal handshake” (ej: XON/XOFF) Criticalidad de la aplicación Consideraciones de seguridad (Safety and Security) 2.4. Restricciones generales Describe en términos generales cualquier ítem que limite al desarrollador las opciones para diseñar el sistema. Estas incluyen: 1. Políticas regulatorias 2. Limitaciones de hardware 3. Interfases con otras aplicaciones 4. Operaciones paralelas 5. Funciones de auditoría 6. Funciones de control 7. Requerimientos de lenguajes de alto nivel 8. Protocolos de “signal handshake” (ej: XON/XOFF) 9. Criticalidad de la aplicación 10. Consideraciones de seguridad (Safety and Security) Esta subsección no debería establecer requerimientos específicos ni restricciones sobre la solución, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos o restricciones de diseño.

62 3.Requerimientos específicos
El sector mayor y más importante de la SRS Presentación y conceptualización del desarrollo de los requerimientos El contexto de la ingeniería de requerimientos. 3. Los requerimientos específicos La presentación de estos está estrechamente asociada con la conceptualización que se tenga del desarrollo de los requerimientos, de allí que esta parte, la mayor y más importante de la SRS, se debe presentar en el contexto de la ingeniería de requerimientos.

63 Requerimientos específicos - I
3.1. Requerimientos funcionales Requerimientos funcionales 1 Introducción Inputs Procesos Outputs ..... 3.1.n. Requerimientos funcionales n 3.2. Requerimientos de interfase externa Interfases del usuario Interfases del hardware Interfases del software Interfases de comunicaciones 3.3. Requerimientos de performance 3.4. Restricciones de diseño Cumplimiento de standards Limitaciones de Hardware ....

64 Requerimientos específicos - II
3.5. Atributos Disponibilidad Seguridad Mantenibilidad Transferibilidad/conversión ... 3.6. Otros requerimientos Base de Datos Operaciones Adaptación del lugar

65 Bibliografía Loucopoulos, P., Karakostas, V., System Requirements Engineering, McGraw-Hill, 1995, London. Sommerville, Ian, Software Engineering 5Th Edition, Addison Wesley, 1995