S07-2020I 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 para llevar 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
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:		
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.
Para demostrar que un subflujo es ejecutado sólo bajo ciertas condiciones como un trigger o alarma.
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. 
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
Buscar Alumnos