Análisis de Requisitos

Análisis de requisitos: permite al ingeniero de sistemas especificar las características
operacionales del software (función, datos y rendimientos),indica la interfaz del software con
otros elementos del sistema y establece las restricciones que debe cumplir el software
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: S
1-reconocimiento del problema,
2- evaluación y síntesis,
3- modelado,
4- especificación
5-revisión. Inicialmente, el analista
Los modelos creados durante el análisis de requisitos desempeñan unos papeles muy
importantes:
• El modelo ayuda al analista a entender la información, la función y el comportamiento del

sistema, haciendo por tanto más fácil y sistemática la tarea de análisis de requisitos.
• El modelo se convierte en el punto de mira para la revisión y por tanto la clave para
determinar si se ha completado, su consistencia y la precisión de la especificación.
• El modelo se convierte en el fundamento para el diseño, proporcionando al diseñador una

representación esencial del software que pueda trasladarse al contexto de la implementación
TFEA: significa Técnicas para facilitar las especificaciones de una aplicación. Es una variación de
entrevistas que tiene como objetivo identificar el problema, proponer elementos de solución,
negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de solución.
Hoy en día, las TFEA son empleadas de forma general por los sistemas de información, pero la
técnica ofrece un potencial de mejora en aplicaciones de todo tipo.
Se han propuesto muchos enfoques diferentes de TFEA2. Cada uno utiliza un escenario
ligeramente diferente, pero todos aplican alguna variación en las siguientes directrices básicas:
• la reunión se celebra en un lugar neutral y acuden tanto los clientes como los
desarrolladores.
• se establecen normas de preparación y de participación.
• se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos
importantes, pero lo suficientemente informal como para animar el libre flujo de ideas
• un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la

reunión.
• se usa un «mecanismo de definición» (que puede ser hojas de trabajo, gráficos, carteles o
pizarras).
• el objetivo es identificar el problema, proponer elementos de solución, negociar diferentes

enfoques y especificar un conjunto preliminar de requisitos de
la solución en una atmósfera que permita alcanzar el objetivo

DFC: se concentra en maxim izar la satisfacción del cliente» [ZUL92], Para con seguirlo, DFC
hace énfasis en entender lo que resulta valioso para el cliente y después desplegar estos
valores a lo largo del proceso de ingeniería. D FC identifica tres tipos de requisitos
En realidad, el DFC se extiende a todo el proceso de ingeniería [AKA90]. Sin embargo, muchos
conceptos DFC son aplicables al problema de la comunicación con el cliente a que se enfrenta
un ingeniero del software duran— te las primeras fases del análisis de requisitos
El DFC utiliza observaciones y entrevistas con el cliente, emplea encuestas y examina datos
históricos (por ejemplo, informes de problemas) como datos de base para la actividad de
recogida de requisitos. Estos datos se traducen después en una tabla de requisitos —
denominada tabla de opinión del cliente que se revisa con el cliente. Entonces se usa una
variedad de diagramas, matrices y métodos de evaluación para extraer los requisitos esperados
e intentar obtener requisitos innovadores [BOS91],
Principio del análisis: Durante las dos pasadas décadas, se han desarrollado un gran número
de métodos de modelado. Los investigadores han identificado los problemas del análisis y sus
causas y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de
heurísticas para solucionarlos. Cada método de análisis tiene su punto de vista. Sin embargo,
todos los métodos de análisis se relacionan por un conjunto de principios operativos:
1. Debe representarse y entenderse el dominio de información de un problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de

acontecimientos externos).
4. Deben dividirse los modelos que representan información, función y comportamiento de

manera que se descubran los detalles por capas (ojerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la

implementación
Aplicando estos principios, el analista se aproxima al problema sistemáticamente. Se examina

el dominio de información de manera que pueda entenderse completamente la función. Se
emplean modelos para poder comunicar de forma compacta las características de la función y
su comportamiento.
Selección del enfoque de creación de prototipos
El paradigma de creación de prototipos puede ser cerrado o abierto. El enfoque cerrado se

denomina a menu do prototipo desechable. Este prototipo sirve únicamente como una basta
demostración de los requisitos. Después se desecha y se hace una ingeniería del software con
un paradigma diferente. Un enfoque abierto, denominado prototipo evolutivo, emplea el
prototipo como primera parte de una actividad de análisis a la que seguirá el diseño y la
construcción. El prototipo del software es la primera evolución del sistema terminado
Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar si se puede crear
un prototipo del sistema a construir. Se pueden definir varios factores candidatos a la creación
de prototipos [BOA84]: área de aplicación, complejidad, características del cliente y del
proyecto'
Métodos y herramientas para el desarrollo de prototipos
Para que la creación del prototipo de software sea efectivo, debe desarrollarse rápidamente
para que el cliente pueda valorar los resultados y recomendar los cambios oportunos. Para
poder crear prototipos rápidos, hay disponibles tres clases genéricas de métodos y herramienta
(por ejemplo, [AND92], [TAN89]):
Técnicas de Cuarta Generación . L as técnicas de cuarta generación (T 4G ) comprenden una

amplia gama de lenguajes de consulta e informes de bases de datos, generadores de
programas y aplicacion es y de otros lenguajes no procedimentales de muy alto nivel. Como las
técnicas T4G permiten al ingeniero del software generar código ejecutable rápidamente, son
ideales para la creación rápida de prototipos.
Componentes de software reutilizables. Otro enfoque para crear prototipos rápidos es

ensamblar, más que construir, el prototipo mediante un conjunto de componentes softare
existentes. La combinación de prototipos con la reutilización de componentes de programa
sólo funcionará si se desarrolla un sistema bibliotecario de manera que los componentes
existentes estén catalogados y puedan recogerse. Debería resaltarse que se puede usar un
prodiicto software existen te como prototipo de un «nuevo y mejorado » producto
competitivo. En cierta manera, ésta es una forma de reutilización en la creación de prototipos
software
Principios de la especificación:
La especificación, independientemente del modo como la realicemos, puede verse como un

proceso de representación. Los requisitos se representan de manera que como fin último
lleven al éxito de la implementación del software. A continuación, se proponen algunos
principios de especificación adaptados del trabajo de Balzery Goldman [BAL86]:
1. Separar la funcionalidad de la implementación.
2. Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y

las respuestas funcionales de un sistema a varios estímulos del entorno.
3. Establecer el contexto en que opera el software especificando la manera en que otros

componentes del sistema interactúan con él.
4 . Definir el entorno en que va a operar el sistema e indicar como «una colección de agentes
altamente entrelazados reaccionan a estímulos del entorno (cambios
de objetos) producidos por esos agentes» [BAL86],
5. Crear un modelo intuitivo en vez de un diseño o modelo de implementación.
6. Reconocer que «la especificación debe ser tolerante a un posible crecimiento si no es

completa». Una especificación es siempre un modelo — una abstracción— de alguna situación
real (o prevista) que normal mente suele ser compleja. De ahí que será
incompleta y existirá a muchos niveles de detalle.
7. Establecer el contenido y la estructura de una especificación de manera que acepte cambios.

Esta lista de principios básicos proporciona la base para representarlos requisitos del software.
Sin em bargo, los principios deben traducirse en realidad. En la siguiente sección examinan os
un conjunto de directrices para la creación de una especificación de requisitos.

Análisis de Requisitos

Cargado por

Copyright:

Formatos disponibles

Análisis de Requisitos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Análisis de Requisitos

Cargado por

Copyright:

Formatos disponibles

Análisis de requisitos: permite al ingeniero de sistemas especificar las características

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: S

1-reconocimiento del problema,

5-revisión. Inicialmente, el analista

• El modelo ayuda al analista a entender la información, la función y el comportamiento del

• El modelo se convierte en el fundamento para el diseño, proporcionando al diseñador una

• se establecen normas de preparación y de participación.

• un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la

• el objetivo es identificar el problema, proponer elementos de solución, negociar diferentes

la solución en una atmósfera que permita alcanzar el objetivo

1. Debe representarse y entenderse el dominio de información de un problema.

2. Deben definirse las funciones que debe realizar el software.

3. Debe representarse el comportamiento del software (como consecuencia de

4. Deben dividirse los modelos que representan información, función y comportamiento de

5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la

Aplicando estos principios, el analista se aproxima al problema sistemáticamente. Se examina

Selección del enfoque de creación de prototipos

El paradigma de creación de prototipos puede ser cerrado o abierto. El enfoque cerrado se

Técnicas de Cuarta Generación . L as técnicas de cuarta generación (T 4G ) comprenden una

Componentes de software reutilizables. Otro enfoque para crear prototipos rápidos es

La especificación, independientemente del modo como la realicemos, puede verse como un

1. Separar la funcionalidad de la implementación.

2. Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y

3. Establecer el contexto en que opera el software especificando la manera en que otros

de objetos) producidos por esos agentes» [BAL86],

5. Crear un modelo intuitivo en vez de un diseño o modelo de implementación.

6. Reconocer que «la especificación debe ser tolerante a un posible crecimiento si no es

incompleta y existirá a muchos niveles de detalle.

7. Establecer el contenido y la estructura de una especificación de manera que acepte cambios.

También podría gustarte

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.