SEMANA 2 – Primera Sesión

CAPTURA DE REQUERIMIENTOS

Profesor del Curso: Aréstegui Guillén Oscar

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.

El ciclo del cambio

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.

3.6. RUP – Flujo Trabajo Captura de Requerimientos

4. Resumen

El proyecto desde el punto de vista de los requerimientos es

administrado así (Rational Requisite Pro):