https://www.google.com.gt/search?q=2.

1+Especificaci
%C3%B3n+de+requisitos+2.1.1+Objetivos+del+sistema+2.1.2+Requisitos+de+inf
ormaci
%C3%B3n+2.1.3+Restricciones+del+sistema+2.2+Requisitos+funcionales+2.2.1+
Diagramas+de+casos+de+uso+2.2.2+Definici
%C3%B3n+de+actores+2.2.3+Documentaci
%C3%B3n+de+los+casos+de+uso+2.3+requisitos+no+funcionales+2.4+Conclusion
es.+2.5+Recomendaciones+2.6+Bibliograf%C3%ADa.&oq=2.1+Especificaci
%C3%B3n+de+requisitos+2.1.1+Objetivos+del+sistema+2.1.2+Requisitos+de+inf
ormaci
%C3%B3n+2.1.3+Restricciones+del+sistema+2.2+Requisitos+funcionales+2.2.1+
Diagramas+de+casos+de+uso+2.2.2+Definici
%C3%B3n+de+actores+2.2.3+Documentaci
%C3%B3n+de+los+casos+de+uso+2.3+requisitos+no+funcionales+2.4+Conclusion
es.+2.5+Recomendaciones+2.6+Bibliograf
%C3%ADa.&aqs=chrome..69i57.690j0j7&sourceid=chrome&es_sm=122&ie=UT
F-8
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 la seccin 2 describiremos
las tareas recomendadas para realizar una correcta elicitacion de requisitos, en la
seccin 3 se definen los productos entregables, en este caso el DER, y por
ltimo, en 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.5
3.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
0
1

Fecha
Fecha 0
Fecha 1

Fecha N

descripcin
Versin x.y
descripcin cambio1

descripcin cambio N

Autores
Autor 0
Autor 1

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 la mostramos a continuacin.