INGENIERÍA DE REQUERIMIENTOS

ADSO (Análisis y Desarrollo de Software

Centro de Servicios Empresariales y Turísticos

Regional Santander
 CONCEPTOS

La ingeniería de requerimientos es un proceso

sistemático mediante el cual se determinan los
servicios que el software como producto debe
suministrar y las restricciones sobre las cuales
operará”. (BOURQUE, 2014)
 CONCEPTOS
La ingeniería de requerimientos es un
proceso de descubrimiento,
refinamiento, modelización, Se desarrollan sistemas de
especificación y validación de lo que se software para satisfacer una
desea construir. En este proceso tanto el necesidad percibida por un
cliente como el analista juegan un papel cliente.
muy importante. (Leite, 1987)

Pueden formularse las

necesidades reales del cliente Los requerimientos son desarrollados
como requerimientos. conjuntamente por el cliente, usuario y
diseñadores del sistema de software.
 Ingeniería de Requerimientos

Posibles Problemas con los Requisitos:

• No reflejan las necesidades reales del cliente

• Son inconsistentes y/o incompletos
• Es costoso realizar cambios sobre los requisitos una vez que han sido
acordados
• Puede haber malentendidos entre clientes, analistas, ingenieros
software, ..
Imprecisión: Los requisitos ambiguos pueden ser
interpretados de diferentes formas por desarrolladores y
usuarios.
 Clases De Requerimientos
Funcionales
Son aquellos que describen cualquier
actividad que este deba realizar, en otras
palabras, el comportamiento o función
particular de un sistema o software cuando
se cumplen ciertas condiciones.
No funcionales
Se trata de requisitos que no se refieren
directamente a las funciones específicas
suministradas por el sistema (características de
usuario), sino a las propiedades del sistema:
rendimiento, seguridad, disponibilidad. En
palabras más sencillas, no hablan de “lo que”
hace el sistema, sino de “cómo” lo hace.
 Ejemplo Requerimiento Funcional de Proceso

El aplicativo debe poder emitir los siguientes
estados financieros:
• Balance general
• Estado de ganancias y pérdidas,
• Estado de flujos de efectivo.
El aplicativo enviará un correo electrónico
cuando se registre alguna de las siguientes
transacciones:
• Pedido de venta de cliente
• Despacho de mercancía al cliente,
• Emisión de factura a cliente y registro de
pago de cliente

El sistema permitirá a los usuarios autorizados el

ingresar planes y cronogramas.
El sistema permitirá aprobar, cambiar o actualizar
planes y cronogramas.
 Ejemplo Requerimiento Funcional de Interfaz Gráfica

▪ El campo de monto acepta únicamente valores numéricos con dos

decimales.

▪ El campo fecha de transacción acepta únicamente fechas anteriores al día de

hoy (día actual).

▪ El campo nombre acepta caracteres alfabéticos únicamente.

▪ El campo dirección acepta caracteres alfabéticos, numéricos y

especiales.

▪ La pantalla de registro de pago puede imprimir los datos en

pantalla a la impresora.
 Ejemplo Requerimiento Funcional de Seguridad

1. La aplicación controlará el acceso y permitirá el ingreso

solo a usuarios autorizados. Los usuarios deben ingresar al
sistema con un nombre de usuario y contraseña.

La aplicación enviará una alerta al administrador cuando: 2. Los usuarios analistas pueden
ingresar solicitudes pero no
• Se registre una nueva cuenta pueden aprobarlas o borrarlas.
• Ingreso al sistema por parte de los clientes
3. Los usuarios de gerentes
• Dos o mas intentos fallidos en el ingreso del usuario y pueden ingresar y aprobar
contraseña y/o cambio de contraseña solicitudes, pero no pueden
borrarlas.

4. Los usuario de administradores no

pueden ingresar o aprobar solicitudes, pero
si pueden borrarlas
 Requerimiento No funcionales

Se clasifican en: 1. Requerimientos de producto: Son los requerimientos que

determinan cómo se debe comportar el producto.

Pueden clasificarse en requerimientos de usabilidad, eficiencia,

dependibilidad y seguridad.

2. Requerimientos Organizaciones: Son aquellos que condicionan la forma

en que tanto la empresa como los desarrolladores llevan a cabo el
proyecto.
pueden clasificarse en requerimientos de entorno, organizacionales y de
desarrollo.

3. Requerimientos Externos: Son los que influencian el proyecto desde afuera

empresa u organización y el proceso de desarrollo. Entre estos tenemos los
requerimientos normativos o de ley.

Pueden clasificarse en requerimientos regulatorios, éticos y legislativos.

 Ejemplos Requerimiento No funcionales de
Producto

✓ El sistema debe ser capaz de procesar “N” transacciones por segundo.

✓ Toda funcionalidad del sistema y transacción de negocio debe responder al usuario

en menos de 5 segundos.

✓ El sistema debe ser capaz de operar adecuadamente con hasta 100.000

usuarios con sesiones concurrentes.

✓ Los datos modificados en la base de datos deben ser actualizados para

todos los usuarios que acceden en menos de 2 segundos.
 Ejemplos Requerimiento No funcionales de
datos

✓ Los permisos de acceso al sistema podrán ser cambiados

solamente por el administrador de acceso a datos.

✓ Todos los sistemas deben respaldarse cada 24 horas. Los

respaldos deben ser almacenados en una localidad segura
ubicada en un edificio distinto al que reside el sistema.

✓ Si se identifican ataques de seguridad o brecha del sistema, el mismo no

continuará operando hasta ser desbloqueado por un administrador de
seguridad.
 Ejemplos Requerimiento No funcionales de
Usabilidad

✓El sistema debe contar con manuales de usuario

estructurados adecuadamente.

✓El sistema debe proporcionar mensajes de error que sean

informativos y orientados a usuario final.

✓El sistema debe contar con un módulo de ayuda en línea.

✓El sistema debe poseer interfaces gráficas bien formadas.

 Ejemplos Requerimientos no Funcionales
De producto…..

• La aplicación debe ser compatible con todas las versiones de

Windows, desde Windows 95.
• La aplicación deberá consumir menos de 500 Mb de memoria RAM.
• La aplicación no podrá ocupar más de 2 GB de espacio en disco

Ejemplos de Externos…..

• Las páginas web a ser desarrolladas deben cumplir con la ley de

tratamiento en condiciones de igualdad para personas con
discapacidad.

• El sistema no revelara a sus operadores otros datos personales de los

clientes distintos a nombres y números de referencia.
 Ejemplos Requerimientos no Funcionales

De Organización…..

• El procedimiento de desarrollo de software a usar debe estar definido

explícitamente (en manuales de procedimientos) y debe cumplir con los
estándares ISO 9000.
• Debe especificarse un plan de recuperación ante desastres para el sistema a
ser desarrollado.
• Cada dos semanas deberán producirse reportes gerenciales en los cuales se
muestre el esfuerzo invertido en cada uno de los componentes del nuevo
sistema.
 Deben ayudar a la
empresa a cumplir
sus objetivos y no a
Características de los Requerimientos
resolver
problemáticas
externas a la
empresa

Debe tener en
cuenta las
restricciones de
tiempo y costo del
proyecto para que
sea alcanzable

Deben definir de
manera clara y
concisa la razón de
ser del
requerimiento
 Características de los Requerimientos
No se pueden repetir,
así es más fácil de
identificar.

Los requerimientos
se deben priorizar,
elegir los de mayor
impacto.

Los requerimientos
no se pueden
contradecir o entrar
en conflicto unos
con otros.
Etapas para la Especificación de Requerimiento

Levantamiento….

En esta etapa se recopilan mediante técnicas

de levantamiento de información los
requerimientos funcionales y no funcionales
del software a desarrollar.

1. Entrevistas
2. Visita de campo
3. Reuniones dirigidas
4. Prototipos
5. Narrativas por parte del usuario
 Levantamiento de la información

1. Entrevistas:

El analista en la entrevista debe indagar al

entrevistado cuál es la razón de ser del
requerimiento y como éste contribuirá con las
metas de la empresa o a resolver un problema o
situación del modelo de negocios.
2. Visita de campo:

La observación directa o la visita de campo

permite que el analista pueda corroborar la
información suministrada por el usuario y
profundizar el conocimiento del contexto que dio
origen al requerimiento.
 Levantamiento de la información

3. Reuniones dirigidas
4. Prototipos
Esta técnica permite unificar los
puntos de vista de los diferentes El analista se puede apoyar en
participantes del proyecto modelos que pueden ser dibujos,
(stakeholders). diagramas, diseños de pantalla para
eliminar ambigüedades,
imprecisiones y demás dudas que le
puedan surgir a los usuarios.
5. Narrativas por parte del usuario

El usuario puede describir el servicio que el software debe

suministrar narrando los beneficios de este. Ejemplo: “yo espero
que el sistema me permita hacer “generar un reporte diario delas
ventas realizadas”.
 Identificación de las Fuentes u Orígenes de los
Requerimientos
Según BOURQUE (2014), las fuentes más comunes de los requerimientos
son:
a) Los objetivos de la empresa, misión, visión.
b) El tipo de industria donde está inmersa la empresa.
c) Los interesados o stakeholders del proyecto.
d) Las reglas del negocio o políticas de la empresa.
e) El ambiente donde operará el sistema.
f) La cultura empresarial.

Stakeholders son todas aquellas personas o entidades que pueden

influenciar el proyecto, el alcance, recursos entre otros
Análisis de requerimientos

Una vez levantados los requerimientos se procede a

su análisis para lograr una mayor compresión y
coherencia entre los diversos interesados o
stakeholders.
 Análisis de requerimientos (Etapas)
Cuando los requerimientos
entran en conflicto, o se
a) Según su prioridad
exceden de los recursos.. Se
b) Grado de impacto sobre
recomienda priorizar por
el proyecto
etapas de proyecto.
c) Según su probabilidad de
cambio en el tiempo

En esta etapa ya se debe

tener claro la arquitectura Analizar el requerimiento se
de la solución porque pueden apoyar en un
muchos requerimientos se modelo (diagramas de casos
solucionarán basados en de uso , modelo de flujo de
ella. datos)
 Definición De Requerimiento

Una vez analizados los requerimientos se

proceden a formalizar con el objetivo que
puedan ser compartidos, revisados,
evaluados y aprobados por todos los
participantes o stakeholders

Esta es la etapa del cierre de la especificación de requerimientos, para pasar

a la fase de desarrollo del sistema de información. También es una
formalización de los acuerdos realizados a lo largo de esta etapa.
DEFINICIÓN DE REQUERIMIENTO
 Descripción del formato
a) Título: contiene logo, encabezado y espacio para el versionamiento del documento en el
sistema de gestión de calidad.
b) ID: Número consecutivo para la identificación del requerimiento
c) Nombre: descripción breve del requerimiento generalmente en una o dos oraciones.
d) Descripción: detalle del requerimiento en lenguaje natural y teniendo en cuenta todos
los aspectos del mismo. Se puede apoyar en gráficos, tablas dibujos, etc.
e) Prioridad: indica el impacto que tiene sobre proyecto en su conjunto o sobre los
objetivos de la empresa. Generalmente se usa la escala: alto, medio, bajo o también se
pueden usar escalas numéricas como de 1 a 10 donde 1 es la menor prioridad y 10 la
máxima.
 Descripción del formato

f) Controles y restricciones: son los requerimientos no funcionales para este

requerimiento. Indican temas de interfaz, seguridad, rendimiento y facilidad de uso.
g) Criterios de aceptación: es un mecanismo para disminuir la subjetividad en el
momento de aceptación del requerimiento por parte de la empresa. Debe describir
qué variables o características debe presentar el software para ser aceptado.

Un criterio de aceptación común es que el software se acepta cuando cumpla con los
requerimientos funcionales y no funcionales planteados.
 Descripción del formato

h) Fecha: Es la fecha en la que el requerimiento es definido y formalizado con la firma de

los stakeholders involucrados.

i) Firmas de aceptación: este campo más que una cuestión técnica es un instrumento
que permite que los usuarios tengan mas compromiso y responsabilidad con las
definiciones realizadas toda vez que cualquier cambio posterior representará costos
adicionales para el proyecto.
Validación del Requerimiento

La validación de los requisitos, tiene como objetivo

comprobar que estos son correctos.

Esta fase debe realizarse o de lo contrario se corre

el riesgo de implementar una mala especificación
 Validación del Requerimiento
Revisión de requerimientos: En esta etapa los
requerimientos se revisan para corroborar que
están claros, alineados con los objetivos del
negocio, acordes a las regulaciones tanto
vigentes como las que se aproximan.
Validaciones con prototipos: Un prototipo
puede ser útil para el analista en el
momento de validar los requerimientos del
cliente ya que sirve para acercar los puntos
de vista con el cliente a través de imágenes,
diagramas, tablas, entre otros.
 Validación del Requerimiento

Establecer criterios de aceptación del requerimiento

Muchas veces la inclusión de uno o más criterios de aceptación es útil para disminuir aún
más la subjetividad.

Este ejercicio también ayuda a identificar si un requerimiento es una necesidad o puede ser
obviado sin afectar el proyecto.

La especificación de requerimientos en la vida real no termina con

la aprobación y la validación del documento. Es un proceso que se
expande a través de todo el ciclo de vida del software.
Validación del Requerimiento

Con frecuencia los requerimientos sufren cambios a lo largo

de las demás etapas del proyecto por razones tan diversas
como:

Mala comunicación entre los stakeholders, cambios

normativos o de ley, cambios en el mercado, etc.
 Validación del Requerimiento

La especificación de requerimientos en la vida real no termina con la aprobación y

la validación del documento. Es un proceso que se expande a través de todo el ciclo
de vida del software.

Con frecuencia los requerimientos sufren cambios a lo largo de las demás etapas
del proyecto por razones tan diversas como:

Mala comunicación entre los stakeholders, cambios normativos o de ley, cambios

en el mercado, etc.