ANÁLISIS DE REQUERIMIENTOS

Análisis de Sistemas

Freddy Manuel Sabogal Pineda – 20151578061

Iván Mauricio Díaz Aranda – 20151578016
William Andrés Gil Sánchez – 20151578032
Laura Estefanía Valbuena Roa – 20151578057

2017
 Tabla de conteni
Definición del análisis de requerimientos.....................................................................................2
Características del análisis de requerimientos..........................................................................2
Importancia del análisis de requerimientos..................................................................................3
Actividades del análisis de requerimientos...................................................................................3
Diagrama de secuencia.................................................................................................................6
Línea de vida:...........................................................................................................................6
Mensaje:...................................................................................................................................7
Mensaje self:............................................................................................................................7
Mensajes perdidos y encontrados:............................................................................................8
Inicio y final de línea de vida:..................................................................................................8
Tiempo.....................................................................................................................................8
Diagrama de colaboración............................................................................................................9
Usos:........................................................................................................................................9
Notación:..................................................................................................................................9
 Objeto:..........................................................................................................................9
 Vinculo:........................................................................................................................9
 Mensaje:.......................................................................................................................9
Diagrama de estados..................................................................................................................10
Partes del diagrama de estados:..............................................................................................11
 Estado:........................................................................................................................11
 Eventos:......................................................................................................................11
 Envió de mensajes:.....................................................................................................11
 Transición simple:......................................................................................................11
 Transición interna:......................................................................................................11
 Transacción compleja:................................................................................................11
 Subestados:.................................................................................................................11
 Acciones:....................................................................................................................11
Modelo de análisis (Diagrama de clases)...................................................................................11
Clase.......................................................................................................................................12
Atributos y métodos...............................................................................................................12
Relaciones..............................................................................................................................12
Generalización:..................................................................................................................12
Asociación:.........................................................................................................................12
Agregación:........................................................................................................................12
 Composición:.....................................................................................................................12
Modelos de análisis................................................................................................................12
Estudios de caso.........................................................................................................................13
Herramientas para el análisis de requerimientos........................................................................14
Objetivos:...............................................................................................................................14
Referencias:................................................................................................................................14

Definición del análisis de requerimientos

Es el conjunto de técnicas y procedimientos que nos permiten 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.

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 cliente intenta plantear un sistema que en muchas
ocasiones es confuso para él, sin embargo, es necesario que describa los datos, que
especifique las funciones y el comportamiento del sistema que desea. El objetivo es que
el desarrollador actúe como un negociador, un interrogador, un consultor, o sea, como
persona que consulta y propone para resolver las necesidades del cliente. 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

Características del análisis de requerimientos

- Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan
de proyecto. Es importante comprender el contexto del sistema y revisar el
ámbito de los programas que se usó para generar las estimaciones de la
planificación
- El analista debe establecer contacto con el equipo técnico y de gestión del
usuario / cliente y con la empresa que vaya a desarrollar el software.
- La evaluación del problema y la síntesis de la solución es la siguiente área
principal de trabajo del análisis
 - Las tareas asociadas con el análisis y especificación existen para dar una
representación del programa que pueda ser revisada y aprobada por el cliente.
- Los documentos del análisis de requerimiento (especificación y manual de
usuario) sirven como base para una revisión conducida por el cliente y el
técnico.

Importancia del análisis de requerimientos

el análisis de requerimiento es fundamental ya que de esto dependen las siguientes
etapas del desarrollo de software “el análisis de requisitos es el primer paso en el
proceso del desarrollo del software (o debería) y, por lo ende, resulta de vital
importancia ya que asienta la base del resto de etapas en dicho proceso” (binarios
cogitans, 2015) y además de esto la especificación de requerimientos nos permite saber
si el proyecto alcanzó sus objetivos o no.

si no se realiza el análisis de requerimiento, las fases preliminares arrastran los errores y

el proyecto corre el riesgo de tener que retroceder a esta etapa, esto provocará cambios y
por lo tanto mayor costo de reparación y retraso en la entrega del proyecto, “un caso
peor, es que no se encontraran y especificarán todos los requerimientos del sistema en
un proceso de desarrollo de software, lo cual produciría la entrega de un producto de
software incompleto o poco funcional.” (rotta, s.f.).

Actividades del análisis de requerimientos

Según Pressman, tanto el desarrollador como el cliente tienen un papel activo en la
ingeniería de requisitos. El cliente intenta replantear un sistema confuso, a nivel de
descripción de datos, funciones y comportamiento, en detalles concretos. El
desarrollador actúa como interrogador, como consultor, como persona que resuelve
problemas y como negociador.

El análisis y la especificación de requisitos pueden parecer una tarea relativamente

sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso.
Abundan las ocasiones para malas interpretaciones o falta de información. Es muy
probable que haya ambigüedad. El análisis de requisitos es una tarea de ingeniería del
software que cubre el hueco entre la definición del software a nivel sistema y el diseño
de software. El análisis de requerimientos 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.

En el proceso de IR son esenciales diversas actividades. En este documento serán

presentadas secuencialmente, sin embargo, en un proceso de ingeniería de
requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden
variado.

Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado
para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en
nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para
cada proceso.

Tabla 1. Actividades IR diferentes Modelos

EIA /IS-632 IEEE Std 1220-1994 CMM nivel RUP

repetitivo
Análisis de Análisis de Identificación de Análisis del Problema
requerimientos requerimientos requerimientos
Análisis Estudio de los Identificación de Comprender las
funcional requerimientos restricciones del necesidades de los
sistema a desarrollar involucrados
Síntesis Validación de Análisis de los Definir el sistema
requerimientos requerimientos

Análisis Análisis funcional Representación de los Analizar el alcance del

y control del requerimientos proyecto
sistema
Evaluación y estudio de Comunicación de los Modificar la definición
funciones requerimientos del sistema

Verificación de Validación de Administrar los

funciones requerimientos cambios de
requerimientos
Síntesis

Estudio
y evaluación del diseño
Verificación física
 Control

A pesar de las 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:

1. Reconocimiento del problema: En esta tarea se responde a la pregunta ¿Qué

haremos? Teniendo en cuenta las características y peticiones que especificó el
cliente.
2. Evaluación y síntesis: Se encarga detectar y corregir las carencias o falencias
de los requisitos obtenidos en la tarea anterior, en condiciones apropiadas para
ser tratados en el diseño.
3. Especificación: La especificación de requisitos de software es la actividad en
la cual se genera el documento, con el mismo nombre, que contiene
una descripción completa de las necesidades y funcionalidades del sistema que
será desarrollado; describe el alcance del sistema y la forma en como hará sus
funciones, definiendo los requerimientos funcionales y los no funcionales.
4. Revisión: Se centra en la revisión del documento de Especificación Software
de Requisitos, que recoge el conjunto de requerimientos del aplicativo, cuando
sea publicado. Se prestará especial atención a que dicho documento respete los
contenidos establecidos en la plantilla publicada en la Ingeniería de requisitos y
que no sea transgredida ninguna de las pautas y directrices de este subsistema y
las marcadas por la Dirección Técnica del Proyecto.
5. Evolución: Los requerimientos son una manera de comprender mejor el
desarrollo de las necesidades de los usuarios y cómo los objetivos de la
organización pueden cambiar, por lo tanto, es esencial planear posibles cambios
a los requerimientos cuando el sistema sea desarrollado y utilizado. La
actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de
vida del proyecto.

Diagrama de secuencia
Es un diagrama que muestra la interacción entre los objetos como líneas de vida a lo
largo de la página y con sus interacciones en el tiempo representadas como mensajes
dibujados como flechas desde la línea de origen hasta la línea de destino. Estos
diagramas son buenos para mostrar la comunicación de unos objetos con otros y qué
mensajes disparan dichas comunicaciones. Los diagramas de secuencia no están
diseñados para mostrar lógicas de procedimientos complejos. Este diagrama consta de
objetos que se representan del modo usual (rectángulos con nombre subrayado),
mensajes entre los objetos representados por líneas continuas y el tiempo representado
como una progresión vertical. Los objetos se colocan en la parte superior del diagrama,
de izquierda a derecha, y se acomodan de tal manera que se simplifique el diagrama.

Línea de vida: Representa un participante individual en un diagrama de secuencia;

usualmente tiene un rectángulo que representa el objeto, en el cual solo se coloca su
nombre. Si el nombre es “self” esto significa que la línea de vida representa el
clasificador que posee el diagrama de secuencia, tal como se ve en el siguiente gráfico:

Imagen recuperada de:

http://www.sparxsystems.com/images/screenshots/uml2_tutorial/seq01.GIF

Algunas veces el diagrama de secuencia contiene una línea de vida con un símbolo del
elemento “actor” en la parte superior; este usualmente sería el caso si un diagrama de
secuencia es contenido por un caso de uso. Los elementos “entidad”, “control” y
“limite” de los diagramas de robustez también pueden contener líneas de vida:

Mensaje: Se muestran como flechas; estos pueden ser complejos, perdidos o

encontrados; síncronos o asíncronos; llamadas o señales. Un objeto puede enviarse un
objeto a sí mismo, es decir, de su línea de vida a la propia. Un mensaje puede ser
simple, síncrono o asíncrono; el mensaje simple es la transferencia del control de un
objeto a otro; el mensaje síncrono es aquel en el que el objeto espera la respuesta a ese
mensaje antes de continuar con su trabajo; y un mensaje asíncrono es aquel en el que el
objeto no espera la respuesta de ese mensaje antes de continuar. Como se puede ver en
el diagrama a continuación, el primer mensaje es síncrono (se representa por una punta
de flecha negra), con un mensaje de retorno implícito; el segundo mensaje es asíncrono
(representado por una punta de flecha en línea) y el tercero es un mensaje de retorno
asíncrono (línea punteada):

Mensaje self: Puede representar una llamada recursiva de una operación o un método
llamando a otro perteneciente al mismo objeto. Se muestra al crear un foco de control
anidado en la ocurrencia de ejecución de la línea de vida:

Mensajes perdidos y encontrados: Los mensajes perdidos son aquellos que han sido
enviados, pero no llegan al destino esperado o que llegan a un destino que no se muestra
en el diagrama actual. Los mensajes encontrados son aquellos que llegan de un
remitente no conocido (o no conocido en el diagrama actual). Ellos se denotan yendo o
llegando desde un elemento de punto final

Inicio y final de línea de vida: Las líneas de vida se pueden crear o destruir durante la
escala de tiempo representada por un diagrama de secuencia. En el último caso, la línea
de vida se termina por un símbolo de detención (representado como una cruz). En el
primer caso el símbolo al inicio de la línea se muestra en un nivel más bajo de la página
que el símbolo del objeto que generó la creación. En el siguiente diagrama se muestra
un objeto que fue creado y destruido:

Tiempo: Se representa en dirección vertical, se inicia en la parte superior y avanza hasta

la parte inferior. Un mensaje que este más cerca de la parte superior ocurrirá antes que
uno que esté en la parte inferior. Con esto se concluye que el diagrama de secuencia
tiene dos dimensiones: la dimensión horizontal que es la disposición de los objetos, y la
disposición vertical que muestra el paso del tiempo.

Diagrama de colaboración
El diagrama de colaboración es similar a un diagrama de interacción cuyo objetivo es
describir de manera detallada el comportamiento dinámico del sistema de información,
mostrando cómo interactúan los objetos entre sí, es decir, con que otros objetos se
vincula o intercambia mensajes un determinado objeto.

Este diagrama muestra la misma información de un diagrama de secuencia, pero de una

forma distinta. En los diagramas de colaboración no existe una secuencia temporal en el
eje vertical, es decir, la colaboración de los mensajes no indica cual es el orden en el que
suceden. Además, la colaboración entre los objetos es más flexible y permite mostrar de
forma clara y eficaz cuáles son las colaboraciones entre ellos. La comunicación entre
objetos se denomina vinculo o enlace (link) y estará particularizada mediante los
mensajes que se intercambian.

Usos:
Su uso es mostrar la implementación de una operación, la comunicación muestra los
parámetros y las variables locales de la operación, así como asociaciones más
permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes
corresponde a la estructura de las llamadas anidadas y el paso de señales del programa.
Este diagrama muestra secuencias en el tiempo como dimensión geométrica pero las
relaciones son implícitas. Muestra relaciones entre objetos geométricamente y relaciona
los mensajes con relaciones, pero las secuencias temporales no son tan claras.

Notación:
 Objeto: Se representa con un rectángulo y dentro de este se incluye su nombre y,
si se desea, el nombre de la clase, separando ambos por dos puntos.
 Vinculo: Se representa como una línea continua que une a dos objetos y que
puede tener uno o varios mensajes asociados en ambas direcciones. Como un
vínculo instancia una relación entre clases, también indica la navegabilidad del
mismo mediante una flecha.
 Mensaje: Se representa con una flecha colocada junto a la línea del vínculo al
que está asociado. La dirección de la flecha va desde el objeto emisor del
mensaje hasta el receptor del mismo, junto a ella se coloca el nombre del
mensaje y sus respectivos argumentos. A diferencia de los diagramas de
secuencia. Siempre se muestra el número de secuencia del mensaje delante de su
nombre, esto debido a que no hay otra forma de conocer la secuencia de los
mismos. Los mensajes pueden tener asociados condiciones e iteraciones que se
representan igual que en los diagramas de secuencia.

En el siguiente ejemplo para el caso de uso: prestar un ejemplar de una aplicación

encargada de préstamo de libros de una biblioteca:

Imagen recuperada de: https://manuel.cillero.es/wp-

content/uploads/2013/11/colaboracion-ejemplo.png?x80877
 Diagrama de estados
El diagrama de estados muestra la secuencia de estados por los que pasa un caso de uso,
un objeto a lo largo de su vida o todo el sistema en cuestión. Es una forma de
representación más intuitiva de los autómatas finitos basadas en diágrafos con arcos
acotados llamados “transiciones” en los cuales se ponen los símbolos de tránsito entre
un vértice (estado) y otro, y se identifican los estados de partida y los de aceptación del
resto. Este diagrama representa la modificación del estado de los objetos como
respuesta a los sucesos y al tiempo. En este diagrama se indica que eventos hacen que
pase un objeto de un estado a otro y que respuestas o acciones genera dichos cambios.
También ilustra los eventos que pueden cambiar el estado de los objetos de la clase;
tiene la ventaja de que el analista se centre en las necesidades del usuario; además de
que este diagrama tiene éxito en sistemas interactivos, debido a que expresa la intención
que tiene el usuario al hacer uso del sistema. Este diagrama sirve para mostrar la vida de
un objeto, indica los eventos que causan que un estado cambie a otro y analizar las
respuestas y acciones que esto conlleva; se utiliza normalmente para describir objetos
del dominio del usuario y se documenta en la etapa de análisis.

Partes del diagrama de estados:

 Estado: Identifica un periodo de tiempo del objeto en el cual este está esperando
alguna operación, tiene cierto estado característico o puede recibir cierto tipo de
estímulos.
 Eventos: Es una ocurrencia que puede causar la transición de un objeto de un
estado a otro.
 Envió de mensajes: Además de la muestra y transición de estados por medio de
eventos, puede representarse el momento en el cual se envían los mensajes a
otros objetos.
 Transición simple: Es una relación entre dos estados que indica que un objeto en
el primer estado puede entrar al segundo estado y así ejecutar ciertas operaciones
cuando un evento ocurre y si ciertas condiciones son satisfechas.
 Transición interna: Es una transición que permanece en el mismo estado en vez
de involucrar dos estados distintos. Representa un evento que no causa un
cambio de estado. Representa una cadena adicional en el compartimiento de
acciones del estado.
 Transacción compleja: Relaciona tres o más estados en una transición de
múltiples fuentes y/o varios destinos.
  Subestados: Un estado puede dividirse en subestados con transiciones entre ellos
y conexiones al nivel superior; las conexiones e ven al nivel inferior como
estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas
del nivel inmediatamente superior.
 Acciones: Podemos especificar la solicitud de un servicio a otro objeto como
consecuencia de la transición. Se puede especificar ejecutar una acción como
consecuencia de entrada, salida, estar en un estado o por la ocurrencia de un
determinado evento.

Modelo de análisis (Diagrama de clases)

Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
agregación, ya que una clase es una descripción de conjunto de objetos que comparten
los mismos atributos, operaciones, métodos, relaciones y semántica; mostrando un
conjunto de elementos que son estáticos, como las clases y tipos junto con sus
contenidos y relaciones. Un diagrama de clases está compuesto por los siguientes
elementos según el lenguaje unificado de modelado (UML): Clase: atributos, métodos y
visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Clase
Este es el elemento básico del diagrama de clases. Las clases representan entidades o
conceptos. Normalmente cada vez que aparece un sustantivo en un documento de
descripción de un sistema ese sustantivo es una clase. En cada clase se definen los
atributos y métodos que tendrán los objetos de esa clase.

Atributos y métodos
Los atributos y los métodos son las características que se le puede atribuir a una clase,
se muestran con su nombre además de su tipo. En el caso de los métodos también se
muestra el tipo de retorno en caso de que retorne algo y el nombre y tipo de sus
parámetros. Los atributos pueden tener un valor inicial.

Relaciones
Las clases se relacionan con otras. En cada relación aparece el nombre del atributo que
se usará para representar esa relación y la multiplicidad. Las relaciones que existen son
las siguientes:

Generalización: Esta relación representa la herencia o la extensión de una clase de otra.

Asociación: Representa una relación básica entre dos clases. Pueden ser
unidireccionales (sólo una de las clases conoce a la otra) o bidireccionales (ambas clases
tienen conocimiento de la otra).

Agregación: Es un tipo de asociación con la que se representa que cada objeto de una de
las clases contiene objetos de la otra clase. El objeto contenedor seguirá existiendo
aunque los objetos contenidos dejen de existir.

Composición: Es un tipo de asociación, pero podemos decir que son agregaciones

fuertes. La diferencia con las agregaciones es que no tiene sentido que el objeto
contenedor siga existiendo si no existen los objetos contenidos.

[ CITATION Gom15 \l 9226 ]

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

1. Describir los que requiere el cliente

2. Establecer una base para la creación de un diseño de software
3. Definir un conjunto de requisitos que pueda validarse una vez construido el
software.

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.
 Estudios de caso
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. En las figuras 6.3 y 6.4 podemos observar ejemplos. 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

Herramientas para el análisis de requerimientos

Se debe tener en cuenta el modelado de negocio y requerimientos, en base a esto se
llevará a cabo el análisis de requerimientos por medio de la herramienta CASE.

“Las herramientas CASE se definen como un conjunto de programas y procesos

“guiados”, que ayudan a los analistas, desarrolladores, ingenieros de software y
diseñadores en una o todas las etapas que comprende un ciclo de vida, con el objetivo
de facilitar el desarrollo de software.” (Fuentes, 2011).
Objetivos:
· Automatizar el desarrollo del software
· Automatizar la documentación
· Automatizar la generación del código
· Automatizar la búsqueda y corrección de errores
· Automatizar la gestión del proyecto
· Permitir la reutilización del software
· Permitir la portabilidad del software
· Permitir la estandarización de la documentación

Referencias:
 Bruegge, B., & Dutoit, A. H. (2002). Ingeniería de software orientado a objetos.
 IEEE Computer Society. Software Engineering Standards Committee, & IEEE-
SA Standards Board. (1998). Ieee recommended practice for software
requirements specifications. Institute of Electrical and Electronics Engineers.
 Presuman Roger, S. (2002). Ingeniería del software un enfoque práctico.

 Gómez, V. (19 de marzo de 2015). Instinto Binario. Obtenido de Diagrama de

clases: http://instintobinario.com/diagrama-de-clases/
 Bruegge, B., & Dutoit, A. H. (2002). Ingeniería de software orientado a objetos.
 IEEE Computer Society. Software Engineering Standards Committee, & IEEE-
SA Standards Board. (1998). Ieee recommended practice for software
requirements specifications. Institute of Electrical and Electronics Engineers.
 Presuman Roger, S. (2002). Ingeniería del software un enfoque práctico.
 Gomez, V. (19 de Marzo de 2015). Instinto Binario. Obtenido de Diagrama de
clases: http://instintobinario.com/diagrama-de-clases/

 García F (2008). “Diagramas de secuencia”. Recuperado de:

https://es.slideshare.net/FABIANGARCIA/diagramas-de-secuencia-presentation
 Gutiérrez M (2012). “Diagrama de secuencia UML 2”. Recuperado de:
http://www.sparxsystems.com.ar/resources/tutorial/uml2_sequencediagram.html
 Cillero M (2014). “Diagrama de colaboración”. Recuperado de:
https://manuel.cillero.es/doc/metrica-3/tecnicas/diagrama-de-
interaccion/diagrama-de-colaboracion/
 Moya N (2013). “Diagramas de estados”. Recuperado de:
https://es.slideshare.net/still01/diagramas-de-estados-16815255

 Binarios Cogitans. (9 de Marzo de 2015). Binarios Cogitans. Obtenido de El

porque del analisis de requerimientos: https://www.binariuscogitans.com/el-
porque-del-analisis-de-requerimientos/
 Fuentes, M. D. (2011). Analisis De Requerimientos. En M. D. Fuentes, Analisis
De Requerimientos. Mexico: Publidisa Mexicana S. A. de C.V.
 Rotta, I. L. (s.f.). ISActividades. Obtenido de Analisis de Requerimientos:
https://isactividades.wikispaces.com/An%C3%A1lisis+de+requerimientos