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 tcnicas de documentacin pueden usarse? Cules son sus limitaciones?

Documento de Requerimientos
En la prctica es comn describir los requerimientos en un documento llamado Especificacin de Requerimientos del Software (SRS Software Requirements Specification) Modelos de Requerimientos especificacin
stakeholders

elicitacin y modelado
Documento de Requerimientos

sistemas existentes

documentos

LaFHIS - Uchitel

anlisis y validacin

negociacin y priorizacin

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 estimacin (tamao, costo, tiempo) y planificacin de proyecto Base para evaluacin de producto final
verificacin y validacin Debera tener suficiente informacin para decidir si el producto final es aceptable (satisface los requerimientos)

Base para el control de cambios

Requerimientos cambian, software evoluciona, el entorno evoluciona

LaFHIS - Uchitel

Lectores de un SRS
Clientes y Usuarios
Interesados en validar objetivos del sistema y descripcin de alto nivel de la funcionalidad Generalmente no interesados en los requerimientos detallados del sistema. Escribirn especificaciones de otros sistemas que interactan con este. El SRS sirve mas all de la puesta en produccin!

Analistas (de sistemas, de requerimientos),

Desarrolladores (ej. arquitectos, diseadores, programadores, ...) Testers (V&Vers) Gerentes

Deben implementar los requerimientos Deben determinar la satisfaccin de los requerimientos Medir y controlar el proceso desarrollo

LaFHIS - Uchitel

Ms lectores de un SRS
Equipo de Operaciones
Debern dimensionar equipos y procedimientos de rutina.

Equipo de soporte de usuario

Legales

Desarrollo de plan de capacitacin Generacin de manuales de usuario Procedimientos de soporte online Los que firman los contratos

Subcontratistas Entes reguladores ...

Cmo 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 aos de trabajo

Un equipo de analistas modelan los requerimientos y luego los documentan en un SRS de 500 paginas

LaFHIS - Uchitel

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 dems hardware y con dems software? Atributos de Calidad.
Disponibilidad, tiempo de respuesta, tiempo de recuperacin despus de fallas, etc.. Consideraciones de portabilidad, correctitud, precisin, mantenibilidad, seguridad y mas...

Restricciones de diseo. Existen estndares a cumplir, lenguaje de programacin, recursos, sistemas operativos, etc...?

LaFHIS - Uchitel

Standard de IEEE para un SRS

Adaptado de IEEE-STD-830

1 Introduction

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

2 Overall Description

Purpose Scope Definitions, acronyms, abbreviations Reference documents Overview

3 Specific Requirements Appendices Index

LaFHIS - Uchitel

Product perspective Product functions User characteristics Constraints Assumptions and Dependencies

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 seccin
8

IEEE STD Seccin 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.3 Performance Requirements 3.4 Design Constraints

3.4.1 Standards compliance 3.4.2 Hardware limitations etc.

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.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.2.2 User Class 2

3.2.1.1 Functional Requirement 1.1

...
LaFHIS - Uchitel

3.6 Other Requirements

9

Ejemplos de Organizacin de Requerimientos Funcionales - Seccin 3.2. Estmulo o estado del mundo externo
ej. Soporte de aterrizaje de aviones: viento, poca nafta, pista corta,... ej. llamado en espera, desvo de llamado, llamado en conferencia, contestador... ej. generar recibos de sueldo, reportes de costo, estado de cuentas... ej. para una biblioteca, organizar por tipo de libro ej. Sistema de admin. de proyectos: gerente, tcnicos, admines, ... ej. un procesador de palabras: page layout, outline, normal, ... ej. Auto: control, manejo de datos, comunicaciones, entretenimientos, ...

Funcionalidad de alto nivel (top-down) Output del sistema Objeto externo Tipo de usuario

Modo de operacin Subsistema

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...

LaFHIS - Uchitel

11

Cualidades de un SRS (2)

Pertinencia
Cada requerimiento y presuncin se necesita para la satisfaccin de objetivo El SRS no contiene elementos que no estn relacionados con la definicin de requerimientos (ej. decisiones de diseo o implementacin)

Consistencia
No hay contradicciones en la formulacin de objetivos, requerimientos y presunciones

Medibilidad
Los requerimientos han sido formulados de manera tal que su satisfaccin pueda ser evaluada de manera no ambigua

LaFHIS - Uchitel

12

Cualidades de un SRS (3)

Precisin (No ambiguo)
No hay vocabulario ambiguo: cada trmino 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 separacin de responsabilidades entre el mundo y el software debe estar indicado claramente.

Factibilidad
Los objetivos y requerimientos deberan ser realizables dentro del presupuesto y cronogramas dispuestos

LaFHIS - Uchitel

13

Cualidades de un SRS (4)

Entendibilidad Trazabilidad
debe ser entendible por todos los lectores potenciales. debe identificar las fuentes de los objetivos, requerimientos, y presunciones debe relacionar requerimientos y presunciones con los objetivos debe facilitar referenciar de requerimientos en documentacin futura (diseo, test, casos de test) tems definidos antes de ser usados, ndices, formateo, etc... Debe ser fcil de adaptar, extender, o achicar con modificaciones locales. Impacto de modificar un tem debera ser fcil de estimar

Buena Estructura Modificabilidad

LaFHIS - Uchitel

14

Contraejemplos (1)
Omisin de objetivos y requerimientos faltantes Omisin de una reaccin a un input Requerimientos inadecuados
No hay un requerimiento sobre estado de las puertas en caso de emergencia Qu pasa si la alarma de emergencia es activada mientras las puertas se cierran Si un libro no es devuelto a la semana del tercer aviso de devolucin, 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 devolucin, x$ sern descontados a modo de multa de la cuenta corriente del usuario.

LaFHIS - Uchitel

15

Contraejemplos (2)
Ruido
Cada vagn estar equipado con un panel de informacin controlado va software y con carteles de prohibido fumar en cada ventana

Relleno
Contenido sin informacin relevante. Ej. contenido con el objeto de cumplir estndares.

Mala Estructura
Mezclar proceso de compra y prstamo de libros Referencias hacia adelante: Mltiples usos de participante para luego introducir la definicin de participante. Definiciones incidentales: El sistema enviar minutas a los participantes (aquellos que asistieron aunque sea parcialmente) de la reunin.
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 informacin contextual de por qu, la fuente y el impacto sobre otros requerimientos.

No medibilidad
Los paneles de informacin sern proveern informacin de manera clara y precisa

LaFHIS - Uchitel

17

Una complicacin: Contratacin

Un SRS puede ser escrito por...
el contratante:
el SRS sirve para llamar a licitacin Debe ser suficientemente general para lograr suficientes pliegos y suficientemente especfico para obviar pliegos no razonables. Representa una propuesta para implementar un sistema que satisfaga algn llamado a propuestas. Debe ser suficientemente especifico para demostrar factibilidad y competencia tcnica... pero suficientemente general para no comprometerse demasiado. refleja el entendimiento que tiene el desarrollador de las necesidades del cliente. forma la base de una evaluacin contractual de la performance del desarrollador.

los proveedores potenciales:

el desarrollador seleccionado:

o por un con consultor independiente en IR.

LaFHIS - Uchitel

18

Una complicacin: Contratacin

Cundo licitar/contratar?
Temprano (etapa conceptual)
slo se pueden evaluar las propuestas sobre la aparente competencia tcnica

Tarde (etapa de especificacin de requerimientos detallados)

mas trabajo para el contratante; experiencia en IR no necesariamente existe dentro de la organizacin

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

LaFHIS - Uchitel

19

Algunas Observaciones
El SRS ser imperfecto
contendr inconsistencias y imprecisiones omitir informacin, har simplificaciones

Mejorar la especificacin tal vez no sea efectivo (costo vs. beneficio)

Anlisis de requerimientos tiene un costo Para diferentes proyectos, el costo-beneficio es diferente.

Anlisis reduce el riesgo de que las imperfecciones causen problema serios. Estas son muchas veces malas excusas para no invertir en Ingeniera de Requerimientos
LaFHIS - Uchitel

20

Resumen
Documento de Especificacin de Requerimientos
Propsitos y audiencias Cualidades esperadas, errores y falencias Dificultades inherentes a la construccin de un SRS de calidad Concepciones errneas sobre el SRS Contratacin

LaFHIS - Uchitel

21

Una Observacin Importante

Siendo el SRS el entregable ms importante, suele tomar un protagonismo desproporcionado
El SRS no es el fin ltimo de un proceso de IR
Entendimiento del dominio de aplicacin, identificacin los problemas reales existentes, elaboracin los sistemas que los resuelven, etc.. Tambin los modelos juegan un rol

El SRS no es el nico soporte fsico a producir

El SRS no se comienza a escribir el primer da.

El SRS no es el elemento central para hacer anlisis

Ms bien es un documento de referencia, enciclopdico.
LaFHIS - Uchitel

Hay muchas actividades previas a la generacin de la primer versin de un SRS

22

Qu es un Modelo?
Una descripcin (de un problema o solucin)...
precisa abstracta manipulable formalmente interpretable en el mundo real

Una descripcin cuyo fin es lograr mayor entendimiento Una entidad que puedo
observar desde mltiples ngulos Hacerle preguntas (y obtener respuestas)

LaFHIS - Uchitel

23

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 tcnicas de documentacin pueden usarse? Cules son sus limitaciones?

Lenguaje Natural
La tcnica ms popular Ventajas

Limitaciones:

No hay lmite en cuanto a poder expresivo No hay una barrera evidente de comunicacin. Ningn entrenamiento especial es necesario Falta de estructura favorece ruido, referencias futuras, opacidad, definiciones incidentales, ... Informacin especfica puede ser difcil de encontrar Ambigedad : Frenado total ser activado por cualquier tren que recibe un comando de aceleracin o que entra al sector de estacin a mas de X kmh y cuando el tren que lo precede est a menos de Y metros Anlisis automatizado es imposible Provee poco soporte metodolgico
25

LaFHIS - Uchitel

Algunas Recomendaciones Generales

Existen muchas recomendaciones generales orientadas a mejorar la calidad de una especificacin en lenguaje natural. Ejemplos:
Oraciones cortas No incluir en una oracin mas de un requerimiento o presuncin Evitar acrnimos Usar ecuaciones para relacionar informacin cuantitativa Usar ejemplos para clarificar aserciones abstractas Introducir un glosario/diccionario de datos para tener referencias e interpretaciones nicas y concisas, adems de precisin tcnica 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 presentacin que buscan forzar el uso de texto simple con el objeto de
aumentar entendibilidad reducir ambigedad permitir algunos anlisis simples de manera automtica reducir el uso inconsistente de trminos

LaFHIS - Uchitel

27

Ejemplo: Indentacin
El sistema proveer informacin comparativa que es oportuna, itemizada en suficiente detalle como para que variaciones individuales de importancia no se pierdan entre otras variaciones, identificacin de la fuente de cada variacin sea posible, y sea identificable el rea de investigacin que maximizar los beneficios globales
vs.

El sistema proveer informacin comparativa

La informacin comparativa ser oportuna, La informacin comparativa ser itemizada en suficiente detalle como para que
Variaciones individuales de importancia no se pierdan entre otras variaciones, Identificacin de la fuente de cada variacin sea posible Sea identificable el rea de investigacin que maximizar los beneficios globales

LaFHIS - Uchitel

28

Ejemplo: Estructura Gramatical

Especificacin de requerimientos debe tener la siguiente estructura:
Localizacin Actor Accin Objeto/Dueo Restriccin.

Ejemplo: Cuando tres o ms 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
LaFHIS - Uchitel

29

Ejemplo: Templates/Plantillas
Cada asercin deber ser estructurada con los siguientes campos:
Identificador Categora Especificacin Criterio de aceptacin Fuente Justificacin Interaccin (positiva/negativa) con otras aserciones Prioridad ...

LaFHIS - Uchitel

30

Tablas de Decisin
El sistema reportar al operador todas las fallas que se originan en funciones crticas o que ocurren durante la ejecucin de una secuencia crtica y para las cuales no existen respuestas de recuperacin de fallas.
(adaptado de la especificacin de la base espacial internacional)

Origen en funcione crtica Ocurre durante ejecucin de secuencia crtica No hay respuesta de recuperacin de fallas Reportar a Operador?

F F F F

T F F F

F T F F

T T F F

F F T F

T F T T

F T T T

T T T T

LaFHIS - Uchitel

31

Diagramas y Modelos Grficos

Altamente estructurados Permiten anlisis automticos superficiales Facilitan comunicacin aunque requieren distintos grados de capacitacin previa Proveen descripciones concisas y abstractas Se complementan en cuanto a foco
Lgica de control Flujo de datos Flujo de control Estructura Estados y cambios de estado Comunicacin ... Eg. Reglas de consistencia sintctica

LaFHIS - Uchitel

32

Diagramas: rboles de Decisin

Origen en funciones crticas
F T

Ocurre durante ejecucin de secuencia crtica

No hay respuesta de recuperacin de fallas

F No Reportar a Operador

F No Reportar a Operador

T Reportar a Operador

No hay respuesta de recuperacin de fallas

F No Reportar a Operador

T Reportar a Operador

LaFHIS - Uchitel

33

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 comn: Inferir control de flujo a partir del de datos

Iniciador Pedido de reunin Pedido invlido Copia de restricciones Fusionar restricciones Restricciones para la reunin

Verificar pedido

Pedido vlido

Consultar restricciones Pedido de restricciones Participante

Restricciones de participantes

Fijar cronograma Notificacin de reunin

Restricciones personales

Recolectar restricciones

Participante
34

LaFHIS - Uchitel

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 Datos de entrada Datos y eventos de control Actividad Datos de salida

Datagram Actividades de control de integridad Datos

Actividades productoras

Componente responsable

Recursos necesarios para procesamiento

Actividades consumidoras

LaFHIS - Uchitel

35

Ejemplo SADT
Rango de fechas Pedido de reunin Rango de fechas Consultar restricciones Gestionar de restricciones Restricciones para reunin

plazo mximo Pedido de restricciones

Rango de fechas

Pedido de reunin Scheduler

Informar de restricciones

todas las restricciones recibidas

Participante

Fusionar de Restricciones restricciones personales

Restricciones para reunin

Scheduler Controlar validez Fusionar de restricciones Restricciones para reunin Planificar reunin Repositorio de restricciones
LaFHIS - Uchitel

36

SADT: Algunas Observaciones

Diagramas semnticamente ricos (ej. ms 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

Nocin de refinamiento grfico

Los datos de E/S de una actividad deben aparecer como E/S de alguna sub-actividad

Diagramaticamente deficientes
Direccin absoluta de flechas (o posicin absoluta de elementos) suele no tener relevancia semntica en diagramas modernos

LaFHIS - Uchitel

37

Diagrama de Contexto
Visto previamente...

pedido de restricciones Iniciador notificacin Scheduler notificacin Participante

restricciones personales pedido de reunin

LaFHIS - Uchitel

38

Diagramas Estructurales del Dominio

Ej. Diagramas de clase, modelos entidad relacin Conceptos: Entidades y Relaciones entre entidades (asociaciones, subclases, etc)

LaFHIS - Uchitel

39

Diagramas de Secuencia
Conceptos:
Tiempo, comunicacin o interaccin entre agentes Descripcin basada en ejemplos.

LaFHIS - Uchitel

40

Diagramas de Transicin de Estados

Conceptos: Estados, Eventos, Guardas y Transiciones

[no autorizado] Recolectando Datos de Reunin

Pedido Denegado

[autorizado] pedido KO

Validando Datos de Reunin pedido OK Restricciones pedidas Reunin notificada

pedido de debilitar restricciones

Resolucin de conflictos

[hay conflictos]

[todas disponibles] notificacin cronograma fijado Planificando Reunin planificada [no hay conflictos]

LaFHIS - Uchitel

41

Descripciones Grficas: Limitaciones

Las descripciones grficas que hemos visto, son adecuadas para describir requerimientos?

No describen cual es el propsito. Se quedan en el qu y cmo Requerimientos implcitos

Justificacin de requerimientos implcita o inexistente Relacin entre requerimientos implcita

Falta de distincin entre descripcin y prescripcin Imposibilidad de representar mltiples opciones Poca gua para el anlisis y elaboracin
Criterios de verificacin y validacin? Grado de completitud?

LaFHIS - Uchitel

42

Especificaciones Formales - Lgica de Primer Orden Sintaxis

Operadores booleanos (disyuncin, conjuncin, negacin, implicacin) Variables tipadas Cuantificacin 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.direccin = tr2.direccin DistFrenado(tr) " ....tr1.velocidad()....tr1.peso()...., tr.modelo(), ....

Semntica
Dado una valuacin para elementos atmicos de la lgica, tenemos un mecanismo preciso para decidir si una frmula es verdadera

Tcnicas de manipulacin sintctica que preserven la semntica

modus ponens, ecadenamiento, instanciacin, ...

LaFHIS - Uchitel

43

Especificaciones Formales - Lgicas Temporales Sintaxis

[] P : siempre en el futuro vale P. <> P : en algn momento en el futuro vale P. P U Q : siempre en el futuro vale P hasta que valga Q. X P : En el prximo estado vale P. Presuncin: Una persona esperada a una reunin efectivamente participar de la reunin si la fecha y lugar de reunin le es conveniente y ha sido notificado de la reunin ! p: persona, r: reunin: Esperado(p, r) && Notificado(r, m) && Conveniente(r, p) -> <> Participa(p, r) Q vale despus de que P valga pero antes de que R valga: [] !P || <>(P && !R U (Q || []!R)))

Ejemplos

Semntica Dado una secuencia de valuaciones para elementos atmicos de la lgica, tenemos un mecanismo preciso para decidir si una frmula es verdadera

LaFHIS - Uchitel

44

Especificaciones Formales
Beneficios
Tienden a facilitar la reduccin de problemas clsicos de especificacin de requerimientos como
ambigedad, ruido, referencias a futuro, aserciones no medibles

Proveen mecanismos de anlisis ms sofisticados: Animacin, verificacin de correctitud va deduccin o exploracin exhaustiva Permiten la generacin automtica de contraejemplos, casos de falla, casos de prueba, modelos/vistas alternativas y fragmentos de cdigo El proceso de formalizacin puede ayudar a tener un mejor entendimiento informal del problema

Desventajas
Tienen poder expresivo limitado. Ej. aspectos cuantitativos Son difciles de escribir y de leer. Obtencin de especificaciones consistentes y adecuadas requiere mucho entrenamiento. Inaccesible para clientes, usuarios, etc. Integracin limitada de especificaciones con prcticas convencionales
LaFHIS - Uchitel

45

Lo que se viene...
Un modelo que trata de ...
resolver limitaciones y combinar beneficios de algunas de las tcnicas de especificacin mencionadas estructurar conocimiento de una manera alternativa, para facilitar las actividades de Ingeniera de Requerimientos

... el modelo de objetivos

LaFHIS - Uchitel

46