Ingeniería de

Requerimientos

Luis Contreras
(MCSD.Net)
Temario
 Introducción
 El proceso de Ingeniería de Requerimientos
1. Estudio de Factibilidad
2. Obtención y análisis de requerimientos
3. Especificación de requerimientos (SRS)
4. Validación de requerimientos
 Administración de Requerimientos
 Análisis comparativo de las técnicas de ingeniería de
requerimientos
 Gestión de Requerimientos según RUP y CMMI
 Caso Práctico
Objetivos
 Resaltar la importancia que tiene la Ingeniería de
Requerimientos dentro del ciclo de desarrollo.
 Dar a conocer las diferentes alternativas que existen
para identificar requerimientos.
 Ayudar a comprender la diferencia que existe entre las
diferentes técnicas utilizadas en la Ingeniería de
Requerimientos.
 Minimizar las dudas que se tiene sobre los casos de uso.
 Mostrar la utilización de herramientas CASE dentro de la
administración de requisitos.
Problemas de los proyectos de TI
 Causas (Standish Gr.1995)
 Requerimientos incompletos (13.1%)
 Falta de involucramiento de usuarios (12.4%)
 Falta de recursos (10.6%)
 Expectativas no realistas (9.9%)
 Falta de soporte de ejecutivos (9.3%)
 Requerimientos y Especificaciones cambiantes (8.7%)
 Falta de planificación (8.1%)
 Sistema no se precisaba más (7.5%)
Problemas de los proyectos de TI
Problemas comunes debido a personas y procesos

 No se capturan requerimientos
críticos.
 Equipos de trabajo no entendieron
bien el problema del negocio.
 Los requerimientos no cubren las
necesidades del negocio.
 Mal entendimiento de los objetivos
por el equipo de trabajo
Importancia de los requerimientos

“La gerencia de proyectos consiste en

la aplicación de conocimientos,
habilidades, herramientas a las
actividades del proyecto a fin de
lograr los requerimientos del
mismo” (fuente PMBOK).
Importancia de los requerimientos

“Un proceso de desarrollo de software es el

conjunto de actividades necesarias para
transformar los requerimientos de usuario
en un sistema software”

JACOBSON, Ivar; BOOCH, Grady y

RUMBAUGH, James 2000 El proceso
unificado de desarrollo de software,
Addison Wesley
Definiciones
 Requerimiento:
 Descripción de los servicios que debe brindar un
sistema y sus restricciones
 Ingeniería de Requerimientos
 Proceso de descubrir, analizar, documentar y verificar
esos servicios y restricciones
 Entender el problema de los usuarios en SU cultura y con
SU lenguaje y construir el sistema que resuelve sus
necesidades
Requerimiento
 El IEEE define:
 Requisito o Requerimiento como:
 Condición o aptitud necesaria para resolver un
problema o alcanzar un objetivo.
 Condición o facilidad que debe proporcionar un

sistema o algunos de sus subsistemas para

satisfacer un contrato, norma, especificación o
cualquier otra condición impuesta formalmente a
través de un documento.
 Una representación documentada de una condición

o facilidad
Diferentes niveles de descripción
 Requerimientos de Usuario:
 Declaraciones en lenguaje natural y en diagramas de los
servicios que se espera que el sistema provea y de las
restricciones bajo las que cuales debe operar.
Diferentes niveles de descripción
 Requerimientos del Sistema:
 Detalla los servicios y restricciones del sistema.
 Documento de Especificación funcional sirve como contrato
entre el comprador del sistema y el desarrollador de software.
Diferentes niveles de descripción
 Especificación del diseño del software:
 Descripción abstracta del diseño del software que es una base para el
diseño detallado y la implementación.
 Agrega detalle a la especificación de requerimientos del sistema .
Lectores de Requerimientos

Gerencia de Cliente
Requerimientos Usuarios Finales del Sistema
de Usuario Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema

Requerimientos del Usuarios Finales del Sistema

Sistema Ingenieros de Cliente
Arquitectos del Sistema
Desarrolladores de Software

Especificación del (Quizás) Ingenieros de Clientes

diseño del Software Arquitectos del Sistema
Desarrolladores de Software
 Requerimientos Funcionales
 Describen la interacción entre el sistema y su
entorno
 Servicios o funciones que proveerá el sistema
 Ejemplos:
 Se deben ingresar cédula, nombre y teléfono de cada cliente
 Se quiere un listado de los clientes por zona
 Requerimientos No Funcionales
 Restricciones a los servicios o funciones ofrecidos por el sistema
 Describen restricciones que limitan las elecciones para construir una solución
 Ejemplos:
 Las consultas deben resolverse en menos de 3 segundos
 El lenguaje de programación debe ser Java
 Se refieren al sistema como un todo mas que a rasgos particulares del mismo.
 De forma ideal se deben expresar de forma cuantitativa utilizando métricas que se
puedan probar objetivamente.
 Requerimientos No Funcionales
 Del Producto: Especifican restricciones al comportamiento del producto
 Ejemplos: desempeño, confiabilidad, portabilidad, usabilidad

 De la Organización: Se derivan de las políticas y procedimientos existentes en la organización del cliente

y en la del desarrollador
 Ejemplos: estándares, lenguajes de programación, método de diseño

 Externos: Se derivan de factores externos, como:

 Interoperabilidad: con otros sistemas
 Legislativos: privacidad, seguridad
 Éticos: dependen del contexto, las personas, etc
Dificultades para definir los
Requerimientos
 Los requerimientos no son obvios y vienen de muchas fuentes.
 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
 Existen muchos tipos de requerimientos y diferentes niveles de detalle.
 La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
Ingeniería de Requerimientos
Definición:
Rama de la ingeniería del software que trata con
el establecimiento de los objetivos, funciones y
restricciones de los sistemas software.
Asimismo, se ocupa de la relación entre estos
factores con el objeto de establecer
especificaciones precisas.
Ingeniería de Requerimientos
Objetivo:
La obtención de requisitos del sistema que se
desea construir a cierto nivel de abstracción y
cumpliendo ciertas características haciendo de
puente entre el espacio del problema y el espacio
de la solución.
Puntos a considerar en IR
 Objetivos del Negocio y Ambiente de trabajo
 Diferentes puntos de vista de los clientes
 Barreras de comunicación entre clientes y analistas de
requerimientos
 Integración del sistema con otros ya existentes
 Tamaño y complejidad
 Documentación de requerimientos
Personal involucrado
 Usuario Final
 Usuario Líder
 Personal de Mantenimiento
 Analistas y programadores
 Personal de pruebas
 Dependiendo de la magnitud del proyecto
 Administradores de proyecto,
 documentadores,
 diseñadores de BD, etc.
Importancia de la IR
 Permite gestionar las necesidades del proyecto en forma
estructurada: La IR proporciona un punto de partida para
controles y actividades de mantenimiento, tales como
estimación de costos, tiempo y recursos necesarios.

 Disminuye los costos y retrasos del proyecto: Muchos

estudios han demostrado que reparar errores por un mal
desarrollo no descubierto a tiempo, es sumamente caro.
Importancia de la IR
 Mejora la calidad del software: Se busca cumplir un conjunto
de requerimientos (funcionalidad, facilidad de uso, confiabilidad,
desempeño, etc.).

 Evita rechazos de usuarios finales: La ingeniería de

requerimientos obliga al cliente a verificar sus requerimientos y
revisarlos dentro del marco del problema, por lo que se le
involucra durante todo el desarrollo del proyecto.
Importancia de la IR
 Mejora la comunicación entre equipos: La
especificación de requerimientos representa
una forma de consenso entre clientes y
desarrolladores. Si este consenso no ocurre, el
proyecto no será exitoso
Técnicas utilizadas en
la Ingeniería de
Requerimientos
Técnicas utilizadas en la Ingeniería
de Requerimientos
 Su objetivo es obtener los requisitos
 Se eligen según el proyecto a desarrollarse

1) Entrevistas y Cuestionarios
2) Tormenta de Ideas
3) Prototipos
4) Casos de Uso
Entrevistas y Cuestionarios

- Consiste en que el analista formule preguntas relacionadas

con varios aspectos de sistemas.
- En general a:

- usuarios de sistemas existentes

- futuros usuarios
- gerentes
- empleados
- Son útiles las Preguntas Abiertas
Entrevistas y Cuestionarios
Ejemplos de Preguntas Abiertas:
 Del Usuario
 ¿Quién es el cliente?
 ¿Quién es el usuario?
 ¿Son sus necesidades diferentes?
 Del Proceso
 ¿Cuál es la razón por la que se quiere resolver este problema?
 ¿Cómo usted resuelve el problema actualmente?
 ¿Qué retrasos ocurren o pueden ocurrir?
 Del Producto
 ¿Qué problemas podría causar este producto en el negocio?
 ¿En qué ambiente se usará el producto?
 ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable,
rendimiento?
 ¿Qué obstáculos afectan la eficiencia del sistema?
Entrevistas y Cuestionarios

Ventajas: Desventajas:
- Se obtienen - La información obtenida

información correcta al principio puede ser

redundante o
- Sirven de pantallazo
incompleta.
- Son flexibles - Requiere mucha
- Permiten combinarse organización si hay que
con otras técnicas manejar mucha
información
Tormenta de ideas (brainstorming)
Se comenzó a utilizar en empresas para:
 encontrar nuevas ideas , nuevos métodos
 futuros productos
 desarrollar el pensamiento creativo a todos
los niveles
y se extendió al mundo del desarrollo de
sistemas
Tormenta de ideas (brainstorming)
 Los principales stakeholders se juntan en un cuarto
 Se establece el objetivo:
 Que características esperan en el producto?
 Que servicios esperan que provea?
 Los objetivos permiten decidir cuando terminar
 Se pide que cada participante escriba sus ideas, luego las
ideas son leídas para que otros piensen en ideas
relacionadas y de esa forma las ideas mutan y se combinan
Tormenta de ideas (brainstorming)
 Reglas: No hay que detenerse en pensar si la idea es o no
del todo utilizable.
 La intención es generar, en una primera instancia, muchas
ideas. Luego, se irán eliminando en base a distintos criterios
como, por ejemplo, "caro", "impracticable", "imposible", etc.
 Equipo:
 Director
 Secretario
 Personas involucradas en el proyecto
Tormenta de ideas (brainstorming)
 El secretario lee cada idea y pregunta si es válida
 Si hay cualquier desacuerdo, la idea se queda
 Agrupamiento de ideas
 Nombrar los grupos
 Definición
 Se escribe una breve descripción de lo que la idea
significa para la persona que la escribió
 Ayuda a tener un entendimiento común del requerimiento
 Lleva unos minutos por idea
Tormenta de ideas (brainstorming)
Fases (1):
- Descubrir hechos:
 Comunicar con anticipación los temas a tratar
 Explicar los principios de una tormenta de
ideas
 Hablar unos 10’ de temas sencillos y no
comprometido
 Determinar y plantear el problema.
 Dividirlo en partes (si es complejo)
-
Tormenta de ideas (brainstorming)
Fases (2):
- Producir ideas (la tormenta propiamente dicha)
- Producir gran cantidad de ideas (según los principios vistos)
- Fin de reunión y próxima reunión
- Descubrir soluciones:
 Elaborar una lista definitiva de ideas y seleccionar las mas
interesantes
 Ponderar las más útiles
 Clasificarlas
 Presentarlas de forma atractiva (ej: en soporte visual)
Tormenta de ideas (brainstorming)

Ventajas: Desventajas
- Los expertos pueden - Es necesaria una
introducir y unificar buena
terminología para
compenetración de
que todos las usen
todos
para expresar las
nuevas ideas.
Prototipos
 Para validar los requerimientos hallados, se
construyen prototipos.
 Los prototipos son simulaciones del posible producto,
que luego son utilizados por el usuario final
 Permiten conseguir una importante retroalimentación
en cuanto a si el sistema diseñado en base a los
requerimientos recolectados le permite al usuario
realizar su trabajo de manera eficiente y efectiva.
 Facilita la comprensión del desarrollador.
 Prototipos
 Prototipo rápido: Mecanismo para lograr
validación pre-compromiso
 Se utiliza para validar requerimientos en una etapa
previa al diseño específico
 También podemos llevar el caso de uso y
bosquejar la interfase de usuario y, mediante el
diálogo, manejamos la interactividad entre el
usuario y el sistema.
 Prototipos
 Prototipo evolutivo: Es implementado sobre la
arquitectura del producto final, el sistema final se
obtiene de evolucionar el prototipo
 Modificaciones y mejoras subsecuentes resultan en
nuevas entregas de prototipos más maduros. Este
proceso continúa hasta que se haya desarrollado el
producto final.
 Todo el ciclo de vida de un producto puede ser visto
como una serie incremental de prototipos.
Prototipos
Desventajas
Ventajas:  El cliente puede llegar a pensar
- Ayudan a validar y que el prototipo es una versión
desarrollar nuevos del software que será
desarrollado.
req.  A menudo, el desarrollador
- Ayudan a hace compromisos de
implementación para acelerar el
comprender req. desarrollo del prototipo
que no están muy
claros.
Mismos datos, pero…

Ingrese Julio 1998

año: ____

mes: ____

día: ____

1998 2025

1 31

Ene Dic
Martes 16 Oct. 2002
Casos de Uso
 Un caso de uso representa una
interacción típica entre un usuario y un
sistema informático.
 La descripción se centra en lo que debe
hacerse, no en la manera de hacerlo.
 No son exclusivos del mundo de OO,
pueden ser utilizados en proyectos que
sigan cualquier metodología de desarrollo
Casos de Uso
 Los casos de uso sólo consideran los
requisitos funcionales del proyecto, hay que
añadir los no funcionales en la descripción.

 Dirigen todo el proceso de desarrollo puesto

que la mayoría de actividades (planificación,
análisis, diseño, validación, test,..) se realizan
a partir de los casos de uso.

 Mecanismo importante para soportar la

“trazabilidad” entre modelos.
ACTOR
 Un actor representa un conjunto
coherente de roles que juegan los
usuarios de los casos de uso al
interaccionar con el sistema.
 Roles jugados por personas,
dispositivos, u otros sistemas.
 No forman parte del sistema
 Inician la ejecución de los casos de uso
CASO DE USO

 Un caso de uso es una descripción de la

secuencia de interacciones que se produce
entre un actor y el sistema, cuando el
actor usa el sistema para llevar a cabo una
tarea especifica.
 El nombre del caso de uso debe reflejar la
tarea especifica que el actor desea llevar a
cabo usando el sistema
Relación de tipo Include
 Es una relación de dependencia entre dos
casos de uso. El caso de uso base, depende
del caso de uso incluido.
 El caso de uso incluido no puede ejecutarse
sin el caso de uso que lo incluye, y no
puede ser iniciado de forma independiente
por el usuario
 Se utiliza para extraer un comportamiento
común a dos casos de uso y para simplificar
un caos de uso complejo.
Relación de tipo Extend
 Es una relación de dependencia entre dos
casos de uso. El caso de uso extendido,
depende del caso de uso base.
 Se ejecuta el caso de uso base, pero bajo
ciertas condiciones llama a otro caso de uso
que extiende su comportamiento.
 Se utiliza para modelar la parte del caso de
uso que tiene un comportamiento opcional,
es decir bajo ciertas condiciones.
 Diagramas de Casos de Uso
Límite Sistema de Pub

extiende Informar Bodega

Sistema de
Bodega

«extend»

incluye
Vender Bebida
caso
Barmen de uso
«include»

Registrar Venta

actor
Ejemplo de relaciones Include-Extend

<<extends>>
Giro por Internet

Cliente

<<includes>>
Giro

Identificación
Plantilla para casos de uso
Caso de Uso identificador / historia
Descripción objetivo a conseguir
Actores lista de actores
Asunciones Condiciones que deben cumplirse
Pasos interacciones entre los actores y el sistema
necesarias para obtener el objetivo
Variaciones (opcional) cualquier variación en los pasos
No-funcional (opcional) lista requisitos no funcionales
Casos de Uso
Ventajas: Desventajas
- Representación de  En sistemas grandes,

req. desde el punto toma mucho tiempo

de vista del usuario definir todos los casos
- Más de un rol para de uso.
 El análisis de calidad
cada afectado
depende de la calidad
con que se haya
hecho la descripción
inicial.
El Proceso de
Ingeniería de
Requerimientos
 Proceso de IR
 Existen cuatro actividades genéricas de alto nivel:
 Estudio de Factibilidad
 Obtención y Análisis de Requerimientos
 Especificación de Requerimientos
 Validación de Requerimientos

 Debido a que los requerimientos cambian por diferentes

factores se tiene una actividad adicional llamada
Administración de Requerimientos, que se refiere a la
administración de cambios en estos.
Actividades de la IR
Ingeniería de Requerimientos

Proceso de los
Administración de
Requerimientos
los Requerimientos

Línea Base de Reqs

Estudio de
Planificación
Factibilidad

Obtención y Especificación Administración

Análisis de del Cambio
de
Reqs Reqs

Validación
de Cambios En Reqs
Reqs
Cambios en el
proyecto
Proceso de IR
 Estudio de Factibilidad
 Encuentran los usuarios actuales que sus necesidades son satisfechas
dada la tecnología y el presupuesto disponible?
 Obtención y Análisis de Requerimientos
 Comprensión del dominio, recolección, clasificación y priorización de
requerimientos.
 Especificación de Requerimientos
 Define los requerimientos en detalle.
 Validación de Requerimientos
 Demostración de que los requerimientos que definen el sistema son lo que
el cliente realmente quiere.
 Proceso de IR
Actividade
s

Obtención y Especificación Validación

Estudio de
Análisis de de de
factibilidad
Requerimientos Requerimientos Requerimientos

Artefactos

Informe Modelo del Especificación

de Sistema de
factibilidad Requerimientos
Estudio de Factibilidad
 Estudio corto para resolver si es posible y
conveniente construir el sistema con la tecnología
existente, las restricciones de costo y tiempo, etc.
 Informe de Factibilidad:
 Documento donde se recomienda si seguir con
el sistema, proponiendo cambiar el alcance,
presupuesto, agenda, etc.
 Proceso de IR
Actividade
s

Obtención y Especificación Validación

Estudio de
Análisis de de de
factibilidad
Requerimientos Requerimientos Requerimientos

Artefactos

Informe Documento Modelo del Especificación

de de Sistema de
factibilidad Requerimiento Requerimientos
s
Obtención & Análisis de Requerimientos
 Se trabaja en conjunto con los usuarios y clientes
 Problemas comunes:
 No saben lo que quieren del sistema, sólo en términos
generales, no conocen el costo de sus peticiones
 Los requerimientos están en sus términos y con conocimiento
implícito de su propio trabajo
Obtención & Análisis de Requerimientos
 Problemas comunes:
 Distintos usuarios tienen distintos requerimientos, se
deben encontrar todas las fuentes
 Influyen factores políticos
 La importancia de los requerimientos varía con el tiempo
 Aparecen nuevos requerimientos
Obtención de Requerimientos
 Técnicas :
Investigarantecedentes
Entrevistas individuales/grupales
Encuestas/Cuestionarios
Tormenta de ideas
Workshop
Casos de Uso
Prototipado
Investigar antecedentes
 Estudio, muestreo, visitas,…
 Buena forma de comenzar un proyecto
 Interna:
 Estructurade la organización, Políticas y
procedimientos, Formularios e informes,
Documentación de sistemas
 Externa:
 Publicacionesde la industria y comercio,
Encuentros profesionales, Visitas, Literatura y
presentaciones de vendedores
Investigar antecedentes
 Ventajas  Desventajas
 Ahorra tiempo  Perspectiva limitada
de otros  Desactualizado
 Prepara para  Demasiado genérico
otros enfoques
 Puede llevarse a
cabo fuera de la
organización
 Entrevista individual/grupal
 Usado para:
 Entender el problema de negocio
 Entender el ambiente de operación
 Evitar omisión de requerimientos
 Mejorar las relaciones con el cliente

 Ventajas
 Orientado a las personas
 Interactivo/flexible

 Desventajas
 Costoso
 Depende de las habilidades interpersonales
Encuesta - Cuestionario
 No substituye la entrevista
 Antes de usar el enfoque:
 Determinar la información que se precisa
 Determinar el enfoque más adecuado:
 Abierto, cerrado, combinado
 Múltiple opción, valor en escala, orden relativo
 Desarrollar cuestionario
 Probarlo con perfil típico
 Analizar resultado de las pruebas

 Su principal uso es para validar asunciones y obtener

datos estadísticos sobre preferencias
Encuesta - Cuestionario
 Ventajas  Desventajas
 Economía de  Problemas por
escala no-respuesta
 Conveniente para  Esfuerzo de
quien contesta desarrollo
 Respuestas
anónimas
Observación/Participación
 Poco utilizado…
 Antes de usarlo
 Determinar información necesaria
 Comunicar a los involucrados
 Considerar períodos normales y atípicos
 Planificar las anotaciones

 Ventajas  Desventajas
 Confiable  Tener cuidado con
 Muy rico en generalizar demasiado
datos (sesgo particular/local)
 Desarrolla
empatía
Tormenta de ideas (brainstorming)
 Objetivo: Lograr consenso sobre los requerimientos
 Ayuda a la participación de todos los involucrados
 Permite pensar en otras ideas
 Un secretario saca notas de todo lo discutido
 Reglas
 No se permite criticar ni debatir
 Dejar volar la imaginación
 Generar tantas ideas como sea posible
 Mutar y combinar ideas
Sesiones de trabajo (Workshop)
 Ámbito para las tormentas de ideas
 Preparación
 Asegurarse que asisten los stakeholders correctos
 Enviar material previo a la reunión
 Doc de requerimientos
 Entrevistas, bugs de los sistemas existentes, etc
 Asegurarse de enviar lo necesario, sin exagerar
 Organizar la Agenda
 Introducción
 Tormenta de ideas
 Priorización
 Conclusiones
Casos de Uso
 Formato simple y estructurado donde los usuarios
y desarrolladores pueden trabajar juntos
 No son de gran ayuda para identificar aspectos no
funcionales
 Mientras se definen los casos de uso, puede ser
un buen momento para definir pantallas u otros
objetos con los que el usuario interactúa
 Pueden ser usados en el diseño y en el testing del
sistema
Prototipado
 Implementación parcial que permite a los
desarrolladores y usuarios:
 entender mejor los requerimientos
 cuales son necesarios, deseables
 Acotar riesgos

 Los prototipos son simulaciones del posible producto,

que permiten conseguir una importante
retroalimentación sobre si el diseño le permite al
usuario realizar su trabajo de manera eficiente y
efectiva .
 Proceso de IR
Actividade
s

Obtención y Especificación Validación

Estudio de
Análisis de de de
factibilidad
Requerimientos Requerimientos Requerimientos

Artefactos

Informe Modelo del Especificación

de Sistema de
factibilidad Requerimientos
Especificación de Requerimientos

 Objetivo:
 Se sigue una serie de buenas prácticas para
escribir especificaciones de requerimientos de
software (SRS).

 Se describen los contenidos y las cualidades

procurando una buena especificación de
requerimientos.
Participantes en el Proceso de
Especificación de Requerimientos
 Cliente y Usuarios
 Requerimientos adecuados a sus necesidades
 Diseñadores
 Comprenderlos para lograr diseño que los satisfaga
 Supervisores del Contrato, sugieren:
 Hitos de Control, cronogramas
 Gerentes del Negocio, entienden:
 Impacto en la Organización
 Verificadores
 Comprenderlos para poder verificar si el sistema los satisface
Características deseables
Especificación IEEE 830
 Correctos: Todos los requerimientos son requeridos en
el sistema
 No existe herramienta que asegure esto
 Debe ser revisado por el cliente y desarrolladores
 Revisado contra otros documentos existentes
 No Ambiguos: Tiene una única interpretación
Características deseables
Especificación IEEE 830
 Completos: Define todos los requerimientos
asociados con funcionalidad, desempeño,
restricciones de diseño, atributos o interfaces
externas
 Consistentes:No son contradictorios entre sí

 Priorizados por Importancia y estabilidad

 Otraforma de priorizar:
Esencial/Condicional/Opcional
Características deseables
Especificación IEEE 830
 Verificables: Un requerimiento es verificable si
existe un proceso finito para determinar que el
sistema lo cumple
 Requerimientos ambiguos no son verificables
 Preparar pruebas para demostrar que se cumplen

 Modificables: Su estructura y estilo son tales que

cualquier cambio en los requerimientos puede
ser hecho fácilmente en forma completa y
consistente
Características deseables
Especificación IEEE 830
 Trazables: El origen de cada requerimiento es
claro, y es posible seguirle la pista en futuros
desarrollos o mejora de la documentación
 Realistas
 Ej.: tiempo de respuesta local=remoto
 Ej.: El cliente quiere adelantarse a la tecnología
 Entendibles: Tanto por los usuarios como por los
desarrolladores
 Proceso de IR
Actividade
s

Obtención y Especificación Validación

Estudio de
Análisis de de de
factibilidad
Requerimientos Requerimientos Requerimientos

Artefactos

Informe Modelo del Especificación

de Sistema de
factibilidad Requerimientos
Modelado del Sistema
 Tablas de Decisión
 Diagramas de Transición de Estados
 Diagramas de Flujo de Datos (DFD)
 Casos de Uso
 UML
 Diagramas de Casos de Uso
 Diagramas de Actividad
 Diagramas de estado
 Diagrama de clases
 Modelo Conceptual
Tipos de Diagramas
 Modelo Estático

 Construye y documenta los aspectos estáticos de un

sistema.
 Crea una representación de los principales elementos
del dominio del problema
 Se compone de:
 Diagramas de Casos de Uso

 Diagramas de Clases

 Diagramas de Componentes

 Diagramas de Despliegue
Tipos de Diagramas
 Modelo Dinámico

 Crea los diagramas que muestran el

comportamiento de un sistema
 Se compone de los siguientes diagramas:

 Diagramas de Secuencia
 Diagramas de Colaboración

 Diagramas de Transición de Estados

 Diagramas de Actividad
 Proceso de IR
Actividade
s

Obtención y Especificación Validación

Estudio de
Análisis de de de
factibilidad
Requerimientos Requerimientos Requerimientos

Artefactos

Informe Modelo del Especificación

de Sistema de
factibilidad Requerimientos
 Especificación de Requerimientos
 El análisis y desarrollo de requerimientos tiene como
producto final: un acuerdo documentado entre el
cliente y el grupo de desarrollo acerca del producto a
ser construido.
 El documento es conocido como: Especificación de
Requerimientos del Software (SRS), Especificación
Funcional o Especificación del Sistema.
Especificación de Requerimientos
 El documento establece con precisión las
funciones y capacidad del software así como sus
restricciones.
 El ERS es la base para toda subsecuente
planificación, diseño, y codificación, así como
para las pruebas del software y documentación
del usuario.
Especificación de Requerimientos
 El SRS (Software Requirements
Specification) puede estar formado por:
 Diagrama de casos de uso
 Modelo del dominio (modelo conceptual)
 Para cada caso de uso:
 Descripción textual (usando una
plantilla)
 Descripciones de las interfaces de
usuario
 Requisitos no funcionales
IEEE Std 830 - Contenido
recomendado
 1. Introducción
 1.1 Propósito
 Establece el propósito de este documento así
como la audiencia para el mismo.
 1.2 Alcance
 a) Identificar el producto SW a ser producido
por nombre.
 b) Explicar en que se aplicara el producto SW,
beneficios, objetivos, metas.
 1.3 Definiciones, siglas y abreviaciones
IEEE Std 830 - Contenido
recomendado
 1.4 Referencias
 Proveer una lista completa de todos los
documentos referidos en el resto del
documento, así como sus fuentes.
 1.5 Vista General / Resumen
 Describir lo que contiene el resto del
documento así como su organización.
IEEE Std 830 - Contenido
recomendado
2. Descripción General
Esta sección debe describir los factores generales que afectan al
producto y sus requerimientos. Esta sección no establece
requerimientos específicos, establece los antecedentes para ellos.
2.1 Perspectiva del Producto
Poner en perspectiva al producto con otros
relacionados. Si el producto es independiente y auto-
contenido, debe ser especificado de esa manera.
2.1.1 Interfaces del Sistema
2.1.2 Interfaces con el usuario
2.1.3 Interfaces con el hardware
2.1.3 Interfaces con otros software
2.1.4 Interfaces con dispositivos de comunicación
2.1.5 Operaciones
IEEE Std 830 - Contenido
recomendado
2. Descripción General (cont.)
2.2 Funciones del Producto
Esta sub-sección debe incluir un resumen de todas las funciones principales
que realizara el software sin incluir la gran cantidad de detalles que cada una
de esas funciones requiere.
2.3 Características del Usuario
Detallar las características generales de cada tipo de usuario incluyendo nivel
de educación, experiencia, y nivel de aptitud técnica.
2.4 Restricciones
Incluir una descripción general de cualquier aspecto que limitara la opciones
del desarrollador.
2.5 Suposiciones y dependencias
Listar cada uno de los factores que afecta n los requerimientos
establecidos en este documento. Estos factores no son restricciones
de diseño para el software.
IEEE Std 830 - Contenido
recomendado
 3 Requerimientos Específicos
Esta sección del ERS debe contener todos los requerimientos de software
hasta un nivel de detalle suficiente como para permitir a los diseñadores
diseñar el sistema que satisfaga esos requerimientos, y a los especialista en
pruebas para comprobar que el sistema satisfaga esos requerimientos.

Cada requerimiento establecido en esta sección debe ser percibido

externamente por un usuario, operador u otro sistema externo.
IEEE Std 830 - Contenido
recomendado
3. Requerimientos específicos
3.1 Interfaces Externos
Esta debe ser una descripción detallada de todas las entradas
y salidas del sistema software. Deberá complementar la
descripción de interfaces en la sección 2 y no repetir la
información en esa sección.
3.1.1 Interfaces de usuario
3.1.2 Interfaces de Hardware
3.1.3 Interfaces de Software
3.1.4 Interfaces de comunicación
IEEE Std 830 - Contenido
recomendado

3.2 Característica del Sistema

3.2.1 Caso de Uso 1
3.2.1.1 Introducción/Propósito
3.2.1.2 Secuencia Estimulo/Respuesta
3.2.1.3 Requerimientos funcionales asociados
3.2.1.3.1 Requerimiento Funcional 1 (El sistema deberá ...........)
……..
3.2.1.3.n Requerimiento Funcional n
……
3.2.m Caso de Uso m
IEEE Std 830 - Contenido
recomendado
3.3 Requerimientos de rendimiento
Especificar los requerimientos numéricos estáticos y dinámicos puestos en el
producto software.
(Ej. Número de terminales soportadas, usuarios simultáneos, cantidad de info., etc.)
3.4 Restricciones de diseño
Especificar restricciones de diseño que pueden ser impuestas por otros estándares,
limitaciones de hardware, etc.
3.5 Atributos del sistema Software
Atributos del sistema que son especificado como requerimientos para poder ser
objetivamente evaluados.
3.6 Otros requerimientos
Proceso de IR
Actividade
s

Obtención y Especificación Validación

Estudio de
Análisis de de de
factibilidad
Requerimientos Requerimientos Requerimientos

Artefactos

Informe Modelo del Especificación

de Sistema de
factibilidad Requerimientos
Validación de Requerimientos
 Proceso por el cual se determina si la
especificación es consistente con las necesidades
del cliente
 Incluye verificar trazabilidad entre la
especificación y el documento de requerimientos
 El Prototipado es una técnica importante de la
validación de requerimientos.
Validación de Requerimientos
 Demostración de que los requerimientos
que definen el sistema son lo que el
cliente realmente quiere.
 Los costos de errores en los
requerimientos son altos, por lo cual, la
validación es muy importante.
 Fijarun error de requerimiento después del
desarrollo puede resultar en un costo 100
veces mayor que fijar un error en la
implementación.
Validación de Requerimientos
 Se realizan las siguientes verificaciones en el
documento de requerimientos:
 Validez: compromiso con el usuario, que valide que es lo
que quiere
 Consistencia: que no haya contradicciones
 Realismo: que se puedan implementar (incluye:
tecnología, presupuesto y calendario)
 Verificabilidad: Diseñar conjunto de pruebas para
demostrar que el sistema cumple esos requerimientos
Verificar características del SRS
 ¿Están incluidas todas las funciones requeridas
por el cliente? (completa)
 ¿Tiene alguno de los requerimientos más de una
interpretación? (no ambigua)
 ¿Está cada requerimiento claramente
representado? (entendible)
 ¿Pueden los requerimientos ser implementados
con la tecnología y el presupuesto disponible?
(factible)
 ¿Está claramente definido el origen de cada
requisito? (rastreable)
 ¿Pueden los requerimientos ser sometidos a
medidas cuantitativas? (verificable)
Verificación de requerimientos NO
funcionales
 Son difíciles de verificar
 Se deben expresar de manera
cuantitativa utilizando métricas que se
puedan probar de forma objetiva ( esto
es IDEAL)
 Para los usuarios es difícil especificarlos
en forma cuantitativa
Verificación de requerimientos NO
funcionales
Propiedad Medida
Rapidez Transacciones por seg
Tamaño KB
Fiabilidad Tiempo promedio entre fallas
Robustez Probabilidad de datos corruptos después de
la falla
Portabilidad Número de sistemas
Facilidad de Tiempo de capacitación
uso
Administración de
Requerimientos
Administración de los Requerimientos
 Los requerimientos cambian, debido a:
 Muchos usuarios
 Quienes pagan por el sistema y los usuarios
no son las mismas personas
 Cambios en el negocio
 Cambios en la tecnología

 Proceso de comprender y controlar los

cambios en los requerimientos del sistema
Administración de los Requerimientos
 Se lleva a cabo junto con los otros
proceso de ingeniería de Reqs, dos
etapas:
 Planificación: Se realiza al comenzar el
análisis de reqs
 Administración del cambio : Comienza
una vez que se tiene una primera versión
del documento de requerimientos
Planificación
 Proceso de Administración del cambio:
Actividades que evalúan el impacto y costo del
cambio
 Políticas de rastreo: Cómo se registra y como
se mantiene
 Herramientas CASE: Definir uso para
 Almacenar los requerimientos
 Administrar el cambio
 Administrar el rastreo
Administración del cambio
 Etapas:
1. Especificación del cambio
2. Análisis del cambio y costo: Se usa la informacion del
rastreo, costo en términos de modificaciones:
 Al documento de reqs
 Al Diseño e implementacion
1. Implementar el cambio: se modifican los artefactos
necesario:
 Todos los cambios se tratan en forma consistente
 Los cambios al doc de reqs se hacen en forma controlada
Gestión de
Requerimientos
según RUP y CMMI
Modelo CMMI

 Capability Maturity Model Integration.

 Modelo para la mejora o evaluación de los
procesos de desarrollo y mantenimiento de
sistemas y productos de software.
 Desarrollado por el Instituto de Ingeniería del
Software de la Universidad Carnegie Mellon
(SEI), y publicado en su primera versión en
enero de 2002.
 Para los usuarios es difícil especificarlos en
forma cuantitativa
Modelo CMMI

 CMMI se desarrolló para facilitar y simplificar la

adopción de varios modelos de forma
simultánea, y su contenido integra y da relevo
a la evolución de sus predecesores:
 CMM-SW (CMM for Sofwtare)
 SE-CMM(Systems Engineering Capability Maturity
Model)
 IPD-CMM(Integrated Product Development)
 CMMI – Niveles de Madurez
NIVEL Descripción
1-Inicial Punto base. La organización tiene procesos ad-hoc o caóticos. El
éxito se debe a personas heroícas.
2-Repetible La organización empieza a guardar información. Ya hay
definiciones, pueden repetirse éxitos anteriores.

3-Definido Se conocen procesos estándares para desarrollar o mantener

software. Hay prácticas de Ingeniería de Software y de
Administración de procesos.

4-Administrado Se usan datos recolectados. Las decisiones están basadas en

datos cuantitativos. Los procesos son medidos, hay
retroalimentación.
5-Optimizado La organización se dedica a mejorar contínuamente. Se localizan
debilidades y fortalezas.
 CMMI
Areas Clave de Proceso (KPAs)
NIVEL Áreas Clave de Proceso
1-Inicial
2-Repetible Gestión de Requisitos (REQM), Planificación de proyecto,
Monitorización y control de Proyectos, Gestión y acuerdo de
suministros, Medición y Análisis, Gestión de la calidad de procesos
y productos, Gestión de la configuración
3-Definido Desarrollo de requisitos (RD), Solución técnica, Verificación,
Validación, Integración de producto, Procesos orientados a la
organización, Formación, Gestión Integrada de proyecto, Gestión
de riesgos, Análisis y resolución de decisiones

4-Administrado Gestión cuantificada de proyectos, Rendimiento de los procesos de

la organización
5-Optimizado Innovación y desarrollo
RD vs REQM
Gestión de requisitos (REQM)

Asegurar que los requerimientos son consistentes a lo largo del ciclo de vida.


Desarrollo de requisitos (RD)


Generar una lista de servicios a ser desarrollados (cliente)

Generar una lista de requisitos de producto (técnicos)

Validar ambas listas de requisitos.

CMMI-Gestión de requisitos (REQM)
Propósito: Gestionar los requisitos del producto y de componentes del producto del proyecto e identificar inconsistencias entre los requisitos, los planes y los resultados de trabajo.

CMMI–Desarrollo de Requisitos (RD)

Propósito: Producir y analizar los requisitos del cliente, del producto y de los componentes de producto.
Rational Unified Process
“RUP es un marco de trabajo genérico que puede
especializarse para una variedad de tipos de
sistemas, diferentes áreas de aplicación, tipos de
organizaciones y diferentes tamaños de proyectos”.

JACOBSON, Ivar; BOOCH, Grady y

RUMBAUGH, James 2000 El proceso
unificado de desarrollo de software,
Addison Wesley
 Rational Unified Process
Fases
Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición

Modelación de Negocios
Requerimientos
Análisis y Diseño
Implementación
Contenido
Prueba
Desarrollo
Flujos de Trabajo de Soporte

Admin. Configuración
Administración
Ambiente
Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminar #1 #2 #n #n+1 #n+2 #m #m+1

Iteraciones
RUP - Workflow de Requerimientos
 El diagrama de actividad presenta el flujo
lógico donde los trabajadores ejecutan
actividades, crean y modifican artefactos
 En el mundo real no es necesario trabajar
en secuencia
 Todos los artefactos se completan y
mejoran incrementalmente en cada
iteración.
RUP - Workflow de Requerimientos
 Actividades
Analizar el Problema
Entender las Necesidades de Stakeholder
Definir el Sistema
Administrar el Alcance del Sistema
Refinar la Definición del Sistema
Administrar Cambios de Requerimientos
RUP - Workflow de Requerimientos
RUP - Workflow de Requerimientos
Especificador de Diseñador de
Analista Arquitecto Casos de uso interface
RUP - Workflow de Requerimientos
 Encontrar actores y casos de uso: Esbozar que actores
interactuarán con el sistema, y que funcionalidad se espera.
 Priorizar Casos de Uso: Determinar que casos de uso son
necesarios en las primeras iteraciones y cuáles pueden
dejarse para más tarde. Considerar aspectos no técnicos
 Detallar un Caso de Uso: Describir su flujo de sucesos en
detalle, flujo básico, flujo alternativo, pre y post condiciones.
Se puede utilizar diagramas de actividad o de interacción
RUP - Workflow de Requerimientos
 Prototipar la interfaz de Usuario: Se realiza el
diseño lógico de la interfaz de usuario, luego el
diseño físico y se construye el prototipo con
apoyo de alguna herramienta.
 Estructurar el modelo de Casos de Uso:
Extraer descripciones de funcionalidad (de casos
de uso) generales y compartidas que puedan ser
utilizados por descripciones (de casos de uso)
más específicas.
Conclusiones
 La IR es una actividad que involucra a clientes, usuarios, equipo de
desarrollo, administradores de proyectos, etc.; por lo tanto, el
proceso de IR no depende solamente de la forma en cómo se
percibe el problema, sino también, del nivel de experiencia que
tengan los involucrados.
 Es importante tomarse el tiempo necesario para conocer a
nuestros clientes y usuarios, para establecer una buena relación
de trabajo y comunicación entre el equipo de desarrollo y los
clientes
Conclusiones
 Los errores en los requerimientos son usualmente muy
caros de corregir una vez desarrollado el sistema.
 La revisión debe involucrar al cliente y al staff de
contratistas para validar los requerimientos del sistema.
 El establecer requerimientos está relacionado con las
actividades del cliente para el Software.
Bibliografía
G. Booch, J. Rumbaugh, I. Jacobson, “El lenguaje unificado de
modelado”, Addison-Wesley, 1999.
Sommerville I., Software Engineering, , Addison-Wesley, 2002.
Brackett, Jhon W. "Software Requirements". Software Engineering
Institute Education Program – Carnegie Mellon University.
C. Larman, “UML y Patrones: Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, Prentice-Hall, 2003.