S07-2021 -II Captura de Requisitos

Vista previa del material en texto

Captura de 
requisitos
F. Sistemas e Informática -
UNAP
Contenido
 Qué es la captura de requisitos
 Ingeniería de requisitos
 El proceso de captura
Lo que Dicen los Autores
 Boehm, 1975: 45% de los errores tienen su origen en los 
requisitos y en el diseño preliminar.
 DeMarco, 1984: 56% de los errores que tienen lugar en 
un proyecto software se deben a una mala 
especificación de requisitos.
 Chaos Report, 1995: Los factores principales que 
conducen al fracaso en los proyectos software son:
Falta de comunicación con los usuarios.
Requisitos incompletos.
Cambios a los requisitos.
Problemas
 Los usuarios no saben lo que quieren.
 Un sistema tiene muchos usuarios y ninguno 
tiene una visión de conjunto.
 No saben cómo hacer más eficiente la 
operación en su conjunto
 No saben qué partes de su trabajo pueden 
transformarse en software.
 No saben detallar lo que saben de forma 
precisa.
Solución tradicional: analistas
Labores
 obtener una lista de requisitos de cada usuario
 adquirir una visión de conjunto
 componer una especificación completa, correcta 
y consistente
Desventajas
 listas de requisitos son difíciles de comprender y de 
hacer bien
 difíciles de transformar en especificaciones de 
diseño e implementación
Objetivos generales
 Enumerar los requisitos candidatos
 Comprender el contexto del sistema
 Capturar requisitos funcionales
 Capturar requisitos no funcionales
Requisitos funcionales
 Definen lo que el sistema tiene que hacer, 
los servicios que debe proporcionar al 
usuario
 Describen la funcionalidad del sistema
Requisitos no funcionales
 Delimitan las condiciones en que el 
sistema presta servicios a los usuarios 
 Velocidad de respuesta
 Ancho de banda requerido
 Espacio en memoria o en disco
 ....
Segunda parte
 Qué es la captura de requisitos
 Ingeniería de requisitos
 El proceso de captura 
Desafíos para la Ingeniería 
de requisitos
 Al informatizar un determinado proceso el propio proceso 
puede sufrir cambios difíciles de predecir. 
 Usuarios diferentes tienen requisitos y prioridades 
diferentes. Hay una negociación de cambios en los 
requisitos. 
 Los usuarios finales del sistema y la organización que 
paga por el sistema tienen requisitos diferentes. 
 El prototipado es necesario para clarificar requisitos
Lectores de requisitos
Gerencia de Cliente
Usuarios Finales del Sistema
Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema
Definición de
Requisitos
Requisitos
Especificación de
Usuarios Finales del Sistema
Ingenieros de Cliente
Arquitectos del Sistema
Desarrolladores de Software
Especificación de
Software
(Quizá) Ingenieros de Clientes
Arquitectos del Sistema
Desarrolladores de Software
El proceso de ingeniería de requisitos
Estudio de 
Viabilidad
Análisis de
Requisitos
Definición de
Requisitos
Especificación
de Requisitos
Informe de
Viabilidad
Modelos del
Sistema
Documento de
Requisitos
Definición de
Requisitos
Especificación de
Requisitos
Validación de requisitos
 Demostración de que los Requisitos que definen el 
sistema son lo que el cliente realmente quiere. 
 Los costos de errores en los Requisitos son altos, por lo 
cual, la validación es muy importante. 
 reparar un error de Requisito después del desarrollo 
puede resultar en un coste 100 veces mayor que 
reparar un error en la implementación. 
 El Prototipado es una técnica importante de la 
validación de Requisitos.
Qué comprobar 
Validación. ¿Provee al sistema las funciones 
que mejor soporten las necesidades del 
cliente? 
 Consistencia. ¿Existe cualquier conflicto en los 
Requisitos? 
Completo. ¿Están incluidas todas las funciones 
requeridas por el cliente? 
Realismo. ¿Pueden los Requisitos ser 
implementados con la tecnología y el 
presupuesto disponible?
Revisión de Requisitos
 Una revisión regular puede ayudar mientras la 
definición de Requisitos está siendo hecha. 
 Tanto el cliente como el personal de contratistas 
deben estar involucrados en la revisión. 
 La revisión debe ser formal (con los documentos 
completos) o informal. Una buena comunicación 
entre desarrolladores, clientes y usuarios puede 
resolver problemas en las primeras etapas.
Evolución de Requisitos
 Es esencial planear posibles cambios en 
los requisitos cuando el sistema sea 
desarrollado y utilizado.
 El documento de requisitos debe ser 
organizado, de tal forma que los cambios 
en los requisitos puedan ser hechos sin 
tener que re-escribir demasiado. 
 Las referencias externas deben ser 
minimizadas y las secciones del 
documento deben ser tan modulares 
como sea posible.
Tercera parte
 Qué es la captura de requisitos
 Ingeniería de requisitos
 El proceso de captura
Qué se pretende
 definir objetos observables
 evaluar el flujo y contenido de la 
información
 definir y elaborar funciones del software
 entender el comportamiento del sistema
 establecer características del interfaz
 descubrir restricciones ocultas
Delimitar el alcance
La funcionalidad y el rendimiento del sistema se 
deben acotar de manera comprensible y concreta 
(sin ambigüedades). 
Describir:
 datos y control,
 función
 rendimiento
 restricciones
 interfaces
 fiabilidad
Viabilidad
 Tecnología: hay tecnología? se domina? está dentro 
del estado del arte? 
 Financiera: pueden asumir el coste la organización, el 
coste, el mercado?
 Tiempo: llegará al mercado antes que la competencia?
 Recursos: qué se va a necesitar? está disponible?
Muy relacionado con la experiencia disponible en 
los proyectos del tipo que se pretenda desarrollar (si 
se han hecho muchos, es más fácil decidir sobre la 
viabilidad de una propuesta)
Citado en el Pressman
"Quien hace una pregunta parece 
ignorante durante cinco minutos. Quien 
se la calla sigue siéndolo el resto de su 
vida. "
Antiguo proverbio chino
Una situación en que los participantes...
no saben qué decir
se preocupan de que se les entienda mal
piensan a dónde va a llevar
tienen expectativas diferentes
quieren que se acabe cuanto antes
quieren que sea un éxito
Una entrevista de obtención de requisitos
¿Una primera cita romántica?
No.
Preguntas: sobre el contexto
 Quién solicita este trabajo
 Quién usará el producto
 Cuál es el beneficio económico de una 
solución satisfactoria
 Hay más fuentes para la solución que se 
busca
Preguntas: sobre el problema
 describir buenos resultados generados 
por una solución buena
 cuál es el problema al que nos 
enfrentamos
 en qué entorno (describir/mostrar) se va a 
utilizar
 restricciones específicas de rendimiento
Preguntas: sobre la reunión en sí
 es usted la persona adecuada para responder 
a estas preguntas
 son oficiales sus respuestas
 le parecen relevantes mis preguntas
 hago demasiadas preguntas
 hay alguien más que pueda aportar 
información
 hay algo más que debería preguntar
Limitaciones
 Las reuniones en generales dan 
resultados muy pobres.
 Se deben emplear sólo como primer 
paso, para luego ser sustituidos por 
reuniones que combinen resolución de 
problemas, negociación, y 
especificación.
Entregables
VISION
Aquí se documenta el
enfoque a alto nivel de
nuestro cliente, con
respecto al sistema
que se desarrollará.
Entregables
SRS:
ESPECIFICACIONES
DE LOS
REQUERIMIENTOS DE
SOFTWARE.
Se enfoca en la
organización
completa de los
requerimientos del
proyecto.
SRS
Identificar Actores
 Este es uno de los primeros
pasos para definir que o
quienes usarán del sistema.
 Cualquier tipo de fenómeno
externo que interactuará con
el sistema es representado por
el actor.
 Los diferentes tipos de usuario
son representados como
actores.
 Para encontrar a los actores,
realice las siguientes
preguntas:
Identificar Actores
 ¿Qué grupos de usuarios necesitan ayuda
del sistema parallevar a cabo sus tareas?
 ¿Qué grupos de usuarios son fundamentales
para ejecutar las funciones obvias del
sistema?
 ¿Qué grupos de usuarios son los que llevarán
a cabo funciones secundarias como
mantenimiento o administración?
 ¿El sistema a desarrollar interactuará con 
algún hardware o sistema de software?
Identificar Casos de Uso
 Define un conjunto de
flujos de eventos que el
sistema lleva a cabo para
brindar un resultado de
valor observable a cada
actor en particular.
 Su principal objetivo es:
Capturar el
comportamiento del
sistema requerido, a partir
del punto de vista del
usuario final.
 La descripción del caso de
uso define que sucede en
el sistema cuando se
ejecuta el caso de uso.
Preguntas clave para
encontrar los casos de
uso:
• Para cada actor
identificado, cuáles son
las tareas en las que el
sistema los puede
ayudar?
• Qué información debe
ser creada o modificada
en el sistema?
• El actor necesita estar
informado sobre ciertas
ocurrencias del sistema?
Pre Requisitos
 Tener documentados
los casos de uso:
Flujo de Eventos.
 La presentación se
realizará tomando
como ejemplo el
Sistema Notas.
Razones
Existen 3 razones para estructurar
el Modelo de Casos de Uso:
– Hacer que los casos de uso sean
fáciles de entender.
– Permite extraer el
comportamiento común
encontrado en varios casos de
uso.
– Hacer que el Modelo de Casos
de Uso sea fácil de mantener.
Tipos De Relaciones
Existen 3 tipos de relaciones
para estructurar los casos de
uso:
 Include
 Extend
 Generalización
Relación Include
 Conecta un caso de uso base a un caso de uso
incluido.
 El caso de uso incluido es abstracto.
 La inclusión es encapsulada y representa el
comportamiento que es reutilizado por varios casos de
uso.
 Se factoriza el comportamiento que es común en un
nuevo caso de uso.
Se tiene el siguiente diagrama:
Los pasos del 2 al 5 se repiten en 
los flujos de eventos de los dos 
casos de usos. 
Es decir, se está llevando a cabo 
el mismo comportamiento en 
ambos casos de uso.
Este comportamiento se 
extrae en un nuevo caso de 
uso: Buscar Alumnos
Buscar Alumnos
CU Base
CU Incluido
El nuevo diagrama con include:
Relación Extend
Conecta un caso de uso extendido a
un caso de uso base.
En el caso de uso base están
referenciados los puntos de
extensión.
El caso de uso extendido es a
menudo abstracto, pero no
necesariamente tiene que serlo.
Se pueden usar la relación extend para varios
propósitos:
a. Para demostrar que una parte del caso de uso es
opcional, de esta manera se separa el
comportamiento opcional del comportamiento
obligatorio en su modelo. También se le
conoce como comportamiento añadido.
b. Para demostrar que un subflujo es ejecutado sólo bajo
ciertas condiciones como un trigger o alarma.
c. Los segmentos de comportamiento que son insertados
como puntos de extensión en el caso de uso base,
dependerán de la interacción con los actores durante
la ejecución del caso de uso base.
d. La extensión es condicional, lo que quiere decir que su
ejecución es dependiente de lo que suceda mientras
se ejecuta el caso de uso base.
El nuevo diagrama con Extend
Relación de Generalización
 Se utiliza cuando el caso
de uso padre debe ser
subclasificado en uno o
más casos de uso hijos.
 El caso de uso hijo hereda
la estructura,
comportamiento y las
relaciones del padre.
Lecturas para Evaluación 
Próxima semana
 Pressman, capítulos 10 y 11
 Sommerville, capítulos 5 y 6