Ingeniería de Requerimientos

Estableciendo lo que el cliente

requiere de un Sistema de
Software.
Requerimientos
 Que funcionalidad se le pide a este sistema ?

Base de Datos
Del Banco Análisis
de Riesgos

Lector de
Interfase Hombre-Maquina
Tarjeta de Crédito
Sistema de
Pantalla ° Teclado
Comunicaciones
del Banco

Sistema de
Control del
Cajero Automático

•Cliente
•Representante
del Banco Sistemas de Control y
•Personal de Sistema de
Mantenimiento Conteo de Billetes Comunicaciones
Ingeniería de Requerimientos

 El proceso de establecer los servicios que el cliente

requiere de un sistema y los limites bajo los cuales opera y
se desarrolla.
 Las malas o ineficientes prácticas de la Ingeniería de
Requerimientos llevan invariablemente al fracaso del
desarrollo del software, y pueden ser más costosas,
dependiendo de que tan tarde estas son descubiertas en el
proceso de desarrollo.
 Es necesaria una disciplina en el desarrollo de software y
en particular en el proceso de Ingeniería de
Requerimientos a fin de evitar que el desarrollo de
software falle o que sufra de costos excesivos.
Ingeniería de Requerimientos

 El éxito de un sistema de software se mide de acuerdo al grado con

que este y su proyecto de desarrollo cumplen con el objetivo para el
cual fueron requeridos.
 El problema del desarrollo de los sistemas de software es que los
requerimientos son inherentemente dinámicos.
 Los cambios ocurren constantemente y esto se de debe ase deben a: Estos
cambios por mejoras,
 cambios por errores descubiertos, cambios por adopción de nuevas
tecnologías,
 cambios por mejoras en la comprensión del sistema, entre otros.
 El proceso de Ingeniería de Requerimientos debe ser preciso y flexible
a la vez.
 Preciso por que debe incluir todos los requerimientos del cliente y del
ambiente donde este estará operando.
 Flexible, ya que los requerimientos están sujetos a constantes cambios.
¿Qué es un Requerimiento?
 Puede variar desde unos estatutos abstractos en alto
nivel de un servicio o unas restricciones del sistema hasta
una especificación funcional matemática detallada.

 Los Requerimientos pueden servir como una función dual

 Puede ser la base para la declaración de un contrato, por lo
tanto, deber estar abierto a interpretación.
 Puede ser la base para el contrato en sí, por lo tanto, debe ser
definido en detalle.
 Ambas declaraciones serán llamadas Requerimientos.
¿Qué es un Requerimiento?

 Un requerimiento de software define las funciones,

capacidades o atributos de cualquier sistema de software.
 También representan:
 Factores de calidad del sistema que permitirán evaluar su
utilidad a un cliente o usuario.
 Los datos de entrada al proceso de desarrollo de software
y representan lo que se requiere implementar.
 Una descripción de cómo el sistema deberá comportarse,
describe información del dominio de la aplicación, describe
restricciones de la operación del sistema y especifica
atributos ó propiedades del sistema.
 Un problema por resolver.
¿Qué es un Requerimiento?
 No se deben incluir aspectos de diseño, que especifiquen
como deben implementarse tales requerimientos, ni detalles
de planeación del proyecto o de las pruebas.
 Es importante separar lo que se requiere (que se detalla con
los requerimientos) de como se requiere que el sistema sea
diseñado (que se detalla en la etapa del diseño).
 Todo software tiene requerimientos que lo definen y quizás la
parte más difícil de la construcción del software es la decisión
de que es lo que se debe construir
¿Qué es un Requerimiento?
 Los Requerimientos pueden ser Funcionales o No-
Funcionales
 Los Requerimientos funcionales describen servicios o
funciones
 Los Requerimientos No-funcionales son un límite en el sistema
o en el proceso de desarrollo.
 Requerimientos de Dominio
 Requerimientos que se obtienen de el dominio de la
aplicacion del sistema y que reflejan sus caracteristicas.
Ingenieria de Requerimientos: Pasos
principales

1. Entender el problema: definicion

2. Describir el problema: especificacion
3.Verificar la naturaleza del problema: validacion
4. Ponerse de acuerdo en los limites del problema:
negociacion

Este es un proceso iterativo

Marco del proceso de
requerimientos

especification

definicion doc & admon validacion

negociacion
Caracteristicas de los requerimientos
 En principio los requerimientos deben ser precisos,
completos y consistentes.
 Precisos
 Deben extraer con precision lo que se desea del sistema
 Completos
 Deben incluir todas las descripciones y componentes
requeridos
 Consistente
 No debe haber conflictos o contradicciones en las
descripciones de los requerimientos
 En la practica es dificil producir un documento con
estas caracteristicas.
Requerimientos Definición/Especificación
 Definición de Requerimientos
 Una declaración en un Lenguaje Natural incluye los diagramas
de los servicios del sistema y sus límites operacionales. Escrito
para clientes.
 Especificación de Requerimientos
 Un documento estructurado con descripción o detalle de los
servicios del sistema. Escrito como un contrato entre el cliente
y el contratista.
 Especificación de Software
 Descripción detallada de software, la cual, puede servir como
una base para diseño o implementación. Escrito para
desarrolladodres.
Definiciones y Especificaciones
Definición de Requerimientos

1. El Software proporciona significado de representación y acceso a

archivos externos creados por otras herramientas.

Especificación de Requerimientos
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será
aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex-
terno al archivo representado por la selección del icono.
Lectores de Requerimientos

Gerencia de Cliente
Definición de Usuarios Finales del Sistema
Requerimientos Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema

Usuarios Finales del Sistema

Especificacion de
Ingenieros de Cliente
Requerimientos
Arquitectos del Sistema
Desarrolladores de Software

Especificación de Ingenieros de Clientes

Software Arquitectos del Sistema
Desarrolladores de Software
Problemas
 Los sistemas de software grandes siempre presentan
problemas.
 Problemas que son tan complejos que puede ser que
nunca se comprendan completamente y donde los
desarrolladores van comprendiendo el sistema durante su
desarrollo.
 Por lo tanto, los requerimientos son normalmente
incompletos e inconsistentes.
Razones de Inconsistencia
 Los sistemas de software grandes deben permitir una
mejora en la situación actual de la empresa. Es difícil
anticipar los efectos que el sistema tendrá en la
organización.
 Usuarios diferentes tienen requerimientos y prioridades
diferentes. Hay constantemente cambios en los
requerimientos.
 Los usuarios finales del sistema y la organización que paga
por el sistema tienen requerimientos diferentes.
 El prototipado es requerido para clarificar requerimientos
Proceso de Ingeniería de Requerimientos
 Estudio de Factibilidad
 Encontrar si las necesidades de los usuarios son satisfechas
dada la tecnología y el presupuesto disponible?
 Análisis de Requerimientos
 Detallar que es lo que los usuarios requieren del sistema.
 Definición de Requerimientos
 Definir los requerimientos en una forma comprensible para el
cliente.
 Especificación de Requerimientos
 Define los requerimientos en detalle.
El Proceso de Ingeniería de Requerimientos

Estudio de Análisis de
Factibilidad Requerimientos

Definición de
Reporte de Requerimientos
Factibilidad
Especificación
Modelos del de Requerimientos
Sistema
Definición de
Requerimientos
Documento de
Requerimientos Especificación de
Requerimientos
Documento de Requerimientos
 Es la declaración oficial de lo que es requerido para que
el sistema sea desarrollado.
 Incluye la definición y especificación de requerimientos.
 No es un documento de diseño. Tanto como sea posible,
es un conjunto de lo que es el sistema y no de como lo
hará.
Requerimientos del Documento
 Especificación del comportamiento externa del sistema.
 Especificar las restricciones de la implementación.
 Fácil de cambiar.
 Sirve como una herramienta de referencia para el
mantenimiento.
 Registro del ciclo de vida del sistema, con el fin de
predecir cambios.
 Caracteriza respuestas a eventos inesperados.
Estructura del Documento de Requerimientos

 Introducción.
 Describe la necesidad de crear el sistema y cuales son sus
objetivos de negocio.
 Glosario.
 Define los términos técnicos usados.
 Modelos del Sistema.
 Define los modelos mediante los cuales se muestran los
componentes del sistema y las relaciones entre ellos.
 Definición de Requerimientos Funcionales.
 Define los servicios que serán proporcionados.
Estructura del Documento de Requerimientos

 Definición de Requerimientos No-funcionales.

 Definir las restricciones del sistema y el proceso de desarrollo.
 Evolución del Sistema.
 Definir las suposiciones fundamentales en las cuales el sistema se basa y los
cambios que preveen.
 Especificación de Requerimientos.
 Especificación detallada de los requerimientos funcionales del sistema.
 Apéndices.
 Descripción de la plataforma de Hardware del Sistema.
 Requerimientos de la base de Datos (quizá como un modelo Entidad
Relacion)
 Indice.
El Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto

requerimientos Factibilidad,
del negocio Tiempos y costos

requerimientos
requerimientos funcionales
del cliente/usuario
y no-funcionales

Cliente y Desarrolladores
Usuarios

Analista de Requerimientos
restricciones y requerimientos funcionales
requerimientos y no-funcionales

Otros interesados Pruebas

en el sistema
El Analista de Requerimientos
Actividades:

 Definir los objetivos del proyecto y los beneficios al negocio.

 Identificar el problema a resolver y obtener los requerimientos.
 Identificar a los involucrados en el desarrollo del proyecto así como
a las clases de clientes y usuarios.
 Identificar el ambiente del dominio a desarrollar y estar preparado
para desarrollar el sistema requerido.
 Administrar los requerimientos utilizando un proceso y un plan de
requerimientos.
 Modelar los requerimientos.
 Realizar control de cambios en los requerimientos.
El Analista de Requerimientos
Habilidades:

 Capacidad de comunicación.
 Capacidad de análisis y observación.
 Capacidad de organización.
 Analizar los riesgos del desarrollo del software.
El Cliente
Actividades y responsabilidades:

 Educar al analista de requerimientos acerca del negocio y sus objetivos.

 Ser claro y preciso acerca del problema que se quiere resolver.
 Colaborar con el analista en la definición de los requerimientos.
 Revisar los documentos de requerimientos y el avance del proyecto.
 Comunicar a los analistas sobre cambios en los requerimientos.
 Plantear costos y tiempos esperados de desarrollo y estar abierto a
discutir cambios en los costos y tiempos de entrega.
 Estar siempre dispuesto a reunirse con los desarrolladores para discutir
distintos aspectos del proyecto.
 Respetar los procesos que implementarán los desarrolladores para
implementar el producto.
El Usuario

Clasificación de los usuarios:

 La frecuencia con la que usan el sistema.
 Las funciones que usan del sistema y su frecuencia.
 La experiencia en el dominio de la aplicación y su experiencia con
otros sistemas similares.
 El tipo de uso que le dan al sistema (operación, administración,
mantenimiento, supervisión).
 Las tareas que desempeñan en soporte de los procesos de la
organización.
 Sus privilegios de acceso o niveles de seguridad (tales como usuario
invitado, administrador o usuario de nivel interno).
 Tipo de usuarios necesarios para operar el sistema (persona, grupo de
personas, robot, u otra computadora).
Problemas asociados al proceso

 Problemas de alcance, en los cuales se describen el

ámbito y los límites de operación del software. En esta
categoría algunos de los problemas podrían ser, que el
ambiente del sistema no esta bien delimitado, o que no
exista información suficiente del flujo de información de
la organización.
 Problemas asociados al proceso
 Problemas de comprensión de lo que se quiere construir,
con los clientes, usuarios y con los grupos de desarrolladores.
En esta categoría podrían aparecer distintos problemas:
 Los clientes y usuarios no entienden completamente todo lo
que requieren o no cuentan con toda la información que de
soporte a sus necesidades.
 Los clientes y usuarios tienen poco conocimiento de las
capacidades y limitaciones de los sistemas de cómputo.
 Los analistas de requerimientos tienen poco conocimiento del
dominio de la aplicación.
 Los usuarios y los analistas hablan distintos lenguajes técnicos.
 Existen distintas perspectivas de cómo debe construirse el
software, entre el cliente y los desarrolladores.
Problemas asociados al proceso

 Problemas de volatilidad debidos a los continuos

cambios en los requerimientos. En esta categoría se
trata de resolver los problemas que existen cuando
los requerimientos deben cambiar razones
tecnológicas, por errores, o por mejoras.
 Problemas de conflictos entre 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.
 Fijar un error de requerimiento después del desarrollo
puede resultar en un costo 100 veces mayor que fijar un
error en la implementación.
 El Prototipado es una técnica importante en la
validación de requerimientos.
Chequeo de Requerimientos
 Validez. Provee al sistema las funciones que mejor
soportan las necesidades del cliente?
 Consistencia. Existen conflictos en los requerimientos?
 Completitud. Están incluidas todas las funciones
requeridas por el cliente?
 Realismo. Pueden los requerimientos ser
implementados con la tecnología y el presupuesto
disponible?
Revisión de Requerimientos

 Revisiones frecuentes deben llevarse a cabo mientras la

definición de requerimientos está siendo hecha.
 Tanto el cliente como el staff de contratistas deben estar
involucrados en la revisión.
 La revisión pueden ser formales (con los documentos
completos) o informales. Una buena comunicación entre
desarrolladores, clientes y usuarios puede resolver
problemas en las primeras etapas.
Chequeo de la Revisión
 Verificabilidad. Pueden hacerse pruebas de los
requerimientos ?
 Entendibilidad. Se comprenden los requerimientos?
 Busqueda (trace). El origen de los requerimientos esta
claramente establecido?
 Adaptabilidad. Puede el requerimiento ser cambiado
sin causar un gran impacto en otros requerimientos?
Chequeo de Consistencia Automatizado

Requerimientos en un Reporte de los problemas

Lenguaje Formal de Requerimientos

Proceso de Análisis de
Requerimientos Requerimientos

Base de Datos
de Requerimientos
Cambios en el Documento de
Requerimientos

 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 referencias externas deben ser minimizadas y las
secciones del documento deben ser tan modulares como
sea posible.
 Los cambios son mas 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.
Evolución de Requerimientos
 Los requerimientos siempre evolucionan cuando existe
una mejor comprension de las necesidades del usuario y
cuando los objetivos de la organización cambian.
 Es escencial planear posibles cambios en los
requerimientos cuando el sistema sea desarrollado y
utilizado.
Evolución de Requerimientos

Comprensión Inicial Comprensión de los

del Problema Cambios del Problema

Requerimientos Cambios en los

Iniciales Requerimientos

Tiempo
 Evolución Controlada
Cambio en los
Requerimientos

Documento VI de Cambio en los Documento V1 Documento V2

Requerimientos Requerimientos de Requerimientos De Requerimientos

Implementación V1 Implementación V2 Implementación Implementación

del Sistema del Sistema V1 del Sistema V2 del Sistema

Inconsistencia de los Consistencia de los

Requerimientos y del Requerimientos y del
Sistema Sistema
Clases de Requerimientos
Requerimientos de acuerdo a su audiencia:

 Los Requerimientos del Cliente.

 Los Requerimientos del Sistema.
 Especificación del Diseño del software.
Clases de Requerimientos

Requerimientos de acuerdo a su característica:

 Requerimientos funcionales.
 Requerimientos no funcionales.
Clases de Requerimientos

Requerimientos de acuerdo a su característica:

 Requerimientos de dominio. Los requerimientos de

dominio son requerimientos que provienen del dominio de
aplicación del sistema y reflejan las características de este
dominio.
 Requerimientos de Datos. Los requerimientos de
datos definen las estructuras de datos requeridas en el
sistema.
 Requerimiento de Interfaz. Definen las características
y parámetros de la comunicación del sistema a desarrollar
con otros sistemas dentro de la empresa, o incluso de los
subsistemas.
 Requerimientos no funcionales
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
Clases de Requerimientos

 Requerimientos Perdurables. Requerimientos estables

derivados de las actividades de la organización del cliente.
Por ejemplo, un hospital siempre tendrá doctores,
enfermeras, etc. Puede ser derivado de modelos de
dominio.
 Requerimientos Volátiles. Los requerimientos cambian
durante el desarrollo o cuando el sistema está en uso. En
un hospital, los requerimientos se derivan de las políticas
salud-cuidados.
Clasificación de Requerimientos
 Requerimientos Cambiantes.
 Los requerimientos que cambian por el ambiente del sistema.
 Requerimientos Emergentes.
 Requerimientos que surgen como una comprensión del
desarrollo del sistema.
 Requerimientos de Consecuencias.
 Requerimientos que resultan de la introducción del sistema
computacional.
 Requerimientos de Compatibilidad.
 Requerimientos que dependen de otros sistemas o de otros
procesos de la organización.
Medidas en los requerimientos no
funcionales

Propiedad Medida

Velocidad Transacciones por segundo

Tiempo de respuesta a eventos
Tamaño Numero de líneas de código
Numero de Bytes de Memoria disponible
Facilidad de uso Tiempo de entrenamiento
Numero de ayudas
Confiabilidad Errores permitidos por unidad de tiempo
Media de tiempo por fallo
Disponibilidad en tiempo
Robustes Tiempo para restablecer después de fallo.
Porcentaje de fallos que causan caída del
sistema.
Portabilidad Facilidad de transportar a otro S.O o
lenguaje.
Ratreo de Requerimientos
 EL rastreo de los requerimientos trata con las relaciones entre
los requerimientos, sus fuentes y el diseño del sistema.
 Rastreo de la fuente
 Liga los requerimientos con los clientes o desarrolladores que
propusieron este requerimiento.
 Rastreo de requerimientos.
 Liga los requerimientos dependientes entre si.
 Rastreo del diseño.
 Liga los requerimientos al diseño.
La matriz de rastreo

Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

id
1.1 U R
1.2 U R U
1.3 R R
2.1 R U U
2.2 U
2.3 R U
3.1 R
3.2 R
Herramientas de Soporte Case
 Almacenamiento de Requirimientos
 Los requerimientos deben de organizarse y guardarse en un
lugar seguro y en donde estos puedan organizarse.
 Manejo de Cambios
 El proceso de cambios en un proceso de flujo de datos cuyas
etapas pueden definirse asi como el flujo de informacion entre
estas etapas.
 Manejo del Rastreo
 Obtencion automatizada de las ligas que generan los
requerimientos.
 Pre-Requisite Pro. Herramienta de Soporte CASE
Factores sociales y organizacionales
 Los sistemas de software se usan dentro de un contexto
social y organizacional. Estos pueden influir o dominar los
requerimientos del sistema.
 Los factores sociales y organizacionales tienen influencia
en todos los puntos de vista.
 Los analistas deben ser sencibles a estos factores aunque
no exista una forma sistematica de enfrentarlos.
Ejemplo

 Considere un sistema que permite a los administradores accesar

informacion sin consultar con los operadores del sistema.
 Estatus de la Administracion. Los adminstradores consideran que
ellos son demasiado importantes como para tener que usar un
teclado de computadora. Esto podria limitar el tipo de interfaz
hombre-maquina a diseñar.
 Responsabilidades de la administracion. Los administradores
podrian no tener tiempo para aprender a usar el sistema.
 Resistencia organizacional. Los administradores podrian no dar
informacion completa o incluso dar informacion erronea para
que el sistema falle.
Etnografia
 Un cientifico gasta una cantidad de tiempo considerable
observando y analizando como trabaja la gente.
 La gente no tiene que explicar o articular su trabajo.
 Se observan los factores de mas importancia sociales y
organizacionales.
 Es importante observar como trabaja la gente para producir
mejores diseños.
Requerimientos
 Ya sabemos que funcionalidad se le pide a este sistema ?

Base de Datos
Del Banco Análisis
de Riesgos

Interfase Hombre-Maquina Lector de

Tarjeta de Crédito
Sistema de
Pantalla ° Teclado
Comunicaciones
del Banco

Sistema de
Control del
Cajero Automático

•Cliente
•Representante
del Banco Sistemas de Control y
•Personal de Sistema de
Mantenimiento Conteo de Billetes Comunicaciones
Resumen
 Es muy difícil formular una especificación de
requerimientos completa y consistente.
 Una definición de requerimientos, una especificación de
requerimientos y una especificación de Software son una
manera de especificar el Software para diferentes tipos de
lectores.
 El Documento de Requerimientos es una descripción
para clientes y desarrolladores.
Resumen
 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.
 Los requerimientos volátiles dependen del contexto en
que se use el sistema.