.

Por Verónica Valdez Alvarado, Project Manager

Hablando del desarrollo en México, podemos inferir que un gran número de los proyectos de desarrollo de sistemas fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos.

Dentro de esa mala administración se pueden encontrar factores como la escasa o nula participación del usuario, lo que puede provocar una pobre definición de los requerimientos, requerimientos ambiguos o inexactos, aunado a esto la mala administración de los cambios generados durante la vida del proyecto, que le pega directamente a la duración del mismo y por ende a la planeación. Dando como resultado la insatisfacción del cliente, la extensión de la duración del proyecto o el fracaso total del mismo.
Para conseguir un proyecto de software exitoso debes comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.
Para poder obtener buenos requerimientos, primero debemos definir que son, que los caracteriza y como pueden clasificarse. Hay muchas definiciones de Requerimiento, considero una de las más completas la siguiente:

“Una capacidad necesitada por un usuario para resolver un problema o llevar a cabo un objetivo”

Ahora que podemos identificar que es un requerimiento, lo siguiente es ver cuáles son las características que debe cumplir.

• Necesario. Si se tiene alguna duda acerca de la necesidad del requerimiento, se pueden preguntar “¿Qué sería lo peor de no incluirlo?” Si no se encuentra una respuesta o cualquier consecuencia, entonces es probable que no sea un requerimiento necesario.
• Completo. Un requerimiento esta completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
• Consistente. Un requerimiento es consistente si no es contradictorio con otro requerimiento
• Correcto. acuerdo entre dos partes. Contiene una sola idea.
• Factible. El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar, generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el requerimiento es no factible hay que revisar la visión del sistema y replantear el requerimiento
• Modificable. Que se pueda realizar alguna modificación sobre el requerimiento y esta sea sencilla, consistente y completa
• Priorizado. Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo Esencial/Critico, Deseado, Opcional Verificable

• Verificable. Si un requerimiento no se puede comprobar, entonces ¿Cómo se sabe si se cumplió con él o no? Debe ser posible verificarlo ya sea por inspección, análisis de prueba o demostración. Cuando se escriba un requerimiento, se deberá de determinar los criterios de aceptación.
• Rastreable. la especificación se debe organizar de tal forma que cada función del sistema se pueda rastrear hasta su conjunto de requerimientos correspondiente. Facilita las pruebas y la validación del diseño
• Claro. Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro

Ahora, los requerimientos los podemos agrupar en una pirámide de tipos para poderlos explicar:

Necesidades

Dentro de la Pirámide de Requerimientos, situados en el punto más alto, se encuentran las necesidades de los Stakeholders, están orientadas a oportunidades (problemas) de Negocio las cuales deben de ser cubiertas de forma satisfactoria. Algunas de estas oportunidades desencadenan la realización de un sistema de Software.

Características (requerimientos No Funcionales)

Características o Cualidades que los Stakeholders esperan como parte del comportamiento del sistema de Software. En ocasiones son orientadas al “Como” en lugar del “Que”. Las características proveen mucha información acerca de como el sistema debe comportase. Están relacionados con las características de calidad del sistema:

Requerimientos de Software (requerimientos funcionales)

Los Requerimientos de Software son las necesidades de los Stakeholders que requiere que el Sistema deba de cumplir de manera Satisfactoria. Son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el ¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema.
Una vez que tenemos identificados los tipos de requerimientos que existen, y las características que deben cumplir, podemos comenzar con la descripción de las actividades que nos ayudarán a realizar una buena obtención de requerimientos. No vamos a descubrir el hilo negro, ya está más que definido el proceso, solo hay que aprender a llevarlo adecuadamente.
A este conjunto de actividades de le denomina Ingeniería de Requerimientos, el cual cumple un papel primordial en el proceso de Desarrollo de Software, es la que nos puede apoyar para lograr proyectos exitosos, ya que se enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema.
Este proceso comprende cinco actividades de alto nivel:

1. Obtención de Requerimientos

Esta fase representa el comienzo de cada ciclo. Es la parte más importante del proceso ya que todo lo que se obtenga en esta fase será la base para la construcción del sistema.
Aquí, los analistas de requerimientos deberán trabajar junto al cliente para descubrir el problema que el sistema debe resolver. Esto por lo regular se hace en una junta llamada kick off o de arranque, donde se debe especificar lo siguientes:

• Objetivo del sistema, y fechas tentativas del inicio y fin del proyecto
• Presentación del Equipo de Trabajo
• Presentación o definición de stakeholders (involucrados en la definición de los requerimientos y líder funcional, que es quien hace la autorización de los documentos en nombre de todo el equipo del cliente)
• Fechas tentativas de reuniones con el cliente (esto se usa cuando es una consultoría la que presta el servicio al cliente)

2. Análisis de Requerimientos

Es el segundo paso que nos dicta la Ingeniería de Requerimientos, implica refinar, analizar, y examinar/escudriñar los requerimientos obtenidos para asegurar que todos los clientes involucrados entienden lo que pidieron, y para encontrar errores, omisiones y otras deficiencias.
En esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.
Las actividades a contemplar durante esta etapa son:

• Reducir ambigüedades en los requerimientos. En esta actividad se realizan las tareas que permiten eliminar los términos que tienen más de una acepción, unificando el léxico empleado.
• Traducir a lenguaje técnico los requerimientos. Los requerimientos, ya con menos ambigüedades, deben ser tratados a los efectos de llevarlos a un lenguaje que se vaya aproximando al lenguaje técnico.
• Plantear un modelo lógico. Se debe construir un modelo del problema ya sea en términos de diagramas de flujo o cualquier otro tipo de representación que se considere conveniente para el modelado y que permita, además, establecer un vínculo con la Etapa de Especificación.

3. Especificación de Requerimientos

En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. Se documenta la descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma como hará sus funciones, definiendo los requerimientos funcionales y no funcionales.

4. Verificación de Requerimientos

Para hacer la verificación se recomienda primero seleccionar varios revisores de diferentes disciplinas puede ser un analista, arquitecto, o incluso un ingeniero de SW, pero debe ser alguien que esté familiarizado con la ingeniería de requerimientos, además debe tener conocimiento de los estándares de documentación de la organización. Se puede preparar un checklist para la revisión de los requerimientos, esto dependerá del proyecto que se esté manejando.
Lo que se debe hacer es realizar revisiones al documento, aplicarles pruebas de escritorio, etc. Aquí un ejemplo de puntos a revisar en los documentos obtenidos:

• ¿Están incluidas todas las funcionalidades requeridas por el cliente? (completa).
• ¿Existen conflictos en los requerimientos? (consistencia)
• ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
• ¿Esta cada requerimiento claramente representado? (entendible)
• ¿Puede ser los requerimientos implementados con la tecnología y presupuesto disponible? (factible)
• ¿Está la especificación escrita en un lenguaje apropiado? (clara)

• ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
• ¿Está claramente definido el origen de cada requerimiento? (rastreable)
• ¿Pueden ser los Requerimientos ser sometidos a pruebas cuantitativas? (verificable)

5. Aceptación de Requerimientos

Este es un proceso donde los analistas involucrados se reúnen con el cliente y comienzan a dar una revisión formal al documento, esto es, comienzan a leer y explicar cada requerimiento, incluso se pueden apoyar nuevamente en prototipos en papel para que quede más claro el funcionamiento, esto con el fin de que todos estén en el mismo entendido de lo que se realizará para cada requerimiento. Una vez que todos estén de acuerdo se hace la aceptación/aprobación de la especificación de requerimientos, se realiza un compromiso formal de que lo contenga la Especificación será lo que se construya y se pide al cliente una aprobación formal vía correo electrónico o una firma sobre el documento físico.

6. Administración de Requerimientos

La administración de requerimientos se realiza durante todo el proyecto, esto implica llevar un buen control de los cambios, asegurarte de hacerle ver al cliente el impacto en costo y/o el tiempo de entrega del proyecto, pero también debes cuidar como pegan estos cambios a los entregables que tienes, según la etapa donde se den.
Otro punto importante es que debes asegurarte de que todas las actividades de tu proyecto se den en tiempo para no causar retrasos en la entrega. Se recomienda tener especial atención en cuidar las versiones de documentos (en un repositorio como Sharepoint) y código (en alguna herramienta como SourceSafe).

Estoy segura que siguiendo estas líneas, tendrás un mejor resultado al final de tu proyecto de desarrollo.

Si prefieres recibir ayuda profesional y evitar errores en la planeación financiera y de calidad en tu proyecto de desarrollo, te invito a que nos contactes.
[hr]

“Somos la mejor opción para acompañar a tu Organización durante su Transformación Digital. Más de 20 años colaborando con empresas nacionales e internacionales.

Si estás próximo a arrancar un proyecto de migración a La Nube, Desarrollo de Software o Aplicaciones Móviles Empresariales y tienes dudas sobre este tema, te invito a que nos contactes”.

Somos una Empresa de Desarrollo de Software, especialista en Desarrollo de Aplicaciones Web, Desarrollo de Apps Empresariales, Microsoft Dynamics 365 y Fábrica de Software. Desarrollamos software basado en Microsoft .NET, y aplicaciones nativas en iOS o Android; para aquellas empresas que sólo requieren la contratación directa de especialistas, brindamos asesoría especializada de acuerdo a las necesidades de nuestros clientes con experiencia en las tecnologías más avanzadas para apoyar tu estrategia en desarrollo de sistemas y desarrollo de app.