El término especificación puede entenderse en dos partes. La primera de ellas se refiere a la asignación numérica de los requerimientos, y la segunda a la producción de los documentos, que es un proceso que debe ser sistemáticamente revisado, evaluado y aprobado.

Esta unidad se divide en seis partes; en la primera se menciona la relación entre los componentes; en la segunda, los principios; en la tercera, la representación y herramientas que se utilizan para la especificación. En la cuarta parte se expone la especificación de requerimientos del sistema; en la quinta, la especificación de requerimientos de software y en la última, el prototipo como técnica para la correcta identificación de la especificación de requerimientos.

Propósito general

Documentar los requerimientos utilizando herramientas y estándares adecuados.

Propósitos específicos

• Conocer la relación entre los elementos básicos para cuantificar los requerimientos y los documentos necesarios para documentar el proceso.
• Identificar los principios fundamentales para cuantificar los requerimientos y los estándares para documentarlos.
• Utilizar la forma de representar y las herramientas para especificar los requerimientos.
• Elaborar el documento de especificación de requerimientos del sistema.
• Elaborar el documento de especificación de requerimientos de software.
• Utilizar la técnica de prototipos para especificar los requerimientos.

Cómo se mencionó anteriormente, la especificación de requerimientos se divide en dos etapas. La primera describe los principios de la especificación de requerimientos que consisten en los criterios para cuantificarlos y los estándares que existen para tal fin.

La segunda etapa se refiere a la forma de representar los requerimientos y a las herramientas más comunes que existen para dicha tarea. En este contexto, los dos documentos principales de la especificación son la especificación de requerimientos del sistema y la especificación de requerimientos de software.

En la metodología unificada de desarrollo es importante destacar que los requerimientos son procesos en los que el trabajo se distribuye de principio a fin. Esta metodología es la base de cualquier otra metodología para el desarrollo de software y describe las fases y los pasos mínimos.

Es recomendable tener una guía para caracterizar los requerimientos y, posteriormente, los elementos mínimos de cada requerimiento. Por lo general, el proceso que se utiliza es el de levantamiento de requerimientos.

Posteriormente es importante saber cuáles son los documentos mínimos que debe contener la documentación para la especificación de requerimientos del sistema y del software.

En los siguientes subtemas se profundizará en cada una de estas dos etapas.

La especificación de requerimientos no solo hace referencia a la documentación, sino a los principios que rigen cada requerimiento.

El proceso de levantamiento de requerimientos tiene por objetivo describir los pasos mínimos que se deben cumplir para especificar los requerimientos.

Este proceso se divide en cuatro partes en las que se identifican los actores que interactúan con el caso de uso pasando por la forma resumida y casual de dicho caso de uso y finalizando con una descripción detallada. Conozca las cuatro fases del levantamiento de requerimientos.

Desde la metodología unificada de desarrollo se destaca que la documentación no es un proceso discreto en la ingeniería de software y menos lo es en la ingeniería de requerimientos. Por lo tanto, al tratarse de un proceso continuo, se debe documentar de manera adecuada desde la elicitación utilizando los estándares establecidos para tal fin.

Consulte el esquema interactivo para comprender los tres tipos de documentos que se recomienda tener en esta especificación.

A pesar de la gran variedad de normas que existen para representar la especificación de requerimientos, las más usadas son la representación UML para la especificación de requerimientos, y los estándares IEEE para la especificación de requerimientos de sistema y de software.

Otra de las normas que más se utiliza para la especificación y seguimiento de requerimientos es Rational Doors Next Generation, que fue desarrollada por IBM y suele utilizarse en la gerencia de proyectos de software y específicamente en la especificación de requerimientos.

El lenguaje unificado de modelado (UML) fue establecido por el consorcio OMG y define una representación gráfica para visualizar, especificar, construir y documentar los artefactos en un sistema, a lo largo de toda la metodología unificada de desarrollo.

El UML se utiliza en la especificación de requerimientos para realizar el levantamiento de requerimientos, donde se describen los actores, los usos y, por consiguiente, cómo se usan los casos.

En las imágenes que aparecen en pantalla se ilustran los elementos básicos de esta representación para el levantamiento de requerimientos.

El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) propone dos normas para la especificación de requerimientos: la IEEE 29148 y la IEEE 830.

1. IEEE 29148
   

   Propone un manejo de la documentación de los requerimientos y específicamente de los requerimientos del sistema y su relación con los de software.

   Esta norma se intitula «Estándar de ingeniería de software y del sistema: ciclo de vida del software en ingeniería de requerimientos», y su principal característica es que además de describir los requerimientos de sistema se basa en la metodología unificada de desarrollo para guiar el proceso.

2. IEEE 830
   

   Define los mínimos elementos que deben documentarse en la especificación de requerimientos de software, por ejemplo: los escenarios exitosos, los alternativos y los fallidos.

   El estándar IEEE 830 se conoce como el documento de especificación de requerimientos de software y comprende un listado de los requerimientos y del contexto de la solución, así como una descripción general del diseño por medio de los casos de uso y los escenarios.

Existe una amplia variedad de herramientas de software para la especificación de requerimientos y una de las más usadas es la Rational Doors Next Generation, desarrollada por IBM.

Esta herramienta tiene por objetivo la especificación de los requerimientos por medio de unidades lógicas conocidas como artefactos, las cuales describen los requerimientos y todos los detalles correspondientes. La Rational Doors Next Generation es muy usada debido a que permite obtener una perspectiva muy detallada de los casos de uso.

Consulte la ampliación temática para conocer otras herramientas que cumplen funciones similares a esta.

Un sistema es un conjunto de elementos que incluye el software, las personas, el hardware, el firmware, la técnica y los servicios, entre otros.

En cuanto a sistemas se refiere, uno de los estándares más usados es el IEEE 29148, en el que se describe la relación entre los diferentes requerimientos. En este documento existe un capítulo importante sobre el tema de los requerimientos del sistema, que se conoce como SyRS, iniciales que hacen referencia a la especificación de requerimientos del sistema y a la relación con los otros requerimientos.

La norma IEEE 29148 se divide en cinco partes: la introducción, las referencias, el listado de requerimientos del sistema, la verificación y los anexos.

En la introducción se determina el propósito, el alcance, las generalidades y las definiciones, y las generalidades se dividen, a su vez, en tres partes que son: contexto, funciones y características del usuario.

En la segunda, cuarta y quinta parte se especifican referencias, verificación y anexos, respectivamente. Finalmente, los anexos se dividen en dependencias, supuestos, acrónicos y abreviaciones.

La norma IEEE 29148 propone los mínimos requerimientos que debe tener el sistema por medio de un listado. Este listado es la base de la especificación de requerimientos.

Consulte la descripción de cada tipo de requerimiento según el estándar arriba mencionado.

Estos requerimientos comprenden lo que el software debe cumplir y, al igual que en la especificación de requerimientos del sistema, para la elaboración de estos requerimientos se utiliza una norma IEEE.

Uno de los estándares más usado para este propósito es el IEEE 830, en el que se describen los componentes mínimos para la especificación de los requerimientos de software. Este documento se conoce como SRS, sigla que hace referencia a la especificación de requerimientos de software.

Material de apoyo

La norma IEEE 830 se divide en seis partes: introducción, descripción general, requerimientos externos de interfaz, características del sistema, otros requerimientos no funcionales y apéndices.

El caso de uso es una descripción de la interacción entre los usuarios y el software. En este contexto y debido a la complejidad de la especificación se empieza con el listado de requerimientos funcionales o del producto para pasar a una descripción muy general y resumida de la interacción. Posteriormente se pasa a la casual, en la que describe la interacción más común del caso y, finalmente, se pasa a una descripción detallada y completa del caso de uso, que es la que se describe en la tabla que aparece en pantalla.

En la forma detallada se describen los componentes más importantes de la descripción del caso.

Actividad de aprendizaje

Acceda a una actividad que le permitirá constituir el escenario exitoso para un caso de uso.

Esta técnica permite hacer una simulación navegable del software para que la usen los involucrados directos de la solución.

Los prototipos se utilizan en la etapa de identificación de requerimientos para verificar si la solución incluye unos elementos mínimos que esperan los usuarios y que son necesarios para la organización. La documentación que se realiza sobre el entendimiento y aceptación del prototipo por parte de los usuarios se convierte en una guía adecuada para el diseño, construcción y pruebas del proyecto de software.

Es importante recordar que el prototipo no es el producto final del proyecto, sino el medio adecuado para ajustar algunos requerimientos funcionales.

La ventaja que ofrece esta técnica es que permite hacer ajustes en los casos de uso del software sin necesidad de implementarlos. Por otra parte, la principal desventaja es que el prototipo puede crear la falsa expectativa de que la solución ya está implementada.

En el transcurso de esta unidad se describieron los principios de la especificación de requerimientos, que consisten en los criterios para cuantificarlos, y los estándares que existen para este proceso.

Se mencionaron la forma de representarlos y las herramientas más comunes para hacerlo, y se describieron los dos documentos principales de la especificación: la especificación de requerimientos del sistema y la especificación de requerimientos de software.

Por último, se explicó la técnica de prototipos que se utiliza para validar y verificar la elicitación de requerimientos.

Pedagogía activa

Haga clic sobre el enlace para acceder a un ejercicio que le permitirá poner en práctica los conocimientos adquiridos en esta unidad.