Please enable JavaScript.
Coggle requires JavaScript to display documents.
Análisis y Especificación de requisitos - Coggle Diagram
Análisis y Especificación de requisitos
Técnicas de análisis de requisitos
El análisis de requisitos define
lo que el sistema debe hacer, pero no el cómo
, plasmado en un documento y sintetizando las necesidades de los usuarios.
Algunas técnicas que pueden ser utilizadas:
Priorización de requisitos
Identificar cuáles requisitos se deben priorizar tomando en cuenta factores como la complejidad, las dependencias y el retorno de inversión a los clientes, entre otros indicadores.
La prioridad y los requisitos pueden variar continuamente durante el proyecto.
Técnica de clasificación de lista
Es una de las más utilizadas y consiste en darle un valor numérico a cada requerimiento iniciando por el número 1 y continuando de forma sucesiva con 2, 3 y hasta el número total de requisitos definidos
Esta técnica asegura un único número 1, evita conflictos, aporta claridad y simplifica la priorización.
Se necesita conocer bien los requerimientos y un gran esfuerzo del equipo para posicionarlos correctamente.
Técnica de puntos de historia y valor del negocio
Se prioriza considerando factores como esfuerzo, opinión de los gerentes, clientes y equipo. El valor del negocio se asigna numéricamente, representando más valor cuanto más alto sea
Priorizar solo por el valor del negocio puede ser problemático. Se usan puntos de historia para considerar el esfuerzo del equipo.
Para priorizar, se calcula el cociente de valor del negocio entre puntos de historia. Los más simples y con mayor interés del cliente tienen prioridad. Ejemplo:
7 more items...
Técnica urgente
Se usa una tabla de dos dimensiones: la urgencia del requerimiento en la horizontal (valor de 1 a 5, donde 5 es la máxima urgencia) y el valor del negocio en la vertical (también de 1 a 5, siendo 5 el máximo).
Para determinar la prioridad final de un requerimiento, se utiliza una escala de colores que surge a partir de la multiplicación de los valores de las escalas de urgencia y de valor de negocio
1 more item...
Técnica MoSCoW
Esta técnica se basa en la asignación de etiquetas a cada requerimiento, y las disponibles se relacionan a continuación:
Los requerimientos son priorizados utilizando el siguiente orden: primero los que tienen etiqueta M, luego los requerimientos con etiqueta S, después aquellos con C y, finalmente, los etiquetados como W.
5 more items...
Juicio de expertos
Básicamente consiste en realizar el proceso de priorización utilizando como base la opinión del gerente de proyecto o dueño de producto, o de algún stakeholder con conocimientos en la industria asociada al producto a desarrollar
Se debe utilizar esta técnica con cuidado ya que se basa en una visión sesgada del negocio.
Matriz de priorización
Esta técnica consiste en construir una tabla donde cada requerimiento es valorado en una escala de 0 a 10 o de 0 a 100 para cada dimensión alineada con los objetivos del producto. Normalmente cada dimensión tiene un peso porcentual, de modo que cada requerimiento tendrá un valor final a partir de la sumatoria de la multiplicación de cada puntuación por el peso de cada dimensión
Esta técnica sigue siendo muy subjetiva al igual que la técnica de juicio de expertos
Matriz de trazabilidad
La matriz de trazabilidad alinea los requisitos del proyecto con los objetivos, relacionando cada requisito con los entregables. Identifica qué resultado se logra con cada requisito y qué requisitos son necesarios para un entregable.
Es clave en seguimiento y control de cambios. Permite ajustar requerimientos, ver inconsistencias, y visualizar el progreso y entregables pendientes.
La estructura de la matriz de trazabilidad se puede construir en una hoja de cálculo, en ella se relacionan todos los requisitos y las metas a alcanzar junto con una serie de valores complementarios que aportan información y coherencia a los vínculos generados.
Al construir una matriz de trazabilidad se deben usar los campos que se consideren útiles para el proyecto, pues no todos los proyectos son iguales y la estructura definida para uno puede no resultar conveniente para otro proyecto. Cuando se usa, esta matriz debe permanecer actualizada a lo largo del ciclo de vida de construcción del proyecto.
Descomposición funcional
Esta estrategia define requerimientos como entradas y salidas del sistema. Se desglosan en funcionalidades detalladas, conocido como enfoque top-down, hasta alcanzar una estructura jerárquica.
Los requerimientos se definen de forma general y luego se desglosan en funcionalidades detalladas para alcanzar el nivel adecuado de detalle.
La descomposición funcional se realiza, por lo general, para identificar y entender los componentes o partes que constituyen un todo; en este proceso es vital identificar las interacciones entre componentes.
Especificación de requisitos
Algunos estándares y/o técnicas que pueden ser usadas por las organizaciones para describir formalmente cada uno de los requisitos del sistema.
Estándar IEEE 29148:2018
Este estándar reemplaza los estándares IEEE 830, IEE 1233, IEEE 1362, y contiene disposiciones para los procesos y productos relacionados con la ingeniería de requisitos para sistemas, productos y servicios de software a lo largo del ciclo de vida
El estándar IEEE 29148:2018 está estructurado de la siguiente forma:
Introducción, resumen y tabla de contenido.
Propósito, alcance del estándar, generalidades.
Explicación de los otros estándares que lo conforman.
Referencias a normas que lo conforman.
Clarificación de la terminología, lo que es muy valioso para cuando se quiere establecer nuevos procesos de ingeniería de requerimientos en una empresa.
Clarificación de los conceptos y procesos.
Explicación y contenido de los ítems de información que vienen a través de la especificación de requerimientos o que debemos considerar incluir en la especificación de requerimientos.
Anexos adicionales para mayor detalle.
Esta norma propone un listado de requerimientos mínimos los cuales son la base de la especificación de requerimientos; en ese sentido se proponen los siguientes tipos de requerimientos del sistema:
Requerimientos funcionales: representan necesidades de los interesados del software.
Requerimientos de usabilidad: requerimientos que son utilizados directamente por los involucrados en la solución (requerimientos de uso).
Requerimientos de desempeño: disponibilidad de servicios y procesos transaccionales.
Interfaces del sistema: interacción entre personas con el software.
Operaciones del sistema.
Modos y estados del sistema.
Características físicas (hardware).
Condiciones del ambiente (operativas y operacionales).
Seguridad del sistema.
Manejo de la información.
Políticas y regulación: normas y estándares que fundamenta el software.
Ciclo de vida del sistema: establece las etapas y duración del desarrollo y uso en producción.
La especificación de requisitos a través de marcos de trabajo ágiles
Los marcos ágiles priorizan la comunicación oral sobre la documentación extensa. Las historias de usuario son un artefacto común para los requerimientos.
Las historias de usuario describen funciones del software desde la perspectiva del usuario. Permiten definir requerimientos, prioridades y estimar tiempos.
Las historias de usuario tienen varios beneficios respecto a otros instrumentos de redacción de requerimientos, entre los cuales se pueden listar:
Se centran en solucionar problemas a usuarios reales.
Permiten la colaboración, ya que como su descripción es corta se necesita que el equipo colabore para decidir cómo dar solución a la historia para cumplir con la necesidad expresada por el usuario.
Impulsan la creatividad, ya que fomentan que el equipo piense de forma crítica y creativa sobre cómo solucionar de la mejor manera el objetivo.
Motivan, pensar en la mejor solución para una problemática particular representan retos y pequeñas victorias para el equipo.
Scrum y la especificación de requisitos
El marco de trabajo Scrum está soportado en un proceso de construcción iterativo e incremental evolutivo.
En el que se identifican tres roles principales:
El equipo de trabajo (team)
Conformado por los desarrolladores, diseñadores, personal de calidad y de infraestructura requerido para la construcción del producto de software
el scrum master
que realizan funciones parecidas a las de un director de proyecto, pero más enfocados en garantizar que el equipo de trabajo tenga todas las herramientas y recursos necesarios para el desarrollo de su trabajo
el dueño del producto (product owner)
que se convierte en un representante del cliente y quien es el único encargado de la gestión de requisitos del proyecto
Scrum establece el concepto de sprint para referirse a una iteración que contempla tiempos fijos entre 2 y 4 semanas dependiendo del equipo de trabajo
durante este tiempo se incluye:
la planeación del sprint, donde se definen los requerimientos a desarrollar en ese periodo de tiempo
una fase de construcción del producto
un proceso de despliegue para poder hacer la respectiva demostración de lo construido al final de iteración en reuniones de revisión
Kanban y la especificación de requisitos
Kanban surge del sistema Toyota Production System (TPS) en los años 40, basado en la demanda del cliente y minimizando desperdicios para crear más valor.
Kanban en la industria del software se basa en cuatro principios fundamentales:
1- Calidad garantizada, todo lo que se produce debe salir bien sin márgenes de errores, prima la calidad sobre la rapidez.
2- Reducción del desperdicio. Hacer solamente lo justo y necesario, pero hacerlo bien.
3- Mejora continua.
4- Flexibilidad: se pueden priorizar tareas entrantes según las necesidades del momento.
Además de los principios, Kanban propone seis (6) prácticas:
1- Visualizar el flujo de trabajo.
2- Eliminar interrupciones.
3- Gestionar el flujo.
4- Hacer políticas explícitas que fomenten la visibilidad.
5- Circuitos de realimentación.
6- Mejorar colaborando.
El tablero Kanban permite mapear y visualizar el flujo de trabajo. Este se divide en columnas a través de las cuales se pueden visualizar cada una de las fases del proceso; las filas del tablero representan los diferentes tipos de actividades específicas que se desarrollan en el marco del proyecto.
Normalmente el tablero tiene tres secciones que representan el estado de cada una de las tareas: por hacer, en proceso, hecho.
Estándar IEEE 830
Conjunto de prácticas recomendadas para la
redacción de un documento de especificación
de requerimientos mejor conocido como SRS.
Secciones del documento
1- Introducción
Propósito
Ámbito del sistema
Definiciones, acrónimos y abreviaturas
Referencias
2- Descripción
Factores generales que afectan al producto y sus requerimientos
Perspectiva del producto
Funciones del producto
Características de los usuarios
Restricciones generales
Suposiciones y dependencias
3- Especificación
de requerimientos
Requerimientos base para guiar los procesos de diseño, implementación y pruebas del software.
Cada requerimiento descrito en esta sección debe cumplir con los siguientes criterios de calidad.
Corrección
Rastreable
No ambiguo
Verificable
Priorizado
Se subdivide para presentar primero los requerimientos funcionales y luego los no funcionales.
4- Modelo de Análisis
Se usan en el desarrollo específico de los requerimientos listados en la sección anterior con introducción y descripción narrativa.
Diagrama de secuencia
Diagrama de flujo de datos
Diagrama de transición de estados
5- Identificar y describir
Quién puede enviar cambios, por cuáles medios y cómo pueden ser aprobados estos cambios.
La siguiente tabla muestra la estructura base de un documento SRS, indicando cuáles son los apartados principales.
1 Introducción
1.1 Propósito
1.2 Ámbito del sistema
1.3 Definiciones, Acrónimos y Abreviaturas
1.4 Referencias
2 Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características de los usuarios
2.4 Restricciones
2.5 Suposiciones y dependencias
3 Requerimientos específicos
3.1 Interfaz
3.2 Requisitos funcionales
3.3 Requerimientos no funcionales
3.4 Otros requisitos
4 Apéndices
Algunos ejemplos que se presentan sobre el diligenciamiento del formato SRS:
Sistema Integral Académico
Link del documento
Sistema de Información de Seminarios Web
Link del documento
Sistema de Estacionamiento Tarifado
Link del documento