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?

Unidad 3

LaFHIS - Uchitel 2

elicitación y modelado

especificación

stakeholders

documentos

sistemas

existentes

análisis y validación

Modelos de Requerimientos

Documento de

Requerimientos

negociación y priorización

Documento de RequerimientosEn la práctica es común describir los requerimientos en un documentollamado Especificación 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 estimación (tamaño, costo, tiempo) y planificación deproyecto

• 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

LaFHIS - Uchitel 4

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 5

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?

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 años 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 demás hardware y con demássoftware?

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

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 aplicación

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 sección

Adaptado de IEEE-STD-830

LaFHIS - Uchitel 9

IEEE STD Sección 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 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 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 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 oimplementació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 13

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

– No hay responsabilidades ambiguas: la separación deresponsabilidades entre el mundo y el software debe estarindicado claramente.

• Factibilidad– Los objetivos y requerimientos deberían 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 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 modificacioneslocales.

– Impacto de modificar un ítem debería ser fácil de estimar

LaFHIS - Uchitel 15

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 laspuertas 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 cuentacorriente del usuario.”

LaFHIS - Uchitel 16

Contraejemplos (2)

• Ruido– “Cada vagón estará equipado con un panel de información

controlado vía software y con carteles de prohibido fumar encada 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 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 tren”sin información contextual de por qué, la fuente y el impactosobre otros requerimientos.

• No medibilidad– Los paneles de información serán proveerán información de

manera clara y precisa

LaFHIS - Uchitel 18

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 19

Una complicación: Contratación

• ¿Cuándo licitar/contratar?– Temprano (etapa conceptual)

• sólo se pueden evaluar las propuestas sobre la aparentecompetencia técnica

– Tarde (etapa de especificación de requerimientosdetallados)

• mas trabajo para el contratante; experiencia en IR nonecesariamente existe dentro de la organización

– 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á información, hará simplificaciones

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

• Análisis reduce el riesgo de que las imperfeccionescausen problema serios.

• Estas son muchas veces malas excusas para no invertiren Ingeniería de Requerimientos