mejores prácticas de ingeniería de requisitos
TRANSCRIPT
Kevin Parker, vicepresidente de marketing mundial de Serena
Software (ahora parte de Micro Focus®)
Informe oficial
Índice página
Requisitos como proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Atributos esenciales de una solución de gestión de requisitos . . . . . . . . . . . . . . 6
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
¿Son los requisitos aún “una cosa”?
Un requisito define un único comportamiento atómico que necesita o que busca la empresa
a fin de lograr sus objetivos. El requisito se debe poder probar de formas cuantificables.
Debe ser completo y contener toda la información necesaria. No debe contradecir ningún
otro requisito y debe seguir los estándares legales . Debe incluir al menos un participante,
un responsable comercial y beneficiar al menos a un usuario.
Un requisito define una propiedad que es esencial para la empresa La definición es sencilla. El rango de metodologías para recopilar y gestionar requisitos
varía más que cualquier otra disciplina de gestión de la vida útil de la aplicación (ALM).
Algunas diferencias son el resultado del nivel de especificidad necesario para un proyecto
determinado debido al ámbito del producto, la complejidad de la aplicación o el tamaño
del equipo y la distribución. En una única organización, un equipo puede necesitar el
perfeccionamiento de requisitos con revisiones detalladas por participante, a diferencia de
otro, que puede empezar con una idea simple y repetir y crear prototipos hasta contar con
los conocimientos suficientes para empezar a generar la solución.
La IEEE define los requisitos como “… las condiciones o capacidades que un sistema
(o componente del sistema) debe cumplir para satisfacer un contrato, estándar,
especificación u otra restricción impuesta oficialmente…”
Karl Wiegers1, la principal autoridad en ingeniería de requisitos, simplifica la definición
para englobar las propiedades que debe tener un producto para proporcionar valor a un
participante .
Todo trabajo del ciclo de vida de desarrollo de software (SDLC)2 comienza con una idea.
Esa idea puede ser un nuevo sistema que desarrollar, una petición de mejora para un sistema
existente o una necesidad de solucionar algo que no se comporta como debería.
Los denominamos nuevos sistemas, mejoras y soluciones. Los catalogamos, priorizamos y
organizamos en lanzamientos, versiones y parches.
Nuevos: nuevos sistemas o nuevas funciones de un sistema existente. Generalmente son los proyectos más importantes en una organización y eso hace que sean los más costosos. Por consiguiente, la financiación de estos proyectos es difícil de obtener. El cálculo, la planificación y la ejecución son más difíciles de realizar porque nos enfrentamos a innumerables incógnitas.
Ejemplo: agregar la capacidad de mostrar el catálogo de productos en un dispositivo móvil.
En una única organización, un equipo puede necesitar el perfeccionamiento de requisitos con revisiones detalladas por participante, a diferencia de otro, que puede empezar con una idea simple y repetir y crear prototipos hasta contar con los conocimientos suficientes para empezar a generar la solución. __________
1 www.karlwiegers.com y http://en.wikipedia.org/ wiki/Karl_Wiegers
2 Ciclo de vida de desarrollo de software, consulte: http://en.wikipedia. org/wiki/Software_ development_process
Informe oficial Mejores prácticas de ingeniería de requisitos
Mejoras: mejoras en el código existente. Se trata de un trabajo incremental y los costes son más bajos, el riesgo es menor y la financiación suele ser más fácil de obtener. Pueden ser proyectos que se dilaten en el tiempo o que duren poco. Son más fáciles de calcular y calcular el gasto porque están relacionados con problemas conocidos de solución estipulada.
Ejemplo: hacer que el catálogo de productos muestre los precios en euros, libras y yenes además de dólares estadounidenses.
Soluciones: a menudo pequeños cambios en el código existente que no añaden nuevas funciones, las soluciones cambian el comportamiento actual de la funcionalidad para cumplir las expectativas de la empresa. La mayor parte de las soluciones tratan comportamientos que son erróneos y dañan a la empresa, aunque las hay que modifican el comportamiento para lograr que funcionen mejor y más rápido.
Ejemplo: en el control de salida, el impuesto se añade a las ventas nacionales únicamente y no a todas las ventas mundiales.
ALM consiste en tomar la idea y convertirla en una solución. Llegar allí es un largo viaje.
De hecho, la simple captura de la idea no es tarea sencilla tampoco.
Requisitos como proceso
La definición del problema puede tardar minutos o meses en determinarse. Depende de
muchos factores. Estos son solo algunas de las cosas que la organización tiene en cuenta
a la hora de definir un problema:
Controles normativos y de conformidad
Seguridad e integridad de los datos
Acceso y autenticación
Disponibilidad de soluciones comerciales
Disponibilidad de recursos
Necesidades de rendimiento
Necesidades de internacionalización
Todo esto antes de preguntarnos: “¿Qué es exactamente lo que quiere que haga esta
tecnología?”.
1. Utilizar prototipos y simulación en lugar de definiciones escritas.
2. Compartir ideas con tantos participantes como sea posible y revisar las opiniones recibidas.
3. Utilizar técnicas de ludificación para obtener comentarios equilibrados.
4. Cada requisito se debe probar.
5. Cada requisito debe ser acerca de una cosa.
6. Mantener el seguimiento desde la petición hasta el requisito que se va a implementar.
7. Utilizar guiones gráficos, casos de uso, pseudocódigo o lo que sea que proporcione un significado claro.
8. Probar todos los requisitos para comprobar su impacto en las funciones existentes y futuras.
9. Mantener la nueva priorización según las prioridades del negocio.
10. Requisitos de versión y cambios de documentos.
3www.microfocus.com
Paso 1: ideación y captura de demanda: es habitual el uso simultáneo de varios
sistemas de tickets para diferentes tipos de peticiones y para diferentes sistemas. Algunos
sistemas son de autoservicio y otros requieren el uso de un correo electrónico o llamada
telefónica. Con bastante frecuencia, Microsoft Excel es el repositorio de estas peticiones.
La mayoría de las organizaciones tienen una forma de recopilar ideas de la empresa,
normalmente a través de algún tipo de sistema de “tickets”, que suele denominarse sistema
de petición de cambio (o sistema CR). Estos suelen estar alojados y gestionados por el
servicio de ayuda técnica (también denominado oficina de servicios).
Un elemento esencial de este proceso es la recopilación de ideas de una forma coherente
y rastreable. La ideación es un concepto más moderno y no formalizado en muchas
organizaciones. En algunas empresas, lo realiza el comité de revisión de control de cambios
(CCRB) o el comité de asesoramiento en materia de cambios (CAB) y muchos otros títulos
similares. Con demasiada frecuencia, MS Excel es el sistema de registro, lo que dificulta en
gran medida la colaboración y la visibilidad.
Paso 2: gestión de cambios: aquí es donde se produce la clasificación de las ideas
de modo que las más importantes, las que tienen restricciones temporales y las que son
esenciales para el control tienen la máxima prioridad. Se realiza un estudio de la viabilidad,
financiación, obtención de recursos y proceso de programación de las ideas antes de
aprobarlas para su desarrollo . Algunas peticiones urgentes y de emergencia obtienen la
aprobación inmediata si el impacto de las mismas en la empresa es grande .
A veces denominada gestión de la demanda, se trata de un concepto más reciente impulsado
por TI, que es más responsable del dinero gastado. El propósito de la gestión de la demanda
es garantizar que los proyectos en los que trabaja TI son proyectos que coinciden con
las prioridades de la empresa. Con frecuencia, los directores de sistemas de información
hablarán de “alineación” o “alineación de TI con la empresa”: cuando lo hacen, están
describiendo la necesidad de garantizar que los proyectos esenciales de conformidad y
misión crítica son los que se implementan en primer lugar y más rápido. El comité de
revisión puede supervisar este proceso y establecer las prioridades, los objetivos e incluso los
presupuestos .
Paso 3: obtención de requisitos: implica la recopilación y registro de los requisitos de
los participantes y otras fuentes. Se utilizan varias técnicas, entre otras, entrevistas, análisis
de documentos, grupos específicos, talleres y, más recientemente, creación de prototipos,
simulación y ludificación. La creación iterativa de prototipos define los requisitos en menos
tiempo de lo que se tardaría en preguntar y volver a preguntar al usuario empresarial.
La ideación es un concepto más moderno y no formalizado en muchas organizaciones.
Informe oficial Mejores prácticas de ingeniería de requisitos
En una organización Agile, el proceso seguido es prácticamente el mismo, excepto que hay muchos más cambios en el momento en que se realiza una actividad de ingeniería de requisitos más tradicional.
La persona clave en un equipo Agile es el propietario del producto, cuya tarea es la de actuar como enlace entre la empresa y el equipo de desarrollo.
El propietario del producto recopila los requisitos y órdenes y los prioriza para el equipo de desarrollo. El propietario del producto realiza la clasificación con la empresa, ayudando a la empresa a permanecer centrada en preguntar qué es lo más importante.
__________
4 http://en.wikipedia.org/ wiki/Unified_Modeling_ Language
Paso 4: validación de requisitos: confirma que el conjunto de requisitos cumple las
necesidades y objetivos empresariales. Este paso existe para garantizar que la información
recopilada es suficiente para crear la solución deseada, y que cumple con restricciones
organizativas tales como estándares de conformidad y control.
Con frecuencia, la definición de los requisitos falla porque el idioma inglés es demasiado
impreciso para reflejar los sutiles detalles de la necesidad empresarial. El desarrollo de
casos de uso3 y el uso de métodos formalizados como el lenguaje unificado de modelado
(UML)4 ayudan a definir con precisión exactamente cuáles serán los comportamientos
esperados para la solución. Estas herramientas ayudan en el desarrollo de casos de prueba
que formarán la base de la validación de la implementación con respecto al requisito más
adelante en el ciclo de vida de desarrollo.
Paso 5: gestión de requisitos: a menudo, esta actividad sigue procedimientos muy
formales y es el proceso en el que los requisitos se mejoran, versionan, rastrean, supervisan,
priorizan, asignan y, en definitiva, gestionan. Estas actividades incluyen:
El perfeccionamiento continuo de los requisitos a medida que se recopilan más datos, entradas e ideas
La ordenación y priorización de requisitos en función de la entrada de la empresa
El ámbito de los requisitos individuales en el esfuerzo
La organización de los requisitos en grupos que conforman piezas de trabajo razonables y versiones que deben terminar los equipos de desarrollo
El seguimiento de los cambios, actualizaciones y modificaciones de los requisitos a medida que se perfeccionan las necesidades empresariales
El mantenimiento del seguimiento para garantizar un seguimiento de auditoría desde la petición hasta la implementación
La supervisión de las aprobaciones para la implementación de requisitos para la financiación de proyectos
El mantenimiento de las relaciones y dependencias entre los requisitos
El proceso de gestión de requisitos es esencial para las mejores prácticas de desarrollo de
aplicaciones. Sin el conocimiento de lo que se supone que se va desarrollar, la probabilidad
de que coincida con la necesidad empresarial es casi nula. No importa cómo se defina
el término, o dónde se encuentre su organización en el espectro metodológico, se deben
entender las expectativas del cliente (o del cliente potencial) antes de comenzar la
construcción. El “cómo” se puede trabajar en desarrollo, pero el “qué” debe entenderse antes
de la aprobación de la financiación.
Mejores prácticas para la gestión de requisitos
Espere que la rotación de requisitos pase del 1 % al 5 % al mes.Fuente: Gartner
“La mejor práctica para la gestión de requisitos es aplicar las mejores prácticas definidas
para la gestión de configuraciones a la gestión de requisitos.”—Kay Fuhrmann, director de
productos de Serena Software (ahora parte de Micro Focus)
1. Convenciones de nomenclatura. Definición y mantenimiento de las convenciones para identificar versiones: desde el conjunto de requisitos aprobados hasta la nueva versión de línea de base y la solución o parche de emergencia.
2. Requisitos de línea de base. Los requisitos, como las nuevas versiones de software, deben ser línea de base y dichas líneas de base se deben asignar directamente a las nuevas versiones que producen.
3. Proceso de control de cambios bien definido y entendido. Una vez que se crea una línea de base, se deben controlar, rastrear, trazar, aprobar y revisar los cambios.
4. Revisión de requisitos. Se debe contar con un proceso de revisión de requisitos de aplicación obligatoria.
5. Expectativa de cambios. Asegúrese de que los cambios se puedan realizar fácilmente pero bajo estrictas reglas de control de acceso con un seguimiento completo.
6. Gestión de versiones. El historial de requisitos se debe mantener mediante métodos que faciliten a los analistas revisar lo anterior.
7. Seguimiento de requisitos. Sin la capacidad de realizar un seguimiento de un requisito de la idea hasta su implementación definida, no hay capacidad para entender el impacto del cambio propuesto.
8. Mantenimiento de la información. Mantenga atributos para dependencias, relaciones, propietarios, participantes, usuarios, financiador, fechas, gastos, modelos, prototipos, diagramas, control, etc. acerca del requisito.
9. Colaboración. Proporcione acceso sencillo a la información de requisitos y notifique automáticamente a los participantes de cualquier cambio de estado o cambio del requisito para promover la colaboración.
10. Requisitos en una única ubicación. Mantenga los requisitos en una única ubicación, preferiblemente en una base de datos diseñada para gestionarlos.
Los proyectos se gestionan a través de los logros (un conjunto de requisitos) e historias (un requisito) que componen la acumulación de tareas del sprint (requisitos asignados al desarrollo pero aún no terminados) del trabajo que se va a realizar.
Se realiza un seguimiento del progreso mediante gráficos de evolución (requisitos terminados) que muestran el progreso hacia el final del sprint actual. Un principio clave de Agile es la autoorganización y la reunión de sesión rápida diaria mantiene todo sincronizado en el proyecto.
La acumulación de proyectos cambia constantemente de prioridad para satisfacer las cambiantes necesidades empresariales.
Atributos esenciales de una solución de gestión de requisitos
Facilidad de uso
Implementación
La implementación de la solución se debe configurar fácilmente para adoptar el lenguaje
utilizado en la organización. No debe ser un requisito que el léxico cambie para adaptarse a
la solución. La formación, implementación razonable y localización se deben terminar en un
plazo de dos a cuatro semanas.
La solución debe ser fácil de aprender
Los nuevos usuarios, independientemente de su función, pueden aprender rápidamente
a iniciar sesión en la solución y navegar por la interfaz del cliente. En este contexto, los
revisores de requisitos no técnicos, que comprenden los requisitos de la empresa, pueden
empezar a trabajar con una descripción general de la página. El resto de usuarios de la
solución, a excepción de los administradores o gestores de proyectos formados para admitir
la implementación, deberían poder utilizar el producto después de dos a cuatro horas de
formación.
La solución debe ser fácil de usar
La solución seleccionada para la gestión y generación del informe de requisitos debe facilitar
la tarea de todos los participantes y poder aumentar, al mismo tiempo, la posibilidad de los
mismos de acceder a la información. El usuario general no debería tardar más de una hora
en entender cómo realizar funciones específicas con la solución.
Las propiedades y visualización deben ser configurables
Debe ser posible para los usuarios o administradores modificar la cantidad de información
visualizada.
Todos los participantes deben tener acceso a documentos
Debe ser posible publicar documentos en formato empresarial para su revisión y aprobación.
No debería ser necesario que los usuarios utilicen la herramienta para ver la información
que incluyen .
La tecnología y la filosofía de la herramienta deben ser transparentes
Los usuarios no deberían tener que contar con ninguna capacidad arquitectónica,
administrativa o técnica para utilizar la herramienta para agregar, modificar, revisar o
aprobar los requisitos y sus propiedades .
10 funciones más solicitadas de una solución de gestión de requisitos Fuente: Forrester
Línea de base de requisitos para rastrear la desviación de alcance
Modelado y simulación de requisitos
Herramientas visuales para gestionar requisitos en nuevas versiones, funciones y parches
Apoyo a las decisiones para priorizar la selección de requisitos
Enlace y rastreo de las relaciones entre los requisitos y las peticiones
Captura de requisitos centrados en el usuario
Reutilización de requisitos comunes y compartidos
Flujo de trabajo de requisitos en paralelo a otros flujos de trabajo del SDLC
Integración basada en el seguimiento con otras herramientas de ciclo de vida de ALM
Requisitos de uso inmediato para necesidades de conformidad comunes como ITAR
7www.microfocus.com
Los requisitos del usuario (a veces denominados requisitos empresariales) identifican las capacidades que los participantes desean o necesitan, mientras que los requisitos funcionales especifican lo que el sistema debe hacer para proporcionar la capacidad establecida.
Debe haber métodos para organizar los requisitos
Debe ser posible crear contenedores (carpetas) como método para organizar requisitos
según el componente, subtipo o para crear listas de usuarios o grupos específicos.
Se deben admitir las funciones de los usuarios
Debe ser posible definir funciones organizativas o de proyecto y asignar usuarios a dichas
funciones.
El sistema debe ser flexible Los requisitos de distinguen por tipo o clasificación. Entre los tipos de requisito comunes
se incluyen los requisitos del usuario y funcionales. Los requisitos del usuario (a veces
denominados requisitos empresariales) identifican las capacidades que el participante desea
o necesita, mientras que los requisitos funcionales especifican lo que el sistema debe hacer
para proporcionar la capacidad indicada. También hay otros tipos de requisitos comunes,
como los no funcionales, del sistema, técnicos y de casos de prueba. Más allá de estos tipos
básicos, las clasificaciones utilizadas para los requisitos son tan diversas como el software
que se va a desarrollar o los procesos empleados por la organización para hacerlo. Una
buena solución de gestión de requisitos debe ser capaz de proporcionar un medio para
clasificar cualquier requisito que la organización desee definir y sus propiedades (metadatos)
también deben ser totalmente configurables.
Los requisitos se deben almacenar como objetos individuales
Los requisitos de todos los tipos se deben almacenar como objetos individuales. Se pueden
enlazar a otros objetos del proyecto, pero no ser propiedad de estos. Se puede recopilar
cualquier combinación de estos objetos para su visualización o publicación.
Los requisitos se deben poder organizar en jerarquías y descomponer hasta el
nivel atómico
Requisitos de todos los tipos se deben poder dividir en requisitos cada vez menores hasta
que alcancen el tamaño atómico que representa únicamente un requisito específico. Las
jerarquías de requisitos descompuestos se deben poder manejar individualmente, en nivel
atómico, y en la jerarquía y el nivel de jerarquía intermedio con acción en cascada hasta los
requisitos descompuestos .
Los tipos de requisitos deben reflejar los estándares empresariales
Se debe asignar un nombre y describir los tipos de requisitos según las necesidades y los
procesos de la organización, en lugar de los del proveedor de la herramienta. No debe haber
ningún requisito en la solución que incluya un tipo de requisito de uso inmediato .
Las propiedades debe ser configurables
Se deben poder definir y asignar propiedades a tipos de requisitos, más allá de los valores
predeterminados definidos por el producto. Los tipos de datos usados en la definición de
estas propiedades también deben ser flexibles. Por ejemplo, deben incluir campos de texto
(cortos y largos), listas desplegables, campos numéricos y campos de fecha. Debe ser posible
asociar gráficos o adjuntos a los tipos de datos.
Las propiedades tienen que utilizar términos conocidos
El lenguaje utilizado para definir los requisitos y sus propiedades debe reflejar el léxico de
la organización y se debe hacer referencia a él de forma coherente en la solución. Debe ser
posible que varios equipos de proyecto de la misma organización definan tipos de requisitos
y utilicen términos que cumplan las necesidades de cada uno. No se debe requerir que
ningún grupo lleve el bagaje de los otros.
Debe haber un seguimiento
Debe ser posible crear una vista de seguimiento, con mecanismos para seleccionar los tipos
de requisitos que se van a seguir. La información recopilada se debe visualizar en un formato
que sea fácil de leer y de analizar.
Importación de requisitos La mayoría de equipos de proyecto, antes de la adopción de una solución de gestión de
requisitos, mantienen requisitos en documentos de MS Excel o MS Word. Es esencial
que la solución importe los datos existentes y debe ser capaz de seguir importando las
actualizaciones de requisitos.
Importar datos de archivos de MS Word
La solución debe proporcionar una funcionalidad para facilitar la importación de datos
de archivos de MS Word. Debe ser posible, por ejemplo, importar los requisitos de este
documento .
Importar datos de archivos de MS Excel
Debe ser posible importar determinados datos de archivos de MS Excel con el fin de crear
nuevos requisitos, con mecanismos sencillos para asignar columnas a propiedades.
Exportar a archivos de MS Excel
Debe ser posible exportar determinados datos de requisitos a archivos de MS Excel,
con mecanismos sencillos para asignar propiedades a columnas .
El lenguaje utilizado para definir los requisitos y sus propiedades debe reflejar el léxico de la organización y se debe hacer referencia a él de forma coherente en la solución.
9www.microfocus.com
La solución debe admitir la funcionalidad para actualizar requisitos existentes con datos de
hojas de cálculo de MS Excel. La asignación de identificadores o nombres de requisitos de
la hoja de MS Excel al requisito actual y, a continuación, la adición de nuevas propiedades
o la actualización de las propiedades existentes permitirá a todos los participantes, incluso
aquellos sin acceso a la solución, tener una función activa en el proceso de revisión. Las
actualizaciones de hojas de cálculo de MS Excel garantizarán también las capacidades de
lotes .
Establecer o actualizar los enlaces con hojas de cálculo
Se pueden establecer enlaces entre los requisitos mediante hojas de cálculo de MS Excel.
Importar datos de soluciones ALM asociadas
Los archivos de MS Excel o CSV generados por cualquier solución del espectro de ALM
se pueden importar con el fin de enlazar, modificar, agregar o suprimir requisitos o sus
propiedades .
Filtros controlados por el usuario
Los requisitos se gestionan, ven o revisan en diferentes momentos del ciclo de desarrollo y
por parte de diferentes personas con necesidades muy distintas. Rara vez es necesario que
alguien lo vea todo.
Listas e informes filtrados por la propiedad de requisito
Debe ser posible filtrar cualquier propiedad no binaria definida en el requisito.
Establecer y actualizar conjuntos de requisitos
Debe ser posible crear conjuntos de requisitos de cualquier tipo y establecer líneas de base a
partir de dichos conjuntos.
Consultas para permitir la selección de requisitos
La herramienta debe permitir el uso de consultas simples o complejas con el fin de recopilar
requisitos basados en el tipo, la propiedad, la ausencia o presencia de una lista, relación
(enlace) o una combinación de éstos; por ejemplo, todos los requisitos del usuario de
alta prioridad que están relacionados con al menos un caso de prueba cuya propiedad de
resultado de la prueba se define en “fallido”.
Los requisitos se gestionan, ven o revisan en diferentes momentos del ciclo de desarrollo y por parte de diferentes personas con necesidades muy distintas. Rara vez es necesario que alguien lo vea todo.
Informe oficial Mejores prácticas de ingeniería de requisitos
Creación sencilla de documentos, listas o archivos csv
Debe ser posible guardar, imprimir o crear archivos de MS Excel o CSV desde cualquier
cuadro de diálogo de la interfaz de usuario.
La solución debe gestionar el historial de requisitos La solución debe ser capaz de proporcionar un mecanismo para crear, suprimir y cambiar un
requisito así como todos y cada uno de los metadatos almacenados con el requisito. También
debe existir la posibilidad de mantener un registro de todas las transacciones .
Se debe mantener el historial de requisitos
La solución debe ser capaz de mantener el historial de cambios para todas las necesidades y
propiedades de requisitos .
Los requisitos se pueden retrasar o abandonar
La solución debe proporcionar la funcionalidad para abandonar o retrasar los requisitos.
Debe ser posible filtrar fácilmente estos requisitos en las listas generales, mientras se
mantiene la accesibilidad para revisión o nueva adopción.
Los requisitos se pueden suprimir
La solución debe permitir que un requisito se suprima permanentemente del proyecto .
Las líneas de base se pueden crear y actualizar con agilidad
Debe haber utilidades para la creación de líneas de base de nuevas versiones que se puedan
versionar y realizar un seguimiento de los cambios. Debe ser posible comparar las líneas de
base para crear una lista sencilla de requisitos modificados, así como un informe detallado
de las diferencias entre las líneas de base.
Enlace y seguimiento de requisitos Un buen sistema de requisitos no solo debe ser capaz de proporcionar un medio de
clasificación de cualquier tipo de requisito, sino que también debe ser capaz de enlazar los
requisitos de varios tipos. El enlace de requisitos proporciona los mecanismos para informes
de seguimiento .
Un buen sistema de requisitos no solo debe ser capaz de proporcionar un medio de clasificación de cualquier tipo de requisito, sino que también debe ser capaz de enlazar los requisitos de varios tipos.
11www.microfocus.com
Enlace de requisitos
Debe existir una funcionalidad para crear relaciones entre tipos de requisitos. Los enlaces
que expresan estas relaciones deben ser de uno a muchos, de muchos a uno o de muchos a
muchos. Por ejemplo, puede haber varios casos de prueba para un único requisito funcional,
pero un caso de prueba se puede aplicar a más de un requisito funcional.
Enlaces manuales
La solución debe proporcionar la capacidad para establecer enlaces manualmente o
mediante un formulario de importación por lotes.
Enlaces suprimidos
Los objetos enlazados deben informar del impacto del cambio
Los objetos enlazados deben mostrar el impacto de los cambios ascendentes. Por ejemplo,
dado un caso de prueba enlazado a un requisito funcional que está enlazado a un requisito
del usuario, un cambio en el requisito del usuario supondrá un posible impacto y, por lo
tanto, obligará a la revisión del requisito funcional y del caso de prueba. Un cambio en
el requisito funcional obligará a la revisión del caso de prueba, pero no del requisito del
usuario .
Matriz de seguimiento
Debe haber disponible una matriz de seguimiento completa que utilice cualquier tipo
de requisito definido y que sea relativamente fácil de usar. El seguimiento visualiza las
conexiones entre los requisitos, permitiendo a los participantes ver que los requisitos
del usuario se han detallado a través de requisitos funcionales asociados y que se han
establecido casos de prueba para cada requisito funcional. La matriz de seguimiento debe
informar del cumplimiento, y durante la vida de la aplicación, debe informar del impacto
del cambio .
Debe haber una excelente funcionalidad de informes La solución debe facilitar un buen informe y debe ser posible generar documentos con un
formato con el que los participantes estén totalmente familiarizados. Resulta fundamental
mantener informes actualizados para el proceso de gestión de requisitos y la creación de
dichos informes debe ser una extensión simple del filtrado y ordenación de la interfaz del
cliente .
Resulta fundamental mantener informes actualizados para el proceso de gestión de requisitos y la creación de dichos informes debe ser una extensión simple del filtrado y ordenación de la interfaz del cliente.
Admisión flexible de documentos
Debe ser posible seleccionar listas de requisitos mediante guiones o consultas y utilizar
fácilmente esas listas para crear o actualizar un documento.
Documentos de control de versiones
Debe ser posible bloquear el contenido de un documento y asignarle al documento
bloqueado un nombre o versión. También debe ser posible suprimir dichos documentos
libremente .
Requisitos que se pueden publicar en formato de documento
Debe ser posible exportar (publicar) documentos con un formato (plantilla) que sea familiar
y que se pueda compartir entre los proyectos .
Facilidad para comparar documentos
La solución debe proporcionar la capacidad para comparar versiones de documentos.
Informes gráficos
Debe ser posible crear informes gráficos o recopilar y exportar los datos necesarios para
crear los informes con las herramientas existentes actuales. Los informes deben incluir,
entre otros, gráficos de barras que muestren los requisitos programados por tipo, número
programado para una versión con nombre y número, que se va a implementar.
Los informes deben incluir, entre otros, gráficos de barras que muestren los requisitos programados por tipo, número programado para una versión con nombre y número, que se va a implementar.
13www.microfocus.com
Resumen
Para algunas organizaciones es difícil dar forma a la disciplina de gestión de requisitos,
y por ello, los grupos suelen sobrecargar el proceso en detrimento del proyecto . Los equipos
de proyecto suelen pasar más tiempo discutiendo acerca de la adecuada estructura del caso
de uso o la diferencia entre un usuario y un requisito empresarial que acerca del contenido
de cualquiera de ellos. Puesto que dichos argumentos no hacen avanzar el proyecto, los
miembros del equipo continuarán y asumirán que las preguntas abiertas se abordarán
durante el desarrollo .
El proceso de gestión de requisitos es esencial para las mejores prácticas de desarrollo de
aplicaciones. Sin el conocimiento de lo que se supone que se va desarrollar, la probabilidad
de que coincida con la necesidad empresarial es casi nula . La gestión de requisitos puede
comenzar con una lista en la que se definan y gestionen las expectativas del proyecto. La lista
se puede visualizar como una pizarra abierta, que recopile y ordene las notas y los cambios.
También puede expandirse al detalle técnico de control y enlazar el detalle a los casos de
prueba, que en última instancia admitirá capacidades completas de informes de requisitos.
Las mejores soluciones de gestión de requisitos son fáciles de aprender, fáciles de usar,
accesibles y transparentes. Además cuentan con excelentes funcionalidades de seguimiento
y creación de versiones e informes. Estas funcionalidades funcionan conjuntamente
para proporcionar la base de una solución de prestigio mundial y el inicio de un proceso
requisitos de mejores prácticas .
Las mejores soluciones de gestión de requisitos son fáciles de aprender, fáciles de usar, accesibles y transparentes.
www.microfocus.com
Panamá +507 2 039291
Micro Focus Sedes corporativas Reino Unido +44 (0) 1635 565200
Informe oficial
Índice página
Requisitos como proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Atributos esenciales de una solución de gestión de requisitos . . . . . . . . . . . . . . 6
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
¿Son los requisitos aún “una cosa”?
Un requisito define un único comportamiento atómico que necesita o que busca la empresa
a fin de lograr sus objetivos. El requisito se debe poder probar de formas cuantificables.
Debe ser completo y contener toda la información necesaria. No debe contradecir ningún
otro requisito y debe seguir los estándares legales . Debe incluir al menos un participante,
un responsable comercial y beneficiar al menos a un usuario.
Un requisito define una propiedad que es esencial para la empresa La definición es sencilla. El rango de metodologías para recopilar y gestionar requisitos
varía más que cualquier otra disciplina de gestión de la vida útil de la aplicación (ALM).
Algunas diferencias son el resultado del nivel de especificidad necesario para un proyecto
determinado debido al ámbito del producto, la complejidad de la aplicación o el tamaño
del equipo y la distribución. En una única organización, un equipo puede necesitar el
perfeccionamiento de requisitos con revisiones detalladas por participante, a diferencia de
otro, que puede empezar con una idea simple y repetir y crear prototipos hasta contar con
los conocimientos suficientes para empezar a generar la solución.
La IEEE define los requisitos como “… las condiciones o capacidades que un sistema
(o componente del sistema) debe cumplir para satisfacer un contrato, estándar,
especificación u otra restricción impuesta oficialmente…”
Karl Wiegers1, la principal autoridad en ingeniería de requisitos, simplifica la definición
para englobar las propiedades que debe tener un producto para proporcionar valor a un
participante .
Todo trabajo del ciclo de vida de desarrollo de software (SDLC)2 comienza con una idea.
Esa idea puede ser un nuevo sistema que desarrollar, una petición de mejora para un sistema
existente o una necesidad de solucionar algo que no se comporta como debería.
Los denominamos nuevos sistemas, mejoras y soluciones. Los catalogamos, priorizamos y
organizamos en lanzamientos, versiones y parches.
Nuevos: nuevos sistemas o nuevas funciones de un sistema existente. Generalmente son los proyectos más importantes en una organización y eso hace que sean los más costosos. Por consiguiente, la financiación de estos proyectos es difícil de obtener. El cálculo, la planificación y la ejecución son más difíciles de realizar porque nos enfrentamos a innumerables incógnitas.
Ejemplo: agregar la capacidad de mostrar el catálogo de productos en un dispositivo móvil.
En una única organización, un equipo puede necesitar el perfeccionamiento de requisitos con revisiones detalladas por participante, a diferencia de otro, que puede empezar con una idea simple y repetir y crear prototipos hasta contar con los conocimientos suficientes para empezar a generar la solución. __________
1 www.karlwiegers.com y http://en.wikipedia.org/ wiki/Karl_Wiegers
2 Ciclo de vida de desarrollo de software, consulte: http://en.wikipedia. org/wiki/Software_ development_process
Informe oficial Mejores prácticas de ingeniería de requisitos
Mejoras: mejoras en el código existente. Se trata de un trabajo incremental y los costes son más bajos, el riesgo es menor y la financiación suele ser más fácil de obtener. Pueden ser proyectos que se dilaten en el tiempo o que duren poco. Son más fáciles de calcular y calcular el gasto porque están relacionados con problemas conocidos de solución estipulada.
Ejemplo: hacer que el catálogo de productos muestre los precios en euros, libras y yenes además de dólares estadounidenses.
Soluciones: a menudo pequeños cambios en el código existente que no añaden nuevas funciones, las soluciones cambian el comportamiento actual de la funcionalidad para cumplir las expectativas de la empresa. La mayor parte de las soluciones tratan comportamientos que son erróneos y dañan a la empresa, aunque las hay que modifican el comportamiento para lograr que funcionen mejor y más rápido.
Ejemplo: en el control de salida, el impuesto se añade a las ventas nacionales únicamente y no a todas las ventas mundiales.
ALM consiste en tomar la idea y convertirla en una solución. Llegar allí es un largo viaje.
De hecho, la simple captura de la idea no es tarea sencilla tampoco.
Requisitos como proceso
La definición del problema puede tardar minutos o meses en determinarse. Depende de
muchos factores. Estos son solo algunas de las cosas que la organización tiene en cuenta
a la hora de definir un problema:
Controles normativos y de conformidad
Seguridad e integridad de los datos
Acceso y autenticación
Disponibilidad de soluciones comerciales
Disponibilidad de recursos
Necesidades de rendimiento
Necesidades de internacionalización
Todo esto antes de preguntarnos: “¿Qué es exactamente lo que quiere que haga esta
tecnología?”.
1. Utilizar prototipos y simulación en lugar de definiciones escritas.
2. Compartir ideas con tantos participantes como sea posible y revisar las opiniones recibidas.
3. Utilizar técnicas de ludificación para obtener comentarios equilibrados.
4. Cada requisito se debe probar.
5. Cada requisito debe ser acerca de una cosa.
6. Mantener el seguimiento desde la petición hasta el requisito que se va a implementar.
7. Utilizar guiones gráficos, casos de uso, pseudocódigo o lo que sea que proporcione un significado claro.
8. Probar todos los requisitos para comprobar su impacto en las funciones existentes y futuras.
9. Mantener la nueva priorización según las prioridades del negocio.
10. Requisitos de versión y cambios de documentos.
3www.microfocus.com
Paso 1: ideación y captura de demanda: es habitual el uso simultáneo de varios
sistemas de tickets para diferentes tipos de peticiones y para diferentes sistemas. Algunos
sistemas son de autoservicio y otros requieren el uso de un correo electrónico o llamada
telefónica. Con bastante frecuencia, Microsoft Excel es el repositorio de estas peticiones.
La mayoría de las organizaciones tienen una forma de recopilar ideas de la empresa,
normalmente a través de algún tipo de sistema de “tickets”, que suele denominarse sistema
de petición de cambio (o sistema CR). Estos suelen estar alojados y gestionados por el
servicio de ayuda técnica (también denominado oficina de servicios).
Un elemento esencial de este proceso es la recopilación de ideas de una forma coherente
y rastreable. La ideación es un concepto más moderno y no formalizado en muchas
organizaciones. En algunas empresas, lo realiza el comité de revisión de control de cambios
(CCRB) o el comité de asesoramiento en materia de cambios (CAB) y muchos otros títulos
similares. Con demasiada frecuencia, MS Excel es el sistema de registro, lo que dificulta en
gran medida la colaboración y la visibilidad.
Paso 2: gestión de cambios: aquí es donde se produce la clasificación de las ideas
de modo que las más importantes, las que tienen restricciones temporales y las que son
esenciales para el control tienen la máxima prioridad. Se realiza un estudio de la viabilidad,
financiación, obtención de recursos y proceso de programación de las ideas antes de
aprobarlas para su desarrollo . Algunas peticiones urgentes y de emergencia obtienen la
aprobación inmediata si el impacto de las mismas en la empresa es grande .
A veces denominada gestión de la demanda, se trata de un concepto más reciente impulsado
por TI, que es más responsable del dinero gastado. El propósito de la gestión de la demanda
es garantizar que los proyectos en los que trabaja TI son proyectos que coinciden con
las prioridades de la empresa. Con frecuencia, los directores de sistemas de información
hablarán de “alineación” o “alineación de TI con la empresa”: cuando lo hacen, están
describiendo la necesidad de garantizar que los proyectos esenciales de conformidad y
misión crítica son los que se implementan en primer lugar y más rápido. El comité de
revisión puede supervisar este proceso y establecer las prioridades, los objetivos e incluso los
presupuestos .
Paso 3: obtención de requisitos: implica la recopilación y registro de los requisitos de
los participantes y otras fuentes. Se utilizan varias técnicas, entre otras, entrevistas, análisis
de documentos, grupos específicos, talleres y, más recientemente, creación de prototipos,
simulación y ludificación. La creación iterativa de prototipos define los requisitos en menos
tiempo de lo que se tardaría en preguntar y volver a preguntar al usuario empresarial.
La ideación es un concepto más moderno y no formalizado en muchas organizaciones.
Informe oficial Mejores prácticas de ingeniería de requisitos
En una organización Agile, el proceso seguido es prácticamente el mismo, excepto que hay muchos más cambios en el momento en que se realiza una actividad de ingeniería de requisitos más tradicional.
La persona clave en un equipo Agile es el propietario del producto, cuya tarea es la de actuar como enlace entre la empresa y el equipo de desarrollo.
El propietario del producto recopila los requisitos y órdenes y los prioriza para el equipo de desarrollo. El propietario del producto realiza la clasificación con la empresa, ayudando a la empresa a permanecer centrada en preguntar qué es lo más importante.
__________
4 http://en.wikipedia.org/ wiki/Unified_Modeling_ Language
Paso 4: validación de requisitos: confirma que el conjunto de requisitos cumple las
necesidades y objetivos empresariales. Este paso existe para garantizar que la información
recopilada es suficiente para crear la solución deseada, y que cumple con restricciones
organizativas tales como estándares de conformidad y control.
Con frecuencia, la definición de los requisitos falla porque el idioma inglés es demasiado
impreciso para reflejar los sutiles detalles de la necesidad empresarial. El desarrollo de
casos de uso3 y el uso de métodos formalizados como el lenguaje unificado de modelado
(UML)4 ayudan a definir con precisión exactamente cuáles serán los comportamientos
esperados para la solución. Estas herramientas ayudan en el desarrollo de casos de prueba
que formarán la base de la validación de la implementación con respecto al requisito más
adelante en el ciclo de vida de desarrollo.
Paso 5: gestión de requisitos: a menudo, esta actividad sigue procedimientos muy
formales y es el proceso en el que los requisitos se mejoran, versionan, rastrean, supervisan,
priorizan, asignan y, en definitiva, gestionan. Estas actividades incluyen:
El perfeccionamiento continuo de los requisitos a medida que se recopilan más datos, entradas e ideas
La ordenación y priorización de requisitos en función de la entrada de la empresa
El ámbito de los requisitos individuales en el esfuerzo
La organización de los requisitos en grupos que conforman piezas de trabajo razonables y versiones que deben terminar los equipos de desarrollo
El seguimiento de los cambios, actualizaciones y modificaciones de los requisitos a medida que se perfeccionan las necesidades empresariales
El mantenimiento del seguimiento para garantizar un seguimiento de auditoría desde la petición hasta la implementación
La supervisión de las aprobaciones para la implementación de requisitos para la financiación de proyectos
El mantenimiento de las relaciones y dependencias entre los requisitos
El proceso de gestión de requisitos es esencial para las mejores prácticas de desarrollo de
aplicaciones. Sin el conocimiento de lo que se supone que se va desarrollar, la probabilidad
de que coincida con la necesidad empresarial es casi nula. No importa cómo se defina
el término, o dónde se encuentre su organización en el espectro metodológico, se deben
entender las expectativas del cliente (o del cliente potencial) antes de comenzar la
construcción. El “cómo” se puede trabajar en desarrollo, pero el “qué” debe entenderse antes
de la aprobación de la financiación.
Mejores prácticas para la gestión de requisitos
Espere que la rotación de requisitos pase del 1 % al 5 % al mes.Fuente: Gartner
“La mejor práctica para la gestión de requisitos es aplicar las mejores prácticas definidas
para la gestión de configuraciones a la gestión de requisitos.”—Kay Fuhrmann, director de
productos de Serena Software (ahora parte de Micro Focus)
1. Convenciones de nomenclatura. Definición y mantenimiento de las convenciones para identificar versiones: desde el conjunto de requisitos aprobados hasta la nueva versión de línea de base y la solución o parche de emergencia.
2. Requisitos de línea de base. Los requisitos, como las nuevas versiones de software, deben ser línea de base y dichas líneas de base se deben asignar directamente a las nuevas versiones que producen.
3. Proceso de control de cambios bien definido y entendido. Una vez que se crea una línea de base, se deben controlar, rastrear, trazar, aprobar y revisar los cambios.
4. Revisión de requisitos. Se debe contar con un proceso de revisión de requisitos de aplicación obligatoria.
5. Expectativa de cambios. Asegúrese de que los cambios se puedan realizar fácilmente pero bajo estrictas reglas de control de acceso con un seguimiento completo.
6. Gestión de versiones. El historial de requisitos se debe mantener mediante métodos que faciliten a los analistas revisar lo anterior.
7. Seguimiento de requisitos. Sin la capacidad de realizar un seguimiento de un requisito de la idea hasta su implementación definida, no hay capacidad para entender el impacto del cambio propuesto.
8. Mantenimiento de la información. Mantenga atributos para dependencias, relaciones, propietarios, participantes, usuarios, financiador, fechas, gastos, modelos, prototipos, diagramas, control, etc. acerca del requisito.
9. Colaboración. Proporcione acceso sencillo a la información de requisitos y notifique automáticamente a los participantes de cualquier cambio de estado o cambio del requisito para promover la colaboración.
10. Requisitos en una única ubicación. Mantenga los requisitos en una única ubicación, preferiblemente en una base de datos diseñada para gestionarlos.
Los proyectos se gestionan a través de los logros (un conjunto de requisitos) e historias (un requisito) que componen la acumulación de tareas del sprint (requisitos asignados al desarrollo pero aún no terminados) del trabajo que se va a realizar.
Se realiza un seguimiento del progreso mediante gráficos de evolución (requisitos terminados) que muestran el progreso hacia el final del sprint actual. Un principio clave de Agile es la autoorganización y la reunión de sesión rápida diaria mantiene todo sincronizado en el proyecto.
La acumulación de proyectos cambia constantemente de prioridad para satisfacer las cambiantes necesidades empresariales.
Atributos esenciales de una solución de gestión de requisitos
Facilidad de uso
Implementación
La implementación de la solución se debe configurar fácilmente para adoptar el lenguaje
utilizado en la organización. No debe ser un requisito que el léxico cambie para adaptarse a
la solución. La formación, implementación razonable y localización se deben terminar en un
plazo de dos a cuatro semanas.
La solución debe ser fácil de aprender
Los nuevos usuarios, independientemente de su función, pueden aprender rápidamente
a iniciar sesión en la solución y navegar por la interfaz del cliente. En este contexto, los
revisores de requisitos no técnicos, que comprenden los requisitos de la empresa, pueden
empezar a trabajar con una descripción general de la página. El resto de usuarios de la
solución, a excepción de los administradores o gestores de proyectos formados para admitir
la implementación, deberían poder utilizar el producto después de dos a cuatro horas de
formación.
La solución debe ser fácil de usar
La solución seleccionada para la gestión y generación del informe de requisitos debe facilitar
la tarea de todos los participantes y poder aumentar, al mismo tiempo, la posibilidad de los
mismos de acceder a la información. El usuario general no debería tardar más de una hora
en entender cómo realizar funciones específicas con la solución.
Las propiedades y visualización deben ser configurables
Debe ser posible para los usuarios o administradores modificar la cantidad de información
visualizada.
Todos los participantes deben tener acceso a documentos
Debe ser posible publicar documentos en formato empresarial para su revisión y aprobación.
No debería ser necesario que los usuarios utilicen la herramienta para ver la información
que incluyen .
La tecnología y la filosofía de la herramienta deben ser transparentes
Los usuarios no deberían tener que contar con ninguna capacidad arquitectónica,
administrativa o técnica para utilizar la herramienta para agregar, modificar, revisar o
aprobar los requisitos y sus propiedades .
10 funciones más solicitadas de una solución de gestión de requisitos Fuente: Forrester
Línea de base de requisitos para rastrear la desviación de alcance
Modelado y simulación de requisitos
Herramientas visuales para gestionar requisitos en nuevas versiones, funciones y parches
Apoyo a las decisiones para priorizar la selección de requisitos
Enlace y rastreo de las relaciones entre los requisitos y las peticiones
Captura de requisitos centrados en el usuario
Reutilización de requisitos comunes y compartidos
Flujo de trabajo de requisitos en paralelo a otros flujos de trabajo del SDLC
Integración basada en el seguimiento con otras herramientas de ciclo de vida de ALM
Requisitos de uso inmediato para necesidades de conformidad comunes como ITAR
7www.microfocus.com
Los requisitos del usuario (a veces denominados requisitos empresariales) identifican las capacidades que los participantes desean o necesitan, mientras que los requisitos funcionales especifican lo que el sistema debe hacer para proporcionar la capacidad establecida.
Debe haber métodos para organizar los requisitos
Debe ser posible crear contenedores (carpetas) como método para organizar requisitos
según el componente, subtipo o para crear listas de usuarios o grupos específicos.
Se deben admitir las funciones de los usuarios
Debe ser posible definir funciones organizativas o de proyecto y asignar usuarios a dichas
funciones.
El sistema debe ser flexible Los requisitos de distinguen por tipo o clasificación. Entre los tipos de requisito comunes
se incluyen los requisitos del usuario y funcionales. Los requisitos del usuario (a veces
denominados requisitos empresariales) identifican las capacidades que el participante desea
o necesita, mientras que los requisitos funcionales especifican lo que el sistema debe hacer
para proporcionar la capacidad indicada. También hay otros tipos de requisitos comunes,
como los no funcionales, del sistema, técnicos y de casos de prueba. Más allá de estos tipos
básicos, las clasificaciones utilizadas para los requisitos son tan diversas como el software
que se va a desarrollar o los procesos empleados por la organización para hacerlo. Una
buena solución de gestión de requisitos debe ser capaz de proporcionar un medio para
clasificar cualquier requisito que la organización desee definir y sus propiedades (metadatos)
también deben ser totalmente configurables.
Los requisitos se deben almacenar como objetos individuales
Los requisitos de todos los tipos se deben almacenar como objetos individuales. Se pueden
enlazar a otros objetos del proyecto, pero no ser propiedad de estos. Se puede recopilar
cualquier combinación de estos objetos para su visualización o publicación.
Los requisitos se deben poder organizar en jerarquías y descomponer hasta el
nivel atómico
Requisitos de todos los tipos se deben poder dividir en requisitos cada vez menores hasta
que alcancen el tamaño atómico que representa únicamente un requisito específico. Las
jerarquías de requisitos descompuestos se deben poder manejar individualmente, en nivel
atómico, y en la jerarquía y el nivel de jerarquía intermedio con acción en cascada hasta los
requisitos descompuestos .
Los tipos de requisitos deben reflejar los estándares empresariales
Se debe asignar un nombre y describir los tipos de requisitos según las necesidades y los
procesos de la organización, en lugar de los del proveedor de la herramienta. No debe haber
ningún requisito en la solución que incluya un tipo de requisito de uso inmediato .
Las propiedades debe ser configurables
Se deben poder definir y asignar propiedades a tipos de requisitos, más allá de los valores
predeterminados definidos por el producto. Los tipos de datos usados en la definición de
estas propiedades también deben ser flexibles. Por ejemplo, deben incluir campos de texto
(cortos y largos), listas desplegables, campos numéricos y campos de fecha. Debe ser posible
asociar gráficos o adjuntos a los tipos de datos.
Las propiedades tienen que utilizar términos conocidos
El lenguaje utilizado para definir los requisitos y sus propiedades debe reflejar el léxico de
la organización y se debe hacer referencia a él de forma coherente en la solución. Debe ser
posible que varios equipos de proyecto de la misma organización definan tipos de requisitos
y utilicen términos que cumplan las necesidades de cada uno. No se debe requerir que
ningún grupo lleve el bagaje de los otros.
Debe haber un seguimiento
Debe ser posible crear una vista de seguimiento, con mecanismos para seleccionar los tipos
de requisitos que se van a seguir. La información recopilada se debe visualizar en un formato
que sea fácil de leer y de analizar.
Importación de requisitos La mayoría de equipos de proyecto, antes de la adopción de una solución de gestión de
requisitos, mantienen requisitos en documentos de MS Excel o MS Word. Es esencial
que la solución importe los datos existentes y debe ser capaz de seguir importando las
actualizaciones de requisitos.
Importar datos de archivos de MS Word
La solución debe proporcionar una funcionalidad para facilitar la importación de datos
de archivos de MS Word. Debe ser posible, por ejemplo, importar los requisitos de este
documento .
Importar datos de archivos de MS Excel
Debe ser posible importar determinados datos de archivos de MS Excel con el fin de crear
nuevos requisitos, con mecanismos sencillos para asignar columnas a propiedades.
Exportar a archivos de MS Excel
Debe ser posible exportar determinados datos de requisitos a archivos de MS Excel,
con mecanismos sencillos para asignar propiedades a columnas .
El lenguaje utilizado para definir los requisitos y sus propiedades debe reflejar el léxico de la organización y se debe hacer referencia a él de forma coherente en la solución.
9www.microfocus.com
La solución debe admitir la funcionalidad para actualizar requisitos existentes con datos de
hojas de cálculo de MS Excel. La asignación de identificadores o nombres de requisitos de
la hoja de MS Excel al requisito actual y, a continuación, la adición de nuevas propiedades
o la actualización de las propiedades existentes permitirá a todos los participantes, incluso
aquellos sin acceso a la solución, tener una función activa en el proceso de revisión. Las
actualizaciones de hojas de cálculo de MS Excel garantizarán también las capacidades de
lotes .
Establecer o actualizar los enlaces con hojas de cálculo
Se pueden establecer enlaces entre los requisitos mediante hojas de cálculo de MS Excel.
Importar datos de soluciones ALM asociadas
Los archivos de MS Excel o CSV generados por cualquier solución del espectro de ALM
se pueden importar con el fin de enlazar, modificar, agregar o suprimir requisitos o sus
propiedades .
Filtros controlados por el usuario
Los requisitos se gestionan, ven o revisan en diferentes momentos del ciclo de desarrollo y
por parte de diferentes personas con necesidades muy distintas. Rara vez es necesario que
alguien lo vea todo.
Listas e informes filtrados por la propiedad de requisito
Debe ser posible filtrar cualquier propiedad no binaria definida en el requisito.
Establecer y actualizar conjuntos de requisitos
Debe ser posible crear conjuntos de requisitos de cualquier tipo y establecer líneas de base a
partir de dichos conjuntos.
Consultas para permitir la selección de requisitos
La herramienta debe permitir el uso de consultas simples o complejas con el fin de recopilar
requisitos basados en el tipo, la propiedad, la ausencia o presencia de una lista, relación
(enlace) o una combinación de éstos; por ejemplo, todos los requisitos del usuario de
alta prioridad que están relacionados con al menos un caso de prueba cuya propiedad de
resultado de la prueba se define en “fallido”.
Los requisitos se gestionan, ven o revisan en diferentes momentos del ciclo de desarrollo y por parte de diferentes personas con necesidades muy distintas. Rara vez es necesario que alguien lo vea todo.
Informe oficial Mejores prácticas de ingeniería de requisitos
Creación sencilla de documentos, listas o archivos csv
Debe ser posible guardar, imprimir o crear archivos de MS Excel o CSV desde cualquier
cuadro de diálogo de la interfaz de usuario.
La solución debe gestionar el historial de requisitos La solución debe ser capaz de proporcionar un mecanismo para crear, suprimir y cambiar un
requisito así como todos y cada uno de los metadatos almacenados con el requisito. También
debe existir la posibilidad de mantener un registro de todas las transacciones .
Se debe mantener el historial de requisitos
La solución debe ser capaz de mantener el historial de cambios para todas las necesidades y
propiedades de requisitos .
Los requisitos se pueden retrasar o abandonar
La solución debe proporcionar la funcionalidad para abandonar o retrasar los requisitos.
Debe ser posible filtrar fácilmente estos requisitos en las listas generales, mientras se
mantiene la accesibilidad para revisión o nueva adopción.
Los requisitos se pueden suprimir
La solución debe permitir que un requisito se suprima permanentemente del proyecto .
Las líneas de base se pueden crear y actualizar con agilidad
Debe haber utilidades para la creación de líneas de base de nuevas versiones que se puedan
versionar y realizar un seguimiento de los cambios. Debe ser posible comparar las líneas de
base para crear una lista sencilla de requisitos modificados, así como un informe detallado
de las diferencias entre las líneas de base.
Enlace y seguimiento de requisitos Un buen sistema de requisitos no solo debe ser capaz de proporcionar un medio de
clasificación de cualquier tipo de requisito, sino que también debe ser capaz de enlazar los
requisitos de varios tipos. El enlace de requisitos proporciona los mecanismos para informes
de seguimiento .
Un buen sistema de requisitos no solo debe ser capaz de proporcionar un medio de clasificación de cualquier tipo de requisito, sino que también debe ser capaz de enlazar los requisitos de varios tipos.
11www.microfocus.com
Enlace de requisitos
Debe existir una funcionalidad para crear relaciones entre tipos de requisitos. Los enlaces
que expresan estas relaciones deben ser de uno a muchos, de muchos a uno o de muchos a
muchos. Por ejemplo, puede haber varios casos de prueba para un único requisito funcional,
pero un caso de prueba se puede aplicar a más de un requisito funcional.
Enlaces manuales
La solución debe proporcionar la capacidad para establecer enlaces manualmente o
mediante un formulario de importación por lotes.
Enlaces suprimidos
Los objetos enlazados deben informar del impacto del cambio
Los objetos enlazados deben mostrar el impacto de los cambios ascendentes. Por ejemplo,
dado un caso de prueba enlazado a un requisito funcional que está enlazado a un requisito
del usuario, un cambio en el requisito del usuario supondrá un posible impacto y, por lo
tanto, obligará a la revisión del requisito funcional y del caso de prueba. Un cambio en
el requisito funcional obligará a la revisión del caso de prueba, pero no del requisito del
usuario .
Matriz de seguimiento
Debe haber disponible una matriz de seguimiento completa que utilice cualquier tipo
de requisito definido y que sea relativamente fácil de usar. El seguimiento visualiza las
conexiones entre los requisitos, permitiendo a los participantes ver que los requisitos
del usuario se han detallado a través de requisitos funcionales asociados y que se han
establecido casos de prueba para cada requisito funcional. La matriz de seguimiento debe
informar del cumplimiento, y durante la vida de la aplicación, debe informar del impacto
del cambio .
Debe haber una excelente funcionalidad de informes La solución debe facilitar un buen informe y debe ser posible generar documentos con un
formato con el que los participantes estén totalmente familiarizados. Resulta fundamental
mantener informes actualizados para el proceso de gestión de requisitos y la creación de
dichos informes debe ser una extensión simple del filtrado y ordenación de la interfaz del
cliente .
Resulta fundamental mantener informes actualizados para el proceso de gestión de requisitos y la creación de dichos informes debe ser una extensión simple del filtrado y ordenación de la interfaz del cliente.
Admisión flexible de documentos
Debe ser posible seleccionar listas de requisitos mediante guiones o consultas y utilizar
fácilmente esas listas para crear o actualizar un documento.
Documentos de control de versiones
Debe ser posible bloquear el contenido de un documento y asignarle al documento
bloqueado un nombre o versión. También debe ser posible suprimir dichos documentos
libremente .
Requisitos que se pueden publicar en formato de documento
Debe ser posible exportar (publicar) documentos con un formato (plantilla) que sea familiar
y que se pueda compartir entre los proyectos .
Facilidad para comparar documentos
La solución debe proporcionar la capacidad para comparar versiones de documentos.
Informes gráficos
Debe ser posible crear informes gráficos o recopilar y exportar los datos necesarios para
crear los informes con las herramientas existentes actuales. Los informes deben incluir,
entre otros, gráficos de barras que muestren los requisitos programados por tipo, número
programado para una versión con nombre y número, que se va a implementar.
Los informes deben incluir, entre otros, gráficos de barras que muestren los requisitos programados por tipo, número programado para una versión con nombre y número, que se va a implementar.
13www.microfocus.com
Resumen
Para algunas organizaciones es difícil dar forma a la disciplina de gestión de requisitos,
y por ello, los grupos suelen sobrecargar el proceso en detrimento del proyecto . Los equipos
de proyecto suelen pasar más tiempo discutiendo acerca de la adecuada estructura del caso
de uso o la diferencia entre un usuario y un requisito empresarial que acerca del contenido
de cualquiera de ellos. Puesto que dichos argumentos no hacen avanzar el proyecto, los
miembros del equipo continuarán y asumirán que las preguntas abiertas se abordarán
durante el desarrollo .
El proceso de gestión de requisitos es esencial para las mejores prácticas de desarrollo de
aplicaciones. Sin el conocimiento de lo que se supone que se va desarrollar, la probabilidad
de que coincida con la necesidad empresarial es casi nula . La gestión de requisitos puede
comenzar con una lista en la que se definan y gestionen las expectativas del proyecto. La lista
se puede visualizar como una pizarra abierta, que recopile y ordene las notas y los cambios.
También puede expandirse al detalle técnico de control y enlazar el detalle a los casos de
prueba, que en última instancia admitirá capacidades completas de informes de requisitos.
Las mejores soluciones de gestión de requisitos son fáciles de aprender, fáciles de usar,
accesibles y transparentes. Además cuentan con excelentes funcionalidades de seguimiento
y creación de versiones e informes. Estas funcionalidades funcionan conjuntamente
para proporcionar la base de una solución de prestigio mundial y el inicio de un proceso
requisitos de mejores prácticas .
Las mejores soluciones de gestión de requisitos son fáciles de aprender, fáciles de usar, accesibles y transparentes.
www.microfocus.com
Panamá +507 2 039291
Micro Focus Sedes corporativas Reino Unido +44 (0) 1635 565200