Los requisitos son las condiciones que debe cumplir un producto o servicio para satisfacer las necesidades definidas por un cliente, estándar, contrato, etc. Son una pieza fundamental en cualquier tipo de proyecto, más si cabe si hablamos de proyectos de desarrollo de software.
En este artículo te ofrecemos algunas buenas prácticas a la hora de captar requisitos, así como recomendaciones a cumplir para obtener una buena especificación de los requisitos del software, de forma que puedas facilitar el desarrollo de todo el proyecto.
La importancia de la captación y definición de requisitos en proyectos de software
Al hablar de software, las necesidades a cumplir pueden venir definidas por multitud de interesados, como clientes, socios, departamento de operaciones, organismos de certificación, etc. Y en muchos casos estas necesidades no están del todo claras.
Esto es algo crucial ya que la definición y gestión de los requisitos tendrá impacto en todo el proyecto, determinando su alcance, límites del trabajo, criterios de calidad, etc. Unos requisitos mal definidos pueden traducirse en retrasos y errores. Se estima que entre el 40 y el 60% de los errores en el software están causados por una mala definición de los requisitos.
Además, hay que tener en cuenta el coste que supone implementar cambios en el proyecto. Mientras que realizar modificaciones en la fase de definición de requisitos es sencillo y económico, algunos estudios indican que realizar modificaciones en el proyecto cuando este ya está en fases más avanzadas multiplica su coste: x10 si se producen en fase de desarrollo, x20 en fases de test finales e incluso x100 una vez que el software está ya en operación.
Buenas prácticas en la captación y definición de requisitos para proyectos de software
Como hemos visto, hay razones más que justificadas para dedicar los recursos necesarios a la hora de realizar la captación y definición de requisitos. Vamos a comentar a continuación algunas buenas prácticas que pueden ayudarte en esta tarea.
Realización de encuestas
El uso de cuestionarios y encuestas es una fórmula muy común para recopilar información sobre los requisitos demandados por usuarios y clientes. Es una práctica sencilla, rápida y económica para concretar la información cuando tanto los clientes como los desarrolladores tienen claros los requisitos de primer nivel. En caso de que esta información no esté clara o haya requisitos complejos que requieran una mayor comunicación, este método no es suficiente y habrá que complementarlo con otras técnicas.
Reuniones grupales
Hablar de forma directa con los clientes y/o usuarios es algo necesario cuando el equipo de desarrollo no tiene información sobre los requisitos y necesita conocer las necesidades que el software debe cubrir. Hay que resaltar que para que las reuniones grupales sean efectivas debe realizarse una recopilación y análisis previos de las necesidades de los usuarios y el contexto de su organización mediante informes, análisis, datos estadísticos, etc. De esta forma, la reunión podrá hacerse mucho más orientada partiendo de una comprensión de las necesidades generales de la organización.
Uso de prototipos
El uso de prototipos de interfaces creados por los desarrolladores puede ayudar a los clientes a confirmar que el software cubre sus requisitos y a detectar posibles nuevas necesidades. Esto es especialmente útil cuando los desarrolladores tienen un buen conocimiento del sector y sus características, mientras que los usuarios no tengan una idea clara sobre los requisitos.
Investigación interna y externa
En ocasiones la información que se tiene es tan escasa que es necesario realizar un proceso de investigación para obtener respuestas, y con ellas los requisitos. Por ejemplo, responder a preguntas como ¿por qué necesita el cliente este software? ¿Qué desea el cliente que haga el software? ¿Qué han hecho otras empresas al respecto?, etc. puede ofrecer información importante.
Uso de escenarios
Como complemento al punto anterior, el uso de escenarios puede ayudar a mapear los requisitos cuando la información es escasa. En un escenario se plantea un caso de uso de diferentes actores con el sistema, determinando qué funcionalidades o características debe cumplir el software para que pueda ser usado. Implementar diferentes casos de uso en colaboración con el cliente ayudará a tener una idea global de todo lo que necesitan que el sistema haga.
Características de una buena especificación de requisitos de software (SRS)
El documento de especificación de requisitos de software (software requirements specification o SRS) describe cómo funcionará el producto, qué hará y cómo eso cubrirá las necesidades de los clientes y/o usuarios. Es por tanto el resultado de todo el proceso anterior de análisis y captación de requisitos.
El SRS es la base sobre la que se desarrolla todo el trabajo de ingeniería de sistemas una vez que se han definido los requisitos. Es la meta a alcanzar, de ahí su importancia dentro de todo este proceso. Es fundamental que los requisitos se capten y analicen de forma adecuada en primer lugar, y después que se reflejen de forma apropiada en este documento, que servirá de guía común tanto a los usuarios como a los desarrolladores.
Un buen SRS debería cumplir con las siguientes características:
- Ser exacto: el cliente deberá ver reflejadas aquí todas y cada una de las necesidades que espera que cubra el software.
- Ser completo: debe incluir los requisitos a todos los niveles: funcionalidad, diseño, atributos, etc.
- Ser consistente: es decir, que no tenga requisitos que entren en conflicto entre ellos.
- No ser ambiguo: que cada requisito tenga solo una interpretación posible de forma clara.
- Priorizar por importancia: los requisitos deberán definirse en orden de importancia y estabilidad mediante un identificador claro.
- Ser modificable: los proyectos pueden sufrir modificaciones, por lo que el SRS tiene que permitir que se añadan cambios o ampliaciones.
- Ser verificable: de forma que se pueda comprobar y verificar el cumplimiento de los requisitos.
- Ser trazable: de forma que permita conocer el origen de cada requisito durante el desarrollo o futuros cambios.
- Ser independiente en cuanto a diseño: de forma que permita seleccionar varias alternativas técnicas para la realización del sistema.
- Ser testeable: que permita generar test para su análisis de forma sencilla.
- Ser entendible: especialmente para el cliente, teniendo en cuenta que no tiene por qué ser un experto y que usará este documento para revisar que incluye todos sus requisitos.
Centum, tu partner para proyectos de desarrollo de software
En CENTUM Digital contamos con más de 16 años de experiencia ofreciendo servicios de Ingeniería de Sistemas Críticos en los entornos más exigentes, como el Aeronáutico, Naval, Defensa, Ferroviario o Automoción, principalmente orientados a los procesos de Certificación, Safety, Calificación Ambiental y HW/SW Assurance. Si quieres más información sobre nuestros servicios puedes contactar con nosotros.
