Proceso de gestión de requerimientos

Los requerimientos son descripciones de lo que el sistema debe hacer y el servicio que debe ofrecer al usuario final, los ingenieros de esta área deben descubrir, analizar, documentar y verificar en toda esta etapa, de manera que, al final, el cliente reciba un producto que realmente le sirva para el problema planteado.

En dicha fase, se realiza un análisis en el cuál se toma en cuenta de forma directa al usuario, ya que éste es el que usará e interactuará con el sistema, basado en un problema real, ya sea que lo que actualmente estén usando cuente con una tecnología obsoleta (como la migración de algo que está programado en COBOL a algo en Java), o la actualización de una base de datos.

Introducción

En muchas ocasiones, sobre todo en las grandes empresas, la interacción directa con el usuario se hace muy difícil, ya que los equipos de trabajo se encuentran dispersos ya sea en distintas oficinas, estados o incluso países.

Es necesario y obligatorio descubrir cuál es el tema a resolver, sus restricciones y además, que el presupuesto y el tiempo no se sobrepasen de lo que originalmente está planteado, algo que está dentro de la Ingeniería de Software y que es una de las partes más difíciles de cumplir en la realidad.

Al identificar el problema y reconocer las necesidades, la ingeniería de requerimientos toma en cuenta los puntos de vista de los participantes, muchos de ellos con entrevistas (abiertas o cerradas, no muy recomendado) o con casos de uso (que hacen más fácil la identificación).

La importancia de la documentación radica en utilizar un lenguaje natural, ya que en la mayoría de las ocasiones, el usuario final no cuenta con el mismo conocimiento informático del desarrollador y para que esto se entienda con claridad, deben evitarse los términos muy técnicos, además de ser claros y concisos.

Además, se requiere hacer distinción sobre lo que es obligatorio y lo que es deseable ya que lo primero será lo más importante para el producto final y lo que realmente resolverá la situación que se quiere. Hay que detallar con claridad también qué es lo que NO se quiere que haga el sistema, para evitar complicaciones y trabajo “inútil”.

Inicio del proceso

El ciclo del proceso inicia con el descubrimiento y termina con la documentación de los requerimientos, como se muestra en la siguiente tabla:

Descubrimiento de requerimientos	Interactuar con participantes del sistema para descubrir sus requerimientos
Clasificación y organización de requerimientos	Toma la compilación no estructurada de requerimientos, agrupa requerimientos relacionados y los organiza.
Priorización y negociación de requerimientos	Se preocupa por priorizar, encontrar y resolver conflictos. Implica reunión de participantes
Especificación de requerimientos	Pueden ser formales e informales

Como se indica, al principio se revela qué es lo que se quiere, después se organiza dependiendo las prioridades, luego se negocia cualquier tipo de conflicto y al final se realiza la especificación.

En el primer punto se tiene qué responder a la pregunta “¿Qué beneficio traerá esto a la organización?”, ya que todo cambio debe ser algo que exprese una solución a un problema o que desee optimizar una forma de trabajo.

Algunos de los problemas que se ubican en este punto, como se mencionaba en la introducción es que muchos de los usuarios finales no están concentrados en el mismo lugar, por lo que los ingenieros carecen del dominio del cliente y los participantes no saben qué es factible o qué no (no saben qué realmente quieren o qué se necesita).

Un ejemplo personal sería la redacción de internet de un periódico en el que trabajé por tres años y medio. El proceso de colocación de notas era “tardado” ya que el manejador de contenidos no era amigable al usuario y requería de varias cosas antes de que la nota apareciera en la página web.

Función:                 Colocar nota en página de internet de forma rápida

Descripción:          Que el tiempo en colocar una nota desde el manejador hasta la web no pase de dos minutos.

Entradas:                Texto, imagen

Salidas:                   Texto e imagen ya en la web

Destino:                   Página web del diario

Acción:                Evitar el uso de muchas funciones, que el usuario final (lector de internet) no ve como importantes, como lo son el uso de puntos destacados obligatorios para poder publicar y otras como el hecho de que el editor web tenga qué ‘cortar’ la imagen en otro programa para que ésta se pueda ‘subir’ al manejador de contenidos. Que al final sea sólo un título, un sumario, el cuerpo de la nota y una imagen.

Requerimientos:       Cambio del manejador de contenidos en uno más simple y amigable      al usuario.

Precondición:           Debe haber información suficiente para poder publicar un título y un      sumario.

Postcondición:         La nota puede editarse después para agregar más información.

Efectos colaterales: Ninguno

Se realizaron entrevistas a los editores web para saber qué cambiarían de su sistema.

Validación y técnicas

Esta parte se usa para entender los procesos operacionales y derivar requerimientos de apoyo para dichos procesos. La etnografía observa el trabajo diario de quienes usarán el sistema, la forma real en que trabaja la gente (que en muchas ocasiones varía mucho del cómo deberían trabajar), conocimiento de actividades y está totalmente enfocada en el usuario final.

La validación verifica que los requerimientos definan realmente la necesidad del sistema que quiere el cliente, se debe comprender la forma en que el sistema se ajusta al trabajo del usuario.

Errores en documento de validación = Grandes costos y pérdidas.

Técnicas de validación de requerimientos

Revisiones	Se verifican errores e inconsistencias
Creación de prototipos	Se muestra un modelo ejecutable del sistema
Generación de casos de prueba	Requerimientos deben ser comprobables
Comprobación de validez	Identificar funciones adicionales a requerir
Comprobaciones de consistencia	Requerimientos no deben estar en conflicto
Comprobaciones de totalidad	Definir funciones y restricciones pretendidas
Comprobaciones de realismo	Deben considerar que en realidad se implementen
Verificabilidad	Demostrar que el sistema entregado cumple los requerimientos

Planeación

El impacto de estas técnicas es que deben evolucionar, ya que el ambiente técnico las hace cambiar y además, deben responder a las siguientes preguntas.

• ·         ¿El requerimiento es coherente con los objetivos generales?
• ·         ¿Se es claro y no sobran detalles técnicos en el documento?
• ·         ¿Cada requerimiento es claro y no muestra algo no esencial?
• ·         ¿No hay ambigüedades?
• ·         ¿Las fuentes son claras para cada requerimiento?
• ·         ¿Hay requerimientos en conflicto?

Estas son las formas que plantea Pressman para asegurarse que el equipo de desarrollo está construyendo el sistema correcto.

Conclusión

En las organizaciones actuales, este proceso es muy importante y además, debe estar sujeto a técnicas de desarrollo ágil que permitan cambios a tiempo, ya que en las grandes empresas suele haber inconvenientes durante el proyecto que, por necesidades del cliente tienen que realizarse.

Se requiere tener especial cuidado en el costo, ya que los clientes no querrán desperdiciar su dinero en un plan que no es concreto y que no solucionará su problema inicial en el plazo que tienen acordado.

Debe haber además, un seguimiento tanto al sistema como a los requerimientos ya que al entregar el producto todo debe estar conforme a la necesidad establecida durante la identificación.

La prioridad deben ser las necesidades recurrentes, los problemas generales que se tienen con el software o aplicaciones actuales y, como se maneja en las metodologías ágiles, entregar un producto usable o un avance cada cierto tiempo para involucrar al cliente en el proceso y que se observe la evolución y el trabajo de los ingenieros.

El equipo de desarrollo además debe comprender y controlar cada cambio que pueda surgir durante el proceso. En mi experiencia profesional he tenido varios problemas en lo que es la parte del seguimiento, ya que se inicia un proyecto y no se verifica en qué paso va, o si se está cumpliendo con lo establecido, dos partes muy importantes dentro de la ingeniería de requerimientos.

De esta forma concluyo el trabajo esperando la evaluación de la asesora.

Bibliografía:

Ian Sommerville. (2005). Ingeniería de Software. Madrid, España: Pearson Education.

Roger S. Pressman. (2010). Ingeniería del Software. Un enfoque práctico. New York: Editorial McGraw Hill.