El ‘Business Analysis’ es un conjunto de tareas y técnicas utilizadas para entender la estructura, políticas y operativa de una organización, identificar problemas, necesidades u oportunidades, y así poder recomendar y definir soluciones que permitan a la organización alcanzar sus objetivos.

El ‘Business Analysis’ implica comprender cómo funcionan las organizaciones a fin de lograr sus propósitos, y definir las capacidades que dicha organización requiere para proveer productos y servicios hacia el exterior (clientes, accionistas, etc). Esta comprensión nos lleva no sólo a determinar los objetivos que se deben alcanzar, sino a establecer el camino que debe acometer esa organización para alcanzar dichos objetivos, definiendo cómo las distintas unidades organizativas y otros interesados (de dentro o de fuera de la organziación) interactúan.

De esta manera, el ‘Business analysis’ casa con la idea de conseguir correctamente los requisitos de la solución y con que esos requisitos sean los correctos.

Definición

Existen múltiples definiciones de lo que es un requisito:

Una condición o capacidad requerida por un interesado para resolver un problema o alcanzar un objetivo (IEEE 610.12-1990).
Una declaración de una necesid u objetivo, o una condición o capacidad que un producto debe poseer para satisfacer tal necesidad u objetivo (“Software Requirements,” by Karl Wiegers).
Algo que el producto debe de hacer o una cualidad que debe de poseer (“Mastering the Requirements Process,” by Suzanne & James Robertson)

Resumiendo: una capacidad que un producto o solución debe de poseer o algo que un producto o solución debe de hacer a fin de satisfacer una necesidad.

Clasificación

Los requerimientos podemos clasificarlos en distintos tipos:

Business Requirements: son las declaraciones de más alto nivel referentes a las metas, objetivos o necesidades de la empresa. Describen las necesidades de la organización en su conjunto y no las particulares de los grupos o partes interesadas de la misma. Indican algunos de los beneficios que la organización o sus clientes esperan recibir al emprender el proyecto.
User/Stakeholder Requirements: son declaraciones de las necesidades de una parte interesada concreta o de un grupo de partes interesadas de la organización. Describen QUÉ se necesita de la solución final. A menudo referidas como necesidades del usuario o requisitos del usuario, describen lo que los usuarios deben poder hacer con el sistema (qué tareas deben poder realizar).
Solution (System) Requirements: describen las características de una solución que cumpla con los ‘business requirements’ y los ‘user requirements’. Describen CÓMO se cumplirá con los ‘user requirements’ (ojo, de manera lógica, sin detalles de la implementación). Son el tipo de requerimiento que los desarrolladores utilizan para construir el sistema. Estas son las declaraciones tradicionales de "shall" que describen lo que el sistema "hará". Los podmos subdividir en:
1. Functional Requirements: describen el comportamiento de la solución y la información que gestionará a fin de satisfacer los ‘ser requirements’. Describen las capacidades que el sistema podrá realizar en términos de comportamientos u operaciones -acciones o respuestas específicas-. En definitiva, describen las características de todos los datos y todos los procesos, incluido cómo deben ser los datos, cómo deben realizarse los procesos, los comportamientos de la pantalla, los formatos de informes, etc.
2. Non-functional Requirements: capturan las condiciones que no se relacionan directamente con el comportamiento o la funcionalidad de la solución, sino que describen las cualidades que debe tener la solución y condiciones ambientales bajo las cuales la solución debe permanecer efectiva. Éstos pueden incluir requisitos relacionados con la disponibilidad, velocidad, seguridad, usabilidad o escalabiliad, entre otros.
Transition Requirements: describen las capacidades que la solución debe tener para facilitar la transición del estado actual al estado futuro deseado, pero que no se necesitarán una vez que se complete la transición. Se diferencian de otros tipos de requisitos porque siempre son de carácter temporal y porque no pueden desarrollarse hasta que tanto la solución existente como la nueva estén definidas (ponen énfasis en los procesos de gestión del cambio).

La pirámide

Podemos, tras lo comentado en el punto anterior, estabelcer una pirámide de requerimientos que exprese cómo se asientan o acoplan los diferentes tipos de requerimeintos expresados, desde una visión más orientada a negocio hasta una visión más orietada a la solución de software final.

Esta pirámide nos da una idea de cómo debemos ir profundizando, desde las capa más externa o punto más elevado de la pirámide hasta la más interna (la base de la pirámide), para ir recolectando y desgranando los requerimientos.

A la pregunta que quizás te estés haciendo de si realmente debes arrancar desde lo alto de la pirámide hasta llegar a su base, te respondería que, como dicen los ingleses, "it’s up to you", pero es el flujo lógico de trabajo del ‘business analysis’ y, por ende, la forma lógica de obtener los mejores resultados en tus proyectos de software.

Un ejemplo

Vamos a elaborar un ejemplo muy básico para observar el modo en que engranan los distintos tipos de requerimientos:

Business requirement: Como galerista de arte quiero que mis clientes puedan ver las obras de arte para reducir el tiempo que pasan en la galería, así como su número de visitas
- User requirement: El sistema permitirá crear fichas de obras de arte. Functional requirements:
  - El galerista cumlimentará los datos de nombre de la obra, estilo y año de cración
  - El galerista vinculará una imagen del repositorio de imágenes a la ficha de la obra
  - El galerista asignará un autor a la obra
  - El sistema no guardará una ficha de una obra de arte si no se han registrado los datos de nombre, estilo, imagen y artista
  - El sistema marcará las fichas de de obras de arte recién creadas como ‘nueva’
  - El galerista podrá marcar como ‘publicable’ una ficha de obra de arte que se encuentre en estado ‘nueva’
- User requirement: El sistema permitirá crear fichas de artistas. Functional requirements:
  - El galerista cumlimentará los datos de nombre, apellido y fecha de nacimiento de la nueva ficha del artista
  - El galerista introducirá la información del CV del artista de la nueva ficha de artista
  - El sistema no guardará la nueva ficha de artista si no se han registrado los datos de apellido, lugar de nacimiento y fecha de nacimiento
- User requirement: El sistema publicará las nuevas fichas de las obras automáticamente. Functional requirements:
  - El sistema revisará las obras de arte pendientes de publicarse cada 60 minutos
  - El sistema publicará nuevas obras de arte sólo cuando dicha obra esté marcada como ‘publicable’
- User requirement: El sistema permitirá consultar el catálogo de obras de arte. Functional requirements:
  - El sistema mostrará las obras de arte ordendas por nombre de la obra
  - El cliente podrá filtrar las obras de arte según estilo o autor, pero no ambos
  - El cliente seleccionará la obra de arte a conslutar del catálogo que se le muestra
  - El sistema abrirá la ficha de la obra de arte cuando el cliente seleccione la obra
Non-Functional Requirements:
- El sistema debe permiir hasta 200 usuarios y clientes concurrentes
- El sistema debe cargar una ficha de obra de arte en menos de 0,5s
- El sistema no permitirá crear fichas a usuarios no identificados
- El sistema deberá tardar un máximo de 10 minutos para la recuperación de un fallo de caída total en el 95% de las ocasiones
- El sistema deberá consumir la información de los sistemas fuente mediante una API de servicios REST
- El sistema deberá ser compatible con los navegadores Internet Explorer 8, Safari 4 y Mozilla Firefox 3.5
- La web de la galería debe visualizarse correctamente en una tableta, teléfono móvil, portátil u ordenador de sobremesa

Si te preguntas por qué en el caso de los business, user y functional requirements he realizado un desarrollo en forma arborescente ‘top-down’ y los non-functional los he puesto a parte, la respuesta es que habitualmente los ‘non-functional requirements’ afectan a toda la solución, es decir, no suelen emanar de un ‘functional requirements’.

La idea es ir tirando del hilo de cada ‘business requirement’ generando sus ‘user requirements’ y, desde éstos, sus ‘functional requirements’.

Si te preguntas por qué la forma de expresar un ‘business requirement’ no es la misma que la de un ‘user requirement’, te aconsejo que leas este artículo.

Si quieres saber más sobre la disciplina del ‘business analysis’ y los requerimientos, no dudes en consultar el Business Analysis Book of Knowledge.