Ingeniera de

requerimientos
Ingeniera de Sistemas e Informtica

Propsito y contenido de la sesin

Propsito de la sesin
Describe las caractersticas
de los requisitos de
software.

Contenido de la sesin
Requisitos de software.

Recapitulando

Requisitos del software

Requisitos del software

Conceptos clave
Independientemente de las tcnicas o procesos que se apliquen para realizar las diferentes tareas
relacionadas con el rea de requisitos, son cinco los objetivos que hay que cubrir:

ANALIZAR EL PROBLEMA

DEFINIR EL SISTEMA

DESARROLLAR LOS REQUISITOS DEL SOFTWARE

GESTIONAR LOS REQUISITOS

COMPRENDER LAS NECESIDADES DE LOS USUARIOS

Analizar el
problema

Comprender las
necesidades de
los usuarios

Definir el sistema

Desarrollar los
requisitos del
software

Gestionar los
requisitos

Requisitos del software

Obtencin de los requisitos

Sndromes

en la obtencin de los requisitos

Cuatro son los principales desafos para el analista de requisitos:

S pero no exactamente as.

Vaya!, pues esto no debera ser as.
Ya est todo?
Usuarios contra desarrolladores

Requisitos del software

Obtencin de los requisitos

Vaya!, pues esto no debera

ser as.

Los medios para reducir su efecto son:

Evitar quedarse con las primeras descripciones genricas.
No dar nada por supuesto.
Evitar las ambigedades.
Conocer el entorno y las necesidades del cliente.
Dedicar esfuerzo y tiempo para la obtencin de requisitos, adecuado
al tamao y complejidad del sistema.

Requisitos del software

Obtencin de los requisitos

S pero no exactamente as.

Inmadurez de los
procesos a los que el
nuevo sistema debe
dar soporte.
l no saba bien lo que
quera, o se ha dado
cuenta de lo que en
realidad necesita.
Emplear prototipos.

Requisitos del software

Obtencin de los requisitos

Ya est todo?

Dedicar tiempo suficiente a la obtencin y anlisis, e

identificar a todos los participantes o partes implicadas en
el proyecto.
9

Requisitos del software

Obtencin de los requisitos

Usuarios contra desarrolladores

Gestionar la comunicacin
10

Requisitos del software

Obtencin de los requisitos

Problemas

frecuentes en la obtencin de requisitos

Los problemas ms frecuentes pertenecen a 3 categoras:

Delimitacin confusa del mbito del sistema.

Comprensin
Inestabilidad

Problema: delimitacin confusa del mbito del sistema

Antes de entrar en la obtencin de requisitos con detalle es necesario conocer cules son los
objetivos y los lmites del sistema.
Si no controlamos los lmites y objetivos esperados del sistema, el sistema nos
controlar a nosotros
Los contextos que es necesario conocer para centrar apropiadamente el sistema en su entorno
son:

Organizacin
Entorno
Proyecto
11

Requisitos del software

Obtencin de los requisitos
Problema: delimitacin confusa del mbito del sistema
Para evitarlo deben analizarse y conocerse los tres mbitos sealados
ORGANIZACIN
Para llevar a cabo la obtencin de requisitos es preciso conocer y comprender la organizacin
en la que trabajar el sistema, y los objetivos que se pretenden conseguir.
ENTORNO
Los factores del entorno del sistema influyen de forma determinante en el proceso de
obtencin de requisitos. Los ms importantes son:
Restricciones: de hardware, sobre el software o sobre los procesos de desarrollo.
Madurez de los procesos del entorno de operacin.
Grado de certidumbre de los interfaces con otros sistemas.
PROYECTO
El contexto en el que se desarrolla el proyecto tambin afecta a los procesos de obtencin de
requisitos, que deber adecuar los mtodos y tcnicas de obtencin a las caractersticas del
proyecto:
Caractersticas especficas de cada grupo de agentes implicados en el proyecto
(usuarios, cliente, desarrolladores, normativas, etc.)
Restricciones impuestas por las partes implicadas en la obtencin de los requisitos
(agenda, coste, parmetros de calidad deseados, etc.)

12

Requisitos del software

Obtencin de los requisitos
Problema: comprensin
El 56% de los errores deslizados en los sistemas desarrollados se deben a deficiencias en la
comunicacin usuario analista durante la obtencin de los requisitos, y este tipo de errores son
los ms caros de corregir porque llegan a consumir hasta el 82% del tiempo de desarrollo[1].
Los problemas de comprensin producen requisitos incompletos, con ambigedades,
inconsistentes; y en definitiva incorrectos, porque no definen las necesidades reales de los
usuarios.
Estos problemas se pueden agrupar en tres categoras:

Dar por supuesto lo desconocido.

Lenguaje.
Informacin desestructurada.

Problema: inestabilidad
Los requisitos son inestables y cambian durante el desarrollo y tras la entrada en servicio del
sistema.
La solucin para evitar problemas radica en el proceso de gestin de requisitos.

[1] Goodrich, Victoria, and Olfman, Lorne. An experimental Evaluacion of Task annd Methodology Variables for Requirements
Definition Phase Success. In Bruce D. Shriver (editor), Proceedings of the twenty-third Annnual Hawaii International Conference on
System Sciences, p. 201-209. IEEE Computer Society, January 1990

13

Requisitos del software

Obtencin de los requisitos

Tcnicas de obtencin de requisitos

ENTREVISTAS

Reuniones JAD, cuestionarios

reuniones de grupo
entrevista, lluvia de ideas

ESCENARIOS

Casos de uso, tarjetas CRC

diagramas de flujo, escenarios

PROTOTIPOS

Prototipos rpidos
prototipos evolutivos

TCNICAS

OBSERVACIN

Introspeccin
anlisis de protocolo
documentacin, otros sistemas

14

Requisitos del software

Clasificacin de los requisitos
REQUISITO
FUNCIONALES
RESTRICCIN

REQUISITO
TIPOS DE REQUISITOS

NO FUNCIONALES
RESTRICCIN

REQUISITO
DE INTERFAZ
RESTRICCIN

Requisitos funcionales
Definen el comportamiento del sistema.
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad,
insuficiencia de detalle o ambigedad, y el exceso de detalle con precisiones o descripciones
innecesarias o redundantes.

15

Requisitos del software

Clasificacin de los requisitos

Requisitos no funcionales
Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan
deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:

Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento.
etc.

Requisitos de interfaz
Definen las interacciones del sistema con su entorno:

Usuarios
Otros sistemas

16

Requisitos del software

Clasificacin de los requisitos

Restricciones
Los requisitos, en su definicin purista definen el QU, y no el CMO; pero en el conjunto de
necesidades que debe cubrir un sistema, no slo hay que tener en cuenta QU cosas hay que
hacer, sino tambin en ocasiones CMO deben hacerse.
La clasificacin entre requisitos puros (QU) y restricciones (CMO) la debe considerar el analista
para que el equipo de trabajo sepa hasta qu punto determinados aspectos limitan sus opciones de
trabajo, y poder mantener as la trazabilidad con su origen (necesidad apuntada por el usuario,
normativa legal, limitacin tcnica, etc.)
Con carcter general las restricciones imponen limitaciones:

En la libertad de los analistas al realizar el diseo del sistema.

En los procesos o formas de trabajar que se emplearn en el desarrollo del sistema.

El analista del sistema elige entre todas las opciones tecnolgicamente posibles aquellas que segn
su criterio profesional y las circunstancias del sistema, aportan mejor solucin para la
implementacin de los requisitos funcionales y no funcionales.
La indicacin por parte del cliente de instrucciones como:
Debe emplearse base de datos Oracle.
Los procesos de desarrollo deben ser conformes a Mtrica 3.
El sistema final debe ejecutarse sobre la plataforma libre Linux.
Debe desarrollarse empleando Java.
El interfaz de comunicacin con un programa externo de contabilidad debe hacerse de la siguiente
forma...
17

Requisitos del software

Clasificacin de los requisitos

Problemas

de clasificacin y nivel de rigor necesario

Para nosotros la base terica de clasificacin es un marco de referencia con la definicin de los
criterios de clasificacin.
En la relacin de requisitos de un sistema, no resulta interesante entrar en anlisis puristas para
determinar si cada requisito lo es de interfaz, funcional, etc.
La diferencia entre:
El sistema comprueba la autentificacin y autorizacin del usuario y le da acceso a una
pantalla con el men general o en caso de error le redirige a la pantalla de usuario y
contrasea otra vez
Y:
RS. 3 El sistema slo permite el acceso al men principal a usuarios autorizados.
RT.3.1 El sistema identifica al usuario solicitando a travs de la pantalla de operacin
su nombre y contrasea de acceso.
En el segundo caso, el equipo de trabajo sabe que debe descartar opciones de identificacin a
travs de tarjetas, o dispositivos biomtricos, o cualquier otra opcin posible.
Se trata por tanto de conocer y comprender el concepto de restriccin, para aplicarlas
slo cuando son necesarias, dejando as el mayor margen posible de libertad para el
diseo de la solucin de software.
18

Requisitos del software

Calidad de la documentacin

Caractersticas

de las buenas descripciones de requisitos

Especificacin

Requisitos
Posibles

Completa

Necesarios

Correcta

Priorizados

Consistente

Concretos

Modificable

Verificables

Trazable

19

Requisitos del software

Propiedades de los buenos requisitos
Posibles
Cada requisito debe poder implementarse dentro de las capacidades y limitaciones conocidas
del sistema y su entorno. El director tcnico deber comprobar la viabilidad de los requisitos
antes de comprobar el documento.

Necesarios
Un requisito es necesario si es algo:

que el cliente realmente necesita

requerido para la conformidad con un requisito
requerido para la conformidad con un interfaz,

Alto

externo o estndar.

Para evitar requisitos innecesarios,

el cliente debe valorar cada
funcionalidad y como afectar
al sistema si esta o no.

Coste

Valor

Alto
20

Requisitos del software

Propiedades de los buenos requisitos
Requisitos priorizados
Los requisitos de una SRS deben incluir una indicacin de la importancia del requisito en el
conjunto del sistema.
Normalmente todos los requisitos de un producto de software no son igual de importantes.
Algunos resultan esenciales, y otros son deseables.
Cada requisito debe identificar estas diferencias de forma clara, de esta forma ayuda a:

Los clientes tengan una consideracin ms adecuada de cada requisito, y a menudo

clarifica asunciones que pudieran estar ocultas.

Que los desarrolladores tomen decisiones de diseo correctas y dediquen niveles de

esfuerzo apropiado a las diferentes partes del producto.

Que el gestor del proyecto pueda establecer prioridades de ejecucin, y disponga de

informacin adicional en caso de problemas de agenda.

21

Requisitos del software

Propiedades de los buenos requisitos
Concretos

Punto ptimo: Mayor grado de comprensin con la

menor ambigedad

Comprensin

Un requisito es concreto si tiene una nica interpretacin. Como mnimo esto requiere que cada
caracterstica del producto final se describa empleando un trmino nico. En los casos en los
que el trmino puede tener diferentes significados segn el contexto, ste debe incluirse en el
glosario de la SRS con el significado con el que se emplea.

Punto
ptimo

Ambigedad

Modos eficaces de evitar la ambigedad:

Inspecciones formales de los documentos de requisitos.

Escritura de casos de prueba
Elaboracin de casos de uso.
Elaboracin de diagramas.
22

Requisitos del software

Propiedades de los buenos requisitos
Verificable
Un requisito es verificable si, y slo si a travs de un proceso concreto y finito es posible
comprobar si el software lo cumple. En general los requisitos ambiguos no son verificables.
Los requisitos no verificables incluyen sentencias como que trabaje eficientemente,interfaz de
usuario amigable, debe responder rpidamente. Estos requisitos no son verificables porque no
es posible definir los trminos eficiente, amigable, rpido. La sentencia el programa no
debe entrar nunca en un bucle infinito tampoco es verificable porque un nivel de pruebas
absoluto es tericamente imposible.
Un ejemplo de requisito verificable es:
El tiempo de respuesta para la compra de un billete sencillo no debe superar los 2 segundos el
90% de las veces, y una transaccin de compra de un billete sencillo nunca debe tardar ms de
5 segundos.
Esta sentencia es verificable porque emplea trminos concretos y magnitudes medibles y
comprobables.
Si no es posible establecer un mtodo para comprobar si el software cumple con un
determinado requisito, el requisito debe eliminarse o revisarse

23

Requisitos del software

Propiedades de la documentacin
Completa
Una SRS es completa si, y slo si incluye los elementos siguientes:

Todos los requisitos significativos, relativos a funcionalidad, rendimientos, restricciones

de diseo, atributos e interfaces externos.

Definicin de las respuestas del software a todas las posibles entradas de datos en toda
clase de situaciones. Es importante especificar las respuesta tanto para datos de
entrada vlidos, como invlidos.

Referencias a todas las imgenes, tablas y diagramas y definicin de todos los trminos
propios y unidades de medida no normalizadas.

No puede considerarse completa una SRS si en la descripcin de algunos requisitos se incluye la

frase A determinar o la expresin inglesa TBD (to be determined).
Si excepcionalmente se indica que un requisito se concretar ms adelante es necesario indicar
tambin:
Descripcin de las causas por las que no se ha concretado el requisito.
Descripcin de qu debe realizarse para poder eliminar el TBD, quin es la persona
responsable de llevarlo a cabo, y cundo debe eliminarse

24

Requisitos del software

Propiedades de la documentacin
Completos
Conocemos

No Conocemos
Entrevistas y revisiones

Entendemos

Este bloque pertenece a

los requisitos que
conocemos y sabemos
que son aplicables al
problema

Este bloque pertenece a

los requisitos que
conocemos pero no
conocemos, es decir que
sabemos que existen pero
no hemos realizado su
anlisis.

Prototipado

Prototipado y
casos de uso

No Entendemos

Este bloque pertenece a

los requisitos que
sabemos que son
aplicables al problema
pero que no entendemos

Este bloque pertenece a

los requisitos que no
conocemos y tampoco
sabemos que no
conocemos

25

Requisitos del software

Propiedades de la documentacin
Correcta
Una especificacin de requisitos de software es correcta si, y solo si todos y cada uno de los
requisitos indicados son los que debe cubrir el software del sistema.
No hay ninguna herramienta que pueda garantizar la correccin. Una SRS debe compararse con
las especificaciones de rango superior del proyecto (Descripcin del sistema, documentacin
referenciada, etc.) para comprobar que cumple sus indicciones.
Tambin es recomendable que la parte cliente determine si la especificacin de requisitos de
software refleja sus necesidades actuales
Necesidades
del Usuario

A
B

B
Revisin y aprobacin

Requisitos
Correctos

C
Requisitos
Especificados
26

Requisitos del software

Propiedades de la documentacin
Consistente
El atributo de consistencia se refiere a consistencia interna no a conformidad o congruencia con
documentos superiores (ej. descripcin del sistema). La ausencia de esta congruencia supondra
un problema de correccin y no de consistencia.
Una documentacin es internamente consistente si, y solo si, no se establecen conflictos entre
requisitos individuales o grupos de requisitos. Los tres tipos de conflictos posibles son:

Conflictos

Objetos

Lgicos

C=A+B
C=A*B

Trminos
RF 10 Informe A
cierre de caja
RF 50 Informe A
cierre diario de operaciones

27

Requisitos del software

Propiedades de la documentacin
Modificable
Un documento de requisitos es modificable si, y slo si su estilo y estructura permiten que
puedan llevarse a cabo modificaciones en los requisitos manteniendo la estructura y el estilo, de
forma fcil, completa y consistente. La modificabilidad generalmente requiere en la
documentacin:
Que tenga una organizacin coherente y fcil, con una tabla de contenidos y un ndice..
Que no sea redundante. (p. ej. que el mismo requisito no aparezca en dos lugares del
documento)
Exprese cada requisito por separado, mejor que mezclados con otros requisitos.
La redundancia, por s misma no es un error, pero puede acarrearlos. En ocasiones la
redundancia puede hacer un SRS ms legible, pero puede generar errores al actualizar el
documento, y generar inconsistencias si slo se actualiza una de las apariciones, olvidando la
otra.

28

Requisitos del software

Propiedades de la documentacin
Trazable
Un SRS es trazable si establece de forma clara el origen de cada requisito, y facilita su
referencia en las futuras etapas del desarrollo, o en las actualizaciones de la documentacin. Se
recomiendan los dos tipos siguientes de trazabilidad:
Trazabilidad remota (hacia fases previas del desarrollo). Para ello se debe referenciar la fuente
del requisito.
Trazabilidad futura (hacia fases posteriores del desarrollo). Para ello cada requisito debe tener
un nombre o referencia nica.
La trazabilidad remota es importante cuando el producto de software entra en la fase de
operacin y mantenimiento. Al modificar el diseo y el cdigo es esencial poder determinar
todos los requisitos que quedan afectados por una modificacin

29

Requisitos del software

Conclusiones
OBJETIVO

Desarrollar software

Desarrollar una
solucin

Tomar requisitos
del usuario

Comprender el entorno
y necesidades del usuario

Realizar procesos
normalizados para el
desarrollo de requisitos

Descripcin de requisitos
correcta

30

Requisitos del software

Conclusiones

MEDIOS

Aplicar tcnicas
y procesos

FIN

Conseguir
el objetivo

31

REQUISITO
FUNCIONALES
RESTRICCIN

REQUISITO
TIPOS DE REQUISITOS

NO FUNCIONALES
RESTRICCIN

REQUISITO
DE INTERFAZ
RESTRICCIN

Actividad
Para una biblioteca universitario de un ejemplo para cada uno de los
tipos de requisitos (requisito y restriccin).

32

Preguntas

Qu hemos aprendido?

Reflexionemos