Los 4 tipos de requerimientos utilizados para hacer análisis de negocio

Imagen por: Halacious.

La disciplina del análisis de negocio, abarca las herramientas para la identificación de necesidades y soluciones a la más amplia variedad de problemas en empresas y organizaciones. El punto de partida para llevarlo a cabo son los tipos de requerimientos que se pueden identificar y documentar.

Todo proyecto comprende actividades para el levantamiento, análisis y gestión de los requerimientos que solicitan los clientes y otros interesados. Lograr proporcionar soluciones efectivas a esos requerimientos es indispensable para el éxito. 

En este artículo te presentamos los 4 tipos de requerimientos definidos por la guía BABOK, uno de los estándares internacionales de mayor reconocimiento en la práctica de análisis de negocio y gestión de requisitos.

Los tipos de requisitos BABOK son:

• Requerimientos de negocio.
• Requerimientos de los interesados.
• Requerimientos de la solución. Estos a su vez se subdividen en:
• Requerimientos funcionales.
• Requerimientos no funcionales.
• Requerimientos de transición.

1. Requerimientos de negocio

Comprenden las metas, objetivos y resultados esperados que describen porque la iniciativa de cambio (el proyecto) se está desarrollando. Pueden aplicar a toda una empresa. Área de negocio o una iniciativa especifica.

Los requerimientos de negocio son los primeros que se definen en un proyecto, a menudo se les puede encontrar escritos en sus documentos iniciales o en el acta de constitución del proyecto.

Suelen referir directamente a mejoras u objetivos de negocio específicos que quiere lograr la organización. También se les puede vincular indicadores de éxito en su propia definición.

Ejemplos de requerimientos de negocio

• Automatizar la gestión de relaciones con el cliente a objeto de reducir el tiempo de respuesta promedio en 70% en los próximos 6 meses.

• Optimizar la toma de pedidos del cliente a objeto de duplicar la cantidad de pedidos que se pueden procesar en un mes (aumentarla en 100%).

• Desarrollar un proceso automatizado para emitir y enviar por medios en línea directamente al ente regular un listado de transacciones de intercambio comercial, según nuevo requerimiento regulatorio. 

Los dos primeros ejemplos están relacionados con un indicador de éxito. Este se puede usar para medir el resultado y determinar si el requerimiento se ha cumplido o no.

¿Buscas formación para definir los requerimientos de software?

Más allá de las user stories: Fundamentos de requerimientos

Descubre el curso definitivo para llevar tus habilidades de requerimientos al siguiente nivel. 

Entra en el apasionante mundo de las historias de usuario y aprende los fundamentos esenciales para desarrollar requerimientos efectivos. 

No pierdas la oportunidad de potenciar tu carrera y ¡únete ya! 

Inscríbeme

2. Requisitos de los interesados

Fotografía por: Gabriel Benois.

En este contexto, interesado (Stakeholder) es toda parte que tenga un interés en el proyecto. Pueden estar representados las distintas áreas de negocio que utilizan un sistema, otras áreas de negocio de soporte, e inclusive agentes externos como clientes o proveedores. La gestión de los interesados es clave en la práctica de administración de proyectos.

Estos requisitos describen cuales son las necesidades de los interesados, para ayudarles a lograr los objetivos y requerimientos de sus áreas de negocio. También se les suele conocer como requerimientos de los usuarios. 

Pueden servir de puente para vincular los requerimientos del negocio con los de la solución.

Ejemplos de requerimientos de los interesados

• Necesitamos un mecanismo para monitorear diariamente los tiempos de respuesta sobre cada solicitud de soporte de clientes, con la finalidad de mejorar los tiempos de respuesta. Este reporte debería generarse de forma diaria, mensual o bajo demanda.

• Necesitamos un mecanismo que reciba los pedidos de los clientes por un medio en línea.

• Necesitamos que los pedidos de cliente recibidos en línea sean asignados automáticamente al analista que los procesará, según el tipo de cliente y área de la industria en el que este de desempeña. 

3. Requerimientos de la solución

Estos requerimientos describen las capacidades y funcionalidades que debe tener la solución para cumplir con los requerimientos de los interesados. Pueden describirse en mayor o menor grado de detalle según sean necesario para su desarrollo e implementación.

Los requerimientos de la solución se pueden dividir en dos subcategorías: Requerimientos funcionales y requerimientos no funcionales.

3.1. Requisitos funcionales

Los requerimientos funcionales describen las capacidades que una solución debe tener, expresadas en términos del comportamiento y la información que esta maneja.

Te recomendamos nuestro artículo sobre ¿Qué es un requerimiento funcional? Allí te contamos que son, cuál es su importancia, cómo se describen según si el enfoque del proyecto es predictivo o ágil, técnicas para el levantamiento y cómo se gestionan.

Ejemplos de requerimientos funcionales

• La solución enviará un correo electrónico cuando se registre un pedido de venta de cliente.

• Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos.

• El sistema permitirá elaborar y emitir el reporte regulatorio XX, según los requerimientos establecidos en el reglamento y ley aplicable. 

Visita nuestro artículo de ejemplos de requerimientos funcionales, donde te compartimos muchos más.

3.2. Requisitos no funcionales

Los requerimientos no funcionales describen las condiciones bajo las cuales la solución debe operar para mantenerse efectiva, así como los requisitos de calidad que debe cumplir. Por este motivo, a estos requisitos también se les conoce como requisitos de calidad de servicio.

No están relacionados directamente con el comportamiento o funcionalidad que debe exhibir la solución.

Para saber más sobre que son los requerimientos no funcionales, visita nuestro artículo requerimientos no funcionales: Porqué son importantes.

Los requisitos no funcionales se pueden también subdividir en categorías, como por ejemplo requisitos de usabilidad, eficiencia, seguridad, de entorno, operacionales, regulatorios, éticos y legislativos. Visita nuestro artículo sobre la clasificación de los requerimientos no funcionales, allí te compartimos más información.

Ejemplos de requerimientos no funcionales

• La solución debe poder manejar hasta 100.000 usuarios concurrentes sin degradación de desempeño.

• Los datos deben actualizarse en la base de datos para todos los usuarios en menos de 2 segundos.

• Todas las comunicaciones con sistemas externos deben encriptarse con el algoritmo RSA.

• La probabilidad de falla del Sistema no podrá ser mayor a 0,05. 

Visita nuestro artículo de ejemplos de ejemplos de requerimientos no funcionales. Allí te compartimos muchos más casos.

4. Requisitos de transición

Fotografía por: Christopher Gower.

Los requisitos de transición describen las capacidades y condiciones que debe cumplir la solución para facilitar la transición entre la situación actual y la nueva, pero que ya no serán necesarias una vez que sea culminado el cambio.

Se diferencian de los demás tipos de requerimientos en que son temporales. Los requerimientos de transición abarcan tópicos como las conversiones de datos, entrenamiento y continuidad del negocio.

Ejemplos de requerimientos de transición

• Los usuarios deben ser entrenados en los módulos del sistema que correspondan con su departamento o función.

• Se debe trasladar los datos históricos transaccionales de al menos 5 años, para poder emitir reportes comparativos en el nuevo sistema.

• La información registrada en la solución anterior podrá ser consultada durante los primeros dos años de operación de la nueva. Sólo para efectos de consulta de datos anteriores al inicio de operación. No se requerirá a los usuarios mantener actualizado el sistema anterior. 

El contenido de este artículo forma parte del Curso Online de Ingeniería de requisitos. Visita la página del curso. Identifica y analiza requisitos de software de manera integrada, para elaborar especificaciones de calidad.

Comienza a clasificar los requisitos en tus proyectos

En este artículo te hemos brindado las herramientas para clasificar los requerimientos en un contexto de análisis de negocio. Con ella, tendrás mayor conocimiento de que tipo de requisito debes documentar dependiendo de la fase del proyecto en la que te encuentres.

También, el esquema de clasificación que te hemos compartido es el establecido en La guía de conocimientos de análisis de negocio (BABOK) del International Institute of Business Analysis. Esta es la organización de mayor reconocimiento internacional en el campo de la gestión de requisitos.

Te invitamos a tomar acción, revisa las prácticas internas en tu organización para establecer qué tipo de requisitos debes documentar y cuando.

¿Existen prácticas estandarizadas de análisis de negocio en tu organización? ¿Sigues está clasificación cuando documentas requerimientos? Déjanos un comentario al final.

¿Buscas más información de gerencia informática?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos vía Twitter, Facebook o Linkedin:

  

Referencias

International Institute of Business Analysis. A Guide to the Business Analysis Body of Knowledge. 

Schedlbauer, M. The Quest For Good Requirements. Publicado en: BA Times. 

Srivastava, A. Types of Requirements | BABOK classification Schema. The BAWorld. 

Artículos relacionados