Estándar IEEE 830
¿Qué es?
En 1998, el Instituto de Ingenieros Eléctricos y Electrónicos publicó el estándar IEEE 830-1998, que es la Práctica Recomendada por este instituto para Especificaciones de Requisitos de Software (SRS). Este estándar proporciona pautas detalladas sobre cómo especificar los requisitos del software que se va a desarrollar, por lo que describe cómo crear documentos SRS de alta calidad para software convencional, su contenido y las cualidades de un buen SRS. Se usa ampliamente en la industria de la ingeniería de software para garantizar una comunicación clara y completa entre las partes interesadas involucradas en proyectos de desarrollo de software, pues, además, ayuda a establecer un entendimiento común de los requisitos y sirve como referencia para desarrolladores, evaluadores y otros miembros del equipo del proyecto.
Este fue el recurso técnico utilizado para el desarrolo del proyecto debido a que fue la base de la cual se desarrolló el diseño para la integración de requisitos de inteligencia artificial en la especificación de requisitos.
Estructura
El estándar se compone por la estructura mostrada a continuación. Esta es una breve explicación de las secciones de la misma.
Se incluye el nombre del proyecto, la versión del documento, su fecha y logo de la empresa desarrolladora
- Esta sección no va incluida en el documento final, sin embargo, proporciona indicaciones generales para el uso de la plantilla, como las siguientes:
- Explica que es una plantilla basada en el estándar IEEE Std 830-1998.
- Indica cómo manejar las secciones.
- Proporciona instrucciones sobre el formato (colores, estilos, numeración automática).
- Explica cómo usar los marcadores de posición y actualizar el índice.
- Registra la fecha, revisión, autor y verificación de calidad.
- Incluye un espacio para la validación por parte del cliente y la empresa suministradora.
Es el índice de contenidos encontrados en el documento.
Se compone de las siguientes subsecciones:
- Propósito: Define el objetivo del documento y su audiencia prevista.
- Alcance: Identifica el producto y su relación con otros sistemas si aplica.
- Personal involucrado: Detalla en una tabla los roles, responsabilidades y contactos de los participantes.
- Definiciones, acrónimos y abreviaturas: Clarifica términos técnicos o específicos.
- Referencias: Lista documentos relacionados con detalles bibliográficos en una tabla.
- Resumen: Ofrece una visión general del resto del documento.
Se compone de las siguientes subsecciones:
- Perspectiva del producto: Contextualiza el producto en un sistema más amplio si es relevante.
- Funcionalidad del producto: Resume las principales capacidades del software.
- Características de los usuarios: Describe tipos de usuarios, su formación y actividades, en una tabla para cada tipo.
- Restricciones: Enumera limitaciones de diseño, implementación o externas.
- Suposiciones y dependencias: Lista factores que podrían afectar los requisitos si cambian.
- Evolución previsible del sistema: Anticipa posibles mejoras o cambios futuros.
En esta sección se especifican primeramente los requisitos funcionales y los no funcionales. Esto se hace mediante tablas, una tabla para especificar cada requisito. Primero se especifican los requisitos funcionales, y luego los no funcionales, separando cada categoría con un título y utilizando la tabla de especificación de requisitos incluida en la plantilla. Luego de esto, se desarrollan las siguientes subsecciones:
- Requisitos comunes de las interfaces: Descripción detallada de todas las entradas y salidas del sistema. Se detallan las siguientes subsecciones:
- Interfaces de usuario: Describe la apariencia y comportamiento de la UI.
- Interfaces de hardware: Especifica conexiones con componentes físicos.
- Interfaces de software: Detalla integraciones con otros sistemas.
- Interfaces de comunicación: Explica protocolos y métodos de comunicación.
- Requisitos funcionales: Detalla las funciones específicas del sistema, incluyendo entradas, procesos y salidas. Estas funcionalidades ya se especificaron anteriormente, pero aquí se describe las actividades que realiza cada funcionalidad. Se hace por cada requisito funcional.
- Requisitos no funcionales: Estos requisitos también sse especificaron anteriormente, pero, aquí se clasifican en las siguientes categorías:
- Rendimiento: Especifica tiempos de respuesta, throughput, etc.
- Seguridad: Describe medidas de protección y control de acceso.
- Fiabilidad: Indica la frecuencia de fallos permitida.
- Disponibilidad: Especifica el tiempo de funcionamiento requerido.
- Mantenibilidad: Define cómo se realizará el mantenimiento del sistema.
- Portabilidad: Indica la facilidad de transferir el sistema a otras plataformas.
- Otros requisitos: Cubre aspectos adicionales como requisitos culturales, legales o políticos.
Proporciona espacio para información adicional relevante que no encaja en las secciones principales.
Plantilla del estándar IEEE 830
La plantilla del estándar IEEE 830 se puede observar y descargar mediante el siguiente botón:
Integración de IA al estándar IEEE 830
¿De qué se trata?
ERS-IA es un proyecto que se enfoca en la adaptación y mejora de la especificación de requisitos de software utilizando inteligencia artificial. Inspirado en la necesidad de integrar la IA de manera efectiva en el desarrollo de software, ERS-IA proporciona un marco estructurado para asegurar que los requisitos de inteligencia artificial se consideren desde las etapas iniciales del desarrollo de sistemas de software.
La integración de requisitos de inteligencia artificial en el proceso de desarrollo de software es un proyecto que surge como una respuesta a la creciente complejidad en el desarrollo de sistemas que incorporan IA, un campo que exige precisión y un enfoque meticuloso para garantizar la funcionalidad óptima dentro de cualquier entorno de desarrollo. Utilizando el estándar IEEE 830 como base, esta es una modificación del mismo, que adapta la especificacion de requisitos para que puedan documentarse requisitos de inteligencia artificial.
Se trata de una plantilla que incluye dos tablas de especificación de requisitos adaptadas para permitir al usuario especificar los requisitos respecto a la inteligencia artificial presentes en su proyecto. Una de las tablas fue diseñada para la especificación de requisitos funcionales, mientras que la otra, fue diseñada para la especificación de requisitos no funcionales.
Con el diseño de estas tablas, se buscó integrar los requisitos de inteligencia artificial dentro de la documentación de los proyectos de software, ya que no suelen ser documentados o especificados de una manera formal. Además, con estas tablas también se optimizó la plantilla de manera que se eliminaron redundancias innecesarias de secciones posteriores que se incluyen dentro de la plantilla original.
El proyecto incorpora la metodología GPEI (Goal-Prompt-Evaluate-Iterate) para el diseño de las dos tablas de especificación de requisitos, la cualoptimiza las interacciones con programas de IA generativa, asegurando que los resultados obtenidos sean confiables y de alta calidad.
Resultados: Plantilla de integración de requisitos de inteligencia artificial
Tabla de especificación de requisitos funcionales
La tabla para requerimientos funcionales, se diseñó con 16 parámetros; 11 parámetros más que en la tabla presentada en la plantilla original. El aumento de los parámetros fue debido a la integración que se hizo para especificar los requerimientos de inteligencia artificial. Al formar parte de una plantilla, dentro de la misma tabla se puede observar que se añadió una pequeña descripción de lo que se espera especificar en cada parámetro de la tabla.
La tabla proporciona una estructura clara y detallada para especificar los requisitos, buscando asegurar que todos los aspectos del sistema, tanto funcionales como de IA, sean comprendidos y abordados adecuadamente. Si bien es cierto que se estableció indicando que se pueden obviar algunos parámetros según las necesidades de cada proyecto, los parámetros específicos de IA fueron incluidos para la especificación para que el modelo de IA sea de alta calidad, preciso y confiable, por lo que se considera preferible que, cuando un requisito sea de inteligencia artificial, esos parámetros sean incluidos al menos en su mayoría.
La justificación del uso de cada parámetro se muestra a continuación:
Identifica de manera única cada requisito es crucial para evitar confusiones y duplicaciones. Un identificador único permite el seguimiento eficiente de los requisitos a lo largo del ciclo de vida del proyecto, facilitando la referencia y la gestión. Un ejemplo es: “RF-IA-001”
Proporciona un título claro y conciso para el requisito, lo que facilita la comunicación y la comprensión entre los miembros del equipo y los stakeholders. Un nombre descriptivo ayuda a recordar el propósito y el contexto del requisito rápidamente.
Diferencia entre requisitos de software, restricciones de software, requisitos de IA y restricciones de IA asegura que cada tipo de necesidad se aborde de manera específica. Esto es crucial para la claridad en proyectos complejos que integran IA, permitiendo que los equipos gestionen y prioricen adecuadamente los distintos tipos de requisitos.
Ofrece una explicación básica del requisito proporciona una visión general de lo que se espera lograr.
Proporciona una explicación detallada y completa del requisito, incluyendo su funcionalidad y comportamiento esperado. Una descripción clara y exhaustiva es fundamental para asegurar que el equipo de desarrollo entienda completamente lo que se debe implementar y cómo debe comportarse el sistema, especialmente en sistemas complejos que integran IA.
Especifica de dónde proviene el requisito (usuarios, regulaciones, estándares), lo que asegura que se reconozcan y respeten las necesidades y expectativas de todas las partes interesadas.
Identifica los requisitos no funcionales, de cualquier categoría, relacionados que son cruciales para garantizar la calidad y usabilidad del sistema.
Determinar la prioridad del requisito (Alta/Esencial, Media/Deseado, Baja/Opcional) facilita la planificación y la gestión de recursos, asegurando que se aborden primero los requisitos más críticos.
Describe los pasos detallados del flujo normal de eventos, proporcionando una guía clara para la implementación. Esto asegura que se cubran los escenarios previstos y que el sistema se desarrolle según las expectativas, además de identificar todas las actividades que podría cubrir. En sistemas de IA, esto puede incluir el proceso de entrenamiento del modelo y la inferencia en condiciones normales.
Esta sección de la tabla fue diseñada para describir paso a paso las acciones del flujo normal de eventos, pero de manera que visualmente el lector pueda entender las acciones que realiza el usuario y las que realiza el sistema, así, mediante una estructura con columnas separadas para diferenciar claramente las acciones de cada actor y sistema, se permite un seguimiento fluido de la interacción entre ellos. El formato que se debe seguir es colocar una acción en cada fila, una debajo de la otra siguiendo la secuencia del flujo, pero ubicándose en la columna correspondiente según se realice. Es decir, si la primera actividad la realiza el usuario, se coloca en la primera fila de su columna, y, si la segunda actividad la realiza el sistema, se coloca en la segunda fila de su columna, y así sucesivamente, sin pasar por alto la numeración.
Describe las variaciones posibles del flujo normal, asegurando que el sistema maneje adecuadamente situaciones excepcionales o imprevistas. Esto es esencial para prever y gestionar diferentes escenarios, aumentando la robustez y flexibilidad del sistema. En IA, esto puede incluir fallos en la obtención de datos o errores en el procesamiento del modelo.
En este caso, no se separan las acciones realizadas por el usuario y sistema, pero, al igual que con el flujo normal, se numeran las actividades que componen el flujo alterno. Esta numeración, se compone por el número de actividad del flujo normal de la cual nace el flujo alterno, sumado a una letra del abecedario en orden, lo que funciona como una segunda numeración que indica que, de la misma actividad normal, se pueden desplegar un conjunto de pasos alternos. De esta manera, la numeración es, por ejemplo: 1a, 1b, 1c, etc.
Esta sección, se usa para todos los flujos alternos que pueden derivar de el flujo normal, por lo que, se puede ver que se añadan pasos como por ejemplo: 1a, 1b, 1c, 2a, 2b, 3a, 3b, 3c, 3d. etc.
Describir las fuentes de datos (datasets) que se utilizarán para entrenar el modelo de IA es crucial para asegurar la calidad, cantidad y representatividad de los datos. Esto impacta directamente en el rendimiento y la precisión del modelo de IA, haciendo que sea un parámetro fundamental para el éxito del sistema.
Sin una especificación clara de la fuente de datos, la documentación del requisito será incompleta y poco clara. Esto puede llevar a malentendidos sobre la calidad y la adecuación de los datos, comprometiendo la precisión y la efectividad del sistema. Además, puede resultar en problemas durante el desarrollo y la validación del modelo, dado que los datos podrían no cumplir con los estándares necesarios para el entrenamiento y la evaluación adecuados.
Detallar los procedimientos de preprocesamiento necesarios para los datos asegura que los datos estén limpios y preparados adecuadamente para el entrenamiento del modelo de IA. Un preprocesamiento adecuado mejora la calidad de los datos y, por ende, el rendimiento del modelo.
La falta de especificación en el preprocesamiento puede resultar en datos mal preparados, lo que afectará negativamente la precisión y el rendimiento del modelo. Esto puede llevar a errores en el entrenamiento del modelo y a resultados subóptimos, afectando la capacidad del sistema para cumplir con los objetivos funcionales definidos en el proyecto.
Describir los métodos que se utilizarán para validar el modelo de IA asegura que el modelo sea preciso y fiable antes de su despliegue. Especificar estos métodos asegura que el modelo se evaluará de manera sistemática y rigurosa, proporcionando una base sólida para su validación.
Si no se especifican estos métodos de validación de manera clara, no se podrá evaluar adecuadamente el rendimiento del modelo en diversos escenarios. Esto puede resultar en un modelo que no generaliza bien a datos nuevos o que no cumple con los requisitos funcionales, afectando la utilidad y la eficacia del sistema en aplicaciones prácticas.
Definir criterios de éxito en los requisitos funcionales proporciona una referencia objetiva para medir si el modelo cumple con los objetivos establecidos. Especificar criterios de éxito permite una evaluación clara y objetiva del modelo en términos de su desempeño y funcionalidad.
La ausencia de la especificación temprana de criterios de éxito dificulta la evaluación de si el modelo está cumpliendo con los objetivos establecidos. Esto puede resultar en un modelo que no satisface las necesidades del proyecto o que no proporciona los resultados esperados, afectando la satisfacción del cliente y el éxito general del proyecto.
Incluir el análisis de sesgos en los requisitos funcionales es fundamental para garantizar que la construcción del modelo de IA sea guiada de manera justa y equitativa. Al especificar este análisis, se ayuda a abordar problemas de justicia y equidad desde el principio del desarrollo del sistema.
Sin un análisis de sesgos especificado, el modelo puede perpetuar sesgos existentes en los datos, lo que puede llevar a decisiones injustas o discriminatorias. Esto no solo afecta la equidad del sistema, sino que también puede dañar la reputación del proyecto y generar problemas éticos y legales.
La evaluación del impacto ético es esencial en los requisitos funcionales para asegurar que el uso del modelo de IA cumpla con principios éticos y no cause daño. La especificación de este análisis permite identificar y abordar posibles problemas éticos asociados con el sistema, promoviendo un desarrollo responsable.
La falta de evaluación del impacto ético puede llevar a problemas serios como violaciones de privacidad o decisiones injustas. Esto puede tener implicaciones negativas para la aceptación del sistema y la conformidad con las normativas legales y éticas, afectando la viabilidad y la reputación del proyecto.
Tabla de especificación de requisitos no funcionales
Aunque se diseñó similar a la tabla anterior, esta tabla tuvo unos cambios diseñados únicamente para especificar requisitos no funcionales. Constó con 14 parámetros, y, al igual que con el diseño anterior, en la plantilla realizada, se añadió esta tabla junto con una pequeña descripción de lo que se espera especificar dentro de cada parámetro de la misma. Algo que se consideró en este diseño fue que, en el parámetro “Categoría”, se añadieron las clasificaciones de requisitos no funcionales establecidas dentro del estándar IEEE 830, para omitir redundancias posteriores.
De igual manera que la tabla para requerimientos funcionales, la estructura de esta se diseñó de manera clara y detallada para el proceso de especificación, con el mismo objetivo de asegurar los aspectos del sistema no funcionales y de IA, sean comprendidos y abordados de manera apropiada. Aunque en la tabla para requisitos no funcionales también se pueden obviar algunos parámetros según las necesidades de cada proyecto, los parámetros específicos de IA fueron incluidos para la especificación para que el modelo de IA no pase por alto las consideraciones de la inteligencia artificial aun cuando se trata de este tipo de requisitos, por ende, en estas tablas también debería considerar preferible que, al menos mayoritariamente, esos parámetros sean incluidos cuando un requisito sea de inteligencia artificial.
La justificación del uso de cada parámetro se muestra a continuación:
Identifica de manera única cada requisito es crucial para evitar confusiones y duplicaciones. Un identificador único permite el seguimiento eficiente de los requisitos a lo largo del ciclo de vida del proyecto, facilitando la referencia y la gestión. Un ejemplo es: “RNF-IA-001”
Proporciona un título claro y conciso para el requisito, lo que facilita la comunicación y la comprensión entre los miembros del equipo y los stakeholders. Un nombre descriptivo ayuda a recordar el propósito y el contexto del requisito rápidamente.
Proporciona un título claro y conciso para el requisito, lo que facilita la comunicación y la comprensión entre los miembros del equipo y los stakeholders. Un nombre descriptivo ayuda a recordar el propósito y el contexto del requisito rápidamente.
Ofrece una explicación básica del requisito proporciona una visión general de lo que se espera lograr.
Proporciona una explicación detallada y completa del requisito, incluyendo su funcionalidad y comportamiento esperado. Una descripción clara y exhaustiva es fundamental para asegurar que el equipo de desarrollo entienda completamente lo que se debe implementar y cómo debe comportarse el sistema, especialmente en sistemas complejos que integran IA.
Especifica de dónde proviene el requisito (usuarios, regulaciones, estándares), lo que asegura que se reconozcan y respeten las necesidades y expectativas de todas las partes interesadas.
Es fundamental para estructurar y organizar los requisitos en función de sus características y objetivos específicos. Este parámetro permite clasificar los requisitos no funcionales en las categorías establecidas como Rendimiento, Seguridad, Fiabilidad, Disponibilidad, Mantenibilidad y Portabilidad. Esta clasificación en estas mismas 6 categorías forma parte del estándar IEEE 830, por lo que es fundamental especificarla, aun cuando originalmente se especificaba en secciones posteriores.
Determinar la prioridad del requisito (Alta/Esencial, Media/Deseado, Baja/Opcional) facilita la planificación y la gestión de recursos, asegurando que se aborden primero los requisitos más críticos.
En los requisitos no funcionales, especificar la fuente de datos es importante para definir cómo se manejarán y evaluarán aspectos como el rendimiento y la seguridad del sistema. Conocer la fuente de datos permite asegurar que los datos sean adecuados para realizar pruebas efectivas y que los resultados sean confiables.
Especificar el preprocesamiento de datos en los requisitos no funcionales asegura que los datos se preparen de manera adecuada para las pruebas y evaluaciones del sistema desde etapas tempranas. Esto incluye la limpieza y transformación de datos para que las pruebas sean precisas y representativas de las condiciones de operación del sistema.
Sin una especificación clara del preprocesamiento, los datos utilizados en las pruebas pueden ser inconsistentes o inadecuados, lo que puede llevar a una evaluación errónea de aspectos no funcionales como el rendimiento y la seguridad. Esto puede afectar la capacidad del sistema para cumplir con los requisitos no funcionales establecidos.
Los métodos de validación en los requisitos no funcionales son esenciales para evaluar cómo el sistema cumple con los estándares de rendimiento, escalabilidad, y seguridad. Especificar estos métodos garantiza que el sistema se pruebe de manera rigurosa y que se verifique su capacidad para operar bajo las condiciones esperadas.
La ausencia de métodos de validación puede resultar en una evaluación inadecuada del sistema en relación con los aspectos no funcionales. Esto puede llevar a problemas de rendimiento y seguridad que no se detectan hasta que el sistema está en producción, afectando su efectividad y confiabilidad.
Definir criterios de éxito para los requisitos no funcionales proporciona un marco claro para medir si el sistema cumple con los requisitos establecidos en términos de rendimiento, seguridad y otros aspectos. Esto ayuda a garantizar que el sistema cumple con las expectativas y los estándares no funcionales.
Sin criterios de éxito, la evaluación de los aspectos no funcionales del sistema puede ser ambigua y subjetiva. Esto puede llevar a una falta de claridad sobre si el sistema cumple con los requisitos y puede resultar en problemas de calidad y desempeño que afectan la viabilidad del proyecto.
En los requisitos no funcionales, el análisis de sesgos ayuda a identificar cualquier sesgo potencial que pueda afectar el rendimiento o la equidad del sistema. Especificar este análisis asegura que se aborden los problemas de sesgo en la evaluación del sistema,
La falta de un análisis de sesgos puede llevar a problemas de equidad y justicia en el sistema, afectando su aceptación y funcionamiento. Los sesgos no identificados pueden comprometer la efectividad del sistema en diferentes contextos y escenarios, afectando su rendimiento general.
Evaluar el impacto ético en los requisitos no funcionales es crucial para garantizar que el sistema opere de manera responsable y conforme a principios éticos. Especificar este análisis permite identificar y mitigar problemas éticos potenciales que puedan surgir durante la operación del sistema.
Sin una evaluación ética adecuada, el sistema puede tener consecuencias imprevistas que afecten su aceptación y conformidad con las normas legales y éticas. Esto puede llevar a problemas de privacidad, injusticias o rechazo del sistema, afectando su viabilidad y reputación.
Eliminación de secciones específicas del estándar IEEE 830
Sección “3.2 Requisitos funcionales”
La sección “3.2 Requisitos funcionales” de la plantilla original del estándar, se vuelve redundante una vez establecidas las tablas de especificación anteriores. Esta sección se encargaba de especificar las actividades específicas de cada requerimiento.
La tabla para requerimientos funcionales contenía dos parámetros tomados de la tabla conocida para la especificación de casos de uso: Flujo Normal y Flujo Alternativo. Al añadir estos parámetros, las actividades específicas de las que cada requerimiento funcional debe encargarse, ya se indicaban y establecían dentro de la misma tabla, por lo que se eliminó por completo la necesidad de proporcionar nuevamente estos detalles importantes de cada requisito en una sección aparte, aumentando la facilidad de comprender cada requisito observando una única sección.
Sección “3.3 Requisitos no funcionales”
La sección “3.3 Requisitos no funcionales” de la plantilla original del estándar, se vuelve redundante una vez establecidas las tablas de especificación anteriores. Esta sección se encargaba de clasificar el cada tipo de requerimiento no funcional.
Se tomó en cuenta, al momento de eliminar esta sección, que el objetivo principal de la misma era clasificar los requisitos no funcionales en sus 6 categorías: Rendimiento, Seguridad, Fiabilidad, Disponibilidad, Mantenibilidad y Portabilidad. Al incluir en la tabla diseñada las clasificaciones de requisitos no funcionales, no solo se optimizó el proceso de gestión al tener toda la información en una misma tabla, sino que se determinó que la sección se volvería obsoleta y redundante, por lo que su eliminación se consideró apropiada.
Plantilla del estándar IEEE 830 con la integración de requisitos de inteligencia artificial
La plantilla del estándar con integración de requisitos de IA se puede observar y descargar mediante el siguiente botón:
Plantilla dinámica para completar en línea
La misma plantilla del estánda con integración re requisitos de IA, se desarrolló en una página web dinámica para que el usuario pueda completar el documento desde la misma, y al final, descargar el documento. Se puede visitar la página accediendo al siguiente enlace: https://computacion.unl.edu.ec/srs/.
Equipo de Invetigación
La presente investigación fue desarrollada en su totalidad por:
- Ing. Pablo Fernando Ordóñez Ordóñez: Director de la carrera de Computación y director especialista del trabajo de integración curricular. Su rol fue crucial en la orientación técnica y la validación de los resultados obtenidos durante la investigación. Diseño el desarrollo de la Revisión Sistemática de la Literatura realizada para la contextualización de la necesidad del tema de investigación, y el procedimiento de integración de inteligencia artificial en el proceso de desarrollode software.
- Yamilka Valeria Erazo Aleaga: Estudiante investigadora de la Unviersidad Nacional de Loja y principal autora del trabajo de integración curricular que dio lugar esta información. Encargada del desarrollo de la Revisión Sistemática de la Literatura realizada para la contextualización de la necesidad del tema de invetigación, así como de haber desarrollado el procedimiento de integración de inteligencia artificial en el proceso de desarrollode software.