C3. PA2. REPORTE

Introducción.

En este tema abordaremos las distintas tareas y técnicas que se utilizan frecuentemente en la ingeniería de requisitos para desarrollar un software, cabe mencionar que la ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de las partes interesadas, que pueden entrar en conflicto entre ellos. Sin embargo, la Ingeniería de requerimientos también es contemplada en otras disciplinas, estando fuertemente vinculada con la administración de proyectos.

 

Tareas y técnicas de la ingeniería de requisitos

Se define como un conjunto de actividades en los cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.

Inicio:

Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.

Obtención:

Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son los objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día a día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:

Ø  Problema de ámbito

Ø  Problema de comprensión

Ø  Problemas de volatilidad

 

 Elaboración:

Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.

Negociación:

En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se priorizan, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.

Especificación:

Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.

Validación:

Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.

Gestión de requisitos:

Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.

Técnicas.

Entrevistas.

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.

Talleres.

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

 Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de uso

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).

Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.

Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadería.

No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro.

Ejemplo: abaratar costos de expedición.

Conclusión.

En conclusión, podemos decir que la ingeniería de requisitos estudia los requerimientos, funcionalidades de un software, dentro de las principales tareas y técnicas tenemos lo que es el inicio su principal objetivo es identificar el ámbito general del proyecto, la obtención es la parte donde los ingenieros recopila información sobre lo que se va a desarrollar, en la elaboración se define el modelo y se analiza todas las funciones que tendrá el software, así mismo se cuenta con una parte donde se negocian los requisitos y se establecen los principales criterios o requisitos del sistema, posteriormente se hace la especificación o la parte de documentar como funciona el sistema, y por último la validación que es donde se deben detectar errores.

 

Referencias.

Que es ingeniería de requisitos. (2021, 11 de octubre). en Wikipedia. https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

Zahuantitla, M. (2021). 2.2 Técnicas de la ingeniería de Requisitos - Fundamentos de Ingería de Software Maribel Zahuantitla Salas. Google.com. https://sites.google.com/site/fundamentosdeingendoftware/unidad-2-ingenieria-de-requisitos/2-2-tecnicas-de-la-ingenieria-de-requisitos

3.3 Tareas y técnicas de la ingeniería de requisitos. (2017). Blogspot.com. https://andoniandresperezdominguezfis.blogspot.com/2017/11/33-tareas-y-tecnicas-de-la-ingenieria.html