• Author / Uploaded
• Romeo Velasquez

Citation preview

Unidad 3

El Documento de Requerimientos ¿De qué trata el Documento de Requerimientos? ¿Para qué sirve? ¿Qué diferencia tiene este documento con un modelo? ¿Qué técnicas de documentación pueden usarse? ¿Cuáles son sus limitaciones?

Documento de Requerimientos En la práctica es común describir los requerimientos en un documento llamado Especificación de Requerimientos del Software (SRS Software Requirements Specification) Modelos de Requerimientos especificación stakeholders

elicitación y modelado

sistemas existentes

Documento de Requerimientos

documentos

LaFHIS - Uchitel

análisis y validación

negociación y priorización

2

¿Para qué sirve un SRS? •

Comunicar de manera precisa los requerimientos, objetivos y presunciones del dominio

•

Contrato – legal, documento interno o a modo de memorando

•

Base para estimación (tamaño, costo, tiempo) y planificación de proyecto

•

Base para evaluación de producto final –

verificación y validación

–

Debería tener suficiente información para decidir si el producto final es aceptable (satisface los requerimientos)

•

Base para el control de cambios – Requerimientos cambian, software evoluciona, el entorno evoluciona

3

LaFHIS - Uchitel

Lectores de un SRS • Clientes y Usuarios

– Interesados en validar objetivos del sistema y descripción de alto nivel de la funcionalidad – Generalmente no interesados en los requerimientos detallados del sistema.

• Analistas (de sistemas, de requerimientos),

– Escribirán especificaciones de otros sistemas que interactúan con este. – El SRS sirve mas allá de la puesta en producción!

• Desarrolladores (ej. arquitectos, diseñadores, programadores, ...) – Deben implementar los requerimientos

• Testers (V&V’ers)

– Deben determinar la satisfacción de los requerimientos

• Gerentes

– Medir y controlar el proceso desarrollo

LaFHIS - Uchitel

4

Más lectores de un SRS • Equipo de Operaciones

– Deberán dimensionar equipos y procedimientos de rutina.

• Equipo de soporte de usuario

– Desarrollo de plan de capacitación – Generación de manuales de usuario – Procedimientos de soporte online

• Legales

– Los que firman los contratos

• Subcontratistas • Entes reguladores • ...

¿Cómo se escribe un documento que le sirva a una audiencia tan variada? 5

LaFHIS - Uchitel

¿Qué es un SRS apropiado? • Consideremos dos proyectos: A) Proyecto chico, 1 programador, 6 meses de trabajo programador habla con el cliente y escribe un memo de 5 hojas

B) Proyecto grande, 50 programadores, 2 años de trabajo Un equipo de analistas modelan los requerimientos y luego los documentan en un SRS de 500 paginas

LaFHIS - Uchitel

6

Contenido de un SRS Adaptado de IEEE-STD-830

• Un SRS deberá abarcar: – Funcionalidad. Que es lo que el software hace? – Interfases externas. Como debe interactuar con gente, con el hardware del sistema, con demás hardware y con demás software? – Atributos de Calidad. • Disponibilidad, tiempo de respuesta, tiempo de recuperación después de fallas, etc.. • Consideraciones de portabilidad, correctitud, precisión, mantenibilidad, seguridad y mas...

– Restricciones de diseño. Existen estándares a cumplir, lenguaje de programación, recursos, sistemas operativos, etc...?

7

LaFHIS - Uchitel

Standard de IEEE para un SRS Adaptado de IEEE-STD-830

1 Introduction

Purpose Scope Definitions, acronyms, abbreviations Reference documents Overview

2 Overall Description

Product perspective Product functions User characteristics Constraints Assumptions and Dependencies

3 Specific Requirements Appendices Index LaFHIS - Uchitel

Identifica el producto y el dominio de la aplicación Define el contenido y estructura del resto del documento Describe todas las interfaces externas: sistema, usuario, hardware, software

Resumen de funciones principales Cualquier cosa que limitará las opciones del desarrollador (ej. regulaciones, limitaciones de hardware, etc) La parte principal del documento. IEEE STD provee 8 esqueletos diferentes para esta sección 8

IEEE STD Sección 3 (ejemplo) 3.1 External Interface Requirements

3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communication Interfaces

3.2 Functional Requirements

this section organized by mode, user class, feature, etc. For example: 3.2.1 User Class 1

3.2.1.1 Functional Requirement 1.1 …

3.2.2 User Class 2

3.2.1.1 Functional Requirement 1.1 …

...

3.3 Performance Requirements 3.4 Design Constraints 3.4.1 Standards compliance 3.4.2 Hardware limitations etc.

3.5 Software System Attributes 3.5.1 Reliability 3.5.2 Availability 3.5.3 Security 3.5.4 Maintainability 3.5.5 Portability

3.6 Other Requirements 9

LaFHIS - Uchitel

Ejemplos de Organización de Requerimientos Funcionales - Sección 3.2. • …Estímulo o estado del mundo externo

– ej. Soporte de aterrizaje de aviones: viento, poca nafta, pista corta,...

• …Funcionalidad de alto nivel (top-down)

– ej. llamado en espera, desvío de llamado, llamado en conferencia, contestador...

• …Output del sistema

– ej. generar recibos de sueldo, reportes de costo, estado de cuentas...

• …Objeto externo

– ej. para una biblioteca, organizar por tipo de libro

• …Tipo de usuario

– ej. Sistema de admin. de proyectos: gerente, técnicos, admines, ...

• …Modo de operación

– ej. un procesador de palabras: page layout, outline, normal, ...

• …Subsistema

– ej. Auto: control, manejo de datos, comunicaciones, entretenimientos, ...

LaFHIS - Uchitel

10

Cualidades de un SRS (1) • Completitud – con respecto a los objetivos (ver Jackson): • Req, Dom |= G • Correspondencia entre el mundo real y G, • Correspondencia entre el mundo real y Dom • Completitud de G con respecto al mundo real

– con respecto a inputs: el comportamiento requerido del software ha sido especificado para todos los inputs posibles. – con respecto a estructura: no hay secciones rotuladas: “A completar...”

11

LaFHIS - Uchitel

Cualidades de un SRS (2) • Pertinencia – Cada requerimiento y presunción se necesita para la satisfacción de objetivo – El SRS no contiene elementos que no están relacionados con la definición de requerimientos (ej. decisiones de diseño o implementación)

• Consistencia – No hay contradicciones en la formulación de objetivos, requerimientos y presunciones

• “Medibilidad” – Los requerimientos han sido formulados de manera tal que su satisfacción pueda ser evaluada de manera no ambigua

LaFHIS - Uchitel

12

Cualidades de un SRS (3) • Precisión (No ambiguo) – No hay vocabulario ambiguo: cada término está definido y es usado consistentemente. – No hay aserciones ambiguas: Objetivos, requerimientos y presunciones deben estar escritos de manera tal que no permiten interpretaciones distintas – No hay responsabilidades ambiguas: la separación de responsabilidades entre el mundo y el software debe estar indicado claramente.

• Factibilidad – Los objetivos y requerimientos deberían ser realizables dentro del presupuesto y cronogramas dispuestos

13

LaFHIS - Uchitel

Cualidades de un SRS (4) • “Entendibilidad”

– debe ser entendible por todos los lectores potenciales.

• Trazabilidad

– debe identificar las fuentes de los objetivos, requerimientos, y presunciones – debe relacionar requerimientos y presunciones con los objetivos – debe facilitar referenciar de requerimientos en documentación futura (diseño, test, casos de test)

• Buena Estructura

– Ítems definidos antes de ser usados, índices, formateo, etc...

• Modificabilidad

– Debe ser fácil de adaptar, extender, o achicar con modificaciones locales. – Impacto de modificar un ítem debería ser fácil de estimar

LaFHIS - Uchitel

14

Contraejemplos (1) • Omisión de objetivos y requerimientos faltantes

– No hay un requerimiento sobre estado de las puertas en caso de emergencia

• Omisión de una reacción a un input

– Qué pasa si la alarma de emergencia es activada mientras las puertas se cierran

• Requerimientos inadecuados

– “Si un libro no es devuelto a la semana del tercer aviso de devolución, el usuario negligente será notificado y deberá pagar una multa de x$” vs. – “Si un libro no es devuelto a la semana del tercer aviso de devolución, x$ serán descontados a modo de multa de la cuenta corriente del usuario.”

15

LaFHIS - Uchitel

Contraejemplos (2) • Ruido – “Cada vagón estará equipado con un panel de información controlado vía software y con carteles de prohibido fumar en cada ventana”

• Relleno – Contenido sin información relevante. Ej. contenido con el objeto de cumplir estándares.

• Mala Estructura – Mezclar proceso de compra y préstamo de libros – Referencias hacia adelante: Múltiples usos de “participante” para luego introducir la definición de participante. – Definiciones incidentales: “El sistema enviará minutas a los participantes (aquellos que asistieron aunque sea parcialmente) de la reunión. LaFHIS - Uchitel

16

Contraejemplos (3) • Poca Modificabilidad – Uso de literales para valores cuantificables.

• Opacidad – Un requerimiento como: “el comando de velocidad del tren deberá ser siempre al menos 12kph por encima de la velocidad real del tren” sin información contextual de por qué, la fuente y el impacto sobre otros requerimientos.

• No medibilidad – Los paneles de información serán proveerán información de manera clara y precisa

17

LaFHIS - Uchitel

Una complicación: Contratación • Un ‘SRS’ puede ser escrito por... – …el contratante:

• el SRS sirve para llamar a licitación • Debe ser suficientemente general para lograr suficientes pliegos… • … y suficientemente específico para obviar pliegos no razonables.

– …los proveedores potenciales:

• Representa una propuesta para implementar un sistema que satisfaga algún llamado a propuestas. • Debe ser suficientemente especifico para demostrar factibilidad y competencia técnica... • …pero suficientemente general para no comprometerse demasiado.

– …el desarrollador seleccionado:

• refleja el entendimiento que tiene el desarrollador de las necesidades del cliente. • forma la base de una evaluación contractual de la performance del desarrollador.

– …o por un con consultor independiente en IR.

LaFHIS - Uchitel

18

Una complicación: Contratación • ¿Cuándo licitar/contratar? – Temprano (etapa conceptual) • sólo se pueden evaluar las propuestas sobre la aparente competencia técnica

– Tarde (etapa de especificación de requerimientos detallados) • mas trabajo para el contratante; experiencia en IR no necesariamente existe dentro de la organización

– IEEE recomienda que el SRS sea desarrollado conjuntamente por el contratante y el desarrollador

19

LaFHIS - Uchitel

Algunas Observaciones • El SRS será imperfecto – contendrá inconsistencias y imprecisiones – omitirá información, hará simplificaciones

• Mejorar la especificación tal vez no sea efectivo (costo vs. beneficio) – Análisis de requerimientos tiene un costo – Para diferentes proyectos, el costo-beneficio es diferente.

• Análisis reduce el riesgo de que las imperfecciones causen problema serios. • Estas son muchas veces malas excusas para no invertir en Ingeniería de Requerimientos LaFHIS - Uchitel

20

Resumen • Documento de Especificación de Requerimientos – Propósitos y audiencias – Cualidades esperadas, errores y falencias – Dificultades inherentes a la construcción de un SRS de calidad – Concepciones erróneas sobre el SRS – Contratación

21

LaFHIS - Uchitel

Una Observación Importante • Siendo el SRS el entregable más importante, suele tomar un protagonismo desproporcionado – El SRS no es el fin último de un proceso de IR

• Entendimiento del dominio de aplicación, identificación los problemas reales existentes, elaboración los sistemas que los resuelven, etc..

– El SRS no es el único soporte físico a producir • También los modelos juegan un rol

– El SRS no se comienza a escribir el primer día.

• Hay muchas actividades previas a la generación de la primer versión de un SRS

– El SRS no es el elemento central para hacer análisis • Más bien es un documento de referencia, enciclopédico.

LaFHIS - Uchitel

22

¿Qué es un Modelo? • Una descripción (de un problema o solución)... – – – –

precisa abstracta manipulable formalmente interpretable en el mundo real

• Una descripción cuyo fin es lograr mayor entendimiento • Una entidad que puedo – observar desde múltiples ángulos – Hacerle preguntas (y obtener respuestas)

23

LaFHIS - Uchitel

Unidad 3

El Documento de Requerimientos ¿De qué trata el Documento de Requerimientos? ¿Para qué sirve? ¿Qué diferencia tiene este documento con un modelo? ¿Qué técnicas de documentación pueden usarse? ¿Cuáles son sus limitaciones?

Lenguaje Natural • La técnica más popular • Ventajas

– No hay límite en cuanto a poder expresivo – No hay una barrera evidente de comunicación. – Ningún entrenamiento especial es necesario

• Limitaciones:

– Falta de estructura favorece ruido, referencias futuras, opacidad, definiciones incidentales, ... – Información específica puede ser difícil de encontrar – Ambigüedad : ”Frenado total será activado por cualquier tren que recibe un comando de aceleración o que entra al sector de estación a mas de X kmh y cuando el tren que lo precede está a menos de Y metros” – Análisis automatizado es imposible – Provee poco soporte metodológico 25

LaFHIS - Uchitel

Algunas Recomendaciones Generales • Existen muchas recomendaciones generales orientadas a mejorar la calidad de una especificación en lenguaje natural. Ejemplos: – – – – – –

Oraciones cortas No incluir en una oración mas de un requerimiento o presunción Evitar acrónimos Usar ecuaciones para relacionar información cuantitativa Usar ejemplos para clarificar aserciones abstractas Introducir un glosario/diccionario de datos para tener referencias e interpretaciones únicas y concisas, además de precisión técnica – Evitar combinaciones complejas de condiciones (ej. anidamiento y asociatividad ambigua) – Introducir figuras para proveer pantallazos – Ayudar texto con diagramas

• No proveen una forma rigurosa de atacar los problemas de fondo

LaFHIS - Uchitel

26

Lenguaje Natural Controlado • Restricciones gramaticales y de presentación que buscan forzar el uso de texto simple con el objeto de – aumentar entendibilidad – reducir ambigüedad – permitir algunos análisis simples de manera automática – reducir el uso inconsistente de términos

27

LaFHIS - Uchitel

Ejemplo: Indentación • El sistema proveerá información comparativa que es oportuna, itemizada en suficiente detalle como para que variaciones individuales de importancia no se pierdan entre otras variaciones, identificación de la fuente de cada variación sea posible, y sea identificable el área de investigación que maximizará los beneficios globales vs.

• El sistema proveerá información comparativa

– La información comparativa será oportuna, – La información comparativa será itemizada en suficiente detalle como para que • Variaciones individuales de importancia no se pierdan entre otras variaciones, • Identificación de la fuente de cada variación sea posible • Sea identificable el área de investigación que maximizará los beneficios globales

LaFHIS - Uchitel

28

Ejemplo: Estructura Gramatical • Especificación de requerimientos debe tener la siguiente estructura: – – – – –

Localización Actor Acción Objeto/Dueño Restricción.

• Ejemplo: Cuando tres o más seguidores de estrellas pierden su estrella de referencia, la nave inmediatamente alineará su eje principal con el eje soltierra salvo que la tapa de los instrumentos ópticos no se encuentre abierta 29

LaFHIS - Uchitel

Ejemplo: Templates/Plantillas • Cada aserción deberá ser estructurada con los siguientes campos: – – – – – – – – –

LaFHIS - Uchitel

Identificador Categoría Especificación Criterio de aceptación Fuente Justificación Interacción (positiva/negativa) con otras aserciones Prioridad ...

30

Tablas de Decisión “El sistema reportará al operador todas las fallas que se originan en funciones críticas o que ocurren durante la ejecución de una secuencia crítica y para las cuales no existen respuestas de recuperación de fallas.” (adaptado de la especificación de la base espacial internacional)

Origen en funcione crítica

F

T

F

T

F

T

F

T

Ocurre durante ejecución de secuencia crítica

F

F

T

T

F

F

T

T

No hay respuesta de recuperación de fallas

F

F

F

F

T

T

T

T

Reportar a Operador?

F

F

F

F

F

T

T

T

31

LaFHIS - Uchitel

Diagramas y Modelos Gráficos • Altamente estructurados • Permiten análisis automáticos superficiales – Eg. Reglas de consistencia sintáctica

• Facilitan comunicación aunque requieren distintos grados de capacitación previa • Proveen descripciones concisas y abstractas • Se complementan en cuanto a foco – – – – – – –

LaFHIS - Uchitel

Lógica de control Flujo de datos Flujo de control Estructura Estados y cambios de estado Comunicación ...

32

Diagramas: Árboles de Decisión Origen en funciones críticas F

T

Ocurre durante ejecución de secuencia crítica

F

No hay respuesta de recuperación de fallas

T

F

No hay respuesta de recuperación de fallas

No Reportar a Operador

F

T

No Reportar a Operador

Reportar a Operador

T

No Reportar a Operador

Reportar a Operador

33

LaFHIS - Uchitel

Diagramas: Flujo de Datos (DFDs) • Modelado de operaciones del sistema y sus dependencias de datos – Operaciones modifican datos. Sus inputs y outputs son declarados con flechas entrantes y salientes – Componentes son iniciadores o terminadores de flujos de datos

• Error común: Inferir control de flujo a partir del de datos Iniciador Pedido de reunión

Pedido inválido

Verificar pedido

Pedido válido

Consultar restricciones Pedido de restricciones Participante

LaFHIS - Uchitel

Fusionar restricciones

Copia de restricciones

Restricciones de participantes

Restricciones para la reunión

Fijar cronograma Notificación de reunión

Restricciones personales

Recolectar restricciones

Participante 34

Diagramas: SADT • “Structured Analysis and Design Technique” (Ross & Schoman, 1977) • Precursor en diagramas para requerimientos • Dos diagramas que son vistas duales/complementarias entre si

Actigram

Datagram

Datos de entrada

Datos y eventos de control Actividad

Componente responsable

Actividades productoras

Datos de salida

Actividades de control de integridad Datos

Recursos necesarios para procesamiento

Actividades consumidoras

35

LaFHIS - Uchitel

Ejemplo SADT Rango de fechas Pedido de reunión Rango de fechas Consultar restricciones

Pedido de reunión Scheduler

Gestionar de restricciones

plazo máximo Pedido de restricciones

Restricciones para reunión

Rango de fechas

Informar de restricciones

Participante

todas las restricciones recibidas

Fusionar de Restricciones restricciones personales

Restricciones para reunión

Scheduler Controlar validez Fusionar de restricciones Restricciones para reunión Planificar reunión Repositorio de restricciones LaFHIS - Uchitel

36

SADT: Algunas Observaciones • Diagramas semánticamente ricos (ej. más que DFDs) – Distingue responsables, dato, restricciones de integridad, etc...

• Criterios de consistencia inter-diagrams. – Ej. Una actividad del control de un datagrama debe aparecer como actividad en un actigrama

• Noción de refinamiento gráfico – Los datos de E/S de una actividad deben aparecer como E/S de alguna sub-actividad

• Diagramaticamente deficientes – Dirección absoluta de flechas (o posición absoluta de elementos) suele no tener relevancia semántica en diagramas modernos

37

LaFHIS - Uchitel

Diagrama de Contexto • Visto previamente...

pedido de restricciones Iniciador

notificación

Scheduler

notificación

Participante

restricciones personales pedido de reunión

LaFHIS - Uchitel

38

Diagramas Estructurales del Dominio • Ej. Diagramas de clase, modelos entidad relación • Conceptos: Entidades y Relaciones entre entidades (asociaciones, subclases, etc)

39

LaFHIS - Uchitel

Diagramas de Secuencia • Conceptos: – Tiempo, comunicación o interacción entre agentes – Descripción basada en ejemplos.

LaFHIS - Uchitel

40

Diagramas de Transición de Estados • Conceptos: Estados, Eventos, Guardas y Transiciones

[no autorizado] Recolectando Datos de Reunión

[autorizado] pedido KO

pedido de debilitar restricciones

Resolución de conflictos

[hay conflictos]

Pedido Denegado

Validando Datos de Reunión pedido OK Restricciones pedidas

Reunión notificada

[todas disponibles] notificación cronograma fijado Planificando Reunión planificada [no hay conflictos]

41

LaFHIS - Uchitel

Descripciones Gráficas: Limitaciones ¿Las descripciones gráficas que hemos visto, son adecuadas para describir requerimientos?

• No describen cual es el propósito. Se quedan en el “qué” y “cómo” • Requerimientos implícitos – Justificación de requerimientos implícita o inexistente – Relación entre requerimientos implícita

• Falta de distinción entre descripción y prescripción • Imposibilidad de representar múltiples opciones • Poca guía para el análisis y elaboración – ¿Criterios de verificación y validación? ¿Grado de completitud?

LaFHIS - Uchitel

42

Especificaciones Formales - Lógica de Primer Orden • Sintaxis – – – –

Operadores booleanos (disyunción, conjunción, negación, implicación) Variables tipadas Cuantificación universal y existencial sobre el universo de instancias Predicados booleanos y Funciones

• Ejemplo – !tr1, tr2: Tren: SigueA(tr1, tr2) -> Dist(tr1, tr2) < Dist-Frenado(tr1) – SigueA(tr1, tr2) " tr1.via() = tr2.via() && tr1.dirección = tr2.dirección – DistFrenado(tr) " ....tr1.velocidad()....tr1.peso()...., tr.modelo(), ....

• Semántica – Dado una valuación para elementos atómicos de la lógica, tenemos un mecanismo preciso para decidir si una fórmula es verdadera

• Técnicas de manipulación sintáctica que preserven la semántica – modus ponens, ecadenamiento, instanciación, ...

43

LaFHIS - Uchitel

Especificaciones Formales - Lógicas Temporales •

Sintaxis

•

Ejemplos

•

Semántica – Dado una secuencia de valuaciones para elementos atómicos de la lógica, tenemos un mecanismo preciso para decidir si una fórmula es verdadera

– [] P : siempre en el futuro vale P. – P : en algún momento en el futuro vale P. – P U Q : siempre en el futuro vale P hasta que valga Q. – X P : En el próximo estado vale P. – Presunción: “Una persona esperada a una reunión efectivamente participará de la reunión si la fecha y lugar de reunión le es conveniente y ha sido notificado de la reunión” ! p: persona, r: reunión: Esperado(p, r) && Notificado(r, m) && Conveniente(r, p) -> Participa(p, r) – Q vale después de que P valga pero antes de que R valga: [] !P || (P && !R U (Q || []!R)))

LaFHIS - Uchitel

44

Especificaciones Formales • Beneficios – Tienden a facilitar la reducción de problemas clásicos de especificación de requerimientos como • ambigüedad, ruido, referencias a futuro, aserciones no medibles

– Proveen mecanismos de análisis más sofisticados: Animación, verificación de correctitud vía deducción o exploración exhaustiva – Permiten la generación automática de contraejemplos, casos de falla, casos de prueba, modelos/vistas alternativas y fragmentos de código – El proceso de formalización puede ayudar a tener un mejor entendimiento informal del problema

• Desventajas – Tienen poder expresivo limitado. Ej. aspectos cuantitativos – Son difíciles de escribir y de leer. Obtención de especificaciones consistentes y adecuadas requiere mucho entrenamiento. Inaccesible para clientes, usuarios, etc. – Integración limitada de especificaciones con prácticas convencionales 45

LaFHIS - Uchitel

Lo que se viene... • Un modelo que trata de ... – resolver limitaciones y combinar beneficios de algunas de las técnicas de especificación mencionadas – estructurar conocimiento de una manera alternativa, para facilitar las actividades de Ingeniería de Requerimientos

• ... el modelo de objetivos

LaFHIS - Uchitel

46