se utiliza en los blogs, pero no en el banner superior de la página del blog ni en la sección dedicada a la marca.
Aprenda a gestionar de forma eficiente los controles de diseño de dispositivos médicos con Modern Requirements. Optimice el cumplimiento normativo, los procesos y las necesidades reglamentarias.
Continuar leyendo
¿Qué es Modern Requirements4DevOps? Sigue leyendo para descubrir cómo funciona Modern Requirements4DevOps: qué problemas puede ayudarte a resolver y quién lo utiliza, además de un recorrido por sus funciones, precios e integraciones.
También explicaré en qué se diferencia Modern Requirements4DevOps de otras herramientas similares.
Lee el artículo completo en Digital Project Manager.
Fácil de usar, ciclos cortos, posibilidad de redactar requisitos en línea, informes de cumplimiento y reducción de las revisiones en el desarrollo. Estas son solo algunas de las expresiones que han utilizado nuestros clientes para describir las capacidades de varios módulos de la aplicación Modern Requirements4DevOps. En nuestra versión de 2020 se han incorporado nuevas funciones y mejoras a los módulos.
A continuación, compartiremos algunas de las novedades más destacadas que se han incorporado a varios de nuestros módulos de Modern Requirements, así como algunas mejoras en las herramientas para su mayor comodidad. Los módulos que vamos a presentar son:
1. Gestión de derechos: Nos lo pedisteis y os hemos escuchado. Ahora podéis gestionar el acceso de los usuarios. Un usuario (que debe tener derechos de administrador de la colección o del proyecto) puede gestionar el acceso de los usuarios a ambos módulos de Modern Requirements4DevOps, así como a las funciones de cada módulo. Configurar estos permisos es muy sencillo... Estos son los pasos para configurar los permisos:
Esto es lo que verás:
Desde esta pantalla, podrás configurar lospermisos de*Grupo y/o*Equipo (situados en el panel izquierdo). Hay dos formas de configurar los permisos: puedes hacerlo en «*Configuración general» o de forma individual dentro de «*Módulos Modern Requirements4DevOps» (situados en el panel derecho de la pestaña de permisos). Aquí puedes configurar los permisos para las funciones de cada módulo.
Las opciones de permisos disponibles son:
Actualmente, la gestión de derechos es compatible con tres módulos: Smart Docs,Baseline yReporting.
Para obtener más información sobre las novedades de la gestión de derechos y sus funciones, consulte el vídeo.
2. Mejoras en el módulo «Revisión»: El módulo «Revisión» te permite comunicarte, revisar y aprobar dentro del entorno del proyecto, así como facilitar los cambios cuando sea necesario. Se han introducido mejoras en el módulo «Revisión». A continuación, te presentamos una lista de algunas de las nuevas funciones:
Derechos de solo lectura para quienes no participan en la revisión: gracias a esta mejora, ahora puedes configurar los derechos de quienes no participan en la revisión para que puedan ver los detalles de la misma en modo de solo lectura.
Usuarios no participantes:usuarios que no son ni los responsables de la aprobación ni los revisores.
Generación automática y masiva de informes de auditoría de revisiones: esta mejora te permitirá generar informes de auditoría de todas las revisiones de un proyecto de una sola vez, ya sea de forma masiva o por proyectos, desde el panel de administración.
Aquí puede seleccionar uno o varios proyectos e introducir los datos necesarios para generar automáticamente los informes de auditoría de sus revisiones existentes
Formato de los informes de auditoría – Word/PDF: El sistema ahora te permite seleccionar el formato en el que deseas generar los informes de auditoría. Puedes elegir entre la versión en Word o en PDF.
El objetivo del informe de auditoría de aprobación es proporcionar detalles sobre todas las tareas de una revisión. Ofrece información completa sobre quién ha aprobado o rechazado las tareas de la revisión, junto con los comentarios y las decisiones.
Para obtener más información sobre las novedades de Review Management y sus funciones, consulte el vídeo.
3. Mejoras en Smart Docs: Smart Docs es una herramienta que tiende un puente entre la gestión de documentos y la gestión de la información, permitiendo redactar los requisitos en una vista de documento en línea. Se han añadido nuevas funciones a Smart Docs; a continuación se destacan algunas de las más importantes:
Compatibilidad con pantalla completa: Para disfrutar de una mejor experiencia de usuario y una visualización más amplia, ahora puedes ver los Smart Docs en modo de pantalla completa. Esto te permite una mejor visualización a la hora de crear tus documentos de requisitos en línea.
Actualización de la interfaz de usuario del panel derecho:
Actualización de la herencia de propiedades del elemento superior: Se trata de una actualización con la que, de forma predeterminada, la casilla de verificación para heredar las propiedades del elemento superior en el elemento secundario aparecerá «desmarcada».
Nota: Si no se selecciona ninguna propiedad en el menú desplegable, no se heredará ninguna propiedad en el elemento de trabajo secundario.
Para obtener más información sobre las novedades de Smart Docs y sus funciones, consulte el vídeo.
4. Mejoras en Smart Reports: Smart Report permite a los usuarios dar formato a sus informes según la estructura de las tareas. Se puede acceder a él desde muchos de los módulos de ADO y Modern Requirements4DevOps. A continuación se incluye una lista de algunas de las mejoras introducidas en el módulo Smart Report:
Cargar plantillas de Word con macros: Smart Report ahora te permite cargar y ejecutar documentos de Word con macros (.docm), así como plantillas de Word con macros (.dotm), en Smart Report a través de la opción «Cargar plantilla de Word». Esto hará que la ya de por sí sencilla opción de cargar plantillas de Word resulte aún más fácil.
Conservar la selección de la última plantilla de Word cargada: ¿Sabías que...? Smart rReport ahora es aún más inteligente: conservará la última selección que hayas realizado al cargar tu plantilla de Word.
Conservar la selección de la última pieza inteligente: Bueno, no nos hemos limitado a recordar la última selección de la plantilla de texto... Se han introducido mejoras para que el sistema conserve ahora también la selección de la última pieza inteligente del informe. Sin duda, es todo ventajas para los creadores de informes.
Para obtener más información sobre las novedades de Smart Reports y sus funciones, consulte el vídeo.
5. Mejoras en Baseline: Baseline te permite crear una instantánea de tus requisitos en un momento determinado para facilitar el control y el seguimiento de los cambios. A continuación te explicamos cómo mejorará aún más tu experiencia de trabajo:
Mantener la selección del elemento de trabajo al cambiar de pestaña: ahora el sistema recordará la última selección de elemento de trabajo al navegar entre las diferentes pestañas dentro de una línea de base. ¿Qué significa esto? Pues bien, mientras trabajas con una línea de base (especialmente si es grande), ve a la pestaña «Comparar» o «Detalles» y vuelve a la pestaña «Ver» si has olvidado con qué elemento de trabajo estabas trabajando… Ya no tienes que preocuparte, porque el sistema lo recordará por ti.
ID de comparación en la comparación de líneas de base: Se han introducido mejoras para que ahora puedas ver las revisiones de los elementos de trabajo solo cuando estos existan en ambas líneas de base que se están comparando. Por ejemplo: si un elemento de trabajo no existe en una de las líneas de base, no se mostrará ningún ID de revisión, sino que aparecerá un «-» en la columna «Rev.ID» o «Comp.Rev.ID». Esta regla también se aplicará en el informe de diferencias.
Para obtener más información sobre las novedades de Baseline y sus funciones, consulte el vídeo.
6. MatCal (Novedad): Se ha incorporado una nueva función a Modern Requirements que permite realizar expresiones matemáticas y lógicas. ¿Te parece interesante? A nosotros nos encanta. Y este es el motivo:
Lo que debe hacer: facilite sus fórmulas a un miembro del equipo de Éxito del Cliente de Modern Requirements y estaremos encantados de configurarlas por usted.
Para obtener más información sobre MatCal y sus funciones, consulte el vídeo.
¡Nos complace anunciar que «Modern Requirements4DevOps 2020» ya está disponible para su descarga!
La gestión de derechos es una nueva función de la versión MR2020 que permite controlar el acceso de los usuarios. El administrador del proyecto puede conceder o denegar a un grupo de usuarios el acceso a un módulo de MR y a sus funcionalidades. Actualmente, la gestión de derechos está disponible para tres módulos de MR: Smart Docs, Baseline y Reporting.
Los permisos flexibles y personalizables permiten a los equipos de proyecto mantener el equilibrio adecuado entre colaboración y control.
Cada vez que se produzca un cambio en los permisos, este afectará inmediatamente a todos los equipos o grupos de usuarios a los que se hayan asignado dichos permisos. Esto garantiza que la configuración de los permisos se pueda actualizar y mantener fácilmente a medida que avanzan los proyectos y los equipos cambian de funciones.
Se puede acceder a la gestión de derechos desde la extensión Modern Requirements4DevOps, en la sección «Configuración del proyecto».
Las funciones disponibles para las que puedes configurar permisos varían de un módulo a otro.
Las funciones de grupo disponibles son las siguientes:
Por lo general, hay tres tipos de permisos de acceso entre los que elegir para cada función de grupo:
«Permitir»
«Negar»
«Sin definir»
Los equipos y grupos pueden heredar automáticamente la configuración de permisos de los equipos y grupos principales. La configuración de permisos modificada explícitamente en los equipos y grupos secundarios puede anular los permisos heredados de los equipos y grupos principales. Ten en cuenta las siguientes reglas:
Cuando un mismo usuario forma parte de más de un equipo o grupo, se aplican las siguientes reglas:
MatCal es una función de Modern Requirement4DevOps que se utiliza para realizar expresiones matemáticas y lógicas en elementos de trabajo.
¡Para gestionar las relaciones entre las propiedades de los elementos de trabajo de una forma más inteligente! Elimina el trabajo manual que supone realizar los cálculos fuera del entorno del proyecto y evita el riesgo de introducir resultados incorrectos en tus proyectos.
Veamos un ejemplo sencillo para ilustrar la relación entre las propiedades de un elemento de trabajo.
Business Value and Priority are properties of work item Feature. Normally, high Business Value leads to high Priority.
With the right configuration, MatCal could help you manage the relationship by automatically assigning Priority value based on the Business Value input.
Escenario 1: Nivel de integridad de seguridad en automoción (ASIL) según la norma ISO 26262
Escenario 2: La calificación de riesgo se asigna automáticamente en función de la puntuación de gravedad y la puntuación de frecuencia
Escenario 3: La clasificación de prioridad se asigna automáticamente en función de la puntuación de gravedad y la puntuación de probabilidad
Verification checks a product against its requirements; validation checks it...
A use case describes how a user interacts with a...
Traceability in Azure DevOps links work items to code and...
Azure DevOps es una plataforma increíble que ofrece una única fuente de información fiable.
Para muchos equipos, esa afirmación por sí sola basta para plantearse utilizar la plataforma ALM líder en el mundo para la gestión de sus requisitos. La posibilidad de vincular las tareas de desarrollo a los requisitos, y estos a los casos de prueba, es una ventaja difícil de dejar pasar.
Pero, ¿y si no necesitas todas las funciones de una plataforma ALM completa?
¿Y si solo necesitas una solución para gestionar tus requisitos?
Puede aprovechar todas las completas funciones de Modern Requirements4DevOps para convertir su proyecto de Azure DevOps en una solución de gestión de requisitos con todas las prestaciones. Una de estas funciones es la posibilidad de reutilizar requisitos en diferentes proyectos, colecciones y servidores mediante la herramienta de reutilización de Modern Requirements4DevOps.
¿Quieres reutilizar requisitos?
Estás en el lugar adecuado.
Lo que aprenderás en este breve artículo:
Cuando hablamos de las ventajas de la reutilización de requisitos, hay un aspecto que debemos abordar en primer lugar.
La pregunta que más me hacen los equipos de hardware es: «¿Cómo podría esto beneficiar a equipos que no se dedican al software?».
Antes de empezar, hay que decir que la reutilización de requisitos no es algo exclusivo de los equipos de desarrollo de software.
La reutilización de requisitos es un tema que suele llamar la atención.
Esto se debe a que, en la economía mundial, vemos cómo las empresas se centran en determinados ámbitos o sectores dentro de unas industrias concretas. Esto lleva a que las empresas desarrollen productos dentro de un ámbito específico, o en torno a una solución concreta, y se centren realmente en las pocas cosas en las que pueden tener verdadero éxito.
Esto significa que, al desarrollar proyectos, soluciones o sistemas, a menudo un equipo puede reutilizar elementos de un proyecto anterior. Aquí es donde entra en juego la reutilización de requisitos.
Al permitir que un equipo reutilice esos requisitos en el siguiente proyecto, se consigue reducir la carga de trabajo necesaria para poner en marcha un nuevo proyecto.
Para algunas personas, esto quizá ya sea obvio.
Sin embargo, lo que quizá no resulte tan evidente es que la reutilización también puede ser una excelente forma de gestionar los requisitos cuyo alcance trasciende el ámbito del proyecto. Esto incluiría los requisitos no funcionales o los riesgos que deben tenerse en cuenta como una exigencia a nivel de toda la empresa. Esto llegaría incluso a permitir que tu equipo reutilice requisitos cuyo propósito sea estrictamente normativo o centrado en el cumplimiento. Esta funcionalidad puede extenderse tanto a equipos de software como de hardware, e incluso puede ayudar a equipos de producto dedicados a un componente físico o a un entregable.
Reutilizar requisitos por referencia es una forma rápida de incorporar requisitos ya existentes a tu proyecto simplemente creando vínculos con ellos. De este modo, podrás acceder directamente a esos elementos de trabajo y revisar todo el contenido, los enlaces y los archivos adjuntos asociados sin necesidad de copiarlos dentro del proyecto ni entre proyectos.
En Azure DevOps, las funciones para copiar requisitos u otros elementos de trabajo de un proyecto a otro son muy limitadas. Sin embargo, al añadir Modern Requirements4DevOps a tu entorno de Azure DevOps, la reutilización de requisitos alcanza todo su potencial.
Al analizar la reutilización de requisitos mediante copia, hay tres enfoques principales que hay que tener en cuenta.
Tras ver los vídeos anteriores, resulta evidente que la herramienta Modern Requirements4DevOps Reuse es eficaz para reutilizar requisitos.
Ofrece un control total sobre los requisitos que se desean reutilizar, permite personalizarlos y vincularlos al elemento de trabajo de origen.
Esto significa que, independientemente de dónde quieras enviar los requisitos, puedes hacerlo utilizando la herramienta Modern Requirements4DevOps Reuse. Sin embargo, hay algunas formas de utilizar la herramienta Reuse de manera más eficaz.
Lo primero que cabe destacar es la combinación de la herramienta de reutilización con la herramienta «Modern Requirements4DevOps Baseline».
¿Qué es una línea de base?
Muchos equipos utilizan líneas de base de requisitos sin siquiera darse cuenta.
Una línea de base es una instantánea de los elementos de trabajo en un momento determinado.
Muchos equipos utilizan simplemente las versiones de los documentos de Microsoft Word como línea de base.
Cuando se trata de registrar los requisitos en un momento determinado, hay muchas razones por las que la función Modern Requirements4DevOps es mejor que el método tradicional de Microsoft Word. Con las líneas de referencia de Modern Requirements4DevOps, puedes registrar un conjunto de elementos de trabajo tal y como estaban en cualquier fecha que elijas.
Esto significa que, si quieres registrar tus requisitos tal y como estaban hace dos semanas, puedes crear fácilmente una línea de base para esos requisitos en esa fecha. Esto se traduce directamente en las ventajas de la herramienta de reutilización incorporada por Modern Requirements4DevOps.
Al combinar la herramienta «Reutilizar» con nuestra línea de base, no solo podrás seleccionar el conjunto de requisitos que deseas reutilizar, sino también la versión de dichos requisitos. Esto te permite trasladar la versión más adecuada y relevante de tus requisitos a tu próximo proyecto.
Otra recomendación importante es utilizar eficazmente el prefijo, el sufijo y otras operaciones al reutilizar los requisitos.
Al reutilizar requisitos, la herramienta Modern Requirements4DevOps Reuse te permite personalizar el aspecto que tendrán los requisitos reutilizados en el proyecto de destino.
A continuación se muestra la pantalla que te permite hacer esto:
El uso de esta función te permitirá añadir fácilmente un prefijo o un sufijo a los requisitos una vez que lleguen al proyecto de destino que hayas elegido. Como se ha visto anteriormente, también puedes optar por enviar estos requisitos a una ruta de área específica (como «hardware» o «software», por ejemplo), o incluso a una iteración determinada, para que puedas decidir cuándo se gestionarán dichos requisitos.
Sin embargo, la función más utilizada en las opciones de campo es la posibilidad de añadir una etiqueta.
A menudo, cuando se envían requisitos de un proyecto a otro, se desea poder identificarlos y rastrearlos fácilmente en el proyecto de destino. Añadir una etiqueta te permitirá hacerlo.
¿Cuál es la relación con la opción «Source Work Item»?
Esta opción te permite establecer un vínculo entre el elemento de trabajo que estás reutilizando y el elemento de trabajo que creas en tu proyecto de destino.
¿Qué enlace se crea?
Este enlace vincula tu nuevo elemento de trabajo de destino con el elemento de trabajo original a través del enlace «Relacionado» o cualquier otro tipo de enlace que hayas configurado en el área de administración.
En la imagen siguiente puedes ver un caso de prueba que he copiado de un proyecto a otro, utilizando tanto el prefijo «CL- » como la opción «Enlazar con el elemento de trabajo de origen».
Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from. While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead.
Baseline es una herramienta muy útil, tanto si deseas reutilizar un único elemento de trabajo como una larga lista de elementos de trabajo de tu proyecto o biblioteca de origen. En Modern Requirements, puedes crear vínculos entre tu fuente y los elementos de trabajo copiados, de modo que puedas localizar el origen de dichos elementos.
Aunque existan vínculos entre ellos, los elementos de trabajo copiados se siguen considerando independientes de los elementos de trabajo originales, lo que significa que cualquier cambio que realices en los elementos de trabajo copiados o en los originales no afectará a su homólogo.
Quizás te preguntes: ¿cómo sincronizar los cambios cuando sea necesario? Supongamos que tienes una biblioteca en la que se guardan todos tus elementos de trabajo de especificaciones de diseño y que los has reutilizado en 5 proyectos diferentes. Si ahora tienes que modificar algunos diseños de la biblioteca y quieres que todas las especificaciones de diseño copiadas se sincronicen, solo tienes que utilizar la función «Combinar», que se encuentra en «Líneas de base de origen copiadas» o «Líneas de base de destino copiadas» en la pestaña «Detalles» del módulo «Líneas de base».
Baseline es una herramienta muy útil, tanto si deseas reutilizar un único elemento de trabajo como una larga lista de elementos de trabajo de tu proyecto o biblioteca de origen. En Modern Requirements, puedes crear vínculos entre tu fuente y los elementos de trabajo copiados, de modo que puedas localizar el origen de dichos elementos.
Aunque existan vínculos entre ellos, los elementos de trabajo copiados se siguen considerando independientes de los elementos de trabajo originales, lo que significa que cualquier cambio que realices en los elementos de trabajo copiados o en los originales no afectará a su homólogo.
Quizás te preguntes: ¿cómo sincronizar los cambios cuando sea necesario? Supongamos que tienes una biblioteca en la que se guardan todos tus elementos de trabajo de especificaciones de diseño y que los has reutilizado en 5 proyectos diferentes. Si ahora tienes que modificar algunos diseños de la biblioteca y quieres que todas las especificaciones de diseño copiadas se sincronicen, solo tienes que utilizar la función «Combinar», que se encuentra en «Líneas de base de origen copiadas» o «Líneas de base de destino copiadas» en la pestaña «Detalles» del módulo «Líneas de base».
¿Recuerdas aún la definición de una línea de base? Es una instantánea de determinados elementos de trabajo en un momento dado. Por lo tanto, independientemente de los cambios que hayamos realizado en los elementos de trabajo incluidos en la línea de base, la instantánea guardada no cambiará. Así pues, aunque hayamos fusionado las líneas de base, los cambios se aplican a las últimas versiones de los elementos de trabajo, no a las propias líneas de base. ¿Te parece un poco difícil de entender?
Por favor, vea el vídeo de 5 minutos titulado «Fusionar líneas de base copiadas».
Prueba hoy mismo Modern Requirements4DevOps de forma gratuita.
Te ofrecemos la posibilidad de probar nuestra solución de gestión de requisitos en tu propio entorno de Azure DevOps o en un entorno que te proporcionamos y que incluye datos de ejemplo.
Verification checks a product against its requirements; validation checks it...
A use case describes how a user interacts with a...
Traceability in Azure DevOps links work items to code and...
Al migrar a Azure DevOps, o cuando trabajas sin conexión lejos de tu proyecto actual de Azure DevOps, necesitas una forma de importar los requisitos que acabas de crear a Azure DevOps.
Muchos equipos se enfrentan al problema de cómo incorporar a Azure DevOps los requisitos que han creado en Excel, Word y otras aplicaciones. Por suerte, hay varias formas sencillas de hacerlo sin tener que preocuparse por añadir una larga sesión de copiar y pegar a tu proceso.
En este artículo, veremos varias formas de importar requisitos.
Una de estas opciones es gratuita, y otras son funciones que se obtienen al añadir Modern Requirements4DevOps a tu proyecto de Azure DevOps.
Los temas que se tratan en este artículo son los siguientes:
Tanto si tienes todos o algunos de tus requisitos actuales en Excel, como si deseas exportar requisitos desde una herramienta interna a un archivo .csv, existe una forma gratuita de importar tus requisitos a tu proyecto de Azure DevOps.
Esta es una solución gratuita, siempre y cuando ya dispongas de Azure DevOps y Excel.
El primer paso es asegurarte de que tienes instalado el complemento de Microsoft Excel llamado «Team tab».
Puedes descargar este complemento directamente desde aquí:
(En la página mencionada, Azure DevOps Office® Integration 2019 aparece en la sección «Otras herramientas, marcos y componentes redistribuibles»).
Si has hecho clic en el enlace anterior, podrás activar la pestaña «Equipo» de Excel.
Cuando está habilitada, esta extensión te permite vincular una hoja de Excel directamente a un proyecto concreto de tu organización de Azure DevOps.
Al habilitar esta función, tendrás a tu disposición dos funciones principales:
1) Podrás publicar requisitos entu proyecto desde Excel
2) Podrás exportar requisitos detu proyecto aExcel
Esto significa que puedes trabajar en tus requisitos desde cualquiera de las dos interfaces y aplicar los cambios a tu proyecto. Es decir, si importas los requisitos a Excel y realizas cambios, puedes publicar esos cambios y aplicarlos a los requisitos de tu proyecto.
Una vez que hayas ejecutado el instalador que has descargado, ya podrás activar la extensión.
Cómo activar la pestaña «Equipo»en Excel:
En este vídeo, explicamos cómo tu equipo puede utilizar las funciones de importación que ofrece el complemento de la pestaña «Equipo» de Excel.
La segunda forma de importar requisitos a tu proyecto es a través de Microsoft Word.
Esta función es una «función de vista previa» disponible con cualquier licencia Enterprise Plus de Modern Requirements4DevOps. Esto significa que cualquier usuario de su organización que cuente con una licencia Enterprise Plus podrá acceder a la función de importación de Word y utilizarla.
Si aún no utilizas Modern Requirements4DevOps, ¡prueba hoy mismo esta función de importación de Word!
¿Cómo funciona la importación de Word?
Advertencia: al tratarse de una función en fase de prueba, es posible que esta no sea la solución más elegante y que, por lo general, requiera algunos conocimientos de programación. Pero no muchos: si puedes pedirle ayuda a un desarrollador que conozca XML (o cualquier otro lenguaje de scripting) durante unos 20 minutos, no deberías tener ningún problema.
La importación de Word funciona a partir de un documento de Word bien formateado que utiliza diferentes encabezados para representar los distintos elementos de trabajo o requisitos y sus propiedades en el documento.
Por ejemplo, tomemos como ejemplo un documento de requisitos de negocio (BRD) que quizá ya tengas en formato Word.
Probablemente hayas aplicado el estilo «Título 1» a la introducción, la descripción general, el alcance y otros elementos contextuales.
También podrías incluir en este documento tus épicas, funcionalidades e historias de usuario.Tu documento podría tener este aspecto:
Título 1 – Introducción
-> Párrafo –Aquí va todo el texto de la Introducción…
Título 1 – Resumen
-> Párrafo –Aquí va todo el texto del resumen…
Título 1 – Ámbito de aplicación
-> Párrafo –Aquí va todo el texto del ámbito de aplicación…
Título 1 – Requisitos
-> Título 2 – Nombre de la épica
–> Título 3 – Nombre de la funcionalidad
—> Título 4 – Nombre de la historia de usuario
—-> Párrafo – Descripción de la historia de usuario anterior
Es posible que tu documento sea un poco diferente, pero no pasa nada.Los principios que estás a punto de aprender son los mismos.
La importación de Word requiere un documento (como se muestra arriba) y un conjunto de reglas (que se explica a continuación).
Por lo general, un administrador creará un conjunto de reglas que tu equipo utilizará para importar documentos, y solo habrá que hacerlo una vez.Así que, si ya tienes un documento creado y tu administrador ha creado un conjunto de reglas, ya estás listo para empezar.
Si tu administrador necesita crear un conjunto de reglas, sigue leyendo.
Crear un conjunto de reglas es increíblemente sencillo y se hace editando un archivo XML.
El archivo XML que crees determinará cómo la herramienta de importación de Word analiza tu documento para:
1) ¿Qué partes del documento son elementos de trabajo?
2) ¿Qué partes del documento son propiedades de un elemento de trabajo determinado?
Si estás trabajando en esto en tiempo real, te puede resultar útil descargar este archivo de reglas como punto de partida y ver el siguiente vídeo:
En este vídeo, explicamos cómo utilizar el archivo de conjunto de reglas de ejemplo para importar un documento de requisitos sencillo. Recuerda que la creación de un conjunto de reglas suele ser un proceso que solo hay que realizar una vez.
Los diagramas, las maquetas y los modelos de casos de uso pueden ser herramientas muy útiles para definir y recabar requisitos.
Por eso, con Modern Requirements4DevOps, tu equipo puede crear fácilmente todas estas visualizaciones directamente desde tu proyecto. Esto te permite beneficiarte de un modelo de «fuente única de verdad» en el que todo está integrado en tu proyecto.
Pero quizá ya tengas diagramas y maquetas que te gustaría añadir a tu proyecto de Azure DevOps y vincular a los requisitos. ¿Es posible importar estos recursos?
La respuesta es sí.
Tanto nuestra herramienta de maquetas como nuestra herramienta de diagramas te permitirán incorporar fácilmente maquetas o diagramas existentes a tu proyecto de Azure DevOps.
Para ello, solo tienes que guardar el recurso como un archivo .png o .jpeg desde la herramienta de maquetas o diagramas que hayas elegido.
A continuación, puedes subir el recurso creado a la herramienta de simulación de Modern Requirements4DevOps (maquetas)o ala herramienta de diagramas (diagramas).
Quizá te preguntes: «Pero si lo subimos como .png o .jpeg, ¿cómo podremos editar nuestros diagramas y maquetas?». Pues bien, no podrás. Pero hay una razón por la que deberías hacerlo de todos modos.
Si quieres vincular un único diagrama a 25 requisitos sin utilizar Modern Requirements, tendrás que abrir los 25 requisitos y vincularlos a cada uno de ellos por separado.
Cuando actualices tu diagrama en el futuro, tendrás que volver a abrir los 25 requisitos y cambiar el archivo adjunto.
Sin embargo, con Modern Requirements4DevOps, puedes crear un elemento de trabajo de diagrama al que vincular directamente todos los requisitos necesarios mediante el panel de la derecha. Esto significa que podrás tener tu diagrama en un solo lugar y, cuando sea necesario actualizarlo, podrás añadir fácilmente la imagen actualizada y vincular el archivo adjunto a ese único elemento de trabajo.
En este artículo hemos explicado tres formas distintas de importar tanto los requisitos como sus activos a tu proyecto de Azure DevOps.
Puedes importar requisitos a través de Excel o Word, o importar tus diagramas y maquetas existentes.
Si te interesa utilizar Modern Requirements4DevOps para optimizar tu proceso de gestión de requisitos, ¡prueba nuestro producto aquí!
En este artículo repasamos las características y ventajas del módulo de preguntas frecuentes.
Este módulo se ha diseñado para ayudar a los equipos que recopilan requisitos al inicio de su proceso de gestión de requisitos. Al crear listas de preguntas, los equipos pueden recopilar y reutilizar fácilmente sus conocimientos sobre el proceso de obtención de requisitos para formular las preguntas adecuadas que permitan obtener los mejores requisitos.
El módulo de preguntas frecuentes es un repositorio de listas de preguntas que tu equipo puede crear, editar, modificar, convertir en plantillas y utilizar para recabar requisitos. Al utilizar el módulo de preguntas frecuentes para crear una base de conocimientos para tu equipo, tendrás la seguridad de que cualquier miembro del equipo podrá interactuar con las partes interesadas de manera eficaz.
Al elaborar el mejor conjunto de preguntas en ese ámbito, tu equipo podrá asegurarse de que siempre recaba el mejor conjunto posible de requisitos.
La principal ventaja de este módulo es que ofrece a tu equipo la oportunidad de crear una base de conocimientos que pueden utilizar tanto los analistas de negocios con experiencia como aquellos que puedan necesitar recabar requisitos en un ámbito que no les resulte familiar. El módulo de preguntas frecuentes ya incluye más de 3000 preguntas que abarcan una gran variedad de temas.
Entre estos temas se incluyen varias plantillas de cumplimiento de normas ISO, así como plantillas sobre requisitos no funcionales, como la escalabilidad, la reutilización o la operatividad, que pueden utilizarse para la obtención de requisitos.
Para muchos equipos, este módulo sustituirá a las listas de preguntas en Excel que quizá hayan utilizado en el pasado.
Para mantener la coherencia con el resto de módulos del conjunto de herramientas Modern Requirements, el módulo de preguntas frecuentes toma lo que antes era un proceso aislado y lo integra directamente en tu proyecto. Esto significa que tus equipos pueden añadir fácilmente requisitos al proyecto con solo responder a las preguntas de la lista de preguntas frecuentes.
El valor de nuestro módulo de preguntas frecuentes se puede resumir en dos puntos sencillos.
Aprovechando los valiosos conocimientos de los analistas de negocios con experiencia, puedes crear plantillas de preguntas específicas para cada ámbito que ayuden a estructurar el proceso de recopilación de requisitos. Esto significa que puedes enviar a cualquier analista de negocios, independientemente de su nivel de experiencia, a reunirse con una parte interesada y tener la seguridad de que elaborará unos requisitos completos y aplicables.
Al no tener que crear plantillas de preguntas y copiar después los requisitos recopilados en tu herramienta de gestión de requisitos, tu equipo podrá avanzar más rápidamente en el proceso de recopilación. Esto se traduce en más tiempo dedicado a perfeccionar requisitos más precisos y menos tiempo dedicado a copiar y pegar historias de usuario que probablemente requieran más trabajo.
Cuando hablamos con nuestra comunidad sobre el uso que hacen del módulo de preguntas frecuentes, suelen describir cómo este módulo les ha permitido agilizar sus procesos y ha facilitado la gestión de la fase de recopilación de información de los proyectos.
Incluso los equipos que tradicionalmente no utilizan listas de preguntas, una vez que se unen a nuestra comunidad, nos comentan el gran valor añadido que les supone poder reunir los conocimientos de todos los miembros de su equipo en una única lista coherente.
Estos son los casos de uso que hemos observado para el módulo de preguntas frecuentes.
CASO DE USO 1
Actualmente, mi equipo recopila los requisitos al principio y, a partir de ahí, avanza de forma iterativa a lo largo del proyecto. En la fase de recopilación de requisitos utilizamos Excel, pero eso implica que después tenemos que copiar los requisitos a la herramienta que utilizamos habitualmente.
Al ser un equipo que recopila los requisitos desde el principio, esto nos brinda una oportunidad perfecta para utilizar una lista de preguntas diseñada específicamente para ese ámbito. Sin embargo, recurrir a Excel como herramienta para gestionar esta lista de preguntas es sinónimo de un largo proceso de copiar y pegar más adelante.
Los procesos de copiar y pegar suelen ser propensos a errores y llevar mucho tiempo. A menudo, es precisamente durante estos procesos, ya de por sí largos, cuando un miembro del equipo se da cuenta de que se le ha pasado por alto una propiedad de una tarea sobre la que necesita la opinión de las partes interesadas.
En este caso, al utilizar el módulo de preguntas frecuentes, ya dispondrás de la lista de preguntas en tu proyecto de Azure DevOps. Cuando plantees tu pregunta a las partes interesadas, podrás responderla en tu lista de preguntas frecuentes y se creará automáticamente un requisito.
De este modo, podrás abrir directamente ese requisito y plantear cualquier pregunta de seguimiento que te surja mientras sigues hablando con la parte interesada. Esto ahorra tiempo y hace que el proceso de recopilación de requisitos sea más exhaustivo, al tiempo que evita que tu equipo pierda oportunidades de obtener la información adecuada en el momento oportuno.
CASO DE USO 2
Mi equipo trabaja en un ámbito sujeto a normativas y regulaciones, y debemos asegurarnos de que cumplimos con todos los requisitos necesarios para mantener el cumplimiento normativo y la auditabilidad.
Una de las mejores características del módulo de preguntas frecuentes es que permite utilizar muchas de nuestras plantillas prediseñadas relacionadas con el cumplimiento normativo para recabar requisitos. Nuestras plantillas prediseñadas se han creado en colaboración con muchos de nuestros clientes actuales, así como a través de colaboraciones con líderes de opinión en estos ámbitos.
En este caso, los equipos que tengan acceso al módulo de preguntas frecuentes pueden consultar a expertos en la materia y a consultores, y elaborar una lista de preguntas que les ayude a definir todos los requisitos necesarios para cumplir con la normativa. Una vez creadas, estas listas de preguntas pueden reutilizarse en varios proyectos y aplicarse una y otra vez.
El módulo de preguntas frecuentes ofrece ventajas increíbles a los equipos que se encuentran en la fase de definición de requisitos de su proyecto. A continuación se indican algunas formas en las que puede utilizar el módulo para facilitar el éxito del proyecto.
Utiliza las plantillas de listas de preguntas ya preparadas
Cuando los usuarios necesiten una plantilla sobre requisitos no funcionales o sobre temas relacionados con la norma ISO, pueden ponerse en marcha rápidamente utilizando una de nuestras plantillas integradas. Estas plantillas ya incluyen muchas de las preguntas más importantes sobre estos temas. Los usuarios pueden partir de una plantilla prediseñada y eliminar las preguntas que no sean pertinentes o añadir las nuevas que sean necesarias.
Crea tus propias plantillas de listas de preguntas
Si ninguna de nuestras plantillas prediseñadas se ajusta a tus necesidades, los equipos pueden crear fácilmente listas de preguntas desde cero. Al partir de una plantilla en blanco, tu equipo podrá elaborar fácilmente un conjunto completo de preguntas que harán que la recopilación de requisitos sea un proceso sencillo y más eficiente.
Una vez elaborada la lista de preguntas, se puede reutilizar en distintos proyectos para facilitar la fase de recopilación de información en el futuro.
Crea listas de preguntas para los miembros menos experimentados de tu equipo
Al elaborar listas de preguntas, estás ofreciendo una orientación útil a cualquier miembro del equipo que no esté tan familiarizado con un ámbito, una solución o un sistema. Estas listas constituyen, por tanto, una herramienta excelente para orientar a los analistas de negocios noveles, o a los que cuentan con experiencia en otros ámbitos, durante la fase de obtención de requisitos. Los equipos son conscientes de que la calidad de las preguntas que formulamos al inicio de un proyecto se refleja directamente en la calidad de los requisitos que obtenemos.
Al crear listas de preguntas con nuestro módulo de preguntas frecuentes, te aseguras de obtener los requisitos más adecuados desde el primer momento.
ERecopilación, redacción y gestión de requisitos no funcionales (NFR)) puede ser una tarea abrumadora y que requiere mucho tiempo. La mayoría de las personas que lean la frase anterior probablemente estarán de acuerdo.
La creación de un NFR puede ser una tarea difícil y la elaboración de requisitos no funcionales que sean a la vez cuantificables y medibles es un problema con el que hemos visto que muchos equipos tienen dificultades.
Sin embargo, merece la pena el esfuerzo de elaborar unos requisitos no funcionales de calidad.
Los requisitos no funcionales proporcionan a los equipos una herramienta para evaluar el éxito de un proyecto, un proceso o un sistema. Permiten a tu equipo definir criterios cuantificables que sirvan para debatir, analizar y evaluar los distintos aspectos de tu proyecto.
Debido al valor que aportan los requisitos no funcionales (NFR) a un proyecto, es frecuente que los equipos se vean envueltos en procesos largos y complicados para elaborar NFR que, al final del proyecto, resultan apenas significativos o relevantes.
Hoy vamos a cambiar eso.
En este artículo abordamos tanto la importancia de crear NFR, comocómo cómo puedes utilizar algunas herramientas sencillas herramientas y técnicas sencillas para reducir el tiempo necesario para crear creación de NFR.
ÍNDICE
Los requisitos no funcionales proporcionan a tu equipo todos los indicadores de éxito de un producto, proyecto, sistema, proceso o aplicación. Cuando se define un buen requisito no funcional, el equipo no solo podrá determinar si un proyecto tiene éxito, sino que también podrá identificar fácilmente en qué medida el proyecto podría estar lejos de alcanzarlo.
Unos buenos requisitos no funcionales pueden ser fundamentales para el éxito de un proyecto de muchas maneras distintas, más allá de servir como indicador de éxito. Los requisitos no funcionales pueden ayudar a los equipos a comprender los objetivos generales de un proyecto, a alinear los resultados del proyecto con los objetivos empresariales y mucho más.
Basta con decir que unos NFR de calidad pueden contribuir en gran medida al éxito del proyecto y a la forma en que evaluamos ese éxito. Pero eso no significa que sean fáciles de gestionar, recabar o redactar.
Echemos un vistazo a la técnica principal que utilizan hoy en día los equipos para crear mejores requisitos no funcionales más rápidamente.
A la hora de definir los requisitos no funcionales, los equipos utilizan plantillas para crear estas tareas con mayor rapidez y coherencia.
Por definición, una una plantilla es cualquier cosa que sirva de modelo y que otros puedan copiar y reutilizar.
Por lo general, las plantillas se crean como un formato predefinido para un documento, un archivo o, simplemente, como el formato que se puede utilizar para crear cualquier NFR. Una vez implementadas, no es necesario volver a crear el formato que ofrece una plantilla cada vez que se necesita, y los usuarios pueden simplemente seleccionar una plantilla y ponerse manos a la obra rápidamente.
Esnos lleva a la ventaja más ventaja más evidente. de el uso plantillas plantillas.
Las plantillas ahorran tiempo y aumentan la coherencia!
Cuando los equipos empiezan a crear un proceso repetible, suelen recurrir a plantillaspara para eliminar la necesidad de volver a crear constantemente documento o archivo formatoformatos. En su lugar, reutilizar las mismas partes de un documento, archivo o estructura como plantilla permite a tu equipo reducir el trabajo repetido y aprovechar las ventajas de una mayor coherencia.
Mientras el tiempo mientras ahorradoy y la consistencia se incrementan son geniales beneficios directos que las plantillas ofrecen, hay hay muchas beneficios indirectos beneficios indirectos que las plantillas también ofrecen.
La mayor ventaja indirecta del uso de plantillas es la posibilidad de crear un método estructurado y fácil de seguir para elaborar archivos, documentos y requisitos.
Al proporcionar una estructura basada en plantillas, a los usuarios que interactúan con un archivo o documento concreto les resulta más fácil identificar dónde introducir cada dato concreto y qué formato debe tener ese dato.
Este tipo de orientación no solo mejora la precisión del contenido en el que se está trabajando, sino que también reduce el tiempo necesario para la elaboración de los informes de no conformidad, la revisión de documentos y la aprobación de requisitos. Esto se debe, en parte, a que el uso de una plantilla también aumenta la estandarización y la familiaridad con el activo que se está creando.
Las plantillas aportan una doble ventaja en cuanto a la simplicidad de los elementos de trabajo NFR. La creación del elemento de trabajo se simplifica, ya que solo hay que introducir los datos en los campos correspondientes de la plantilla. Además, una vez creado el elemento de trabajo, la plantilla presenta la información de una forma más accesible.
A medida que el proceso se simplifica, también se vuelve más accesible. Esto significa que las plantillas también facilitan la creación de los requisitos no funcionales (NFR) y su documentación a los analistas de negocio noveles o con menos experiencia.
Sin embargo, este debate sobre las plantillas quizá ya haya empezado a dar lugar a cierta ambigüedad.
¿Nos referimos al uso de plantillas para documentos?
¿Nos referimos al uso de plantillas para la creación de informes no financieros?
¿Nos referimos a utilizar plantillas que describan las características de un NFR?
En pocas palabras, sí.
Una plantilla de requisitos no funcionales podría utilizarse en cualquiera de estas áreas para mejorar la redacción, la obtención y la gestión de los requisitos no funcionales.
Una plantilla de NFR puede utilizarse para organizar y gestionar los NFR, ayudar al equipo en la creación de documentos o incluso en la elaboración propiamente dicha de los NFR.
Si buscas un método sencillo para elaborar requisitos no funcionales de alta calidad, ¡echa un vistazo a nuestro artículo «Dos pasos sencillos para crear requisitos no funcionales», que encontrarás aquí!
Independientemente de cómo utilice tu equipo las plantillas para elaborar los requisitos no funcionales, puedes estar seguro de que la elaboración de dichos requisitos ofrece unos resultados extraordinarios y se puede llevar a cabo de forma más rápida y sencilla que nunca.
La identificación de requisitos, o la recopilación de requisitos, nunca ha sido un proceso sencillo.Sin embargo,esalgo con lo que muchas personas se enfrentana diarioen el ámbito laboral.
Por ejemplo, si alguien te pide que crees o termines algo, es posible que le hagas algunas preguntas. ¿Qué debe hacer ese algo (requisito funcional) y cómo debe ser en cuanto a seguridad, usabilidad o accesibilidad (requisito no funcional)?
Un analista de negocios (BA) bien preparado) hará, de manera similar, preguntas diseñadas para desentrañar los requisitos funcionales y no funcionales necesarios de cualquier proyecto, proceso o sistema. Los BA utilizan principalmente las preguntas como medio para interactuar con las partes interesadas. A través de este tipo de estrecha colaboración con las partes interesadas, el BAs crean un foro que ayuda a las partes interesadas a expresar lo que esperan de su producto.
Durante una conversación con un analista de negocios, unparte interesada expresará expresará qué características desea y qué debe hacer su producto (requisitos funcionales) , así como cómo quiere que sea la experiencia del usuario (requisitos no funcionales).
Licenciatura’s suelen emplear varias técnicas de técnicas de obtención de información al interactuar con las partes interesadas. Ddurante el proceso de obtención de información algunas de estas técnicas podrían incluir::
Todas estas técnicas tienen dos cosas en común.
Pensemos en cómo los cuestionarios pueden beneficiarse de convertirse en plantillas o de utilizarlas.
Sabemos que, paradeterminar los requisitos adecuados, hay que plantear las preguntas adecuadas.
Aquí es donde los conocimientos de unanalista de negocios con amplia experienciase convierten en unagran ventaja,yaque ha pasado por el proceso de determinación de requisitos en numerosas ocasiones. Cuenta con la ventaja de la experiencia y puede sabermejorquépreguntas plantear en relación con sectores, productos o tecnologías específicos.
Esta experiencia y estos conocimientos se pueden recopilar fácilmente mediante una plantilla de cuestionario de requisitos no funcionales. Los analistas de negocios con experiencia pueden elaborar listas de preguntas bien pensadas o plantillas de preguntas que se centren en funciones específicas (FR) o en atributos del sistema (NFR), y orientar de forma pasiva guiar al el del equipo , aunque no participen directamente.
Estas plantillas de cuestionario pueden entonces aportan estructura y coherencia al el proceso de obtención de información, garantizar que se formulen las preguntas correctasy además reducire la probabilidad de que se pasen por alto preguntas importantes.
Hay muchos ejemplos en los que las plantillas pueden ayudar a los equipos a aprovechar los conocimientos que ya tienen dentro del equipo.
Veamos más ejemplos de cómo se utilizan las plantillas hoy en día en tareas de obtención de requisitos y creación de contenido ..
Muchos equipos siguen implementar plantilla de requisitos no funcionales plantillaen en forma de tabla para redactar y almacenar los requisitos.
El uso de tablas suele responder a la necesidad de los usuarios de organizar y mantener sus requisitos en un solo lugar. Antes de que se utilizaran herramientas específicas de gestión de requisitos, se utilizaban utilizaban para ayudar definir las convenciones de nomenclatura y numeración, para ayudar a realizar un seguimiento y rastrear los requisitos, así como ayudar mediante proporcionar campos para cualquier número de propiedades.
Las tablas han tenido históricamente funcionadofuncionado tan bien como las plantillas , son son de organizar y facilitan la gestión el contenido de la tabla. Las tablas han tenido tradicionalmente la ventaja añadida de ofrecer un método para exportar la información desde una tabla a otras áreas, como la creación de documentos.
¿En qué consiste ese método de exportación? Copiar y pegar.
Para los equipos que utilizan tablas como plantillas, los rrequisitos normalmente se copian y pegan de una tabla y luego se insertan en un documento. Por lo general, el requisito es copiar y pegar campo por campo campo en una plantilla diseñada específicamente para el documento (¡otro ejemplo de uso de plantillas!).
Sin embargo, aunque las tablas solían ser una solución sólida para gestionar esos requisitos que contienen una variedad de campos, presentan algunos inconvenientes importantes en el mundo actual de las herramientas de gestión de riesgos explícitas.
Las tablas suelen ser recopilaciones inconexas de información importante y puedena menudo quedar aisladas de otras herramientas y procesos. Oa menudo esto da lugar a tablas convertirseen un paso adicional en tu proceso de gestión de riesgos, y un activo adicional del que alguien tiene que hacerse responsable para gestionarlo, actualizarlo y mantenerlo.
Pero no tiene por qué ser así.
Con la extensión «Team» de Excel de Microsoft, los equipos pueden vincular fácilmente las tablas que han utilizado anteriormente con su proyecto de Azure DevOps. Pueden asignar fácilmente cada campo de requisito, propiedad e identificador al elemento de trabajo de Azure DevOps que se crea en su proyecto.
Pero, ¿cómo ayuda Azure DevOps con los requisitos no funcionales?
En primer lugar, Azure DevOps es flexible.
La plataforma ALM de Microsoft te permite añadir fácilmente a un proyecto cualquier tipo de tarea que tu equipo necesite.
Los requisitos no funcionales son solo uno de los tipos de elementos de trabajo que se pueden añadir a un proyecto.
¿Qué es un «elemento de trabajo»? tipo»?
Los elementos de trabajo son plantillas de creación basadas en ADO para el tipo de requisito que representan.
Algunos ejemplos son requisitos funcionales, requisitos de transición, historias de usuario o incluso requisitos no funcionales. Sea cual sea la taxonomía que requiera tu proyecto, Azure DevOps la admitirá y cada uno de los elementos de trabajo que crees tendrá su propio conjunto de propiedades, estados y relaciones que se pueden seleccionar y personalizar.
Con un requisito no funcional, puedes configurar cualquier campos o propiedad que tu equipo necesites para ayudar con la gestión de tu proyecto. Como se ha mencionado anteriormente, plasmar los requisitos que ya tienes en una tabla es sencillo con la extensión de Excel de la pestaña de Microsoft Teams [proporcionar enlace].
Pero, ¿qué se puede hacer con los NFR una vez que están en Azure DevOps (ADO) y en qué beneficia a tu equipo trasladar la creación de los NFR a ADO?
Veamos las herramientas.
La elaboración de documentos depende de las políticas, los procesos, las expectativas y los requisitos de las partes interesadas de una organización, e incluso puede diseñarse para dar cabida a sus requisitos no funcionales.
Los documentos ofrecen una forma sencilla de rendir cuentas para cumplir con los requisitos acordados para un proyecto. Ellos ofrecen un nivel de seguridad a las partes interesadas, ya que los documentos pueden servir de lista de verificación de los requisitos acordados, lo que puede fácilmente compararse para determinar si las partes interesadas están obteniendo lo que han pagado o si el trabajo no se ha completado.
Otra ventaja importante de una documentación adecuada es que los requisitos suelen evolucionar a lo largo del ciclo de vida de un proyecto. Un requisito puede definirse con mayor claridad en una fase posterior, o simplemente puede evolucionar de tal manera que dé lugar a una expectativa diferente respecto a su producto.
Incluye en tu proceso los documentos de requisitos no funcionales.
A medida que cambian los requisitos, tambiéno las expectativas respecto a tu proyecto. Esto significa que los indicadores de éxito de tu proyecto, también conocidos como requisitos no funcionales, tendrán que revisarse y modificarse.
Gracias al módulo Smart Docs de la suite Modern Requirements4DevOps, los usuarios pueden crear fácilmente un documento de requisitos con control de versiones directamente desde su proyecto de Azure DevOps. Esto significa que los usuarios pueden realizar y realizar un seguimiento de los cambios en los requisitos de forma sencilla a través de una interfaz de documentos muy intuitiva.
Los nuevos requisitos pueden también crearse fácilmente en tu proyecto desde la interfaz del documento, o puedes optar por insertar los requisitos existentes directamente entu documento. Esto significa que puedes arrastrar y soltar fácilmente tus requisitos no funcionales directamente en un documento fácilmente exportable sin salir de Azure DevOps y sin necesidad de copiar y pegar.
Ampliemos la idea de importar tus NFR existentes que se encuentran en tablas a Azure DevOps, y luego explicar cómo puedes convertir estos NFR en documentos utilizando Modern Requirements.
En primer lugar, importa a Azure DevOps los requisitos no funcionales de tu tabla mediante la extensión de la pestaña «Microsoft Teams» para Excel. A continuación, solo tienes que consultar todos los requisitos no funcionales y arrastrarlos y soltarlos en tu documento.
Así de sencillo.
Pero supongamos que ahora quieres estructurar un documento de tal manera que los requisitos no funcionales solo se puedan añadir en determinadas secciones del mismo.
¡Nosotros también lo apoyamos!
Hay un diseñador de plantillas integrado directamente en el módulo Smart Docs, que te ayuda a definir qué tipos de elementos de trabajo se permiten y en qué parte de tus documentos. Esto significa que cualquier persona que cree un documento, ya sea basado en NFR o de otro tipo, puede seguir fácilmente la estructura que ofrece su plantilla y crear documentación coherente.
Las plantillas de documentos reutilizables son un gran recurso para cualquier equipo. De hecho, es probable que ya las utilices a diario.
Una plantilla de documento reutilizable proporciona a tu equipo un documento ya rellenado que muestra cómo debe ser el documento final. Este tipo de plantilla ayuda a los autores a determinar fácilmente dónde debe ir cada dato concreto y qué elementos contextuales deben formar parte del documento creado.
Piensa en ese documento de Word que ya tienes en el escritorio. Probablemente ya tenga espacios reservados para secciones como «Introducción», «Ámbito de aplicación» y «Objetivos», así como para los requisitos específicos. Se trata de una plantilla de documento reutilizable.
La principal motivo por el que se utilizan se utilizan eso aumentar la eficiencia y reducir el trabajo de reelaboración en el proceso de elaboración .
Por suerte para los equipos que actualmente utilizan varias aplicaciones para sus procesos de gestión de requisitos y documentación, existe una solución que sirve para ambos: Modern Requirements con Azure DevOps.
El plantillas de documentos que que crees con Modern Requirements + Azure DevOps, se pueden configurar para incluir cualquier campo o propiedadque necesites mostrar en tu documento. Puede guardar cualquier documento como una plantilla de documento reutilizable, que puede rellenar automáticamente campos como Introducción, Objetivos, Requisitos NFR y más.
¡Con solo unos clics podrás crear documentos que ayudarán a tu equipo a ponerse en marcha rápidamente a la hora de elaborar cualquier tipo de documentación! Esto significa que tu equipo no solo se beneficiará de que tus documentos y requisitos se encuentren en un mismo espacio, sino que también aumentar la eficiencia, crear una estructura, mejorar la precisión y lograr coherencia en tu proceso de creación de documentos.
Los requisitos no funcionales son mucho más abstractos que los funcionales.
Esto hace que que sean más difíciles de extraer, ya que no te limitas a señalar el sistema y decirle qué debe hacer, sino que estás haciendo preguntas sobre cómo debería ser el sistema y utilizando los NFR para representarlo.
Como se ha comentado anteriormente en este artículo, la creación de NFR sólidos depende basan en plantear las preguntas adecuadas.
Entonces, ¿qué pasa si eres nuevo en la gestión de requisitos o tienes poca experiencia? ¿Por dónde empiezas? MR4DevOps aborda esta situación con nuestro completo módulo de preguntas frecuentes.
El módulo de preguntas frecuentes es una serie de plantillas de preguntas específicas dirigidas a atributos concretos del sistema, clasificadas según los tres aspectos principales del producto: operativo, de revisión y de transición.
Además, el módulo de preguntas frecuentes contiene plantillas de preguntas para la obtención de requisitos no funcionales (NFR) para el cumplimiento y de riesgo basado el desarrollo de productos sanitarios. A medida que los usuarios responden a las preguntas de laplantilla plantilla, se automáticamente creane un requisito no funcional directamente en el Backlog.
El plantillas plantillas de cuestionario incluidas en el módulo de preguntas frecuentes son útiles para los analistas de negocios con todos los niveles de experiencia. Los analistas de negocios veteranos pueden modificar las listas existentes añadiendo sus propias preguntas o crear su propia lista de preguntas desde cero. De este modo, los analistas de negocios pueden plasmar su experiencia y sus conocimientos sobre el proceso de obtención de requisitos y transmitirlos a otros miembros del equipo.
MR4DevOps ofrece una excelente solución a una de las principales carencias de ADO: la falta de una herramienta de generación de informes integrada.
Si utilizas herramientas como FAQ o Smart Docs para redactar y gestionar tus requisitos no funcionales, Smart Report será la herramienta que utilices para generar tus requisitos. Smart Report te permite generar requisitos en formato PDF, HTML o Microsoft Word, donde podrás aplicar tus propios encabezados y pies de página prediseñados e incluso una tabla de contenidos o una portada.
¿Quieres elaborar un informe sobre los requisitos no funcionales (NFR) de tu proyecto?
La herramienta Smart Report cuenta con un diseñador de plantillas diseñador de plantillas. El diseñador de plantillas te permite crear y guardar plantillas de informes plantillabasadas basadas en el tipo de elemento de trabajo. Esto te permite crear una plantilla de NFR única que muestre las propiedades y los campos de un NFR que desees incluir en el informe; ¡esta información se extrae directamente del elemento de trabajo!
Esta plantilla se puede aplicar a cualquier grupo de NFR seleccionados o extraídos mediante una consulta, y utilizarla siempre que lo requiera su proceso de generación de informes. La ventaja de esta herramienta de generación de informes es que le permite crear informes de requisitos instantáneos, estructuradosy coherentes.
Modern Requirements4DevOps ofrece varias soluciones para ayudar en la obtención, redacción y gestiónde requisitos no funcionales.
¿Te gustaría conocer más a fondo el diseño de plantillas con Modern Requirements o te interesa saber qué otras herramientas pueden mejorar tu proceso? ¡Reserva hoy mismo una demostración del producto!
Comprueba por ti mismo cómo nuestra caja de herramientas «Modern Requirements» puede potenciar Azure DevOps de Microsoft, líder del sector, para convertirlo en una solución única de gestión de requisitos de aplicaciones.
Visita www.modernrequirements.com para obtener más información sobre nuestra empresa y nuestros productos.
Reducción del 50 % en los esfuerzos de UAT
Ahorro del 80 % en tiempo de creación del análisis de trazas.
Reducción significativa de los retrasos en la aprobación
50 % de requisitos de mejora de la productividad
Reducción de 10 veces en la reelaboración del desarrollo
Reducción del 40 % en los esfuerzos de presentación de informes de cumplimiento normativo.
En este artículo, analizaremos cómo documentar los requisitos no funcionales con el objetivo de comprender qué es la documentación y por qué elaboramos documentos.
La documentación es una parte importante del proceso de gestión de requisitos. El objetivo de un documento es proporcionar información específica sobre un proyecto para compartirla con las partes interesadas. Al igual que muchos aspectos de la gestión de requisitos, la documentación no es un proceso estandarizado. Los equipos abordan la documentación de diversas maneras. La forma, el momento y los documentos que se utilizan dentro de un proceso varían de un equipo a otro. Sin embargo, si la documentación forma parte de tu proceso, es probable que crees diversos tipos de documentos y revisiones de estos a lo largo de la vida útil de un proyecto.
ÍNDICE
El objetivo principal de la documentación es informar. Sin embargo, la documentación presenta algunas ventajas indirectas. Por ejemplo, la documentación fomenta la responsabilidad. Los documentos son una forma sencilla de comprometerse a cumplir los requisitos acordados. Desde el punto de vista de las partes interesadas, la documentación aporta un mayor nivel de seguridad, ya que estos documentos sirven como lista de verificación de los requisitos acordados. La documentación puede utilizarse para comprobar si el trabajo no se ha completado o si se está entregando lo que se ha pagado.
Otra ventaja de la documentación es que permite a los equipos supervisar el alcance de los requisitos a lo largo de todo el ciclo de vida de un proyecto. A lo largo de dicho ciclo, los requisitos evolucionan. Un requisito concreto, por ejemplo, puede definirse con mayor claridad en una fase posterior. A medida que se crean o actualizan los documentos a lo largo del proyecto, es posible comparar los requisitos entre las distintas versiones de los documentos. Esto permite a los miembros del equipo identificar los requisitos que puedan estar desviándose de su alcance original.
No existe un documento estandarizado creado específicamente para los requisitos no funcionales. Sin embargo, esto no significa que no se pueda elaborar documentación específica sobre los requisitos no funcionales dentro de su propio proceso. Por el contrario, los requisitos no funcionales suelen incluirse en un tipo de documento más amplio.
Existen varios documentos de requisitos diseñados para destacar aspectos concretos de un proyecto. Por ejemplo, se pueden elaborar documentos sobre requisitos de negocio (BRD), requisitos técnicos (TRD) y muchos otros aspectos de la gestión de requisitos.
En lo que respecta al proceso de documentación, los requisitos no funcionales suelen incluirse en los documentos de requisitos funcionales (FRD), los documentos de requisitos del producto (PRD) y las especificaciones de requisitos de software (SRS).
Echemos un vistazo básico a algunos de los tipos de documentos mencionados anteriormente que incluyen requisitos no funcionales, para comprender mejor por qué se elaboran estos documentos.
El Documento de Requisitos Funcionales es una declaración formal de los requisitos funcionales de una aplicación. Por lo general, un analista de negocios elabora el FRD a partir de diversas interacciones con los clientes y las partes interesadas, con el objetivo de recabar los requisitos. La elaboración del FRD se lleva a cabo bajo la supervisión del director del proyecto.
Los requisitos no funcionales suelen aparecer en una sección específica del documento de requisitos funcionales (FRD). Esta sección suele ir a continuación de los requisitos funcionales y se titula «Requisitos no funcionales». Sin embargo, en algunos documentos, los requisitos no funcionales pueden clasificarse según los atributos del sistema (por ejemplo, «Requisitos operativos») o aparecer bajo denominaciones como «Requisitos no comerciales».
El documento de requisitos del producto suele ser redactado por el director del proyecto. El PRD se utiliza para comunicar a los equipos de pruebas y desarrollo qué funcionalidades deben incluirse en el lanzamiento de un producto.
Ten en cuenta las diferencias entre los requisitos funcionales y los no funcionales. Los requisitos no funcionales no definen directamente lo que debe hacer un producto. Se refieren a las características del producto que determinan cómo se percibe este y a otras especificaciones técnicas que contribuyen a la experiencia del usuario. Los documentos de requisitos del producto son detallados. El objetivo de estos documentos es proporcionar la orientación general del producto. Por lo tanto, los requisitos funcionales y no funcionales se tratan en secciones específicas del documento de requisitos del producto.
El documento de especificaciones de requisitos del sistema se elabora para ilustrar y describir las características y el comportamiento de un software o un sistema. En la mayoría de los casos, los documentos de especificaciones de requisitos del sistema los redactan arquitectos de sistemas o responsables de producto expertos en la materia. Sin embargo, durante el proceso inicial de recopilación de requisitos, los responsables de producto trabajan en colaboración con los clientes.
Los requisitos no funcionales vuelven a aparecer en una sección específica del documento de especificaciones de requisitos del sistema.
El verdadero problema del proceso de documentación en la gestión de requisitos es la falta de estandarización. Hay ciertos tipos de documentos que son más habituales que otros. Sin embargo, la estructura y el contenido de estos documentos varían de un equipo a otro. Además, los equipos siempre tienen la opción de abordar la documentación de forma puntual. Como se ha mencionado anteriormente, un equipo podría optar por documentar los requisitos no funcionales en su propio documento específico.
La falta de estandarización parece ser una ventaja que aporta flexibilidad al proceso de documentación. Lamentablemente, esta flexibilidad tiene algunos inconvenientes. La falta de estandarización puede dar lugar a que se omitan elementos de trabajo. En lo que respecta a los requisitos no funcionales, esto puede resultar perjudicial para el éxito de un producto, ya que son estos los que definen la experiencia del usuario.
Para poner esto en perspectiva, imagina una situación en la que hayas probado dos productos similares. Es muy probable que hayas descubierto que te gustaba más uno de los dos, aunque ambos cumplieran con su función prevista. Esto se debe, muy probablemente, a que el producto por el que te decantaste ofrece una mejor experiencia de usuario. La experiencia de usuario viene determinada por los requisitos no funcionales. Establecer requisitos no funcionales que estén bien definidos, sean cuantificables y se puedan comprobar permite a los equipos evaluar de forma rápida y concluyente el éxito de cualquier proyecto.
La inclusión de requisitos no funcionales en la documentación les confiere una mayor visibilidad, lo que facilita su revisión y perfeccionamiento. Esta visibilidad también puede influir en la creación y la evolución de los requisitos funcionales dentro del documento.
La herramienta Smart Docs de Modern Requirements permite a los usuarios crear la estructura de sus documentos de requisitos directamente dentro de su entorno de Azure DevOps. Al crear un Smart Doc, los requisitos —incluidos los no funcionales— pueden insertarse en el Smart Doc directamente desde el backlog del proyecto. Además, los requisitos no funcionales pueden redactarse sobre la marcha mientras se crea un Smart Doc.
Smart Docs también cuenta con una herramienta completa de gestión de versiones que permite a los usuarios crear versiones de su Smart Doc en cualquier momento. Gracias a la gestión de versiones, los cambios en elementos de trabajo, como los requisitos no funcionales, pueden seguirse comparando versiones y exportarse como formularios de cambio.
La gestión de revisiones también está integrada en la herramienta Smart Docs. Modern Requirements4DevOps ofrece una solución única para la revisión de aplicaciones que fomenta la colaboración dentro del equipo a la hora de revisar y modificar los elementos de trabajo. Al iniciar las revisiones, los miembros del equipo y las partes interesadas pueden examinar críticamente los elementos de trabajo. En lo que respecta específicamente a los requisitos no funcionales, las revisiones son un componente fundamental del proceso de gestión, ya que estos elementos de trabajo pueden utilizarse para evaluar el éxito de un proyecto. La posibilidad de realizar revisiones de forma fluida junto con la creación de documentos fomenta un flujo de trabajo sólido centrado en la elaboración de requisitos bien definidos.
¿Le supone un problema la falta de estandarización en su propio proceso de documentación? Smart Docs ofrece una solución a este problema generalizado en el sector gracias a la posibilidad de crear plantillas de documentos reutilizables. Mediante la herramienta Meta Template Designer, los usuarios de Smart Docs pueden personalizar la estructura de sus documentos. Al crear una estructura personalizada para su documento, los usuarios pueden decidir qué elementos de trabajo se pueden incluir y en qué parte del documento deben aparecer. Las plantillas de documentos estructuradas y reutilizables garantizan la coherencia y fomentan la eficiencia (reduciendo la necesidad de reelaborar documentos) en el proceso de documentación de su equipo.
Con Modern Requirements4DevOps puedes crear documentos de requisitos directamente desde tu entorno de Azure DevOps. ¡Echa un vistazo a este documento de requisitos funcionales creado con Smart Docs!
Comprueba por ti mismo cómo nuestra caja de herramientas «Modern Requirements» puede potenciar Azure DevOps de Microsoft, líder del sector, para convertirlo en una solución única de gestión de requisitos de aplicaciones.
Prueba Modern Requirements en la nube aquí.
End-to-end requirements management in Azure DevOps.
AI-powered assistance for DevOps workflows.
Autonomous AI agents for DevOps execution.
Real-time data sync across tools and systems.
