1

INTRODUCCIÓN

El módulo de Análisis de Sistemas de Información desarrolla en el estudioso las

competencias necesarias para la primera etapa en el desarrollo de software,
correspondiente a la ingeniería de requerimientos, la cual realiza un análisis
detallado de los requisitos del cliente y el diseño mediante la incorporación de
herramientas UML. La ingeniería de requerimientos se realiza mediante dos
etapas: elicitación y diseño de los requerimientos.

La elicitación de los requisitos es un proceso de recolección de requerimientos y

se apoya en instrumentos como: muestras, entrevista, cuestionarios y prototipos.
Los anteriores tipos de instrumentos permiten representar los requerimientos del
cliente.

Después de la recolección de los requerimientos, se debe realizar un análisis para

determinar la viabilidad del desarrollo de Software. Para esta tarea se apoya el
Ingeniero de requerimientos, en las herramientas UML, se encuentra diferentes
tipos de modelos, de los cuales se tienen: modelo de análisis, modelo de
escenarios, modelo de clases y modelo de flujo de datos.

2
 COMPETENCIAS

§ Identifica los requerimientos necesarios para la solución del sistema.

§ Selecciona las principales técnicas de recolección de información.
§ Aplica las técnicas adecuadas de recolección de información en la
especificación de requerimientos del sistema de información.
§ Realiza el seguimiento de la metodología de especificación de requerimientos
§ Implementa las herramientas UML para el diseño de los requerimientos
identificados.
§ Construye el documento de especificación de requerimientos.

3
 ESTRUCTURA TEMÁTICA

Introducción

1. Ingeniería de Requerimientos ........................................................................... 6

1.1 Definición de requerimientos .......................................................................... 6
1.2 Tipos de requerimientos ................................................................................. 7
2. Dimensiones de los requerimientos ........................................................... 10
3. Proceso de Especificación de requerimientos .......................................... 11
3.1 Elicitación de Requerimientos. ..................................................................... 12
3.2 Análisis de Requerimientos. ......................................................................... 12
3.3 Especificación de Requerimientos. .............................................................. 13
3.4 Validación y Certificación de los Requerimientos. ........................................ 13
4. Instrumentos para la recolección de los requerimientos............................. 18
4.1. Muestra ....................................................................................................... 18
4.2. La entrevista ................................................................................................ 18
4. 3 Cuestionarios............................................................................................... 22
4.4 Prototipo de Software ................................................................................... 23
4.5. Diagramas de casos de uso ........................................................................ 24
5. Análisis de requerimientos ............................................................................. 25
6. Proceso de Análisis de Requerimientos........................................................ 26
6.1. Reconocimiento del problema ..................................................................... 27
6.2. Evaluación y síntesis ................................................................................... 27
6.3 Modelización de la evaluación y síntesis de la solución ............................... 28
6.4 Especificación .............................................................................................. 28
6.5 Revisión ........................................................................................................ 28
7. Modelo de análisis ........................................................................................... 28

4
7.1. Objetivos generales del modelo de análisis. ............................................... 29
7.2. Elementos del modelo de análisis ............................................................... 29
7.2.1 Modelos basados en escenarios
........................................................................................................................... 30
7.2.2 Modelos orientados al flujo
........................................................................................................................... 33
7.2.3 Modelos basados en clases.
........................................................................................................................... 35

5
 IDEOGRAMA

Análisis y Diseño de
Sistemas de Información

Módulo 1. Panorama general Módulo2. Análisis de Módulo 3. Diseño de

de la Ingeniería de Sistemas Sistemas de Información Sistemas de Información

Panorámica del enfoque de la Fundamentos de Ingeniería de Ingeniería de requerimientos Diseño de salidas efectivas
Teoría General de Sistemas Software

Definición de sistema Software Concepto de requerimiento Métodos de salidas

Clasificación de Sistemas La Ingeniería del Software Dimensiones de los Factores de decisión

requerimientos

Sistemas abiertos Disciplinas de las Ingeniería del Procesos de especificación de Diseño de salidas impresas
Software requerimientos

Sistemas cerrados Procesos de apoyo: Gestión de Muestras Diseño de salidas por pantalla
riesgos, gestión de la configuración,
y documentación

Sistemas dinámicos Especificación de Entrevistas Diseño de entradas efectivas

requerimientos

Estructura de Sistemas Análisis, diseño, desarrollo, Cuestionarios Diseño de formas

implementación y pruebas

La organización como sistema Implantación Prototipos Diseño de pantallas

abierto

Casos de uso Diseño de interfaz de usuario

Mantenimiento

Procesos de desarrollo (ciclo de Procesos de análisis de Tipos de interfaz

vida) requerimientos

Proceso general de desarrollo Elementos del modelo de Diseño de procedimientos para la

análisis captura precisa de datos

Metodología general o Diseño de archivo o de la

proceso en cascada base de datos

Construcción por prototipos Análisis de las bases de datos

Modelo en espiral Modelo físico de la base de

datos

Diseño del proceso

6
1. Ingeniería de Requerimientos

Los requerimientos especifican qué es lo que el sistema debe hacer, es decir sus
funciones. La obtención de los requerimientos tiene como objetivo principal la
comprensión de lo que los clientes y los usuarios esperan que haga el sistema.

Los requerimientos identifican el qué del sistema, mientras que el diseño establece
el cómo del sistema.

SISTEMA

Figura 1: Prioridad de los requerimientos. Fuente: propia

1.1 Definición de requerimientos

Existen varias definiciones de requerimientos, de entre las cuales se pueden citar

las siguientes:

IEEE(1990) lo define como:

Condición o capacidad requerida por el usuario para resolver un problema o
alcanzar un objetivo.
Condición o capacidad que debe satisfacer o poseer un sistema o una
componente de un sistema para satisfacer un contrato, un standard, una
especificación u otro documento formalmente impuesto.

7
Condición o capacidad que debe satisfacer o poseer un sistema o una
componente de un sistema para satisfacer un contrato, un standard, una
especificación u otro documento formalmente impuesto.
Zave
Rama de la ingeniería del software que trata con el establecimiento de los
objetivos, funciones y restricciones de los sistemas software.
Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer
especificaciones precisas.
Boehm
Ingeniería de Requerimientos es la disciplina para desarrollar una especificación
completa, consistente y no ambigua, la cual servirá como base para acuerdos
comunes entre todas las partes involucradas y en dónde se describen las
funciones que realizará el sistema.
Loucopoulos
Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y
cooperativo de análisis del problema, documentando los resultados en una
variedad de formatos y probando la exactitud del conocimiento adquirido.
Leite
Es el proceso mediante el cual se intercambian diferentes puntos de vista para
recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una
combinación de métodos, herramientas y actores, cuyo producto es un modelo
del cual se genera un documento de requerimientos.
La captura y el análisis de los requerimientos del sistema es una de las fases más
importantes para que el proyecto tenga éxito. Como regla de modo empírico, el
costo de reparar un error se incrementa en un factor de diez de una fase de
desarrollo a la siguiente, por lo tanto, la preparación de una especificación
adecuada de requerimientos reduce los costos y el riesgo general asociado con el
desarrollo.
El proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema de software es llamado Ingeniería de Requerimientos
La meta de la ingeniería de requerimientos es entregar una especificación de
requerimientos de software correcta y completa. La ingeniería de requerimientos
apunta a mejorar la forma en que comprendemos y definimos sistemas de
software complejos.

1.2 Tipos de requerimientos

Según el estándar internacional de Especificación de Requerimientos IEEE830,

los documentos de definición y especificación de requerimientos deben contemplar

8
los siguientes aspectos resumidos por [Pfleeger, 2002] como se indica a
continuación:

Ambiente físico § Dónde está el equipo que el sistema necesita para

funcionar.
§ Existe una localización o varias.
§ Hay restricciones ambientales como temperatura,
humedad o interferencia magnética.

Interfaces § La entrada proviene de uno o más sistemas.

§ La salida va a uno o más sistemas.
§ Existe una manera preestablecida en que deben
formatearse los datos.

Usuarios y § ¿Quién usará el sistema?

factores § Habrá varios tipos de usuario.
humanos § ¿Cuál es el nivel de habilidad de cada tipo de usuario?
§ ¿Qué clase de entrenamiento requerirá cada tipo de
usuario?
§ ¿Cuán fácil le será al usuario comprender y utilizar el
sistema?
§ ¿Cuán difícil le resultará al usuario hacer uso indebido
del sistema?

Tipos de usuario § ¿Cuál es el nivel de habilidad de cada tipo de usuario?

§ ¿Qué clase de entrenamiento requerirá cada tipo de
usuario?
§ ¿Cuán fácil le será al usuario comprender y utilizar el
sistema?
§ ¿Cuán difícil le resultará al usuario hacer uso indebido
del sistema?

9
Funcionalidad § ¿Qué hará el sistema?
§ ¿Cuándo lo hará?
§ ¿Existen varios modos de operación?
§ ¿Cómo y cuándo puede cambiarse o mejorarse un
sistema?
§ ¿Existen restricciones de la velocidad de ejecución,
tiempo de respuesta o rendimiento?

Documentación § ¿Cuánta documentación se requiere?

§ ¿Debe estar en línea, en papel o en ambos?
§ ¿A qué audiencia está orientado cada tipo de
información?

Datos § ¿Cuál será el formato de los datos, tanto para la entrada

como para la salida?
§ ¿Cuán a menudo serán recibidos o enviados?
§ ¿Cuán exactos deben ser?
§ ¿Con qué grado de precisión deben hacerse los
cálculos?
§ ¿Cuántos datos fluyen a través del sistema?
§ ¿Debe retenerse algún dato por algún período de
tiempo?

Recursos § ¿Qué recursos materiales, personales o de otro tipo se

requieren para construir, utilizar y mantener el sistema?
§ ¿Qué habilidades deben tener los desarrolladores?
§ ¿Cuánto espacio físico será ocupado por el sistema?
§ ¿Cuáles son los requerimientos de energía, calefacción o
acondicionamiento de aire?
§ ¿Existe un cronograma prescrito para el desarrollo?
§ ¿Existe un límite sobre la cantidad de dinero a gastar en
el desarrollo o en hardware y software?

Seguridad § ¿Debe controlarse el acceso al sistema o a la

información?
§ ¿Cómo se podrán aislar los datos de un usuario de los de
otros?

10
 § ¿Cómo podrán aislarse los programas de usuario de los
otros programas y del sistema operativo?
§ ¿Con qué frecuencia deben hacerse copias de respaldo?
§ ¿Las copias de respaldo deben almacenarse en un lugar
diferente?
§ ¿Deben tomarse precauciones contra el fuego, el daño
provocado por agua o el robo?
Aseguramiento § ¿El sistema debe detectar y aislar defectos?
de la calidad § ¿Cuál es el promedio de tiempo prescrito entre fallas?
§ ¿Existe un tiempo máximo permitido para la recuperación
del sistema después de una falla?
§ ¿El mantenimiento corregirá los errores, o incluirá
también el mejoramiento del sistema?
§ ¿Qué medidas de eficiencia se aplicarán al uso de
recursos y al tiempo de respuesta?
§ ¿Cuán fácil debe ser mover el sistema de una ubicación
a otra o de un tipo de computadora a otro?

2. Dimensiones de los requerimientos.

Los requerimientos permiten que el equipo de desarrollo tenga insumos para:

§ Para que los desarrolladores expliquen cómo han entendido lo que el cliente
pretende del sistema.
§ Para los diseñadores qué funcionalidad y que características va a tener el
sistema resultante.
§ Indican al equipo de pruebas qué demostraciones llevar a cabo para convencer
al cliente de que el sistema que se le entrega es lo que solicitó.

A continuación, se presentan las principales características que deben cumplir un

requerimiento:

11
 Figura 1. Características de los requerimientos. Fuente: propia
3. Proceso de Especificación de requerimientos

El proceso de especificación de requerimientos, se plantea mediante la

metodología DORCU, se centra en el usuario y la cual se describe a continuación:

12
 Figura 2. Proceso de especificación de requerimientos. Fuente: propia

Los objetivos que se proponen para cada una de ellas son:

3.1 Elicitación de Requerimientos.

Esta es la etapa en donde se adquiere el conocimiento del trabajo del

cliente/usuario, se busca comprender sus necesidades y se detallan las
restricciones medioambientales. Como resultado de las acciones realizadas se
tiene el conjunto de los requerimientos de todas las partes involucradas.

3.2 Análisis de Requerimientos.

En esta etapa se estudian los requerimientos extraídos en la etapa previa a los

efectos de poder detectar, entre otros, la presencia de áreas no especificadas,
requisitos contradictorios y peticiones que aparecen como vagas e irrelevantes. El

13
resultado de haber llevado a cabo las tareas que involucran estos términos puede,
en más de una oportunidad, hacer que se deba regresar a la primera etapa, a los
efectos de eliminar todas las inconsistencias y falencias que se han detectado. En
esta etapa ya se realizan aproximaciones a un lenguaje técnico.

3.3 Especificación de Requerimientos.

Partiendo de lo elaborado en la etapa anterior tales como funciones, datos,

requerimientos no funcionales, objetivos, restricciones de diseño/implementación o
costos, e independientemente de la forma en que se realice, esta etapa es un
proceso de descripción del requerimiento. Si se presentan dificultades para
especificar un requerimiento se debe volver a la etapa anterior que se crea
conveniente.

3.4 Validación y Certificación de los Requerimientos.

Esta etapa final se documenta con el resultado de las anteriores y realiza la

integración y validación final de lo obtenido en cada una de las etapas anteriores
dando, como resultado final, el Documento de Requerimientos.

Este documento no es uno solo, sino que, como mínimo, se entregan dos
documentos:

§ Para el cliente/usuario a los efectos de la certificación de los Requisitos por

parte del cliente, es la aceptación de los requerimientos.
§ Documento técnico, orientado a las etapas de la Ingeniería de Software y
base fundamental de trabajo para los analistas, diseñadores,
desarrolladores y el equipo de testing.

14
Baltzer y Goldman proponen ocho principios para una buena especificación:

PRINCIPIO 1.

Separar funcionalidad de implementación.

Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma
es la de funciones matemáticas: dado algún conjunto de entrada, producir un
conjunto particular de salida.

PRINCIPIO 2.

Se necesita un lenguaje de especificación de sistemas orientado al proceso.

Considerar una situación en la que el entorno sea dinámico y sus cambios afecten
al comportamiento de alguna entidad que interactúe con dicho entorno. Su
comportamiento no puede ser expresado como una función matemática de su
entrada. En vez de ello, debe emplearse una descripción orientada al proceso, en
la cual la especificación del que se consigue mediante la especificación de un
modelo del comportamiento deseado en términos de respuestas funcionales, a
distintos estímulos del entorno.

PRINCIPIO 3.

Una especificación debe abarcar el sistema del cual el software es una

componente.

Un sistema está compuesto de componentes que interactúan. Solo dentro del

contexto del sistema completo y de la interacción entre sus partes puede ser
definido el comportamiento de una componente especifica. En general, un sistema

15
puede ser modelado como una colección de objetos pasivos y activos. Estos
objetos están interrelacionados y dichas relaciones entre los objetos cambian con
el tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales los
objetos activos, llamados agentes, responden. Las respuestas pueden causar
posteriormente cambios y, por tanto, estímulos adicionales a los cuales los
agentes deben responder.

PRINCIPIO 4.

Una especificación debe abarcar el entorno en el que el sistema opera.

Similarmente, el entorno en el que opera el sistema y con el que interactúa debe

ser especificado. Tan solo necesita reconocer que el propio entorno es un sistema
compuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema
especificado es una agente, Los otros agentes, los cuales son por definición
inalterables debido a que son parte del entorno, limitan el ámbito del diseño
subsecuente y de la implementación. De hecho, la única diferencia entre el
sistema y su entorno es que el esfuerzo de diseño e implementación subsecuente
opera exclusivamente sobre la especificación del sistema. La especificación del
entorno facilita que se especifique la interfaz del sistema de la misma forma que el
propio sistema, en vez de introducir otro formalismo.

PRINCIPIO 5.

Una especificación de sistema debe ser un modelo cognitivo.

La especificación de un sistema debe ser un modelo cognitivo, en vez de un

modelo de diseño o implementación. Debe describir un sistema tal como es
percibido por su comunidad de usuario. Los objetivos que manipula deben
corresponderse con objetos reales de dicho dominio; los agentes deben modelar

16
los individuos, organizaciones y equipo de ese dominio; y las acciones que
ejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser
posible incorporar en la especificación las reglas o leyes que gobiernan los objetos
del dominio. Algunas de estas leyes proscriben ciertos estados del sistema (tal
como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"), y por
tanto limitan el comportamiento de los agentes o indican la necesidad de una
posterior elaboración para prevenir que surjan estos estados.

PRINCIPIO 6.

Una especificación debe ser operacional.

La especificación debe ser completa y lo bastante formal para que pueda usarse
para determinar si una implementación propuesta satisface la especificación de
pruebas elegidas arbitrariamente. Esto es, dado el resultado de una
implementación sobre algún conjunto arbitrario de datos elegibles, debe ser
posible usar la especificación para validar estos resultados. Esto implica que la
especificación, aunque no sea una especificación completa del cómo, pueda
actuar como un generador de posibles comportamientos, entre los que debe estar
la implementación propuesta. Por tanto, en un sentido extenso, la especificación
debe ser operacional.

PRINCIPIO 7.

La especificación del sistema debe ser tolerante con la incompletitud y

aumentable.

17
Ninguna especificación puede ser siempre totalmente completa. El entorno en el
que existe es demasiado complejo para ello. Una especificación es siempre un
modelo, una abstracción, de alguna situación real (o imaginada). Por tanto, será
incompleta. Además, al ser formulad existirán muchos niveles de detalle. La
operacionalidad requerida anteriormente no necesita ser completa. Las
herramientas de análisis empleadas para ayudar a los especificadores y para
probar las especificaciones, deben ser capaces de tratar con la incompletitud.

PRINCIPIO 8.

Una especificación debe ser localizada y débilmente acoplada.

Los principios anteriores tratan con la especificación como una entidad estática.
Esta surge de la dinámica de la especificación. Debe ser reconocido que, aunque
el principal propósito de una especificación sea servir como base para el diseño e
implementación de algún sistema, no es un objeto estático pre compuesto, sino un
objeto dinámico que sufre considerables modificaciones. Tales modificaciones se
presentan en tres actividades principales: formulación, cuando se está creando
una especificación inicial; desarrollo, cuando la especificación se está elaborando
durante el proceso iterativo de diseño e implementación; y mantenimiento, cuando
la especificación se cambia para reflejar un entorno modificado y / o
requerimientos funcionales adicionales.

18
4. Instrumentos para la recolección de los requerimientos.

Para la recolección de requerimientos el analista y diseñador, tienen varios tipos

de instrumentos que pueden ayudar al proceso, entre ellos se tienen: Muestras,
Entrevistas, Cuestionarios, Prototipos y Casos de uso.

4.1. Muestra

La selección de la muestra se realiza mediante métodos estadísticos, lo que

permite una mayor confianza y que se puedan llegar a conclusiones sobre todos
los elementos que constituyen el universo o población. Por lo general se realiza
sobre procesos del Software que necesitan una exactitud del establecimiento de
requerimientos.

4.2. La entrevista

Es una forma de recoger información de otra persona a través de una

comunicación interpersonal que se lleva a cabo por medio de una conversación
estructurada.

Braude, 2003, distingue las siguientes fases para la entrevista preparada.

Figura 3. Fases de la entrevista. Fuente: propia

19
Preparación:

El entrevistador debe documentarse e investigar la situación de la organización,

analizando los documentos de la empresa disponible. Hay que intentar minimizar
el número de entrevistados:

§ Considerar la entrevista de cortesía.

§ Analizar el perfil de los entrevistados.
§ Definir el objetivo y el contenido de la entrevista.
§ Planificar el lugar y la hora en la que se va a desarrollar la entrevista es
conveniente realizarla en un lugar confortable.
§ Algunos proponen enviar previamente el entrevistado un cuestionario y un
pequeño documento de introducción al proyecto de desarrollo.

Realización:

Se describe por medio de las siguientes fases:

§ Apertura: Presentarse e informar al entrevistado sobre la razón de la

entrevista.
§ Desarrollo: Cumplir las reglas del protocolo, hay que llegar a un acuerdo
sobre cómo se va a registrar la información obtenida.
§ Terminación: Se termina recapitulando la entrevista agradeciendo el
esfuerzo y dejando abierta la posibilidad de volver a contactar para aclarar
conceptos o bien citándole para otra entrevista.

Análisis:

Consiste en leer las notas, pasarlas en limpio, reorganizar la información,

contrastarlas con otras entrevistas o fuentes de información, evaluar cómo ha ido
la entrevista.

20
Las entrevistas con los involucrados con el sistema son parte de la mayoría de los
procesos de la ingeniería de requerimientos. En estas entrevistas, el equipo de la
ingeniería de requerimientos hace preguntas sobre el sistema que utilizan y sobre
el sistema a desarrollar.

Los requerimientos provienen de las respuestas a estas preguntas. Las

entrevistas pueden ser de dos tipos:

§ Entrevistas cerradas: donde los entrevistados responden a un conjunto

predefinido de preguntas.

Figura 4. Ejemplo de preguntas cerradas .Fuente:

http://es.slideshare.net/albertosalas33/elaboracion-decuestionariosy-entrevista

§ Entrevistas abiertas: donde no hay un programa predefinido. El equipo de

la ingeniería de requerimientos examina una serie de cuestiones con los

21
 involucrados con el sistema y, por lo tanto, desarrolla una mejor
comprensión de sus necesidades.

Los buenos entrevistadores deben tener como características adicionales:

Ayudan al entrevistado a empezar las discusiones con una pregunta, una

propuesta de requerimientos o sugiriendo trabajar juntos en un prototipo del
sistema.

Preguntar al cliente por lo que quiere de manera general normalmente no

proporciona información útil. Para la mayoría de la gente es mucho más fácil
hablar de algo en particular que en términos generales.

También debe tener en cuenta las siguientes actividades a realizar, antes y

después de la entrevista:

Figura 6. Actividades a tener en cuenta para la entrevista. Fuente: propia.

22
El entrevistador debe poseer y debe evitar:

Figura 7. Cualidades del entrevistador. Fuente: propia

4. 3 Cuestionarios

Los cuestionarios pueden utilizarse para recopilar datos sistemáticos habituales o

poco frecuentes, y datos para estudios especializados. Si bien la información de
esta sección se aplica a los cuestionarios para todos estos usos, los ejemplos se
refieren sólo a datos sistemáticos, tanto si son habituales como poco frecuentes.

Los cuestionarios deben presentar las siguientes características:

§ Los encuestados rellenen el formulario ellos mismos, para lo que también

se requiere un alto nivel de alfabetización.
§ Los cuestionarios deben prepararse utilizando los idiomas principales del
grupo destinatario.
§ Debe prestarse especial atención a estos casos para asegurar la precisión
de las traducciones.

23
 § Los cuestionarios, al igual que las entrevistas, pueden contener preguntas
estructuradas con espacios en blanco para rellenar, preguntas con
opciones múltiples o pueden incluir preguntas abiertas en las que se invita
al encuestado a contestar de forma amplia y en cierta medida elegir su
propio enfoque.

4.4 Prototipo de Software

Modelo que se desarrolla de un software para reflejar cómo se comporta un

sistema. Estos prototipos se utilizan para comprender cómo funciona el sistema en
cuestión.

Figura 8: Modelo de prototipo de software

Fuente: http://blog.santa.cl/2013/12/es-el-fin-de-las-aplicaciones-de.html

24
4.5. Diagramas de casos de uso.

Los diagramas de casos de uso pertenecen al grupo de los diagramas de

Comportamiento. Un caso de uso es una interacción entre el sistema y una
entidad externa. En su forma más simple, un caso de uso identifica el tipo de
interacción y los actores involucrados. Primero se identifican los eventos externos
a los que el sistema en desarrollo debe responder, y, en segundo lugar, se
relacionan estos eventos con los actores y los casos de uso.

Los diagramas de casos de uso especifican un sistema en término de su

funcionalidad. A diferencia de las metodologías estructuradas, los diagramas de
casos de uso no se descomponen en funciones de programación.

Figura 9. Diagrama de caso de uso. Fuente:

http://revistas.ucr.ac.cr/index.php/intersedes/article/view/790

25
5. Análisis de requerimientos

Es el conjunto de técnicas y procedimientos que permite conocer los elementos

necesarios para definir un proyecto de software. Es una tarea de ingeniería del
software que permite especificar las características operacionales del software,
indicar la interfaz del software con otros elementos del sistema y establecer las
restricciones que debe cumplir el software. Además, el análisis de requerimientos
permite cumplir con las siguientes tareas:

§ Suministra al técnico y al cliente, los medios para valorar el cumplimiento de

resultados, procedimientos y datos, una vez que se haya construido.

§ La tarea de análisis de los requerimientos es un proceso de descubrimiento

y refinamiento, el cliente y el desarrollador tienen un papel activo en la
ingeniería de requerimientos de software.

§ El análisis de requerimientos proporciona una vía para que los clientes y lo

desarrolladores lleguen a un acuerdo sobre lo que debe hacer el sistema.
La especificación, producto de este análisis proporciona las pautas a seguir
a los diseñadores del sistema.

La carencia de buenos requisitos ha sido la causa del fracaso de proyectos con

presupuestos de millones de dólares, ha impedido el desarrollo productivo, y ha
sido el mayor contribuyente de los costes elevados del mantenimiento del
software” 1.

1
Dr. Raymond Yeh in the forward to System and Software Requirements Engineering, IEEE Computer Society Press
Tutorial, Editors, M. Dorfman, and R.H Thayer, 1990).

26
 Figura 10. Costo relativo de la mala definición de requerimientos
Fuente: Somerville, Ian. “Ingeniería del Software”, 7ª Ed.,
Pearson Addison Wesley, 2005.

6. Proceso de Análisis de Requerimientos.

El proceso del establecimiento de requerimientos de un sistema de software, es el

primer paso esencial en entregar lo que el cliente desea. Entre los métodos
conocidos se puede citar a los siguientes:

Para Pressman, en el proceso de análisis de requerimientos del software se puede

identificar cinco tareas o etapas fundamentales:

27
 Figura 11. Proceso general de análisis de requerimientos. Fuente: propia.

6.1. Reconocimiento del problema.

Se deben de estudiar inicialmente las especificaciones del sistema y el plan del

proyecto del software. Realmente se necesita llegar a comprender el software
dentro del contexto del sistema. 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.

6.2. Evaluación y síntesis

En esta etapa el analista debe centrarse 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.

28
6.3 Modelización de la evaluación y síntesis de la solución.

Se crean modelos del sistema que servirán al analista 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.

6.4 Especificación.

Las tareas asociadas con la especificación intentan 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.

6.5 Revisión.

Una vez que se han descrito la información básica, se especifican los criterios de
validación que han de servir para 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.

7. Modelo de análisis

El modelo de análisis es la primera representación técnica de un sistema. Utiliza

una mezcla de formatos en texto y diagramas para representar los requisitos del
software, las funciones y el comportamiento. De esta manera se hace mucho más
fácil de comprender dicha representación, ya que es posible examinar los

29
requisitos desde diferentes puntos de vista aumentando la probabilidad de
encontrar errores, de que surjan debilidades y de que se descubran descuidos.

7.1. Objetivos generales del modelo de análisis.

El modelo de análisis debe cumplir tres objetivos primarios:

§ Describir los que requiere el cliente

§ Establecer una base para la creación de un diseño de software

§ Definir un conjunto de requisitos que pueda validarse una vez construido el

software.

7.2. Elementos del modelo de análisis

El modelo de análisis se complementa de cuatro elementos fundamentales. Estos

elementos sirven para clasificar principalmente los diferentes diagramas y otros
derivados conocidos en plataformas como sistemas de información e ingeniería de
software entre otros. Además, estos con clasificados en:

• Elementos de escenario.
• Elementos de flujo.
• Elementos de clases.
• Elementos de comportamiento.

30
 Figura 52: Elementos del modelo de análisis. Fuente: Propia

El modelo de análisis se complementa de cuatro elementos fundamentales. Estos

elementos sirven para clasificar principalmente los diferentes diagramas y otros
derivados conocidos en plataformas como sistemas de información e ingeniería de
software entre otros. Además, estos con clasificados en elementos de escenario,
elementos de flujo, elementos de clases y elementos de comportamiento.

7.2.1 Modelos basados en escenarios

Este modelo en simples palabras sirve para una interacción más amena entre el
sistema y el usuario, por lo tanto, el modelo de análisis con UML comienza con la

31
creación de escenarios en la forma de “los casos de uso, diagrama de actividad y
diagrama de secuencias:

Caso de uso: describe un escenario de un caso específico en un lenguaje directo

desde el punto de vista de un actor definido.

Figura 63. Ejemplo de caso uso. Fuente:

https://mundokramer.files.wordpress.com/2011/05/casos_de_uso.jpg

Diagrama de actividad: es un modelo muy parecido al caso de uso pero mucho

mejor complementado y proporciona una representación del flujo de interacción
dentro de un escenario específico.

32
 Figura 74: Ejemplo diagrama de actividades. Fuente:
http://www.conocimientosweb.net/portal/cursos/2008/img/09.gif

Diagrama de secuencias: consiste en tomar el diagrama actividad y situarlo en

filas o en carriles. En este modelo los actores son fundamentales ya que en el
diagrama de secuencias se especifica la responsabilidad a cada actor.

33
 Figura 85. Ejemplo de diagrama de secuencias
Fuente: https://i-msdn.sec.s-msft.com/dynimg/IC378044.png

7.2.2 Modelos orientados al flujo

Tiene una visión del sistema del tipo entrada-proceso-salida. Los objetos de datos
fluyen hacia el interior del software, se transforman mediante elementos de
procesamiento y los objetos de datos resultantes fluyen al exterior del software.

34
Diagrama de flujo de datos: sus principales características se mencionan a
continuación:

§ El nivel 0 del diagrama del flujo debe representar al software.

§ La entrada y la salida primaria se deben establecer con detalle.
§ La refinación debe comenzar por el aislamiento de procesos, objetos de
datos y almacenamiento de datos candidatos a ser representados en el
siguiente nivel.
§ Todas las flechas y burbujas se deben rotular con el nombre.
§ Se debe tener la continuidad de flujo al cambiar el nivel.
§ La refinación de burbujas debe hacerse una por una.

Figura 16. Ejemplo de diagrama de Flujo de datos

Fuente:http://ejerciciode.com/wp-content/uploads/2013/07/flujograma.png

35
 Figura 17: Diagrama de Nivel 0.Fuente: https://lh4.googleusercontent.com

7.2.3 Modelos basados en clases.

Una clase orientada a objetos encapsula atributos de los datos, pero también
incorpora las operaciones que manipulan los datos implicados por dichos
atributos. Las clases se manifiestan en la siguiente forma: entidades externas,
sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y
estructuras.

36
 Figura 18 .Ejemplo de diagrama de clases. Fuente: https://lh4.googleusercontent.com/

Modelo CRC (clase-responsabilidad-colaborador)

El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio

simple para identificar y organizar las clases relevantes para los requisitos del
sistema o producto. Un modelo CRC es una colección de tarjetas índices estándar
que representan clases. El objeto es desarrollar una representación organizada de
las clases. Las clases: tienen diferentes categorías:

37
 § Clases de entidad: llamadas clases de modelo o negocios, se extraen de
manera directa del enunciado del problema.

§ Clases de frontera: se utilizan para crear la interfaz que el usuario ve y con

la cual interactúa cuando se utiliza el software.

§ Clases de controlador: manejan una “unidad de trabajo” desde el inicio

hasta el final.

§ Responsabilidad: son los atributos y las operaciones relevantes para la

clase.

§ Colaboradores: son aquellas clases que se requieren para que una clase
reciba la información necesaria para completar una responsabilidad.
§ Agregación: son las subclases que forman parte de una clase, se conectan
a través de una relación de tipo” es parte de”.

7.2.4 Modelos de Comportamiento

El modelo de comportamiento indica la forma en que el software responderá a los

eventos o estímulos externos.

§ Diagrama de estado: representa el comportamiento de las clases cuando

el sistema.

38
 Figura 19. Ejemplo de diagrama de estado. Fuente:
http://jms32.eresmas.net/tacticos/UML/UML08/Fig0805.gif

Existen diferentes interpretaciones que cada desarrollador tenga sobre el conjunto

de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco
actividades principales que son:

§ Análisis del Problema

§ Evaluación y Negociación
§ Especificación
§ Validación
§ Evolución

A continuación, se presenta un resumen de los diferentes modelos que se aplican

para la definición de requerimientos en los proyectos de desarrollo de ingeniería
de software:

39
Tabla 1. Actividades de Ingeniería de requerimientos para diferentes modelos de Ingeniería
de Software. Fuente: propia

Oliver and EIA / IS-632 IEEE Std 1220- CMM nivel RUP
Steiner 1996 1994 Repetitivo (2)+
Evaluar la Análisis de Análisis de Identificación Análisis del
información requerimientos Requerimientos de Problema
disponible requerimientos
Definir métricas Análisis Estudio de los Identificación Comprender
efectivas funcional requerimientos de restricciones las
del sistema a necesidades
desarrollar de los
involucrados
Crear un modelo Síntesis Validación de Análisis de los Definir el
del requerimientos requerimientos sistema
comportamiento
del sistema
Crear un modelo Análisis Análisis Representación Analizar el
de los objetos y control del funcional de los alcance del
sistema requerimientos proyecto
Ejecutar el Evaluación y Comunicación Modificar la
análisis estudio de de los definición del
funciones requerimientos sistema
Crear un plan Síntesis Validación de Administrar los
secuencial requerimientos cambios de
de construcción y Estudio requerimientos
pruebas y evaluación del
diseño

Verificación
física

Control

40
ACTIVIDAD 01

Para cada uno de los siguientes modelos de Ingeniería de Software y de acuerdo

a las etapas.

• Oliver and Steiner 1996

• EIA / IS-632
• IEEE Std 1220- 1994
• CMM nivel Repetitivo (2)+
• RUP

Indique cual sería el más apropiado para aplicarlo a la solución de un desarrollo de

software que debe tener las siguientes características:

1. Implementación de bases de datos en línea para la fidelización de un sitio

de venta de libros, cuando el cliente escoge un libro ya sea para revisar o
comprar, y debe realizar el registro de sus datos, con esta información se
quiere tener el contacto de sus clientes para empezar una campaña de
contacto y promocionar ofertas y servicios a los clientes.
2. Se debe ejecutar en tres meses.
3. Se debe involucrar activamente al cliente en el proceso de especificación de
requerimientos.

41
 GLOSARIO

Actividad: Los procedimientos necesarios para implementar un área clave de

proceso. Comprende el establecimiento de planes y procedimientos, la ejecución
del trabajo, el seguimiento del mismo, el control de las salidas del proceso, y las
acciones correctivas que deben tomarse según sea necesario.

Ciclo de vida del software: El conjunto de procesos sistemáticos que tienen lugar
durante la existencia del producto, desde su concepción inicial hasta que la
organización decide no continuar manteniéndolo

Evaluación: Es la determinación de la manera en que las prácticas de ingeniería

de software han sido implementadas por la organización, habitualmente usando el
CMM como referencia. Puede ser realizada por evaluadores externos o internos,
dependiendo si el propósito es determinar competencia o mejorar internamente
Evaluación de la Capacidad del Software

Método de evaluación: creado por el SEI para evaluar la capacidad de procesos

de una compañía mediante un equipo de evaluadores externos (se usa
habitualmente para seleccionar o supervisar subcontratistas

Mantenimiento: proceso de corregir problemas y agregar nuevas capacidades a

un programa de software después de su entrega a los usuarios

Medición y Análisis: describen la necesidad de medir el proceso y analizar las

mediciones resultantes

Mejoramiento: evolución del proceso para hacerlo más eficiente para satisfacer
las necesidades de la empresa y los individuos que lo utilizan

Mejoramiento Interno del Proceso: proyecto emprendido por la organización

para incorporar nuevos procesos o hacer más eficaces los existentes, a objeto de
aumentar su capacidad para producir software.

42
Modelo de Madurez de Capacidades: Capability Maturity Model (CMM),
Conjunto de prácticas de ingeniería de software recomendadas por el SEI-CMU en
la versión SW-CMM.

Sponsor: Ejecutivos de la gerencia superior que apadrinan la iniciativa de

mejoramiento (o la evaluación CBA-IPI) y que tienen la capacidad de proveer los
recursos necesarios para su ejecución

Plan de Acción: Es el plan que identifica las actividades del proyecto de

mejoramiento de procesos. Identifica recursos, entrenamiento, calendarios,
riesgos, etc.

43
 BIBLIOGRAFÍA

Pressman, Roger S. "Ingeniería del Software: Un enfoque práctico", 5a edición.

Editorial McGraw Hill, España, 2002.Libro recomendado.

McDonnell, S., Desarrollo y gestión de proyectos informáticos, McGraw Hill y

Microsoft Press, España, 1997.

Norris & Rigby. “Ingeniería de software explicada”, 1ª edición. Editorial Megabyte-

Noriega editores, México, 1994.

Piattini M., Calvo-Manzano J., Cervera J., Fernandez L. “Análisis y diseño de

Aplicaciones Informáticas de Gestión”. Una perspectiva de Ingeniería de Software.
Alfaomega-Rama, México, 2004.

Pleeger, Shari L. “Ingeniería de software. Teoría y práctica” 1ª edición. Editorial

Pearson Education, Buenos Aires, 2002.

Rumbaugh, J., “Modelado y Diseño Orientado a Objetos: Metodología OMT”.

Prentice Hall, 1996.

Robertson & Robertson. “Mastering the Requirements Process”, Addison-Wesley,

1999.

Soto, I. & González, P., “Propuesta de un plan para la recuperación de proyectos

de software”.

Sommerville, Ian. “Ingeniería del Software”, 7ª Ed., Pearson Addison Wesley,

Madrid, 2005.

Weitzenfeld, Alfredo. “Ingeniería de Software Orientada a Objetos con UML, Java

e Internet”. Editorial Thomson, 2004.

Yourdon, Edward, “Análisis estructurado moderno”, Ed. Prentice Hall/Pearson,

1993.

44