Pasos de la Gestin de Requerimientos

Por Joaqun Ibez Marimn, PMP [ Acerca del autor]

Una descripcin simplificada de la gestin de requerimientos contiene
los siguientes pasos principales:
Establecer un plan de gestin de requisitos
Una de las primeras tareas en el proyecto es desarrollar un Plan de
gestin de requerimientos (RMP son sus siglas en ingles). El RMP
describe el enfoque general para gestionar los requerimientos del
proyecto. El documento detalla cmo se generan, organizan,
modifican y trazan los requerimientos en el ciclo de vida del proyecto.
Tambin describe todos los tipos de requerimientos y los atributos
utilizados en el proyecto. Algunas cuestiones que debe clarificar el
RPM son:

Cmo deben usarse las herramientas de gestin de

requerimientos?

Qu tipos de requerimientos sern trazados en el proyecto?

Cules son los atributos de estos requerimientos?

Dnde se crearan los requerimientos-en una base de datos o

solo en documentos?

Entre cuales requerimientos necesitamos implementar

trazabilidad?

Qu documentos se requieren?

Qu requerimientos y documentos sern utilizados como

contrato con un proveedor? Qu metodologa ser utilizada?

El cliente necesita algn documento especfico para cumplir

con su proceso de desarrollo?

Cmo se implementar la gestin de cambios?

Qu proceso garantizar que todos los requerimientos sern

implementados y comprobados?

Qu requerimientos u opiniones necesitamos para generar

informes?

Tcnicas para la recopilacin de requerimientos

La recopilacin de requerimientos es un paso muy importante. Un
error o mala interpretacin de un requisito en esta etapa propagar el
problema a travs del ciclo de vida de desarrollo.
En muchos proyectos es ms fcil agrupar todas las entradas de los
interesados en un mismo tipo de requerimiento,. En otros proyectos,
puede haber la necesidad de distinguir entre "necesidades de los
interesados", que describen los requisitos iniciales, y "solicitudes de
los interesados ", que pueden incluir las solicitudes de cambio
posterior.
Entrevistas: Son utilizadas para recopilar informacin de los
interesados. Sin embargo, la predisposicin y experiencias de la
persona entrevistada influirn en la obtencin de resultados. Es
conveniente la utilizacin de preguntas abiertas que no sugieran una
determinada respuesta.
Anlisis de Documentos: Todo establecimiento de requisitos implica
un cierto estudio de los documentos que definen la razn de ser del
proyecto, tales como planes de negocio, estudios de mercado,
contratos, etc.
Tormenta de ideas: Es una tcnica eficaz porque las ideas ms
creativas y efectivas, son a menudo, el resultado de la combinacin de
ideas aparentemente inconexas. Adems, esta tcnica alienta el
pensamiento de ideas inusuales.

Talleres de Requisitos: Pueden estar diseados para alcanzar la

unificacin de criterios en cuanto a los requisitos de una capacidad en
concreto. Conviene que sean dirigidos y coordinados por un experto, y
son normalmente cortos (uno o varios das). Otras ventajas que a
menudo consiguen es alentar el compromiso de los participantes con
el proyecto, fomentando el espritu de grupo
Creacin de prototipos: Consiste en la creacin de una versin
rpida y poco depurara de un sistema o partes del mismo. Con dicho
prototipo, los usuarios y diseadores tendrn una idea clara de las
capacidades del sistema., aunque podra tener la percepcin de que
los desarrolladores estn en un estadio del diseo ms avanzado de lo
que realmente estn, sugiriendo una impresin de los plazos de
finalizacin demasiado optimista.
Casos de uso: Es una representacin grfica de las acciones que
debe realizar un sistema. Deben complementarse siempre con
atributos de calidad y otras informaciones tales como caractersticas
de la interfaz.
Los casos de uso por s sola no proporcionan suficiente informacin
que permita actividades de desarrollo.
Guiones grficos: Son un conjunto de dibujos que representan un

conjunto de actividades de usuario que describen las que se producen

en un sistema o capacidad existente o prevista. Los guiones grficos
son una especie de prototipos de papel. Los clientes, usuarios o
desarrolladores dibujan pantallas, cuadros de dilogo, barras de
herramientas y otros elementos que creen que deber proporcionar el
software. Los guiones grficos son baratos y permiten eliminar los
riesgos y costos ms elevados de creacin de prototipos.
Anlisis de interfaces: El diseo incorrecto de las interfaces es a
menudo una de las principales causas de sobrecoste y fracaso del
producto. La identificacin temprana de las caractersticas de las
interfaces externas clarifica el mbito de aplicacin de producto,
ayuda en el proceso de evaluacin del riesgo, reduce los costos de
desarrollo del producto, y mejora la satisfaccin del cliente.
Modelado: Es una representacin de la realidad que pretende facilitar
la comprensin. El uso de prototipos y modelos ayuda a eliminar
ambigedades y contradicciones, contribuyendo de forma notable al
xito del proyecto.
Desarrollo el documento de visin
Es un documento de visin es un documento que describe la 'visin', o
plan general, para un determinado proceso de software. Pretende ser
un documento de alto nivel ms breve y general que un documento de
requisitos de producto, y en l se describe lo que se espera llevar a
cabo y las caractersticas que no estn en el alcance, pero que se
prev agregarn al producto en posteriores etapas del desarrollo de
ste
El propsito del documento es recopilar y analizar las ideas que han
surgido para el futuro del producto, y asegurarse de que los
interesados clave tienen una visin clara y compartida de los objetivos
y alcance del proyecto. Identifica alternativas y los riesgos asociados
con el proyecto. Por ltimo, presenta un presupuesto para la fase de
planificacin.

Durante el desarrollo del documento de visin, uno de los logros

principales del anlisis de negocio es que se deriven caractersticas
para las necesidades de los interesados. Las caractersticas deben
tener todos los atributos de un buen requerimiento: Verificable, no
redundante, claro.
El documento de visin debe contener la informacin esencial acerca
del sistema que est siendo desarrollado. Adems de listar todas sus
caractersticas, debe contener:

Una descripcin general del producto.

Un sumario con las capacidades del sistema.

Toda la informacin que pueda ser requerida para comprender

el propsito del sistema.

Tambin pueden listarse todas las necesidades de los interesados que

no fueron recogidas en otros documentos
Crear casos de uso
Los requerimientos funcionales se describen mejor en forma de casos
de uso, que se derivan de las caractersticas. Un caso de uso es una
descripcin de un sistema en trminos de una secuencia de acciones.
Debe ser un resultado observable o un valor para el actor (un actor es

alguien o algo que interacta con el sistema).

Los casos de uso:

Son iniciados por un actor

Modelan la interaccin entre el interesado y el sistema

Describen una secuencia de acciones

Capturan los requerimientos funcionales

Proporcionan algn valor para un actor

Representan un completo y significativo flujo de eventos.

Especificacin suplementaria
Las especificaciones suplementarias recogen aquellos requerimientos
no funcionales (usabilidad, fiabilidad, rendimiento,..) y algunos
requerimientos funcionales internos del sistema que, por tanto, son
difciles de contemplar en los casos de uso.
Creacin de casos de prueba a partir de casos de uso
Tan pronto como se recopilan todos los requisitos, deberamos disear
una forma de comprobar si se implementan correctamente en el
producto final. Los casos de prueba mostrarn a los evaluadores qu
pasos deben realizarse para probar todos los requisitos. En este paso
nos concentraremos en la creacin de casos de prueba a partir de
casos de uso.
Creacin de casos de prueba a partir de especificaciones
complementarias
El enfoque utilizado en el paso anterior no se aplica a las pruebas de
los requisitos complementarios. Dado que estos requisitos no se
expresan como una secuencia de acciones, el concepto de escenarios
no se les aplica, y debe desarrollarse un enfoque individual a cada uno
de los requisitos complementarios.
En este paso, tambin se disearn pruebas de infraestructura y
cuestiones relacionadas con la plataforma.
Diseo del sistema
Los requisitos son la base para el diseo del sistema, que a menudo se
ve facilitada por el uso del lenguaje unificado de modelado (UML)
Bibliografa:
Young, Ralph R, Recommended Requirements Gathering

Practices,STSC, Abril 2002.

Gottesdiener, Ellen, Good Practices for Developing User
Requirements , STSC, Marzo 2008.
Zielczynski, Peter . Requirements Management Using IBM
Rational RequisitePro, IBM Press., 2008.