Desarrollo de Requisitos

Antes de entrar a describir el proceso de desarrollo de requisitos y las actividades que tiene relacionadas, vamos a situar el desarrollo de requisitos dentro de la gran área de ingeniería de requisitos. La ingeniería de requisitos comprende el desarrollo y gestión de requisitos:

  • El desarrollo de requisitos implica entender los requisitos de negocio, identificar los requisitos de usuario y trasladar los requisitos de usuario y de negocio a requisitos de sistema/software.
  • La gestión de requisitos implica gestionar los cambios de requisitos y mantener la consistencia entre los requisitos y otros productos de trabajo del proyecto.

Las principales actividades realizadas durante el proceso de desarrollo de requisitos son:

  1. Obtención de requisitos
  2. Búsqueda de requisitos
  3. Definición de requisitos
  4. Escritura de requisitos
  5. Verificación de requisitos
  6. Puertas de calidad
  7. Revisión de requisitos
  8. Priorización (fig. desarrollo de requisitos)

Obtención de Requisitos

La obtención de requisitos se define como el proceso de identificar las necesidades del negocio, solucionando las posibles disparidades entre las personas involucradas en el mismo, con el propósito de definir y destilar los requisitos para cumplir las restricciones impuestas por las distintas partes.

Un buen proceso de obtención de requisitos soporta el desarrollo de la especificación de los requisitos, de tal forma que tengan los siguientes atributos:

  • Los requisitos han de ser completos, consistentes y han de estar dentro del alcance del proyecto.
  • Los requisitos son identificados de forma única y han de priorizarse.
  • Cumplen con los objetivos de los clientes.
  • Son viables y apropiados para el desarrollo.
  • Están indicados de forma clara y no ambigua.
  • Los requisitos han de ser “testeables”, es decir, es necesario que sean comprobables para poder validarlos y verificarlos en etapas posteriores. Deben tener capacidad de prueba.

En la obtención de requisitos se necesita tener un entendimiento de la organización en la que se va a utilizar la aplicación que se va a desarrollar, así como un entendimiento de la misión del sistema dentro del contexto de la organización.

La siguiente tabla muestra algunos de los factores a tener en cuenta durante este proceso. Estos factores se han clasificado en 3 niveles: organizacional, factores de entorno y de proyecto.

NivelFactor
OrganizacionalPersonas que presentan las entradas del sistema objetivo
OrganizacionalUsuarios de las salidas del sistema objetivo
OrganizacionalFormas en las que el sistema objetivo cambiaría la forma de hacer negocio de la organización
OrganizacionalEl papel del sistema objetivo dentro de un sistema mayor
EntornoRestricciones de hardware y software impuestos en el sistema objetivo
EntornoLa madurez del dominio del sistema objetivo
ProyectoLos atributos de las distintas personas involucradas en el proyecto (usuarios finales, patrocinadores, desarrolladores y analistas de requisitos) ejemplos: estilos de gestión, experiencia en el dominio
ProyectoLas restricciones impuestas por las personas involucradas en el proceso de obtención de requisitos

La obtención de requisitos es un proceso complejo. Hay que tener claro que no hay que esperar a que los clientes presenten los requisitos con una lista de necesidades concisa, completa y bien organizada. Los analistas de requisitos deben clasificar la información que surge de la voz del cliente en varias categorías, de tal forma que se pueda documentar de una forma apropiada y se pueda usar de la forma más sensata posible.

A continuación se propone una serie de categorías en las que se puede clasificar esta información:

CategoríaDefinición
Requisitos de negocioCualquier cosa que describa los beneficios financieros, de mercado u otros beneficios de negocio que los clientes o la organización puedan obtener de un producto.
Casos de uso o escenariosLas declaraciones generales de metas de usuario o tareas de negocio que necesitan realizar con el sistema pueden ser probablemente casos de uso, mientras que las descripciones de tareas específicas representan escenarios de uso.
Reglas de negocioCuando un cliente dice que algunas actividades solo las pueden realizar ciertos individuos o roles, bajo unas condiciones concretas, pueden estar describiendo una regla de negocio. Son principios operativos sobre un proceso de negocio.
Requisitos funcionalesDescriben los comportamientos observables que el sistema debe exhibir como respuesta del sistema.
Atributos de calidadLas afirmaciones que indican cómo de bien realiza el sistema alguna tarea o cómo de bien deja al usuario realizar alguna acción, un tipo de requisito no funcional.
Requisitos de la interfaz externaDescriben las conexiones entre el sistema y el resto del universo.
RestriccionesSon condiciones que limitan las opciones disponibles para el diseñador o programador. Representan otro tipo de requisitos no funcionales que se deberían documentar en la especificación de requisitos.
Definiciones de datosSiempre que los usuarios describan el formato, los valores permitidos, o los valores por defecto para cada item de datos o la composición de una estructura de datos de negocio compleja, están presentando una definición de datos. Agrupar todo esto es un diccionario de datos proporciona una referencia que los participantes del proyecto pueden utilizar durante el desarrollo y mantenimiento del proyecto.
Ideas de soluciónSi un cliente describe la forma específica de interactuar con el sistema para llevar a cabo alguna acción se trata de una solución sugerida, no un requisito.