PDF de programación - Análisis de requisitos y especificación de una aplicación - Ingeniería software - 4º de Físicas

Análisis de requisitos

Ingeniería Software
Ingeniería software

4º Físicas
4º de Físicas

2
0
0
8

Análisis de requisitos y

especificación de una aplicación

José M. Drake
Computadores y Tiempo Real

Santander, 2008

1

Ingeniería de Programación (4º Físicas) J.M. Drake

1

Análisis de requisitos

Objetivos de este tema

2
0
0
8

Obtención de deseos y
necesidades del cliente

Formular los requisitos

detallados

Formular los requisitos del cliente
(Requisitos C)
• Descripción textual
• Casos de uso
• Diagramas de actividad
• Diagramas de interacción

Mantenimiento

Integración
y validación

Identificar practicas

corporativas

Seleccionar

proceso

Análisis de requisitos

Prueba de unidades

Análisis

Codificación

Diseño

Santander, 2008

Ingeniería de Programación: Análisis de requisitos

J.M. Drake

2

El análisis global de los requisitos de una aplicación es un proceso de conceptualización y
formulación de los conceptos que involucra de forma concreta. Es una parte fundamental
del proceso de desarrollo de una aplicación, la mayor parte de los defectos encontrados en el
software entregado se originan en la fase de análisis de requisitos, y además son los mas
caros de reparar.
Siempre se ha discutido quién es el dueño de los requisitos: el cliente o el desarrollador.
Para gestionar esto, es habitual presentar el análisis de requisitos en dos secciones:
•Requisitos de cliente: documentan los deseos y necesidades de los clientes y se expresan en
lenguaje claro para él.
•Requisitos detallados: Determina los requisitos de manera específica y estructurada y están
destinadas específicamente hacia los desarrolladores.
Los objetivos de este tema son:
•Distinguir entre requisitos de clientes y requisitos detallados.
•Disponer de recursos para formular de forma clara y sistemática los requisitos del cliente.

- Casos de uso
- Diagramas de actividad
- Diagramas de interacciones, colaboraciones y flujo de datos.
- Descripción de las interfaces de usuario y sus protocolos de uso.

•Ser capaz de describir los documentos de la especificación de requisitos de software.
El resultado del proceso es el documento “Especificación de Requisitos Software”

Ingeniería de Programación (4º Físicas) J.M. Drake

2

Análisis de requisitos

Análisis de requerimientos.

2
0
0
8

requerimientos

El análisis de
trata de capturar y describir
detalladamente los requerimientos de funcionalidad y de calidad de
servicio del producto que se desarrolla.
La tarea la desarrollan entre los “expertos de dominio” (usuarios,
expertos de marketing, etc.) que saben lo que se quiere hacer y los
analistas que definen de forma no ambigua lo que se va a hacer.
Dentro de un proceso en espiral, no es una actividad única, sino una
tarea que se va desarrollando incrementalmente.
Los principales aspectos del análisis de requerimientos son:
! Identificar los paquetes de funcionalidad y detallarlos hasta hacerlos no ambiguos.
! Establecer los límites de la aplicación, identificando los agentes externos con los que

interacciona.

! Identificar las características de las interacciones mediante la elaboración de un

catálogo de mensajes y de sus semánticas.

Santander, 2008

Ingeniería de Programación: Análisis de requisitos

J.M. Drake

3

Para construir algo primero debe entenderse lo que debe ser ese algo. El proceso de
entender y documentar una aplicación software se llama “Análisis de requisitos”. En general
los requisitos expresan qué se supone debe hacer una aplicación y no intentan expresar
como logra estas funciones.
El análisis inicial de un sistema debe tratar de descubrir los requerimientos del producto
final que se desarrolla en detalle.
Unos de los principales objetivos de UML es hacer que este análisis sea lo suficientemente
intuitivo para que los clientes y expertos en el dominio que solicitan el producto puedan
comprenderlo, y lo suficientemente formal y riguroso para que se establezca una
formulación no ambigua que pueda ser utilizada por los técnicos que la desarrollan.
Los aspectos básicos que deben tratarse en esta fase son:
•Determinar los paquetes de funcionalidad y de la calidad de servicio del producto,
formulados de una forma independiente de su implementación, y refinar y detallar estas
especificaciones hasta que den lugar a una especificación no ambigua del producto que se
desarrolla.
•Identificar los actores externos al sistema que interactúan con la aplicación de forma
relevante.
•Identificar la semántica y las características de los mensajes que intercambian los actores
con el sistema que se desarrolla.
•Refinar los protocolos de interacción que usan los actores para llevar a cabo las diferentes
transacciones que se pueden realizar con el sistema.
El análisis de requisitos es una necesidad, no un un lujo. Para apoyarlo considérese su efecto
sobre las pruebas del producto concluido. Si alguien le proporciona una caja negra con un
cable rojo, rosa y morado que sale de ella, sería imposible probarlo. No se sabe que hace,
Ingeniería de Programación (4º Físicas) J.M. Drake
para que sirve.

3

Análisis de requisitos

Proceso de análisis de requisitos

2
0
0
8

Identificar al cliente.
1.
2. Entrevistar al cliente.

! Identificar deseos y necesidades.
! Utilizar las herramientas de expresión de requisitos (las ofrecidas por

UML).

! Bosquejar las interfaces de usuario (protocolos y GUIs)
! Identificar las plataformas hardware que debe soportar el software.

3. Elaborar un documento de los requisitos de usuario (Debe

validarse con el cliente)
Inspeccionar los requisitos de usuario.

4.
5. Elaborar los requisitos detallados mediante documentos

gráficos y textuales.

Santander, 2008

Ingeniería de Programación: Análisis de requisitos

J.M. Drake

4

El proceso de análisis de requisitos requiere diferentes actividades de alto nivel y que son
desarrollados por múltiples agentes (usuarios, expertos de dominio, expertos de
marketing, programadores, etc.)

Para la formulación de las especificaciones existen diferentes estándar, el mas conocido es

el estándar ANSI, IEEE 830-1993.

Para todas las etapas se pueden utilizar métricas tales como:
• Tiempo dedicado a su análisis.
• Cantidad producida (páginas de requisitos, minutos de interacción con el cliente, etc.)
• Calidad deducida de la autoevaluación (Tasas de defectos en las inspecciones).

Estándar ANSI IEEE 830-1993
1.

Introducción

Propósito.

•
• Definiciones acrónimos y abreviaturas
•

▪ Alcance
▪ Referencias

Panorama
2. Descripción general

•

Perspectiva del producto:(Interfaces del sistema, del usuario, hardware,
software, de comunicación, restricciones de memoria, operaciones, requisitos
de adaptación)
Funciones del producto

▪ Características del usuario
▪ Suposiciones y dependencias

•
• Restricciones
• Distribución de requisitos

3. Requisitos específicos (Se desarrollará mas adelante)
4.
Ingeniería de Programación (4º Físicas) J.M. Drake

Información de apoyo.

4

Análisis de requisitos

Recursos para la especificación del sistema.

2
0
0
8

Para la especificación del sistema se usan tres tipos de
recursos:
! Descripción del proyecto: Documento textual que describe de forma
concisa el objetivo del sistema, su oportunidad de mercado y el análisis
de riesgos.

! Análisis del contexto: Modelo de objetos que

las
interacciones externas y los mecanismos de interacción física entre los
actores que constituyen el entorno y el propio sistema.

identifica

! Casos de uso: Recursos UML para describir la funcionalidad del
sistema. Identifican los límites del sistema a través de la captura de los
tipos de usuario, de los elementos básicos de funcionalidad a través de
casos de uso, y de los protocolos de interacción a través de diagramas
de secuencia o de interacción.

Santander, 2008

Ingeniería de Programación: Análisis de requisitos

J.M. Drake

5

Los sistemas interactúan con su entorno externo (operadores, usuarios, otros sistemas,
dispositivos, etc.) y la funcionalidad básica que tienen que ofrecer debe formularse en
función de este contexto y con independencia de la forma en que se construyen
internamente.
Existen tres vías que pueden utilizarse para realizar la formalización de los requerimientos:
•Descripción del proyecto: Es un paso previo que aunque es obvio tiene una gran
importancia, y consiste en generar un documento que de forma concisa resuma la
información inicial relativa al proyecto que se inicia. En él debe incluirse la naturaleza y
objetivo del proyecto, las características mas relevantes, su oportunidad de mercado, y un
análisis de los riesgos que conlleva. Debe ser un documento breve con solo dos o tres
páginas, pero que establece un punto de arranque en el que los diferentes responsables de su
ejecución (clientes, expertos de dominio y desarrolladores) tienen el mismo concepto sobre
lo que se desarrolla.
•Análisis del contexto: Trata de especificar la funcionalidad del sistema a través de la
descripción de las interacciones que se pueden producir entre el sistema y el entorno
externo. Se formula como diagramas de objetos en los que el sistema aparece como una caja
negra sobre la que se identifican los elementos de interacción (sensores y actuadores) y
también se identifican los actores externos que interactúan con él, así como los tipos de
mensajes que se producen definiendo su semántica y la información que transmiten.
•Casos de uso: Es el recurso específico de UML para describir la funcionalidad y las
características de calidad de servicio del sistema. Se basa en identificar los límites del
sistema a través de la captura de los actores, de los elementos básicos de funcionalidad a
través de casos de