Ingeniería de requisitos

INGENIERIA DE
REQUISITOS
INGENIERÍA DE SOFTWARE
La comprensión de los requisitos
de un software está entre las
tareas más difíciles que encuentra
un ingeniero de software.
¿Qué es?
 La ingeniería de requisitos ayuda a los ingenieros de
software a entender mejor el problema en cuya
solución trabajaran.
¿Porqué es importante ?
 El diseño y la construcción de un software elegante
que resuelva el problema incorrecto no satisface las
necesidades de nadie.
¿Cómo puedo estar seguro de que lo he hecho
correctamente?
 El ingeniero de software revisa los productos de
trabajo de la ingeniería de requisitos junto con el
cliente y los usuarios finales para asegurarse que
hayan entendido lo que en realidad pretendían
decirle.
 Es necesario hacer una advertencia: aún después de
que todas las partes están de acuerdo, las cosas
cambian, y continuarán haciéndolo a través de la vida
del proyecto.
Determinación de Requerimientos
Antes de que los requisitos puedan ser analizados,
modelados o especificados, deben ser recogidos a
través de un proceso de obtención.
Tareas de la Ingeniería de Requisitos
“Por lo general, las semillas de los
desastres más importantes en
software se siembran en los
primeros tres meses desde el
comienzo del proyecto”
1. Inicio
En algunos casos, una conversación informal es todo lo
que se necesita para precipitar un esfuerzo importante
de ingeniería del software, pero en general, la mayoría de
proyectos comienza cuando se identifica una necesidad
de negocios o se descubre un nuevo mercado o servicio
potencial.
2. Obtención
La técnica de obtención de requisitos más usada es llevar a
cabo una reunión o entrevista preliminar.
¿Quién está detrás de la
solicitud
de
este
trabajo?
¿Cuál será el beneficio
económico del éxito de
una solución?
¿Hay
alguna
otra
alternativa
para
la
solución que necesita?
¿Quién
utilizará
solución?
la
Las siguientes preguntas permiten al analista obtener un
mejor entendimiento del problema y al cliente comentar
sus opiniones sobre la solución:
¿Cómo
caracterizaría
una
buena
salida
generada
para una
buena solución?
¿A
que
tipo
de
problema(s) va dirigida
esta solución?
¿Hay
aspectos
o
restricciones
especiales
del
rendimiento
que
afecten la manera de
enfocar la solución?
Las siguientes preguntas se concentran en la eficacia de la
reunión:
¿Es usted la persona adecuada para responder a estas
preguntas?
¿Sus respuestas son oficiales?
¿Estoy preguntando demasiado?
¿Hay alguien más que pueda suministrar información
adicional?
¿Hay algo más que debería preguntarle?
Consejo
Si un sistema o producto va a servir a muchos usuarios, los
requisitos deberán ser obtenidos de un grupo
representativo de dichos usuarios. Si sólo una persona
define todos los requisitos, el riesgo de aceptación será
alto.
Todas estas preguntas ayudarán a romper el hielo e iniciar
la comunicación tan esencial para el éxito del análisis.
Técnicas para facilitar las especificaciones de una
aplicación
La reunión se celebra en un lugar neutral y acuden tanto los
clientes como los desarrolladores.
Se establecen normas de preparación y de participación.
Se sugiere una agenda lo suficientemente formal como para
cubrir todos los puntos importantes, pero lo suficientemente
informal como para animar el libre flujo de ideas.
Un coordinador que controla la reunión.
El objetivo es identificar el problema, proponer elementos de
solución, negociar diferentes enfoques y especificar un conjunto
preliminar de requisitos de la solución en una atmósfera que permita
alcanzar el objetivo.
Consejo
Evite el impulso de cortar la idea de un cliente por
demasiado costosa o poco práctica. La idea es
negociar algo que sea aceptable por todos. Es decir,
debes tener una mente abierta.
Despliegue de la Función de Calidad
El DFC es una técnica de gestión de calidad que traduce
las necesidades del cliente en requisitos técnicos del
software.
Identifica tres tipos de requisitos:
Normales
Esperados
Innovadores
3. Elaboración
 La información conseguida con el cliente durante el
inicio y la obtención se expande y se refina durante la
elaboración.
 Esta actividad de la ingeniería de requisitos se enfoca
en el desarrollo de un modelo técnico refinado de las
funciones, características y restricciones del
software.
4. Negociación
 El ingeniero de requisitos debe conciliar los
conflictos por medio de un proceso de
negociación.
 Se identifican y se analizan los riesgos
asociados con cada requisito. Se hacen
estimaciones preliminares de esfuerzos
requeridos para su desarrollo y después se
analizan para saber su impacto de cada
requisito en el costo del proyecto y sobre el
tiempo de entrega.
5. Especificación
 La especificación es el producto de trabajo final que
genera la ingeniería de requisitos. Sirve como base
para las actividades de ingeniería de software
subsecuentes.
6. Validación
 La validación de requisitos examina la especificación
para asegurar que todos los requisitos de software se
han establecido de manera precisa; que se han
detectado las inconsistencias, errores y omisiones, y
que éstos han sido corregidos.
7. Gestión de requisitos
 Es un conjunto de actividades que ayudan al equipo de
proyecto a identificar, controlar y rastrear los
requisitos y los cambios a éstos en cualquier momento
mientras se desarrolla el proyecto.
Casos de Uso
Una vez recopilados los requisitos, el analista puede
crear un conjunto de escenarios que identifiquen una
línea de utilización para el sistema que se ha de
construir.
Clave
Un caso de uso es un escenario que describe cómo
el software va a ser usado en una determinada
situación.
Casos de Uso (Cont.)
Para crear un caso de uso, el analista debe primero
identificar los diferentes tipos de personas (o
dispositivos) que utiliza el sistema o producto (actores).
Es importante indicar que un actor y un usuario no son
la misma cosa.
Ya que la obtención de requisitos es una actividad de
evolución, no todos los actores se identifican en la
primera interación.
Muchas gracias