Técnicas de análisis de requisitos con ejemplo: tutorial completo

Como analista de negocios, el análisis de requisitos es la parte más importante de su trabajo. Va a ayudarle a determinar las necesidades reales de las partes interesadasAl mismo tiempo, le permite comunicarse con las partes interesadas en un lenguaje que comprendan (como gráficos, modelos, 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 de algún tipo para el cliente.

 

Técnicas de análisis de requisitos

Las técnicas de análisis de requisitos se utilizan principalmente para mapear el flujo de trabajo empresarial de modo que pueda analizar, comprender y realizar los cambios necesarios en ese flujo de trabajo o proceso.

Existen varias técnicas de análisis de requisitos que se pueden utilizar según el Desarrollo de software ad-hoc proceso como

1. Notación de modelado de procesos de negocio (BPMN)

BPMN (Business Process Modeling & Notation) es una representación gráfica de su proceso de negocio utilizando objetos simples, que ayuda a la organización a comunicarse de manera estándar. Varios objetos utilizados en BPMN incluyen

• Objetos de flujo
• Conectando objetos
• Swim lanes
• Artefactos.

Un modelo BPMN bien diseñado debería poder brindar detalles sobre las actividades realizadas durante el proceso como,

• ¿Quién realiza estas actividades?
• ¿Qué elementos de datos se requieren para estas actividades?

El mayor beneficio de usar BPMN es que es más fácil de compartir y la mayoría de las herramientas de modelado son compatibles con BPMN.

2. UML (lenguaje de modelado unificado)

UML es un estándar de modelado utilizado principalmente para la especificación, el desarrollo, la visualización y la documentación de sistemas de software. Para capturar procesos y artefactos comerciales importantes, UML proporciona objetos como

• Estado
• Objeto
• Actividad
• Diagrama de clase

Hay 14 diagramas UML que ayudan con el modelado, como el diagrama de casos de uso, el diagrama de interacción, el diagrama de clases, el diagrama de componentes, el diagrama de secuencia, etc. Los modelos UML son importantes en el segmento de TI, ya que se convierte en el medio de comunicación entre todas las partes interesadas. Un modelo de negocio basado en UML puede ser una entrada directa a una herramienta de requisitos. Un diagrama UML puede ser de dos tipos: modelo de comportamiento y modelo estructural. Un modelo de comportamiento intenta brindar información sobre lo que hace el sistema, mientras que un modelo estructural brindará en qué consiste el sistema.

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 o acciones relacionadas. Existen diferentes formatos para diagramas de flujo que incluyen lineal, de arriba hacia abajo y multifuncional (carriles de natación). Un diagrama de flujo se puede usar para diferentes actividades, como representar flujos de datos, interacciones del sistema, etc. La ventaja de usar el diagrama de flujo es que puede ser fácil de leer y escribir incluso para miembros del equipo sin conocimientos técnicos, y puede mostrar el proceso paralelo por función. , atributos críticos de un proceso, etc.

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 del diagrama de flujo de datos incluyen

• Proceso
• Flow
• Tienda
• Terminator

Un diagrama de flujo de datos lógico muestra las actividades del sistema, mientras que un diagrama de flujo de datos físico muestra la infraestructura de un sistema. Se puede diseñar un diagrama de flujo de datos al principio del proceso de obtención de requisitos de la fase de análisis dentro del SDLC (Ciclo de vida de desarrollo de sistemas) para definir el alcance del proyecto. Para facilitar el análisis, se puede profundizar en un diagrama de flujo de datos en sus subprocesos conocidos como "DFD nivelado".

5. Diagramas de actividades de roles (RAD)

El diagrama de actividad de roles es similar a la notación de tipo diagrama de flujo. En el diagrama de actividad de roles, las instancias de roles son participantes del proceso, que tiene un estado inicial y final. RAD requiere un conocimiento profundo del proceso u organización para identificar roles. Los componentes de RAD incluyen

• Actividades
• Eventos externos
• Estados

Los roles agrupan actividades en unidades de responsabilidad, según el conjunto de responsabilidades que desempeñan. Una actividad se puede llevar a cabo de forma aislada con un rol o puede requerir coordinación con actividades de otros roles.

Los eventos externos son los puntos en los que ocurren los cambios de estado.

Los estados son útiles para mapear las actividades de un rol a medida que avanza de un estado a otro. Cuando se alcanza un estado particular, indica que se ha logrado una determinada meta.

RAD es útil para respaldar la comunicación, ya que es fácil de leer y presenta una vista detallada del proceso y las actividades de permisos en paralelo.

6. Diagramas de Gantt

Un diagrama de Gantt es una representación gráfica de un cronograma que ayuda a coordinar, planificar y realizar un seguimiento de tareas específicas en un proyecto. Representa el lapso de tiempo total del objeto, desglosado en incrementos. Un diagrama de Gantt representa la lista de todas las tareas a realizar en el eje vertical mientras que, en el eje horizontal, enumera la duración estimada de la actividad o el nombre de la persona asignada a la actividad. Un gráfico puede demostrar muchas actividades.

7. IDEF (Definición integrada para modelado de funciones)

IDEF o Definición Integrada para Modelado de Funciones es un nombre común referido a clases de lenguajes de modelado empresarial. Se utiliza para modelar actividades necesarias para respaldar el análisis, diseño o integración del sistema. Hay alrededor de 16 métodos para IDEF, las versiones más útiles de IDEF son IDEF3 e IDEF0.

8. Redes de Petri de colores (CPN)

CPN o redes de Petri coloreadas son un lenguaje orientado gráficamente para especificación, verificación, diseño y simulación de sistemas. Las redes de Petri de colores son una combinación de gráficos y texto. Sus componentes principales son Lugares, transiciones y arcos.

Los objetos de las redes de Petri tienen una inscripción específica como para

• Lugares: Tiene inscripciones como .Nombre, .Conjunto de colores, .Marca inicial, etc.
• Transición : Tiene inscripciones como .Name (para identificación) y .Guard (la expresión booleana consta de algunas de las variables)
• Arcos: Tiene inscripción como .Arc. Cuando se evalúa la expresión del arco, se obtiene un conjunto múltiple de colores simbólicos.

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 aclarar la comprensión del proceso o para hacer recomendaciones de mejora del proceso. Al igual que otros diagramas como diagramas de flujo, actividad UML y mapa de procesos, la técnica del flujo de trabajo es la técnica más antigua y popular. BA incluso lo utiliza para tomar notas durante la obtenció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 un paradigma orientado a objetos y un lenguaje de modelado para diseñar un sistema. Hace hincapié en encontrar y describir el objeto en el dominio del problema. El propósito del método orientado a objetos es

• Para ayudar a caracterizar el sistema.
• Saber cuáles son los diferentes objetos relevantes
• Cómo se relacionan entre sí
• Cómo especificar o modelar un problema para crear un diseño efectivo
• Analizar los requisitos y sus implicaciones.

Este método es aplicable al sistema que tiene requisitos dinámicos (cambia con frecuencia). Es un proceso de derivar casos de uso, flujo de actividades y flujo de eventos para el sistema. El análisis orientado a objetos se puede realizar a través de necesidades textuales, comunicación con las partes interesadas del sistema y un documento de visión.

El objeto tiene un estado y los cambios de estado están representados por el comportamiento. Entonces, cuando el objeto recibe un mensaje, el estado cambia a través del 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 cualquier negocio y sus funcionalidades. Responde preguntas como ¿cuál es el estado actual del proyecto? ¿Donde queremos estar? etc. Varias etapas del análisis de brechas incluyen

• RevSistema de visualización
• Requisitos de desarrollo
• Comparación
• Implicaciones