<ingeniera de Requisitos (IR)

A nivel de tiempo-espacio-sociedad uno de los principales problemas que enfrenta la

Ingeniera de Software es una definicin errada de lo que se debe de construir.
"Lo ms difcil en la construccin de un sistema software es decidir precisamente qu
construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace
mal... Ninguna otra tarea es tan difcil de rectificar a posteriori... F. P. Brooks, 1987" F. P.
Brooks es el autor de The Mythical Man-Month, quiz el nico libro clsico de la Ingeniera del Software (Addison-Wesley, 1975).
Brooks fue jefe de proyecto del OS/360, el sistema operativo del IBM/360. A lo largo de este enorme proyecto, Brooks padeci todos
los males que constituyren lo que habitualmente se conoce como crisis del software.

Y Qu podemos hacer? Pues, no se ha encontrado solucin universalmente vlida, hay

serias dudas acerca de si dicha solucin existe, nos movemos en la frontera socio-tcnica
de los sistemas: borrosa, voluble e inconsistente. Debemos reconocer que los requisitos
poseen vida y situaciones propias, son dinmicos y se mueven segn inters de los
interesados.
Para remediar en lo posible esta situacin, surge la Ingeniera de Requisitos (IR).
Segn[Leite89] "Es el proceso mediante el cual se intercambian diferentes puntos de vista
para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una
combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se
genera un documento de requerimientos". Otro concepto de la IR sera, "Trata de los
principios, mtodos, tcnicas y herramientas que permiten descubrir, documentar y
mantener los requisitos para sistemas basados en computadora propias de las
necesidades de los clientes, de forma sistemtica y repetible. La meta de la ingeniera de
requerimientos es entregar una especificacin de requerimientos de software correcta,
completa y no ambigua. La ingeniera de requerimientos apunta a mejorar la forma en que
comprendemos y definimos sistemas de software complejos".
Desde los aos 50 hasta la fecha, la tasa de proyectos de ingeniera de software ha
disminuido, aunque no lo suficiente Por qu?

Debemos comprender que si no se entiende el problema no podremos realizar una

solucin. En este artculo descubriremos pasos a seguir para aplicar una correcta IR,
respondiendo preguntas como.
Qu?: Los diferentes niveles y tipos de requisitos que deben definirse
Por qu?: Los beneficios de tener los requisitos de software correctos
Quin?: Las partes interesadas en los requisitos de software
Cundo?: Requisitos de las actividades durante todo el ciclo de desarrollo de
software
Cmo?: Tcnicas que permitan deducir, analizar, especificar y validar el
software requisitos

Qu son los requisitos?

Veamos este concepto que ofrece Jackson & Zave: Todo problema sw. consiste en
configurar una mquina para que ejerza unos efectos R en un dominio K. La conexin se
realiza a travs de una interfaz S.
Los efectos R son los requisitos: Necesidades, metas, objetivos
El conocimiento del dominio K describe el contexto.
La mquina (hw+sw) es la que realizar los requisitos R, gracias a S, que describe
la conexin con el dominio K.

En la fase de requisitos tan slo necesitamos K, S y R. No necesitamos describir el

comportamiento interno de la mquina
Idealmente: K y S => R
R: NO son realidades, pero sern realidades cuando construyamos el sistema.
K: Describe realidades. Afirmaciones cuya verdad es independiente de la existencia, o no, del
sistema.
S: Describe comportamiento externo del sistema (interfaz)

Aplicamos un ejemplo para entender el concepto. Sistema de control de una caldera de

vapor:

K: el agua entra en ebullicin a 100 Grados Centgrados y a 1 atm. de presin

R: El sistema evitar que el agua entre en ebullicin
S: El sistema leer la temperatura del agua por medio del sensor S342, El
sistema podr subir la temperatura del agua por medio del regulador R452
Propiamente hablando tan slo R son requisitos, pero a la Ingeniera de
Requisitos le interesan tambin K y S, pues todas son necesarias.
Pero K, S y R no son suficientes...
Debemos de considerar que existe informacin importante, no slo del tipo que debe de
hacer el software sino necesidades adyacentes no visibles en muchos casos. Estos otros
datos de la informacin acerca del problema a solucionar como propiedades y
comportamiento del sistema, restricciones de diseo y fabricacin del producto,
descripciones acerca de cmo el futuro sistema ayudar a sus usuarios a realizar mejor
sus tareas, restricciones acerca de la tecnologa que ser utilizada en la construccin del
sistema (protocolos, SSOO, COTS, etc.), restricciones acerca de las propiedades
emergentes del sistema (requisitos no funcionales).

Un concepto importante es que el qu de una persona es el cmo de otra. Por ejemplo:

Qu: minimizar el nmero de personas que circulan por las escaleras
Cmo: Instalando un ascensor.
PERO para la empresa instaladora de ascensores, instalar un ascensor es un
qu, no un cmo. El cmo del ascensorista es, qu herramientas utilizo?, qu proceso
sigo? qu medidas de seguridad aplicar?
En su artculo "Software Requirements Engineering: What, Why, Who, When, and
How", Linda Westfall nos ofrece unos niveles y tipos de requisitos:

Niveles y tipos de requisitos

Por ejemplo, el requisito de negocio para permitir que el cliente pague en el grifo su
consumo podra traducirse en mltiples necesidades de los usuarios, incluidos los
requisitos para que el usuario:
Pase de crdito o dbito
Introduzca un nmero de PIN de seguridad
Solicite un recibo en el grifo
Los requisitos funcionales del producto, que definen la funcionalidad del software debe ser
construido en el producto para que los usuarios puedan realizar sus tareas, respondiendo
as a los requisitos de las empresas. Mltiples requisitos de nivel funcional pueden ser
necesarios para cumplir con un requisito de un usuario. Por ejemplo, los requisitos que los
usuarios puedan pasar su tarjeta de crdito podra traducirse en mltiples requerimientos
funcionales como requisitos para el software:
Preguntar al cliente poner su tarjeta en el lector
Detectar que la tarjeta haya sido pasada
Determine si la tarjeta se lee correctamente y rpido que el cliente pase la tarjeta
de nuevo
Analizar la informacin de la banda magntica de la tarjeta
A diferencia de los requisitos de negocio, las reglas de negocio son las polticas
especficas, normas, prcticas, reglamentos y directrices que definen cmo los usuarios
hacer negocios (y por tanto se consideran los requisitos de nivel de usuario). El producto
de software debe cumplir a estas reglas para funcionar adecuadamente en el dominio del
usuario. Una visin comercial de los requisitos resumen la siguiente grfica.

Visin comercial de requisitos

En la siguiente figura, Noritaki Kano ha desarrollado un modelo de la relacin entre la

satisfaccin del cliente y la calidad requisitos (Pyzdek 2000). La la lnea de espera de
calidad representa los los requisitos de explcitos de calidad que espera el cliente. Por
ejemplo, expresa sus preferencias por la marca, modelo, opciones y rendimiento de la
gasolina al comprar un coche. Los clientes no estarn satisfechos (e ir a comprar un
coche en otro lugar) si sus requisitos explcitos no se cumplen. La satisfaccin del cliente
aumenta a medida que sus requisitos explcitos se van cumpliendo. Cuando un nmero
suficiente de sus requisitos explcitos se cumplen, el cliente pasa de ser satisfecho con el
producto a ser un cliente satisfecho.

Modelo de relacin Satisfaccin Cliente - Calidad/Requisito de Kano

Hay un nivel bsico de los requisitos de calidad que un cliente espera que el producto
tenga. Estos son requisitos que son asumidos por el cliente y generalmente no son
expresados. Por ejemplo, se espera un coche que tiene cuatro ruedas, un motor en
funcionamiento, y un volante. Este nivel de exigencia no satisface al cliente. La
emocin representa los elementos inesperados. Se trata de artculos que los clientes ni
siquiera saben que quieren, pero les encanta cuando los ven.

Cmo escribir los requisitos?

La mejor forma de escribir requisitos no existe. Lo ms utilizado es el lenguaje natural.
Cada requisito expresado en una frases corta (el sistema har X ..., se facilitar Y...,
etc), o lenguaje natural complementado con diagramas y/o notaciones formales. Por
ejemplo:

El sistema mantendr la temperatura de la caldera entre 70 y 80

El sistema mantendr un registro de todos los materiales de la biblioteca,
incluyendo libros, peridicos, revistas, videos y CDRoms
El sistema permitir a los usuarios realizar una bsqueda por ttulo, autor o ISBN
El interfaz de usuario se implementar sobre un navegador Web
El sistema deber soportar al menos 20 transacciones por segundo
El sistema permitir que los nuevos usuario se familiaricen con su uso en menos
de 15 minutos.
Aqu puede verse que los requisitos son de muy distintos tipos:

Requisitos que definen efectos sobre el entorno

Requisitos muy generales
Requisitos funcionales
Requisitos de implementacin
Requisitos de rendimiento
Requisitos de usabilidad
Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma
estndar de escribirlos. Tampoco es posible decir cual es la mejor forma de
especificarlos. Todo depende mucho de quien los escribe, quien los va a leer, el dominio
de la aplicacin, etc. Podemos dar una aproximacin a la clasificacin de los tipos de
requisitos. Por ejemplo:

Los requisitos funcionales describen los servicios (funciones) que se esperan del
sistema: El sistema aceptar pagos con VISA
Los requisitos no funcionales son restricciones sobre los requisitos funcionales: El
sistema aceptar pagos con VISA de forma segura y con un tiempo de respuesta menor
de 5 segundos (si fuera de forma arbitaria dira: El sistema aceptar pagos con VISA a
travs del protocolo SET).

Tipos de requisitos no funcionales:

Orientados al usuario: Fiabilidad, Seguridad (security), Seguridad

(safety), Usabilidad, Robustez, Disponibilidad, Rendimiento, Tiempo de
respuesta, Capacidad (carga), otros.

Orientados al
desarrollador: Disponibilidad, Portabilidad, Adaptabilidad, Testabilidad, Comprensibilidad,
otros.
Debemos tener en cuenta que se debe escribir los requisitos tanto positivos como
negativos. Los negativos es lo que el sistema NO va a realizar, ya que se
evita ambigedad y restringe el alcance, lo aclara desde el inicio.
Requerimientos de software y requisitos de sistemas

Existe un relacin de requisitos y arquitectura de software, teniendo en cuenta los

siguiente putnos:
La eleccin de una determinada arquitectura sw. debe tener en cuenta los requisitos
funcionales pero, sobre
todo, los requisitos no funcionales
No hay una regla definitiva para establecer, dados los requisitos, el tipo de arquitectura
Tan slo hay una serie de heursticas para, dados unos requisitos, elegir la arquitectura.
En la prctica, es difcil desarrollar uno sin el otro

Procesos de Ingeniera de Requisitos

A la pregunta de cmo podemos realizar las actividades para poder manejar los requisitos
a un nivel formal y que pueda indicar el camino adecuado, la respuesta de la IR lo plasma
en los procesos que se sigue.

Procesos de la Ingeniera de Requisitos (basado en Wiegers 2003)

Los requisitos son formalmente documentados durante la fase de especificacin para que
puedan ser comunicados a los interesados del producto. La especificacin de requisitos
puede tomar una de muchas formas. Por ejemplo, en proyectos pequeos de la
informacin sobre los requisitos puede ser documentada en un solo documento de
Especificacin de Requisitos de Software (SRS). En proyectos ms complejos, los
requisitos pueden ser indicados en varios documentos. Por ejemplo:

Los requisitos de negocio pueden ser documentados en un Documento de

Requisitos de Negocio (Business Requirement Document BRD), Documento de
Requisitos de Marketing (Marketing Requirement Document - MRD), o en un documento
de la Visin del proyecto.
Los requisitos de usuario puede ser documentados en una serie de casos de uso
de una herramienta o en un documento de Especificaciones de Requisitos de Usuario
(URS).
Si el software es parte de un sistema mayor, los requisitos a nivel de producto
puede ser documentado en la Especificacin de Requisitos del Sistema y un
sistema especificacin de arquitectura puede documentar las asignaciones de los
requisitos al software, el hardware y los componentes de las operaciones manuales de
ese sistema.
El software de los requisitos funcionales y no funcionales y las restricciones puede
ser documentado en un SRS, asimismo las interfaces externas pueden ser incluidos en el
SRS o por separado

Una buena prctica para la especificacin de los requisitos es contar con los requisitos
predefinidos, es decir, plantillas de especificacin. Estas plantillas permiten que el analista
de requisitos se centre en el contenido en lugar del formato y puede ayudar a garantizar
que los elementos clave no se pasan por alto. Otra buena prctica es utilizar una
herramienta de requisitos (o base de datos). Una herramienta de requisitos puede ser un
activo importante en tanto para la gestin y administracin de proyectos.
En el siguiente grfico observamos el proceso de Ingeniera de Requisitos en un modelo

de espiral.

Gestin de requisitos

En el dibujo, los cuadros redondeados son tareas. Los cuadrados son productos (inputs o
outputs). En el resto de esta presentacin se explicar cada componente de este
proceso. La separacin que aqu se ofrece es ms conceptual que real. Las
distintas tareas que se ejecutan durante el proceso de requisitos suceden en paralelo y
se solapan unas con otras. Por ejemplo, durante un proceso de elicitacin (obtener de una
manera provocada informacin de una fuente) de requisitos empleando prototipado, es
inevitable realizar una pequea validacin de los requisitos que se van obteniendo, o
incluso una pequea negociacin, si estamos tratando con varios usuarios a la vez.

I. ELICITACIN DE REQUISITOS
Se refiere a la capturay descubrimiento de los requisitos. Es una actividad ms humana
que tcnica, adems se identifican a los interesados (stakeholders) y se establecen las
primeras relaciones entre ellos. Los requisitos pueden proceder de varias fuentes como:

Metas: Factores crticos de xito

Conocimiento del dominio de la aplicacin. Por ejemplo, si el analista
tiene experiencia en realizar sistemas para compaas de seguros, puede
sugerir requisitos que no son obvios para los usuarios, o puede deducir mejor
las consecuencias de los requisitos propuestos por los usuarios. Por ejemplo, un usuario
quiere consultar por pantalla todas las plizas que venzan durante el mes. Para que ello
sea posible, el software deber obligar, cada vez que se crea una pliza, a que se
introduzca su fecha de vencimiento. Esto puede resultar obvio para un informtico, pero
no lo es tanto para un usuario inexperto.
Interesados. Afectados por el cambio
El entorno que rodea al sistema
La organizacin. Los procesos de negocio.
Existen problemas a la hora de elicitar los requisitos, pues los usuarios no pueden o no
saben describir muchas de sus tareas, esta informacin importante no llega

a verbalizarse. Ocurre tambin que a veces hay que inventar los requisitos, o
los sistemas orientados a miles de usuarios: web, mercado, son demasiado complejo en
relacin a los tiempos que se tiene para obtener la informacin. Esta etapa requiere que el
aprendizaje del conocimiento del negocio no sea pasivo, sino colaborativo.
Algunas tcnicas para obtener requisitos:

Preliminares: Utilizar preguntas libres de contexto

Brainstorming (lluvia de ideas)
Creatividad (herramientas como ideafisher, curio, mindjet, etc.)
Entrevistas: Es el mtodo tradicional
Observacin y anlisis de tareas
Casos de uso / Escenarios: requisitos en contexto de uso
Prototipado: tiles cuando la incertidumbre es total acerca del futuro sistema. Hay
dos tipos principales: Evolutivo, de usar y tirar (prototipos en papel, mago de Oz, etc.).

II. ANLISIS DE REQUISITOS

Consiste en detectar y resolver conflictos entre requisitos, adems se precisan los lmites
del sistema y la interaccin con su entorno. Es la etapa donde se trasladan los requisitos
de usuario a requisitos del software (implementables). Se realizan tres tareas
fundamentales: Clasificacin, Modelizacin, Negociacin.

Clasificacin de los requisitos

En el anlisis de requisitos, stos se clasifican En funcionales vs. no funcionales
(Capacidades vs. Restricciones). Tenemos en cuenta los ciertas clasificaciones como: Por
prioridades, Por coste de implementacin, Por niveles (alto nivel, bajo nivel), Segn su
volatilidad/estabilidad, si son requisitos sobre el proceso o sobre el producto.
En Ingeniera de Sistemas, adems, se realiza la ubicacin de requisitos (Requirements
Allocation)

Modelizacin conceptual
Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de
estados, de interaccin, de objetos, etc. La meta es entender mejor el problema, ms que
iniciar el diseo de la solucin (idealmente). El tipo de modelo elegido depende de: La
naturaleza del problema, La experiencia del modelizador, La disponibilidad de
herramientas, Por decreto (El cliente impone una notacin).
Tradicionalmente se entenda que el anlisis se reduca a modelizar (DFDs, modelos de
objetos, etc), pero el anlisis de requisitos NO es exclusivamente un proceso de
modelizacin, como ya se ha dicho. Por otro lado, no existe la mejor forma de modelizar
requisitos. En realidad, no hay evidencia emprica que demuestre, en general, la
superioridad de unas notaciones de modelizacin frente a otras.

Negociacin de requisitos
En todo proceso de IR intervienen distintos individuos con distintos y, a veces,
enfrentados intereses. Estos conflictos entre requisitos se descubren durante el
anlisis. Incluso a veces, detrs de un requisito ambiguo lo que hay, en realidad, es un
conflicto no resuelto. Es durante el anlisis cuando muchos de los conflictos entre
requisitos son descubiertos. EL CONFLICTO NO ES RECHAZABLE y no debe resolverse
por decreto, sino mediante un proceso de negociacin. Desde este punto de vista,
los conflictos son positivos, pues SON FUENTE DE NUEVOS REQUISITOS.
Los acuerdos alcanzados deben ser convenientemente anotados, favorecindose as
la trazabilidad de los requisitos a sus orgenes (el requisito 987 surge como resultado de
la reunin entre x, y z el da tal del tal...) Existe, incluso, un subcampo de la IR dedicada
a este tipo de temas: la IR orientada a Puntos de Vista o Viewpoint-Based Requirements
Engineering.

III. ESPECIFICACIN DE REQUISITOS

Es el modo habitual de guardar y comunicar requisitos. Es buena prctica a utilizar, al
menos, dos documentos, a distinto nivel de detalle DRU/URD: Documento de Requisitos
de Usuario/User Requirements Document. ERS/SRS: Especificacin de Requisitos
Software/Software Requirements Specification.
La pregunta que surge es en qu se diferencian los requisitos de usuario de
los requisitos del software?. Pues como lo vimos ms arriba, podemos resumir en lo
siguiente, el NIVEL DE DETALLE:
El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los
requisitos de usuario, contenidos en la DRU, no poseen demasiado nivel de detalle. Se
incluye la descripcin del problema actual (razones por las que el sistema de trabajo
actual es insatisfactorio) y las metas que se espera lograr con la construccin del nuevo
sistema.
La ERS desarrolla mucho ms los contenidos de la DRU. Los requisitos del software
contenidos en la ERS son, por tanto, ms detallados. Contiene la respuesta a la pregunta
Qu caractersticas debe poseer un sistema que nos permita alcanzar los objetivos, y
evitar los problemas, expuestos en la DRU.
Existen estndares para la documentacin de requisitos, entre los cules tenemos:

IEEE Std. 1362 (ConOps)

IEEE Std. 830 (SRS)
PSS-05 de la Agencia Espacial Europea (ESA)
Las herramientas de gestin de requisitos permiten generar documentacin en los
anteriores formatos, a
partir de una base de datos de requisitos. Es importante tener en cuenta que los requisitos
deberan de cumplir ciertas caractersticas, en total son 24:

1.
No ambigua: La ERS es no ambigua si todo requisito posee una sla
interpretacin
2.
Completa: Una ERS es completa si todo lo que se supone que el software debe
hacer est includo en la ERS. Por completitud, deberan describirse todas las
posibles respuestas a todas las posibles entradas y en todas las situaciones posibles.
Adems, la ERS no contendr secciones de tipo por determinar...
3.
Correcta: Todo requisito de la ERS contribuye a satisfacer una necesidad real.
4.
Comprensible: Todo tipo de lectores (clientes, usuarios, desarrolladores, equipo
de pruebas, gestores, etc.) entienden la ERS.
5.
Verificable: Si para cada requisito expresado en la ERS existe un procedimiento
de prueba finito y no costoso para demostrar que el futuro sistema lo satisface.
6.
Internamente Consistente: No existen subconjuntos de requisitos contradictorios.
7.
Externamente Consistente: Ninguno de los requisitos est en contradiccin con
lo expresado en documentos de nivel superior. Por ejemplo, en un
sistema (hardware+software), los requisitos del software no pueden contradecir los
requisitos del sistema.
8.
Realizable: Si, dados los actuales recursos, la ERS es implementable
9.
Concisa: La ERS debe ser lo ms breve posible, sin que esto afecte al resto
de atributos de calidad
10.
Independiente del diseo: Existen ms de un diseo e implementacin
que realizan la ERS. Para ello la ERS debera limitarse a describir el
comportamiento externo del sistema.
11.
Trazable: Cada requisito se puede referenciar de forma unvoca. Es
fundamental para precisar qu requisitos son implementados por qu componente del
diseo, lo cual es imprescindible a la hora de realizar las pruebas de dicho componente
12.
Modificable: Los cambios son fciles de introducir.
13.
Electrnicamente almacenada: Se encuentra en un archivo de texto, en una
base de datos o, mejor an, ha sido creada con una herramienta de gestin de
requisitos (RequisitePro, Doors, etc.)
14.
Ejecutable/Interpretable/Prototipable/Animable: Si existe una herramienta software
que, recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable
tan slo a ciertas notaciones como las notaciones formales o los diagramas de transicin
de estados.
15.
Anotada por importancia relativa: Si los requisitos se clasifican segn
su importancia. Como mnimo un requisito puede ser Obligatorio, Deseable u Opcional.
Esto sirve para no asignar demasiados recursos a la implementacin de requisitos no
esenciales.
16.
Anotada por estabilidad relativa: Los requisitos son, en general, inestables
y voltiles. A cada requisito se le asigna una probabilidad de cambio (p.ej. Alta, Media o
Baja). Esto ayudar a los diseadores a diferenciar los componentes ms flexibles de los
ms estables.
17.
Anotada por versin: Si un lector de la ERS puede determinar qu requisitos
sern satisfechos por qu versin del producto.
18.
No redundante: Cada requisito se expresa en un solo lugar de la ERS.
La redundancia, de todas formas, no es del todo mala si aumenta la legibilidad.
19.
Al nivel adecuado de abstraccin: Ni demasiado detallada ni demasiado vaga.

20.
Precisa: Una ERS es precisa si hace uso de valores numricos para precisar
las caractersticas del sistema. La precisin es aplicable, ante todo, a los requisitos
no funcionales. Por ejemplo, no es til decir El tiempo de respuesta ser ms
bien rpido, sino El tiempo de respuesta ser menor que dos segundos. En la prctica
diaria, la precisin es dificilsima de conseguir pues es fuertemente dependiente de la
tecnologa disponible, la cual no siempre se conoce al principio de un proyecto.
21.
Reutilizable: Si ciertas secciones de la ERS se pueden reutilizar
22.
Trazada: Si est claro el orgen de cada requisito (quin o qu lo pide)
23.
Organizada: Si el lector puede fcilmente encontrar la informacin buscada.
24.
Con referencias cruzadas: Si se utilizan referencias entre requisitos
relacionados (trazabilidad intra-ERS) o entre secciones relacionadas.

Debemos de considerar que una ERS perfecta es imposible, la calidad de la ERS es muy
difcil de cuantificar, en general, una ERS de calidad NO garantiza la ausencia de
problemas, pero una ERS psima
garantiza su presencia.

IV. VALIDACIN DE REQUISITOS

El objetivo de esta etapa es descubrir problemas en el Documento de Requisitos antes de
comprometer recursos a su implementacin. como resultado se produce una lnea-base
(baseline).
En el contexto de la Ingeniera de Requisitos, una lnea base es un conjunto de requisitos
que han sido formalmente aceptados por todas las personas implicadas en el proyecto.
Una vez que se establece una lnea base, futuros cambios a tales requisitos slo podrn
realizarse por medio de un proceso formal de gestin y aprobacin de cambios.
La revisin del documento es la frmula ms empleada para validacin, puede ser
realizada por un grupo de personas (incluyendo usuarios) y se ocupan de revisar el
documento de requisitos. Pueden establecerse tres fases: Busqueda de problemas,
reunin y acuerdos. Como gua para identificar problemas habituales, se
pueden utilizar listas de comprobacin (checklists, existen plantillas adaptadas a
distintos tipos de sistemas).
El 33% de los errores de requisitos en la especificacin del sistema fueron detectados
mediante revisin manual. El resto se descubrieron en posteriores fases, con el
consiguiente incremento en el coste.
Curiosamente, las revisiones parecen funcionar tambin con el cdigo ejecutable: se
descubren ms errores inspeccionando el cdigo fuente que ejecutando el programa.
Radica aqu el xito de los desarrollos Open Source?

Cada organizacin, segn su experiencia y segn el dominio de las aplicaciones que

desarrolle, debera desarrollar su lista de comprobacin o checklist particular. Un

ejemplo de cuestiones que deberan figurar en una lista de comprobacin podra ser esta:

Estn todos los requisitos convenientemente numerados?

El mismo servicio es solicitado en distintos requisitos? Existen contradicciones
entre ellos?
Los requisitos relacionados se encuentran agrupados en el documento?
Los requisitos son fcilmente comprensibles? Por todo tipo de lectores?
En general, una lista de comprobacin debera girar alrededor de los 24 atributos de
calidad que debera poseer una ERS. Para cada atributo de calidad, se pueden plantear
una serie de cuestiones que sirvan para confeccionar la lista de comprobacin.
Otros mtodos de validacin como: Prototipado (Permite descubrir con rapidez si
el usuario se encuentra satisfecho, o no, con los requisitos), Uso de escenarios/casos de
uso, Validacin de modelos (Cuando los requisitos se expresan por medio de modelos (de
objetos, DFDs, etc.), Validacin de su testabilidad (El equipo de pruebas debe revisar los
requisitos).
Al finalizar esta etapa, el documento generado debe de cumplir como mnimo con las
siguientes caractersticas luego de la revisin:

Completa. El documento de requerimientos incluye todos los requisitos

necesarios de la informacin. Por ejemplo, el SRS incluye todas las funciones y no
funcionales requerimientos, restricciones, requisitos de interfaz externa, y datos
requeridos que deben ser satisfechas.
Consistente. Los conflictos internos no existen entre los requisitos del documento.
Los requisitos no entrar en conflicto con los requisitos de alto nivel, incluidos empresarios,
usuarios, o sistemas. La terminologa tambin se usan de manera habitual dentro de
la documentacin, es decir, una palabra tiene el mismo significado que cada vez que se
utiliza, o dos palabras diferentes que no se utilizan para significar la misma cosa.
Modificable. El documento de requerimientos es organizado y escrito de una
manera que facilitar hacer cambios en el futuro.
El proceso de revisin tambin debe mirar a todos los requisitos y asegurarse como
mnimo que cumpla lo siguiente:

Inequvoca. Cada declaracin requisito debe tener una sola interpretacin, y cada
requisito se debe especificar de forma coherente, fcil de entender manera. Por ejemplo,
las bsquedas de autor de las palabras que terminan en "mente" (por ejemplo, rpida y
fcil de usar, de forma automtica), ya que los adverbios, por naturaleza, son casi siempre
ambiguos.
Conciso. Cada requisito debe ser declarado en breve, especfico, orientado a la
accin del idioma.

Finitos. El requisito no debe plantearse de una manera abierta. Para ejemplo,

palabras como "todos", "todos", y "todo" se debe evitar en los requisitos de las
declaraciones.
Medibles. Los lmites especficos, mensurables o valores deben ser establecidos
para cada requisito segn el caso.
Factible. El requisito se puede implementar utilizando las tecnologas
disponibles, tcnicas, herramientas, recursos y personal en el costo y el horario
especificado restricciones.
Comprobable. Existe una forma razonablemente rentable para determinar que
el software cumple con los requisitos.
Trazabilidad. Cada requisito debe permitir rastrear el origen de su fuente (por
ejemplo, a nivel de requisitos de usuario, los requisitos de nivel de sistema, estndar,
mejora peticin). Tambin se debe especificar de una manera que permita seguir
adelante en el diseo, implementacin y pruebas.

V. GESTIN DE REQUISITOS
Requirements Management (RM), consiste, bsicamente, en gestionar los cambios a los
requisitos. Esto asegura la consistencia ente los requisitos y el sistema construido (o en
construccin), pero consume grandes cantidades de tiempo y esfuerzo, y abarca todo el
ciclo de vida del producto.
Debemos de gestionar, porque entendemos que los requisitos son voltiles, el entorno
fsico cambia (en el caso de trasladar un sistema de un entorno a otro
requiere modificaciones), el entorno organizacional cambia (Las polticas
cambian, Cambios en las reglas y en los procesos del negocio provocan cambios en el
sistema), y la propia existencia del sistema va a generar nuevos requisitos por parte de
los usuarios.
Para la gestin debemos de definir lo siguiente:

Definir procedimientos de cambios: definen los pasos y los anlisis que se

realizarn antes de aceptar los cambios propuestos (una Software Change
Request (SCR) de la NASA ocupa ms de 500 pginas !!!).
Cambiar los atributos de los requisitos afectados
Mantener la trazabilidad: hacia atrs, hacia delante y entre requisitos (P.ej.
Proyectos para la FDA)
Control de versiones del documento de requisitos
Existen herramientas de gestin que facilitan las tareas relacionadas con la
escritura, trazabilidad y gestin de cambios, Organizan los requisitos en bases de datos,
Gestionan incrementalmente teniendo una lnea base, adems de clasificar los requisitos

mediante atributos. Por ejemplo: DOORS (de QSS/Telelogic), RequisitePro (de

Rational), IRqA, icConcept, etc.

Proceso de elaboracin de lnea base de documento

Una lnea base (baseline) es un conjunto de requisitos que, mediante acuerdo entre las
partes implicadas, se ha decidido no modificar. Son aquellos requisitos ms importantes
que el desarrollador se compromete a implementar. A lo largo de un proceso de requisitos
pueden crearse (incrementalmente) varias lneas base.
Las herramientas de gestin de requisitos permiten gestionar fcilmente las lneas base.
Por ejemplo, los requisitos que forman parte de una lnea base no podrn
ser modificados, salvo por usuarios privilegiados.

Prefacio
Hoy el software es parte casi imprescindible de todo tipo de dispositivos. El software
se utiliza para proporcionar valor aadido a productos tradicionales
(telfonos, refrigeradores, coches) y para diferenciarse de los productos de la
competencia. Basta con decir que, hoy da, el componente ms complejo de un coche es
el software (por ejemplo, modelos de Mercedes contienen sistemas empotrados que
suman casi 5 Mbytes de cdigo ejecutable), Industrias tradicionalmente alejadas del
software hoy tienen problemas de requisitos. Introducir componentes software es distinto
a introducir nuevos componentes fsicos. La complejidad que aade el software es de
varios rdenes de magnitud respecto a la
complejidad que aadira un nuevo componente fsico.
Introducir el software en industrias tradicionales est produciendo choques
culturales. Estas industrias poseen tradiciones, normas y procedimientos que no son
aplicables al desarrollo de software. El mismo concepto de prototipo posee significados
muy distintos en Ingeniera Aeronutica, por ejemplo, y en Ingeniera del
Software. Muchas veces hay que desarrollar un software cuando no se conocen todos los
detalles del hardware u otros subsistemas. Adems, los plazos de entrega normalmente
son cortos e innegociables. Frecuentemente, deber trabajarse con una arquitectura
software lo suficientemente flexible (an a costa de su eficiencia) que permita incorporar
futuros aspectos: patrones que permitan un futuro plug-in de componentes, desarrollos
iterativos y/o incrementales, etc. [IEEE Computer, Nov. 2001].

Actualmente, los requisitos no funcionales (seguridad, fiabilidad, tiempo de

respuesta, disponibilidad, etc.) ocupan ms espacio en el documento de requisitos que los
requisitos puramente funcionales. Los requisitos ya no son un problema exclusivo de la
industria del software y, desde luego, no son un problema exclusivo de los Sistemas de
Informacin tradicionales. Pero es el software, precisamente, lo que provoca los
problemas de requisitos, debido al gran potencial que posee para aumentar la
complejidad de un sistema. Ms informacin en: Juristo, N.; Moreno, A.M.; Silva, A. Is the
European industry
moving toward solving requirements engineering problems? IEEE Software, 19(6),
Nov/Dec. 2002, page(s): 70- 77.
Si no ha quedado claro el tema de requisitos y su importancia lo podemos resumir en una
frase:
"Definir formalmente el deseo del cliente para minimizar el riesgo de desarrollar
algo que no desea".
Plan de Elicitacin de Requisitos

1. Objetivo

Definiremos las tareas que realizaremos, los productos a obtener y las

tcnicas que emplearemos durante la actividad de elicitacion de
requisitos para el desarrollo del software.

Hay dos tipos de productos: los productos entregables y los no

entregables o internos. Los productos entregables los entregaremos
oficialmente al cliente como parte del desarrollo en fechas previamente
acordadas, mientras que los no entregables son productos internos que
no se entregarn al cliente.

El producto entregable luego de hacer la elicitacin de requisitos que

entregaremos es el Documento de Especificacin de requisitos (DER).

La estructura de este documento es la siguiente: en

describiremos las tareas recomendadas para realizar
elicitacion de requisitos, en la seccin 3 se definen
entregables, en este caso el DER, y por ltimo, en

la seccin 2
una correcta
los productos
la seccin 4

describimos las tcnicas recomendadas que podemos usar para obtener

los productos.

2. Tareas recomendadas

Las tareas recomendadas para obtener los productos son los siguientes:

Tarea 1: Obtendremos informacin sobre el dominio del problema y el

sistema actual.
Tarea 2: Prepararemos y realizaremos las reuniones de
elicitacin/negociacin.
Tarea 3: Identificaremos/revisaremos los objetivos del sistema.
Tarea 4: Identificaremos/revisaremos los requisitos de informacin.
Tarea 5: Identificaremos/revisaremos los requisitos funcionales.
Tarea 6: Identificaremos/revisaremos los requisitos no funcionales.
Tarea 7: Priorizaremos objetivos y requisitos.

El orden que recomendamos para la realizacin de estas tareas es: 17,

aunque las tareas 4, 5, y 6 podemos realizarla simultneamente o en
cualquier orden que se considere oportuno. La tarea 1 es opcional y
depender del conocimiento previo que tenga el equipo de desarrollo
sobre el dominio del problema y el sistema actual.

En las siguientes secciones describiremos cada una de las tareas

mencionadas.

2.1 obtener informacin sobre el dominio del problema y el sistema

actual

2.1.1. Objetivos

Conocer el dominio del problema.

Conocer la situacin actual.

2.1.2. Descripcin

Antes de reunirnos con los clientes y usuarios e identificar los requisitos

es fundamental que conozcamos el dominio del problema y los contextos
organizacional y operacional, es decir, la situacin actual.
Enfrentarnos a un desarrollo sin conocer las caractersticas principales ni
el vocabulario propio de su dominio provocar que el producto final no
sea el esperado por nuestros clientes y usuarios.
Por otro lado, si mantenemos reuniones con nuestros clientes y usuarios
sin conocer las caractersticas de su actividad har que probablemente
no entendamos sus necesidades y que su confianza inicial hacia el
desarrollo se vea deteriorada enormemente.
Esta tarea es opcional, ya que nuestro equipo de desarrollo tiene
experiencia en el dominio del problema y el sistema actual a desarrollar.

2.1.3. Productos internos

Informacin recopilada: libros, artculos, folletos comerciales, desarrollos
previos sobre el mismo dominio, etc.

2.1.4. Productos entregables

Introduccin, participantes en el proyecto, principalmente clientes y
desarrolladores, descripcin del sistema actual y glosario de trminos
como parte del DER (Documento de Especificacin de Requisitos) (ver
secciones 3.1.53.1.7 y 3.1.17 paginas).

2.1.5. Tcnicas recomendadas

Obtendremos informacin de fuentes externas al negocio del cliente:

folletos, informes sobre el sector o rea, publicaciones, consultas con
expertos, etc.
En el caso de requisitos muy especficos del dominio ser necesario que
recurramos a fuentes internas al propio negocio del cliente, en cuyo caso
podemos utilizar las tcnicas auxiliares de elicitacin de requisitos como
el estudio de documentacin, observacin in situ, cuestionarios,
inmersin o aprendizaje, etc.
Construccin de glosarios de trminos.

2.2. Tarea 2: Preparar y realizar las sesiones de elicitacin/negociacin

2.2.1. Objetivos

Identificaremos a los usuarios participantes.

Conoceremos las necesidades de clientes y usuarios.
Resolveremos posibles conflictos.

2.2.2. Descripcin
Teniendo en cuenta la informacin recopilada en la tarea anterior, en
esta tarea prepararemos y realizaremos las reuniones con los clientes y
usuarios participantes con objeto de obtener sus necesidades y resolver
posibles conflictos que se hayan detectado en iteraciones previas del
proceso.

Esta tarea es especialmente crtica y la realizaremos con especial

cuidado, ya que si nuestro equipo de desarrollo no conoce los detalles
especficos de lo que necesita la organizacin para la que se va a
desarrollar el sistema y, por otra parte, si los clientes y posibles usuarios
no saben qu es lo que necesita saber nuestro equipo de desarrollo para
llevar a cabo nuestra labor.

2.2.3. Productos internos

Notas que tomaremos durante las reuniones, transcripciones o actas de
reuniones, formularios, grabaciones en cinta o vdeo de las reuniones o
cualquier otra documentacin que se considere oportuna.

2.2.4. Productos entregables

Participantes en el proyecto, en concreto los usuarios participantes,

como parte del DER.
Objetivos, requisitos o conflictos, que hayamos identificado claramente durante
las sesiones de elicitacin, como parte del DER (ver secciones 3.1.83.1.9 y
3.1.18, pgs.).

2.2.5. Tcnicas recomendadas

Tcnicas de elicitacin de requisitos incluyendo las plantillas de

objetivos, requisitos y conflictos, que podremos usar directamente
durante las sesiones de elicitacin.
Tcnicas de negociacin.

2.3. Tarea 3: Identificar/revisar los objetivos del sistema

2.3.1. Objetivos

Identificaremos los objetivos que esperamos alcanzar mediante el

sistema software a desarrollar.
Revisaremos, en el caso de que haya conflictos, los objetivos
previamente identificados.

2.3.2. Descripcin
A partir de la informacin obtenida en la tarea anterior, en esta tarea se
debemos identificar qu objetivos esperamos alcanzar una vez que el
sistema software a desarrollar se encuentre en explotacin o revisarlos
en funcin de los conflictos identificados.

2.3.3. Productos internos

No hay productos internos en esta tarea.

2.3.4. Productos entregables

Objetivos del sistema como parte del DER (ver seccin 3.1.8, pg. ).

2.3.5. Tcnicas recomendadas

Anlisis de factores crticos de xito o alguna tcnica similar de

identificacin de objetivos.
Plantilla para especificar los objetivos del sistema
2.4. Tarea 4: Identificar/revisar los requisitos de informacin

2.4.1. Objetivos

Identificaremos los requisitos de almacenamiento de informacin que

deber cumplir el sistema software a desarrollar.
Identificaremos los requisitos de restricciones de informacin o reglas de
negocio que deber cumplir el sistema software a desarrollar.
Revisaremos, en el caso de que haya conflictos, los requisitos de
almacenamiento y/o de restricciones de informacin previamente
identificados.

2.4.2. Descripcin
A partir de la informacin obtenida en la tareas 1 y 2, y teniendo en
cuenta los objetivos identificados en la tarea 3 y el resto de los
requisitos, en esta tarea debemos identificar, o revisar si existen
conflictos, qu informacin relevante para el cliente deber gestionar y
almacenar el sistema software a desarrollar as como qu restricciones o
reglas de negocio debe cumplir dicha informacin.

Inicialmente partiremos de conceptos generales para posteriormente ir

detallndolos hasta obtener todos los datos relevantes.

2.4.3. Productos internos

No hay productos internos en esta tarea.

2.4.4. Productos entregables

Requisitos de almacenamiento de informacin como parte del DER (ver
seccin 3.1.10, pg. ).

2.4.5. Tcnicas recomendadas

Plantilla para requisitos de almacenamiento de informacin

Plantilla para requisitos de restricciones de informacin.

2.5. Tarea 5: Identificar/revisar los requisitos funcionales

2.5.1. Objetivos

Identificaremos los actores del sistema software a desarrollar.

Identificaremos los requisitos funcionales, expresados de forma
tradicional o como casos de uso, que deber cumplir el sistema software
a desarrollar.
Revisaremos, en el caso de que haya conflictos, los requisitos
funcionales previamente identificados.

2.5.2. Descripcin
A partir de la informacin que obtengamos en las tareas 1 y 2, y
teniendo en cuenta los objetivos identificados en la tarea 3 y el resto de
los requisitos, en esta tarea identificaremos, o revisaremos si existen
conflictos, qu debe hacer el sistema a desarrollar con la informacin
identificada en la tarea anterior.

Inicialmente identificaremos los actores que interactuarn con el

sistema, es decir aquellas personas u otros sistemas que sern los
orgenes o destinos de la informacin que consumir o producir el
sistema a desarrollar y que forman su entorno.

A continuacin identificaremos los casos de uso asociados a los actores,

los pasos de cada caso de uso y posteriormente se detallarn los casos
de uso con las posibles excepciones hasta definir todas las situaciones
posibles.
En el caso de que se considere necesario, se optaremos por expresar
algunos o todos los requisitos funcionales de la forma tradicional, es
decir, mediante un prrafo en lenguaje natural, en lugar de hacerlo
mediante casos de uso.

2.5.3. Productos internos

No hay productos internos en esta tarea.

2.5.4. Productos entregables

Requisitos funcionales como parte del DRS (ver seccin 3.1.11, pg. ).

2.5.5. Tcnicas recomendadas

Casos de uso.
Plantilla para actores.
Plantilla para casos de uso.
Plantilla para requisitos funcionales.

2.6. Tarea 6: Identificar/revisar los requisitos no funcionales

2.6.1. Objetivos

Identificaremos los requisitos no funcionales del sistema software a

desarrollar.
Revisaremos, en el caso de que haya conflictos, los requisitos no
funcionales previamente identificados.

2.6.2. Descripcin
A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuenta los
objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea
identificaremos, o revisaremos si existen conflictos en los requisitos no
funcionales, normalmente de carcter tcnico o legal.
Algunos tipos de requisitos que podemos incluir en esta seccin son los
siguientes:

Requisitos de comunicaciones del sistema

Son requisitos de carcter tcnico relativos a las comunicaciones
que deber soportar el sistema software a desarrollar. Por ejemplo:
el sistema deber utilizar el protocolo TCP/IP para las
comunicaciones con otros sistemas.
Requisitos de interfaz de usuario
Este tipo de requisitos especifica las caractersticas que deber
tener el sistema en su comunicacin con el usuario. Por ejemplo:
la interfaz de usuario del sistema deber ser consistente con los
estndares definidos en IBMs Common User Access.

Debemos ser cuidadosos con este tipo de requisitos, ya que en

esta fase de desarrollo todava no conocemos bien las dificultades
que pueden surgir a la hora de disear e implementar las
interfaces, por esto no es conveniente que entremos en detalles
demasiado especficos.

Requisitos de fiabilidad
Los requisitos de fiabilidad deben establecer los factores que se
requieren para la fiabilidad del software en tiempo de explotacin.
La fiabilidad mide la probabilidad del sistema de producir una
respuesta satisfactoria a las demandas del usuario. Por ejemplo: la
tasa de fallos del sistema no podr ser superior a 2 fallos por
semana.

Requisitos de entorno de desarrollo

Este tipo de requisitos especifican si el sistema debe desarrollarse
con un producto especfico. Por ejemplo: el sistema deber
desarrollarse con Oracle 10 como servidor y clientes Visual
C#.net.
.
Requisitos de portabilidad
Los requisitos de portabilidad definen qu caractersticas deber
tener el software para que sea fcil utilizarlo en otra mquina o
bajo otro sistema operativo. Por ejemplo: el sistema deber
funcionar en los sistemas operativos Windows XP, Windows Seven
y Windows Server 2008, siendo adems posible el acceso al
sistema a travs de Internet usando cualquier navegador
compatible.

2.6.3. Productos internos

No hay productos internos en esta tarea.
2.6.4. Productos entregables
Requisitos no funcionales del sistema como parte del DRS (ver seccin
3.1.15, pg. ).

2.6.5. Tcnicas recomendadas

Plantilla para requisitos no funcionales.

3. Productos entregables
El producto entregable es el Documento de Especificacin de requisitos
(DER).

3.1. Documento de requisitos del sistema

La estructura del DER puede verse en la figura 2. En las siguientes
secciones describimos con detalle cada seccin del DER.

3.1.1. Portada
La portada del DER tendr el formato que puede verse en la figura 3. Los
elementos aparecern son los siguientes:

Nombre del proyecto: el nombre del proyecto al que pertenece el

DER.
Versin: la versin del DER que entregaremos al cliente. La versin
se compondr de dos nmeros X e Y. El primero indicar la versin, y
incrementaremos cada vez que se hace una nueva entrega formal al
cliente. Cuando incrementemos el primer nmero, el segundo volver
a comenzar en cero. El segundo nmero indicar cambios dentro de
la misma versin an no entregada, y incrementaremos cada vez que
publiquemos una versin con cambios respecto a la ltima que se
public y que no entreguemos formalmente todava.
Este tipo de versiones podrn ser internas al equipo de desarrollo o
entregadas al cliente a ttulo orientativo.

Fecha: fecha de la publicacin de la versin.

Equipo de desarrollo: nombres de los integrantes de nuestro
equipo de desarrollo.
Cliente: nombre del cliente / empresa.
3.1.2. Lista de cambios
El documento incluir una lista de cambios en la que se especifiquen,
para cada versin del documento, los cambios producidos en el mismo
con un formato similar al que puede verse en la figura 4. Para cada

cambio realizado incluiremos el nmero de orden, la fecha, una

descripcin y los autores.

Portada
Lista de cambios
ndice
Lista de figuras
Lista de tablas
1. Introduccin
2. Participantes en el proyecto
3. Descripcin del sistema actual
4. Objetivos del sistema
5. Catlogo de requisitos del sistema
5.1 Requisitos de informacin
5.2 Requisitos funcionales
5.2.1 Diagramas de casos de uso
5.2.2 Definicin de actores
5.2.3 Casos de uso del sistema
5.3 Requisitos no funcionales
6. Matriz de rastreabilidad objetivos/requisitos
7. Glosario de trminos
8. Conflictos pendientes de resolucin [opcional, pueden ir en un documento
aparte]
Apndices [opcionales]

Figura 2: Estructura del Documento de Requisitos del Sistema

Proyecto nombre del

proyecto

Documento de
Requisitos del Sistema

Versin X:Y
Fecha fecha

Realizado por equipo de

desarrollo
Realizado para cliente

Figura 3: Portada del Documento de Requisitos del Sistema

Num

Fecha

descripcin

Autores

Fecha 0

Versin x.y

Autor 0

Fecha 1

descripcin
cambio1

Autor 1

Fecha N

descripcin
cambio N

Autor N

Figura 4: Lista de cambios del Documento de Requisitos del

Sistema

3.1.3. ndice
El ndice del DRS indicar la pgina en la que comienza cada
seccin, sub-seccin o apartado del documento. En la medida de
lo posible, sangraremos las entradas del ndice para ayudar a
comprender la estructura del documento.

3.1.4. Listas de figuras y tablas

El DER incluir listas de las figuras y tablas que aparezcan en el
mismo. Dichas listas sern dos ndices que indicarn el nmero, la
descripcin y la pgina en que aparece cada figura o tabla del
DER.

3.1.5. Introduccin
Esta seccin contendr una descripcin breve de las principales
caractersticas del sistema software que se va a desarrollar, la
situacin actual que genera la necesidad del nuevo desarrollo, la
problemtica que se acomete, y cualquier otra consideracin que
site al posible lector en el contexto oportuno para comprender el
resto del documento.

3.1.6. Participantes en el proyecto

Esta seccin contendr una lista con todos los participantes en el
proyecto, tanto desarrolladores como clientes y usuarios. Para

cada participante indicaremos su nombre, el papel que

desempea en el proyecto, la organizacin a la que pertenece y
cualquier otra informacin adicional que se considere oportuna.

3.1.7. Descripcin del sistema actual

Esta seccin contendr una descripcin del sistema actual en el
caso de que se haya acometido su estudio. Para describir el
sistema actual puede utilizarse cualquier tcnica que se considere
oportuno, por ejemplo las descritas en [Laguna et al. 1999]
(Diagrama DocumentosTarea, DDT) o en [Ortn et al. 2001]
(Diagramas de Actividad, tambin descritos en [Booch et al.
1999]).

3.1.8. Objetivos del sistema

Esta seccin contendr una lista con los objetivos que esperamos
alcanzar cuando el sistema software a desarrollar est en
explotacin, especificados mediante la plantilla para objetivos.

3.1.9. Catlogo de requisitos del sistema

Esta seccin ser dividida en las siguientes sub-secciones en las
que se describiremos los requisitos del sistema. Cada uno de los
grandes grupos de requisitos, de informacin, funcionales y no
funcionales,
dividindose para ayudar a la legibilidad del
documento, por ejemplo dividiendo cada sub-seccin en requisitos
asociados
a
un
determinado
objetivo,
requisitos
con
caractersticas comunes, etc.

3.1.10. Requisitos de informacin

Esta sub-seccin contendr la lista de requisitos de
almacenamiento y de restricciones de informacin que se
identifiquemos, utilizando

Para especificarlos las plantillas para requisitos de informacin.

3.1.11. Requisitos funcionales

Esta sub-seccin debe contendr la lista de requisitos funcionales,
expresados de la forma tradicional o mediante casos de uso, que
hayamos identificado, dividindose en los siguientes apartados
que se describen a continuacin.

3.1.12. Diagramas de casos de uso

Este apartado contendr los diagramas de casos de uso del
sistema que hayamos realizado.

3.1.13. Definicin de los actores

Este apartado contendr una lista con los actores que hayamos
identificado, especificados mediante la plantilla para actores de
casos de
Uso.

3.1.14. Casos de uso del sistema

Este apartado contendr los casos de uso que
hayamos
identificado, especificados mediante la plantilla para requisitos
funcionales. En el caso de que consideremos oportuno, tambin
podremos expresar algunos o todos los requisitos funcionales de la
forma tradicional, usando para ello la misma plantilla.

3.1.15. Requisitos no funcionales

Esta sub-seccin contendr la lista de los requisitos no funcionales
del sistema que hayamos identificado, especificados mediante la
plantilla para requisitos no funcionales.

3.1.16. Matriz de rastreabilidad objetivos/requisitos

Esta seccin contendr una matriz objetivorequisito, de forma

que para cada objetivo se pueda conocer con qu requisitos est
asociado. El formato de la matriz de rastreabilidad puede verse en
la figura 5.

Figura 5: Matriz de rastreabilidad del Documento de

Requisitos del Sistema

3.1.17. Glosario de trminos

Esta seccin, contendr una lista ordenada alfabticamente de los
trminos especficos del dominio del problema, acrnimos y
abreviaturas que aparezcan en el documento y que consideremos
que su significado deba ser aclarado. Cada trmino ser
acompaado de su significado.

3.1.18. Conflictos pendientes de resolucin

Esta seccin, la incluiremos en el caso de que no optemos por
registrar los conflictos en un documento aparte, contendr los
conflictos identificados durante el proceso y que an estn
pendientes de resolucin, descritos mediante la plantilla para
conflictos.

3.1.19. Apndices

Los apndices los usaremos para proporcionar informacin

adicional a la documentacin obligatoria del documento. Slo
aparecern si los consideramos oportunos y los identificaremos
con letras ordenadas alfabticamente: A, B, C, etc.

4.- Herramientas para la especificacin de requisitos

Existen varias formas de conseguir informacin de los requisitos del sistema a

desarrollar: por entrevistas, JAD, brainstorming, diseo de prototipos conjunto
etc.

Un paso previo a la Elicitacin de requisitos es la educcin de requisitos donde

conseguimos los requisitos y con qu objetivos est relacionado, esta fase la
hacemos de manera conjunta entre el/los analista(s) y el/los usuario(s),
adems de puntualizar los objetivos principales del sistema.

Una plantilla que usaremos para la educcin de requisitos

continuacin.

la mostramos a