You are on page 1of 25

ICI 542

INGENIERA DE SOFTWARE
Dr. Cristian Rusu
cristian.rusu@ucv.cl

5.1.7 El documento de
requerimientos del software
n
n

Documento oficial
Incluye los requerimientos del usuario y los
requerimientos del sistema:
n
n

a veces en la misma descripcin


si no, los requerimientos del usuario se definen en la
introduccin a los requerimientos del sistema

Los detalles de la especificacin del sistema se


pueden presentar como documentos separados
Utilizados tanto por los clientes del sistema como por
los desarrolladores

5.1.7 El documento de
requerimientos del software
Usuarios del documento de
requerimientos:
n
n
n
n
n

clientes del sistema


administradores
ingenieros software
probadores del sistema
mantenedores del sistema

5.1.7 El documento de
requerimientos del software
La especificacin de requerimientos es:
n

n
n
n

Correcta si representa la visin del


cliente/usuarios del sistema
Completa si describe todos los escenarios posibles
en el sistema, incluyendo el comportamiento
excepcional
Consistente si no se contradice a s misma
Clara si no genera distintas interpretaciones
Realista si el sistema puede implementarse segn
lo especificado

Es deseable que la especificacin sea


verificable!

5.1.7 El documento de
requerimientos del software
Estructura sugerida por IEEE:
1. Introduccin
1.1 Propsito del documento de requerimientos
1.2 Alcance del producto
1.3 Definiciones, acrnimos y abreviaturas
1.4 Referencias
1.5 Resumen del resto del documento

2. Descripcin general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Caractersticas del usuario
2.4 Restricciones generales
2.5 Suposiciones y dependencias

3. Requerimientos especficos
Es la parte ms sustancial del documento, que cubre los requerimientos funcionales y
no funcionales (del usuario y del sistema).

4. Anexos
5. ndice

5.2 Procesos de la ingeniera


de requerimientos
Actividades genricas en el proceso de
ingeniera de requerimientos:
n !Estudio de factibilidad!
n Obtencin y anlisis de requerimientos
n Especificacin y documentacin de
requerimientos
n Validacin de requerimientos

5.2 Procesos de la ingeniera


de requerimientos
Obtencin y
anlisis de

Estudio de
factibilidad

requerimientos

Informe de
factibilidad

Modelos
del sistema

Especificacin
de
requerimientos

Validacin de
requerimientos

Requerimientos
del usuario y
del sistema

Documento de
requerimientos

5.2.1 Obtencin y anlisis de


requerimientos
Los desarrolladores del sistema trabajan en
conjunto con los clientes y los usuarios
para determinar:
n
n
n
n

El rea de aplicacin
Los servicios que debe proveer el sistema
El desempeo requerido del sistema
Las restricciones hardware, etc.

5.2.1 Obtencin y anlisis de


requerimientos
Stakeholders = cualquier persona que
tiene influencia directa o indirecta sobre
los requerimientos del sistema:
n
n
n
n
n
n

Usuarios del sistema


Desarrolladores del sistema
Mantenedores de sistemas relacionados
Expertos en el rea de aplicacin
Administradores del negocio
Representantes de los trabajadores etc.

5.2.1 Obtencin y anlisis de


requerimientos
Dificultades en el proceso de obtencin y
anlisis de requerimientos:
n

Los stakeholders conocen en trminos generales lo


que desean obtener del sistema
Los ingenieros de requerimientos sin experiencia en
el dominio del cliente deben comprender su
requerimientos
Diferentes stakeholders tienen requerimientos
distintos (a veces divergentes)
Los factores polticos pueden intervenir el proceso,
para aumentar sus influencia en la organizacin
El entorno econmico y de negocios puede cambiar
durante el proceso de anlisis

5.2.1 Obtencin y anlisis de


requerimientos
Comprensin
del dominio

Recoleccin de
requerimientos

Clasificacin

Verificacin de
requerimientos

Priorizacin

Resolucin de
conflictos

Especifacin de
requerimientos

Documento de
requerimientos

5.2.1 Obtencin y anlisis de


requerimientos
Es un proceso iterativo, con retroalimentacin,
compuesto por:
n

n
n

Comprensin del dominio el analista desarrolla su propia


comprensin del dominio de la aplicacin
Recoleccin de requerimientos interaccin con los
stakeholders del sistema, para descubrir los requerimientos
Clasificacin organiza de manera coherente la coleccin no
estructurada de requerimientos
Resolucin de conflictos descubrir y resolver conflictos entre
los stakeholders involucrados en el proceso
Priorizacin organizar los requerimientos segn prioridad
Verificacin de requerimientos se verifica si los
requerimientos son completos, consistentes y acordes con las
necesidades de los stakeholders

5.2.1 Obtencin y anlisis de


requerimientos
Mtodos para la obtencin y anlisis de
requerimientos:
n
n
n
n
n

Obtencin orientada a puntos de vista


Escenarios
Etnografa
Anlisis estructurado
Construccin de prototipos

Combinacin de enfoques!

5.2.1 Obtencin y anlisis de


requerimientos
Obtencin orientada a puntos de vista:
n

Para sistemas de grande o mediano existen muchos


puntos de vista diferentes, que consideran el
problema de forma diferente (no completamente
diferente!)
Los diferentes puntos de vista se toman en cuenta
para estructurar y organizar el proceso de
obtencin y los requerimientos mismos
Ofrece un marco de trabajo para descubrir conflictos
en los requerimientos propuestos por diferentes

stakeholders

5.2.1 Obtencin y anlisis de


requerimientos
VORD (Vision Oriented Requirements
Definition), Kotonya y Sommerville (1996,1998),

Mtodo

marco de trabajo orientado a servicios:


n

Identificacin de puntos de vista identificar los servicios


especficos para cada punto de vista
Estructuracin de puntos de vista establecer una jerarqua de
servicios (los servicios comunes se ubican en los niveles altos)
Documentacin de puntos de vista refinar la descripcin de los
servicios y de los puntos de vista
Trazado del punto de vista del sistema identificar los objetos (en
enfoque de diseo orientado a objetos) utilizando la informacin
encapsulada en los puntos de vista

Debido a la gran cantidad de informacin que se genera, el


mtodo VORD es til en la prctica solo si se apoya en
herramientas CASE.

5.2.1 Obtencin y anlisis de


requerimientos
Escenarios:
n Los escenarios son descripciones de ejemplos
de las sesiones de interaccin de los usuarios
con el sistema
n Es ms fcil dar ejemplos de la vida real, que
descripciones abstractas
n Son especialmente tiles para agregar detalle
a un bosquejo de descripcin de
requerimientos
n Cada escenario cubre una o pocos posibles
interacciones

5.2.1 Obtencin y anlisis de


requerimientos
Un escenario incluye:
n

n
n
n
n

Descripcin del estado del sistema al inicio del


escenario
Descripcin del flujo normal de eventos en el escenario
Descripcin de lo que puede ir mal y cmo manejarlo
Informacin de actividades concurrentes
Descripcin del estado del sistema despus de
completar el escenario

5.2.1 Obtencin y anlisis de


requerimientos
Etnografa:
n Tcnica de observacin para entender los
requerimientos sociales y organizacionales
del sistema
n

El analista se sumerge en el entorno laboral donde el


sistema se utilizar, observa las tareas reales en las que
los participantes estn involucrados
La gente comprenden su propio trabajo, pero no su
relacin con las dems tareas en la organizacin
Los factores sociales y organizacionales son mucho ms
obvios para un observador imparcial

5.2.1 Obtencin y anlisis de


requerimientos
Etnografa:
n

Para tener xito, un sistema debe satisfacer


los requerimientos sociales y organizacionales
Los sistemas software no existen de forma
aislada
La etnografa no es un enfoque completo,
debe utilizarse en conjunto con otros enfoques

5.2.1 Obtencin y anlisis de


requerimientos
Obtencin de requerimientos orientada a
objetos:
n

Identificacin de los actores entidades externas


que interactan con el sistema
Identificacin de los escenarios descripcin de una
sola caracterstica del sistema, desde el punto de
vista de un solo actor
Identificacin de los casos de uso especifica todos
los escenarios posibles para una funcionalidad dada
Refinamiento de los casos de uso se refinan los
casos de uso descritos, algunos se eliminan, se
describen nuevos casos de uso

10

5.2.1 Obtencin y anlisis de


requerimientos
Obtencin de requerimientos orientada a
objetos:
n

Identificacin de las relaciones entre casos de uso


se reduce la redundancia entre casos de uso, se
separa el flujo comn de eventos del flujo
excepcional, se describe el sistema en capas de
funcionalidad
Identificacin de los objetos participantes se
obtiene un glosario de objetos
Identificacin de los requerimientos no funcionales
no estn relacionados en forma directa con el
comportamiento funcional del sistema

5.2.1 Obtencin y anlisis de


requerimientos
Anlisis de requerimientos orientado a objetos:
n

Identificacin de objetos de entidad examinando cada


caso de uso e identificando objetos candidatos
Identificacin de objetos de frontera la interfaz del
sistema con los
Identificacin de objetos de control responsables de la
coordinacin entre objetos de frontera y de entidad

11

5.2.1 Obtencin y anlisis de


requerimientos
Anlisis de requerimientos orientado a objetos:
n

n
n

Modelado de interacciones entre objetos diagramas de secuencia


(unen los casos de uso con los objetos, muestran como se
distribuye el comportamiento de un caso de uso entre los objetos
participantes)
Identificacin de asociaciones entre objetos describen la
conectividad espacial de los objetos
Identificacin de atributos de objetos propiedades de objetos
individuales
Modelado de comportamiento no trivial con grficas de estado
representan el comportamiento de objetos individuales
Modelado de relaciones de generalizacin elimina las redundancias
Revisin del modelo de anlisis el anlisis es un proceso iterativo

5.2.2 Validacin de
requerimientos
n

Los errores en el documento de requerimientos


pueden llevar a costos excesivos al repetir el trabajo
cuando sean descubiertos durante el desarrollo o
despus de la puesta en marcha del sistema
Los errores de requerimientos son mucho ms
costosos que los errores del diseo o de codificacin

Son necesarios varios tipos de


verificaciones del documento de
requerimientos!

12

5.2.2 Validacin de
requerimientos
Verificaciones en el documento de requerimientos:
n

Verificaciones de validez cualquier conjunto de requerimientos


es inevitablemente un compromiso entre las necesidades de
diversos usuarios
Verificaciones de consistencia no debe haber restricciones
contradictorias o diferentes de la misma funcin del sistema
Verificaciones de integridad deben ser definidos todas las
funciones y restricciones
Verificaciones de realismo los requerimientos deben verificarse
para asegurar que se pueden implementar
Verificabilidad los requerimientos del sistema deben redactarse
de tal forma que sean verificables

5.2.2 Validacin de
requerimientos
Tcnicas de validacin de requerimientos:
n

Revisiones de requerimientos los requerimientos son


analizados sistemticamente por un equipo de revisores, tanto del
cliente como del desarrollador
Construccin de prototipos se muestra un modelo ejecutable
del sistema a los usuarios finales; stos pueden revisar el prototipo
Generacin de casos de prueba si los requerimientos no se
pueden probar, generalmente sern difciles o imposible de
implementar y deberan ser reconsiderados
Anlisis de consistencia automtico si los requerimientos se
expresan en notacin estructurada/formal, las herramientas CASE
pueden verificar la consistencia del modelo

13

5.2.2 Validacin de
requerimientos
Pruebas de utilidad:
n

Examinan la comprensin de los usuarios sobre el


modelo de casos de uso
Encuentran problemas en la especificacin
permitiendo a los usuarios explorar el sistema (o
parte de l)
Se basan en experimentos que identifican
deficiencias que los desarrolladores corrigen en
forma iterativa
Tres tipos de prueba:
n
n
n

Prueba de escenario
Prueba de prototipo
Prueba de producto

5.2.3 Administracin de
requerimientos
Administracin de requerimientos el proceso de
comprender y controlar los cambios en los
requerimientos del sistema
Desde una perspectiva evolutiva:
n

Requerimientos duraderos relativamente estables se derivan

de la actividad principal de la organizacin, estn relacionados


directamente con el dominio del sistema
Requerimientos voltiles cambian durante el desarrollo del
sistema o despus de que se haya puesto en operacin:
n
Mutantes cambian debido a los cambios en el ambiente en el que
n
n
n

opera la organizacin
Emergentes emergen al incrementarse la compresin del cliente
Consecutivos son resultado del uso del sistema en la organizacin
De compatibilidad dependen de sistemas particulares dentro de la
organizacin y cambian cuando estos cambian

14

5.2.3 Administracin de
requerimientos
Evolucin de requerimientos
Comprensin
inicial del
problema

Requerimientos
iniciales

Cambio en la
comprensin
del problema

Requerimientos
cambiados

5.2.3 Administracin de
requerimientos
n

Se aplica a todos los cambios


propuestos en los requerimientos
Utilizando un proceso formal para
administrar los cambios:
n

Todos stos sern tratados de forma


consistente
Los cambios en el documento de
requerimientos se harn de forma
controlada

15

5.2.3 Administracin de
requerimientos
Existen tres etapas principales en el proceso de
administracin de cambio:
n Anlisis del problema y especificacin del cambio:
n
n

Anlisis del cambio y costeo:


n
n

Se evala el efecto del cambio


Se toma la decisin si se hace o no el cambio de requerimientos

Implementacin del cambio:


n

Se analiza si la propuesta de cambio es vlida


Si es as, se hace una propuesta especfica de cambio de
requerimientos

Se modifica el documento de requerimientos (si es necesario, el


diseo y/o la implementacin)

Es importante que el documento de requerimientos sea


modular, flexible!

5.2.3 Administracin de
requerimientos
Problema
identificado
Anlisis del
problema y
especificacin del
cambio

Anlisis y
costeo del
cambio

Implementacin
del cambio

Requerimientos
revisados

16

5.3 Prototipos de software


Prototipo = versin del sistema software que se
utiliza para comprobar conceptos, probar las
opciones de diseo y enterarse ms acerca del
problema y sus posibles soluciones
Incrementa los costos en las primeras
etapas del proceso software, pero baja
los costos en etapas posteriores!

5.3 Prototipos de software


n

n
n
n
n
n

Ayudan a establecer y validar los


requerimientos del sistema
Dan una percepcin mas completa de las
capacidades del sistema
Se pueden utilizar en el anlisis del riesgo
Mejoran la usabilidad del sistema
Mejoran la calidad del diseo
Mejoran el mantenimiento
Reducen el esfuerzo de desarrollo

17

5.3 Prototipos de software


Los prototipos ayuda a:
n

La obtencin de requerimientos permite adquirir


nuevas ideas, encontrar reas fuertes y dbiles del
software y proponer nuevos requerimientos
La validacin de requerimientos puede revelar
errores y omisiones de requerimientos
Capacitar el usuario antes de que el sistema final sea
entregado
Probar el sistema

5.3.1 Proceso de desarrollo


de prototipos
Para desarrollar un prototipo se usan las mismas tcnicas que para
desarrollar el sistema software mismo!
Establecer
objetivos del
prototipo

Definir
funcionalidad
del prototipo

Desarrollar
prototipo

Evaluar
prototipo

Plan de
construccin
del prototipo

Definicin
general

Prototipo
ejecutable

Informe de
evaluacin

Los objetivos deben ser claros y explcitos desde el inicio del proceso
de desarrollo del prototipo!
Un mismo prototipo no puede cumplir todos los objetivos!

18

5.3.1 Proceso de desarrollo


de prototipos

Prototipo
evolutivo
Requerimientos
generales
Prototipo
desechable

Sistema
entregado
Prototipo
ejecutable
+
Especificacin
del sistema

5.3.1 Proceso de desarrollo


de prototipos
Prototipos evolutivos:
n

Se comienza con un sistema relativamente


simple, que implementa los requerimientos
ms importante del usuario
El prototipo aumenta o cambia de acuerdo
con los nuevos requerimientos
Al final el prototipo se convierte en el sistema
mismo

19

5.3.1 Proceso de desarrollo


de prototipos
Prototipos evolutivos:
n

Se comienza con los requerimientos que se


comprenden mejor, de alta prioridad
Los requerimientos de baja prioridad se
implementan posteriormente
Evolucionan hacia el sistema final, por lo
tanto se deben desarrollar con los mismos
estndares de calidad como el sistema mismo
Deben ser robustos, fiables y eficientes

5.3.1 Proceso de desarrollo


de prototipos
Prototipos desechables:
n

Ayudan a refinar y clarificar la especificacin


del sistema
Despus de la evaluacin el prototipo se
descarta y se construye el sistema mismo
El proceso de anlisis de requerimiento se
extiende, pero se reducen los costos en
etapas posteriores del ciclo de vida

20

5.3.1 Proceso de desarrollo


de prototipos
Prototipos desechables:
n

Se comienza con los requerimientos que no


se comprenden bien, ya que se requiere
saber ms de ellos
Tienen un perodo de vida corto, no se
requiere darle mantenimiento a largo plazo
Se permite un desempeo pobre, de baja
fiabilidad

5.3.2 Construccin de
prototipos evolutivos
Problemas con la construccin de
prototipos evolutivos:
n Problemas de administracin los prototipos
evolucionan rpidamente
n Problemas de mantenimiento es difcil
encontrar personas especializadas
n Problemas contractuales el modelo
contractual normal se basa en la
especificacin del sistema, la cual
evoluciona

21

5.3.2 Construccin de
prototipos evolutivos
Desarrollar
especificacin
abstracta

Construir sistema
prototipo
&o
Utilizar sistema
prototipo

Sistema
apto?
Si
Entregar
sistema

5.3.3 Construccin de
prototipos desechables
Problemas con la construccin de prototipos
desechables:
n
n

Las caractersticas importantes se excluyen del prototipo


Una implementacin no tiene valor legal en el contrato
entre el cliente y el desarrollador
La implementacin no puede probar de manera
adecuada requerimientos no funcionales, como los de
fiabilidad, robustez y seguridad
El modo de utilizar el prototipo es distinto al uso del
sistema final

22

5.3.3 Construccin de
prototipos desechables
Requerimientos
generales

Desarrollar
prototipo

Evaluar
prototipo

Especificar
sistema

Desarrollar
software

Validar
sistema

Componentes
reutilizables

Entregar
sistema

5.4 Especificacin formal


Los mtodos formales de desarrollo incluyen:
n
n
n
n
n

Especificacin formal del sistema


Anlisis del sistema
Prueba de especificaciones
Desarrollo transformacional
Verificacin de programas

23

5.4 Especificacin formal


Los mtodos formales:
n
n

n
n

Complementan las tcnicas de especificacin informal


Se utilizan para refinar una especificacin informal de
requerimientos
Ayudan a llenar el hueco entre los requerimientos y
el diseo
Son precisas, no ambiguas
Eliminan los problemas de mala interpretacin

5.4 Especificacin formal


Las tcnicas matemticas son muy utilizadas en
otros disciplinas ingenieriles, pero
relativamente poco en ingeniera de software,
por varias razones:
n

El xito de mtodos alternativos en ingeniera de


software
Los mtodos formales no son apropiados para
especificar la interfaz usuario, que se ha
convertido en la parte esencial de los sistemas
software
Los mtodos formales tienen escalabilidad limitada

24

5.4 Especificacin formal


Los mtodos formales son tiles para:
n
n

Descubrir los errores de especificacin


Representar la especificacin del sistema de una
forma no ambigua

Se usan especialmente en el desarrollo de sistemas


crticos, en la cual las propiedades emergentes
(seguridad, fiabilidad, proteccin) son muy
importantes!

25