Los requisitos claros y bien comunicados ayudan a los equipos de desarrollo a crear el producto solicitado.

Muchas veces nos encontramos ante requisitos definidos a alto nivel, pero gracias a las metodologías ágiles podemos ir clarificándolos y verificándolos sprint a sprint, de forma iterativa.

Según el glosario estándar de terminología de ingeniería del software del IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) el requisito es:

1. Condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo.
2. Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de un sistema para satisfacer un contrato, estándar, u otro documento impuesto formalmente.
3. Una representación en forma de documento de una condición o capacidad como las expresadas en 1 o en 2.

Las principales ventajas de tener una buena especificación de requisitos son:

1. Ayuda a garantizar que todas las partes interesadas tengan un entendimiento común del sistema que se va a desarrollar. Esto evita cualquier malentendido durante las etapas posteriores del desarrollo.
2. Sirve como punto de referencia para todas las partes interesadas durante el proceso de desarrollo.
3. Ayuda a identificar cualquier brecha en los requisitos en una etapa temprana.
4. Reduce el costo general y el tiempo de desarrollo, ya que evita la repetición del trabajo debido a cambios en los requisitos.

Desde el área de calidad y pruebas, el primer paso para entender qué tenemos qué probar es leer los documentos que detallan los requisitos del producto, que establece el Sistema Bajo Prueba (SUT). Entre ellos se encuentran:

La especificación de Requisitos de Negocio o Requisitos Empresariales (BRS).

Contiene la información sobre el negocio y los detalles sobre los procesos que deben implementarse en el software y si se requieren nuevas funciones. Es un documento formal, creado por un analista de negocios, que detalla los requisitos proporcionados por el cliente. Y define sus necesidades. Este documento se utiliza desde el principio hasta el final del proyecto.

En general, BRS contiene la cantidad máxima de usuarios concurrentes que van a usar el sistema, los tipos de usuarios, los conocimientos informáticos, los problemas a los que se enfrentan los usuarios actualmente. También proporciona una descripción del sistema actual y posibles expansiones futuras.

BRS también describe los entregables o lo que espera el cliente y describe el nivel de confiabilidad esperado por el software.

BRS no está escrito utilizando términos excesivamente técnicos.

La especificación de Requisitos de Software (SRS).

Un SRS es un documento que proporciona una descripción completa del comportamiento del futuro software o producto que se va a desarrollar. Lo crea un analista de sistemas, un arquitecto de sistemas o un analista de negocios. Describe cómo funciona el negocio cuando se utiliza el software o la aplicación. En este documento las especificaciones están descritas de una manera más técnica o formal.

La especificación de Requisitos Funcionales (FRS).

Los requerimientos funcionales de un sistema son aquellos que describen cualquier actividad que este deba realizar, es decir el comportamiento o función particular de un sistema o software cuando se cumplen ciertas condiciones.

Los requisitos funcionales comienzan describiendo la funcionalidad requerida según lo esencial que sea para la aplicación. Los requisitos funcionales se centran en la funcionalidad del usuario final no en la lógica interna.

Todos estos documentos que hemos mencionado anteriormente ayudan a identificar qué tenemos que probar, cómo tenemos que probarlo y qué necesitamos para probarlo.

 

Los equipos de calidad y pruebas de SIPSA trabajan para alcanzar los más altos niveles de calidad del software, centrándose en la definición de los casos de prueba desde las primeras etapas del ciclo de vida del producto.

Contacta aquí para solicitar más información sobre cómo podemos ayudarte en la definición y ejecución del plan de calidad de tu proyecto IT.