PDF de programación - Metodologías, procesos y entornos para sistemas de tiempo real - Master de Computación - Especificación de una aplicación

Análisis de requisitos

Metodologías, procesos y entornos para sistemas de tiempo real

Master de Computación

Especificación de una aplicación

José M. Drake
Computadores y Tiempo Real

Santander, 2012

1

Metodos, procesos y entornos para sistemas de tiempo real

1

Análisis de requisitos

Análisis de requisitos

El análisis de requisitos 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 términos y de sus semánticas.

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

2

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, para que
sirve.

Metodos, procesos y entornos para sistemas de tiempo real

2

Análisis de requisitos

Proceso de análisis de requisitos

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, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

3

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.

Información de apoyo.

Metodos, procesos y entornos para sistemas de tiempo real

3

Análisis de requisitos

Recursos para la especificación del sistema.

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, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

4

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 uso, y de los protocolos de interacción a través de diagramas de secuencia o de interacción.

Metodos, procesos y entornos para sistemas de tiempo real

4

Análisis de requisitos

Descripción del proyecto

Un proyecto que se inicia siempre debe partir de un documento breve
que lo describa y plantee sus principales características.
Sirve de contrato para que todos los que participan en su promoción
tengan el mismo concepto sobre su contenido y objetivos.
El documento debe ser breve (2 o 3 páginas) y debe ser realizado por
una o dos personas y aceptado por todos los participantes.
Usuarios del producto
Responsable de la empresa
Programadores
El documento debe contener:
La naturaleza y objetivos del producto.
Las características más relevantes.
La oportunidad de mercado del producto.
Análisis de riesgos para el desarrollo del proyecto.

■ Los que encargan y financian el producto
■ Administradores

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

5

A las personas que tienen intereses en el producto que se desarrolla, le denominamos
interesados (stakeholders):
•Usuarios del producto: son aquellos que van a utilizar directamente el producto como operarios.
•Los que encargan o financian el producto
•Los directivos de la empresa en que se desarrolla el producto.
•Los administradores.
•Los desarrolladores siempre que utilicen la aplicación como forma de actualizar su tecnología.

Cada requisito debería ser:
•Expresado en el lenguaje del usuario.
•Incluido en una lista organizada que facilite su localización y acceso sea sencillo.
• Estar numerado y ser referenciado en el código.
•Ser verificable de forma aislada e ir acompañado de pruebas que posibiliten su verificación.

Metodos, procesos y entornos para sistemas de tiempo real

5

Análisis de requisitos

Descripción de sistema SCADA

La aplicación ScadaDemo supervisa un conjunto de hasta 16 magnitudes
f