REQUISITOS DEL USUARIO

(captura de requisitos)
Anlisis y definicin de los requisitos
de una aplicacin informtica
I. Presentacin / Estndares de documentacin
Flujos de trabajo vs. Documentos
USDP vs. Clsica
IEEE vs. ESA
Documentos definidos en el estndar de la ESA
1
Flujos de trabajo vs. Documentos
Flujos de trabajo Documentos
USDP (RUP) Clsica IEEE ESA
Requisitos
Anlisis de
requisitos
Software
Requirements
Specification
(IEEE 830-1993)
User Requirements
Document
Anlisis
Software
Requirements
Document
Diseo
Diseo
arquitectnico
Software Design
Document
(IEEE 1016-1987)
Architectural Design
Document
Diseo detallado
Detailed Design
Document
2
+ Implementacin, Pruebas, Mantenimiento...
El Estndar de la ESA
GENERAL
European Space Agency software engineering standards
Guide to the software engineering standards
PRODUCTS
Guide to the user requirements definition phase
Guide to the software requirements definition phase
Guide to the software architectural design phase
Guide to the software detailed design and production phase
Guide to the software transfer phase
PROCEDURES
Guide to the software operations and maintenance phase
Guide to software project management
Guide to software configuration
Guide to software verification and validation
Guide to software quality assurance
ESA Lite
Guide to applying the ESA standards to small software projects
3
Los requisitos del usuario
4
Los requisitos de
los usuarios
incluyen
cuatrocientos
caractersticas
Te das cuenta
que ningn ser
humano sera
capaz de utilizar
un producto con
ese nivel de
complejidad?
Buen punto. Ser
mejor aadir
"fcil de usar" a
la lista.
Los requisitos del usuario en el Estndar ESA
ESA software engineering standards (PSS-05-0)
Chapter 2. The user requirements definition phase
2.3. Actividades: nociones importantes
Guide to applying the ESA SE-Std to projects using OO Methods
(BSSC98-1)
Chapter 3. Using Object-Oriented Methods with PSS-05
Guide to the user requirements definition phase (PSS-05-02)
Chapter 2. The user requirements definition phase
2.3. Determinacin del entorno operacional
2.4. Requisitos de capacidad / Requisitos de restriccin
2.7. Revisin de los requisitos del usuario
Chapter 5. The user requirements document
5.1. Introduccin: lo que debe ser, lo que no debe ser
5.3. Estilo: claridad, consistencia, modificabilidad
5.6. Contenido adaptado
5
Nociones importantes en el URD
Alcance del software: objetivo general que se persigue con la aplicacin.
Entorno operacional: contexto en el que debe operar el software.
Requisitos de capacidad: funciones y operaciones requeridas por los
usuarios para resolver un problema o alcanzar un objetivo; describe una
operacin, o secuencia de operaciones, que el software debe ser capaz de
realizar.
Requisitos de restriccin: restricciones impuestas por los usuarios sobre la
manera en que el problema es resuelto o el objetivo es alcanzado; restringe
la manera en que el software es construido o funciona, sin alterar o describir
las capacidades del software.
Atributos de cada requisito: identificador, descripcin, fuente (personas,
grupos, documentos...), necesidad (esencial, conveniente, opcional).
Importante: definir bien el alcance del software, el entorno operacional, los
tipos de usuarios, etc. (esto marca una diferencia importante con los
requisitos del software). 6
Los requisitos del software en el Estndar ESA
ESA software engineering standards (PSS-05-0)
Chapter 3. The software requirements definition phase
3.3. Actividades: modelo lgico; tipos de requisitos y propiedades
Guide to applying the ESA SE-Std to projects using OO Methods
(BSSC98-1)
Chapter 3. Using Object-Oriented Methods with PSS-05
3.4. Modelo lgico = modelo de requisitos + modelo de anlisis
Guide to the software requirements definition phase (PSS-05-03)
Chapter 2. The software requirements definition phase
2.3. Construccin del modelo lgico (rendimiento, riesgos, prototipado)
2.4. Tipos y propiedades de los requisitos del software
2.6. Revisin de los requisitos del software
Chapter 5. The software requirements document
5.1. Introduccin: lo que debe ser, lo que no debe ser
5.3. Estilo: claridad, consistencia, modificabilidad
5.6. Contenido adaptado
7
Nociones importantes en el SRD
Construccin del modelo lgico (PSS-05-0,
3.3.1; BSSC98-1, 3.4.1): modelo de lo que
necesita el usuario, independiente de la
implementacin.
8
II. Introduccin a la especificacin de requisitos
Qu es la especificacin de Requisitos
Comprender las necesidades del cliente y que el sistema
informtico debe satisfacer.
Proceso iterativo y cooperativo en el que se analiza el
problema
Se pueden distinguir dos fases en el proceso: Captura y
Anlisis.
Obtener los requisitos correctos es un proceso difcil.
Resultado del proceso: es el documento de
requisitos (productos o artefactos del proceso de
desarrollo de software. Otros artefactos son: modelos
de diseo, cdigo fuente, pruebas, manuales...).

9
Introduccin a la especificacin de requisitos
Se distinguen dos fases en el proceso:
Captura: interaccin cuidadosa con todos los
interesados en el sistema informtico; adquisicin de
informacin, requisitos en bruto.
Anlisis: estudio metdico de la informacin adquirida
y lograr comprender lo que debe hacer el sistema para
satisfacer las necesidades del cliente; expresar los
requisitos de forma concreta y detallada; formales,
refinados, estructurados, proceso eficazmente
gestionado, requisitos depurados.

10
Introduccin a la especificacin de requisitos
Tener los requisitos correctos es un proceso difcil:
Adivinar los deseos y necesidades que normalmente el cliente no es
capaz de describir ms que en forma confusa, incompleta y
desordenada.
Las necesidades se descubren, los requisitos se inventan; los
requisitos no estn ah esperando que alguien los descubra, sino
que son creados, construidos o inventados en un proceso
interactivo entre el cliente y el ingeniero.
La mayor parte de los errores en el software entregado tienen su
origen en el anlisis de requisitos, y pueden ser los ms difciles de
reparar.
El xito en el producto requiere colaboracin y comunicacin fluida
entre clientes y desarrolladores: cuanto ms completo y menos
ambiguo sean los requisitos, hay probabilidades de xito.
11
12
Un caso prctico
Agenda de compromisos: Necesito algo para organizar mejor mis actividades,
una agenda para llevar al da mi horario, mis compromisos, etc.
Cunto se tardara en desarrollar esta aplicacin? Esto lo realizo en una
semanita!
En el momento de la entrega de la agenda el cliente no queda satisfecho. Quiere
ms, quiere otra cosa. Colores, sonidos, funciones, copiar de un da a otro La
divertida semanita se convierte en una pesada carga. Hasta qu punto me he
comprometido?
Antes de entregarla, quiero probarla Qu pruebo? Qu porcentaje de
funcionalidad he alcanzado, cmo lo mido?
La ingeniera del software no trata de programar bien, sino de:
Cumplir plazos, presupuestos y expectativas.
Gestionar riesgos y recursos.
Transformar la produccin artesanal en industrial.
Termina el ciclo de vida del software a la entrega del producto? Grave error:
mantenimiento.
13
Necesidad de la especificacin de Requisitos
Para construir algo, antes hay que entender qu es ese algo.
La aplicacin funciona, pero no satisface las necesidades del cliente de qu sirve?
En general, los requisitos expresan qu debe hacer una aplicacin, sin decir cmo
debe hacerlo: expresan el punto de vista del cliente, que sabe lo que quiere (en el
mejor de los casos), pero no tiene por qu saber cmo conseguirlo:
A menudo el cliente ni siquiera sabe lo que quiere.
Tarea del analista es ayudar a que el cliente se exprese.
Ejemplo:
El sistema permitir al usuario consultar el saldo de su cuenta (s).
Los saldos de clientes se grabarn en una tabla Saldo en una base de datos MySQL (no).
Excepciones: puede ocurrir que usar Access sea un requisito:
Existen distintos niveles de abstraccin en requisitos, porque suelen provenir de distintas
fuentes (distintos interlocutores con distinto nivel de conocimientos tecnolgicos).
Ejemplo: el informtico de la empresa nos habla de los sistemas con los que deber
interactuar el nuestro, mientras que el jefe de contabilidad nos proporciona una mejor
visin sobre el conjunto de procesos del rea.
14
Por qu es necesario escribir los requisitos
Con demasiada frecuencia se ignora o se deja pasar.
Tarea descuidada en mucho tiempo: trivial, literaria, poco tecnolgica...
No quedan bien expresados en el cdigo fuente? No, no funciona.
Sin requisitos escritos, el equipo de desarrollo:
No sabe cul es su objetivo. No puede inspeccionar su trabajo.
No puede probarlo (y las pruebas s se consideran esenciales!).
No puede analizar su productividad. No puede reflexionar sobre sus prcticas.
No puede predecir el tamao y esfuerzo del siguiente trabajo.
No puede satisfacer a sus clientes.
En resumen, no hay ingeniera profesional sin requisitos escritos.
Cada uno de los requisitos debe ser...
Expresado con propiedad. Fcilmente accesible para todo el personal involucrado.
Numerado de forma unvoca. Acompaado por pruebas que lo verifiquen.
Tenido en cuenta en el diseo y el cdigo. Probado aisladamente y con otros requisitos.
Verificado por las pruebas al finalizar la construccin de la aplicacin.
Sin requisitos escritos sera imposible hacer todo esto.
15
16
Conclusiones: la adecuada gestin de los requisitos es el factor ms importante
de xito en un proyecto, por encima de las pruebas, el diseo, la
programacin...
Dos niveles en los requisitos
Del cliente o del sistema, del usuario o del software?
Sera ms correcto decir: requisitos del software para el cliente / para el desarrollador.
Primer nivel: requisitos del usuario (o del cliente):
Deseos y necesidades del cliente, expresados en lenguaje comprensible por l.
Audiencia primaria: cliente. Audiencia secundaria: desarrollador.
Segundo nivel: requisitos del software (o del sistema):
Forma estructurada y especfica, carcter mucho ms tcnico, modelos.
Audiencia primaria: desarrollador. Audiencia secundaria: cliente.
La finalidad es la misma. La distincin entre los dos niveles no es muy clara:
Forma: no estructurada / estructurada. Audiencia: cliente / desarrollador.
Contenido: mayor o menor nivel de detalle, precisin y formalidad.
Texto / Texto + Diagramas (modelos). Requisitos en bruto -> Requisitos depurados.
Distintas nomenclaturas y clasificaciones, misma idea de fondo:
Clsica/IEEE: Una nica fase: Anlisis de Requisitos. nico documento Especificacin de
Requisitos con los requisitos C y D.
USDP/ESA: Dos fases: Requisitos + Anlisis. Dos documentos: Requisitos del Usuario + Requisitos
del Software.
17
Dificultades de la especificacin de Requisitos
El precio pagado: un defecto en los requisitos es 20-50 veces ms caro de reparar si
se desliza en el resto del proceso de desarrollo.
La inversin es ms valiosa cuanto mayor sea el proyecto.
Si el beneficio es grande, por qu se omite el anlisis de requisitos?
Los clientes normalmente no tienen claro lo que quieren al principio, slo una idea
vaga, convirtiendo al anlisis de requisitos en una tarea ms difcil.
Solucin: sucesivas iteraciones Requisitos-Diseo-Implementacin.
Es una necesidad, no un lujo (voy despacio porque tengo prisa, no puedo
permitirme el lujo de gastar tan poco).
Muchas organizaciones no logran escribir los requisitos: (slo existen en las mentes
de los ingenieros). Otro peligro: la rotacin de personal. No es extrao que muchos
proyectos nunca terminen.
Un problema ms sutil: escribir slo la primera versin de requisitos, sin actualizar
en sucesivas iteraciones. Para actualizar el documento de requisitos es necesario
que est bien organizado. Gestin de requisitos cambiantes. Herramientas.
Escribir cdigo prematuramente es como echar cemento sin saber cmo va a ser el
puente. Documentar no es slo registrar decisiones, es pensar por escrito.
18
La especificacin de Requisitos en el contexto
del proyecto
Los requisitos tienen valor contractual, establecen los lmites de la
aplicacin.
Pueden estar sujetos a normas de confidencialidad y propiedad
intelectual.
Son la base para los estudios de viabilidad: merece la pena realizar
el proyecto?
La mejor comprensin de los requisitos facilita refinar las
estimaciones de esfuerzo necesario.
La obtencin de requisitos afecta a la planificacin del proyecto. El
proceso puede ser iterativo, pero con ciertos lmites: el cliente quiere
saber el coste antes de empezar, el desarrollador no quiere
comprometerse al menos hasta congelar los requisitos.
19