Mejores prácticas de ingeniería de requisitos Julio de 2015 Kevin Parker, vicepresidente de marketing mundial de Serena Software (ahora parte de Micro Focus ® ) Informe oficial
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