análisis e ingeniería de requisitosai… · son restricciones de los servicios o funciones...

Análisis e Ingeniería de Requisitos – Tema 1 www.kybele.urjc.es

Análisis e Ingeniería de RequisitosTema 2: Introducción a la Ingeniería de Requisitos

Curso 2011-2012


Bibliografía Básica

� Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill, 2002 5ª Ed.

� Ingeniería del Software. Ian Sommerville,Addison Wesley, 2004ª Ed.

� Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Piattini et al., RA-MA, 1996.


Índice de Transparencias

� Introducción

• Definición de Requisitos

• Tipos de Requisitos

• Definición de Ingeniería de Requisitos

� Procesos de Desarrollo de Requisitos

• Identificación de Requisitos

• Análisis de Requisitos

• Especificación de Requisitos

• Validación de Requisitos


Introducción: Definición de Requisitos

¿Qué son los Requisitos?

Describen los servicios que debe proporcionar

el sistema y sus restricciones operativas.

� Un requisito puede ser una simple declaración abstracta de

alto nivel o bien una definición detallada y formal de una

función del sistema.

� Es necesario hacer una separación entre niveles de

descripción.


Introducción: Tipos de Requisitos

Tipos de Requisitos

Requisitos del Usuario (descripción de alto nivel)

Requisitos del Sistema (descripción detallada)

� Requisitos Funcionales

� Requisitos No Funcionales:

• Requisitos Del Producto

• Requisitos Organizacionales

• Requisitos Externos

� De Dominio



Requisitos del Usuario: descripciones, en lenguaje

natural o diagramas, de lo que se espera que el

sistema proporcione y las restricciones bajo las cuales

debe funcionar.

Requisitos del Sistema: establecen con detalle las

funciones, servicios y restricciones operativas del

sistema.

� Deben ser precisos.

� Definir exactamente qué es lo que se va a implementar.

� Puede ser parte del contrato entre el comprador y el

desarrollador.



� Ejemplo:



Requisitos Funcionales:

� Son declaraciones de los servicios que debe proporcionar el

sistema.

� Especifica la manera en que éste debe reaccionar a determinadas

entradas.

� Especifica cómo debe comportarse el sistema en situaciones

particulares.

� Pueden declarar explícitamente lo que el sistema no debe hacer.



Ejemplo:

Requisitos Funcionales1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la

base de datos o seleccionar un subconjunto de ella.

2. El sistema deberá proporcionar visores adecuados para que el usuario lea

documentos en el almacén de documentos.

3. A cada pedido se le deberá asignar un identificar único (ID_PEDIDO), que el

usuario podrá copiar al área de almacenamiento



Requisitos No Funcionales:

� No se refieren a funciones específicas que proporciona el

sistema.

� Son restricciones de los servicios o funciones ofrecidas por el

sistema (fiabilidad, tiempo de respuestas, capacidad de

almacenamiento, etc.)

� Generalmente se aplican al sistema en su totalidad.

� Surgen de las necesidades del usuario debido a restricciones de

presupuesto, políticas de la organización, necesidad de

interoperatividad, etc.



Requisitos No Funcionales: � Requisitos Del Producto:

• Especifican el comportamiento del producto. • Ejemplos: rapidez de la ejecución, capacidad de memoria, fiabilidad, etc.

� Requisitos Organizacionales:• Derivan de políticas y procedimientos existentes en la organización

del cliente y del desarrollador. • Ejemplos: Estándares de procesos, métodos de diseño, lenguajes de

programación, métodos de entrega, etc.

� Requisitos Externos:• Se derivan de factores externos al sistema y a su proceso de

desarrollo. • Ejemplos: Requisitos de interoperatividad, legislativos, éticos, etc.



� Ejemplo:

Requisitos No FuncionalesRequerimiento del producto:

8.1 La interfaz de usuario del LIBSYS se implementará como HTML simple sin marcos

o aplets Java.

Requerimiento organizacional:

9.3.2 El proceso de desarrollo del sistema y los documentos a entregar deberán

ajustarse al proceso y a los productos a entregar definidos en XYZCo-SP-STAN-95

Requerimiento externo:

10.6 El sistema no deberá revelar al personal de la biblioteca que lo utilice ninguna

información personal de los usuarios del sistema aparte de su nombre y número de

referencia de biblioteca.



Requisitos De Dominio:

� Provienen del dominio de aplicación del sistema.

� Reflejan características y restricciones del dominio de la

aplicación.

� Pueden ser funcionales o no funcionales.



� Ejemplo:

Requisitos de Dominio1. Deberá existir una interfaz de usuario estándar para todas las bases de datos

que estará basada en el estándar Z39.50

2. Debido a las restricciones en los derechos de autor, algunos documentos

deberán borrarse inmediatamente después de su llegada. Dependiendo de

los requerimientos del usuario, estos documentos se imprimirán de forma

local en el servidor del sistema para ser distribuidos de forma manual al

usuario o se enviarán a la impresora.



� Ejercicio 1:

1. Redacte un conjunto de requisitos funcionales para el sistema expendedor de billetes.

2. Redacte un conjunto de requisitos no funcionales para el sistemaexpendedor de billetes. Indicando su tipo.

3. Redacte un conjunto de requisitos de dominio para el sistema expendedor de billetes.


Introducción: Definición de Ingeniería de Requisitos

¿Qué es la Ingeniería de Requisitos?

Es el proceso para descubrir, analizar, documentar y verificar

los servicios que debe proporcionar el sistema y sus

restricciones.

� Define un proceso.

� Facilita la comprensión de lo que quiere el cliente.

• Analizando sus necesidades

• Confirmando su viabilidad

• Negociando la solución

• Especificando la solución sin ambigüedad

• Validando y Gestionando requisitos para que el sistema pueda ser operativo.


Proceso de Desarrollo de Requisitos

� Objetivo: Crear y mantener un documento de

requisitos del sistema.

� Define el conjunto estructurado de actividades de cuya

ejecución se obtiene y mantiene la especificación de

los requisitos.

El proceso de desarrollo (ingeniería) de requisitoscomprende (en general) 4 etapas:

1. Identificación o captura de requisitos

2. Análisis (y negociación) de requisitos

3. Especificación o documentación de requisitos

4. Validación de requisitos



Actores del proceso:

� Stakeholders: persona o grupo que se verá afectado

por el sistema, directa o indirectamente.

Usuarios finales del sistema

Gerentes

Ingenieros de software

Encargados de mantenimiento de sistemas relacionados

Reguladores externos

Expertos en el dominio

Representantes de trabajadores

Etc.



Ejemplo: Stakeholders del sistema para un cajero automático (ATM) de un banco



� Identificación o captura de requisitos

En esta etapa los ingenieros de software trabajan

con los clientes y los usuarios finales del sistema.

Determinar:

� el dominio de la aplicación

� qué servicios debe proporcionar el sistema

� rendimiento requerido del sistema

� restricciones de hardware

� etc.



� Análisis (y negociación) de requisitos:

Una vez recopilados los requisitos:� Se agrupan por categorías y se organizan

� Se estudia cada requisito en relación con el resto

� Se examina la consistencia, completitud y ambigüedad de los requisitos

� Se clasifican en base a las necesidades de los clientes/usuarios (negociación)

• Los clientes, usuarios y resto de los implicados deberán clasificar sus requisitos y discutir posibles conflictos

• Priorizar requisitos

• Compromiso final sobre el conjunto de requisitos a implementarEspecificación o documentación de requisitos



� Especificación o documentación de requisitos

Es un documento que define, de forma completa, precisa

y verificable, los requisitos, el comportamiento u otras

características de un sistema o componente de un

sistema.

� Debe incluir información veraz

� Debe comunicar dicha información de forma eficaz

� Describir correctamente todos los requisitos del software

� No describir ningún detalle del diseño del software, de su

verificación o de la dirección del proyecto que influyen en

los requisitos.



� Validación de requisitos

En esta etapa se intenta encontrar problemas con los requisitos

Se realizan verificaciones sobre la especificación de requisitos:

� Verificaciones de validez.

� Verificaciones de consistencia.

� Verificaciones de completitud.

� Verificaciones de realismo (presupuesto, tiempos)

� Verificabilidad.

Ejemplos: el sistema no se ajusta a estándares; se detectan nuevas inconsistencias o ambigüedades; etc.

análisis e ingeniería de requisitosai… · son restricciones de los servicios o funciones...

Documents