Gestión de los requisitos

3
31032

Gestión de los requisitos

 

Gestión
de los requisitos. 1

Resumen. 2

1.
Introducción a la Gestión de Requisitos. 2

2. Los
primeros requisitos: objetivo y alcance. 2

3. Tipos de
requisitos. 2

3.1
Requisitos funcionales. 2

Requisitos
de Actores. 3

Requisitos
de Interfaz. 3

Requisitos
de Procesamiento. 4

Requisitos
de Persistencia. 4

Requisitos
de Gestión y Administración. 4

3,2
Requisitos no funcionales. 4

Requisitos
de Disponibilidad. 4

Requisitos
de Rendimiento. 4

Requisitos
de Calidad. 5

Requisitos
de Almacenamiento. 5

Requisitos
de Trazabilidad. 5

Requisitos
de Seguridad. 5

Requisitos
de Escalabilidad. 6

Requisitos
Legales y Normativas. 6

3.3
Requisitos de sistema. 6

Requisitos
de Arquitectura. 6

Requisitos
de Software. 6

Requisitos
de Hardware. 6

Requisitos
de Comunicaciones. 6

Requisitos
de Integración. 6

Requisitos
de Contingencia. 6

4. Captura
de requisitos. 6

4.1 El
responsable del  usuario. 7

4.2El
responsable de TI. 7

4.3 El
responsable financiero. 7

5.
Métodos de captura. 7

5.1
Extracción de requisitos desde la información proporcionada por
el cliente. 7

5.2
Entrevista con el Cliente. 7

5.3
Observación del usuario. 7

5.4
Observación de sistemas semejantes. 8

5.5 Consulta
a los expertos. 8

5.6
Obtención de métricas representativas. 8

5,7 Uso de prototipos. 8

5.8Requisitos
autoimpuestos. 9

6.
Árboles de decisión y plantillas de requisitos. 9

7.
Métodos de documentación. 9

7.1 Lista de
requisitos. 9

7.2
Priorización y categorización de requisitos. 10

7.3 Matriz
de trazabilidad. 10

7.4 Control
de versiones. 10

7.5
Documento final 10

7.6
Validación de requisitos. 11

7..7
Aplicaciones de gestión de requisitos. 11

7.8 Un
ejemplo: REM11

8.
Agrupación de requisitos. 11

9. Casos de
uso. 11

10. Conclusión. 12

 

Resumen

Cuando vamos a abordar el desarrollo de un proyecto, ya sea de
ingeniería de software o de cualquier campo, una de sus primeras
etapas es la definición de los requisitos del proyecto. Para ello
debemos saber qué son los requisitos, cómo se capturan,
cómo se analizan y cómo se realiza la definición final de requisitos
del proyecto.

En este artículo vamos a realizar una
introducción a la gestión de requisitos para el desarrollo de un
sistema informático. Vamos a comenzar definiendo lo que son los
requisitos: Luego veremos diferentes técnicas de captura de requisitos.
También dedicaremos un apartado a la organización de los
requisitos. Otro apartado que vamos a incluir es el dedicado a los Casos de
Uso, ampliamente usados como complemento a la toma de requisitos del sistema.

1. Introducción a la Gestión de Requisitos

Los requisitos de un sistema son los aspectos que el sistema
desarrollado debe cumplir. Surgen de las necesidades del cliente, de las
limitaciones del entorno donde se va a implantar o de la propia gestión
de la información que debe realizar el sistema. Normalmente van a
representar valores que debe cumplir como mínimo o como máximo a
cada uno de los aspectos desarrollados del sistema. Los requisitos sirven para
acotar la funcionalidad o la construcción del sistema suponiendo límites
al diseño del sistema y enumerando todas las funcionalidades que debe
cubrir el sistema.

2. Los primeros requisitos: objetivo y alcance

Todo proyecto tiene dos requisitos principales, que son el
objetivo y el alcance. El objetivo define lo que pretende realizar el proyecto.
Si se trata de un desarrollo de software/hardware, define lo que va a hacer
el producto final. Normalmente este punto suele ser el primero de todo plan de
proyecto, ya que es lo que queremos vender a nuestro cliente.

El alcance es el segundo gran requisito de todo proyecto, ya
que pone límites a lo que vamos a desarrollar. Nos dice hasta
dónde va a llegar el sistema que vamos a desarrollar para nuestro
cliente, y cuáles son las necesidades generales que va a cubrir nuestro
sistema. Normalmente el alcance se define dentro del plan de proyecto, tras el
objetivo.

Una vez que en nuestro poyecto hemos definido las
líneas maestras del mismo, como los estudios de viabilidad o la
planificación general, puede comenzar la primera parte del desarrollo
del poyecto: la toma de requisitos.

3. Tipos de requisitos

Un requisito es una necesidad del cliente que debe ser
cubierta por el sistema que le vamos a ofrecer. Los requisitos van a delimitar
cómo quiere el cliente que se comporte el sistema, que
información tiene que manejar y cómo la debe procesar y
presentar.

En este artículo vamos a repasar algunos de los tipos
más importantes de requisitos, organizándolos por tipos sin
entrar en un nivel de detalle muy alto para cada uno de ellos.

3.1 Requisitos funcionales

En este apartado vamos a recoger los requisitos que afectan
directamente a la funcionalidad principal del sistema. Normalmente esta
funcionalidad describe los procesos de negocio a los que se destina el sistema.

Requisitos de Actores

Son todos los requisitos que afectan a los diferentes
actores del sistema, es decir aquellas personas o sistemas externos que pueden
interactuar con el sistema, que van a proporcionarle la información de
entrada y van a recibir la información de salida del sistema. En este
apartado recogeremos requisitos por ejemplo de :

· Usuarios. Son los
responsables de interactuar con el sistema. Pueden ser usuarios físicos
o sistemas externos.

· Grupos. Permite realizar
conjuntos de usuarios con características comunes, para simplificar las
reglas de interacción entre los usuarios y el sistema.

· Perfiles. Permite agrupar
todas las características que distinguen a un usuario o grupo.

· Papeles (roles),. Permite
asignar grupos de funcionalidades a los usuarios y grupos, permitiendo
diferenciar el comportamiento de los usuarios con el sistema según la
actividad o proceso a realizar en el mismo.

Requisitos de Interfaz

En este apartado aparecen reflejados todos los requisitos
que definen la forma de enviar la información a procesar por los
usuarios al sistema, y  la forma de recibir la respuesta del sistema por
el usuario. Entre ellos podemos distinguir

·        
Medios de interacción (Aplicación de
escritorio, páginas Web, Sistemas de Kiosko, etc)

·        
Pantallas, formularios y demás elementos de la
interfaz de usuario

&midmiddot;        
Mensajes intercambiados y protocolos de
comunicación, fundamentales para describir las interacciones entre
sistemas.

·        
Movimiento por la interfaz de usuario del sistema

·        
CLAMB. Pantallas de gestión normalizadas:
consultas, listados, altas, modificaciones y bajas.

·        
Ayudas a los usuarios. Deberemos recoger el nivel de ayuda
y formato de dicha ayuda que proporcionará el sistema a los diferentes
tipos de usuarios.

·        
Informes, documentos, archivos y datos en general
generados por el sistema.

·        
Internacionalización. Aquí hay que
distinguir entre la internacionalización de la interfaz y la
internacionalización de la información contenida en el sistema.

·        
Accesibilidad. Define los requisitos de adaptación
de un sistema para su uso por usuario con diferentes tipos y grados de
discapacidad.

·        
Libros de estilo y cosmética del sistema. Definen
los diferentes estándares, estilos, formatos de pantallas, formatos de
la información, formatos de salida de los documentos que serán
tomados como guía para el desarrollo del sistema.

Requisitos de Procesamiento

En este apartado incluiremos todos los requisitos que
permiten realizar las principales funciones del sistema. Son aquellos
requisitos que indican qué hacer con los datos de entrada, cómo
procesarlos y generar datos de salida. Indican los requisitos que hay que
aplicar a las funciones y procesos internos. Hay que definir qué datos
hay que tratar y mediante qué procesos se van a tratar. Normalmente para
una aplicación de gestióin se recogen los requisitos que definen
la lógica de negocio.

Requisitos de Persistencia

En este apartado se recogen los requisitos que afectan a la
información que se debe persistir en el sistema, es decir la
información que se debe guardar entre

diferentes ejecuciones del sistema. Normalmente tendremos
los requisitos que nos permitirán construir el modelo de datos del
sistema. Normalmente para una aplicación de gestión se recogen
los requisitos que van a definir las entidades, o información de negocio
que se debe persistir.

Requisitos de Gestión y
Administración

Estos requisitos recogen todas las funciones que son
necesarias para gestionar s el sistema, por ejemplo la gestión de
usuarios, gestión de la configuración del sistema y otras
funciones del sistema que se apartan de la función principal del
sistema.

3,2 Requisitos no funcionales

Aquí se recogen todos los requisitos del sistema que
no representan la funcionalidad principal del sistema, sino que fijan
condiciones para realizar dicha funcionalidad.

Requisitos de Disponibilidad

 

En este apartado se incluyen los requisitos que definen la
disponibilidad del sistema, el tiempo que debe estar operativo, así como
el comportamiento del sistema en caso de fallos. Entre ellas podemos enumerar:

§ Tiempo total de
disponibilidad (en %anual)

§ Tiempo medio entre fallos

§ Tolerancia a fallos en el
sistema o en su acceso

§ Tolerancia a fallos de su
base de datos, si la tiene

§ Tolerancia a fallos del
sistema de ficheros, si lo tiene

§ Tolerancia a fallos de
otros sistemas o comunicación con sistemas externos

§ Operativas que deben estar
disponibles en caso de fallos de alguna de las partes del sistema

Requisitos de Rendimiento

En este apartado se recogen todos los requisitos de
rendimiento del sistema, lo que se denominan métricas de rendimiento,
pues suelen ser fácilmente medibles. Entre ellos podemos sugerir los
siguientes:

§ Velocidad de las peticiones
al sistema (número de peticiones que debe responder en cierto tiempo)

§ Tiempo medio de respuesta
por tipo de petición, que sería el tiempo máximo (en
media) que debería tardar el sistema en contestar a una petición

§ Velocidad en la
comunicación con el sistema

§ Velocidad en la
gestión de la interfaz del usuario

 

Requisitos de Calidad

Aquí recogemos los requisitos que afectan a la
gestión de la Calidad en el desarrollo del proyecto. Entre ellos podemos
destacar:

§ Normativas y procedimientos
de gestión del proyecto

§ Normativas y procedimientos
de desarrollo

§ Normativas y procedimientos
de documentación

§ Normativas y Procedimientos
de generación de entregables

§ Normativas de calidad del
Cliente

§ Pruebas de
Certificación de Calidad que deben superar los entregables.

Requisitos de Almacenamiento

Aquí se recogen todos los requisitos que especifican
el cómo, dónde y cuándo guardar los datos persistentes del sistema,
así como la capacidad del sistema de almacenamiento de los mismos, su
seguridad, su fiabilidad, su protección contra fallos o intento de
acceso no autorizado y su política de respaldo.

Requisitos de Trazabilidad

Aquí se recogen los requisitos de trazabilidad de
todas las acciones del sistema, como pueden ser:

§ Acciones de las que se
deben guardar trazas en el sistema

§ Formato y medio de
almacenamiento de cada tipo de trazas

§ Gestión de la
caducidad de las trazas y de sus históricos

§ Control y medio de acceso a
las trazas del sistema.

 

Requisitos de Seguridad

Aquí se recogen todos los requisitos relativos a la
seguridad del sistema, como pueden ser:

§ Control de acceso al
sistema y autenticación de usuarios

§ Políticas de
usuarios y contraseñas, si las hubiere.

§ Desactivación de
usuarios.

§ Control y auditoría
de las acciones de los usuarios

§ Políticas de
gestión de la seguridad y de los elementos y funcionalidades del
sistema.

§ Métodos de
agrupación de usuarios, y de permisos. Esquemas de administración
y almacenamiento de la seguridad

§ Gestión de los roles
de los usuarios, si hubiese.

§ Medidas de
protección del sistema frente a ataques externos

§ Normativas y protocolos de
seguridad que debe cumplir el sistema

§ Auditorías de
seguridad y alarmas.

Requisitos de Escalabilidad

Aquí se recogen los requisitos de capacidad del
sistema y cómo se debe poder ampliar si es necesario. Si el sistema es
utilizado por múltiples usuarios simultáneos, debe disponer de un
plan para redimensionar el sistema al crecer el número de usuarios.

Requisitos Legales y Normativas

En este apartado se recogen los requisitos legales que debe
cumplir el sistema, es decir, toda la normativa legal que aplica al sistema,
las restricciones legales de su uso y las normativas de gestión de la información
confidencial. También se incluyen los requisitos de destrucción
de información confidencial al final del ciclo de vida de la misma.

3.3 Requisitos de sistema

En este apartado se recogen todos los requisitos que debe
cumplir el sistema, independientemente de la funcionalidad que debe cubrir.

Requisitos de Arquitectura

Estos requisitos definen arquitectura y componentes del
sistema, cuando es un sistema creado a partir de varios, modúlalos.

Requisitos de Software

En este apartado recogemos todos los requisitos de software
que se aplicarán al sistema, como pueden ser:

Sistemas operativos de los diferentes módulos que
forman el sistema,  incluyendo versiones y actualizaciones

Software adicional necesario en el sistema

Requisitos de actualización del software de base del
sistema

Requisitos de Hardware

Aquí se recogen todos los requisitos de 
hardware de todos los componentes del sistema. Entre ellos tipos de servidores,
configuración de los mismos, tipos de unidades de disco y
configuración, sistemas de backup, etc.

Requisitos de Comunicaciones

Aquí recogemos los requisitos necesarios para
interconectar nuestro sistema, tanto interiormente, si es complejo, como
exteriormente. Definiremos los parámetros de red requeridos,
topología, tipos de enlace, anchos de banda, etc.

Requisitos de Integración

En este apartado recogeremos los requisitos de
integración de nuestro sistema con otros sistemas externos o del
cliente. Deberemos incluir los protocolos que se deben soportar, los servicios
que nos proporcionan o que debemos proporcionar, las aplicaciones con las que
debemos interactuar, etc.

Requisitos de Contingencia

Aquí enunciaremos los requisitos que debe cumplir
nuestro sistema en caso de contingencia, y que servirán de base para
desarrollar el plan de contingencia del sistema.

4. Captura de requisitos

Una vez que ya sabemos lo que necesitamos recoger, hay que
realizar un proceso de captura de requisitos. Los requisitos nos los van a
proporcionar diferentes figuras del cliente, ya que debemos satisfacer las
demandas de todos ellos.

4.1 El responsable del  usuario

El responsable del usuario es la figura que conoce los
requisitos de negocio del sistema a implementar. Sabe qué demanda
debemos cubrir, luego conoce el “QUÉ” debemos hacer.

4.2 El responsable de TI

El responsable de TI del cliente es el que conoce el estado
actual de la tecnología dentro de las instalaciones del cliente, y hacia
dónde quiere enfocar su mejora. Es el que nos va a responder al
“CÓMO” realizar el sistema.

4.3 El responsable financiero

El responsable financiero del cliente es la figura que
conoce cuánto se puede gastar para implementar el sistema y
cuándo puede desembolsar dicha cantidad. Él por tanto conoce el
“CUÁNTO” y el “CÚANDO” se podrá
abordar el desarrollo.

5. Métodos de captura

Una vez que sabemos lo que queremos buscar, es decir, los
requisitos que nos hace falta encontrar, hay que utilizar diferentes
técnicas para recoger dichos requisitos.

5.1 Extracción de requisitos desde la
información proporcionada por el cliente

Normalmente el cliente comenzará
proporcionándonos algo de información dentro de la primera
petición. Dicha información puede tener un carácter
heterogéneo, mezclando datos actuales de la empresa con documentos que
recogen la idea de lo que necesitan.

5.2 Entrevista con el Cliente

Una vez analizada la documentación inicial, se debe
comenzar la ronda de entrevistas con el cliente. Para ello seleccionaremos
interlocutores válidos en cada una de las tres áreas: TI,
financiera y de negocio, para ir obteniendo la lista de requisitos del sistema.
De cada reunión deberíamos crear un documento de acta de
reunión, y un documento global de requisitos del sistema, que
servirá de referencia para todo el desarrollo del sistema.

5.3 Observación del usuario

Es muy importante observar al futuro usuario del sistema en
su propio entorno para saber qué tareas realiza actualmente y
cuáles debe cubrir el sistema a desarrollar. Cada organización
realiza tareas de una forma particular, algunas veces buenas, otras mejorables,
pero suele ser muy complicado cambiar por completo la forma de trabajar de la organización. Por ello normalmente el sistema se adapta a la organización, y no
la organización al sistema.

Esta observación se hace especialmente importante y
obligatoria si desconocemos el negocio del cliente o la operativa habitual para
este tipo de usuarios. Si no se hace esta observación pueden pasarse
detalles por alto que luego serán difíciles de implementar. Y
como dice el doctor House: “El paciente siempre miente”. Con esto
quiero decir que el usuario te va a  decir siempre que es todo muy
sencillo y se le van a “olvidar” esas casuísticas que luego
serán muy difíciles de implementar.

5.4 Observación de sistemas semejantes

Otra técnica de extracción de requisitos es
realizar el mismo proceso en otro entorno diferente, quizás en otra
organización a la que tengamos acceso. Probablemente no sea extrapolable
directamente los requisitos obtenidos, pero sí nos puede dar una buena
base para saber qué tenemos que buscar y obtener una colección de
requisitos de partida que permita agilizar la toma de requisitos.

5.5 Consulta a los expertos

Otra técnica de toma de requisitos es realizar una
entrevista a un experto en la materia. Podemos identificar dos tipos de expertos: los que conocen la parte funcional del sistema y los que conocen la parte
técnica del sistema. De los expertos podremos obtener no sólo
requisitos, sino también un conjunto de recomendaciones y buenas
prácticas que nos evitarán problemas en nuestro desarrollo.
También nos permitirán descubrir problemas y casuísticas
ocultas, que al tenerlos en cuenta nos evitarán luego retrasos en los
desarrollos.

5.6 Obtención de métricas
representativas

Todo sistema desarrollado debería funcionar (bueno,
eso es en teoría) y además hacerlo con un rendimiento adecuado.
Para conocer ese rendimiento “adecuado” debemos tomar
métricas del rendimiento del sistema que queremos desarrollar, bien
tomando métricas de sistemas antiguos, si estamos sustituyendo a un
sistema ya existente, o de sistemas semejantes.

5.7 Uso de prototipos

Otra técnica de captura de requisitos es la
creación de prototipos del sistema. Los prototipos son sistemas
teóricos o desarrollados que nos permiten presentar las ideas de lo que
queremos realizar al cliente para su validación. De la
observación del prototipo se obtendrán nuevos requisitos para
completar la lista.

Hay varios tipos de prototipos:

§ Prototipos
teóricos
. Serían diseños en papel (documento,
presentación, páginas Web o similar) en la que se explica
mediante pantallas y diagramas la futura funcionalidad del sistema. El
desarrollo de las herramientas de creación de documentación
actuales (procesadores de texto, herramientas de presentación,
herramientas de edición de páginas Web) permite hacer prototipos
de sistemas informáticos fácilmente, que al menos nos
darán una idea de cómo quedará el sistema.

§ Prototipos no
funcionales o de “cartón piedra”.
Son maquetas del
sistema que muestra algunos datos fijos, y la interfaz de usuario. Están
a medio camino entre un prototipo teórico y un prototipo funcional. Si
el sistema incluye una interfaz de usuario avanzada se puede hacer un prototipo
no funcional con alguna herramienta de desarrollo rápido que nos permita
validar los requisitos funcionales de interfaz de usuario y los principales
procesos de negocio.

§ Prototipos funcionales.
Son sistemas que ya incluyen una cierta funcionalidad, normalmente
desarrollados sobre una arquitectura más sencilla. Pueden servirnos para
probar el futuro comportamiento del sistema o para realizar pruebas de
concepto, en las que se pruebe si una cierta solución técnica es
posible.

Es importante entender que los
prototipos son descartables, es decir, no formarán parte del futuro
sistema. Esto es así pues el prototipo debe ser realizado en el menor
tiempo posible y con el menor coste  (dos requisitos para el prototipo que
no tienen porqué estar presentes en el sistema final).

5.8Requisitos autoimpuestos

Este tema es bastante delicado. Los requisitos autoimpuestos
son los requisitos que se añaden a la lista de requisitos sin que el
cliente los haya solicitado. Normalmente son requisitos que restringen la
construcción del sistema. Por ejemplo podemos incluir en este tipo de
requisitos:

§ Impuestos por la organización. Se introducen por el modo de entender los desarrollos de la organización  Pueden ser requisitos que afecten a la metodología de
desarrollo, a la gestión de la calidad o incluso a la tecnología.

§ Impuestos por el
conocimiento del equipo de desarrollo. Pueden aparecer requisitos debido a las
carencias técnicas del equipo que realiza el proyecto.

§ Impuestos por la costumbre.  Son requisitos que se introducen sin ser contrastados, normalmente debidos
al modo de trabajo de los desarrolladores. En ocasiones se añaden para amoldar
el desarrollo de un proyecto a lo que interesa al equipo de desarrollo. Prima
el interés personal sobre el interés del proyecto.

La detección de
este tipo de requisitos es bastante complicada. Para ayudar a ello, cada
requisito añadido a la lista de requisitos debería tener la
referencia del documento, acta o anotación en la que quedó
reflejada su introducción.

6. Árboles de decisión y plantillas
de requisitos

Para realizar una captura eficiente de requisitos debemos
llevar preparada una posible lista de requisitos a capturar, es decir, hacer
los deberes antes de iniciar el proceso de captura. Para ello podemos utilizar
un par de técnicas que nos ayudarán a realizar este proceso:

§ Plantillas de requisitos.
Si vamos a repetir el proceso de toma de requisitos con una cierta frecuencia
conviene preparar una plantilla de requisitos, que nos facilite la tarea de la
toma de requisitos. En esta plantilla podemos recoger los requisitos que hemos
dado como ejemplo o los que sean necesarios para realizar la toma de
requisitos.

§ Árboles de
decisión. A medida que el proceso de toma de requisitos se hace
más habitual, participando en más proyectos, conviene utilizar
árboles de decisión que  ayude a los nuevos integrantes del
equipo a realizar la toma de requisitos de manera más rápida y
fiable. El árbol de decisión se irá montando poco a poco
con las diferentes características comunes y particulares de los
proyectos en los que participemos.

7. Métodos de documentación

Como siempre, todo el proceso de toma de requisitos hay que
documentarlo. Vamos a exponer algunos de los métodos de gestión
de los requisitos más habituales:

7.1 Lista de requisitos

Es el método más simple. Consiste en crear una
lista ordenada de requisitos, en la que asignaremos a cada requisito un identificador
único. Se puede hacer a mano, pero es difícil controlarla.

Para la creación inicial de las listas podemos utilizar
algún sistema que nos permita rápidamente gestionar los
requisitos. Un ejemplo podría ser una simple hoja Excel o un esquema de
Word o similares. Si el documento no va a ser complejo, podemos comenzar por
aquí, pero pronto nos daremos cuenta de que no es el mejor sistema, ya
que por ejemplo, la trazabilidad y la gestión de las versiones pronto se
complica. Nos obliga a realizar un montón de tareas a mano, muy
repetitivas y propensas a errores. Aun así, muchas organizaciones
utilizan este medio para presentar a sus clientes los requisitos de grandes
proyectos…

7.2 Priorización y categorización de
requisitos

Después de obtener la lista global de requisitos hay
que clasificarlos y priorizarlos, ya que fijarán la importancia en su futuro
desarrollo.

7.3 Matriz de trazabilidad

La matriz de trazabilidad es una técnica que liga los
requisitos a los diferentes elementos del desarrollo. Por ejemplo podemos hacer
una matriz de trazabilidad de cada requisito con los casos de uso en los que
aparece. Dado que la matriz es muy grande, conviene hacer vistas de la misma si
queremos incluirla en los documentos de análisis

Se pueden trazar varios tipos de matrices de trazabilidad.
Algunos ejemplos pueden ser:

 

·        
Requisitos frente a fases de desarrollo del sistema

·        
Requisitos frente a Actores

·        
Requisitos frente a Casos de Uso

·        
Requisitos frente a entidades del sistema

·        
Requisitos frente a procesos de negocio

·        
Requisitos frente a interfaces del sistema

·        
Requisitos frente a módulos

 

Hay que tener en cuenta que las matrices de trazabilidad
suelen tener un gran tamaño, por lo que conviene partirlas en matrices
más pequeña, usando la agrupación de requisitos.

.

7.4 Control de versiones

Como todo documento del proyecto, el listado de requisitos
debe estar controlado mediante algún sistema de control de versiones. Lo
ideal es que elijamos un sistema que nos dé la siguiente
información:

·        
Versiones del documento, con posibilidad de recuperar
fácilmente versiones anteriores

·        
Ver las diferencias entre versiones

·        
Identificar las diferencias mediante un resumen o cuadro de
modificaciones

7.5 Documento final

Debemos elegir un mecanismo para generar el documento final
que será entregado al cliente. Este documento fija por contrato las
funcionalidades que debe cubrir el sistema a desarrollar, por lo que es
conveniente que cualquier alteración sobre el mismo quede documentada.
Debemos prestar especial importancia a:

·        
Formato del documento. Debe ser un formato estandarizado y de
amplia difusión. Un ejemplo puede ser el formato PDF, pues es
fácilmente generable y legible desde cualquier plataforma.

·        
Versión y control del documento. Ya que es habitual el
intercambio de documentos con el cliente hasta la obtención de una
versión definitiva es muy importante detallar la versión del
documento y la lista de cambios entre versiones del mismo.

·        
Control de distribución. Debemos asegurarnos de que quedan
reflejados en el documento la lista de interesados del mismo, así como
la lista de personas que deben recibir copia del mismo.

·        
Control de aprobación. Debemos incluir también la
lista de verificaciones y aprobaciones del documento. Lo ideal es que el
documento fuese firmado. A estas alturas debería ser ya posible la firma
digital de los mismos.

·        
El documento debe estar depositado en un sistema de gestión
de la documentación, de manera que quede accesible y claramente
identificado por los interesados.

7.6 Validación de requisitos

El último paso en la gestión de requisitos es
la validación de los mismos por el cliente. Una vez validados, los requisitos
están cerrados y listos para ser enviados al equipo de análisis y
desarrollo.

7.7 Aplicaciones de gestión de requisitos

Dado que la gestión de requisitos es un proceso
crítico y complejo, ya que define contractualmente lo que nos
comprometemos a desarrollar, la gestión de los mismos se suele hacer con
ayuda de aplicaciones específicas para la gestión de requisitos.

7.8 Un ejemplo: REM

Un ejemplo de aplicación de gestión de
requisitos es el desarrollo REM, que está cubierto en otro de los tutoriales
ya publicados (ver https://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=REM)
Esta herramienta permite hacer una gestión bastante sencilla de los
requisitos de un proyecto, generando el documento final. Dado que utiliza XML
como formato interno, se pueden usar sistemas de control de versiones
típicos de código fuente para almacenarlos y compararlos.

8. Agrupación de requisitos

Antes de cerrar la etapa de toma de requisitos debemos
realizar un análisis de los mismos. En esta etapa organizaremos y
repasaremos los requisitos capturados, hasta obtener la lista final de
requisitos. En esta etapa debemos organizar los requisitos según
diferentes criterios.

·        
Agrupación por alcance y fases. Si el alcance del
proyecto es muy amplio conviene dividir el proyecto en fases, limitando el
alcance de cada fase hasta cubrir el alcance final. En este caso la primera
organización de los requisitos es identificar a qué fase afecta
cada uno.

·        
Agrupación funcional. Otra agrupación
importante es la agrupación funcional, en la que agrupamos requisitos
que tienen una relación funcional directa, por ejemplo según el
tipo de datos que van a manejar o según los procesos de negocio que van a
cubrir.

·        
Agrupación modular. En este caso primero dividimos
el sistema en módulos y luego identificamos a qué modulo afecta
cada requisito.  Esta división permite detectar el alcance de cada
requisito, delimitando las partes del sistema a las que afecta.

·        
Agrupación por producto. Si el sistema se compone
de productos separados, los requisitos pueden quedar también asociados a
alguno de los productos, limitando también su alcance, como en el caso
anterior.

9. Casos de uso

El uso de los casos de uso, ideados por Ivar Jacobson, es
una buena herramienta para la captura y el análisis de requisitos. Los
casos de uso permiten definir de forma sencilla el comportamiento del sistema
desde el punto de vista de interacción con el usuario u otros sistemas.

Un caso de uso es una descripción textual de la
secuencia de interacción de los usuarios (actores) con el sistema. Al
escribir el caso de uso se considera al sistema como una “caja
negra”, ya que no nos importa lo que sucede dentro sino las posibles
interacciones entre el sistema y el usuario. Los casos de uso son documentos de
texto breves (normalmente caben en una página) en la que se va
detallando los posibles caminos de interacción entre el usuario y el
sistema.

Los casos de uso los explicaremos en detalle en la segunda
parte de este artículo, debido a su extensión.

10. Conclusión

En este artículo hemos dado un repaso a las técnicas
de gestión de requisitos de un sistema, su descripción, su
captura y su gestión. También hemos visto cómo y de
dónde obtener los requisitos de nuestro sistema. Poco a poco iremos
perfeccionando nuestras técnicas de captura de requisitos, de manera que
en el desarrollo de nuestros proyectos no nos llevemos sorpresas.
También hemos visto los casos de uso, una técnica muy usada para
generar y validar requisitos del sistema para la parte de interfaz del mismo.

Con este tutorial hemos ampliado el anterior tutorial
dedicado a la herramienta de gestión de requisitos REM:

3 Comentarios

  1. Muchas gracias mi estimado [Cristóbal González Almirón].

    La verdad me ayudo bastante el tutorial, esta muy bien explicado, claro y adecuado para los novatos como yo, saludos desde México…

Dejar respuesta

Please enter your comment!
Please enter your name here