Ing. Miguel Torres M.Sc. Ingeniería de Requerimientos

Ing. Miguel Torres M.Sc.
Ingeniería de
Requerimientos
"The Roman bridges of antiquity were very
inefficient structures. By modern standards,
they used too much stone, and as a result, far
too much labor to build. Over the years we
have learned to build bridges more efficiently,
using fewer materials and less labor to
perform the same task.“
Tom Clancy (The Sum of All Fears)
Outline
• Panorama general
• Requerimientos
• Una buena especificación de
Requerimientos
• Ingeniería de Requerimientos
• Buenas prácticas y documentos útiles
En La Actualidad
El Proyecto Chaos
The Standish Group 1995
For purposes of the study, projects were classified into three resolution types:
•
•
•
Resolution Type 1, or project success: The project is completed ontime and on-budget, with all features and functions as initially specified.
Resolution Type 2, or project challenged: The project is completed
and operational but over-budget, over the time estimate, and offers fewer
features and functions than originally specified.
Resolution Type 3, or project impaired: The project is cancelled at
some point during the development cycle.
Overall, the success rate was only 16.2%, while challenged projects
accounted for 52.7%, and impaired (cancelled) for 31.1%.
Factores Según el Proyecto Chaos
Project Success Factors
Project Challenged Factors
1. User Involvement 15.9%
2. Executive Management Support
13.9%
3. Clear Statement of Requirements
13.0%
4. Proper Planning 9.6%
5. Realistic Expectations 8.2%
6. Smaller Project Milestones 7.7%
7. Competent Staff 7.2%
8. Ownership 5.3%
9. Clear Vision & Objectives 2.9%
10. Hard-Working, Focused Staff 2.4%
Other 13.9%
1. Lack of User Input 12.8%
2. Incomplete Requirements &
Specifications 12.3%
3. Changing Requirements &
Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%
Factores (cont.)
Project Impaired Factors
1. Incomplete Requirements 13.1%
2. Lack of User Involvement 12.4%
3. Lack of Resources 10.6%
4. Unrealistic Expectations 9.9%
5. Lack of Executive Support 9.3%
6. Changing Requirements & Specifications 8.7%
7. Lack of Planning 8.1%
8. Didn't Need It Any Longer 7.5%
9. Lack of IT Management 6.2%
10. Technology Illiteracy 4.3%
Other 9.9%
Dispersión del Error
En otras palabras …
You folks start coding.
I will go to the client and find out what the
requirements are.
¿Cuál Es La Solución?
“Los requerimientos son una especificación de lo
que
debe
ser
implementado.
Estos
son
descripciones de cómo el sistema se debe
comportar, de las propiedades y atributos del
mismo. Deben ser una restricción del proceso de
desarrollo del sistema” 1
Debemos conocer por qué es necesario el sistema !
También deben indicar qué NO hace el sistema!
Son la base para todo el trabajo de desarrollo
posterior!
1
Sommerville and Sawyer 1997

Importancia de los
Requiremientos
Discusión Ingeniería


Discusión Economía


Los defectos son más baratos de remover si se encuentran
en etapas tempranas.
Discusión Empírica


Una buena solución sólo puede ser desarrollada si el
ingeniero tiene un profundo conocimiento del problema.
La inhabilidad de entender y gestionar los requerimientos
son la causa mas frecuente en sobrecostos (tiempo y
recurso).
Discusión Safety

Errores de Safety surgen de requerimientos inadecuados o
malinterpretados.
……
 07/26/09
11
Niveles De Descripción De Los
Requerimientos
 Requerimientos de Negocio: Representan a gran nivel los
objetivos de la organización y/o las solicitudes del cliente con
respecto al sistema o producto.
 Requerimientos de Usuarios: Describen las tareas de los
usuarios que deben poder ser realizadas con el producto.
 Requerimientos del Sistema: Definen la funcionalidad del
software que los desarrolladores deben construir dentro del
producto para permitir al usuario realizar sus tareas y satisfacer
los Requerimientos del Negocio.
Business vs. System
Tipos De Requerimientos de Sistema
 Software
 Requerimientos Funcionales: Define que hace el sistema
(describen entradas y salidas), es decir, las funciones del
sistema.
 Requerimientos No Funcionales: Definen los atributos que
le indican al sistema como realizar su trabajo (eficiencia,
hardware, software, interfaces, usabilidad, etc.). Es el como,
cuando y cuanto del que.
 Hardware
 Restricciones: tipo de máquina, Desempeño, tiempo,
carga, Proceso de pruebas, Interface, Lugar donde se debe
realizar la implementación, etc.
HW vs. SW
Niveles De Descripción De Los
Requerimientos
Algunos Atributos – Req. SW
Ejemplo
Debido a una falla mecánica un piloto de helicóptero no puede
determinar su posición actual. El piloto toma un cartel que
dice “¿Donde Estoy?” y lo pone en la ventana de su
helicóptero y lo muestra a unas personas que se
encuentran en la parte alta de un edificio, ellos le muestran
a su vez un letrero inmenso que dice “Ud. Está en un
Helicóptero”. ¿Cuál es el tipo de problema asociado al
último cartel?
–
–
–
–
Req.
Req.
Req.
Req.
No Funcionales del Sistema
Funcionales del Sistema
Del Negocio
De Usuario
Características De Un Buen Requerimiento
Factible
Características De Una Buena
Especificación De Requerimientos
Una Buena Especificación de
Requerimientos de ser:
•
•
•
•
•
Completa
Consistente
Modificable.
Trazable - Fácil de Seguir
etc.!
Complete
• No requirements or necessary
information should be absent.
• Missing requirements are hard to
spot because they aren't there!
• Focusing on user tasks, rather than
on system functions, can help you to
prevent incompleteness.
Consistent
• Consistent requirements don't conflict with other
requirements of the same type or with higherlevel business, system, or user requirements.
• Disagreements between requirements must be
resolved before development can proceed.
• You might not know which single requirement (if
any) is correct until you do some research.
• Recording the originator of each requirement lets
you know who to talk to if you discover conflicts.
Modifiable
• You must be able to revise the SRS when necessary and to
maintain a history of changes made to each requirement.
• Each requirement must be uniquely labeled and expressed
separately from other requirements so that you can refer to it
unambiguously.
• Each requirement should appear only once in the SRS.
• It's easy to generate inconsistencies by changing only one
instance of a duplicated requirement.
• Consider cross-referencing subsequent instances back to the
original statement instead of duplicating the requirement.
• A table of contents and an index will make the SRS easier to
modify.
• Storing requirements in a database or a commercial requirements
management tool makes them into reusable objects.
Traceable
• A traceable requirement can be linked backward
to its origin and forward to the design
elements and source code that implement it
and to the test cases that verify the
implementation as correct.
• Traceable requirements are uniquely labeled
with persistent identifiers.
Trazabilidad
What for?
•
•
•
•
•
•
To show what results stakeholders
want
To give stakeholders a chance to
say what they want
To represent different viewpoints
To check the design
To measure progress
To accept products against precise
criteria
Requirements, then, are used for
many different reasons by
different people. For example:
• users say and get what they want;
• systems engineers can be sure
they are solving the right
problems;
• test engineers know what to test;
• managers have more confidence
that the project is on track.
Quienes?
RA Role
Work collaboratively with customers,
users, and system architects and
designers to identify the real
requirements.
Work effectively with customers and users
to manage new and changed
requirements so that the project stays
under control. Install a mechanism to
control changes.
Be alert to new technologies that may
help.
Facilitate the project in reusing artifacts
and achieving repeatability.
Assist the project and its customers in
envisioning a growth path from the
first release or version of a product
through a set of staged releases to the
“ultimate system or products.”
Advise the project (and customer) of
methods, techniques, and automated
tools that are available to best support
requirements-related project work and
activities.
Use metrics to measure, track, and control
requirements- related project work
activities and results.
Be able to facilitate discussions and to
mediate conflicts.
Study the domain of the area in which the
system or software is being used.
El Proceso
Ingeniería De Requerimientos
• Ciencia y disciplina que se preocupa por encontrar,
establecer y documentar los requerimientos de Software.
• Requirements Engineering is the branch of systems
engineering concerned with real-world goals for, services
provided by, and constraints on software systems.
• Requirements Engineering is also concerned with the
relationship of these factors to precise specifications of
system behavior and to their evolution over time and across
system families.
Ingeniería De Requerimientos
Recolección
Análisis y
Negociaciones
Necesidades de Usuario
Dominio de la Información
Información Existente
Regulaciones
Restricciones
Estándares
Documentación
Documento de
Requerimientos
Documento del Sistema
Validación
Requerimientos
Pactados
Variabilidad del Proceso
• El proceso de IR varia de una organización
a otra
• Factores
–
–
–
–
Madurez técnica
Cultura Organizacional
Dominio de la Aplicación
…
• Por tanto no hay un proceso ideal de IR
Las Actividades - Técnicas
Recolección de
Requerimientos:
• Entrevistas
• Casos de Uso y/o
Escenarios
• Peeling the Onion
• Observación y Análisis
Social
• Lluvia de Ideas
• Prototipos
Análisis de
Requerimientos:
• Sesiones JAD
• Priorización de
Requerimientos
• Modelos
• Análisis de Riesgos
y Costos
• Análisis de Textos
Las Actividades - Técnicas
Especificación de
Requerimientos:
• Especificación
Asistida
• Manejo de Plantillas
• Especificación Formal
• Meta Lenguajes
Validación de
Requerimientos:
• Validación de
Modelos
• Pruebas de
Aceptación
• Prototipos
• Inspección de la
Especificación
Escribiendo Requerimientos
• Los REQUERIMIENTOS están
orientados al objetivo.
– Objetivo: Un único resultado deseado
Escribir los pasos básicos
• Escenarios. Cada paso puede ser en
efecto un requerimiento y un
subobjetivo
Anatomía de un buen requerimiento
Cada REQUERIMIENTO DE USUARIO debe tener:
• Tipo de usuario que se beneficiara.
• Estado deseado que se desea alcanzar, usualmente
un Objetivo (entidad) con un calificador;
• Mecanismo que permita que se pueda escribir una
prueba del requerimiento.
Ejemplo
• Tipo de Usuario: El Operador Telefónico…
• Tipo de Resultado (Verbo): ... Debe poder observar...
• Objeto: ... detalles de una casa protegida ...
• Calificador : ... Dentro de los primeros 5 segundos en
que realizo la solicitud de consulta.
Plantilla ejemplo
Ejemplo
Mal
Bien
El sistema será lo más fácil de
utilizar posible.
Un usuario experimentado debe
ser capaz de utilizar todas las
funciones del sistema tras un
entrenamiento de 2 horas, tras
el cual no cometerá más de 3
errores diarios en media.
El sistema proporcionará una
respuesta rápida al usuario.
Cuando haya hasta 100
usuarios accediendo
simultáneamente al sistema, su
tiempo de respuesta no será en
ningún momento superior a 2
segundos.
El sistema se recuperará
automáticamente tras producirse
un fallo.
Ante un fallo en el software del
sistema, no se tardará más de 5
minutos en restaurar los datos
del sistema (en un estado válido)
y volver a poner en marcha el
sistema.
Problemas y soluciones al
Estructurar Requerimientos
Problemas y soluciones al
Estructurar Requerimientos
(Cont.)
SI
• Use Frase simples y directas
• Use un vocabulario limitado
• Identifique el tipo de usuario
• Enfóquese en los resultados
• Defina criterios verificables enmarcados en un
criterio de aceptación.
NO
• Evite la ambigüedad
“El mismo subsistema debe poder generar una señal de
alerta/precaución visible o audible para el copiloto o el
navegante."
Cuál subsistema? Es la señal visible o audible o las dos? Es
alerta o precaución o las dos? Es solo para el copiloto o
el navegante o los dos? Si es solo para uno de ellos, cuál
y bajo que condiciones?
• No escriba múltiples requerimientos en uno (y, o
, con, además)
• No diseñe el sistema – No mezcle requerimientos
y diseño
No (cont.)
• No mezcle requerimientos y planes
• No especule, no hay espacio para
deseos
• No exprese posibilidades (podría,
puede, debería…)
Requerimientos son
planeados
Un plan de requerimientos define:
• Como evolucionarán los
requerimientos, y como se ejecutarán
las actividades relacionadas con ellos.
• Facilita la comprensión de las
actividades y esfuerzos.
Plan
•
•
•
•
•
•
•
Propósito del Plan
Contrato / Resumen del Proyecto
Trasfondo
Evolución
Roles y responsabilidades del personal
Definición del Proceso
Mecanismos, métodos, técnicas y
herramientas
• Bibliografía (interna o externa)
• Apéndices
Estructura de un SRS
Ejercicios
Identificando Requerimientos
El siguiente texto corresponde aun definición dada por un
usuario
(a) El Proyecto es para un base de datos que almacenará
información histórica del desempeño de los proyectos
que se realizan en la empresa, (b) permitirá a los
usuarios consultar cual era el cronograma original
propuesto y (c) compararlo con los planes proyectados
actuales, (d) El sistema será fácil de usar para todos los
gerentes, y (e) será accesible desde todas las estaciones
de trabajo de la organización, (f) Será implementado en
Oracle, y (g) debe presentar un nivel de desempeño
aceptable a lo largo de toda la organización.
(h) El sistema producirá un reporte de estado de todos los
proyectos de manera mensual para la alta Gerencia.
(i) La pantalla mostrara gráficos de comportamiento del
estado actual contra el planeado así como predicciones
de cumplimiento, y (j) la fecha mas cercana de
terminación de un proyecto.
(k) El sistema debe funcionar satisfactoriamente para
Diciembre de 2008, y (l) será producido por el
departamento de Sistemas de Información, (m) bajo la
gestión del departamento de Ingeniería de sistemas, (n)
El software correrá en PC’s.
Clasifique las
sentencias (a) a
(n) en los
siguientes tipos:
1 Requerimientos de
Negocio
2 Req. De Usuario
3 Req. De sistema
4 Elementos de
Diseño
5 Planes
6 Trasfondo
7 Detalle Irrelevante
Estructurando Requerimientos
A continuación encontrara una lista de requerimientos (numerados a hasta i). Ud. Debe organizarlos en las secciones
numeradas 1 a 7. Ha y siempre una única respuesta? La estructura propuesta es correcta?
Secciones propuestas para estructurar los requerimientos
1.
2.
3.
4.
5.
6.
7.
Preparación para el vuelo.
Despegue y Aterrizaje.
Vuelo.
Mantenimiento.
Safety.
Desempeño.
Materiales.
Requerimientos
a.
b.
c.
d.
e.
f.
g.
h.
i.
Todos los materiales expuestos externamente deben ser resistentes a la corrosión por agua salada.
(Sección
)
La aeronave debe poder navegar a una velocidad constante de 800 Km/h a 10000 m de altitud. (Sección )
Ninguna falla en un motor debe afectar la operación de ningún otro motor. (Sección )
Personal manipulador de equipaje podrá ingresar un carro estándar de equipaje directamente en la zona de
carga. (Sección )
El piloto debe poder oscurecer las luces de la cabina para el momento del despegue. (Sección )
El piloto debe poder ver el tiempo estimado para el aterrizaje (Sección )
El piloto debe ser alertado en caso de que el tren de aterrizaje no sea completamente desplegado durante la
preparación para el aterrizaje. (Sección )
Ingenieros de mantenimiento deben poder acceder todos los sellos de aceite directamente luego de retirar
las coberturas de los motores. (Sección )
Todos los materiales usados en el compartimiento de los pasajeros deben resistir la ignición bajo calor
aplicado de acuerdo al FAA estándar 123-45. (Sección )
Self Assesment
• Por Karl Wiegers
Verdades Cósmicas (Wiegers)
• If you don't get the requirements right, it doesn't matter
how well you execute the rest of the project.
• Change happens.
• Customer involvement is the most critical contributor to
software quality.
• The customer is not always right, but the customer always
has a point.
• Requirements development is a discovery and invention
process, not just a collection process.
• The first question an analyst should ask about a proposed
new requirement is, "Is this requirement in scope?“
Más Verdades
• The requirements might be vague, but the product will be
specific.
• You're never going to have perfect requirements.
Estándar IEEE 1074
ADMINISTRACIÓN DEL PROYECTO
Inicio, Supervisión, Control, Calidad
PRE- DESARROLLO
Exploración
Asignación del sistema
DESARROLLO
Requerimientos
Análisis
Diseño
Implementación
POS- DESARROLLO
Instalación
Operación & Soporte
Mantenimiento
Retiro
PROCESOS INTEGRALES
Verificación, Validación, Adm. de configuraciones, Documentación, Entrenamiento
Bibliografía
•
Karl E. Wiegers , More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press,
2006 ISBN:0735622671
•
Institute for Electronics and Electrical Engineers. Glosario Estándar de la Terminología de La Ingeniería
de Software. 1997.
•
Rational Software. Applying Requirements Management With Use Cases. Rational Software Corporation,
2000.
•
Sommerville Ian, Sawyer Peter. Requirements Engineering: A Good Practice Guide. John Wiley. 2000.
•
Young, Ralph, The Requirements Engineering Handbook, Artech House, Inc., 2004.
•
Thayer, Richard, Dorfam, Merlin. Software Requirements Engineering. IEEE Computer Science Press. 2000.
•
Wiegers, Karl. Software Requirements. Microsoft Press. Segunda edición. 2003.
•
SWEBOK, Software Engineering Body of Knowledge
•
Imágenes tomadas y/o adaptadas de estas fuentes