ANLISIS Y ESPECIFICACIN DE SISTEMAS SOFTWARE

3.2 Anlisis y especificacin de requisitos

Curso: 2013-2014

Indice
1. 2. 3. 4. 5. 6. 7. Ejemplo Flujo de trabajo Anlisis de requisitos Negociacin y validacin Especificacin de requisitos Documento de especificacin de requisitos Gestin de requisitos

Ejemplo
18.1.2 Guiado:
Cuando el piloto mueva la palanca hacia la derecha, el alern derecho se elevar adecuadamente y el alern izquierdo bajar adecuadamente. Igualmente, cuando el piloto mueva la palanca hacia la izquierda, el alern derecho bajar adecuadamente y el alern izquierdo se elevar adecuadamente.

Ejemplo: Refinado
18.1.2 Guiado 18.1.2.1 Direccin: Cuando el piloto mueva la palanca hacia la derecha, el alern derecho se elevar y el alern izquierdo bajar. Igualmente, cuando el piloto mueva la palanca hacia la izquierda, el alern derecho bajar y el alern izquierdo se elevar. 18.1.2.2 Graduacin: Movimientos incrementales de la palanca correspondern a movimientos incrementales de los alerones.

Ejemplo: Refinado
Resulta que hoy, gracias al software se puede proteger la integridad estructural del avin: 18.1.2.2 Graduacin: Movimientos incrementales de la palanca correspondern a movimientos incrementales de los alerones, sin superar nunca la integridad estructural del avin.

Ejemplo: Seguimos Refinando

18.1.2.2.1 Seguridad: Si el piloto mueve bruscamente la palanca, el avin ejecutar el mayor giro posible que no exceda la tolerancia estructural del avin. 18.1.2.2.1.1 El sistema monitorizar la velocidad del aire 18.1.2.2.1.2 El sistema monitorizar ... ... 18.1.2.2.1.n El sistema calcular el mayor ngulo posible compatible con las restricciones estructurales del avin.

Ejemplo: Ingeniero Jefe Boeing 777

El software no es el problema. Los requisitos son el problema... En otras ingenieras las leyes naturales limitan el crecimiento de los requisitos, pero el software no tiene esas leyes... Nuevos requisitos crecen como un tumor hasta que se pierde el control del proyecto

Flujo de trabajo
Enumerar requisitos candidatos Comprender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales

Enumerar los requisitos candidatos

Durante el ciclo de vida de un sistema aparecen muchas ideas que pueden convertirse en verdaderos requisitos Las ideas de clientes, usuarios, analistas y desarrolladores pueden mantenerse en una lista como un conjunto de requisitos candidatos Esta lista crece a medida que se aaden elementos y disminuye cuando algunas ideas se convierten en requisitos

Enumerar los requisitos candidatos

Cada caracterstica (idea) tiene un nombre corto y una breve explicacin o definicin Cada caracterstica (idea) tiene un conjunto de valores de planificacin:
Estado (propuesto, aprobado, incluido o validado) Coste estimado de implementacin (tipos de recursos y horas-persona) Prioridad (crtico, importante o secundario) Nivel de riesgo asociado a la implementacin (crtico, significativo u ordinario)

Comprender el contexto del sistema

Hay dos aproximaciones para entender el contexto del sistema:
Modelado del dominio Modelado del negocio

Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio y enlaza estos objetos unos con otros Los objetos del dominio representan las cosas que existen o los eventos que suceden en el entorno en que trabaja el sistema

Comprender el contexto del sistema

La identificacin y asignacin de un nombre para estos objetos ayuda a definir un glosario de trminos que permitirn una mejor comunicacin Muchos de los objetos del dominio o clases, pueden obtenerse de una especificacin de requisitos o mediante la entrevista con los expertos del dominio

Comprender el contexto del sistema

Las clases del dominio aparecen en 3 formas:
Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas y expedientes Objetos del mundo real y conceptos relacionados con estos, como cliente, historial de ventas, etc Sucesos que ocurrirn o han ocurrido, como la llegada de trenes, su salida, el plazo para pagar una factura, etc

El modelo del dominio se describe mediante diagramas de UML (especialmente mediante el diagrama de clases)

Comprender el contexto del sistema

El objetivo del modelo del dominio es comprender y describir las clases ms importantes dentro del contexto del sistema En dominios de negocio muy pequeos, no es necesario desarrollar un modelo de objetos para el dominio. En su lugar, puede ser suficiente un glosario de trminos El glosario y el modelo del dominio ayudan a los usuarios, clientes y desarrolladores y otros interesados a utilizar un vocabulario comn

Comprender el contexto del sistema

El objetivo del modelo del negocio es comprender los procesos de negocio de la organizacin Describe a grandes rasgos los procesos y entidades principales en torno al software El modelo del negocio especifica qu procesos de negocio soportar el sistema Suele utilizarse el diagrama de casos de uso Este modelo tambin establece las competencias requeridas en cada proceso: sus trabajadores, sus responsabilidades y las operaciones que llevan a cabo

Capturar requisitos funcionales

Se necesitan comprender las necesidades del usuario y del cliente Estas necesidades se pueden extraer a travs de entrevistas, cuestionarios, reuniones, etc Mediante los requisitos funcionales se establece qu debe hacer el sistema para satisfacer a todos los implicados La tcnica para identificar los requisitos del sistema se basa en los Casos de uso o historias de usuario

Capturar requisitos no funcionales

Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementacin, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad y fiabilidad La fiabilidad hace referencia a caractersticas como la disponibilidad, exactitud, tiempo medio entre fallos, defectos por miles de lneas de cdigo y defectos por clase

Capturar requisitos no funcionales

Un requisito de rendimiento impone condiciones sobre los requisitos funcionales como la velocidad, rendimiento, tiempo de respuesta y uso de memoria

Resumen
Trabajo a realizar Artefactos resultantes

Enumerar requisitos candidatos Comprender el contexto del sistema

Capturar los requisitos funcionales Capturar los requisitos no funcionales

Lista de caractersticas Modelo del dominio o del negocio

Modelo de casos de uso Requisitos adicionales o casos de uso concretos (para requisitos especficos de un caso de uso)

Para capturar los requisitos de forma eficaz es necesario disponer de un conjunto de tcnicas y artefactos que proporcionen una visin suficientemente buena del sistema

Anlisis de requisitos
En esta etapa se delimita el alcance del sistema
Se decide qu requisitos estn dentro o fuera del alcance del sistema

Una vez identificados los requisitos se puede construir una matriz de dependencia o de interaccin La matriz listar los requisitos en filas y columnas de forma ordenada para establecer las posibles dependencias

Anlisis de requisitos
Ejemplo de matriz de dependencia
Requisito R1 R2 R3 R4 Solapamiento Solapamiento Conflicto R1 R2 R3 R4

La parte de arriba de la matriz incluyendo la diagonal no se utiliza El resto de celdas indican si existe o no solapamiento entre requisitos, si estn en conflicto o son independientes (celdas vacas)

Anlisis de requisitos
Los requisitos en conflicto deben ser discutidos con los clientes y reformulados Los requisitos solapados deben ser reformulados para evitar el solapamiento La matriz de dependencia es una tcnica simple pero efectiva para encontrar conflictos y solapamientos cuando el nmero de requisitos es relativamente pequeo Cuando existe un gran nmero de requisitos, se puede continuar utilizando pero agrupando los requisitos por categoras

Anlisis: Clasificacin
Los requisitos se pueden clasificar siguiendo varios criterios:
Funcionales vs No Funcionales De producto vs de Proceso Prioridad Alcance Voltiles vs Estables

Anlisis: Modelado Conceptual

El objetivo del modelado conceptual es comprender el problema antes de comenzar el diseo de la solucin Los requisitos se transforman en modelos que permitan a los desarrolladores comprender el problema para disear la solucin Existen diferentes tcnicas de modelado:
DFDs Diagramas de interaccin de usuarios Modelos de Objetos y Datos

Negociacin y validacin
Los requisitos obtenidos a partir de las necesidades de los clientes pueden entrar en conflicto Algunos requisitos pueden ser ambiguos Otros pueden permanecer ocultos Por estas razones los requisitos deben ser negociados y validados antes de incorporarlos al documento de requisitos La negociacin y validacin de requisitos se realiza en paralelo al proceso de elicitacin

Negociacin y validacin
La negociacin de requisitos se basa en la realizacin de un borrador del documento de requisitos
Los requisitos listados en el borrador se negocian y modifican si es necesario Los requisitos innecesarios son eliminados Nuevos requisitos son aadidos

La validacin requiere de una versin ms completa de los requisitos

Los stakeholders leen el documento y convocan una reunin formal de revisin

Especificacin de requisitos
La especificacin conlleva a la realizacin de un documento Este documento puede ser revisado, evaluado y aprobado En proyectos que no incluyen slo software (sistemas informticos), se distinguen otros dos documentos previos:
Definicin del Sistema. Define los requisitos de los usuarios desde la perspectiva del dominio de aplicacin Especificacin de Requisitos del Sistema. Incluye los requisitos del sistema, de los cuales se pueden derivar los requisitos software

Especificacin de requisitos
Especificacin de requisitos software (ERS)
Software Requirements Specification (SRS)

Especificacin: Documento que define, de forma completa, precisa y verificable, los requisitos, el diseo, el comportamiento u otras caractersticas de un sistema o componente de un sistema Software: Conjunto de programas, procedimientos y documentacin asociada a la operacin de un sistema informtico

Especificacin de requisitos
Este documento es la base para el acuerdo entre clientes y desarrolladores sobre lo que har el producto
Es de gran ayuda para una evaluacin rigurosa de los requisitos antes del comienzo del diseo, reduciendo los esfuerzos posteriores de rediseo Suele estar escrito en lenguaje natural, acompaado de descripciones formales o semi-formales Las notaciones deben permitir describir los requisitos tan preciso como sea posible.

Especificacin de requisitos
Implicaciones:
Describir correctamente todos los requisitos del software No describir ningn detalle del diseo del software

Caractersticas de una buena ERS (IEEE 830):

No ambigua Completa Fcil de verificar Consistente Clasificada por orden de importancia o estabilidad Fcil de modificar Fcil de identificar el origen de cada requisito (traza) Fcil de utilizar durante las fases

Especificacin de requisitos
Caractersticas de una buena ERS (IEEE 830):
No ambigua
Un requisito ambiguo se presta a distintas interpretaciones Cada caracterstica del producto final debe ser descrita utilizando un trmino nico Si un trmino tiene distintos significados en distintos contextos se debe incluir un glosario

Completa:
Incluye todos los requisitos significativos del software Define la respuesta del software a todas las posibles clases de datos de entrada y en todas las posibles situaciones Est conforme con cualquier estndar de especificacin que se deba cumplir. Estn etiquetadas y referenciadas en el texto todas las figuras, tablas y diagramas.

Especificacin de requisitos
Caractersticas de una buena ERS (IEEE 830):
Fcil de Verificar
Existe algn procedimiento finito y efectivo en coste para que una persona o mquina compruebe que el SW satisface cada requisito

Consistente
Los Requisitos no entran en conflicto

Clasificada por orden de importancia o estabilidad

Facilita la gestin a los desarrolladores

Especificacin de requisitos
Caractersticas de una buena ERS (IEEE 830):
Fcil de Modificar
Cualquier cambio se puede realizar fcil, de forma completa y consistente Implica una organizacin coherente y manejable (Tabla de Contenidos, ndice y Referencias Cruzadas) Es fundamental que la ERS sea No Redundante

Facilidad de Traza (Trazabilidad)

Debe facilitar las referencias con otros productos del ciclo de vida Referencias hacia atrs Referencias hacia delante

Especificacin de requisitos
Destinatarios de la ERS:
Clientes. Para comprobar que satisface sus necesidades y para hacer cambios a los requisitos Gestores. Para planificar el proceso de desarrollo Ingenieros de Desarrollo. Para comprender el sistema a desarrollar Ingenieros de Pruebas. Para elaborar pruebas de validacin del sistema Ingenieros de Mantenimiento. Para facilitar la comprensin del sistema y las relaciones entre sus partes

Especificacin de requisitos
IEEE Std 830 (1998)
IEEE Recommended Practice for Software Requirements Specifications.
Disponible versin en espaol.

Establece una estructura recomendable para el documento ERS:

Introduccin Descripcin General Requisitos Especficos Apndices ndice

Documento de ERS
Estructura para la ERS:
1. Introduccin 1.1. Propsito 1.2. mbito 1.3. Definiciones, Siglas y Abreviaturas 1.4. Referencias 1.5. Visin Global 2. Descripcin general 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Caractersticas del usuario 2.4. Limitaciones generales 2.5. Supuestos y dependencias 2.6. Requisitos futuros 3. Requisitos especficos Apndices ndice
3. Requisitos especficos 3.1. Requisitos funcionales 3.1.1. Requisito funcional 1 3.1.1.1. Introduccin 3.1.1.2. Entradas 3.1.1.3. Procedimiento 3.1.1.4. Salidas 3.1.2. Requisito funcional 2 .................. 3.1.n. Requisito funcional n 3.2. Requisito de Interfaz externa 3.2.1. Interfaces de usuario 3.2.2. Interfaces hardware 3.2.3. Interfaces software 3.2.4. Interfaces de comunicaciones 3.3. Requisitos de ejecucin 3.4. Restricciones de diseo 3.4.1. Acatamiento de estndares 3.4.2. Limitaciones hardware 3.5. Atributos de calidad 3.5.1. Seguridad 3.5.2. Mantenimiento 3.6. Otros requisitos 3.6.1. Base de datos 3.6.2. Operaciones 3.6.3. Adaptacin de situacin

Documento de ERS
1. Introduccin:
1.1 Propsito:
Propsito del documento y a quin va dirigido

1.2 mbito
Se le da un nombre al futuro sistema. Qu hace y qu no hace el producto SW? Beneficios, objetivos y metas

1.3 Definiciones, siglas, y abreviaturas

En forma de apndices o referencias a otros documentos

1.4 Referencias
Lista completa de todas las referencias de los documentos en otra parte de la ERS

1.5 Visin Global

Descripcin de contenidos y cmo se organiza el resto de la ERS

Documento de ERS
2. Descripcin General:
2.1 Perspectiva del Producto
Relacin con otros Productos SW del Sistema
Interfaces Sistema; Usuario; HW; SW; Comunicaciones ..

2.2 Funciones del Producto

Resumen de las funciones principales (texto o grficos)

2.3 Caractersticas del Usuario

Tipo de usuarios al que est destinado el producto, experiencia tcnica, nivel de conocimientos

2.4 Restricciones Generales

Estndares, Limitaciones HW, Interfaces con otras aplicaciones

2.5 Asunciones y Dependencias

Factores que pueden afectar a los requisitos especificados

2.6 Requisitos Futuros

Documento de ERS
3. Requisitos Especficos: Contiene todos los requisitos software. Para cada requisito, se debe incluir:
Identificador nico Descripcin de cada entrada (el estmulo) en el sistema, Cada salida (la contestacin) del sistema, y Todas las funciones realizadas por el sistema en la salida a una entrada o en el apoyo de la salida.

Los requisitos se pueden organizar y ordenar de varias maneras (ver anexo A del estndar).

Documento de ERS
Requisitos Especficos: segn modo (anexo A)
3.1 Interfaces Externas
Descripcin detallada de las entradas y salidas del Sistema SW Complementa las descripciones de Interfaz de los apartados anteriores

3.2 Funciones (requisitos funcionales) 3.3 Requisitos de Rendimiento/Ejecucin

Estticos y Dinmicos

3.4 Restricciones de Diseo

Impuestas por otros estndares (formato informes; convenciones de nombrado elementos; etc..) Limitaciones del HW

3.5 Atributos de Calidad del Software

Fiabilidad, Disponibilidad, Mantenibilidad, Seguridad,

3.6 Otros Requisitos

Gestin de requisitos
Los requisitos deben ser gestionados La Gestin de Requisitos implica la recoleccin, almacenamiento y mantenimiento de grandes cantidades de informacin Existen herramientas CASE que facilitan la gestin de requisitos:
BBDD para almacenar requisitos Facilidades de anlisis y generacin de documentos Facilidades de gestin de cambios Facilidades de trazabilidad

Gestin de requisitos
La identificacin y clasificacin de requisitos es necesaria para poder gestionarlos de forma eficiente Los requisitos deben numerarse usando algn tipo de esquema Este esquema debe incluir una clasificacin de los requisitos en grupos ms manejables Existen diferentes tcnicas para la identificacin y clasificacin de requisitos

Gestin de requisitos
Tcnicas para clasificacin e identificacin:
Identificadores nicos. Numeracin secuencial asignada manualmente o por una herramienta CASE de forma automtica Numeracin segn una jerarqua. Numeracin asignada segn la posicin dentro del documento de requisitos. Por ejemplo, el sptimo requisito de la tercera seccin del segundo captulo: 2.3.7 Numeracin secuencial dentro de cada categora. Se asigna un identificador a la categora del requisito al que se le aade la numeracin correspondiente.

Gestin de requisitos
Los requisitos se pueden agrupar jerrquicamente Un requisito padre se compone de una serie de requisitos hijos Un requisito hijo es un sub-requisito de su padre Las relaciones jerrquicas introducen un nivel adicional a la clasificacin de requisitos La jerarqua de requisitos permite definir requisitos en diferentes niveles de abstraccin

Gestin de requisitos
Los requisitos cambian, pueden ser desestimados o pueden aparecer nuevos requisitos en cualquier etapa del ciclo de vida Cuanto ms avanzado est el desarrollo ms costar introducir un cambio en los requisitos La gestin de cambios involucra un rastreo de todos los requisitos relacionados Las herramientas CASE que permiten manejar diferentes versiones y rastrear los cambios efectuados en los requisitos son muy tiles en estos casos

Gestin de requisitos
La trazabilidad de los requisitos es una parte importante de la gestin de los cambios La trazabilidad implica mantener una serie de relaciones entre requisitos para rastrear los efectos de un cambio

Gestin de requisitos
Algunos requisitos cambian ms que otros Requisitos Estables
Esencia del Sistema y su Dominio de Aplicacin

Requisitos Voltiles
Especficos del Sistema en un entorno particular para un cliente particular Las causas del cambio son variadas:
Correccin de errores y problemas en los requisitos Conocimiento creciente del cliente/usuario Problemas tcnicos, de calendario o costes Cambio en las prioridades del cliente

Bibliografa
Requirements Analysis and System Design. Leszek A. Maciaszek Ingeniera del Software. Ian Sommerville. Sptima edicin Agile Software Requirements. Dean Leffingwell