Ingeniería de Requerimientos: proceso para establecer servicios y restricciones del sistema. Según Cristía (2011), la ingeniería de requerimientos es la actividad que consiste en definir qué debe hacer el sistema, mediante la identificación, documentación y validación de los requerimientos, que son las características o capacidades que el sistema debe poseer para satisfacer un propósito específico.
Requerimiento: característica o capacidad del sistema para satisfacer un propósito. Es una descripción que especifica qué debe hacer el sistema, y siempre debe estar documentada y validada por el solicitante, asegurando que refleja las necesidades reales del usuario o cliente. Los requerimientos no son inventados por los ingenieros, sino que surgen de pedidos o deseos de los interesados, transformados en requerimientos mediante documentación y validación.
Requerimientos funcionales: describen interacciones entre sistema y ambiente. Estos requerimientos explicitan cómo debe comportarse el sistema ante estímulos del entorno, detallando las acciones o funciones que el sistema debe realizar. Ejemplos incluyen la apertura de puertas en un sistema de ascensores o la identificación de cuentas en un sistema de facturación, siempre en relación con el entorno del sistema, no en su implementación interna.
Requerimientos no funcionales: restricciones o atributos de calidad del sistema. Son atributos que el sistema debe cumplir, relacionados con su desempeño, seguridad, usabilidad, entre otros. No describen funciones específicas, sino cualidades o restricciones que el sistema debe tener, como la disponibilidad, seguridad o rendimiento, y también incluyen cualidades del negocio.
Interacción con interesados: comunicación esencial para definir requerimientos. La actividad de la ingeniería de requerimientos implica una interacción constante con los interesados en el sistema, ya que estos proporcionan los pedidos, deseos y necesidades que se transformarán en requerimientos. La comunicación mediante reuniones, prototipos y preguntas repetidas es fundamental para garantizar que los requerimientos sean correctos y relevantes.
La ingeniería de requerimientos es la segunda fase en el ciclo de vida de cascada, y su importancia radica en que permite definir qué debe hacer el sistema y bajo qué condiciones, estableciendo una base sólida para las etapas posteriores del desarrollo. Los requerimientos deben ser documentados y validados por el solicitante, asegurando que reflejen las necesidades reales del cliente y que sean comprensibles y aceptados por todos los interesados.
Es importante destacar que los ingenieros no originan los requerimientos, sino que los transforman de los pedidos o deseos de los usuarios o clientes. Esto implica mantener una comunicación constante y efectiva con los interesados, mediante reuniones, prototipos y validaciones, para captar correctamente sus necesidades y evitar malentendidos o requerimientos incorrectos.
Asimismo, los requerimientos siempre describen el entorno del sistema, no su implementación interna. Esto significa que en la documentación de requerimientos no se deben incluir detalles técnicos específicos de cómo se implementarán, como clases, tablas o subrutinas, sino que se enfocan en qué debe hacer el sistema en su contexto de uso.
La fase de ingeniería de requerimientos es crucial porque proporciona la base para definir el Modelo Estructural del sistema, que incluye la arquitectura y el diseño, aunque en la práctica, debido a limitaciones de tiempo, solo algunos requerimientos son considerados inicialmente. La correcta identificación, documentación y validación de los requerimientos garantizan que el sistema final sea correcto, útil y alineado con las expectativas del cliente.
La ingeniería de requerimientos es la base fundamental para definir qué debe hacer el sistema y en qué condiciones, y su éxito depende en gran medida de la interacción constante con los interesados para garantizar que los requerimientos sean válidos, relevantes y reflejen fielmente las necesidades del usuario.
Proceso de Ingeniería de Requerimientos: es el conjunto de actividades destinadas a obtener y gestionar los requerimientos del sistema. Este proceso incluye varias etapas que permiten identificar, analizar, especificar, validar y mantener los requerimientos a lo largo del ciclo de vida del proyecto, asegurando que los requisitos sean claros, completos y alineados con las necesidades del cliente y del negocio.
Productos de Ingeniería de Requerimientos: son los documentos y artefactos generados durante el proceso de ingeniería de requerimientos. Entre estos productos se encuentran el documento de requerimientos, que recopila, organiza y estructura toda la información obtenida, así como otros artefactos como prototipos, escenarios y listas de interesados. La calidad de estos productos influye directamente en el éxito del proyecto, ya que sirven como base para las fases posteriores de diseño, implementación y testing.
Ítem de configuración: en el contexto de ingeniería de requerimientos, los requerimientos se consideran ítems de configuración, lo que significa que deben ser elementos controlados en la gestión de cambios. Esto implica que cada requerimiento debe ser registrado, versionado y gestionado cuidadosamente para mantener la trazabilidad y garantizar que las modificaciones sean controladas y aprobadas, evitando confusiones o inconsistencias en el desarrollo del sistema.
Modelo Funcional: es la especificación de los servicios que el sistema debe proveer. Este modelo describe qué funciones o servicios debe realizar el sistema, sin entrar en detalles sobre su estructura interna. Es fundamental en las etapas iniciales del diseño, ya que establece las capacidades y comportamientos esperados del sistema desde la perspectiva del usuario o del cliente.
Modelo Estructural: se refiere a la arquitectura y diseño del sistema basados en los requerimientos. Este modelo describe cómo están organizados los componentes del sistema, sus relaciones y la estructura interna que permite soportar los servicios definidos en el Modelo Funcional. La elaboración del Modelo Estructural sigue al Modelo Funcional y proporciona una visión detallada del diseño técnico del sistema.
El proceso de ingeniería de requerimientos comprende varias actividades fundamentales: obtención, análisis, especificación, validación y gestión de requerimientos. La obtención implica recopilar información mediante técnicas como reuniones, prototipos y escenarios, asegurando que los interesados tengan claro el negocio detrás del sistema. El análisis y la especificación convierten esa información dispersa en un conjunto organizado y priorizado de requerimientos, que deben ser claros, completos, consistentes, correctos, actualizados y observables externamente. La validación es una etapa clave que se realiza durante todo el proceso, garantizando que los requerimientos reflejen fielmente las necesidades del cliente y que sean aceptados por él. La gestión de requerimientos implica controlar estos ítems de configuración, asegurando su trazabilidad y control de cambios a lo largo del ciclo de vida del proyecto.
Los productos generados en este proceso, principalmente el documento de requerimientos, son esenciales para el éxito del proyecto, ya que sirven como base para las fases siguientes: diseño, desarrollo y testing. La calidad de estos productos impacta directamente en el resultado final, incrementando las probabilidades de éxito y reduciendo costos asociados a errores o cambios tardíos.
El Modelo Funcional y el Modelo Estructural son etapas secuenciales en el ciclo de vida del desarrollo del sistema. Primero, se define qué servicios debe proveer el sistema (Modelo Funcional), y posteriormente, se diseña cómo esos servicios serán implementados en términos de arquitectura y componentes internos (Modelo Estructural). Este orden asegura que el diseño técnico esté alineado con las necesidades funcionales del usuario.
Es importante destacar que el proceso de ingeniería de requerimientos es iterativo y circular, permitiendo revisiones y ajustes continuos. La validación constante y la gestión controlada de los requerimientos son elementos clave para minimizar errores, reducir costos y aumentar la confianza en el éxito del proyecto.
La ingeniería de requerimientos debe entenderse como un proceso estructurado y controlado que produce artefactos fundamentales para el diseño y desarrollo del sistema, donde la gestión y calidad de los productos influyen decisivamente en el éxito del proyecto.
Ingenieros de Requerimientos: profesionales encargados de transformar los pedidos y necesidades del cliente en requerimientos claros y precisos. Su función principal es recopilar, analizar y documentar las necesidades del negocio y del sistema, asegurándose de que los requerimientos sean observables externamente, consistentes, actualizados, factibles, no ambiguos y validables. Estos ingenieros deben mantener una interacción constante con los interesados para garantizar que los requerimientos reflejen correctamente las necesidades del cliente y del negocio.
Interesados (Stakeholders): personas físicas o jurídicas que pueden tener influencia directa o indirecta sobre el sistema. Incluyen usuarios, clientes y otros afectados por el sistema. La identificación y participación activa de los interesados son fundamentales para captar sus deseos, validar requerimientos y asegurar que el sistema desarrollado satisfaga sus expectativas y necesidades reales.
Es imprescindible que los ingenieros de software no definan requerimientos sin interactuar con los interesados. La interacción continua con estos participantes permite comprender en profundidad sus necesidades y expectativas, y evita que los requerimientos sean ambiguos o incompletos. La realización de múltiples reuniones con los interesados es una actividad clave en este proceso. Durante estas reuniones, se pueden presentar prototipos, que son programas desechables que imitan algunos requerimientos funcionales, para facilitar la validación de los requerimientos por parte del cliente. La demostración de prototipos ayuda a aclarar dudas y a ajustar los requerimientos en función del feedback recibido.
Los interesados aportan deseos, expectativas y necesidades que deben ser documentados de manera clara y estructurada. Estos aportes, una vez validados en las reuniones, se convierten en requerimientos que guían el desarrollo del sistema. La validación de estos requerimientos con los interesados es un paso crucial para asegurar que el sistema final refleje verdaderamente las necesidades del negocio y de los usuarios.
La colaboración activa y constante entre los ingenieros de requerimientos y todos los interesados es esencial para que los requerimientos sean precisos, observables y alineados con las necesidades reales del negocio, garantizando así el éxito del proyecto.
Diseño: Es un documento técnico que se deriva de los requerimientos y tiene como finalidad describir la estructura del sistema. Es decir, el diseño toma los requerimientos y los transforma en una representación concreta de cómo será organizado el sistema, estableciendo la arquitectura, componentes y relaciones internas que permitirán su implementación.
Especificación: Es un detalle técnico que define de manera precisa cómo se implementarán los requerimientos. La especificación actúa como un puente entre el diseño y el programa, proporcionando instrucciones claras y concretas para que los desarrolladores puedan traducir los requerimientos en código fuente, asegurando que la implementación sea coherente con lo planeado.
Programa: Es el código fuente que implementa el diseño y los requerimientos. Es la materialización del trabajo técnico realizado en las fases anteriores, donde se codifican las funcionalidades, estructuras y comportamientos definidos en el diseño y la especificación, permitiendo que el sistema funcione en el entorno real.
Testing de aceptación: Son las pruebas basadas en los requerimientos que sirven para validar el sistema. Estas pruebas verifican si el sistema cumple con las expectativas y necesidades del cliente, asegurando que el producto final sea aceptable y funcional según los criterios establecidos en los requerimientos.
Los requerimientos constituyen la base fundamental para todas las fases posteriores del desarrollo del sistema. Es decir, tanto el diseño como la especificación se derivan directamente de los requerimientos, por lo que la calidad y precisión de estos últimos influyen de manera directa en la calidad del diseño y la especificación. Un requerimiento bien definido facilitará la creación de un diseño claro y una especificación detallada, reduciendo errores y ambigüedades.
El diseño y la especificación, a su vez, guían la implementación del programa. El diseño proporciona la estructura general y los componentes necesarios, mientras que la especificación detalla cómo deben implementarse estos componentes en código. La correcta relación entre estos documentos asegura que el programa final refleje fielmente los requerimientos originales.
Por otro lado, los requerimientos son esenciales para el testing de aceptación y la validación final del sistema. Sin requerimientos claros y completos, no sería posible definir criterios de prueba adecuados ni verificar que el sistema satisface las necesidades del cliente. La alineación entre requerimientos y pruebas garantiza que el producto entregado sea útil y cumpla con las expectativas.
Finalmente, la calidad de los requerimientos tiene un impacto directo en la calidad de todas las fases del desarrollo. Requerimientos precisos, completos y bien comunicados permiten un diseño eficiente, una implementación efectiva y un testing confiable, disminuyendo costos y conflictos durante el proyecto.
Los requerimientos actúan como el núcleo que conecta y condiciona todas las fases del desarrollo del sistema, desde el diseño hasta la validación, siendo su correcta definición y gestión esencial para el éxito del proyecto.
Límite práctico: Se refiere a la imposibilidad de obtener una lista completa y consistente de requerimientos al inicio del proyecto. Debido a la complejidad y a la naturaleza dinámica del proceso, no es factible definir todos los requerimientos desde el comienzo, ya que estos evolucionarán a medida que se avanza en el desarrollo y se comprenden mejor las necesidades del negocio y del sistema.
Tiempo razonable: Es la restricción temporal que se impone para definir los requerimientos en proyectos reales. Este límite busca evitar que la actividad de obtención de requerimientos se extienda indefinidamente, lo cual podría retrasar o paralizar el proyecto. La definición de un tiempo razonable ayuda a enfocar los esfuerzos en obtener los requerimientos más importantes en un plazo determinado, permitiendo avanzar hacia las siguientes fases del desarrollo.
Evolución de requerimientos: Se refiere a los cambios y ajustes que experimentan los requerimientos durante el desarrollo del sistema. A medida que los interesados y el equipo de desarrollo profundizan en el proyecto, surgen nuevas necesidades, se clarifican requisitos existentes y se modifican otros. La evolución es una característica natural y esperada en la ingeniería de requerimientos, y debe ser gestionada adecuadamente para mantener la coherencia y la calidad del sistema final.
Es prácticamente imposible tener todos los requerimientos completos y consistentes al inicio del proyecto. La complejidad inherente a la actividad, junto con la necesidad de entender en profundidad el negocio y las expectativas de los interesados, hace que la lista de requerimientos sea siempre incompleta y susceptible a cambios.
Por ello, los proyectos deben planificar considerando que los requerimientos evolucionarán a lo largo del tiempo. La gestión de esta evolución implica aceptar que los cambios son inevitables y que deben integrarse de manera controlada para no comprometer la calidad y el cumplimiento de los objetivos del sistema.
Intentar definir todos los requerimientos inicialmente puede resultar en retrasos o incluso en la paralización del proyecto. La búsqueda de una lista exhaustiva y definitiva en las etapas iniciales puede consumir demasiado tiempo y recursos, impidiendo avanzar en otras actividades críticas del desarrollo.
Reconocer que la ingeniería de requerimientos tiene límites prácticos y que la gestión de cambios y evolución es parte esencial del proceso permite a los equipos de proyecto adaptarse a las circunstancias reales y asegurar el éxito del sistema. La flexibilidad y la planificación para la evolución de los requerimientos son fundamentales para afrontar la complejidad inherente a esta actividad.
Impacto en el éxito del proyecto: La calidad de los requerimientos determina los resultados finales del sistema. La correcta captura y definición de estos requisitos es fundamental para que el proyecto tenga éxito, ya que los requerimientos establecen la base sobre la cual se diseña, implementa y prueba el sistema. Si los requerimientos son imprecisos o incompletos, el sistema resultante puede presentar dificultades de mantenimiento, vulnerabilidades o fallos en rendimiento, afectando directamente su éxito a largo plazo.
Modificaciones extensivas: Son cambios significativos en el sistema que suelen ser causados por requerimientos no funcionales que han sido ignorados o no considerados inicialmente. Estos cambios pueden afectar varias partes del sistema, requiriendo revisiones profundas en el diseño, la implementación y las pruebas, y suelen generar retrasos y costos adicionales. La omisión o mala identificación de requerimientos no funcionales, como seguridad, rendimiento o mantenimiento, incrementa la probabilidad de que se produzcan estas modificaciones extensivas.
Atributos de calidad: Son aspectos no funcionales del sistema que influyen en su mantenimiento, seguridad y rendimiento. Estos atributos determinan cómo debe comportarse el sistema en diferentes condiciones y cómo será su interacción con los usuarios y otros sistemas. La atención adecuada a estos atributos en los requerimientos es esencial para garantizar que el sistema sea robusto, seguro y eficiente, facilitando su mantenimiento y adaptabilidad futura.
Los requerimientos definen la base para el diseño, implementación y pruebas del sistema. La atención exclusiva a los requerimientos funcionales, sin considerar los no funcionales, es una causa común de fallos posteriores en el proyecto. La captura adecuada de los requerimientos, incluyendo los aspectos no funcionales, es crucial para evitar que el sistema sea difícil de mantener, inseguro o ineficiente. Además, fallar en la identificación y documentación de los requerimientos no funcionales puede generar modificaciones extensivas que impactan en el presupuesto, los plazos y la calidad del producto final.
Es importante destacar que los requerimientos no funcionales, como la seguridad, el rendimiento y la facilidad de mantenimiento, afectan directamente atributos de calidad que, a su vez, condicionan la sostenibilidad y éxito del sistema a largo plazo. La metodología de validación y validación cruzada, mediante prototipos y ejemplos, permite obtener y validar estos requerimientos de manera efectiva, asegurando que todos los interesados expresen sus expectativas y necesidades específicas. La correcta gestión de estos requerimientos garantiza que el sistema no solo funcione correctamente, sino que también cumpla con los estándares de calidad necesarios para su operación futura.
Valorar los requerimientos como el factor crítico que condiciona la calidad, mantenimiento y éxito del sistema a largo plazo es fundamental. La atención minuciosa a todos los aspectos de los requerimientos, especialmente los no funcionales, asegura que el sistema sea robusto, seguro y adaptable, minimizando modificaciones extensivas y maximizando las probabilidades de éxito del proyecto.
Prototipación rápida desechable: técnica que consiste en crear modelos funcionales de un sistema que, aunque son desechables, permiten obtener y validar los requerimientos funcionales de manera temprana en el proceso de desarrollo. Estos prototipos no se consideran definitivos, sino herramientas para facilitar la comprensión y ajuste de las necesidades del sistema.
Validación cruzada: método que asegura la coherencia y aceptación de los requerimientos mediante la comparación y revisión de los prototipos por parte de los interesados. Este proceso ayuda a verificar que los requerimientos reflejan correctamente las necesidades reales y que son comprendidos por todos los participantes en el proyecto.
Herramienta Repose: software diseñado para apoyar la prototipación rápida. Repose facilita la creación, modificación y gestión de prototipos mediante la utilización de archivos odg (OpenOffice.org Draw) para dibujar las interfaces y planillas de cálculo para definir comportamientos y relaciones entre formularios. Esta herramienta ayuda a que los prototipos sean desechables y fácilmente iterables.
Desarrollo de prototipos: proceso de creación de modelos funcionales que permiten la interacción con los interesados. La elaboración de estos prototipos implica definir los formularios en términos de datos de entrada, estado y salida, dibujar la interfaz gráfica (GUI) en archivos odg, y definir el comportamiento mediante planillas de cálculo. Los prototipos sirven para validar requerimientos y facilitar la comunicación entre los participantes del proyecto.
La prototipación rápida facilita la obtención y validación temprana de requerimientos funcionales mediante la creación de modelos que, aunque son desechables, no se desechan inmediatamente. Estos prototipos sirven para iterar en el proceso de definición, permitiendo a los interesados interactuar con versiones preliminares del sistema y detectar posibles errores o malentendidos en los requerimientos.
Los prototipos son considerados desechables porque su función principal es la validación y ajuste de requerimientos, no su uso final. Sin embargo, no se eliminan de inmediato, sino que se utilizan en ciclos iterativos para perfeccionar la comprensión del sistema y asegurar que los requerimientos reflejen las necesidades reales de los usuarios y stakeholders.
La validación cruzada es fundamental para garantizar que los requerimientos sean comprendidos y aceptados por todos los interesados. Este método implica revisar los prototipos con los usuarios y otros participantes, asegurando que los modelos sean coherentes con las expectativas y necesidades del sistema. La validación cruzada ayuda a detectar errores, malentendidos o requerimientos incompletos, permitiendo realizar ajustes antes de avanzar en el desarrollo.
Las herramientas como Repose apoyan la creación y modificación rápida de prototipos. Repose permite dibujar las interfaces gráficas en archivos odg, usando formas básicas y símbolos que representan controles de interfaz, y asignar colores específicos para datos de entrada, estado y salida. Además, facilita la definición del comportamiento del prototipo mediante planillas de cálculo, donde se especifican las interacciones y relaciones entre formularios, asegurando un proceso iterativo y controlado.
El desarrollo de prototipos implica crear modelos funcionales que permitan la interacción con los interesados, usando controles gráficos que representan datos de entrada (como botones y listas desplegables), datos de estado (variables globales compartidas) y datos de salida (información producida por el sistema). La creación de estos modelos ayuda a validar los requerimientos, detectar errores y ajustar las funcionalidades antes de la implementación definitiva.
El uso de prototipos y validación iterativa, apoyados por herramientas como Repose, asegura que los requerimientos reflejen correctamente las necesidades reales, facilitando la comprensión y aceptación por parte de todos los interesados en el sistema.
Interacción sistema-ambiente: Es la relación fundamental que describe cómo el sistema responde y se comporta ante estímulos provenientes del entorno. Esta interacción constituye la base de los requerimientos funcionales, ya que determina cómo el sistema recibe, procesa y genera respuestas a las entradas del usuario o de otros sistemas, asegurando que su comportamiento sea coherente con las expectativas y necesidades del entorno en el que opera.
Chequeos de validación de entrada: Son controles diseñados para verificar que los datos ingresados al sistema sean correctos, completos y adecuados antes de ser procesados. Estos controles garantizan que las entradas cumplan con los formatos, rangos y restricciones definidos, evitando errores, fallos o comportamientos indeseados durante la ejecución del sistema. La validación de entradas es esencial para mantener la integridad y confiabilidad del funcionamiento del sistema.
Secuencia de operaciones: Se refiere al orden exacto en que deben ejecutarse las funciones o pasos dentro del sistema para cumplir con un proceso determinado. La secuencia asegura que las operaciones se realicen en la lógica correcta, respetando dependencias y condiciones previas, lo cual es vital para obtener resultados esperados y mantener la coherencia en el comportamiento del sistema ante diferentes estímulos.
Respuestas a situaciones anormales: Incluyen el manejo de errores, desbordes y comunicaciones imprevistas o no esperadas durante la operación del sistema. Estas respuestas garantizan que el sistema pueda detectar, gestionar y comunicar adecuadamente las situaciones que no corresponden a la operación normal, minimizando fallos, evitando pérdida de datos y proporcionando información útil para la resolución de problemas.
Relación entrada-salida: Es la definición de cómo las entradas proporcionadas al sistema se transforman en salidas esperadas. Incluye fórmulas, secuencias y reglas que describen con precisión los resultados que se deben obtener en función de las entradas, asegurando que el comportamiento del sistema sea predecible y consistente con los requerimientos establecidos.
Los requerimientos funcionales describen claramente cómo debe comportarse el sistema ante estímulos específicos del entorno. Esto implica que cada interacción entre el sistema y su ambiente está regulada por reglas y procedimientos definidos, que aseguran respuestas correctas y coherentes. Para ello, se incluyen los chequeos de validación de entrada, que verifican que los datos ingresados sean correctos, evitando errores que puedan afectar el funcionamiento.
Asimismo, los requerimientos especifican la secuencia de operaciones que deben seguirse en cada proceso, garantizando que las funciones se ejecuten en el orden correcto para obtener los resultados deseados. En caso de situaciones anormales, como errores o desbordes, el sistema debe tener respuestas predefinidas que permitan gestionar estos eventos de manera controlada, minimizando impactos negativos y manteniendo la estabilidad.
Por último, los requerimientos establecen relaciones precisas entre las entradas y las salidas, mediante fórmulas y secuencias que definen claramente qué resultados se esperan en función de las entradas recibidas. Esto asegura que el comportamiento del sistema sea previsible, verificable y alineado con los objetivos funcionales.
Los requerimientos funcionales definen el comportamiento operativo y las interacciones básicas del sistema con su entorno, estableciendo reglas claras para la validación de entradas, la secuencia de operaciones, las respuestas ante situaciones anormales y las relaciones entre entradas y salidas.
Restricciones del sistema: Son limitaciones impuestas sobre la plataforma, el lenguaje o el entorno en el que se desarrolla y opera el sistema. Estas restricciones determinan los límites dentro de los cuales debe funcionar el sistema, afectando aspectos como compatibilidad, configuración y tecnologías utilizadas.
Cualidades del negocio: Se refieren a los aspectos que impactan la viabilidad y el valor del sistema desde una perspectiva empresarial. Incluyen factores como la sostenibilidad, la supervivencia, la internacionalización y la acompañabilidad, que influyen en la capacidad del sistema para adaptarse y sostenerse en el tiempo.
Validación de no funcionales: Es el proceso mediante el cual se verifica que el sistema cumple con las restricciones y atributos de calidad definidos. Esta validación asegura que las cualidades esperadas del sistema se hayan implementado correctamente y que las limitaciones impuestas se respeten, garantizando la calidad y el éxito del sistema.
Los requerimientos no funcionales establecen las restricciones y cualidades que el sistema debe cumplir, y son fundamentales para definir cómo debe comportarse el sistema más allá de sus funciones específicas. Estos requerimientos incluyen aspectos como la seguridad, el rendimiento y la disponibilidad, que son críticos para la operación efectiva del sistema. Además, son esenciales para asegurar la mantenibilidad, la escalabilidad y la aceptación del sistema por parte de los usuarios y administradores.
La validación de estos requerimientos no funcionales es tan importante como la de los requerimientos funcionales, ya que garantiza que las restricciones y atributos de calidad se hayan implementado correctamente y que el sistema pueda operar en las condiciones deseadas. La validación se realiza mediante escenarios específicos que miden aspectos como el tiempo de disponibilidad, la capacidad de recuperación, la seguridad y la usabilidad, entre otros.
Es importante entender que los requerimientos no funcionales definen las cualidades y restricciones que garantizan la calidad y el éxito del sistema, asegurando que este no solo funcione correctamente, sino que también sea confiable, eficiente y adaptable a las necesidades del negocio y del entorno.
Los requerimientos no funcionales establecen las cualidades y restricciones que aseguran la calidad, sostenibilidad y éxito del sistema más allá de sus funciones específicas, siendo esenciales para su mantenimiento, escalabilidad y aceptación en el entorno operativo.
Escenarios de calidad: Son descripciones detalladas que permiten especificar y analizar atributos no funcionales en contextos específicos. Estos escenarios ayudan a concretar cómo se comportará el sistema en situaciones particulares, facilitando la evaluación y mejora de atributos como disponibilidad, seguridad, desempeño, entre otros.
Disponibilidad: Se refiere al tiempo durante el cual el sistema está operativo y accesible para los usuarios. La disponibilidad se expresa en términos de métricas que indican qué porcentaje del tiempo total el sistema permanece funcional, permitiendo a los usuarios realizar sus tareas sin interrupciones.
Modificabilidad: Es la facilidad con la que se pueden realizar cambios en el sistema. Incluye aspectos como la facilidad para agregar nuevas funcionalidades, corregir errores o adaptar el sistema a nuevos requisitos, lo cual impacta directamente en la capacidad de mantenimiento y evolución del sistema.
Desempeño: Describe la capacidad del sistema para responder y procesar información bajo carga. Incluye métricas como la latencia, el tiempo de respuesta y la capacidad de procesamiento, que determinan qué tan eficiente y rápido es el sistema en condiciones normales y de alta demanda.
Seguridad: Es la protección del sistema contra accesos no autorizados y ataques. La seguridad abarca aspectos como la confidencialidad, integridad, autenticidad y no repudio, asegurando que los datos y servicios estén protegidos frente a amenazas internas y externas.
Testeabilidad: Se refiere a la facilidad con la que se puede probar el sistema y detectar fallos. Un sistema con alta testeabilidad permite controlar el estado interno, las entradas y observar las salidas, facilitando la identificación y corrección de errores mediante testing.
Los escenarios permiten especificar y analizar atributos de calidad concretos, facilitando la comprensión de cómo debe comportarse el sistema en diferentes situaciones. Cada atributo de calidad tiene características y métricas específicas que permiten medir su cumplimiento, por ejemplo, la latencia para desempeño o la probabilidad de detección de ataques en seguridad.
La definición clara de escenarios contribuye a la validación del sistema y a la mejora continua, ya que proporciona un marco para evaluar si los atributos de calidad cumplen con los requisitos establecidos. Además, los escenarios ayudan a valorar el impacto de estos atributos en la satisfacción del usuario y en los objetivos del negocio, asegurando que el sistema sea robusto, confiable y alineado con las expectativas.
Es importante destacar que los escenarios sirven como herramientas para concretar y gestionar atributos de calidad, permitiendo que estos sean medibles y verificables en contextos específicos. Esto, a su vez, favorece la toma de decisiones informadas durante el desarrollo, mantenimiento y evolución del sistema, garantizando su desempeño y confiabilidad a largo plazo.
Valorar los escenarios como herramientas para concretar y gestionar atributos de calidad resulta fundamental para asegurar que un sistema sea robusto, confiable y alineado con las necesidades del usuario y del negocio, facilitando su validación y mejora continua.
Caso de uso: "Un comportamiento del sistema que produce un resultado medible para al menos un actor" (SW01). Es decir, describe una interacción entre uno o más actores y el sistema que culmina en un resultado observable y verificable. La descripción de un caso de uso generalmente se presenta como una sucesión de pasos o acciones que muestran cómo el actor y el sistema interactúan para alcanzar un objetivo específico.
Requerimientos funcionales temporales: Son funciones o actividades que deben realizarse en momentos específicos o en secuencias particulares dentro del sistema. Aunque en el contenido no se ofrece una definición formal, se indica que estos requerimientos corresponden a actividades que ocurren en momentos determinados y que, en algunos casos, pueden ser descritos mediante casos de uso que consideran el tiempo como un actor o mediante el conteo del tiempo para iniciar ciertos procesos.
Forma de un caso de uso: Es una estructura textual que incluye varias secciones clave, principalmente: flujo de eventos, caminos alternativos, precondiciones y postcondiciones. La descripción se realiza en lenguaje natural, organizada en pasos enumerados que reflejan la secuencia de acciones del usuario y del sistema, y puede dividirse en camino básico y caminos alternativos. La forma busca facilitar la comprensión y el análisis del comportamiento esperado del sistema en diferentes escenarios.
Diseño orientado a objetos: Es un enfoque que utiliza los casos de uso como guía para estructurar y desarrollar el sistema. Aunque en el contenido no se profundiza en su definición, se menciona que los casos de uso ayudan a orientar el diseño del sistema, permitiendo que este sea modular y alineado con las funcionalidades requeridas desde la perspectiva del usuario.
Los casos de uso representan requerimientos funcionales desde la perspectiva del usuario, ya que describen cómo los actores interactúan con el sistema para lograr objetivos específicos. Esta perspectiva facilita entender qué funciones necesita el sistema y cómo deben realizarse esas funciones en un orden determinado, si es que el orden es importante. La estructura de los casos de uso ayuda a identificar funciones temporales y condiciones específicas, ya que al describir los pasos y caminos alternativos, se evidencian las diferentes situaciones que pueden ocurrir durante la interacción.
Su uso también favorece la comprensión y comunicación entre interesados, ya que presenta de forma clara y estructurada cómo el sistema debe comportarse en diferentes escenarios. Además, los casos de uso constituyen una base fundamental para el diseño orientado a objetos y el desarrollo modular, ya que permiten traducir las funcionalidades en componentes y objetos que cumplen con los requisitos definidos.
Es importante destacar que los casos de uso son especialmente útiles en proyectos pequeños o medianos, donde su descripción gráfica o textual puede ser manejable y efectiva. En proyectos grandes, sin embargo, se recomienda una descripción textual para dominar la complejidad y mantener la claridad en la documentación.
Los casos de uso son herramientas clave para capturar y comunicar las funcionalidades del sistema desde la perspectiva del usuario final, facilitando la comprensión del comportamiento esperado y sirviendo como base para un diseño orientado a objetos eficiente y modular.
IEEE 830-1998: es un estándar que proporciona una guía para la elaboración de la especificación de requerimientos de software. Este estándar establece cómo debe estructurarse un documento que describa de manera clara, completa y precisa los requerimientos necesarios para el desarrollo de un sistema de software, con el fin de facilitar la comunicación entre todos los interesados y asegurar la calidad del producto final.
Estructura del documento: se refiere a la organización recomendada para el contenido del documento de requerimientos, incluyendo las diferentes secciones y el tipo de información que debe contener cada una. La estructura ayuda a garantizar que todos los aspectos relevantes del sistema sean considerados y documentados de manera sistemática.
Secciones típicas: son las partes principales que conforman el documento de requerimientos según el estándar IEEE 830-1998. Incluyen la introducción, la descripción general del sistema, los requerimientos específicos y los apéndices. Cada sección tiene un propósito definido y contenido recomendado para facilitar la comprensión y validación de los requerimientos.
Importancia del estándar: radica en que asegura que la documentación de requerimientos sea clara, completa y consistente, lo cual es fundamental para el éxito del proyecto de desarrollo de software. La utilización de este estándar ayuda a reducir errores, malentendidos y omisiones, promoviendo una mejor comunicación entre los interesados y una mayor calidad en la especificación del sistema.
El estándar IEEE 830-1998 define claramente cómo debe estructurarse un documento de requerimientos para que sea efectivo. En primer lugar, establece que el documento debe incluir secciones específicas que describan el propósito, alcance y detalles técnicos del sistema. La sección de introducción debe explicar el objetivo del documento y el público destinatario, mientras que la descripción general debe contextualizar el producto en relación con otros sistemas y describir cómo operará en diferentes aspectos, como interfaces y modos de operación.
La sección de requerimientos específicos es fundamental, ya que allí se listan de manera organizada y estructurada todas las funciones y restricciones que debe cumplir el sistema. Esta organización puede basarse en diferentes criterios, como modos de operación, tipos de usuarios, servicios ofrecidos, estímulos o respuestas del sistema, o en una jerarquía funcional que agrupe las funciones por entradas, salidas o estructuras internas.
Además, la sección de apéndices puede incluir información adicional, como definiciones, siglas, referencias y otros datos complementarios que faciliten la comprensión del documento. La estructura recomendada del documento, según IEEE 830-1998, busca facilitar la comunicación clara y la validación entre todos los interesados, asegurando que los requerimientos sean entendidos y aceptados por todos los actores involucrados.
Por último, la importancia de seguir esta estructura radica en que promueve la calidad y la consistencia en la documentación, lo cual es crucial para que el proceso de desarrollo sea eficiente, para la gestión de cambios futuros y para mantener la integridad conceptual del sistema a lo largo de su ciclo de vida.
Comprender y aplicar la estructura recomendada por el estándar IEEE 830-1998 es fundamental para elaborar documentos de requerimientos claros, completos y útiles, que sirvan como base sólida para todo el ciclo de vida del software y para una comunicación efectiva entre todos los interesados.
| Aspecto | Principios de ingeniería de requerimientos | Proceso y productos |
|---|---|---|
| Autor relevante | Cristía (2011) | No especificado |
| Definición clave | Establecer servicios y restricciones del sistema mediante identificación, documentación y validación | Conjunto de actividades para obtener, analizar, especificar, validar y gestionar requerimientos |
| Producto principal | Documento de requerimientos | Documento de requerimientos, prototipos, escenarios |
| Enfoque principal | Interacción con interesados para definir qué debe hacer el sistema | Gestión de cambios y trazabilidad de requerimientos |
| Modelo asociado | Modelo funcional (qué debe hacer el sistema) | Modelo estructural (cómo está organizado el sistema) |
| Aspecto | Requerimientos funcionales | Requerimientos no funcionales |
|---|---|---|
| Autor relevante | No especificado | No especificado |
| Definición clave | Describen interacciones entre sistema y ambiente | Restricciones o atributos de calidad del sistema |
| Ejemplos | Apertura de puertas en un ascensor, identificación en facturación | Seguridad, rendimiento, usabilidad |
| Enfoque | Funciones y comportamientos del sistema | Cualidades del sistema que deben cumplirse |
Teste tes connaissances sur Fundamentos de Ingeniería de Requerimientos avec 9 questions à choix multiples et corrections détaillées.
1. ¿Cuál es la causa principal que garantiza que los requerimientos del sistema sean correctos y relevantes en la ingeniería de requerimientos?
2. ¿Cuál de las siguientes afirmaciones describe mejor la ingeniería de requerimientos según Cristía (2011)?
Mémorisez les concepts clés de Fundamentos de Ingeniería de Requerimientos avec 9 flashcards interactives.
Principios de ingeniería de requerimientos
Definir servicios y restricciones mediante identificación, documentación y validación.
Ingeniería de Requerimientos — definición?
Proceso para establecer servicios y restricciones del sistema.
Proceso y productos
Actividades para obtener, analizar, especificar, validar y gestionar requerimientos, generando documentos y artefactos.
Importe ton cours et l'IA génère fiches, QCM et flashcards en 30 secondes.
Générateur de fiches