UNIDAD 2: ingeniería de requisitos

Definición: Requisito

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

Ingeniería de requerimientos

    El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos 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 los inversores, que pueden entrar en conflicto entre ellos.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante. Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto.

Tipos de Requerimientos

Los requerimientos de software pueden dividirse en 2 categorías: requerimientos funcionales y requerimientos no funcionales.

Requerimientos funcionales.

Son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Requerimientos no funcionales.

Requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. 

Características de un Requerimiento.

Es importante no perder de vista que un requerimiento debe ser:

Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no?

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

2.1.- Tareas de la ingeniería de requisitos

Se define como un conjunto de actividades en los cuales, utilizando tecnicas 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 os 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 d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:

1 Problema de ámbito

1 Problema de comprensión

1 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 prioriza, 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.

2.2 Técnicas de la ingeniería de requisitos

Se conocen varias técnicas para la ingeniería de requisitos, estas pueden ser aplicables a las distintas fases del proceso de la IR. Las técnicas más utilizadas son:

Entrevistas y cuestionarios:

Estos se emplean para reunir la información proveniente de personas o de grupos. El analista conversa con el encuestado y realiza preguntas relacionadas con varios aspectos de un sistema. Lo más común, los encuestados son usuarios de los sistemas existentes. El éxito que se tenga depende de la habilidad del entrevistador y de su preparación de la misma.

Sistemas existentes:

Consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido, podemos analizar las interfaces de usuario observando el tipo de información que se maneja y como es manejada.

Lluvia de ideas:

Este modelo se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema, la principal intención es generar muchas ideas, posteriormente se irán eliminando en base a distintos criterios como, “caro”, “impracticable”, “imposible” etc.

Prototipos:

Para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante alimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

Casos de uso:

Son una técnica para especificar el comportamiento de un sistema. Los casos de uso permiten describir la posible secuencia de interacciones entre el sistema y uno o más actores. Los casos de uso es una técnica que se basa en escenarios para la obtención de requerimientos, se ha convertido en una característica fundamental de la notación UML que es utilizado para describir modelos de sistemas orientada a objetos.

Herramientas automatizadas para la administración de requerimientos:

Las herramientas case (ingeniería del software asistida por computadora) se le conoce a todo aquel software que es usado para ayudar a las actividades del proceso de desarrollo del software. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificación de requisitos. Entre otras cosas estas herramientas permiten un control mayor en proyectos complejos, reducir costos y retrasos en los proyectos, ayudan a determinar la complejidad y los esfuerzos necesarios.

RequisitePro:

Es la herramienta tener un mayor control sobre los requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida del proyecto. Esta herramienta se integra con aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo.

2.3 modelado de requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se

Basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí:

Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.

Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.

Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.

Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

2.4.- herramientas case para la ingeniería de requisitos

Borland caliber analyst:

Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía borland. Por un lado están el caliber define(la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como a capturar las diferentes herramientas visuales, es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.

1 Case espec:

Esta herramienta está desarrollada por la empresa coda software.

Características:

Especificación, seguimiento de los requisitos, capacidad de rastres, importar y exportar archivos.

1 IRQA4:

Herramienta desarrollado por visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de la informática aparte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento).

1 Tiger pro:

Herramienta shoreware desarrollado para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los aspectos.

1 IBM rational requisite pro:

Esta herramienta desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramienta más completas y potentes dentro del análisis y la gestión de requisitos: una de las grandes ventajas que aporta este producto es la compatibilidad y algunos programas más usados.

1 Rambután:

Esta herramienta está basada en XML, realmente consta de un conjunto de aplicación para usuario final ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos ofrece las ventajas de aplicación para pal (PDA clases), portabilidad entre plataformas independientemente metodología, herramienta de distribución libre.