Ingeniería de requisitos software

Este recurso de aprendizaje es una lección creada originalmente como material didáctico del proyecto de aprendizaje Dirección y gestión de proyectos y sistemas informáticos.

La ingeniería de requisitos software consiste en el proceso que permite identificar los servicios y restricciones que formarán un sistema software.

Definición

La ingenieria de requisitos es la rama de la ingeniería del software o ingeniería de sistemas que se encarga de la realización de actividades en el intento de entender las necesidades exactas de los usuarios de un sistema y traducir éstas a precisas funciones y acciones que subsecuentemente serán usadas en el desarrollo del sistema. Loucopoulos, P (1995). System Requirements Engineering. McGraw-Hill.

Requisito

Según la IEEE un requisito es:

Una condición o capacidad requerida por un usuario para resolver un problema o alcanzar un objetivo.
Una condición o capacidad que debe cumplir o poseer un sistema o componente de sistema para satisfacer un contrato, estándar, especificación, o cualquier otro documento impuesto formalmente.
Una representación documentada de una condición o capacidad de lo explicado en los puntos 1 o 2.

IEEE Standard Glosary of Software Engineering Terminology. IEEE Computer Society Press. 1990.

Los requisitos pueden dividirse en:

Requisitos de usuario: Son frases en lenguaje natural o descripciones gráficas (diagramas) de los servicios que se espera que ofrezca el sistema y de sus restricciones.
Requisitos de sistema: Una descripción más detallada de los servicios exactos que se proporcionarán y sus restricciones. Estos requisitos sirven como contrato con el cliente. A su vez los requisitos de sistema pueden dividirse en requisitos funcionales, no funcionales y de dominio.
- Requisitos funcionales: Especifican lo que debe hacer o los servicios que debe proporcionar el sistema. Ejemplo: en un software de gestión de una biblioteca podrían ser requisitos funcionales dar de alta un cliente, alquilar un libro, devolver un libro, comprar un libro, etc. Los requisitos funcionales deben describir también cómo responderá el sistema ante estas distintas entradas, y su comportamiento frente a situaciones particulares.
- Requisitos no funcionales: Son restricciones de los servicios del sistema o funciones que ofrece. Ejemplo: en un software de gestión de compras de una tienda podrían ser requisitos no funcionales un tpv para pagar con tarjeta, un PC con memoria y espacio en disco para almacenar la base de datos de ventas, que sea capaz de atender a la vez a varios clientes, que no tarde más de X tiempo en gestionar una venta, etc.
- Requisitos de dominio: Estos requisitos reflejan características del dominio de la aplicación. Ejemplo: la forma en la que se comunicarán distintas partes de la aplicación, el tipo de datos con los que trabajará, etc.

Importancia de La Ingeniería de Requisitos

Permite gestionar las necesidades del proyecto en forma estructurada
Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultados
Disminuye los costos y retrasos del proyecto
Mejora la calidad del software
Mejora la comunicación entre equipos
Evita rechazos de los usuarios finales

Actividades de la Ingeniería de Requisitos

Actividades cíclicas que cumplen una buena practica de ingeniería de requisitos.

Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento preliminar de los requisitos de usuario.
Estudio de viabilidad: En esta fase se estima si el problema del usuario se podrá resolver con la tecnología disponible y si el sistema será rentable según el presupuesto del que se dispone.
Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se interactúa con clientes o usuarios para determinar los requisitos funcionales y no funcionales del sistema, además del dominio de la aplicación.
Especificación: En esta fase se documentan los requisitos con mayor detalle y precisión, de manera que sirva de base para un contrato entre el desarrollador y el cliente.
Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse de que son aceptados por el cliente. Esto implica verificar que los requisitos sean consistentes, que estén completos, que sean realistas y que puedan ser verificables.

Quispe-Otazu, Quispe-Otazu, Rodolfo (2011). Que es la Ingenieria de Requisitos.

Metodos de Análisis de Requisitos

Estudiamos básicamente dos, el de Pressman y el de Core.

Metodo de Pressman

Para Pressman, en el proceso de análisis de requisitos del software se puede identificar cinco tareas o etapas fundamentales:

Reconocimiento del problema: Se basa en el estudio inicial de las especificaciones del sistema y el plan del proyecto del software. El analista debe establecer un canal adecuado de comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la función primordial del analista en todo momento es reconocer los elementos del problema tal y como los percibe el usuario.

Evaluación y síntesis: Se centra en el flujo y estructura de la información, definir las funciones del software, determinar los factores que afectan el desarrollo de nuestro sistema, establecer las características de la interfaz del sistema y descubrir las restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la determinación del problema de forma sintetizada.

Modelización: Se basa en la creación de modelos del sistema que servirán para comprender mejor el proceso funcional, operativo y de contenido de la información. El modelo servirá de pilar para el diseño del software y como base para la creación de una especificación del software.

Especificación: Las tareas asociadas con la especificación intenta proporcionar una representación del software. Esto más adelante permitirá llegar a determinar si se ha llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar plasmados manuales.

Revisión: Es la etapa final del levantamiento de requisitos y se enfoca en demostrar que se ha llegado a un buen entendimiento de la forma de implementar con éxito el software. La documentación del análisis de requerimientos y manuales, permitirán una revisión por parte del cliente, la cual posiblemente traerá consigo modificaciones en las funciones del sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones previstas inicialmente.

Metodo de Core

Existen metodologías alternas como el Método CORE (Controlled Requirements Expression) que plantean un escenario más tecnico al realizar una ingeniería de requerimientos sobre un software. Este método es un conjunto de notaciones textuales y gráficas, con guías especificadas para la captura y validación de requerimientos del sistema, en las etapas iniciales del diseño del sistema.Es pensado como puramente una técnica de captura y análisis de requerimientos, aunque soporta algunos aspectos de diseño tales como estructuras de datos. CORE está basada en el principio de primero definir el problema a ser analizado y luego dividirlo en unidades o puntos de vista a considerar.

Esta metodología se basa en 7 aspectos:

Definición del problema: El propósito de la definición del problema es identificar los límites del mismo. Contiene detalles de los objetivos de la empresa de los usuarios del sistema, la base para la necesidad de un nuevo sistema, limitaciones de costo y tiempo, y quién va a ser el responsable de la revisión y aceptación de los resultados finales.

Estructuración del punto de vista: El propósito de esta etapa es descomponer el ambiente del sistema en los elementos para que el sistema propuesto pueda ser analizado desde los puntos de vista de todas las entidades que se comunican con él, la más importante de las cuales son los usuarios. Durante esta etapa, todas las entidades que son fuentes potenciales de información deben ser identificadas.

Colección tabular: Esta etapa es cuando la información sobre los flujos de datos entre los puntos de vista y el procesamiento de éstos son reunidos. Esto ayuda a establecer la totalidad y consistencia.

Estructuración de datos: En la etapa previa, los elementos de información que pasan entre los puntos de vista son referidos por sus nombres generales. En esta etapa, se da una vista más cercana al contenido, a la estructura y a la derivación de datos, al producir diagramas de estructura de datos.

Modelación individual de puntos de vista: Esta etapa puede dividirse en dos partes. Lo único concerniente a la primera es convertir las TCF'S en una notación diferente para producir los diagramas individuales del modelo de punto de vista. La segunda parte se refiere a agregar alguna información nueva perteneciente a flujos de datos internos, control de acciones y tiempo de acciones.

Modelación combinada de punto de vista: Esta etapa facilita el análisis de una secuencia de eventos de más de un punto de vista. Cada diagrama de modelo combinado de punto de vista producido durante esta etapa es una representación del procesamiento de información que ocurre entre puntos de vista.

Análisis de restricciones. : En esta etapa, se consideran restricciones adicionales tales como desempeño y seguridad. Éstas pueden afectar los diagramas de puntos de vista ya producidos. Las restricciones se documentan en una especificación de restricción del sistema

Técnicas de captura de requisitos

Entrevistas y cuestionarios
Brainstorming
Casos de Uso
JAD

Conclusiones

La Ingeniería de Requisitos es una compleja disciplina que trata de formalizar las actividades relacionadas con obtener la especificación de requisitos formales del sistema a desarrollar a base de interactuar y negociar con el cliente. Especialmente en las metodologías 'pesadas' o tradicionales del desarrollo de software es crucial contar con un conjunto de requisitos muy estables sobre los que construir el resto del proyecto.

Referencias

Méndez, Gonzalo. Ingeniería de Requisitos. Apuntes para la Facultad de Informática, Universidad Complutense de Madrid.

Participantes activos

Daniel Fariña (discusión) 10:16 10 oct 2014 (UTC)
Javier Mansilla 09:03 13 oct 2014 (UTC)
Esteban.alej (discusión) 21:27 14 oct 2014 (UTC)
Teresa Rodríguez (discusión) 11:30 30 oct 2014 (UTC)