Técnicas de análisis de requisitos con ejemplo
⚡ Resumen inteligente
Las técnicas de análisis de requisitos ayudan a los analistas de negocio a modelar flujos de trabajo, comunicarse con las partes interesadas y traducir las necesidades empresariales en especificaciones estructuradas utilizando BPMN, UML, diagramas de flujo, diagramas de flujo de datos, IDEF, redes de Petri y análisis de brechas.
Como analista de negocios, el análisis de requisitos es la parte más importante de tu trabajo. te ayuda a determinar las necesidades reales de las partes interesadas.También permite comunicarse con las partes interesadas mediante gráficos, modelos y diagramas de flujo en lugar de texto complejo.
Un análisis de requisitos tiene un
- Objetivo específico
- Entrada específica
- Salida específica
- Utiliza recursos
- Tiene una serie de actividades para realizar en algún orden.
- Puede afectar a más de una unidad organizativa.
- Crea valor para el cliente.
Técnicas de análisis de requisitos
Las técnicas de análisis de requisitos permiten trazar un mapa del flujo de trabajo empresarial para que puedas analizarlo, comprenderlo y mejorarlo.
Las siguientes técnicas se utilizan en toda la Desarrollo de software ad-hoc .
1. Notación de modelado de procesos de negocio (BPMN)
BPMN (Business Process Model and Notation) es una representación gráfica de un proceso de negocio mediante objetos sencillos, que ayuda a la organización a comunicarse de forma estandarizada. Los principales objetos utilizados en BPMN son:
- Objetos de flujo
- Conectando objetos
- Swim lanes
- Artefactos.
Un modelo BPMN bien diseñado proporciona detalles sobre las actividades realizadas durante el proceso, tales como:
- ¿Quién realiza estas actividades?
- ¿Qué elementos de datos se requieren para estas actividades?
La mayor ventaja de BPMN es que los diagramas son fáciles de compartir y la mayoría de las herramientas de modelado admiten esta notación.
2. UML (lenguaje de modelado unificado)
UML es un estándar de modelado para especificar, desarrollarping, visualizando y documentando sistemas de software. UML proporciona objetos como:
- Estado
- Objeto
- Actividad
- Diagrama de clase
Existen 14 tipos de diagramas UML, incluyendo diagramas de casos de uso, interacción, clases, componentes y secuencias. Los modelos UML sirven como medio de comunicación entre todos los interesados. Un modelo de negocio basado en UML puede ser una entrada directa para una herramienta de requisitos. Un diagrama UML puede ser conductual o estructural. Un modelo conductual describe el funcionamiento del sistema; un modelo estructural muestra su composición.
3. Técnica de diagrama de flujo
Un diagrama de flujo es una representación visual del flujo secuencial y la lógica de control de un conjunto de actividades relacionadas. Los formatos comunes de diagramas de flujo incluyen el lineal, el descendente y el multifuncional (carriles). Un diagrama de flujo se puede utilizar para representar flujos de datos, interacciones del sistema y pasos de un proceso. Los diagramas de flujo son fáciles de leer y escribir, incluso para personas sin conocimientos técnicos, y pueden mostrar procesos paralelos y atributos críticos.
4. Diagrama de flujo de datos
Los diagramas de flujo de datos muestran cómo un sistema procesa los datos en términos de entradas y salidas. Los componentes de un diagrama de flujo de datos son:
- Proceso
- Flow
- Tienda
- Terminator
Un DFD lógico muestra las actividades; un DFD físico muestra la infraestructura. Un DFD se puede diseñar al principio de la fase de análisis del SDLC (Ciclo de vida de desarrollo de sistemas) para definir el alcance del proyecto. Se puede desglosar en subprocesos, lo que se conoce como un “DFD nivelado”.
5. Diagramas de actividades de roles (RAD)
Un diagrama de actividad de roles (RAD) es similar a la notación de diagramas de flujo. Las instancias de rol son participantes del proceso, cada uno con un estado inicial y final. El RAD requiere un conocimiento profundo del proceso o la organización para identificar los roles. Los componentes del RAD son:
- Actividades
- Eventos externos
- Estados
Los roles agrupan las actividades en unidades de responsabilidad. Una actividad puede realizarse de forma aislada o requerir coordinación con actividades de otros roles.
Los eventos externos marcan los puntos donde se producen cambios de estado.
Los estados describen cómo progresa un rol a lo largo del proceso. Alcanzar un estado indica que se ha logrado un objetivo específico.
RAD es fácil de leer, presenta una vista detallada del proceso y muestra actividades paralelas.
6. Diagramas de Gantt
Un diagrama de Gantt es una representación gráfica de un cronograma que ayuda a coordinar, planificar y track tareas específicas en un proyecto. Muestra la duración total del proyecto, dividida en incrementos. El eje vertical enumera las tareas; el eje horizontal muestra la duración estimada de la actividad o el responsable asignado. Un solo gráfico puede mostrar varias actividades.
7. IDEF (Definición integrada para modelado de funciones)
IDEF (Integrated Definition for Function Modeling) abarca una familia de lenguajes de modelado empresarial. Modela las actividades que dan soporte al análisis, diseño o integración de sistemas. Existen aproximadamente 16 métodos IDEF; IDEF0 e IDEF3 son los más útiles.
8. Redes de Petri de colores (CPN)
Las redes de Petri coloreadas (CPN) son un lenguaje orientado gráficamente para las redes de Petri coloreadas. especificación, verificación, diseño y simulación de sistemas. CPN combina gráficos y texto. Sus componentes principales son: Lugares, transiciones y arcos.
Los objetos de la red de Petri tienen inscripciones específicas, por ejemplo:
- Lugares: Tiene inscripciones como .Nombre, .Conjunto de colores y .Marcación inicial.
- Transición : Tiene inscripciones como .Name (para identificación) y .Guard (una expresión booleana sobre algunas de las variables).
- Arcos: Tiene una inscripción .Arc. Cuando se evalúa la expresión arc, produce un conjunto múltiple de colores de token.
9. Técnica de flujo de trabajo
La técnica de flujo de trabajo es un diagrama visual que representa uno o más procesos de negocio para clarificar la comprensión o para formular recomendaciones de mejora de procesos. Junto con los diagramas de flujo, los diagramas de actividad UML y los mapas de procesos, la técnica de flujo de trabajo es uno de los enfoques más antiguos y ampliamente utilizados. Los analistas de negocio también la utilizan para tomar notas durante la recopilación de requisitos. El proceso consta de cuatro etapas:
- Recopilación de información
- Modelado de flujo de trabajo
- Modelado de procesos de negocio
- Implementación, Verificación y Ejecución
10. Métodos orientados a objetos
El método de modelado orientado a objetos utiliza el paradigma y el lenguaje de modelado orientados a objetos para diseñar un sistema. Hace hincapié en la búsqueda y descripción de los objetos en el dominio del problema. El propósito del método orientado a objetos es:
- Para ayudar a caracterizar el sistema
- Para identificar los diferentes objetos relevantes
- Para comprender cómo se relacionan los objetos entre sí.
- Especificar o modelar un problema para crear un diseño eficaz.
- Analizar los requisitos y sus implicaciones.
Este método es idóneo para sistemas con requisitos dinámicos que cambian con frecuencia. Consiste en derivar casos de uso, flujos de actividad y flujos de eventos para el sistema. El análisis orientado a objetos puede basarse en las necesidades textuales, la comunicación con las partes interesadas del sistema y un documento de visión.
Un objeto tiene un estado, y los cambios de estado se representan mediante un comportamiento. Cuando el objeto recibe un mensaje, su estado cambia a través de dicho comportamiento.
11. Análisis de brechas
El análisis de brechas es la técnica utilizada para determinar la diferencia entre el estado propuesto y el estado actual de una empresa y sus funciones. Responde a preguntas como: ¿Cuál es el estado actual del proyecto? ¿Dónde queremos estar? ¿Cómo cerramos la brecha? Las etapas del análisis de brechas incluyen:
- RevSistema de visualización
- Requisitos de desarrollo
- Comparación
- Implicaciones
- Recommendations










