Ingeniería de requerimientos (IR)

La realización de este blog es con el fin de dar una perspectiva diferente acerca de los conceptos y las características de lo que es la Ingeniería de requerimientos, y así mostrar su importancia en el proceso de la creación de proyectos de desarrollo de software

En que consiste la Ingeniería de requerimientos 

Es el proceso de recopilar, analizar y verificar las necesidades del cliente, para un sistema de software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos.

La  importancia de los requerimientos

Los requerimientos son importantes para que el proyecto surja de manera eficiente, sino se tienen en cuenta estos podrían causar problemas, para ello debemos contar con una coherencia en la implementación de las herramientas de planeación, se deben de realizar estimaciones realistas, la arquitectura, diseño y desarrollo de software deben de tener una base firme, se deben de realizar revisiones periódicas en el proceso de desarrollo del proyecto, hacer un estudio previo de los requisitos del usuario, definir por completo el alcance del proyecto y crear un modelo de negociación antes de desarrollar el software

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. 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.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes  de verificación: inspección, análisis, demostración o pruebas.

La Trazabilidad en los Requerimientos

Un concepto clave en el proceso de gestión de cambios es la trazabilidad. Los requerimientos deben ser trazables, es decir, "rastreables". Se podría decir que un requerimiento es trazable si se pueden identificar todas las partes del producto existente relacionadas con ese requerimiento. Todos los requerimientos deberían ser trazables para mantener consistencia entre los distintos documentos de un proyecto.
Es importante conocer aspectos de los requerimientos tales como:

• Su origen (quién lo propuso).
• Necesidad (por qué existe).
• Relación con otros requerimientos (Dependencias).
• Relación con otros elementos (Dependencias).

Proceso de la Ingeniería de Requerimientos

Se han definido diversos modelos a nivel de toda la Ingeniería de Software, así tenemos para el desarrollo de aplicaciones web, de escritorio, o sencillamente se ha definido un estándar, pero en general, la mayor parte de estos procesos tienen un símil y lo único que buscan es recopilar la mayor cantidad de requerimientos correctos para así conformar una buena estructura que servirá de base para el desarrollo de un proyecto.

Estudio de viabilidad: Este permitirá rendir un informe tanto al equipo de desarrollo del proyecto como al usuario o cliente, donde se verificará si el proyecto vale la pena desarrollarlo. Es de vital importancia para la satisfacción de los objetivos del negocio.

Captura y Análisis: En esta fase el desarrollador o su equipo de desarrollo entran en contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema que se desea construir, además, se debe identificar cuáles son los servicios que prestará el sistema, su rendimiento, sus necesidades y restricciones, y cuáles son los objetivos esperados.

Especificación: Aquí se debe obtener un documento de especificación de requisitos, en cual se llega a definir de una forma completa, precisa y verificable cada uno de los requerimientos o necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware).

Validación: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos definen el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa solamente entran aquellos requisitos que se mencionaron ya en la especificación.

Gestión: Se realiza la comprensión y control de los cambios de cada una de los requisitos, sean estos requisitos estables (corresponden al estado del sistema) o volátiles (representan eventos que hacen que el sistema realice una función dada).

Relaciones entre administración de requerimientos y ciclos de vida

Al modelo o proceso de desarrollo de software se le conoce como ciclo de vida del software. porque describe la vida de un producto de software desde su concepción hasta su implantación, entrega, utilización y mantenimiento. Un modelo es una representación abstracta de un proceso.

Modelo en cascada  

Consta de 5 etapas, que son las actividades fundamentales en cualquier desarrollo de software:

• Análisis y definición de requerimientos. 
• Diseño del sistema y del software.
• Implementación y validación de unidades. 
• Integración y validación del sistema. 
• Funcionamiento y mantenimiento. 

Modelo evolutivo  

Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del software.

Existen dos tipos de desarrollo evolutivo: 

           

• Desarrollo exploratorio: El objetivo del proceso es trabajar de la mano con el               cliente para explorar los requerimientos y entregar un sistema final

• Prototipos desechables: El prototipo se centra en experimentar con los                         requerimientos del cliente que no se comprenden del todo. 
  

Modelo de componentes reutilizables  

En la mayoría de los proyectos existe algo de reutilización de software, esto sucede, generalmente, cuando las personas que trabajan en el proyecto conocen diseños de códigos similares al diseño que se requiere.

Artefactos de modelado para el Desarrollo Estructurado de Sistemas

El objetivo es lograr una definición completa del sistema en términos de funciones, estableciendo los datos  de entrada y salida  correspondientes para el análisis  del dominio de la información.

Caso de uso

Es una secuencia de interacciones  que se desarrollan entre un sistema y sus actores.

Diagrama de clases

Es un tipo de diagrama y estructura estática que describe la estructura de un sistema morado.

Diagrama de objetos

Representan un único ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicación.

Diagrama de estado

Son útiles para indicar los eventos del sistema en los casos de uso.

Diagramas de secuencias

Muestra la interacción de un conjunto de objetos  en una aplicación a través del tiempo y se modela para cada caso de uso.

ARTEFACTOS DE MODELADO PARA EL DESARROLLO ORIENTADO A OBJETOS

El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo: es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

Un artefacto: es una información que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software.

MÉTODOS DE COMUNICACIÓN

Existen varios métodos de comunicación que se emplean para compartir la información entre los interesados del proyecto. De manera general, estos métodos pueden clasificarse en:

• Comunicación interactiva. Entre dos o más partes que realizan un intercambio de información de tipo multidireccional. Resulta la manera más eficiente de asegurar entre todos los participantes una comprensión común acerca de temas específicos, e incluye reuniones, llamadas telefónicas, videoconferencias, etc.

• Comunicación de tipo push (empujar). Enviada a receptores específicos que necesitan conocer la información. Esto asegura la distribución de la información, pero no garantiza que efectivamente haya llegado a la audiencia prevista ni que haya sido comprendida. Este tipo de comunicación incluye las cartas, los memorandos, los informes, los correos electrónicos, los faxes, los correos de voz, los comunicados de prensa, etc.

• Comunicación de tipo pull (halar). Utilizada para grandes volúmenes de información o para audiencias muy grande, que requieren que los receptores accedan al contenido de la comunicación según su propio criterio. Entre los métodos, se incluyen los sitios intranet, el aprendizaje virtual, los servidores de contenido, etc.

En función de los requisitos de comunicación, el director del proyecto decide qué métodos de comunicación deben utilizarse dentro del proyecto, cómo y cuándo hacerlo.

OBTENCIÓN Y VALIDACIÓN DE REQUERIMIENTOS

Los requerimientos funcionales describen una interacción entre el sistema y su ambiente, describen cómo debe comportarse el sistema ante determinado estímulo. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, también pueden declarar explícitamente lo que el sistema no debe hacer.

> 1ra reunión Negocio detrás del sistema Requerimientos en general

> Listar los interesados.

Desarrollar el 1er prototipo.

> Siguiente reunión Validar los requerimientos contra el prototipo Tal vez modificar el prototipo Obtener otros requerimientos

> Más requerimientos obtener Errores en el prototipo

> Desarrollar un nuevo prototipo

> Todo listo

> Fin Pasar los requerimientos a los diseñadores

OBTENCIÓN Y VALIDACIÓN DE REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales: describen una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema. Restringen los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, el tipo de proceso de desarrollo a utilizar, fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Los requerimientos no funcionales ponen límites y restricciones al sistema.

Los requerimientos no funcionales incluyen restricciones las restricciones son características que no pueden ser negociadas y que son impuestas por el cliente como guía o definición para el sistema atributos de calidad son propiedades o características del sistema que importan a los stakeholders y que por lo tanto afectaran el grado de satisfacción del sistema este tipo de requerimientos pueden ser evaluados con dos enfoques

factores de calidad (externo) -ejecución 

criterios de calidad (interno) - desarrollo

CASOS DE USO

Los casos de uso son una técnica para especificar el comportamiento de un sistema: “Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.” Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido. 

DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS

El estándar IEEE 830-1998 para el SRS(en inglés) o ERS (Especificación de requerimientos de software) es un conjunto de recomendaciones para la especificación de los requerimiento o requisitos de software el cuál tiene como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas.




Autores del blog:

• Cristhian Guzman Lopez  / E-mail:cristhianguzman93@gmail.com 
• Sebastian Pino
• David Loaiza / E-mail: davidloa_00@hotmail.com
• Joan Hernandez / E-mail: joanalexander1999@outloock.es