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?

Unidad 3

LaFHIS - Uchitel 2

elicitacin y modelado

especificacin

stakeholders

documentos

sistemas

existentes

anlisis y validacin

Modelos de Requerimientos

Documento de

Requerimientos

negociacin y priorizacin

Documento de RequerimientosEn la prctica es comn describir los requerimientos en un documentollamado Especificacin de Requerimientos del Software (SRS -Software Requirements Specification)

LaFHIS - Uchitel 3

Para qu sirve un SRS?

Comunicar de manera precisa los requerimientos, objetivos ypresunciones del dominio

Contrato legal, documento interno o a modo de memorando

Base para estimacin (tamao, costo, tiempo) y planificacin deproyecto

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 4

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.

Analistas (de sistemas, de requerimientos), Escribirn especificaciones de otros sistemas que interactan con este. El SRS sirve mas all de la puesta en produccin!

Desarrolladores (ej. arquitectos, diseadores,programadores, ...) Deben implementar los requerimientos

Testers (V&Vers) Deben determinar la satisfaccin de los requerimientos

Gerentes Medir y controlar el proceso desarrollo

LaFHIS - Uchitel 5

Ms lectores de un SRS

Equipo de Operaciones Debern dimensionar equipos y procedimientos de rutina.

Equipo de soporte de usuario Desarrollo de plan de capacitacin Generacin de manuales de usuario Procedimientos de soporte online

Legales Los que firman los contratos

Subcontratistas Entes reguladores ...

Cmo se escribe un documento que le sirva a una audiencia tan variada?

LaFHIS - Uchitel 6

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 trabajoUn equipo de analistas modelan los requerimientos y luego los

documentan en un SRS de 500 paginas

LaFHIS - Uchitel 7

Adaptado de IEEE-STD-830

Contenido de un SRS

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 demssoftware?

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 8

1 IntroductionPurposeScopeDefinitions, acronyms,

abbreviationsReference documentsOverview

2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies

3 Specific RequirementsAppendicesIndex

Standard de IEEE para un SRS

1 IntroductionPurposeScopeDefinitions, acronyms,

abbreviationsReference documentsOverview

2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies

3 Specific RequirementsAppendicesIndex

Identifica el producto yel dominio de la aplicacin

Define el contenido y estructuradel resto del documento

Describe todas las interfaces externas:sistema, usuario, hardware, software

Resumen de funcionesprincipales

Cualquier cosa que limitar lasopciones del desarrollador (ej.regulaciones, limitaciones de

hardware, etc)

La parte principal del documento. IEEESTD provee 8 esqueletos diferentes

para esta seccin

Adaptado de IEEE-STD-830

LaFHIS - Uchitel 9

IEEE STD Seccin 3 (ejemplo)

3.1 External InterfaceRequirements

3.1.1 User Interfaces3.1.2 Hardware Interfaces3.1.3 Software Interfaces3.1.4 Communication Interfaces

3.2 Functional Requirementsthis 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 PerformanceRequirements

3.4 Design Constraints3.4.1 Standards compliance

3.4.2 Hardware limitations

etc.

3.5 Software SystemAttributes

3.5.1 Reliability3.5.2 Availability3.5.3 Security3.5.4 Maintainability3.5.5 Portability

3.6 Other Requirements

LaFHIS - Uchitel 10

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

Funcionalidad de alto nivel (top-down) ej. llamado en espera, desvo 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, tcnicos, admines, ... Modo de operacin

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

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

LaFHIS - Uchitel 11

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 delsoftware ha sido especificado para todos los inputs posibles.

con respecto a estructura: no hay secciones rotuladas: Acompletar...

LaFHIS - Uchitel 12

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 oimplementacin)

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 13

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 nopermiten interpretaciones distintas

No hay responsabilidades ambiguas: la separacin deresponsabilidades entre el mundo y el software debe estarindicado claramente.

Factibilidad Los objetivos y requerimientos deberan ser realizables

dentro del presupuesto y cronogramas dispuestos

LaFHIS - Uchitel 14

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 documentacin

futura (diseo, test, casos de test) Buena Estructura

tems definidos antes de ser usados, ndices, formateo, etc... Modificabilidad

Debe ser fcil de adaptar, extender, o achicar con modificacioneslocales.

Impacto de modificar un tem debera ser fcil de estimar

LaFHIS - Uchitel 15

Contraejemplos (1)

Omisin de objetivos y requerimientos faltantes No hay un requerimiento sobre estado de las puertas en caso

de emergencia Omisin de una reaccin a un input

Qu pasa si la alarma de emergencia es activada mientras laspuertas se cierran

Requerimientos inadecuados Si un libro no es devuelto a la semana del tercer aviso de

devolucin, el usuario negligente ser notificado y deberpagar 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 cuentacorriente del usuario.

LaFHIS - Uchitel 16

Contraejemplos (2)

Ruido Cada vagn estar equipado con un panel de informacin

controlado va software y con carteles de prohibido fumar encada 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 17

Contraejemplos (3)

Poca Modificabilidad Uso de literales para valores cuantificables.

Opacidad Un requerimiento como:

el comando de velocidad del tren deber ser siempre al menos12kph por encima de la velocidad real del trensin informacin contextual de por qu, la fuente y el impactosobre otros requerimientos.

No medibilidad Los paneles de informacin sern proveern informacin de

manera clara y precisa

LaFHIS - Uchitel 18

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.

los proveedores potenciales: 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.

el desarrollador seleccionado: refleja el entendimiento que tiene el desarrollador de las necesidades del

cliente. forma la base de una evaluacin contractual de la performance del

desarrollador. o por un con consultor independiente en IR.

LaFHIS - Uchitel 19

Una complicacin: Contratacin

Cundo licitar/contratar? Temprano (etapa conceptual)

slo se pueden evaluar las propuestas sobre la aparentecompetencia tcnica

Tarde (etapa de especificacin de requerimientosdetallados)

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

IEEE recomienda que el SRS sea desarrolladoconjuntamente por el contratante y el desarrollador

LaFHIS - Uchitel 20

Algunas Observaciones

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

Mejorar la especificacin tal vez no sea efectivo (costovs. beneficio) Anlisis de requerimientos tiene un costo Para diferentes proyectos, el costo-beneficio es diferente.

Anlisis reduce el riesgo de que las imperfeccionescausen problema serios.

Estas son muchas veces malas excusas para no invertiren Ingeniera de Requerimientos

LaFHIS - Uchitel 21

Resumen

Documento de Especificacin deRequerimientos 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 22

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 quelos resuelven, etc..

El SRS no es el nico soporte fsico a producir Tambin los modelos juegan un rol

El SRS no se comienza a escribir el primer da. Hay muchas actividades previas a la generacin de la primer

versin de un SRS El SRS no es el elemento central para hacer anlisis

Ms bien es un documento de referencia, enciclopdico.

LaFHIS - Uchitel 23

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 mayorentendimiento

Una entidad que puedo observar desde mltiples ngulos Hacerle preguntas (y obtener respuestas)

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?

Unidad 3

LaFHIS - Uchitel 25

Lenguaje Natural

La tcnica ms popular Ventajas

No hay lmite en cuanto a poder expresivo No hay una barrera evidente de comunicacin. Ningn entrenamiento especial es necesario

Limitaciones: 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 deestacin a mas de X kmh y cuando el tren que lo precede est amenos de Y metros

Anlisis automatizado es imposible Provee poco soporte metodolgico

LaFHIS - Uchitel 26

Algunas Recomendaciones Generales

Existen muchas recomendaciones generales orientadas a mejorarla 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 27

Lenguaje Natural Controlado

Restricciones gramaticales y de presentacinque buscan forzar el uso de texto simple con elobjeto de aumentar entendibilidad reducir ambigedad permitir algunos anlisis simples de manera

automtica reducir el uso inconsistente de trminos

LaFHIS - Uchitel 28

Ejemplo: Indentacin

El sistema proveer informacin comparativa que es oportuna,itemizada en suficiente detalle como para que variacionesindividuales de importancia no se pierdan entre otras variaciones,identificacin de la fuente de cada variacin sea posible, y seaidentificable el rea de investigacin que maximizar losbeneficios 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 29

Ejemplo: Estructura Gramatical

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

Ejemplo: Cuando tres o ms seguidores de estrellaspierden su estrella de referencia, la naveinmediatamente alinear su eje principal con el eje sol-tierra salvo que la tapa de los instrumentos pticos nose encuentre abierta

LaFHIS - Uchitel 30

Ejemplo: Templates/Plantillas

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

LaFHIS - Uchitel 31

Tablas de DecisinEl sistema reportar al operador todas las fallas que se originanen funciones crticas o que ocurren durante la ejecucin de unasecuencia crtica y para las cuales no existen respuestas derecuperacin de fallas.

(adaptado de la especificacin de la base espacial internacional)

TTTFFFFFReportar a Operador?TTTTFFFFNo hay respuesta de recuperacin de fallas

TTFFTTFFOcurre durante ejecucin de secuencia crtica

TFTFTFTFOrigen en funcione crtica

LaFHIS - Uchitel 32

Diagramas y Modelos Grficos

Altamente estructurados Permiten anlisis automticos superficiales

Eg. Reglas de consistencia sintctica 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 ...

LaFHIS - Uchitel 33

Diagramas: rboles de DecisinOrigen en funciones crticas

Ocurre durante ejecucin

de secuencia crtica

No hay respuesta de

recuperacin de fallas

F

TF

No Reportar

a Operador

No Reportar

a Operador

T

No hay respuesta de

recuperacin de fallas

Reportar a

Operador

F T

No Reportar

a Operador

Reportar a

Operador

F T

LaFHIS - Uchitel 34

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

Participante Participante

Verificar

pedido

Consultar

restricciones

Recolectar

restricciones

Fusionar

restricciones

Fijar

cronogramaRestricciones de

participantes

Pedido de

reunin

Copia de

restriccionesPedido

invlido

Pedido

vlido

Restricciones

para la reunin

Pedido de

restriccionesRestricciones

personales

Notificacin

de reunin

LaFHIS - Uchitel 35

Diagramas: SADT

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

Actividad

Datos de

entrada

Datos

de salidaComponente

responsable

Datos y eventos

de control

Datos

Actividades

productoras

Actividades

consumidorasRecursos necesarios

para procesamiento

Actividades de control

de integridad

Actigram Datagram

LaFHIS - Uchitel 36

Ejemplo SADT

Gestionar de

restricciones

Consultar

restricciones Informar de

restricciones

Fusionar de

restricciones

Pedido de reunin

Restricciones

para reunin

Rango de

fechas

Rango de

fechas

Pedido de

reunin

Scheduler

Pedido de

restricciones

ParticipanteRestricciones

personales

Scheduler

Restricciones

para reunin

plazo

mximotodas las

restricciones

recibidas

Rango de

fechas

Restricciones

para reunin

Fusionar de restricciones

Planificar reunin

Repositorio de restricciones

Controlar validez

LaFHIS - Uchitel 37

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 dealguna sub-actividad

Diagramaticamente deficientes Direccin absoluta de flechas (o posicin absoluta de elementos) suele

no tener relevancia semntica en diagramas modernos

LaFHIS - Uchitel 38

Iniciador Scheduler Participante

pedido de reunin

notificacin

pedido de restricciones

notificacin

restricciones personales

Diagrama de Contexto

Visto previamente...

LaFHIS - Uchitel 39

Diagramas Estructurales del Dominio

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

subclases, etc)

LaFHIS - Uchitel 40

Diagramas de Secuencia

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

LaFHIS - Uchitel 41

Diagramas de Transicin de Estados

Conceptos: Estados, Eventos, Guardas y Transiciones

Recolectando Datos

de Reunin

Pedido Denegado

Validando Datos

de Reunin

Restricciones

pedidas

Planificando Reunin planificada

Reunin notificada

Resolucin de

conflictos

[no autorizado]

[autorizado]

pedido OKpedido KO

[todas disponibles]

[hay

conflictos]

pedido de debilitar restricciones

[no hay

conflictos]

cronograma

fijado

notificacin

LaFHIS - Uchitel 42

Descripciones Grficas: Limitaciones

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?

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

LaFHIS - Uchitel 43

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 44

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.

Ejemplos 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 notificadode 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)))

Semntica Dado una secuencia de valuaciones para elementos atmicos de la

lgica, tenemos un mecanismo preciso para decidir si una frmula esverdadera

LaFHIS - Uchitel 45

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 mejorentendimiento 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. Inaccesiblepara clientes, usuarios, etc.

Integracin limitada de especificaciones con prcticas convencionales

LaFHIS - Uchitel 46

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