3. guia análisis de requerimientos
TRANSCRIPT
Ingeniería de Requerimientos
Levantamiento de Información
Requerimientos
de
Sistemas de Información
Hardware
Desarrollo
Necesidades del Cliente
Clientes
Analistas
Sistemas
Documentación
La ingeniería de requerimientos ayuda a los
ingenieros de software a entender mejor el
problema en cuya solución trabajarán.
Incluye el conjunto de tareas que conducen a
comprender cuál será el impacto del software y
cómo interactúan los usuarios finales con el
sistema.
Ingeniería de RequerimientosDefinición
Ingeniería de RequerimientosDefinición
Teniendo en cuenta lo que usted visualiza enla imagen, una situación muy típica en loreferente proyectos de desarrollo desoftware, ¿Qué deduce de la historieta? ¿Aqué cree que se deba el resultado obtenidoen la imagen?
Pregunta de Análisis Req1
Tarea Req1
Realice un breve y conciso análisis --deacuerdo con su experiencia desarrollandosoftware-- sobre el porqué puede serdesastroso un sistema de información.
•La educción de requisitos se refiere a la
captura y descubrimiento de los requisitos.
•Es una actividad más “humana” que técnica
•Se identifica a los interesados (stakeholders) y
se establecen las primeras relaciones entre
ellos y el equipo de desarrollo
La ingeniería de requisitos proporciona el
mecanismo apropiado para:
• Entender lo que el cliente quiere
• Analizar las necesidades
• Evaluar la factibilidad
• Negociar una solución razonable
• Especificar la solución sin ambigüedades
• Validar la especificación y administrar los
requisitos conforme éstos se transforman
en un sistema operacional
Ingeniería de RequerimientosEducción
Ingeniería de RequerimientosFunciones
La ingeniería de
requisitos es un puente
hacia el diseño y laconstrucción.
1. Inicio
2. Obtención
3. Elaboración
4. Negociación
5. Especificación
6. Validación
7. Gestión
La ingeniería de requisitos se lleva a acabo a través de siete distintas funciones, ytodas están dirigidas a definir lo que el cliente quiere.
Algunas de estas actividades ocurren en paralelo
•Es una tarea que define el ámbito y la naturaleza del problema que debe
resolverse.
•La mayoría de los proyectos comienzan cuando se identifica una necesidad
de negocios o se descubre un nuevo mercado o servicio potencial.
•Los clientes pueden estar en una ciudad o país diferente, pueden tener sólo
una idea vaga de lo que se quiere.
•Debe haber una identificación de los interesados, que son las personas que
se benefician de una forma directa o indirecta.
•Reconocimiento de múltiples puntos de vistas, ejemplo. Las personas de
mercadotecnia, en cuanto a que el nuevo sistema sea fácil de vender, los
gerentes de negocios están interesados en un grupo de características que se
puedan construir sin rebasar un presupuesto.
Ingeniería de Requerimientos1-Inicio
Fase de inicio
Técnicas de obtención de requerimientos
• Preliminares: Utilizar preguntas libres de contexto
• Brainstorming. Administrador, lluvias de ideas.
• Creatividad? (manejo de herramientas.)
• Entrevistas: Es el método “tradicional”
• Observación y análisis de tareas
• Casos de uso / Escenarios: requisitos en contexto de uso
• Prototipado: Útiles cuando la incertidumbre es total acerca del futuro sistema.
Ingeniería de Requerimientos2-Obtención
• Dentro de las técnicas utilizadas para recopilar información,
las entrevistas ocupan un lugar preponderante, son la mayor
fuente de información del analista.
• Las entrevistas se pueden realizar sobre la base de un
cuestionario rígido o de una guía más o menos detallada que las
orienta hacia puntos bien definidos.
• Es fundamental: Entrevistar a la(s) persona(s) adecuadas
• Preparar las preguntas con antelación
• Utilizar diagramas, modelos, etc.
Ingeniería de Requerimientos2-Obtención
El método de entrevistas para obtener información tiene lassiguientes ventajas:
• Permite a los analistas presentar sus necesidades de forma
directa y verificar en las respuestas recibidas, si las preguntas
realizadas fueron interpretadas correctamente.
• Es una oportunidad que tiene el analista para conocer el grado de
aceptación o resistencia que existe entre los usuarios hacia el
sistema que se desea diseñar.
• .
Ingeniería de Requerimientos2-Obtención
Objetivo:
• Generar un gran número de ideas
• Seleccionar un grupo variado de participantes
• Eliminar críticas, juicios y evaluaciones mientras los participantes sugieren
ideas
• Producir muchas ideas. “La calidad emerge de la cantidad”
• Recoger todas las ideas por escrito
BRAINSTORMING
Ingeniería de Requerimientos2-Obtención
Comprensión de Requerimientos
Ingeniería de Requerimientos2-Obtención
La comprensión de los requisitos de un problema está entre las tareasmás difíciles que enfrenta un ingeniero de software.
El cliente no sabe lo que quiere, no esta seguro de qué es lo que necesita
Algunas veces el cliente no comprende del todo el dominio delproblema.
Tiene dificultades al comunicar necesidades al ingeniero de sistemas.
Omiten información que consideran obvia, y aún si los clientes y usuariosfinales son explícitos en sus necesidades, estos requisitos pueden cambiardurante el proyecto.
Pregunta de Análisis Req2
Las listas pueden haber sido colocadas en un boletín electrónico, en un sitio web interno, o
situadas dentro de un ambiente de foro de discusión.
Ingeniería de Requerimientos2-Obtención
R
E
C
O
P
I
L
A
C
I
Ó
N
C
O
N
J
U
N
T
A
R
E
Q
U
I
S
I
T
O
S
D
E
Se crea el equipo de participantes y desarrolladores, para identificar el problema y proponer
elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de
requisitos para la solución.
Se programan reuniones dirigidas a los diferentes actores involucrados.
Se sugiere un a agenda que sea tan formal como para cubrir todos los puntos importantes.
Se pide a cada asistente hacer una lista de objetos que son parte del ambiente que rodea el
sistema, otros objetos que éste producirá, y objetos que utiliza para realizar sus funciones.
Además se le pide a cada asistente que elabore una lista de los servicios (procesos o
funciones) que manipulan o interactúan con los objetos.
Ingeniería de Requerimientos3-Elaboración
Cada escenario del usuario se analiza para obtener clases deanálisis, entidades del dominio de negocio, se definen losatributos de cada clase de análisis y se identifican las relacionesy la colaboración entre las clases y se produce una variedad dediagramas de UML complementarios.
Esta actividad de la ingeniería de requisitos se enfoca en eldesarrollo de un modelo técnico refinado de las funciones,características y restricciones del software, mediante la creacióny el refinamiento de escenarios del usuario que describen laforma en que el usuario final, y otros actores interactuarán conel sistema.
Ingeniería de Requerimientos4-Negociación
Se pide a los clientes, usuarios y otros interesados que ordenensus requisitos y después discutan los conflictos relacionados con laprioridad.
Se identifican y analizan los riesgos asociados con cada requisito
Se hacen estimaciones preliminares de esfuerzo requerido para sudesarrollo y después se utilizan para evaluar el impacto de cadarequisito en el costo del proyecto y sobe el tiempo de entrega.
Ingeniería de Requerimientos5-Especificación
Una especificación puede ser un documento
escrito
También puede ser un conjunto de modelos gráficos, una colección de escenarios de uso, un
prototipo o cualquier combinación de estos.
También podría ser un documento que combina descripciones en el lenguaje natural y modelos
gráficos.
Algunos sugieren que para una especificación
se debe desarrollar y utilizar una plantilla
estándar.
ID de Requerimiento: Clave ó identificador del RequerimientoRequerimiento: Nombre del Requerimiento
Tipo de Requerimiento:
Funcional ó No Funcional
Clasificación:Si el requerimiento es NO funcional, clasificarlo
como Facilidad de uso, Disponibilidad, Capacidad…
Descripción: Descripción del RequerimientoDatos de Entrada: Entradas requeridas para el requerimiento
Datos de Salida: Salidas que se obtienen del requerimientoUsuarios Involucrados: Perfiles que intervienen en el requerimiento
Ingeniería de Requerimientos6-Validación
El equipo de revisión que valida los requisitosincluye ingenieros de software, clientes, usuarios yotros interesados que examinan la especificación ybuscan errores en el contenido o la interpretación.
Aquí se examina la especificación paraasegurar que todos los requisitos desoftware se han establecido de maneraprecisa.
Tarea Req2
Los requisitos contienen demasiados errores
Muchos de estos errores no se detectan al principio
Muchos de estos errores podrían ser detectados al principio
No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial
Además, los programadores obedecen los requisitos (cuando existen).
• El sistema resultante no satisfará a los usuarios
• Se producirán desacuerdos entre usuarios desarrolladores
• Puede ser imposible demostrar si el software cumple, o no, los requisitos
• Se gastará tiempo y dinero en construir el sistema equivocado
Ingeniería de RequerimientosErrores
La evidencia empírica demuestra que…
Consecuencias de los errores
Problema
Especificación Correcta
Especificación Incorrecta
Diseño Correcto
Diseño Erróneo
Programas Correctos
Programas Erróneos
Diseño Basado en la Especificación Errónea
Programas Basados en la Especificación Errónea
Programas Basados en un Diseño Erróneo
Funciones Correctas
Errores Corregibles
Errores Ocultos
Errores Incorregibles
Especificación de Requisitos
Diseño
Implementación
Pruebas
Productos Imperfectos
Ingeniería de RequerimientosErrores
Acumulación de Errores
El proceso de requisitos es excesivamente largo y costoso
Los implicados en el proceso se quejan de falta de tiempo u otros recursos
Se reciben quejas acerca de la inteligibilidad del documento de requisitos
Los implementadores se quejan del trabajo perdido por culpa de errores en los requisitos
Los usuarios no utilizan muchas de las capacidades del sistema
En cuanto el producto se entrega, se recibe una inmensa cantidad de solicitudes de cambios
Lleva demasiado tiempo alcanzar un acuerdo cuando se proponen cambios a los requisitos
Ingeniería de RequerimientosProblemas
Encontraremos problemas en nuestro análisis de requerimientos cuando:
_ Sistemas de 15 o 30 requisitos
– Sistemas de cientos de requisitos
– Sistemas de miles de requisitos
– Sistemas de 5.000 requisitos
– Sistemas de más de 10.000
– Sistemas de incluso 60.000 requisitos
Ingeniería de RequerimientosComplejidad
Dependiendo la cantidad de requisitos, el sistema va
adquiriendo cierta complejidad…
Tarea Req3
Consultar el esquema estándar de IEEE 810, teniendo en cuenta:
•Introducción• Propósito• Alcance• Definiciones• Referencias• Visión General
•Descripción General• Perspectiva del producto• Funciones del producto• Características del usuario• Restricciones• Suposiciones
•Requisitos específicos• Apéndices• Índice
Ingeniería de RequerimientosTarea
• Ingeniería de software, un enfoque práctico. Roger S. Pressman. Mc Graw Hill.
• Ingeniería de software, IAN SOMMERVILLE. Sexta edición. Addison Wesley. Person Educación
• UML y patrones . Craig. Larman
• www.vico.org
• Esquema del estándar de IEEE 830
Ingeniería de RequerimientosBibliografía