Soluciones Visure


Soporte
Registro
Iniciar Sesión
Empiza La Prueba Gratuita

Implementación de IA, tecnologías y mejores prácticas para redactar requisitos de seguridad para industrias críticas por Jordan Kyriakidis

Podcast (Inglés) Enero 11, 2023 10 a. M. PST

Índice del contenido

Introducción

La redacción de requisitos ha supuesto un importante reto desde hace ya muchas décadas, y una de las principales razones de ello es el lenguaje que se utiliza para expresarlos. Es esencial redactar los requisitos de una manera que sea completa y fácilmente comprensible, especialmente cuando los lectores son propietarios de negocios, usuarios finales o partes interesadas. Esto significa usar un lenguaje “natural” que esté libre de jerga técnica y terminología compleja. Sin embargo, el lenguaje natural es inherentemente impreciso y puede malinterpretarse o malinterpretarse fácilmente, lo que genera más complicaciones.

Desafortunadamente, muchos analistas se resisten a cualquier tipo de estructura en la redacción de sus requisitos, prefiriendo confiar en párrafos y oraciones descriptivos que pueden implicar requisitos adicionales. Si bien este enfoque puede ser más atractivo para sus lectores, a menudo genera confusión y malentendidos cuando los requisitos se entregan a los desarrolladores o analistas de sistemas. Esto, a su vez, puede resultar en largas discusiones y demoras al tratar de aclarar qué significan realmente los requisitos.

Durante la entrevista con Visure Solutions, Jordan Kyriakidis, el estimado cofundador y director ejecutivo de QRA Corp, compartió sus ideas sobre varios aspectos de la ingeniería de requisitos. Durante esta entrevista, discutimos algunos temas bastante interesantes, incluyendo

  • Elementos esenciales de grandes requisitos
  • Easy Aacercarse a Requi pos SEnfoque yntax
  • La IA gana fuerza en la digitalización de la ingeniería de requisitos
  • Consejos y trucos para redactar excelentes requisitos
  • ¡Y mucho más!

¿Quién es Jordan Kyriakidis?

Jordan Kyriakidis es un líder reconocido en el campo del diseño y la verificación de sistemas críticos para la seguridad. Es Co-Fundador y CEO de QRA Corp, una empresa que brinda soluciones de vanguardia para empresas y gobiernos para identificar y mitigar el riesgo en proyectos complejos que involucran nuevas tecnologías en industrias reguladas. Con casi dos décadas de experiencia liderando equipos de alto rendimiento, Jordan es un científico consumado con numerosas publicaciones internacionales en su haber.

Jordan tiene un Ph.D. en Teoría Cuántica de la Universidad de Basilea, Suiza, y ha vivido y trabajado en varios países del mundo, incluidos Europa, Estados Unidos y Canadá. Su experiencia en ingeniería de requisitos, junto con su pasión por avanzar en el campo, lo han convertido en un orador solicitado y líder de pensamiento en la industria. Jordan es conocido por su enfoque visionario para aprovechar la IA y las mejores prácticas para escribir requisitos en industrias críticas, y ha sido fundamental en la digitalización de la ingeniería de requisitos.

¿Qué es la especificación de requisitos?

La especificación de requisitos es el proceso de definir y documentar claramente los requisitos funcionales y no funcionales de un sistema, aplicación de software o producto. El propósito de la especificación de requisitos es capturar las necesidades y expectativas de las partes interesadas, incluidos los clientes, los usuarios finales y otras partes interesadas, de manera clara y concisa. Esta documentación se utiliza como modelo para el diseño, desarrollo, prueba e implementación del sistema o producto. 

La especificación de requisitos generalmente incluye una descripción de la funcionalidad, el rendimiento, la usabilidad, la confiabilidad, la seguridad y otras características importantes previstas del sistema o producto. También puede incluir cualquier restricción, suposición o dependencia que pueda afectar el diseño o la implementación del sistema o producto. La especificación de requisitos es un componente esencial del ciclo de vida del desarrollo de software y sirve como base para una comunicación y colaboración efectivas entre las partes interesadas del proyecto.

Importancia de escribir grandes requisitos

Escribir grandes requisitos es crucial para el éxito de cualquier proyecto de desarrollo de software. Aquí hay algunas razones de por qué:

  1. Comunicación clara: Los requisitos bien escritos ayudan a garantizar que todas las partes interesadas del proyecto tengan una comprensión clara y compartida de lo que se espera del sistema o producto que se está desarrollando. Esta claridad garantiza que todos estén en sintonía, lo que reduce el riesgo de malentendidos y falta de comunicación que pueden provocar errores, reelaboraciones y retrasos en los proyectos.
  2. Centrarse en las necesidades del usuario: Los grandes requisitos se centran en las necesidades de los usuarios finales y los clientes, asegurando que el sistema o producto que se está desarrollando cumpla con sus expectativas y requisitos. Este enfoque aumenta la satisfacción del cliente y reduce el riesgo de fracaso del proyecto debido a la falta de coincidencia entre el producto y las necesidades del usuario.
  3. Gestión de riesgos: Los requisitos pueden identificar posibles riesgos y problemas al principio del proceso de desarrollo, lo que permite implementar estrategias proactivas de mitigación. Al identificar problemas potenciales de forma temprana, los equipos pueden evitar costosos retrabajos, demoras y fallas en el futuro.
  4. Eficiencia: Los grandes requisitos ayudan a agilizar el proceso de desarrollo al proporcionar una hoja de ruta clara para que los desarrolladores la sigan. Esta hoja de ruta garantiza que los desarrolladores trabajen en las características y los requisitos más importantes, evitando el desperdicio de esfuerzos en tareas menos importantes.
  5. Seguro De Calidad: Al tener requisitos bien definidos, es más fácil asegurar que el sistema o producto que se está desarrollando cumpla con los estándares de calidad requeridos. Los grandes requisitos facilitan la prueba, la validación y la verificación del sistema o producto que se está desarrollando, lo que garantiza que se entregue a tiempo, dentro del presupuesto y con el nivel de calidad esperado.

Características de los Grandes Requisitos

Los grandes requisitos son esenciales para entregar proyectos de desarrollo de software exitosos que satisfagan las expectativas del cliente, se entreguen a tiempo y estén dentro del presupuesto. Estas son algunas características de los grandes requisitos:

  1. Claro y conciso: Los grandes requisitos son fáciles de entender, con un lenguaje claro y conciso que evita la ambigüedad o la confusión.
  2. Completar: Los grandes requisitos deben capturar todos los aspectos funcionales y no funcionales necesarios del sistema o producto que se está desarrollando, sin dejar lugar a interpretaciones o malentendidos.
  3. Preciso: Los grandes requisitos deben ser precisos y verificables, sin discrepancias entre lo que está escrito y lo que se espera que haga el sistema o producto.
  4. Comprobable: Los grandes requisitos deben ser comprobables, lo que significa que debería ser posible crear pruebas que puedan verificar que el sistema o producto cumple con los requisitos.
  5. Priorizado: Se deben priorizar los grandes requisitos para garantizar que las características y funcionalidades más importantes se desarrollen primero.
  6. Factible: Los grandes requisitos deben ser factibles, lo que significa que son técnica y prácticamente alcanzables dentro de las limitaciones de tiempo y presupuesto dadas.
  7. Trazable: Los grandes requisitos deben ser rastreables, lo que significa que existe un vínculo claro entre cada requisito y su fuente, incluida la parte interesada que lo solicitó.
  8. Consistente: Los grandes requisitos deben ser consistentes con otra documentación del proyecto, incluido el plan del proyecto, la declaración del alcance y otra documentación relevante.
  9. Inequívoco: Los grandes requisitos deben estar libres de ambigüedad o confusión, asegurando que haya una comprensión clara de lo que se espera del sistema o producto que se está desarrollando.

Desafíos al escribir requisitos

Hay varios desafíos que enfrentan las personas al escribir los 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 dar lugar 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 ha 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.

Errores comunes al escribir requisitos

Escribir requisitos puede ser una tarea desafiante, y se pueden cometer errores comunes que pueden afectar el éxito del proyecto de desarrollo de software. Aquí hay algunos errores comunes al escribir requisitos:

  1. Ambigüedad: Uno de los errores más comunes al redactar los requisitos es el uso de un lenguaje ambiguo, lo que puede dar lugar a malentendidos y errores. Esto se puede evitar utilizando un lenguaje claro, conciso y sin ambigüedades.
  2. Requisitos incompletos o inconsistentes: Los requisitos incompletos o inconsistentes pueden generar confusión y errores en el proceso de desarrollo de software. Esto se puede evitar revisando y validando los requisitos para garantizar que estén completos y sean coherentes con otra documentación del proyecto.
  3. Falta de priorización: Sin una priorización adecuada, los requisitos pueden desarrollarse al azar, lo que genera demoras y un producto que no cumple con las expectativas del cliente. Priorizar los requisitos puede garantizar que las características y funcionalidades más importantes se desarrollen primero.
  4. Requisitos poco claros o no verificables: Los requisitos poco claros o no verificables pueden generar malentendidos y dificultades para validar que el sistema o producto cumple con los requisitos. Esto se puede evitar asegurando que los requisitos sean claros y verificables.
  5. Oro platino: El chapado en oro ocurre cuando se agregan características o funcionalidades adicionales al sistema o producto que no se especificaron en los requisitos. Esto puede generar demoras, costos adicionales y un producto que no satisfaga las necesidades del cliente.
  6. Falta de participación de las partes interesadas: La falta de participación de las partes interesadas puede dar lugar a requisitos que no satisfagan las necesidades de los clientes y otras partes interesadas. Involucrar a las partes interesadas a lo largo del proceso de desarrollo de software puede garantizar que los requisitos estén alineados con sus necesidades y expectativas.
  7. Dependencia excesiva de la tecnología: La dependencia excesiva de la tecnología puede conducir a requisitos que no se alinean con las capacidades del sistema o producto que se está desarrollando. Esto se puede evitar asegurando que los requisitos sean factibles y estén alineados con la tecnología que se está utilizando.
  8. Falta de consideraciones de prueba: Las pruebas son un aspecto importante del desarrollo de software, y la falta de consideración de las pruebas en los requisitos puede conducir a un producto que es difícil de probar o que no cumple con los estándares de calidad.

Requisitos de escritura utilizando métodos de lenguaje natural

Redactar requisitos utilizando métodos de lenguaje natural implica usar lenguaje cotidiano para comunicar los requisitos de una manera que sea clara, concisa y fácil de entender. Este enfoque se usa a menudo en el desarrollo de software y otras industrias donde existe la necesidad de capturar y documentar requisitos que sean fácilmente comprensibles para todas las partes interesadas, independientemente de su experiencia técnica.

El lenguaje natural es el lenguaje que usamos en nuestra comunicación diaria, como inglés, francés, español, etc. Redactar los requisitos en lenguaje natural implica usar el mismo lenguaje que las partes interesadas usan en su comunicación diaria, en lugar de usar una jerga técnica o un lenguaje especializado que puede ser desconocido para las partes interesadas no técnicas.

En comparación con otros idiomas para los requisitos de escritura, el lenguaje natural tiene la ventaja de ser más fácil de entender para las partes interesadas no técnicas. El uso del lenguaje natural puede ayudar a garantizar que los requisitos se comuniquen de manera efectiva a todas las partes interesadas, lo que lleva a un resultado del proyecto más exitoso. Por el contrario, otros lenguajes para escribir requisitos, como los lenguajes de especificación formal, pueden ser más precisos e inequívocos, pero pueden ser más difíciles de entender para las partes interesadas no técnicas.

Para redactar requisitos utilizando métodos de lenguaje natural, es importante utilizar un lenguaje sencillo y cotidiano que sea fácil de entender. Los requisitos deben ser específicos, medibles y verificables, y deben evitar el uso de términos vagos o jerga técnica. El uso de plantillas, ejemplos y elementos visuales también puede ayudar a que los requisitos sean más claros y concisos.

Plantilla de OREJAS

La plantilla EARS (Enfoque fácil a la sintaxis de los requisitos) es una plantilla de recopilación y documentación de requisitos que proporciona una forma estructurada de capturar y documentar los requisitos. Se usa comúnmente en industrias como la aeroespacial, la defensa y el desarrollo de software, donde existe la necesidad de capturar y documentar requisitos complejos y, a menudo, técnicos. La plantilla EARS se puede utilizar tanto para requisitos funcionales como no funcionales.

La plantilla EARS consta de cuatro secciones principales:

  1. Ambiente: Esta sección describe el contexto en el que operará el sistema, incluidas las restricciones o dependencias que deben tenerse en cuenta.
  2. actores: Esta sección describe los diferentes tipos de usuarios o sistemas que interactuarán con el sistema, incluidas sus funciones y responsabilidades.
  3. Requisito: Esta sección describe los requisitos específicos para el sistema, incluidos los requisitos funcionales y no funcionales. Cada requisito se define de manera clara y concisa utilizando una sintaxis estandarizada.
  4. Estímulo: Esta sección describe las entradas que activarán el sistema para realizar ciertas acciones o respuestas, y las salidas o respuestas esperadas.

Para usar la plantilla EARS, el analista de requisitos o el equipo primero debe identificar el entorno en el que operará el sistema, incluidas las restricciones o dependencias. A continuación, deben identificar los diferentes actores o usuarios que interactuarán con el sistema y sus roles y responsabilidades. Luego, deben identificar los requisitos específicos para el sistema, utilizando la sintaxis estandarizada definida en la plantilla. Finalmente, deben identificar los estímulos que harán que el sistema realice ciertas acciones o respuestas, y las salidas o respuestas esperadas.

La plantilla EARS está diseñada para proporcionar una forma clara y concisa de documentar los requisitos, facilitando la comprensión y verificación de los requisitos. A menudo se usa en industrias donde se necesitan requisitos precisos y precisos, como la industria aeroespacial, la defensa y el desarrollo de software. Mediante el uso de la plantilla EARS, los analistas de requisitos pueden asegurarse de que todos los requisitos relevantes se capturen y documenten de manera coherente y estructurada.

Directrices INCOSE - Plantilla

INCOSE, o el Consejo Internacional de Ingeniería de Sistemas, es una organización internacional de miembros sin fines de lucro que proporciona estándares y pautas para ayudar a las organizaciones a crear mejores procesos de ingeniería de sistemas. El Estándar de requisitos del sistema (SRS) de INCOSE contiene un conjunto de reglas y estándares que están diseñados para ayudar a las organizaciones a evaluar las declaraciones de requisitos antes de que se implementen. El SRS ha sido adoptado por varias corporaciones importantes, así como por agencias gubernamentales de todo el mundo, y se puede utilizar en muchas industrias diferentes para diversas aplicaciones. Es importante que las partes interesadas, como los desarrolladores de software, los analistas comerciales, los gerentes de proyectos, los evaluadores, el personal del departamento de TI y otros miembros del equipo, comprendan bien estos requisitos antes de comenzar a trabajar en cualquier proyecto o declaración de requisitos del sistema.

En última instancia, escribir buenos requisitos implica un cuidadoso equilibrio entre ser detallado y conciso, así como asegurarse de que el requisito sea comprobable y factible. El SRS de INCOSE ofrece principios y pautas para que los equipos puedan escribir requisitos de buena calidad y ayudar a garantizar que sus proyectos sean exitosos. Esto ayudará a evitar errores costosos durante el desarrollo o después de la implementación, lo que ayudará a las organizaciones a crear mejores sistemas en menos tiempo.

¿Qué son las Reglas INCOSE?

Las declaraciones de requisitos se evalúan a través de las reglas de INCOSE. Estos estándares ayudan a las organizaciones a evaluar la viabilidad y la calidad de los requisitos antes de implementarlos. El proceso de evaluación incluye cuatro criterios principales:

  • Claro - 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.
  • inequívoco - 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 requisito debe ser técnicamente ejecutable y debe implementarse teniendo en cuenta el presupuesto, el plazo y otras restricciones que afectan 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.
  • Completo - El documento de requisitos debe incluir suficiente información para que su equipo de desarrollo y evaluadores completen el producto y se aseguren de 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.

Tendencias futuras: requisitos de escritura con IA

La tecnología de inteligencia artificial (IA) tiene el potencial de revolucionar la forma en que se escriben y gestionan los requisitos en el desarrollo de productos. En los últimos años, ha habido avances significativos en el procesamiento del lenguaje natural (NLP) y el aprendizaje automático (ML) que han hecho posible automatizar ciertos aspectos de la ingeniería de requisitos.

Una posible tendencia futura es el uso de chatbots impulsados ​​por IA, como ChatGPT y Jasper, para ayudar a redactar los requisitos. Estos chatbots utilizan algoritmos de NLP para analizar los aportes de las partes interesadas y generar requisitos de alta calidad basados ​​en esos aportes. Al aprovechar estas herramientas, las organizaciones pueden optimizar el proceso de ingeniería de requisitos, reduciendo el tiempo y el esfuerzo necesarios para desarrollar requisitos, lo que lleva a ciclos de desarrollo de productos más rápidos y un uso más eficiente de los recursos.

Otra tendencia potencial es el uso de IA para identificar y extraer automáticamente requisitos de varias fuentes de datos no estructurados, como comentarios de clientes, publicaciones en redes sociales y reseñas de productos. Mediante el uso de algoritmos NLP para identificar y extraer automáticamente los requisitos relevantes de estas fuentes, las organizaciones pueden obtener una comprensión más profunda de las necesidades y preferencias de los clientes, lo que lleva a resultados de desarrollo de productos más exitosos.

La tecnología de IA también puede ayudar a mejorar la calidad y la consistencia de los requisitos al identificar posibles conflictos, ambigüedades o redundancias en los requisitos. Esto puede ayudar a reducir el riesgo de errores y malentendidos, lo que conduce a una mejor calidad del producto y menos ciclos de reprocesamiento costosos.

Consejos esenciales para escribir requisitos

  1. Escribir en capas – Escribir requisitos en capas significa desglosar requisitos complejos en partes más pequeñas y manejables. Esto ayuda a que los requisitos sean más comprensibles, completos y fáciles de implementar.
  2. Uno a la vez - 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.
  3. Hable “Qué” No “Cómo” – El enfoque debe estar en lo que hará el sistema, no en cómo lo hace. Además, evite profundizar demasiado en temas de diseño como nombres de campo, objetos de lenguaje de programación y objetos de software. Si se encuentra discutiendo estos temas en el Documento de especificación de requisitos, dé un paso atrás; esto probablemente significa que se está volviendo demasiado específico.
  4. Verificable – Otra cosa a tener en cuenta al organizar los requisitos es que siempre deben ser comprobables. Esto significa que debe ser posible verificar que el sistema cumpla con el requisito en cuestión. Esto también se vincula con nuestro siguiente punto: la trazabilidad. Si un requisito está lleno de términos vagos, se vuelve más difícil analizar y verificar si el sistema realmente cumple con estos estándares en cuanto al rendimiento. Por lo tanto, en la medida de lo posible, apunte a la claridad y precisión en su lenguaje para que la recopilación de requisitos no sea un proceso ambiguo.
  5. Trazabilidad – La trazabilidad en la gestión de proyectos se refiere a garantizar que los requisitos estén vinculados a otros componentes del proyecto. Esto permite a los administradores de proyectos, desarrolladores y partes interesadas realizar un seguimiento del ciclo de vida completo de un requisito de principio a fin en todas las direcciones, así como con otras partes del sistema. Si gestiona la trazabilidad correctamente, puede evitar el código que no corresponde a ningún requisito (código 'extraviado') y asegurarse de que cada caso de prueba cubra al menos un requisito. Puede hacer que los requisitos sean rastreables etiquetándolos con un identificador único y brindando información sobre su origen en un repositorio central accesible para todos los miembros del equipo.
  6. Las 3 W - Los requisitos deben centrarse en satisfacer las necesidades del usuario y no en la solución. Por lo tanto, es esencial comprender los requisitos del usuario y los puntos débiles antes de desarrollar los requisitos.
    1. ¿Qué? - ¿Que estamos haciendo?
    2. ¿OMS? – ¿Quién se beneficiará?
    3. ¿Por qué? – ¿Por qué lo hacemos?
  7. 1 requisito para 1 tarea – Cada requerimiento debe establecer una sola acción y objetivo. Tenga cuidado con el uso excesivo de "y" y "o". Por ejemplo, "Si el último viernes del mes y el pago vence el 31, y si el 31 es el último viernes del mes, enviar el pago ese día después de las 6 p. m., hora del este, resultará en un pago atrasado". ”. ¡Te desafío a que lo entiendas!
  8. Priorizar requisitos – Priorizar los requisitos en función de su importancia e impacto en el éxito del proyecto. Esto ayuda a garantizar que los requisitos más importantes se cumplan primero y que se satisfagan las necesidades de las partes interesadas.
  9. Sin cláusula de escape - Por ejemplo, “El sistema determinará el número de intentos de inicio de sesión, excepto cuando el usuario claramente haya ingresado un nombre de usuario incorrecto”.

Según Jordan, ¿qué separa a los proyectos exitosos de los que no?

Según Jordan Kyriakidis, lo que separa a los proyectos exitosos de los que no lo son es la capacidad de administrar los requisitos de manera efectiva. Los proyectos exitosos tienen una comprensión clara de los requisitos y pueden gestionarlos durante todo el proceso de desarrollo, desde la planificación inicial hasta la entrega final. Por otro lado, los proyectos que no tienen éxito a menudo sufren de una mala gestión de los requisitos, lo que puede provocar falta de comunicación, retrasos y, en última instancia, el incumplimiento de los objetivos del proyecto. Por lo tanto, es crucial que las empresas inviertan en prácticas y herramientas sólidas de ingeniería de requisitos para garantizar el éxito de sus proyectos.

¿Dónde encontrar más información sobre Jordan Kyriakidis?

Para obtener más información sobre Jordan Kyriakidis y QRA Corp, consulte su página de LinkedIn en https://www.linkedin.com/company/qra-corp/. Además, puede encontrar a Jordan Kyriakidis en LinkedIn en https://www.linkedin.com/in/jordankyriakidis/. QRA Corp también tiene varios documentos técnicos y estudios de casos disponibles en su sitio web que brindan información sobre su tecnología y su aplicación en varias industrias.

Consideraciones Finales:

En conclusión, Jordan Kyriakidis y Visure Solutions han compartido una conversación reveladora sobre los requisitos de escritura. Hemos explorado la importancia de escribir requisitos excelentes y abordamos los desafíos al escribir requisitos junto con errores comunes. Analizamos diferentes métodos, como los métodos de lenguaje natural, la plantilla EARS y las pautas INCOSE. La tecnología de IA también ha abierto muchas posibilidades para escribir requisitos, lo que facilita a las personas que están comenzando a aprender cómo escribirlos mejor. Por último, también hemos incluido consejos clave para ayudarlo en el camino a medida que se embarca en este viaje. Desde aprender sobre las reglas de INCOSE hasta las tendencias futuras en los requisitos de escritura, ¡aquí hay algo para todos! ¡Llévate estos consejos esenciales y ponlos en práctica ahora! ¡Mira la entrevista completa ahora!

¡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.