Análisis y diseño de

sistemas
Semana 05
Del 26 al 29 de abril
Análisis de requerimientos
Ing. Juan Carlos Hernández Saona
jhernandez@iestpjctello.edu.pe
Introducción

• El éxito de un proyecto de software radica, entre otros

factores, en la elección correcta de un proceso que conduzca
a desarrollar un buen sistema de software. La elección de la
metodología adecuada es más importante que utilizar las mejores
y más potentes herramientas
 Metodología
para la
gestión
de

procedimientos:
contiene los siguientes
procesos
1. Identificación de necesidades con el
cliente
• Si los requerimientos se
enfocan a describir las
necesidades del cliente,
entonces es lógico que para
recabarlos haya que obtener
la información de primera
mano. Esto es, mediante
entrevistas con el cliente u
obteniendo la documentación
que describa la manera que
el cliente desea como
funcione el sistema de
software.
1.1 Obtener y Analizar información de
las necesidades del cliente

• Para hacer una correcta identificación de los clientes y poder

realizar un análisis de manera asertiva se pueden implementar
una serie de técnicas de acuerdo al cliente con el que se
esté tratando.
1.2 Definición del alcance

• La definición del alcance tiene

como propósito describir y delimitar
claramente las necesidades del
cliente, las cuales pretenden ser
cumplidas con el proyecto.
1.3 Fuentes de información claves
 1.4 Recomendaciones para definir el alcance

• Desarrollar un escrito o documento formal.

• Detallar claramente qué actividades y procesos son parte del
proyecto
• Definir los criterios que se utilizarán para determinar si el
proyecto o fase ha finalizado exitosamente
• Al definir el alcance, tener en mente que lo que no esté en el
alcance está fuera del proyecto.
• Formalizar la aceptación del alcance con el cliente.
 1.5 Beneficios de una buena definición

• Mejorar la precisión en las estimaciones de tiempo, costo y recursos.

• Facilitar la asignación clara de recursos y responsabilidades.
• Definir la línea base para la medición del desempeño y control
• Identificar, tanto el equipo de proyecto como el cliente, el objetivo final
del proyecto y sus entregables.
• Desarrollar y confirmar un entendimiento común del proyecto
entre ambas partes, cliente y equipo de proyecto.
• "Asegurar que el proyecto incluye todo el trabajo requerido para
terminar exitosamente."
2. TÉCNICAS PARA
IDENTIFICAR REQUERIMIENTOS

• Técnicas generales para la identificación de requerimientos

• Técnicas específicas para la identificación de requerimientos
• Técnicas para Identificar Requisitos Funcionales y No Funcionales
• Técnicas de investigación de los atributos de las necesidades de
los clientes
2.1 Técnicas generales
para la identificación de
requerimientos

• Las técnicas agrupadas como

generales son las que permiten
investigar aspectos generales para
posteriormente ser especificados
con un mayor detalle con el apoyo
de técnicas más específicas.
2.1.1 Entrevista

• Estas técnicas son muy utilizadas para la recolección de opiniones,

criterios o descripciones sobre diferentes actividades. Se lleva a
cabo mediante conversaciones estructuradas donde es
fundamental que la relación con el cliente este basada en la
confianza para dar a conocer la información de la manera mas
detallada.
2.1.1 Entrevista

Estudiar el tipo de Estudiar como será Estudiar como es la

personas a las cuales el entorno donde se manera de hablar de
se les realizará la llevara a cabo la las personas
entrevista. entrevista. individualmente.

Entender que es
Verificar que las Revisar como es la importante obtener
personas tengan la relación del cliente la mayor
disponibilidad. con la organización. información.
 Esta técnica es abierta y se utiliza para
explorar necesidades iniciales.

2.1.2 Lluvia
de
ideas Es utilizada para investigar nuevos servicios o
necesidades que no son claramente
identificadas.
Escoger un sitio tranquilo
que permita que las
Tomar la iniciativa para Tomar nota de las ideas
personas involucradas se
que iniciar una reunión las personas
sientan cómodas y
expresan en
dispuestas para dar a
enfocada en la confianza. los equipos de trabajo.
conocer sus ideas.
• Esta técnica puede ir dirigida a un público específico o general, lo
que permite obtener una información mayor, ya que se tiene la
posibilidad de involucrar más personas para el desarrollo de los
cuestionarios y que estos tengan diferentes puntos de vista.

2.1.3 Cuestionarios
2.2 Técnicas específicas
para la identificación
de requerimientos
2.2.1 Observación

Es una técnica que sirve

Esta técnica permite Hay que tener en
para revisar que no
obtener información cuenta que se debe
existen omisiones o
directa sobre la forma utilizar si el cliente lo
interpretaciones
en que se realizan las permite y si el proyecto
erróneas sobre el
actividades. así lo amerita.
proceso que se realiza.
• Esta técnica permite conocer el
comportamiento del producto ante
determinados eventos considerando los
datos, acciones y excepciones que se
pueden presentar.
• El análisis de casos de uso es un ejemplo de
aplicación de esta técnica

2.2.2
Escenarios
2.3 Técnicas para Identificar Requisitos
Funcionales y No Funcionales

1. Identificación de Requerimientos funcionales

2. Identificación de Requerimientos no funcionales
3. Aspectos a tener en cuenta en la identificación de
requerimientos funcionales y no funcionales
4. Identificación de elementos
5. Preguntas generales
2.3.1 Identificación de
Requerimientos
funcionales

• Los requerimientos funcionales son

declaraciones de los servicios que
proveerá el sistema, de la manera
en que éste reaccionará a entradas
particulares.
• En algunos casos, los
requerimientos funcionales de los
sistemas también declaran
explícitamente lo que el sistema no
debe hacer.
2.3.2 Identificación de
Requerimientos no funcionales

• Son aquellos requerimientos que no se

refieren directamente a las funciones
específicas que entrega el sistema, sino a
las propiedades emergentes de éste
como la fiabilidad, la respuesta en el
tiempo y la capacidad de
almacenamiento.
• De forma alternativa, definen las
restricciones del sistema como la
capacidad de los dispositivos de
entrada/salida y la representación de
datos que se utiliza en la interface del
sistema.
 Requerimientos del producto.
Especifican el comportamiento del
producto;

2.3.2
Identificación Requerimientos organizacionales. Se
derivan de las políticas y
de procedimientos existentes en la
organización del cliente y en la del
desarrollador.

Requerimientos
no funcionales Requerimientos externos. Se derivan de
los factores externos al sistema y de su
proceso de desarrollo.
• Requerimientos básicos: se estructura su 2.3.3 Aspectos a
identificación al buscar respuestas a
preguntas como: tener en
• ¿Cuál es el proceso básico de la
empresa? cuenta
• ¿Qué datos utiliza o produce este identificación
en la
proceso?
• ¿Cuáles son los límites impuestos por el de
tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?
requerimientos
funcionales y
no funcionales
2.3.4 Aspectos a tener en cuenta en la identificación de
requerimientos funcionales y no funcionales

• Las siguientes preguntas son de utilidad para adquirir la comprensión

necesaria:
• ¿Cuál es la finalidad de la actividad dentro de la empresa?
• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?
2.3.4 Identificación de elementos

• Durante esta, se debe identificar muy claramente los siguientes elementos:

• Procesos
• Flujos de datos entre procesos
• Datos de cada flujo de datos
• Bases de datos
• Datos de las bases de datos
 ¿Cuántos empleados laboran para la organización en el área(s) que
se pretende desarrollar el sistema?

¿Cuáles son las personas claves en el sistema? ¿Por qué son

importantes?

2.3.5
¿Existen obstáculos o influencias de tipo político que afectan la
eficiencia del sistema?

¿Existen manuales de procedimientos, políticas o lineamientos de

Preguntas desempeño documentados oficial o no oficialmente?. Si los hay, ¿Se

cumplen en forma cabal en el 100% de las ocasiones?, es decir, ¿se
respetan dichos procedimientos?

¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?

generale
s ¿Qué áreas necesitan un control específico?

¿Qué criterios se emplean para medir y evaluar el desempeño?

2.4 Técnicas de investigación
de los atributos de las
necesidades de los clientes

• En realidad, quien conoce sus

necesidades es el cliente y,
consecuentemente, lo que se
hace es preguntarle a él sobre
cada una de ellas, con el objeto
de clasificar y ponderar su
importancia.
2.4.1 Grupos focales

• Los grupos focales se conforman reuniendo a un grupo

seleccionado de clientes, conjuntamente con un moderador que
va a conducir un debate de grupo sobre una serie de aspectos y
cuestiones concretas en las que se focaliza la discusión.
• En la reunión se establece, de por sí, una relación de afinidad
por
la que todas las respuestas giran en torno a la situación a
analizar.
• La habilidad para conducir el debate, sugerir y plantear los temas,
atemperar las discusiones sobre aspectos banales y centrarla en
los relevantes, es una cuestión que va a determinar la cantidad y
calidad de la información a obtener.
2.4.2 Entrevista individual

• Esta tiene alguna ventaja adicional sobre el grupo focal, como

el que se pueden matizar, en un ambiente de mayor privacidad,
los aspectos con mayores atributos de impacto.
• El entrevistador juega aquí un papel crítico. No sólo tiene que
dominar las técnicas de la entrevista, como el saber preguntar, el
crear un clima de cooperación, sino que, además debe reunir la
experiencia y dominio suficiente sobre el tema.
2.4.3 Análisis contextual

• Con esta técnica, lo que se hace es, no sólo pedir al cliente que
cuente su experiencia de uso y responda a las sagaces y hábiles
preguntas de los métodos anteriores, sino que se le solicita,
además, ver cómo utiliza el producto para comprender el por qué
de su necesidad y discutir sobre el terreno cada uno de los
detalles y particularidades de uso.
2.4.4 Clientes piloto

• Clientes de alto prestigio y conocimiento que pueden ofrecer un

formidable campo de pruebas para el nuevo producto.
• Arthur D. Little llama a este tipo de clientes «lead adopters» y
señala algunas condiciones que deben cumplir con ese papel de
cliente piloto.
• Se les pide liderazgo en el producto, es decir, se trata de clientes
de reconocido prestigio por su conocimiento y experiencia en su
campo de actividad.
3. DEFINICIÓN DE REQUERIMIENTOS

• Para tener una buena definición de requerimientos es necesario

realizar una buena identificación de los mismos, posterior a esto
es importante definirlos de manera detallada, donde se involucre
la información aportada por los usuarios
• Para realizar una correcta definición de los requerimientos del
proyecto y que éstos satisfagan las necesidades verdaderas del
cliente, se deben tener en cuenta las siguientes actividades:
3.1 Definición de Requisitos

• Definir los requerimientos teniendo en cuenta la información

identificada con la perspectiva del usuario
• Reutilizar requerimientos, revisando proyectos ya finalizados para
ver si contienen material potencialmente reutilizable.
• Se debe documentar los requerimientos de una forma clara y
correcta.
3.2 Clasificación de Requerimientos

• Requerimientos funcionales
• Requerimientos no funcionales
3.2.1 Requerimientos funcionales

• Estos requerimientos se utilizan para determinar que hará el Software,

definiendo las relaciones de su operación y su implementación, sin
olvidar que deben ser explícitos también en lo que el sistema no debe
hacer y que validaciones se deben realizar, teniendo en cuenta cual será
el comportamiento del sistema.
• Los Requerimientos funcionales se pueden dividir en dos puntos de vista:
• El primero tiene relación con el usuario, donde se identifica la relación del
usuario con el sistema desde el punto de vista del mismo;
• El segundo tiene relación con el sistema dando respuesta al usuario, es
decir
desde el punto de vista de lo que realiza el sistema.
 • Estos requerimientos se basan en las restricciones
de los servicios o funciones ofrecidos por el
sistema.
• Los Requerimientos no funcionales son los
requerimientos que no se refieren directamente a
las funciones específicas que entrega el sistema,
3.2.2 sino a las propiedades emergentes de éste como
la fiabilidad, la respuesta en el tiempo y la
Requerimientos capacidad de almacenamiento.

no • Los requerimientos no funcionales surgen de la

necesidad del usuario, debido a las restricciones
funcionales en el presupuesto, a las herramientas utilizadas, a
las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software
o hardware o a factores externos como los
reglamentos de seguridad, las políticas de
privacidad, etcétera.
3.2.2 Requerimientos no
funcionales
3.3 Verificación de requisitos

• Para la verificación de
requisitos se deben
añadir criterios de
aceptación
por cada requisito, una tarea
de la calidad es asegurarse de
que cada requisito cumple con
los criterios asignados, este
criterio es una medida del
requisito que lo hace
entendible y con capacidad de
ser probado.
•
3.3 Verificación de requisitos
3.4 Revisión de Requisitos vs Especificación
3.4 Revisión de Requisitos vs
Especificación
3.4.1 Preparar plan de revisión

• En la preparación del plan de reunión de debe planear quienes

deben asistir que se va a hablar y cuánto tiempo se va a gastar.
3.4.2 Documentos de requisitos a revisar

• Identificar cuáles son los documentos de especificación de

requisitos que se va a revisar
3.4.3 Preparar reunión

• Se debe confirmar el lugar en el cual realizará la reunión y se

deben prepara los materiales necesarios para la reunión (lápices,
hojas, elementos visuales… etc)
3.4.4 Realizar reunión

• Se revisa el entendimiento de la especificación por parte de los

interesados y se valida que lo especificado si cumple con la
necesidad del cliente y con lo solicitado.
3.4.5 Identificar los defectos de la
especificación

• Si revisa si se encuentran defectos con respecto a lo solicitado o si

hace falta alguna especificación requerida.
3.4.6 Realización de correcciones a los
documentos

• Si en la etapa anterior se encuentran defectos en la especificación

el analista del sistema debe realizan las debidas correcciones al
documento.
3.4.7 Informar modificaciones a los
interesados

• Una vez los defectos en la especificación han sido subsanados, se

debe enviar un breve resumen informando las tareas realizadas
para la corrección de los documentos especificados junto con los
documentos corregidos a los participantes en la reunión para dar
su aprobación.
3.4.8 Cierre de los requerimientos

• Por último se da por cerrado y entendido la el requerimiento se

firma la aprobación por parte de los interesados y se procede a
enviarse un correo con la aprobación del requerimiento.
4. TÉCNICAS PARA DEFINIR
REQUISITOS
• Para obtener los requisitos del cliente se pueden emplear varias
técnicas.
• Históricamente, esto ha incluido técnicas tales como las
entrevistas, o talleres con grupos para crear listas de requisitos.
• Técnicas más modernas incluyen los prototipos, y utilizan casos de
uso.

De acuerdo a las necesidades de los clientes específicos a los cuales

se va a aplicar la metodología propuesta, se han definido las
siguientes:
4.1 Definición de diagramas

• De manera general se recomienda el uso de los diagramas UML,

pero cuándo utilizar diagramas UML? y cuándo no hacerlo?.
4.1.1 Cuando no utilizar diagramas

• No dibujar diagramas porque el proceso te lo dice

• Porque te sientes culpable de no hacerlo o porque piensas que es
buen diseño hacerlo.
• Los buenos diseñadores escriben código y dibujan diagramas
solamente cuando es necesario.
• Dibujar diagramas para que otra persona codifique
4.1.2 Cuando utilizar los diagramas

• Utilizar los diagramas cuando varias personas necesiten entender

la estructura de una parte particular del diseño, porque todos
ellos lo estarán trabajando simultáneamente.
• Cuando dos o mas personas estén en desacuerdo con un elemento
particular que debería ser diseñado, y quieres un consenso del
equipo.
• Cuando quieras jugar con una idea de diseño, y los diagramas
pueden ayudarte a entenderlo.
• Cuando necesites exponer una estructura de alguna parte del
código a alguien más o a ti mismo.
4.1.2 los diagramas que se utilizan

• De estados: Estos diagramas nos muestra los diferentes

estados de un objeto durante su vida.
• De secuencia: Estos nos muestran el intercambio de
mensajes en un momento dado.
• De caso de uso: Los diagramas de casos de uso
describen qué es lo que debe hacer el sistema, pero no cómo.
4.2 Definición de Casos de uso

• Para la correcta definición de los casos de uso a emplear en la

especificación de los requisitos, se deben tener en cuenta algunos
aspectos como:
4.2.1 La identificación de actores

• Permite categorizar los diferentes grupos de actores.

• también debemos hacernos las siguientes preguntas:
• Quién o qué inicia eventos con el sistema?
• Quién proveerá, usará o quitará información?
• Quién usará esta funcionalidad?
• Quién está interesado en cierto requerimiento?
• En que parte de la organización será usado el sistema?
• Quién dará soporte y mantendrá el sistema?
• Cuales son los recursos externos del sistema?
• Qué otros sistemas necesitarán interactuar con este sistema?
• Al definir los actores que intervienen en un caso de uso se debe considerar que
una persona puede ejecutar distintos roles en el sistema. Hay actores
principales y hay actores secundarios
4.2.2 Intereses de los actores

• La identificación de estos intereses nos permiten priorizar

desarrollo de los casos de uso, planificar mejor las interacciones y
reconocer cuales son los usuarios con los que debemos levantar los
casos de uso.
4.2.3 La identificación de eventos
y escenarios que este podría llegar a tener

• La identificación de eventos y escenarios es necesarios para poder

determinar cual es la interacción entre el sistema y los actores,
que puede ser descrito mediante una secuencia de mensajes, es
una descripción narrativa de lo que la gente hace al intentar
utilizar la aplicación.
4.3 Especificación de Casos de uso

• Los casos de uso deben ser relatos secuenciales que especifiquen

una funcionalidad determinada del sistema que se desea
desarrollar, así que debe describir como inicia y termina el caso de
uso, que datos se intercambian entre el actor y el caso de uso, el
flujo de eventos.
4.4 Prototipos

• Los prototipos son modelos a escala de lo real, pero no tan funcional

para que equivalga a un producto final.
• Es importante definir un objetivo para los prototipos, ya que puede ser
útil en diferentes fases del proyecto, por ello su objetivo debe ser claro.

• Características de un prototipo
• El prototipo es una aplicación que puede no funcionar(conjunto de dibujos por
ejemplo, una presentación de escenarios) o que puede funcionar (conjunto de
pantallas que proporcionan un modelo dinámico).
• Los prototipos se crean con rapidez
• Los prototipos evolucionan a través de un proceso iterativo.
• Los prototipos tiene un costo bajo desarrollo.
4.5 Definición de criterios de aceptación

• Estos criterios nos permiten asegurar que los requisitos satisfacen la

funcionalidad requerida y al mismo tiempo que el producto es de
calidad.
• para la definición de criterios de aceptación se presenta el siguiente
modelo:
• Se debe encontrar el documento de requisito terminado, revisado y aprobado por las
diferentes partes, implicadas.
• El requisito no debe tener escenarios ambiguos
• El requisito debe hacer que dice el documento de especificación ni mas, ni menos y
cumplir con todos los escenarios.
• El requisito debe ser medible, es fácil identificar si cumple o no cumple.
• No existe contraindicaciones con otros requisitos
• El requisito debe haber sido probado y aceptado por este proceso.
• Se debe entregar el requisito dentro de las fechas establecidas.
• El requisito aparte de cumplir con los anteriores pasos, puede haber otros criterios
que el
cliente solicite.