Contenidos

2.1 Tipos de requisitos.

2. Requisitos

2.1.1 Requisitos de usuario y del sistema

2.1.2 Requisitos funcionales y no funcionales.

2.2 Actividades de la Ingeniera de Requisitos

2.3 Elicitacin de Requisitos
2.2.1 Entrevistas.
2.2.2 Herramientas. Diagramas de actividades

Ingeniera del Software I

3 I.T.I.Gestin

2.4 Validacin y gestin de requisitos

2.5 El documento de requisitos

Miguel A. Laguna

Problema y Solucin

Ingeniera de Requisitos
Espacio del

Problem
Problema

Problema

Usuarios

Objetivos
Requisitos
Software
Test

sistema
nuevo

Espacio de
la Solucin

Trazabilidad

Diseo

Los requisitos determinan

lo que har el sistema (cmo funcionar)
restricciones sobre su operacin e
implementacin.

La elicitacin, anlisis y especificacin de

requisitos es el proceso del estudio de las
necesidades de los usuarios para llegar a una
definicin de los requisitos del sistema

Doc.
3

Qu es un requisito?

Qu es un requisito?

Un requisito es una condicin o capacidad

que necesita el usuario para resolver un
problema o conseguir un objetivo
determinado.

Puede verse como

Tambin se aplica a las condiciones que debe

cumplir o poseer un sistema o uno de sus
componentes para satisfacer un contrato, una
norma o una especificacin.
5

una declaracin abstracta de alto nivel de un

servicio que el sistema debe proporcionar
una definicin matemtica detallada y formal de
una funcin del sistema.

Los requisitos cumplen una doble funcin

Son una oferta de contrato -> abiertos a la
interpretacin
Son el contrato en s mismo -> deben definirse de
forma detallada
6

Tipos de requisitos
Requisitos de usuario
Declaraciones en lenguaje natural y en diversos diagramas
de los servicios del sistema y de las restricciones bajo las
que debe operar.

2.1 Tipos de requisitos

Requisitos
q
del sistema
Un documento estructurado que determina las descripciones
detalladas de los servicios de sistema.
Escrito como contrato entre el cliente y el desarrollador
Deben ser una especificacin completa y consistente del
sistema
Especificacin del software: descripcin detallada del
software que sirve de base a los desarrolladores para
disear el sistema .

Requisitos de usuario y del sistema

Requisitos funcionales y no funcionales
(Reglas y requisitos de informacin)

Requisitos de usuario y del sistema

Requisitos funcionales y no funcionales

Un requisito de usuario

Entradas

1.- El sistema debe permitir representar y acceder a archivos

externos creados por otras herramientas

Salidas

Sistema

Requisitos del sistema asociados

1.- El usuario deber poder definir el tipo de un nuevo archivo externo.
2.- Cada tipo de archivo tendr una herramienta asociada, que se aplicar
al archivo.

Funcionalidad

3.- Cada tipo de archivo se representar con un icono especfico.

RNF

4.- El usuario deber poder definir el icono que representa un tipo de

archivo externo.
5.- Cuando el usuario selecciona un icono que representa un archivo
externo, el efecto es aplicar la herramienta asociada con este tipo de
archivo al archivo representado por el icono seleccionado.
9

Requisitos funcionales y no funcionales

10

Requisitos funcionales
Describen el funcionamiento del sistema

Requisitos funcionales (RF)

Definicin de los servicios que el sistema
debe proporcionar, cmo debe reaccionar
a una entrada particular y cmo se debe
comportar ante situaciones particulares.

Requisitos no funcionales (RNF)

Restricciones que afectan a los servicios o
funciones del sistema, tales como
restricciones de tiempo, sobre el proceso
de desarrollo, estndares, etc.
11

Los RF del usuario pueden ser frases muy

generales sobre lo que el sistema debera
hacer. Se suelen expresar como objetivos del
sistema.
Los RF del sistema deben describir los
servicios que hay que proporcionar con todo
detalle: los casos de uso
12

Requisitos no funcionales

Ejemplos de requisitos funcionales

1. Se deben poder realizar bsquedas en
base a diferentes criterios.

Definen propiedades emergentes del sistema, tales

como el tiempo de respuesta, las necesidades de
almacenamiento, la fiabilidad,
Pueden especificar tambin la utilizacin de una
herramienta CASE en particular, un lenguaje de
programacin o un mtodo del desarrollo.

2. Se deben proporcionar diferentes

visores p
para que
q el usuario lea los
documentos recuperados.
3. Cada factura tendr un nmero nico
y correlativo y la fecha.

Pueden ser ms crticos que los funcionales.

Si un R. funcional no se cumple, el sistema se degrada
Si un R. no funcional no se cumple, el sistema puede
inutilizarse

13

Clasificacin de los requisitos no

funcionales

14

Ejemplo de requisitos no funcionales

1.

Requisitos del producto

Especifican el comportamiento del producto obtenido:
velocidad de ejecucin, memoria requerida, porcentaje de
fallos aceptables,

Requisitos organizacionales
Son una consecuencia de las polticas y procedimientos
existentes en la organizacin: procesos estndar utilizados,
de fechas de entrega, documentacin a entregar,

Requisitos externos

Requisito del producto

4.C.8 Se utilizar en todas las comunicaciones el
conjunto de caracteres ADA estndar

2.

Requisito
q
organizacional
g
9.3.2 El sistema se debe desarrollar de acuerdo
con el proceso estndar XYZCo-SP-STAN-95.

3.

Requisito externo
7.6.5 El sistema no divulgar a los operadores
ninguna informacin personal sobre los
clientes aparte de su nombre y su nmero de
referencia.

Presentan factores externos al sistema y a su proceso de

desarrollo: interoperabilidad del sistema con otros, requisitos
legales, ticos,
15

Requisitos verificables

16

Ejemplo: RNF verificables

Los requisitos no funcionales pueden ser muy

difciles de expresar con exactitud.
Los requisitos imprecisos pueden ser difciles
d verificar
de
ifi

1.

Un deseo general del usuario es, por ejemplo, la

facilidad de uso

2.

Requisito no funcional verificable

Una frase que incluye alguna medida que puede
ser objetivamente probada
17

RNF imprecisos (una primera versin)

-

Los usuarios especializados debern utilizar el sistema

fcilmente.

El sistema deber estar organizado para minimizar los

errores del usuario.
RNF verificables (detallados)

Los usuarios experimentados debern poder utilizar

todas las funciones del sistema despus de un total de
dos horas de entrenamiento.

Despus de este entrenamiento, el nmero medio de

errores cometidos por los usuarios experimentados no
exceder de dos por da.
18

Una gua bsica de RNF: [F]URPS

Funcionality

Requisitos funcionales

U sability

Human factors aesthetics, consistency,

documentation

R eliability
(Fiabilidad)

Frequency/severity of failure,
recoverability, predictability, accuracy,
MTBF

P erformance
(Rendimiento)

S upportability
(Soporte)

[F]URPS, ejemplo
Facilidad de uso (usability)
Se debe ver el texto fcilmente a una distancia de 1
metro

Fiabilidad ((reliability)
y)
Si se produce algn fallo al usar un servicio externo
(autorizacin de pago) solucionarlo localmente

Speed efficiency, resource usage,

throughput, response time

Rendimiento (performance)

Testability
Adaptability
Compatibility
Serviceability
Localizability

Soporte (supportability)

conseguir la autorizacin de pago en menos de 1

minuto, el 90% de las veces

Extensibility
Maintainability
Configurability
Installability
Robustness

El sistema debe ser instalable por los usuarios.

19

Reglas del negocio

y Requisitos de informacin

20

Reglas de negocio en diversos

dominios

Las reglas del negocio describen las caractersticas

del dominio en el que se encuadra la organizacin.
Pueden ser requisitos funcionales, restringir los existentes o
definir clculos particulares.
Si las reglas
g
del negocio
g
no se satisfacen,, el sistema puede
p
no trabajar de forma satisfactoria.

1.

Restriccin a un requisito funcional:

Habr una interfaz del usuario estndar para
todas las bases de datos, que tomar como
referencia el estndar Z39.50.

2.

Restriccin legal:
Debido a las restricciones en los derechos de
autor, algunos documentos se deben suprimir
inmediatamente despus de su llegada.

Los requisitos de informacin son tambin formas

especializadas de requisitos:
el sistema guardar informacin sobre los socios del
videoclub, en concreto DNI, nombre)

3.

Clculo particular:
La desaceleracin del tren se calcula como:
Dtren = Dcontrol + Dgradiente

21

Requisitos de informacin

22

Guas para escribir requisitos

Inventar un formato estndar y utilizarlo para
todos los requisitos
Utilizar el lenguaje de forma consistente.
Distinguir entre los requisitos obligatorios y
los deseables.
Resaltar el texto para identificar las partes
claves del requisito.
Evitar el uso de lenguaje tcnico.

IRQ02: Informacin sobre un socio de un

videoclub

Nmero de socio
Nmero del DNI
Nombre y apellidos
Fecha de nacimiento
Sexo
Fecha de alta como socio
Direccin
Telfonos
Pelculas alquiladas en un momento dado
23

24

Ejemplo: Un catlogo de
requisitos

Ejemplo: Un catlogo de
requisitos

Requisitos Funcionales.

Funciones principales del sistema

Mantenimiento de datos de socios.

Generacin de facturas con periodicidad
variable (1, 2, 3, 6, 12 meses) a partir de
cualquier mes.

Funciones de consultas

Socios, facturas e impagados

Lista detallada de facturas impagadas para

poder proceder a su reclamacin

Facturacin con el formato exigido por la Caja

de Ahorros.

Facturacin mensual para recibos corrientes, y

en cualquier momento para no corrientes

F
Funciones
i
de
d informacin
i f
i

Socios (datos personales, bancarios, cuota y

periodicidad)

Facturas (todas las facturas emitidas, sean

cobradas o pendientes de pago)

25

26

Ejemplo: Un catlogo de
requisitos

Ejemplo: Un catlogo de
requisitos

Funciones de interaccin con otros sistemas

Caja de ahorros: disco con formato normalizado

para realizar la facturacin

Programa de contabilidad, para realizar los

asientos correspondientes a cada mes

Requisitos No Funcionales.

De rendimiento

27

Ejemplo: Un catlogo de
requisitos

De seguridad
Control de accesos: Una palabra clave para el
usuario (secretaria)

Copias de respaldo: No especificado

Volumen de 500 socios

De frecuencia de tratamiento

Facturacin mensual tpica de 250 socios, con

picos de hasta 5000

Los impagados suelen ser el 2% del volumen

total facturado al mes
28

Imprecisiones en los requisitos

No se especifican detalles

I t id d d
Integridad
de la
l informacin:
i f
i No
N especificado
ifi d

Aparecen problemas cuando los requisitos no

se precisan con exactitud
Los requisitos expresados de forma ambigua se
pueden interpretar de manera diferente por los
d
desarrolladores
ll d
y por los
l usuarios
i

De comunicaciones

Ninguno. Todas las aplicaciones funcionan en el

mismo computador

29

Objetivo: La especificacin debe ser completa

y consistente
Completa: Todos los servicios solicitados por el
usuario estn definidos.
Consistente: Los requisitos no tienen definiciones
contradictorias.
30

Problemas con el lenguaje

natural

Ejemplos de mezcla de requisitos

Falta de claridad

En el siguiente ejemplo se mezclan requisitos de usuario

con requisitos del sistema:

La precisin es difcil sin hacer el

documento ilegible.

4.A.5

Confusin de requisitos
Los requisitos funcionales y no funcionales
tienden a estar mezclados.

Conjuncin de requisitos
Varios requisitos se pueden expresar
juntos, como un nico requisito.

La base de datos debe soportar la generacin y

el control de la configuracin de aquellos
elementos que agrupaciones de otros elementos
que tambin estn en la base de datos.
Este control de la configuracin debera permitir
al usuario acceder a los elementos de una
determinada versin sin especificar su nombre
completo.

31

32

Ambigedad

Ejemplos de requisitos

Un requisito debe tener una nica

interpretacin

En el siguiente ejemplo aparecen requisitos

funcionales y no funcionales

A deber hacer B

2.6
Para ayudar en la ubicacin de una entidad en
un diagrama, el usuario activar una cuadrcula
en centmetros o en pulgadas, mediante una
opcin en el panel de control.

A deber hacer B

Inicialmente, la cuadrcula estar desactivada. La

cuadrcula se podr activar o desactivar
enel sistema
RNF:
cualquier momento y ponerse en centmetros
o
deber soportar
en pulgadas.
distintos sistemas
de unidades

A deber hacer B

33

Ambigedad: un ejercicio

34

Definiciones del diccionario

Mara tena un cordero

Tena, del verbo Tener

1. tr. Asir o mantener asido algo.
2. tr. poseer ( tener en su poder).
3. tr. mantener ( sostener). U. t. c. prnl.
4. tr. Contener o comprender en s.
5 tr.
5.
tr dominar ( sujetar).
sujetar)
6. tr. guardar ( cumplir). Tener la palabra, la promesa
7. tr. hospedar ( recibir huspedes).
8. tr. Estar en precisin de hacer algo u ocuparse en ello. Tener clase Tener junta
9. tr. Juzgar, reputar, considerar. Tener a alguien POR rico. Tener A gala, A honra algo. U.
t. c. prnl. Tenerse POR sabio
10. tr. Estimar, apreciar. Tener EN POCO, EN MUCHO. U. t. c. prnl.
11. tr. Emplear, pasar algn espacio de tiempo en un lugar o sitio, o de cierta manera.

Tener las vacaciones en Barcelona Tener un da aburrido

Gause & Weinberg, 1989

35

12. tr. experimentar. Tener cuidado, vergenza, miedo, hambre, calor, nervios
.
36

Ambigedad y
comprensibilidad

Definiciones del diccionario

cordero.
(Del lat. vulg. *cordarius, der. de cordus, tardo).
1. m. Hijo de la oveja, que no pasa de un ao.
2. m. Piel de este animal adobada.
3. m. Hombre manso, dcil y humilde.
4. m. por antonom. Jesucristo, Hijo de Dios.

comprensibilidad

Ambigedad
37

38

Alternativas al lenguaje
natural
Lenguaje natural estructurado
Mantiene la expresividad y comprensin del
lenguaje natural
Delimita la terminologa utilizada y emplea
plantillas.
Se describen los objetos que manipula el sistema,
las funciones que ejecuta y los eventos que
procesa.

2.2 Actividades de la Ingeniera

de Requisitos

Notaciones grficas
Se utiliza un lenguaje grfico, complementado con
anotaciones en lenguaje natural estructurado.
39

Actividades de la Ingeniera de
Requisitos

Un esquema general
Entrevistas con
los
Stakeholders

Definicin del
Problema

Sin embargo, hay un nmero de actividades

genricas comunes a todos los procesos

Documento de
Vision

Requisitos Func.

Modelo de
casos de uso

Los procesos utilizados en Ingeniera de Requisitos

varan dependiendo del dominio de aplicacin, de la
gente implicada y de la organizacin que desarrolla
los requisitos

Req. NF

Modelo de
dominio

Especificacin de
requisitos

41

Estudio de viabilidad
Elicitacin (extraccin o captura) de Requisitos
Anlisis de Requisitos
Validacin de Requisitos
Gestin de Requisitos

42

Elicitacin y anlisis de
requisitos

Estudio de viabilidad
El estudio de viabilidad permite decidir si el
sistema propuesto es conveniente
Es un estudio rpido y orientado a conocer:
si el sistema contribuye
y a los objetivos
j
de la
organizacin
si el sistema se puede realizar con la tecnologa
actual y con el tiempo y el coste previsto
si el sistema puede integrarse con otros existentes

Elicitacin (o extraccin o captura o determinacin)

de requisitos:

El proceso mediante el cual los usuarios descubren, revelan,

organizan y comprenden los requisitos que desean.
Tcnicas: observacin, entrevistas, herramientas CASE (REM
y UML)

Anlisis de requisitos:

El proceso de razonamiento sobre los requisitos obtenidos

en la etapa anterior, detectando y resolviendo posibles
inconsistencias o conflictos, coordinando los requisitos
relacionados entre s, etc.
Tcnicas: diferentes representaciones grficas (UML) y
tcnicas de revisin

43

Validacin y gestin de
requisitos

44

Elicitacin

Validacin de los requisitos:

El proceso de confirmacin, por parte de los usuarios, de

que los requisitos especificados son vlidos, consistentes,
completos, etc.
Tcnicas: Listas de comprobacin
p
y tcnicas de revisin.

Gestin de Requisitos:

es el proceso de manejar los requisitos que cambian durante

el desarrollo del sistema
Tcnicas: Herramientas CASE (REM)

En esta etapa, se trata de descubrir los

requisitos
El personal tcnico trabaja con los clientes y
usuarios para descubrir el dominio de la
aplicacin los servicios que se deben
aplicacin,
proporcionar y las restricciones
Puede implicar a usuarios finales,
encargados, ingenieros implicados en el
mantenimiento, expertos del dominio, etc.
Son los llamados participantes o interesados
(stakeholders).

45

46

Etapas en la elicitacin de
requisitos

Problemas
Los participantes no conocen realmente lo
que quieren
Los participantes expresan los requisitos con
sus propios trminos
Diferentes participantes pueden tener
requisitos conflictivos
Factores polticos y organizativos pueden
tener influencia en los requisitos
Los requisitos cambian durante el anlisis.
Pueden aparecer nuevos participantes y
cambiar el entorno del negocio
47

1: Obtener informacin sobre el dominio del

problema y el sistema actual.
2: Preparar y realizar las reuniones de
elicitacin/negociacin.
3: Identificar/revisar los objetivos del sistema.
4: Identificar/revisar los requisitos de informacin.
informacin
5: Identificar/revisar los requisitos funcionales.
6: Identificar/revisar los requisitos no funcionales.
7: Priorizar objetivos y requisitos.
Metodologa de elicitacin de requisitos (Amador
Durn, 2003)
48

Entrevistas,
Flujos de
trabajo

2.3 Elicitacin de Requisitos

La entrevista
Herramientas grficas
Casos de
uso

49

Talleres de requisitos
(Workshops)

Tcnicas de elicitacin

Busca un acuerdo general sobre el alcance, riesgos, y

las caractersticas importantes del sistema de
software.

Requisitos

?
?
?
?
?

Entrevistas

Talleres de
discusin

System
Requirement
sds

Son dirigidos por un facilitador.

Duracin: tres a cinco de das

Cuestionarios,
fichas, etc.

Artefactos creados:
declaracin de problema
objeto de negocio
diagrama de Casos de uso
lista de riesgos

lNeed

Storyboards, Flujos de trabajo

Ventajas:
Resultados muy pronto

Prototipos

52

La entrevista

Entrevistas a la direccin
Objetivos:

Los objetivos de la etapa de elicitacin son dos:

Conocer a fondo el departamento donde la empresa necesita

mejorar.
Realizar un censo exhaustivo de las necesidades del sistema
que se quiere informatizar

Cada persona del departamento tiene su propia

visin del sistema.

La direccin, global pero difusa; los trabajadores, parcial

pero concreta

Resultados: Visin del proyecto

Las tcnicas de recogida inicial de informacin son:

Observacin directa
Estudio de los documentos
Revisin de los ficheros que se manejan actualmente
Sobre todo, las entrevistas.

primer conocimiento
censo de objetivos deseados
organigrama de puestos de trabajo
interfaces con otros proyectos
delimitar en lo posible el campo de estudio
Entrevistados: jefe de rea, de servicio, de negociado,...
Tcnica: informal, periodstica

53

objetivos principales
lista de puestos de trabajo
campo de estudio
restricciones: medios, calendario, legislacin, etc.

54

Entrevistas a puestos de
trabajo

Fichas de entrevista

Objetivos:

El contenido de una ficha de entrevista a un puesto

de trabajo ser:
Identificacin

operaciones efectuadas (Lista de Tareas)

eventos peridicos
datos y documentos/informaciones manipuladas
qu puestos intervienen
tambin mensajes electrnicos, telefnicos, fax,...
reglas del negocio
lenguaje de la empresa

Persona
Departamento
Empleo

Entrevistados: contable, administrativo, agente de ventas,

etc.

Operaciones que realiza y descripcin

Documentos enviados y recibidos desde el puesto
(incluidos los documentos orales) y descripcin
nombre
origen y destino
periodicidad
volumen
conservacin/destruccin

Tcnica: Se debe intentar estructurar la informacin recibida,

mediante fichas, representacin grfica...

55

56

Ejemplo Restaurante:
pedidos a proveedores.

Herramientas auxiliares
Matriz de flujos:
En ella, se representan tanto los actores externos
como los internos y cmo fluye la informacin
entre ellos

Diagrama de flujos de trabajo (diagrama de

actividades de UML)
Se asignan actividades a los actores externos e
internos. Los resultados de las actividades (la
informacin que fluye) se representan como
objetos
Permite la reorganizacin de los flujos de trabajo

El encargado del restaurante, cada martes y jueves

confecciona los pedidos a los proveedores con todo
aquello que est bajo mnimos y en funcin de los
mens de la prxima semana.
Dispone de una ficha por cada producto y una vez
hecho el pedido (fax o telfono), guarda una copia
en la carpeta de pendientes.
Cuando un pedido llega al almacn, el almacenista
comprueba el albarn de entrada y si es correcto se
lo pasa al encargado.
Al final de cada da, el encargado actualiza las fichas
de producto y la carpeta de pendientes con los
albaranes revisados.

57

Documentacin de actividades
Descripcin de la actividad
y condiciones de disparo

Puesto de
Trabajo

Frecuencia y
duracin

Entrada

Salida

Hacer pedido
cada jueves 9:00

Encargado

10 min

Ficha,
Mens

Pedido,
Pedidos ptes.

Recepcin de pedidos y
control cuando llega
Albarn

Almacn

2 3 diarias,
45

Albarn

Albarn
revisado

Actualizar pendientes y
fichas, al final del da

Encargado

30

Albarn rev,
Ficha,
Pedidos ptes.

Ficha,
Pedidos ptes.

Control facturas,
cuando llega factura

Encargado

2 3 diarias,
5

Factura,
Pedidos ptes.

Pedidos ptes.
Orden de
pago

Pagar,
los das 1, 10 y 20 del mes

Contable

10-12 cada vez

Orden de
pago

Transferencia
59

58

Matriz de Flujos
De . A

Encargado

Almacn

Proveedor

factura

albarn

Encargado Pedido

Pedidos ptes.
ptes
Fichas producto

Almacn

Albarn
revisado

Contable

Proveedor

Contable

orden de
pago

Transferencia
60

10

Proveedor

Almacn

Ejemplo Restaurante:
pagos a proveedores.

Encargado
[Ficha Producto]

actor externo

[Menu]

Hacer pedido
Servir Pedido

Las facturas llegan directamente de los

proveedores al encargado.
El encargado comprueba las facturas y,
si son correctas
correctas, da la orden de pago al
contable, que hace la transferencia
efectiva.

jueves

[Pedido]
[Pedidos Ptes.]

[Albarn]

Recepcin
final del da
[Albarn Rev.]

Actualizar ptes y ficha

[Ficha Producto]
[Pedidos Ptes.]

Proveedor

Pagos

A ctor externo

Encargado

61

Contable

Escenarios y casos de uso

[Pedidos Ptes.]

Facturar

[Factura]

Las actividades representan los requisitos

funcionales pero no estn detalladas

Control facturas
dias 1, 10, 20
[O rden de pago]

62

Pago

[T ransferencia]

Los escenarios son descripciones de cmo se

utilizar
l
ell sistema en la
l prctica

(completan
(
l
o sustituyen los requisitos funcionales)
Las personas comprenden mejor los
supuestos que presentan situaciones en las
que se interacciona con el sistema

63

Casos de Uso

64

Requisitos de Informacin

Los casos de uso son una tcnica de

escenarios incorporada en UML que describe
la interaccin entre los actores y el sistema
Un conjunto de casos de uso describe todas
las posibles interacciones con el sistema
Describen lo que puede ir mal y cmo
manejar el problema
65

Se trata, aqu, de recopilar todos los

datos con los que trabaja la
organizacin y que soportan
informacin
Hay que distinguir muy claramente lo
que es documento (es soporte de
informacin) de lo que es dato (es la
informacin)
66

11

Documento y datos

Diccionario de Datos

XXXXXXXXXXX
CIF 99999999

Nombre

Nombre Proveedor

Definicin

Es el nombre del proveedor que suministra los

productos.

Ref. : XXX

Factura

Fecha 99/99/99
Importe:
Iva:

999.999
999.999

Total:

999.999

Estructura

Cadena de 40 caracteres alfanumricos.

Tipo

Elemental

Nombre del proveedor

Cuantificacin

~ 100

CIF del proveedor

Ejemplos

Coca-Cola, Carrefour,...

Nmero de referencia

Comentarios

Problemas de duplicacin
restricciones
lista de valores
reglas de clculo (si el dato es calculado)
controles
varias definiciones (sinnimos, polisemias)

Fecha factura
Importe factura
IVA factura
Total factura

67

68

Validacin de requisitos
2.4 Validacin y gestin de
requisitos

Se trata de demostrar que los requisitos

definen el sistema que el cliente realmente
desea
L costes de
Los
d los
l errores en los
l requisitos
i i
son
altos; la validacin es muy importante
La deteccin de un error de los requisitos despus
de la entrega del producto puede llegar a costar
hasta 100 veces el coste de la deteccin de un
error en la implementacin

70

Controles sobre los requisitos

Controles sobre los requisitos

Comprensibilidad.

Validez.

Se ha comprendido adecuadamente el requisito?

El sistema proporciona las funciones que

soportan las necesidades de los clientes?

Trazabilidad.
El origen del requisito est claramente
e t ble ido?
establecido?

C
Completos.
l t
Estn recogidas todas las funciones solicitadas?

Consistencia.
Hay conflictos, contradicciones, en los requisitos?

Verificabilidad.

Adaptabilidad.
Se puede cambiar el requisito sin un gran
impacto en otros requisitos?

Realismo.
Pueden implementarse los requisitos con la
tecnologa y conocimientos actuales?

Pueden comprobarse los requisitos?

71

72

12

Planificacin de la gestin de los

requisitos

Gestin de los requisitos

La gestin de los requisitos es el proceso de
manejar los requisitos que cambian durante
el desarrollo del sistema
Los requisitos son, inevitablemente,
inconsistentes e incompletos
Emergen nuevos requisitos durante el proceso, las
necesidades del negocio cambian, hay una mejor
comprensin del sistema
Diversos puntos de vista afloran diversos
requisitos que pueden ser contradictorios

Durante el proceso de la ingeniera de

requisitos, hay que planear:
La identificacin de los requisitos
Un proceso de gestin de los cambios
Polticas de trazabilidad
La cantidad de informacin sobre las relaciones entre los
requisitos que se mantiene

Soporte de herramientas CASE

La herramienta de soporte necesaria para ayudar a
manejar los requisitos que cambian

73

Trazabilidad

74

Trazabilidad

Se refiere a las relaciones entre los requisitos,

sus fuentes y el diseo del sistema
Trazabilidad de las fuentes
Enlace desde los requisitos
q
a los participantes
p
p
que
q
los propusieron

Trazabilidad entre requisitos

Enlace entre requisitos dependientes

Trazabilidad del diseo

Enlace desde los requisitos al diseo

75

76

Soporte de herramientas CASE

Almacenamiento de los requisitos
Los requisitos se deben almacenarse en un
almacn seguro

2.5 El documento de
requisitos

Gestin de los cambios

Gestin de la trazabilidad
Recuperacin automatizada de los enlaces
entre los requisitos

77

13

El documento de requisitos

Caractersticas de una ERS

El documento de requisitos es la declaracin

oficial de lo que se necesita construir. Se
denomina Documento de Especificacin de
Requisitos del Software (ERS)
Incluye tanto los requisitos del usuario como
la especificacin detallada de los requisitos
del sistema.
NO es un documento de diseo:
Debe indicar QU es lo que el sistema debe hacer.
No debe indicar CMO va a hacerlo.

No ambigua.
Completa.
Fcil de verificar.
C
Consistente.
i t t
Fcil de modificar.
Facilidad para identificar el origen y las
consecuencias de cada requisito.
Facilidad de utilizacin durante la fase de
explotacin y mantenimiento.

79

80

Estructura del Documento de

Requisitos (1)

Estndar IEEE para la ERS

1 Visin

Introduccin
Descripcin general
Requisitos especficos.

1.1 Introduccin:
mbito y alcance del Proyecto. Describe la necesidad de crear el
sistema, las funciones y cmo trabajar con otros sistemas.

Cubren los requisitos funcionales, no funcionales y de

interfaz.
Documentan las interfaces externas, describen la
funcionalidad y el rendimiento del sistema, detallan los
requisitos lgicos de la base de datos, las restricciones del
diseo, las propiedades emergentes del sistema y las
caractersticas de calidad.

Apndices
ndice

1.2 Participantes en el proyecto

Tanto desarrolladores de software como clientes y usuarios

1.3 Objetivos del sistema

Los usuarios (y los sistemas externos) necesitan un sistema para
satisfacer sus objetivos

1.4 Visin general del producto

Presenta una visin global de alto nivel de la arquitectura prevista

del sistema

[1.5 Glosario de trminos]

Define los trminos tcnicos utilizados en el documento.

2 Resumen de entrevistas
81

Estructura del Documento de

Requisitos (2)

Ejemplo Larman: Visin

1.1 Introduccin:

3 Catlogo de requisitos del sistema

Servicios que se proveen al usuario y los requisitos no funcionales del
sistema

3.1 Requisitos funcionales

3.1.1 Diagrama de casos de uso
3 1 2 Definicin de actores
3.1.2
3.1.3 Casos de uso del sistema

Prevemos una aplicacin de punto de venta (PDV) tolerante

a fallos de prxima generacin, PDV NuevaEra, con
flexibilidad para poder soportar variacin en las reglas del
negocio del cliente, mltiples mecanismos de terminal e
interfaz de usuario, y la integracin con mltiples sistemas
de terceras partes.

Oportunidad del negocio:

3.2 Requisitos no funcionales

3.3 Requisitos de informacin

Los productos PDV existentes no son adaptables al negocio

del cliente, ... Adems, no permiten su extensin de manera
adecuada cuando se incrementan los terminales y crece el
negocio. Y ninguno permite trabajar en lnea o
desconectados, adaptndose dinmicamente dependiendo
de los fallos. ...

Diccionario de datos

3.4 Reglas de negocio (Requisitos del dominio )

Restricciones impuestas

[4 Matrices de rastreabilidad]
5 Modelo del Dominio
Modelo inicial de clases

82

83

84

14

Ejemplo Larman: Visin

Ejemplo Larman: Visin

1.4 Visin general del producto

1.2 Participantes en el proyecto

Descripcin del personal involucrado

Entrevistas:
Resumen del personal involucrado (No usuarios)...
Resumen de Usuarios...

El PDV NuevaEra residir, normalmente, en tiendas; si se

utilizan terminales mviles se encontrarn muy prximos a
la red de la tienda, en el interior o en el exterior.
Proporcionar servicios al usuario, y colaborar con otros
sistemas

1 3 Objetivos del sistema

1.3

Objetivo de alto nivel: El sistema deber procesar las

ventas de modo rpido, robusto e integrado
Objetivos secundarios: Los usuarios (y los sistemas
externos) necesitan un sistema para satisfacer sus objetivos:
Cajero: procesar las ventas, gestionar las devoluciones, abrir y
cerrar caja.
Administrador del sistema: gestionar los usuarios, gestionar la
seguridad, ...
Director: poner en marcha, suspender operacin.
Sistema de actividad de ventas: analizar los datos de las
ventas....
85

Ejemplo Larman: Visin

86

Ejemplo Larman: Visin

Resumen de las caractersticas del sistema

Entrada de ventas.
Autorizacin de pagos (crdito, dbito, cheque).
Administracin del sistema de usuarios, seguridad, cdigo y
tablas de constantes, etc
Procesamiento automtico de ventas sin conexin cuando
fallen los componentes.
p
Transacciones en tiempo real, basadas en estndares
industriales, con sistemas de terceras partes, que incluye los
servicios de inventario, contabilidad, recursos humanos,
impuestos, y autorizacin de pagos.

1.5 Glosario de trminos

Artculo

Un artculo o servicio en venta.

Autorizacin de pago

Validacin llevada a cabo por un servicio externo de autorizacin

de pago, que har o garantizar el pago al vendedor.

Solicitud de autorizacin de pago

Un compuesto de elementos enviados electrnicamente a un

servicio de autorizacin, normalmente como un array de
caracteres. Los elementos comprenden: ID de la tienda, nmero de
cuenta del cliente, cantidad y fecha.

Cdigo Universal de Producto

Cdigo de 12 dgitos que identifica un artculo. Normalmente se

representa mediante un cdigo de barras en los artculos. Dirjase a
http://www.uc-council.org para ver ms detalles.

87

Ejemplo Larman: Catlogo de

requisitos del sistema

88

Ejemplo Larman: Catlogo de

requisitos del sistema
3.2 Requisitos no funcionales

3.1 Requisitos funcionales

Seguridad

3.1.1 Diagrama de casos de uso

3.1.2 Definicin de actores
3.1.3 Casos de uso del sistema

Todo uso requiere la autenticacin de los usuarios.

3.2 Requisitos no funcionales

3.3 Requisitos de informacin
3.4 Requisitos del dominio

89

NFR-0001

Seguridad

Versin

1 0 ( 18/10/2006 )
1.0

Autores

Craig Larman

Fuentes

Cajero

Dependencias

[OBJ-0001] Procesamiento de ventas

Descripcin

El sistema deber requerir la autenticacin de los

usuarios.

Importancia

vital

Urgencia

inmediatamente
90

15

Ejemplo Larman: Catlogo de

requisitos del sistema

Ejemplo Larman: Catlogo de

requisitos del sistema

3.2 Requisitos no funcionales

...3.2 Requisitos no funcionales

Facilidad de uso

Restricciones de Implementacin

El cliente ser capaz de ver la informacin en un gran monitor del PDV.

Se debe ver el texto fcilmente a una distancia de 1 metro. El cajero
est mirando a menudo al cliente o los artculos, no a la pantalla del
ordenador. Por tanto, se deben comunicar las seales y avisos con
sonidos,
so
dos, e
en lugar
uga de s
slo
o mediante
ed a te g
grficos.
cos

La direccin de NuevaEra insiste en una solucin utilizando las

tecnologas Java

Componentes
p
adquiridos
q
El sistema de clculo de impuestos. Debe soportar sistemas de
clculo conectables de diferentes pases.

Fiabilidad

Capacidad de recuperacin
Si se produce algn fallo al usar un servicio externo (autorizacin de
pago, sistema de contabilidad,...) intentar solucionarlo con una
solucin local

Interfaces hardware
Monitor con pantalla tctil
Escner lser de cdigo de barras
Impresora de recibos
Lector de tarjetas de crdito/dbito
Lector de firmas (pero no en la primera versin)

Rendimiento

Como se mencion en los factores humanos, los compradores quieren

completar el proceso de ventas muy rpido. Un cuello de botella
potencial es la autorizacin de pagos externa. El objetivo es conseguir
la autorizacin en menos de 1 minuto, el 90% de las veces
91

Ejemplo Larman: Catlogo de

requisitos del sistema

92

Ejemplo Larman: Catlogo de

requisitos del sistema
3.4 Reglas del negocio

3.3 Requisitos de informacin

IRQ-0001

producto

Descripcin

El sistema deber almacenar la

informacin correspondiente a
producto. En concreto:

Datos especficos

Tiempo de vida
Ocurrencias simultneas
Importancia

REGLA 1, firma

Se requiere la firma para pagos a crdito. La

poltica de las compaas de autorizacin de crdito.

cdigo universal de producto

nombre del producto
precio unitario del producto

CRQ-0001

pagos firmados

Versin

1.0 ( 18/10/2006 )

Dependencias

Ninguno

Descripcin

La informacin almacenada por el sistema deber

satisfacer la siguiente restriccin: se requiere la
firma del cliente para pagos a crdito.

Medio

Mximo

8 mes(es)

5 ao(s)

Medio

Mximo

Importancia

PD

400

1000

Urgencia

PD

vital
93

Ejemplo Larman: Catlogo de

requisitos del sistema
3.4 Reglas del negocio

94

Bibliografa Recomendada
Sommerville, I. "Ingeniera del software" Pearson, 2005 (7 ed.)
Larman, C. UML y Patrones. Introduccin al Anlisis y Diseo
Orientado a Objetos y al Proceso Unificado . Prentice Hall, 2004. cap.
4, 5 y 7.

REGLA 2, impuestos

Hay que aadir el IVA

REGLA 3, devoluciones

Las devoluciones de los pagos a crdito slo pueden

efectuarse como crdito en las cuentas de crdito de los
compradores, no en efectivo. La poltica de las
compaas de autorizacin de crdito

REGLA 4, Fijacin de precios

Los artculos tienen un precio original, y opcional mente,

un precio rebajado.

95

Lecturas complementarias
Pressman, Roger S. "Ingeniera del software : un enfoque prctico
MacGraw-Hill", 2005 (6 ed) Pressman, Roger S. "Ingeniera del
software : un enfoque prctico MacGraw-Hill", 2005 (6 ed)
Amador Durn Toro, Beatriz Bernrdez Jimnez, "Metodologa
para la Elicitacin de Requisitos de Sistemas Software", Versin 2.3,
Informe Tcnico LSI200010 (revisado), Universidad de Sevilla

96

16