CAPTURA DE REQUERIMIENTOS - Universidad Alas … · 2010-08-26 · Describen las interacciones...
Transcript of CAPTURA DE REQUERIMIENTOS - Universidad Alas … · 2010-08-26 · Describen las interacciones...
Temario
• Ingeniería de Requerimientos
• Diagrama de actividades del proceso del negocio
• Identificación de Actores y Casos de Uso
• Documento Especificación de Requerimientos deSoftware (SRS).
Objetivos• Conceptualizar lo que es un requerimiento, tipos y la Ingeniería deRequerimientos
• Describir en que consiste la Administración de Requerimientos,propósitos y creación de la Base de Datos de requerimientos
• Obtener un Modelo de Casos de Uso y Modelo Conceptual a partir deun Diagrama de Actividades del Proceso del Negocio
• Entender la importancia de la Especificación de Requerimientos delSistema (SRS)
• Comprender la metodología RUP y las aplicaciones de los Casos de Uso.
1. DEFINICION DE REQUERIMIENTOS
Corresponde a una declaración en un Lenguaje Natural,
escrito para los clientes, incluye:
Diagramas de los servicios del sistema
Límites operacionales.
I. INGENIERIA DE REQUERIMIENTOS
1.1. ¿QUE ES UN REQUERIMIENTO?
• Es una característica que un sistema debe tener para
cubrir alguna de las necesidades que lo motivan
• Rango de instrucciones abstractas de alto nivel de un
servicio o de un sistema
• Base para la declaración de un contrato y deber ser
interpretado
• Posteriormente debe ser definido en detalle
• Ambas declaraciones serán llamadas Requerimientos.
• Los ATRIBUTOS y las RELACIONES entre requerimientos sirven
para el manejo de la información del proyecto.
1.2. PROPOSITOS: OBTENCION DE REQUERIMIENTOS
• Identificación de un área del problema
• Llegar a un acuerdo con los clientes/usuarios sobre lo
que el sistema debe hacer
• Especificación del sistema
• Proporcionar a los desarrolladores un mejor
entendimiento de los requerimientos
• Definir las fronteras (delimitar) del sistema
• Proporcionar bases para planificar las iteraciones
• Estimar los costos y el tiempo de desarrollo
• Definir la GUI, basándose en las necesidades y
objetivos de los usuarios.
• Formalización de la especificación: Modelo de Análisis
• Especificación VS Análisis:
Representan la misma información
Difieren en el lenguaje y la notación
Especificación: lenguaje natural
Análisis: notación formal o semi formal
• Sirven de elemento de comunicación
Especificación: comunicación con cliente y usuarios
Análisis: comunicación entre desarrolladores
1.3. TIPOS DE REQUERIMIENTOS
•Requerimientos FuncionalesDescriben las interacciones entre el sistema y su Entorno
(Usuarios u otros Sistemas), sin tener en cuenta la
implementación
Representan el Modelo de Casos de Uso (MCU)
También son conocidos como “CAPACIDADES” del sistema.
•Requerimientos No FuncionalesAspectos visibles por el usuario (Portabilidad, Confiabilidad,
Eficiencia, Ingeniería Humana, Verificabilidad, Entendimiento,
Modificabilidad)
Se recogen de los CU con los que están relacionados, o en las
Especificaciones Complementarias.
•Requerimientos de Implementación Son necesidades del cliente que restringen la implementación,
como por ejemplo: lenguaje de programación, plataforma,
hardware, servidor de páginas Web, Base de Datos, Tipo de
navegador para Internet, políticas de seguridad, etc.
El Glosario agrupa y clarifica los términos que se utilizan en los
requisitos.
Gestionar asignaturas
Gestionar profesores
Introducir encargo de docencia
Gestionar aulas y laboratorios
Administrador
Gestionar horarios
Usuario externo
Consultar horarios
Requerimientos FuncionalesModelo de Casos de UsoGestión de horarios
RequerimientosNo Funcionales
requerimientosdel producto
requerimientosorganizacionales
requerimientosexternos
eficienciafiabilidadusabilidad portabilidad
rendimientoespacio entregaimplementaciónestándares
interoperabilidadéticos legislativos
privacidadseguridad
Fuente: Ingeniería de Software, I. Sommerville, p. 102
1.4. CARACTERISTICAS DE LA ESPECIFICACION DE
REQUERIMIENTOS
Validación de requerimientos: continua y es muy
importante, para asegurar que la especificación sea:
• Correcta: representar la visión que el cliente tiene del sistema
• Completa: con todos los escenarios posibles, incluyendo el
comportamiento excepcional (alternativo)
• Consistente: no se contradice a sí misma
• No ambigua: interpretar aspectos de especificación de 2 ó más
formas diferentes
• Realista: el sistema se puede implementar con las restricciones
documentadas
• Verificable: construido el sistema, se puede diseñar pruebas
repetibles que demuestren que se satisfacen los requerimientos
Ejemplos de requerimientos no verificables:
El producto debe tener una buena interfaz de usuario
El producto debe responder en un tiempo razonable
El sistema debe ser seguro
• Rastreable: se debe organizar de tal forma que cada
funcionalidad se pueda auditar hasta su conjunto de
requerimientos correspondientes, facilitando las pruebas y
validaciones del diseño.
2. INGENIERIA DE REQUERIMIENTOS
La Ingeniería de Requerimientos es una disciplina que
abarca la captura, elaboración, documentación y
validación de los Requerimientos.
INGENIERIA DE REQUERIMIENTOS
DESARROLLO DE REQUERIMIENTOS ADMINISTRACION DE REQUERIMIENTOS
CAPTURA
REQUERIMIENTOS
ANALISIS
REQUERIMIENTOS
ESPECIFICACION
REQUERIMIENTOS
VALIDACION
REQUERIMIENTOS
3. ADMINISTRACION DE REQUERIMIENTOS
Es una forma sistemática de obtener, documentar,
organizar y rastrear los cambios en los requerimientos de
su sistema.
Problemas:• Roles del equipo de desarrollo indefinidos y descoordinados
• Trabajo y rendimiento del proceso son dañados por brechas de
performance y conflictos
• Visión limitada en el proceso y calidad del producto
• Control limitado de las configuraciones del producto
• Entrega tardía del cronograma inicialmente fijado
• Descontrol de costos, el trabajo cuesta mucho más de estimado
• Las necesidades del cliente no son cubiertas por el software.
Tener en cuenta:
• Los errores en los requerimientos son los más
caros de solucionar
• Los errores en los requerimientos son los errores
más comunes
• El retraso consume del 40 al 50% del
presupuesto
• Los errores de requerimientos consumen
mayoría de los retrasos (>%70)
• El retraso consume del 30 al 40% del total
presupuestado.
Dificultades:
• No son obvios - vienen de muchas fuentes
• Son difíciles de expresar en palabras
• Existen muchos tipos variando en detalles
• El número puede ser duro manejar
• Nunca son iguales
• Se relacionan entre si y a otras cosas
• Trascienden las áreas funcionales
• Hay cambios a lo largo de todo el ciclo de vida de
desarrollo
• El retorno de la inversión (ROI) es difícil
cuantificar (porque es muy especifico para cada
proyecto).
Beneficios:
• Dentro de un proyecto, mejora la predictibilidad de los
Cronogramas y Entregables
• Disminuye costos y demoras de un proyecto
• Mejora la calidad del software
• Mejora la comunicación del equipo
• Mejora el ajuste a estándares y reglamentos: Capability Maturity
Model (CMM), ISO 9000, etc.
3.1. ACTIVIDADES: ADM. DE REQUERIMIENTOS
• Generar acuerdos sobre el problema a resolver
El Análisis del problema es un acto de razonamiento para
encontrar “el verdadero problema detrás del problema”.
Determinar quién tiene el problema realmente (el apoyo clave)
Explorar muchas posibles soluciones (desde una variedad de
perspectivas)
Seguir preguntando: ¿Por qué?
Desarrollar un Documento Posición del Producto
Desarrollar un Documento de Visión.
• Promover un vocabulario común (Glosario de Términos)
Asegurar que todos hablan de lo mismo
Reducción temprana de la ambigüedad
Optimizar el uso del tiempo disponible
Reusabilidad por otros proyectos
• Definir los límites del sistema
Modelo de Casos de Uso del sistema (MCU)
Saber lo que se está construyendo y lo que no está
construyendo
Entender lo que se necesita ahora y cómo esa solución
evolucionará (estrategia de producto a corto y largo plazo).
• Identificar los apoyos clave es decir los actores (ellos son
materialmente afectados por resultado del sistema)
• Identificar las restricciones a imponer al sistema
Entender el mercado (dominio del usuario) y cómo está
cambiando
No sobredimensionar (over-architect) la solución
Determinar cualquier restricción de impacto medioambiental,
de presupuesto, de viabilidad o de planificación
Desarrollar una declaración de Posición de Producto.
3.2. Comunicar los Requerimientos
Los requerimientos deben ser comunicados en todos los
niveles del proyecto.
Puntos a seguir:• Documentar todos los requerimientos
• Disgregar hasta un nivel de detalle apropiado
• Hacerlos visibles a todos los apoyos clave
• Asegurar que los requerimientos son estables
• Entender la razón y beneficios para cada requerimiento
• Permitir el cambio - analizar impacto de cada cambio antes de
aceptar la modificación de un requerimiento
• Mantener documentos “vivos” que son fáciles de adaptar a los
cambios de requerimientos
• Establecer relaciones entre requerimientos para indicar
dependencias y refinamiento.
3.3. FORMATO DE LOS DOCUMENTOS
• El formato de los documentos generados en la fase de
requerimientos deben de seguir un formato estándar
preferentemente guiados de los artefactos que RUP proporciona
• Gestión de Requerimientos Basado en Casos de Uso.
Beneficios:• Potencia el trabajo de los otros
• Los documentos se ven familiares y no intimidan
• Los documentos son mas fáciles de escribir
• Capítulos y secciones estándar
• Recomendaciones que proveen de ayuda a quien los complete
• Los documentos son de lectura más sencilla
• Saber exactamente donde buscar la información
• Asegurar la cobertura de tópicos importantes
• Secciones obligatorias como el checklist.
3.4. Técnicas: Obtención de Requerimientos
a) Entrevistas y Cuestionarios
Usuario
¿Quién es el cliente?
¿Quién es el usuario?
¿Son sus necesidades diferentes?
¿Cuáles son sus capacidades, ambientes y presupuestos?
Productos
¿Qué problemas de negocios podría crear este producto?
¿En qué ambiente se usará el producto?
¿Cuáles son las expectativas de utilidad, fiabilidad, actuación?
Procesos
¿Cuál es la razón para querer resolver este problema?
¿Cuál es el valor de una solución exitosa?
¿Cómo resuelve usted el problema ahora?
b) Workshops de Requerimientos
• Reuniones con los usuarios y clientes, se ven los apoyos claves
por un periodo acotado y focalizado
• El facilitador que hace el WorkShop administra la reunión y se
espera que todos opinen
• Lo favorable es que se obtiene resultados inmediatamente
disponibles y provee un marco referencial para aplicar otras
técnicas de extracción.
3.5. Los cambios en los requerimientos
Se pueden presentar por:
• Porque no se hicieron las preguntas
adecuadas a las personas correctas en el
momento oportuno
• Porque el problema que se esta
resolviendo cambió
• Porque los usuarios cambiaron sus ideas o
sus percepciones
• Porque el ambiente comercial cambió
• Porque el mercado cambió.
• El documento de requerimientos debe ser
organizado, de tal forma que los cambios en
los requerimientos puedan ser hechos sin
tener que re-escribir demasiado.
• Las secciones del documento deben ser tan
modulares como sea posible.
• Los cambios son fáciles cuando se trata de un
documento electrónico. Sin embargo, la falta
de estándares para documentos electrónicos
lo hace difícil.
Trazabilidad de RequerimientosEl propósito es:
• Garantizar que todos los requerimientos del sistema se han
cumplido
• Asegurar que la aplicación hace lo que se pensaba que hacía
• Ayudar a administrar el cambio
• Una técnica probada para entender el impacto de los cambios
• Una técnica probada para asegurar la calidad.