Post on 14-Jul-2015
Ayuda a entender mejor el problema
Incluye conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio
Establece una base sólida para el diseño y la construcción
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
Administrar los requisitos conforme estos se transforman 2
Inicio
Identificar a los interesados
Reconocer múltiples puntos de vista
Identificar áreas de conflicto y áreas en común
Formulación de preguntas
4
Obtención
5
Problemas de ámbito
Problemas de comprensión
Problemas de volatibilidad
El límite del sistema mal definido o los clientes/usuarios especifican detalles innecesarios que pueden confundir.
Los clientes/usuarios no están seguros por completo y de qué es lo que se necesita -No comprenden el dominio del problema-Especifican requisitos ambiguos o inestables-Omiten información que consideran obvia
Los problemas cambian conforme transcurre el tiempo
Despliegue de la función de calidad(QFD)
6
Tipos de Requisitos
Normales
Reflejan los objetivos y metas establecidos
Ejm: Gráficos en pantalla, funciones específicas, niveles de rendimiento óptimos.
Esperados
Están implícitos en el producto o sistema
Ejm: Facilidad Humano/máquina,
corrección y confiabilidad operacional
Estimulantes
Características que van más allá de las
expectativas del cliente
Ejm: Predecir palabras en un sistema q no se
especifico esa funcionalidad
Traduce necesidades del cliente en requisitos técnicos para el software
Se concentra en aumentar la satisfacción del cliente desde el proceso de la ingeniería del software
Obtención
Casos de uso
7
Obtención
Cuenta la manera en que un usuario final interactúa con el sistema en un conjunto de circunstancias
Definir actores
Diferentes personas que se comunican con el sistema.
Ejemplo 1
-El programador-El que realiza las pruebas-El que monitorea-El que resuelve problemas
8
Obtención
Ejemplos casos de uso
Descripción de un caso de uso
Diagrama de caso de uso
Fuente: http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php
Elaboración
9
Desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software
Se definen los atributos de cada clase de análisis y se identifican los servicios que requiere cada clase
Se definen las relaciones y la colaboración entre las clases
Clase de análisis: entidades de dominio de negocios visibles para el usuario final
Negociación
10
Definir prioridades
Analizar los riesgos de cada requisito
Hacer estimaciones del esfuerzo requerido y su impacto sobre el costo y tiempo
Eliminar, combinar y modificar los requisitos si es necesario
No debe haber ganador ni perdedor, ambas partes deben salir ganando
Especificación
11
Sirve como base para las actividades de ingeniería de software subsecuentes
Puede ser un documento escrito , un conjunto de modelos gráficos, un modelo matemático formal, una colección de casos de uso, un prototipo o
una combinación de estos
Describe la función y desempeño de un sistema y sus restricciones
Validación
12
La especificación para asegurar que todos los requisitos se han establecido de manera precisa
Que los productos de trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto
Examina
Que se han detectado las inconsistencias, omisiones y errores y que estos han sido corregidos
Gestión de requisitos
13
Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a éstos en cualquier momento
Tablas de rastreabilidad
De las características De la fuente
De dependenciaDel substistema
De la interfaz