PROCESOS DE LA INGENIERA

DE REQUISITOS
INGENIERA DE
REQUERIMIENTOS
Ing. Sfora Romn Snchez

INTRODUCCIN
La I.R. cumple un papel primordial en el proceso de
produccin de software, que se enfoca a un rea fundamental:
la definicin de lo que se desea producir
Su tarea principal consiste en la generacin de
especificaciones correctas que describan con claridad, sin
ambigedades, en forma consistente y compacta, el
comportamiento del sistema, de esta forma, se pretende
minimizar los problemas relacionados al desarrollo de
sistemas.

TIPOS DE REQUISITOS

Nueva
Abstraccin

Usuarios: Servicio del sistema debe ser

comprensible para el cliente.
Sistema: Descripcin detallada de funciones
, uso de notaciones especializadas.
Dominio: Declaraciones cercanas al diseo e
implementacin

Naturaleza

Funcionales: Descripcin de qu funciones

hace el sistema.
No funcionales: Descripcin de cmo debe
funcionar el sistema

REQUISITOS FUNCIONALES Y NO FUNCIONALES

Requisitos funcionales: describen lo que el

sistema debera hacer
Ej.: el sistema debe proveer autenticacin de la identidad
de un usuario
Ej.: el sistema debe emitir una factura

Requisitos no funcionales: establecen

restricciones de cmo estos requisitos
funcionales son implementados.
EJ.: El proceso de autenticacin debera completarse en
menos de 4 segundos.
EJ.: La emisin de factura debe poder hacerse desde
cualquier terminal de trabajo.

REQUERIMIENTO
Definicin: Condicin o necesidad de un usuario para
resolver un problema o alcanzar un objetivo.
Es necesario si su omisin provoca una deficiencia en el sistema a
Necesario
construir.

Conciso

Si es fcil de leer y entender

Si no necesita ampliar detalles en su redaccin, esto es si proporciona

Completo
la informacin suficiente para su comprensin.
No
ambiguo

El lenguaje usado en su definicin, no debe causar confusiones.

Cuando puede ser cuantificable, de manera que permita hacer uso de

Verificable
mtodos como la inspeccin, anlisis, demostracin o pruebas

QU ES UN REQUISITO?
Un requisito podra describir:
Una facilidad a nivel usuario

Ej.: el procesador de palabras debe incluir un verificador de

ortografa y un comando de correccin

Una propiedad muy general del sistema

Ej.: el sistema debe asegurar que la informacin personal
nunca se haga disponible sin autorizacin

Una restriccin especfica del sistema

Ej.: el sensor debe ser activado 10 veces por segundo

Una restriccin para el desarrollo del sistema

Ej.: el sistema debe ser desarrollado usando Ada

Cmo llevar a cabo algn clculo

Ej.: la nota final debe ser calculada sumando las notas del
examen, proyecto y cursada del estudiante basado en la siguiente
frmula
nota final = nota_exam + 2 * nota_proy + 2/3 *
nota_cursada

Propiedades del dominio: Cosas en el dominio de aplicacin

que son verdaderas independientemente que se construya o no
el sistema de software
Requisitos: Cosas en el dominio de aplicacin que se desean
sean verdaderas mediante la construccin del sistema de
software
Especificacin: Descripcin de comportamiento (y datos) que
el programa tiene que tener para cumplir los requisitos slo
puede ser descrito en trminos de los fenmenos
compartidos por la maquina y el dominio de aplicacin

ROL DE LOS REQUISITOS

Acuerdo desarrolladores-stakeholders
Aspecto contractual
Multipartes (comunicacin, conflicto y
cambio de visiones)
Base para el diseo del software
Minimizar defectos tanto como sea posible
Proyecto Tcnicamente factible
Soporte para verificacin y validacin
Soporte a la evolucin del sistema

Stakeholder:

Entidad que ser afectada por el

sistema y que tienen una influencia
directa
o
indirecta
sobre
los
requisitos del sistema.
Usuarios finales del sistema
Gerentes involucrados en los procesos organizacionales
influenciados o que influencian al sistema
Ingenieros
responsables
por
el
desarrollo
y
mantenimiento del sistema,
Clientes de la organizacin
Cuerpos externos tales como autoridades reguladoras o
de certificacin.
.

STAKEHOLDERS
Posibles stakeholders de un sistema
automatizado de sealizacin ferroviaria:
Los Operadores responsables de ejecutar el
sistema de sealizacin
Tripulacin del tren
Gerentes ferroviarios
Pasajeros
Ingenieros de instalacin y mantenimiento de
equipos
Autoridades de certificacin de seguridad

PROCESO DE RE
Conjunto de actividades que son seguidas con el
objetivo de descubrir, modelar, validar y mantener
un documento de requisitos.
Sistemas de informacin
existentes
Necesidades de los
stakeholders
Standard de la
organizacin
Regulaciones, polticas e
informacin del dominio

proceso

Requisitos acordados
Modelos del sistema
y su entorno.

QU DEBE HACER EL INGENIERO DE

REQUISITOS?
Punto de inicio

Nocin de existencia de un problema que debe ser

resuelto, ej:
Insatisfaccin con estado corriente del sistema/negocio
Oportunidad del negocio
Potencial ahorro de tiempo, recursos, costos, etc.

Un ingeniero de requisitos en un agente de cambio

El ingeniero de requisitos debe:

identificar el problema/oportunidad

Cual es el problema que se debe resolver? (Identificar los lmites)

en donde se debe resolver (Comprender el contexto)
De quien es el problema ? (Identificar los stakeholders)
Por qu necesita se resuelto? ((Identificar los objetivos de los
stakeholders)
Cmo podra ayudar un S.S. ( Plantear escenarios)
Cuando necesita resolverse? (Identificar restricciones de desarrollo)
Que podra evitar que lo resolvamos? (Identificar riesgos y viabilidad)

ACTIVIDADES DEL PROCESO DE

INGENIERA DE REQUISITOS
Elicitacin

Modelado

Anlisis

Gestin

Identificacin de
Fuentes Inform.
Recoleccin de
hechos
Comunicacin

Representacin

Verificacin

Organizacin

Validacin

Almacenamiento
(registracin)

Negociacin

Identificacin de
cambios
Anlisis de
cambios
Realizacin de
cambios

ACTIVIDADES EN EL PROCESO
Dependiendo del tamao DE
del proyecto
y del modelo de proceso de
LA
IR
software utilizado para el ciclo de desarrollo, las actividades de la IR
varan tanto en nmero como en nombres.
Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniera de Software
MODELO
Oliver and Steiner
EIA / IS-632
IEEE Std 1220-1994
CMM nivel Repetitivo
1996
(2)

Evaluar la
informacin
disponible
Definir mtricas
efectivas
Crear un modelo del
comportamiento del
sistema
Crear un modelo de
los objetos

Activi
dades

Ejecutar el anlisis
Crear un plan
secuencial de
construccin y
pruebas

Anlisis de

requerimientos Requerimientos

Identificacin de
requerimientos

Anlisis del Problema

Anlisis
funcional

Identificacin de
restricciones del
sistema a desarrollar

Comprender las
necesidades de los
involucrados

Anlisis de los
requerimientos

Definir el sistema

Anlisis funcional

Representacin de los
requerimientos

Analizar el alcance del

proyecto

Evaluacin y
estudio de
funciones

Comunicacin de los
requerimientos

Modificar la definicin
del sistema

Validacin de
requerimientos

Administrar los
cambios de
requerimientos

Estudio y evaluacin
del diseo

Sntesis
Anlisis y
control del
sistema

Anlisis de

RUP

Estudio de los
requerimientos
Validacin de
requerimientos

Verificacin de
funciones

Sntesis

EJERCICIO
Definir 10 requerimientos necesarios para el
desarrollo del problema planteado.

PERSONAL INVOLUCRADO
Usuario Final. Es la persona que usar el sistema desarrollado.
Ser quien utilice, disponga y se encuentre familiarizado con los
procesos que debe realizar el software; as tambin, es el que
utiliza las interfaces y los manuales de usuario.
Usuario Lder. Es el individuo que comprende el ambiente del
sistema o el dominio del problema en donde ser empleado el
software desarrollado.
Personal de Mantenimiento. Para proyectos que requieran un
mantenimiento eventual, stas personas son las responsables de
la administracin de cambios, de la implementacin y resolucin
de anomalas. Su trabajo consiste en revisar y mejorar los procesos
del producto finalizado.

PERSONAL INVOLUCRADO
Analistas y programadores. Son los responsables del desarrollo
del producto, en s ellos interactan directamente con el cliente.
Personal de pruebas. Se encarga de elaborar y ejecutar el plan
de pruebas para asegurar que las condiciones presentadas por el
sistema son las adecuadas. Son quienes validan si los
requerimientos satisfacen las necesidades del cliente.

EJERCICI
O
Mostrar una tabla con la cantidad de personal
requerido para el desarrollo y solucin del problema
planteado.
Tipo de personal

Cantidad

Justificacin

ACTIVIDADES DE LA INGENIERA DE
REQUERIMIENTOS
A pesar de las diferentes interpretaciones que cada
desarrollador tenga sobre el conjunto de actividades
mostradas en la tabla anterior, podemos identificar y extraer
cinco actividades principales que son:

Evolucin
Validacin
Especificacin
Evaluacin y
negociacin
Anlisis
del
problema

1. ANLISIS DEL PROBLEMA

El objetivo de esta actividad es entender las verdaderas
necesidades del negocio para el cual se har el proyecto.
Durante el anlisis del problema, se realiza una serie de
pasos para garantizar un acuerdo entre los involucrados,
basados en los problemas reales del negocio, los pasos
serian los siguientes:

Comprender el problema que se est resolviendo

Construir un vocabulario comn
Identificar a los afectados del sistema
Definir los lmites y restricciones del sistema

1. ANLISIS DEL PROBLEMA

El objetivo de esta actividad es entender las verdaderas
necesidades del negocio para el cual se har el proyecto.
Durante el anlisis del problema, se realiza una serie de
pasos para garantizar un acuerdo entre los involucrados,
basados en los problemas reales del negocio, los pasos
serian los siguientes:

Comprender el problema que se est resolviendo

Construir un vocabulario comn
Identificar a los afectados del sistema
Definir los lmites y restricciones del sistema

PARA PROYECTO
Redactar el problema planteado.
Elaborar el vocabulario comn.
Identificar los afectados del sistema.
Definir los lmites y restricciones del problema a
solucionar.

2. EVALUACIN Y NEGOCIACIN DE
REQUERIMIENTOS
Las principales actividades son:
Descubrir problemas potenciales.
Clasificar los requerimientos (Prioridad de cada requerimiento
depender de las necesidades que tenga el negocio)
Busca identificar la importancia que tiene un requerimiento
en
trminos de implementacin.

Mandatario
Deseable (se necesitan pero no son indispensables)
Innecesario
Una vez hecha esta categorizacin de los requerimientos, puedo tomar
como estrategia general el incluir los mandatorios, discutir los deseables y
descartar los innecesarios.
Antes de decidir la inclusin de un
requerimiento, tambin debe analizarse su costo, complejidad, y una
cantidad de otros factores.

Las principales actividades son:

Evaluar factibilidades y riesgos
Factibilidades tcnicas
Factibilidades operacionales
Factibilidades econmicas
Factibilidades tcnicas (pueden implementarse los
requerimientos con la tecnologa actual?);
Factibilidades operacionales (puede ser el
sistema utilizado sin alterar el organigrama
actual?);
Factibilidades econmicas (ha sido aprobado por
los clientes el presupuesto?).

Incremento en la comunicacin entre el equipo de

desarrollo y los afectados. Para una comunicacin
efectiva, hay una serie de consideraciones a tener en
cuenta:
Documentar todos los requerimientos a un nivel de
detalle apropiado.
Mostrar todos los requerimientos a los involucrados
en el sistema.
Analizar el impacto que causen los cambios a
requerimientos antes de aceptarlos.
Establecer las relaciones entre requerimientos que
indiquen dependencias.
Negociar con flexibilidad para que exista un
beneficio mutuo.
Enfocarse en intereses y no en posiciones.

EJERCICIO.
Entregar documento en donde se enlisten los
requerimientos del sistema planteando los puntos
vistos anteriormente, dicho documento ser la
carta de presentacin de los equipos.
Exponer ante los compaeros los requerimientos
fundamentales para llevar a buen trmino la
solucin del problema a plantear. (tiempo de
exposicin max. 10 minutos)

3. ESPECIFICACIN DE REQUERIMIENTOS
DE SOFTWARE.
Es la actividad en que se genera el documento y
contiene una descripcin completa de las
necesidades y funcionalidades del sistema, que
ser desarrollado; describe el alcance del sistema
y la forma como har sus funciones, definiendo
los requerimientos.
En la especificacin se definen:

Todos los requerimientos de hardware

Todos los requerimientos de software
Diagramas
Modelos de sistemas y cualquier otra cosa que sirva de
soporte y gua para fases posteriores.

Los clientes y usuarios utilizan la SRS para comparar si lo

que se est proponiendo, coincide con las necesidades de la
empresa.
Los analistas y programadores la utilizan para
determinar el producto que debe desarrollarse.
El personal de pruebas elaborar las pruebas funcionales
y de sistemas en base a este documento.
Para el administrador del proyecto sirve como
referencia y control de la evolucin del sistema.

4. VALIDACIN DE LOS REQUISITOS

Permite demostrar que los requerimientos definidos en el
sistema son los que realmente quiere el cliente, adems
revisa que no se haya omitido ninguno, que no sean
ambiguos, inconsistentes o redundantes.
La validacin de requerimientos es importante pues de
ella depende que no existan elevados costos de
mantenimiento para el software desarrollado

No debe confundirse la actividad de

evaluacin de requerimientos con la
validacin de requerimientos. La
evaluacin verifica las propiedades de
cada requerimiento, mientras que la
validacin revisa el cumplimiento de las
caractersticas de la especificacin de
requisitos.

Durante la actividad de validacin pueden hacerse preguntas en

base a cada una de las caractersticas que se desean revisar. A
continuacin se presentan varios ejemplos:

Estn incluidas todas las funciones requeridas por el cliente?

(completa)
Existen conflictos en los requerimientos? (consistencia)
Tiene alguno de los requerimientos ms de una
interpretacin? (no ambigua)
Est cada requerimiento claramente representado?
(entendible)
Pueden los requerimientos ser implementados con la
tecnologa y el presupuesto disponible? (factible)
Est la SRS escrita en un lenguaje apropiado? (clara)
Existe facilidad para hacer cambios en los requerimientos?
(modificable)
Est claramente definido el origen de cada requisito?
(rastreable)
Pueden los requerimientos ser sometidos a medidas
cuantitativas? (verificable)

5. EVOLUCIN DE LOS REQUERIMIENTOS

La actividad de evolucin es un proceso externo que
ocurre a lo largo del ciclo de vida del proyecto.
Los requerimientos cambian por diferentes razones:
Porque al analizar el problema, no se hacen las
preguntas correctas a las personas correctas.
Porque cambi el problema que se estaba
resolviendo.
Porque los usuarios cambiaron su forma de
pensar o sus percepciones.
Porque cambi el ambiente del negocio.