Captura de requisitos.

Por qu es complicado
Capturar requisitos es muy complicado:
no haces sw para ti sino para otros
se supone que los otros saben EXACTAMENTE lo que
quieren
se supone que los otros te van a explicar perfectamente lo
que quieren
se supone que los otros hablan tu mismo idioma

El analista debe hablar el mismo idioma que el

usuario, lo cul implica:
conocer el modelo de negocio
tener cuidado a la hora de formalizar informacin

Cmo lo conseguimos (I)

Lista de requisitos candidatos
Para cada requisito:
Descripcin.
Estado -propuesto, aprobado, incorporado, validado Coste estimado para implantarlo -en trminos de recursos y
hora/persona Prioridad.
Nivel de riesgo.

 Comprender el contexto del sistema

describe los conceptos
importantes del contexto como objetos del dominio,
y los enlaza entre s.

Modelo de dominio:

en ocasiones puede ser necesario

conocer el proceso de negocio en el que estamos
involucrados -p.e. renta fija para la realizacin de
una aplicacin de tiempo real-

Modelo de negocio:

Este es el concepto clsico de consultor.

Cmo lo conseguimos (y II)

Capturar los requisitos funcionales
Aqu es donde modelamos nuestros casos de uso.

Capturar los requisitos no funcionales

Especificacin de propiedades del sistema -entorno,
restricciones de implementacin, prestaciones,
dependencias de plataforma, -

Tipos de Requisitos
Funcionales:
De Interfaz:

diferentes tareas del sistema futuro.

de usuario, entre mdulos SW,

uso futuro del sistema -backups,

recuperaciones, -

Operacionales:

De Documentacin.
De Seguridad:

proteccin, niveles de acceso, histricos,

De mantenibilidad y portabilidad.

 De recursos: limitaciones de memoria, discos,

De verificacin y fiabilidad: qu errores se pueden

producir, cules soporta,

De rendimiento.
De comportamiento.

Resultados
TRABAJ O A REALIZAR

ARTEFACTOS RESULTANTES

Listar requisitos candidatos

Lista de caractersticas

Comprender el contexto del

sistema

Modelo de negocio o de dominio

Capturar requisitos funcionales

Modelo de casos de uso

Capturar requisitos no
funcionales

Requisitos suplementarios o
casos de uso individuales

Actividades de Requisitos

Encontrar actores y casos de uso

Priorizar casos de uso

Detallar un caso de uso

Prototipado de interfaz de usuario

Estructurar el modelo de casos de uso

Actividad: Encontrar actores y casos

de uso (I)

Actividad realizada por el analista.

Encontrar actores
Habr tpicamente un actor por cada tipo de usuario del sistema y por cada sistema externo
que interactue con l.
Para cada actor, debe haber al menos un usuario real.

Encontrar casos de uso

Si no hay modelo de negocio (lo habitual), el analista identifica los casos de uso mediante
reuniones de trabajo con los actores.

Actividad: Encontrar actores y casos

de uso (II)

Describir brevemente cada caso de uso

Precondiciones, flujos alternativos, postcondiciones, etc.
El caso de uso ha de ser:

Correcto

No ambiguo

Verificable

Clasificable

Realista.

Actividad: Encontrar actores y casos

de uso (y III)

Describir el modelo de casos de uso global

El objetivo es explicar cmo se relacionan los casos de uso entre ellos y con los actores.
Si hay muchos casos de usos pueden agruparse en paquetes.
No se trata slo de listar casos de uso. Hay que identificar casos de uso contenidos en otros (y
probablemente compartidos en otros), generalizaciones y extensiones de caso de uso.
El modelo ha de ser:

Completo

Consistente

Actividad: Priorizar casos de uso

Actividad realizada por el arquitecto.

En las primeras iteraciones, los casos de uso relevantes para la arquitectura

tienen mayor prioridad.

En la priorizacin se tienen en tambin en cuenta aspectos econmicos, de

negocio, etc.

Actividad: Detallar un caso de uso

Actividad realizada por el especificador de casos de uso.

Datos por cada caso de uso:

Precondiciones

Postcondiciones

Secuencia de acciones:
Flujo bsico.
Flujos alternativos.

Describir exactamente qu hace el sistema y qu hacen los actores.

Los requerimientos no funcionales (eficiencia, etc.) se aaden en una seccin

aparte.

Actividad: Prototipado de interfaz de

usuario

Actividad realizada por el diseador de interfaz de usuario.

El objetivo es decidir la interfaz de usuario detalladamente para cada actor.

Esta actividad no va a ser generalmente requerida, aunque en proyectos

innovadores puede ser necesario.

Actividad: Estructurar el modelo de

casos de uso

Actividad realizada por el analista.

La idea es bsicamente :

Encontrar comportamientos comunes en diferentes casos de uso, de manera que

podamos agrupar ese comportamiento comn en un caso de uso reutilizado por otros
(caso de uso abstracto).

Encontrar casos de uso que son extensiones de otros casos de uso. Por ejemplo, si en
un caso de uso de una transferencia bancaria no hay fondos en la cuenta origen, se
inicia el caso de uso de reclamar a un moroso. Es decir un caso de uso B aparece
cuando en la ejecucin de un caso de uso A ocurren unas ciertas condiciones.

Ejemplo

Aplicacin de realizacin de Tests por ordenador

Cliente: Pblico

Objetivo: pruebas de comprobacin de prerrequisitos para las asignaturas.

Premisas:
El proyecto ha sido aceptado financieramente.
Se parte de una reunin informal con el cliente, a partir del cual hay que establecer la lista de
requisitos. Se supone que la lista bsica de requisitos ya existe.

A partir de la lista de requisitos, hay que construir el sistema software utilizando el

proceso unificado.

Tarea

Investigar

Ciclos de vida del software

Metodologa de desarrollo del software

Desarrollo interactivo e incremental.

Desarrollo gil

Indicar cual utilizaras y por que?