Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Una técnica para tus requisitos.

0 comments
Una técnica para tus requisitos.

Técnica para requisitos mediante Business Case.

En este artículo quiero contaros una experiencia real sobre requisitos de un proyecto bastante complejo con muchos intervinientes y que se ha enfocado mediante la elaboración de un Business Case para demostrar las distintas situaciones que se pueden dar al interactuar con el sistema.

Un Business Case es un documento que resume los principales aspectos de una acción comercial y suele utilizarse para justificar una inversión en un proyecto. Aplicado a un proyecto de Sw, un Business Case es un documento que describe la situación o situaciones que se pueden presentar como consecuencia de la implementación de los requisitos de negocio.

En el documento, que debe empezar con la personalización de una interacción de un individuo con un sistema , por ejemplo : ” El Sr.  X, se conecta a internet y teclea en su navegador….. ” o “Carlos, el gestor de la oficina se conecta todas las mañanas a su sistema de gestión de expedientes y ….. ” lo que se debe conseguir es que todos los involucrados en el proyecto, tanto si son de las unidades de Negocio de la organización, como equipos internos de IT afectados o clientes finales se vean representados y sus funciones con respecto al sistema identificadas.

Para llegar a una buena definición de un Business Case aplicado a una especificación de requisitos de un proyecto es condición fundamental que el/ los analistas que lo elaboren tengan una  visión global del proyecto con todos los subsistemas involucrados en el mismo, y todas las interacciones de cada uno de las agrupaciones usuarias del sistema , asi como los aspectos organizativos que el proyecto conlleva.

En mi experiencia, es de gran utilidad cuando una vez realizada la primera versión de las especificaciones detectamos que hay dudas y cuestiones que no quedan suficientemente claras a la mayor parte de los intervinientes en la validación de las mismas. En estos casos, elaborando el Business Case, se va a conseguir clarificar y poner en un lenguaje mucho más natural todo lo que tiene que hacer el sistema. Para ello nos basaremos s en el relato de las experiencias de las personas /agrupaciones que interactuan con el sistema y siempre lo redactaremos  de una manera muy clara, coloquial y que refleje situaciones reales que se pueden dar.

Es de utilidad cuando :

– Hay muchos intervinientes en el proyecto y muchos requisitos.

– El proyecto es grande y muy importante para el negocio por lo que conviene  evitar riesgos desde el inicio y que  todo el mundo tenga claro desde el principio lo que va a hacer el sistema.

– El documento de especificaciones genera dudas cuando lo has enviado a validar y tras una primera contestación aún surgen más dudas.

– Hay varios sistemas afectados,  se deben realizar adaptaciones en varios de ellos y además diferentes tipos de usuarios según que sistema se use.

Hay muchas técnicas para la obtención de requisitos que pueden aplicarse en un proyecto, pero esta que os recomiendo consigue acercar y hace tangible los requisitos difusos y complejos a todos los participantes en el proyecto. En próximos artículos , continuando con la práctica de Gestión de requisitos, hablaré sobre las técnicas de obtención de requisitos en Scrum  : “Las historias de usuario”.

Esta otra técnica que os recomiendo es una “Mega historia de usuarios” , si me permitis el simil.

 

 

 

 

 

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*