Planificación de buenos requisitos
Entonces, ¿qué hace que sea un buen requisito? Un buen requisito debe ser valioso y factible; debe definir una necesidad y proporcionar un camino hacia una solución. Todos en el equipo deben entender lo que significa. Los requisitos varían en complejidad.
Un buen documento de requisitos puede formar parte de un grupo con requisitos de alto nivel desglosados en subrequisitos.
También pueden incluir especificaciones muy detalladas que incluyen un conjunto de requisitos funcionales que describen el comportamiento o los componentes del producto final.
Los buenos requisitos deben ser concisos y específicos, y deben responder a la pregunta "¿qué necesitamos?" En lugar de "¿cómo satisfacemos una necesidad?"
Los buenos requisitos garantizan que todas las partes interesadas comprendan su parte del plan; Si las piezas no están claras o se malinterpretan, el producto final podría ser defectuoso o fallar.
Se puede ayudar a prevenir fallas o malas interpretaciones de los requisitos recibiendo comentarios del equipo continuamente durante todo el proceso a medida que evolucionan los requisitos. La colaboración continua y la aceptación de todos es la clave del éxito.
Recopilación y análisis de requisitos
Un requisito es una condición o capacidad que necesita un interesado para resolver un problema o lograr un objetivo organizacional; una condición o capacidad que debe cumplir o poseer un sistema.
El análisis de requisitos en la ingeniería de software cubre aquellas tareas que entran en la determinación de las necesidades o condiciones a cumplir para un producto nuevo o alterado teniendo en cuenta los posibles requisitos conflictivos de varias partes interesadas, analizando, documentando, validando y gestionando los requisitos de software o sistema.
Los requisitos deben ser:
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Los requisitos deben estar relacionados con las necesidades u oportunidades comerciales identificadas y definidas con un nivel de detalle suficiente para el diseño del sistema.
Un analista de negocios recopila información a través de la observación de los sistemas existentes, el estudio de los procedimientos existentes, las discusiones con los clientes y los usuarios finales. El analista también debe tener habilidades imaginativas y creativas en ausencia de un Sistema de trabajo. Analizar el requisito recopilado para encontrar los enlaces faltantes es un análisis de requisitos.
Enfoque de obtención
Para obtener los objetivos, pregunte al experto en negocios, al gerente de desarrollo y al patrocinador del proyecto las siguientes preguntas:
¿Qué objetivos comerciales de la empresa ayudará a lograr este proyecto?
¿Por qué estamos haciendo este proyecto ahora?
¿Qué pasará si lo hacemos más tarde?
¿Y si no lo hacemos en absoluto?
¿Quiénes se beneficiarán de este proyecto?
¿Las personas que se beneficiarán de él lo consideran la mejora más importante que posiblemente se pueda realizar en este momento?
¿Deberíamos estar haciendo un proyecto diferente en su lugar?
Los posibles objetivos pueden ser reducir costos, mejorar el servicio al cliente, simplificar el flujo de trabajo, reemplazar tecnología obsoleta, probar una nueva tecnología y muchos otros. Además, asegúrese de comprender exactamente cómo el proyecto propuesto ayudará a lograr el objetivo establecido.
Diferentes tipos de requisitos
Los tipos más comunes de requisitos que interesan a un analista de negocios serían los siguientes:
Requisitos comerciales
Los requisitos comerciales son las actividades críticas de una empresa que deben realizarse para cumplir con los objetivos organizacionales sin dejar de ser independiente de la solución. Un documento de requisitos comerciales (BRD) detalla la solución comercial para un proyecto, incluida la documentación de las necesidades y expectativas del cliente.
Requisitos de usuario
Los requisitos del usuario deben especificar los requisitos específicos que el usuario espera / desea que el software se construya a partir del proyecto de software. Un requisito del usuario debe ser verificable, claro y conciso, completo, coherente, rastreable y viable.
El documento de requisitos del usuario (URD) o la especificación de requisitos del usuario es un documento que se utiliza normalmente en la ingeniería de software y que especifica lo que el usuario espera que el software pueda hacer.
Requisitos del sistema
Los requisitos del sistema tratan de definir los requisitos de recursos de software y los requisitos previos que deben instalarse en una computadora para proporcionar un funcionamiento óptimo de una aplicación.
Requerimientos funcionales
Los requisitos funcionales capturan y especifican el comportamiento previsto específico del sistema que se está desarrollando. Definen cosas como cálculos del sistema, manipulación y procesamiento de datos, interfaz de usuario e interacción con la aplicación, y otras funciones específicas que muestran cómo se satisfacen los requisitos del usuario. Asigne un número de identificación único a cada requisito.
Requerimientos no funcionales
El requisito no funcional es el que especifica criterios que se pueden utilizar para juzgar el funcionamiento de un sistema en lugar de comportamientos específicos. La arquitectura del sistema habla sobre el plan para implementar requisitos no funcionales.
Los requisitos no funcionales hablan de cómo debería verse el sistema o se puede mencionar como "el sistema será". Los requisitos no funcionales se denominan cualidades del sistema.
Requisitos de transición
Los requisitos de transición describen las capacidades que la solución debe cumplir para facilitar la transición del estado actual de la empresa a un estado futuro deseado, pero que no serán necesarias una vez que se complete la transición.
Se diferencian de otros tipos de requisitos porque siempre son de naturaleza temporal y porque no pueden desarrollarse hasta que se defina una solución nueva y una existente. Por lo general, cubren la conversión de datos de los sistemas existentes, las brechas de habilidades que deben abordarse y otros cambios relacionados para alcanzar el estado futuro deseado. Se desarrollan y definen a través de la evaluación y validación de soluciones.
Gestión de la trazabilidad y cambios
La trazabilidad de requisitos es una forma de organizar, documentar y realizar un seguimiento de todos sus requisitos desde la generación de la idea inicial hasta la fase de prueba.
La matriz de capacidad de seguimiento de requisitos (RTM) proporciona un método para realizar un seguimiento de los requisitos funcionales y su implementación a través del proceso de desarrollo. Cada requisito se incluye en la matriz junto con su número de sección asociado.
A medida que avanza el proyecto, el RIM se actualiza para reflejar el estado de cada requisito. Cuando el producto está listo para la prueba del sistema, la matriz enumera cada requisito, qué componente del producto lo aborda y qué prueba verifica que se haya implementado correctamente.
Incluya columnas para cada uno de los siguientes en el RTM:
- Descripción del requisito
- Referencia de requisitos en FRD
- Método de verificación
- Referencia de requisitos en el plan de prueba
Example- Conectando los puntos para identificar las relaciones entre elementos dentro de su proyecto. Es un conector de flujo descendente común.
Requisitos de la idea Prueba de diseño Objetivos comerciales
Debería poder rastrear cada uno de sus requisitos hasta su objetivo comercial original.
Al rastrear los requisitos, puede identificar el efecto dominó que tienen los cambios, ver si se ha completado un requisito y si se está probando correctamente. La trazabilidad y la gestión de cambios proporcionan a los gerentes la tranquilidad y la visibilidad necesaria para anticipar problemas y garantizar una calidad continua.
Seguro de calidad
Obtener los requisitos correctamente a la primera puede significar una mejor calidad, ciclos de desarrollo más rápidos y una mayor satisfacción del cliente con el producto. La gestión de requisitos no solo lo ayuda a hacerlo bien, sino que también ayuda a su equipo a ahorrar dinero y muchos dolores de cabeza durante el proceso de desarrollo.
Los requisitos concisos y específicos pueden ayudarlo a detectar y solucionar problemas temprano, en lugar de más tarde, cuando es mucho más costoso solucionarlos. Además, puede costar hasta100 times más para corregir un defecto más adelante en el proceso de desarrollo después de que se haya codificado, que para corregirlo en una etapa temprana mientras sea un requisito.
Al integrar la gestión de requisitos en su proceso de garantía de calidad, puede ayudar a su equipo a aumentar la eficiencia y eliminar la repetición. Además, el reproceso es donde ocurren la mayoría de los problemas de costos.
En otras palabras, los equipos de desarrollo están desperdiciando la mayor parte de sus presupuestos en esfuerzos que no se realizan correctamente la primera vez. Por ejemplo, un desarrollador codifica una función basándose en un documento de especificación antiguo, solo para saber más tarde que los requisitos de esa función cambiaron. Este tipo de problemas se pueden evitar con las mejores prácticas de gestión de requisitos eficaces.
En resumen, la gestión de requisitos puede parecer una disciplina compleja, pero cuando se reduce a un concepto simple, se trata de ayudar a los equipos a responder la pregunta: "¿Todos comprenden lo que estamos construyendo y por qué?" Desde los analistas de negocios, gerentes de productos y líderes de proyectos hasta los desarrolladores, gerentes de control de calidad y evaluadores, junto con las partes interesadas y los clientes involucrados, a menudo la causa raíz del fracaso del proyecto es una mala comprensión del alcance del proyecto.
Cuando todos colaboran y tienen un contexto y una visibilidad completos de las discusiones, decisiones y cambios relacionados con los requisitos a lo largo del ciclo de vida del proyecto, es entonces cuando el éxito ocurre de manera constante y se mantiene la calidad continua. Además, el proceso es más fluido con menos fricción y frustración en el camino para todos los involucrados.
Note- La investigación ha demostrado que los equipos de proyectos pueden eliminar del 50 al 80% de los defectos del proyecto mediante la gestión eficaz de los requisitos. Según el instituto de ingeniería de software Carnegie Mellon, "el 60-80 por ciento del costo del desarrollo de software está en reelaboración".
Obtención de aprobación de requisitos
La firma de requisitos formaliza el acuerdo de las partes interesadas del proyecto de que el contenido y la presentación de los requisitos, según se documenta, son precisos y completos. El acuerdo formal reduce el riesgo de que, durante o después de la implementación, una parte interesada introduzca un nuevo requisito (no encontrado anteriormente).
La obtención de la aprobación de los requisitos generalmente implica una revisión final cara a cara de los requisitos, según se documenta, con cada parte interesada del proyecto. Al final de cada revisión, se solicita a las partes interesadas que aprueben formalmente el documento de requisitos revisado. Esta aprobación puede registrarse física o electrónicamente.
La obtención de la aprobación de los requisitos suele ser la tarea final dentro de la Comunicación de requisitos. El Analista de Negocios requerirá el resultado de la (s) Revisión (es) de Requisitos Formales, incluida la adaptación de cualquier comentario u objeción que se haya planteado durante el proceso de revisión.