Soluciones Visure


Soporte
Registro
Iniciar Sesión
Empiza La Prueba Gratuita

Pasar de buenos a excelentes requisitos

Meet 29 de septiembre de 2022 Múltiples veces disponibles Gratis

Índice del contenido

Una de las partes más importantes de cualquier proyecto de desarrollo de software es crear requisitos detallados y precisos. Sin una comprensión clara de lo que se necesita construir, es imposible crear un producto final de alta calidad. Desafortunadamente, escribir buenos requisitos suele ser más fácil decirlo que hacerlo. La razón principal por la que las personas escriben requisitos deficientes es que no han tenido capacitación ni experiencia en la redacción de buenos requisitos. Si usted o su personal tienen problemas para redactar buenos requisitos, puede beneficiarse de una guía sobre cómo redactar buenos requisitos. Al tomarse el tiempo para aprender a escribir mejores requisitos, puede mejorar la calidad general de sus proyectos de desarrollo de software y ahorrarse muchos dolores de cabeza en el futuro.

¿Por qué fracasan los proyectos de ingeniería de sistemas?

¿Por qué fracasan los proyectos en industrias fuertemente reguladas? Muchos investigadores han investigado por qué fallan los proyectos de sistemas y software. Standish Group realizó una investigación en 2009, que destaca que la mayoría de las razones por las que los proyectos fallan están relacionadas con los requisitos.

Analizar la calidad del proyecto

Esa es una de las razones principales por las que escribir buenos requisitos es crucial para el éxito del proyecto. Además, escribir buenos requisitos trae muchos otros beneficios a los equipos.

¿Qué es la especificación de requisitos?

La especificación de requisitos es un proceso en el que los requisitos se definen, documentan y analizan. Es una parte importante del desarrollo de software porque garantiza que todas las partes interesadas estén de acuerdo con la funcionalidad del software antes de que comience el desarrollo. Al hacer esto, se reduce la probabilidad de malentendidos y reelaboraciones posteriores.

La especificación de requisitos, también conocida como documentación, es un proceso de anotar o escribir todos los requisitos del sistema y del usuario en forma de documento. Estos requisitos deben ser claros, completos, completos y consistentes.

Especificación de requisitos

Proceso de ingeniería de requisitos

Ingeniería de requerimientos

Hay algunas actividades a las que nos enfrentamos cuando trabajamos con los requisitos. En el ciclo de Ingeniería de Requisitos, hay cinco actividades principales, a saber,

  1. Obtención de requisitos – Este es el proceso de recopilación, revisión y comprensión de las necesidades y limitaciones de las partes interesadas y los usuarios para la temporada. Los usuarios necesitan información de dominio, información del sistema existente, regulaciones, estándares, etc. Con base en esta información, obtenemos los requisitos. Después de esto, pasamos al análisis y negociación de requisitos. 
  2. Análisis y Negociación de Requerimientos – El análisis es el proceso de refinar las necesidades y restricciones del usuario sobre la base de la información recopilada y obtenida. Luego, pasamos a la actividad de documentación. 
  3. Requisitos Documentación/Especificación – Después de obtener las especificaciones de requisitos, pasamos a la parte de documentación. Documentamos las necesidades y limitaciones del usuario de forma clara y precisa. 
  4. Validación de requisitos – Finalmente, en la actividad de validación, insertamos que los requisitos de la temporada sean completos, concisos y claros. 
  5. Gestión de necesidades – La gestión de requisitos es una forma de recopilar, analizar, refinar y priorizar todos los productos o requisitos, en la fase de desarrollo. Durante esta fase también se establece una sólida trazabilidad entre los requisitos y las fuentes de información. 

Cuando finalizamos estas cinco actividades, las repetimos una y otra vez hasta obtener un conjunto de documentos de requisitos acordados que son especificaciones formales.

¿Por qué es importante redactar buenos requisitos?

Hay muchos beneficios de tener buenas especificaciones de requisitos. Algunos de ellos se enumeran a continuación:

  • Ayuda a garantizar que todas las partes interesadas tengan un entendimiento común del sistema que se va a desarrollar. Esto evita cualquier malentendido durante las etapas posteriores del desarrollo.
  • Sirve como punto de referencia para todas las partes interesadas durante el proceso de desarrollo.
  • Ayuda a identificar cualquier brecha en los requisitos en una etapa temprana.
  • Reduce el costo general y el tiempo de desarrollo, ya que evita la repetición del trabajo debido a cambios en los requisitos.

¿Qué conseguimos escribiendo grandes requisitos?

Hay muchas cosas que los grandes requisitos ayudan a lograr. Algunos de ellos se enumeran a continuación:

  • Los grandes requisitos ayudan a garantizar que el sistema que se está desarrollando satisfaga las necesidades de los usuarios.
  • Sirven como base para probar el sistema para garantizar que funciona como se espera.
  • Ayudan a reducir el costo general y el tiempo de desarrollo al evitar la repetición del trabajo debido a cambios en los requisitos.
  • Los grandes requisitos ayudan a que el proceso de desarrollo sea más eficiente y eficaz.

Desafíos al escribir requisitos

Hay varios desafíos que enfrentan las personas al escribir los requisitos.

Redacción de requisitos

Mal papeleo – En algunas organizaciones, la documentación de los procesos es inexistente o no está a la altura. En este caso, la recopilación de requisitos se convierte en un proceso de dos pasos: primero aplicar ingeniería inversa al proceso existente y luego identificar las áreas que necesitan mejoras y optimización. Para confirmar que los requisitos están desarrollados y son precisos, es clave identificar a las partes interesadas clave y a los expertos en la materia, interactuando con ellos directamente. Dibujar mapas de procesos comerciales y visualizar flujos de trabajo son dos formas excelentes de hacerlo. Esto ayuda en la eliminación de suposiciones incorrectas al mismo tiempo que proporciona una imagen completa. Dibujar mapas de procesos y mostrar procesos son dos enfoques útiles para este propósito.

Requisitos contradictorios – Cuando las partes interesadas tienen diferentes prioridades para sus objetivos comerciales, esto genera requisitos que entran en conflicto entre sí. En casos como estos, la responsabilidad de un analista comercial es documentar todos los requisitos en detalle, identificar qué solicitudes se oponen entre sí y permitir que las partes interesadas decidan qué es lo que tiene prioridad.

No puede tomar decisiones sin escuchar los aportes de las partes interesadas y, como analista de negocios, puede tener algunas ideas sobre lo que debe priorizarse. Todavía es crucial escuchar la perspectiva de las partes interesadas. La configuración de una encuesta podría ser uno de los métodos para obtener claridad sobre lo que más le importa a la mayoría de las partes interesadas.

Indisponibilidad de la entrada del usuario – Algunas razones pueden contribuir a la falta de disponibilidad de los usuarios finales, y cada una requiere su propia resolución. Por ejemplo, a veces los usuarios finales están tan preocupados con su trabajo diario que no están dispuestos a participar en las actividades de recopilación de requisitos.

En tales casos, lo mejor que puede hacer un analista de negocios es limitar el número y la duración de los compromisos. Antes de la reunión, investigar lo más posible ayudará a que la discusión sea más organizada e informativa. Es casi como convertir la recopilación de requisitos en sesiones de validación de requisitos. definición de grupos focales e identificación de los usuarios finales más adecuados para cada grupo

Centrarse en la interfaz en lugar de la experiencia – Muchas partes interesadas y usuarios finales tienen una visión clara de cómo debe aparecer la nueva solución, pero no saben qué debe lograr. La interfaz de usuario de cualquier sistema es crucial, pero no debe definir ni interferir con la funcionalidad.

Los analistas de negocios siempre deben recordar mantener separados los requisitos funcionales y de diseño en su documentación. Mediante el uso de herramientas más generales, como diagramas, historias de usuarios o prototipos de baja fidelidad en lugar de borradores de diseño, pueden mantener el enfoque en los aspectos funcionales de la recopilación de requisitos.

Aportes de las partes interesadas – Cuando las partes interesadas o los usuarios finales intentan decirles a los diseñadores cómo debe funcionar el sistema en lugar de lo que debe hacer el sistema, puede conducir a diseños subóptimos. Para evitar esto, valide cada 'requisito falso' potencial preguntando '¿por qué?' hasta llegar al problema real que necesita solución.

Problemas de comunicación – Entre los problemas que pueden generar problemas de comunicación entre un analista comercial y otras partes se encuentran las barreras del idioma, las suposiciones incorrectas, el vocabulario insuficientemente explicado y el uso excesivo de términos técnicos.

El enfoque ideal para evitar este problema es interactuar con frecuencia y desarrollar conversaciones bidireccionales. Documente las necesidades que haya descubierto y envíelas para revisión y crítica de pares a una variedad de especialistas en la materia, cree un glosario de jerga y verifique dos veces las premisas.

¿Estándares para los requisitos de escritura?

EARS sería una metodología efectiva aquí. Lo que representa Easy Aacercarse a Requi pos Syntax, de Alastair Marvin. En este método, escribimos un lenguaje claro, conciso y comprensible. Esto mejora todo el flujo de trabajo de ingeniería de requisitos y simplifica el trabajo al hacer que las cosas sean bastante fáciles de entender. 

Para lograr esto, aquí hay algunos principios que deben tenerse en cuenta al escribir los requisitos. Implican:

  • Cada requisito debe tener la forma de una oración completa. No se deben utilizar viñetas, acrónimos, abreviaturas o palabras de moda. Trate de hacer oraciones cortas, directas y completas. 
  • Asegúrese de que cada requisito tenga un sujeto, un predicado y un verbo adecuados. El tema sería el tipo de usuario o el sistema del que estamos hablando. El predicado serían las condiciones o acciones o resultados deseados que esperamos. Debemos usar palabras como 'deberá', 'voluntad' y 'debe' para expresar algún tipo de necesidad, y palabras como 'puede' para expresar opcionalidad en el requisito. 
  • Cada requisito debe explicar de manera eficiente el resultado final que deseamos del sistema. 
  • Además, el requisito debe describir la calidad que esperamos del sistema. Ayuda cuando medimos el resultado final y vemos si el requisito se implementa correctamente o no.

Componentes esenciales de un documento de requisitos:

Las secciones principales de una especificación de requisitos de software son:

  • Impulsores del negocio – Las razones por las que el cliente busca construir un sistema se describen en esta sección. Esta sección incluye además los problemas que enfrenta el cliente con el sistema actual y las oportunidades que brindará el nuevo sistema.
  • Modelo de negocio – El modelo de negocio que el sistema debe soportar se analiza en esta sección. Además, incluye varios otros detalles como el contexto organizacional y comercial, las principales funciones comerciales y los diagramas de flujo de procesos del sistema.
  • Requisitos funcionales y del sistema – Esta sección normalmente detalla los requisitos que están organizados en una estructura jerárquica. Los requisitos funcionales se encuentran en el nivel superior y los requisitos detallados del sistema se enumeran como subelementos.
  • Casos de uso del sistema – Esta sección consta de un diagrama de casos de uso del lenguaje de modelado unificado (UML) que explica todas las entidades externas clave que interactuarán con el sistema y los diferentes casos de uso que tendrán que realizar.
  • Requerimientos Técnicos – Esta sección analiza todos los requisitos no funcionales que conforman el entorno técnico y las limitaciones técnicas en las que operará el software.  
  • Cualidades del sistema – En esta sección, se definen las numerosas cualidades del sistema, como la confiabilidad, la facilidad de servicio, la seguridad, la escalabilidad, la disponibilidad y la mantenibilidad.
  • Limitaciones y supuestos – Todas las limitaciones impuestas al diseño del sistema desde el punto de vista del cliente se describen en esta sección. Las diversas suposiciones del equipo de ingeniería sobre qué esperar durante el desarrollo también se analizan aquí.
  • Criterios de aceptación – En esta sección se analizan los detalles de todas las condiciones que deben cumplirse antes de que el sistema se entregue a los clientes finales.

Características de un Documento de Especificación de Requisitos de Software:

Especificación de Requerimientos de Software
  • Actualizar – Los requisitos escritos deben ser claros, fáciles de leer y comprensibles. Especifique claramente la información utilizando oraciones afirmativas que se intercambiarán entre los actores. Cada requisito debe describir criterios claros de éxito. Trate de usar un vocabulario simple y evite las abreviaturas. Por ejemplo, "El usuario podrá ver el Informe de registro de auditoría".
  • Atómico – Cada requisito debe tratarse como un caso de prueba discreto. No se deben usar conjunciones como y, o, etc., porque pueden hacer que se pierdan requisitos. Esto es particularmente crucial ya que términos como estos pueden hacer que los desarrolladores y probadores de software pasen por alto los requisitos. Dividir las necesidades complicadas en partes más pequeñas hasta que cada una pueda probarse por separado es una forma de evitar que esto suceda.
  • Sin ambigüedades – Los requisitos poco claros, incompletos o contradictorios pueden dar lugar a errores y reelaboración. Para evitar que esto suceda, todos los interesados ​​deben revisar los requisitos antes de finalizarlos. Esto ayudará a identificar cualquier brecha desde el principio que luego se pueda abordar.
  • Verificable – Todos los miembros del equipo de desarrollo deben tener acceso al documento para que puedan consultarlo tantas veces como sea necesario. Debido a que los requisitos deben ser claros, los miembros del equipo no quieren más información. Todos deben estar accesibles en el documento SRS.
  • Necesario – Cada requisito debe documentar algo que los usuarios realmente necesitan o algo que se requiere para cumplir con un estándar o una necesidad de integración debido a la existencia de una interfaz externa. Además, es importante que cada requerimiento tenga una fuente autorizada.
  • Diseño Independiente – Cada requisito debe definir lo que es necesario, no cómo se implementará. Los requisitos deben definir las características del sistema que se observarán externamente, no los detalles internos.
  • Factible – Cada requerimiento debe ser técnicamente ejecutable y debe ser implementado teniendo en cuenta el presupuesto, plazo y demás restricciones que afecten el proyecto. Los requisitos deben reflejar el estado real de las cosas, incluido el costo, el cronograma y la tecnología. No deberían depender de futuros avances tecnológicos.
  • Solución – El documento de requisitos debe incluir suficiente información para que su equipo de desarrollo y evaluadores completen el producto y garanticen que cumple con los requisitos del usuario sin errores.
  • Correcto – Los requisitos especificados en los documentos deben ser muy precisos para evitar cualquier tipo de confusión. No deben tener lagunas, ambigüedades, subjetividad, superlativos o comparaciones. Por lo tanto, para escribir requisitos correctos, debemos obtener información correcta y documentar correctamente la información que se recopila.

Reglas para el conjunto de requisitos correctos

Hay ciertas reglas que los requisitos deben cumplir para ser llamados "Correcto".

  • Solución – El documento de requisitos debe incluir suficiente información para que su equipo de desarrollo y evaluadores completen el producto y garanticen que cumple con los requisitos del usuario sin errores.
  • Consistencia – Mantener un nivel constante de detalle. Por ejemplo, para los requisitos del usuario, el usuario final debe ser el sujeto de cada oración. De manera similar, para los requisitos del sistema, un sistema debe ser el sujeto de cada oración.
  • Modificabilidad – Los requisitos pueden cambiar a lo largo del ciclo de vida del proyecto. El registro de requisitos debe almacenarse y debe ser posible el análisis del impacto de los cambios realizados en otros requisitos y elementos del proyecto.
  • Priorización – Los requisitos deben clasificarse desde el punto de vista de la importancia. No todas las características deseadas para un sistema son igualmente importantes. Para eso, sería útil establecer una regla para definir prioridades de requisitos a nivel organizacional y adaptarla a cada proyecto. Y trabajar con los usuarios para que puedan priorizar los requisitos.

Requisitos de visualización Plataforma ALM

Visure es una de las plataformas de administración del ciclo de vida de aplicaciones más confiables que se especializa en la administración de requisitos para organizaciones de todos los tamaños en todo el mundo. Los principales socios de Visure incluyen empresas críticas para el negocio y críticas para la seguridad. La empresa se integra a través de todos los procesos de gestión del ciclo de vida de las aplicaciones, incluida la gestión de riesgos, el seguimiento de problemas y defectos, la gestión de trazabilidad, la gestión de cambios y varias otras áreas como el análisis de calidad, el control de versiones de los requisitos y la generación de informes potentes.  

Cursos de herramientas de Visure

Si está buscando una herramienta de administración de requisitos que lo ayude con los requisitos funcionales y no funcionales, consulte Requisitos de Visure. Con esta plataforma, puede crear, administrar y rastrear fácilmente todos los requisitos de su proyecto en un solo lugar.

Conclusión

Para producir un gran software, es importante tener una especificación de requisitos bien escrita. Este documento describe las necesidades del cliente y lo que el sistema debe hacer para cumplir con sus expectativas. Sin embargo, escribir buenos requisitos puede ser un desafío. Hay muchos estándares y pautas que deben seguirse, y hay muchas formas diferentes de escribirlos según el lenguaje y las herramientas que utilice. La plataforma ALM de requisitos de Visure ofrece un curso que le enseña cómo escribir especificaciones de requisitos eficaces utilizando las mejores prácticas y los estándares de la industria. El curso cubre todos los componentes esenciales de un documento de requisitos, desde la estructura hasta el formato, además de cómo utilizar varios idiomas para redactar los requisitos. También destaca las características de los grandes requisitos para que pueda crear documentos con los que a su equipo le encantará trabajar. Si desea obtener más información sobre cómo redactar requisitos efectivos, pruebe el Curso de especificación de requisitos por Visure Requisitos Plataforma ALM hoy!

¡No olvides compartir esta publicación!

Software de puertas racionales de IBM
Notable

Simplificación de la gestión y validación de requisitos

11 julio,2024

10 a. m. EST | 4:7 horas (hora central europea) | XNUMX a. m. hora del Pacífico

Luis Arduin

Luis Arduin

Consultor sénior, Soluciones Visure

Thomas Dirsch

Consultor senior de calidad de software, Razorcat Development GmbH

Un enfoque integrado con Visure Solutions y Razorcat Development TESSY

Aprenda cómo optimizar la gestión y validación de requisitos para obtener los mejores resultados.