Área: Tecnología

Taller de analítica avanzada

M1 Definición de requerimientos
 Módulo: 1
Curso: Taller de analítica avanzada

Mapa de Contenido

Entorno

Negocio

Investigación general Componentes

Análisis FODA del negocio Personas

Entrevista a usuarios
Problemas
destacados

Definición de Análisis de procesos

requerimientos actuales

Toma de requerimientos

Determinación de objetivos
y KPI del problema a
resolver

Informe de definición y
requerimientos del
proyecto
 Módulo: 1
Curso: Taller de analítica avanzada

Índice

Introducción ............................................................................................................................................................................................................ 4
1. Investigación general ..................................................................................................................................................................................... 5
1.1 Entorno .............................................................................................................................................................................. 6
1.1.1 Tipos de entorno ........................................................................................................................................................ 6
1.2 Negocio .............................................................................................................................................................................. 8
1.3 Componentes .................................................................................................................................................................... 8
1.4 Personas ............................................................................................................................................................................ 9
1.5 Problemas ........................................................................................................................................................................ 10
2. Análisis FODA del negocio ......................................................................................................................................................................... 11
3. Entrevista a usuarios destacados ............................................................................................................................................................. 13
4. Análisis de procesos actuales .................................................................................................................................................................... 15
5. Toma de requerimientos ............................................................................................................................................................................. 16
6. Determinación de objetivos y KPI del problema a resolver .......................................................................................................... 22
7. Informe de definición y requerimientos del proyecto .................................................................................................................... 24
Cierre ....................................................................................................................................................................................................................... 26
 Módulo: 1
Curso: Taller de analítica avanzada

Resultado de aprendizaje

Analiza la información recolectada a partir de la toma de requerimientos con un usuario, detectando

un problema de negocios, en un contexto de una problemática institucional.

Introducción
Abordando los aspectos principales de la ingeniería de software, particularmente, la etapa vinculada a la
definición de requerimientos es necesario recordar que el software se puede considerar como un
producto industrial y, como consecuencia, tiene sentido hablar de una ingeniería del software, entrando
en contacto con dos grandes problemas que afectan tradicionalmente al desarrollo de software, estas
son, las carencias referidas a la productividad y la calidad.

Al adentrarnos al proceso de elaboración del software se aborda

el desarrollo del ciclo de vida a partir de dos grandes modelos, en
cascada o clásico y los ciclos de vida iterativos e incrementales, en
todos iniciando con la gestión de requerimientos, siendo este una
representación escrita de las expectativas del usuario sobre lo que
quiere que haga el software.

En este sentido, gestionarlo implicará trabajar junto a los

desarrolladores para crear tareas automatizadas, acordes a los
procesos que el software emulará. Por tanto, una buena gestión de
requisitos garantizará un trabajo de mayor valor, bien definido y
organizado, enfocado en la obtención de la mayor cantidad de
información desde la interacción entre el usuario y el desarrollador,
siguiendo metodologías y estrategias efectivas.

Bajo este escenario, nos planteamos en este módulo, conocer y desarrollar varios aspectos que explican
o representan el proceso de definición de requerimientos, como: investigación general, entorno,
negocio, componentes, personas, problemas, análisis FODA del negocio, entrevista a usuarios
destacados, análisis de procesos actuales, toma de requerimientos, determinación de objetivos y KPI del
problema a resolver y, el Informe de definición y requerimientos del proyecto.

Pág. 4
 Módulo: 1
Curso: Taller de analítica avanzada

1. Investigación general
La gestión de requerimientos se encarga de definir o delinear lo
que el sistema debe cubrir respecto a procesar, consultar, reportar,
generar alarmas, interfaces, restricciones de seguridad y algunos
otros elementos que forman parte de las necesidades de la
organización, los cuales, al no ser identificados de manera correcta,
el software no podrá proporcionar al usuario la funcionalidad
deseada. Tampoco será posible determinar de una forma completa
y clara el alcance ni la dimensionalidad real del proyecto.

En este sentido, la gestión de requerimientos proporcionará los mecanismos adecuados que faciliten las
actividades de análisis, documentación y verificación de los procesos propios de la organización a ser
modelados mediante un software. Este tipo de gestión englobará actividades relacionadas con el
descubrimiento, documentación y mantenimiento del conjunto de requerimientos de un proyecto
de software de tipo empresarial.

Importante

Durante la planificación o coordinación estratégica para la investigación inicial en la gestión de

requerimientos, la Ingeniería de Requerimientos cumple un rol fundamental, pues busca
principalmente dar, tanto al usuario como al desarrollador, un mecanismo apropiado de
aseguramiento, desde donde puedan estar de acuerdo con la definición del alcance funcional y
técnico asociado al proyecto. Básicamente, se aborda la transformación de una necesidad operativa
en una descripción del sistema, cuyos parámetros de desempeño y configuración se concretan a
través del uso de un proceso iterativo de análisis, diseño y prototipado.

La investigación inicial probablemente deba reflejar una complejidad, por consiguiente, si existiera algo
técnico, el desarrollador deberá incorporar también una explicación concreta para disipar las dudas del
usuario final, garantizando la comprensión y abordaje correcto del proceso por ambas partes.

Requerimientos de un proyecto de software

Es de suma importancia delimitar o comprender la diferenciación
existente entre los requerimientos de sistemas y los de software,
siendo el primero aquellos asociados al cliente y, el segundo
asociado a los requerimientos y/o especificaciones del sistema.

Como el cliente es el experto ejecutor y conocedor de los procesos

del negocio, sabe cuáles son sus necesidades de información; sin
embargo, el proveedor de la información será el experto en las características principales del sistema y
las especificaciones del software.

Pág. 5
 Módulo: 1
Curso: Taller de analítica avanzada

1.1 Entorno
En el ámbito del desarrollo del software, la
disposición de un entorno de trabajo
adecuado marca la diferencia entre alcanzar
un resultado óptimo o simplemente no lograr
nada. Por consiguiente, uno de los aspectos
de mayor relevancia a considerar es el diseño
de cada entorno presente y necesario en el
ciclo de vida del software; por supuesto,
también lo serán los procedimientos que
establecen el flujo de trabajo entre ellos.

Podemos definirlo entonces cómo un sistema que posee hardware, software y una configuración
basada en circunstancias y estados asociados a él. Dentro de cada procedimiento será posible
establecer varios entornos con fines variados, los cuales representarán etapas a cubrir por el software
durante su ciclo de vida antes de llegar al entorno de producción final.

1.1.1 Tipos de entorno

▪ De desarrollo
Se define como el lugar donde se programa, ubicado en un computador desde donde los desarrolladores
podrán trabajar en distintos aspectos de un mismo proyecto, a la vez.

Recuerda

Debemos tener presente que aun cuando cada desarrollador tiene su entorno de desarrollo y está
enfocado en aspectos distintos del proyecto, todos deben mantener las misas condiciones de su
entorno, evitando errores de compilación o de ejecución asociadas a configuraciones distintas o
incluso a diferentes sistemas operativos.

Solo cuando el desarrollador completa un código perfectamente funcional e integrable en el entorno de

preproducción y tras realizar las pruebas necesarias para asegurar que el software desarrollado tiene la
estabilidad suficiente se podrá pasar al entorno de integración continua.

▪ De integración continua
Es un tipo de entorno que integra el trabajo de todos los desarrolladores en un repositorio central, con
el fin de generar un resultado en una sola versión de código, automatizando las pruebas de integración
y validación previas al cambio de entorno. También, este tipo de entorno se enfocará en permitir el envío
del código al siguiente entorno, si las pruebas han sido superadas de forma satisfactoria.

Pág. 6
 Módulo: 1
Curso: Taller de analítica avanzada

▪ De pre - producción
Utilizados luego de superar la prueba de integración, donde se realizan pruebas de validación al software
en general, buscando localizar cualquier error antes de pasar al entorno de producción, evitando
cualquier problema que pueda derivarse de este escenario. Este entorno se mostrará funcional a nivel de
usuario, siendo crítico garantizar que el entorno de desarrollo sea similar al de producción, a nivel de
aplicaciones, versiones, configuraciones, hardware y sets de datos.

Importante

A mayor similitud menor será el número de incidencias a presentarse, cuando el software esté en
producción.

▪ De demo
Se asemeja muchísimo al de pre-producción, y por tanto al de producción. Este entorno se usa para que
el cliente final pueda probar el software, considerando los últimos cambios que se han realizado sobre
él, de esta forma no solo lo valida, sino también localizar de una forma temprana posibles carencias en
los requisitos iniciales de la investigación inicial, en el diseño o en la implementación.

Por supuesto, la validación del cliente es siempre necesaria, no disponer de este entorno puede suponer
el origen o presencia de varias situaciones:

Detener la actualización del

entorno de pre-producción
generando molestias y
dificultades extra en los
Una nueva actualización en
desarrolladores, retrasando
el entorno de pre-
por supuesto las fechas del
producción, probablemente
proyecto.
asociada a la funcionalidad
No hay correcciones que
que estamos probando,
realizar ni problemas que
provocando errores
resolver.
requiriendo dar la validación
por fallida.

Si trabajamos con una metodología ágil, estos problemas se verán aumentados, ya que se dará un mayor
nivel de iteración en el desarrollo del software.

▪ De producción
Es el entorno final y es aquel donde será posible visualizar las virtudes y defectos del trabajo desarrollado
hasta el momento. En efecto, los entornos anteriores deberán asegurar una llegada a este punto de forma
eficiente, garantizando la fiabilidad y la diferencia de calidad sobre el resultado final.

Pág. 7
 Módulo: 1
Curso: Taller de analítica avanzada

1.2 Negocio
Cuando se realiza la investigación inicial sobre
la que se enmarca el desarrollo del software,
se debe considerar el negocio, siendo este
visto como una secuencia de actividades
donde se produce un listado de
requerimientos asociados al nuevo sistema de
información, analizando, validando y
documentado todo bajo una especificación
formal.

Los requerimientos basan su importancia en

que proveen las bases para el trabajo de
desarrollo, a partir de los cuales se realiza el diseño, desarrollo, implementación y generación de
pruebas. En este sentido, tomar la documentación de un proceso de negocios para realizar un
levantamiento de requerimientos, es una estrategia efectiva para disminuir riesgos propios de este
proceso, identificando capacidades, características y factores de calidad del sistema de información.

Bajo este escenario, es común emplear BPMN (Business Process Model and Notation) desde el punto de
vista de negocio, pues desde él se realizan especificaciones de requerimientos. El modelado y
entendimiento del proceso de negocio es responsabilidad del Analista de Requerimientos.

1.3 Componentes
Cualquier proceso en el desarrollo de
software implica la descomposición
funcional del mismo, refiriéndose a la
identificación y resolución de las relaciones
funcionales en sus partes constituyentes,
buscando que la función global pueda
reconstruirse a partir de sus partes.
Generalmente, esta descomposición se
realiza para identificar y entender los
componentes o partes que constituyen un todo, es decir, la función global, sin olvidar considerar las
interacciones entre componentes para analizarlos individualmente. De requerirse, es posible
descomponer en tantas partes como sea necesario para lograr un nivel alto de detalle.

En esencia, la importancia de generar tanta división del sistema es describir cada componente sin
necesidad de referirse a otro. De esta manera, cada parte del sistema tendrá funciones independientes,
reutilizables y reemplazables.

Pág. 8
 Módulo: 1
Curso: Taller de analítica avanzada

1.4 Personas
Durante el desarrollo del software la presencia y participación de
diferentes perfiles de persona se hace de suma importancia, puesto
que cuanto mayor sea la ayuda de los usuarios en un proyecto de
desarrollo de software, mayor será la probabilidad de generar un
software que cubra todos los requerimientos asociados a un proceso.
Sin embargo, particularmente en este punto, la toma de
requerimientos, donde es importante seguir varios principios
fundamentales como:

▪ La interacción con el usuario ayuda a interpretar con precisión lo que necesita, por tanto, si no
existe un feedback continuo durante todo el proceso de desarrollo, aumentarán las posibilidades
de que algún requisito funcional no haya sido recogido adecuadamente. También podría
desarrollarse un software con una usabilidad bastante incómoda o inadecuada para los usuarios.

Estas circunstancias conllevan a problemas en las fases finales del proyecto, provocan retrasos,
aumento de costos y enormes dificultades finalizar propiamente el proyecto, además de crear
conflictos en las relaciones con el cliente. Por consiguiente, se hace fundamental la interacción
efectiva entre, usuario, cliente, el jefe de proyectos, los analistas funcionales y los
desarrolladores.

▪ Es importante que entre el grupo de usuarios se encuentre uno enfocado en el uso final del
sistema, no solo aquellos que definen el uso desde un punto idealista y/o teórico, a fin de que
desde todas esas perspectivas se nutra el resultado definitivo de la herramienta. Dentro de los
usuarios también es importante clasificarlos por niveles de usabilidad, ya que el software no sólo
se diseña para el corto plazo, sino que sirva para tareas de gestión, planificación, entre otras,
generando una visión de uso más robusta.

▪ Los analistas deben limitarse a tomar los requerimientos que el usuario le provee, no para
indicar o plantear cambios en la forma de trabajos de estos. La clave se basa entonces en la
colaboración y en el diálogo, pudiendo proponer alternativas de ejecución al usuario, sin modificar
el desarrollo actual de la tarea, salvo que ellos mismos lo soliciten.

▪ Como todo proceso, es esencial la documentación del paso a paso, sirviendo de base para el
establecimiento de normativas de calidad en la organización, servir de guía de trabajo para la
ejecución de tareas de los usuarios, de una forma clara precisa y concisa, recordando que ellos no
son desarrolladores. Estas guías también buscan que el usuario comprenda mejor lo que el
desarrollador o analista hace, para aportar información que nutra el proceso en desarrollo, pues
sin esto, la construcción se hará arriesgada, impactando en los costos por modificaciones no
previstas, debiendo tal vez reconstruir varias veces distintas funcionalidades del sistema.

Pág. 9
 Módulo: 1
Curso: Taller de analítica avanzada

1.5 Problemas
Es común que, durante la investigación inicial, los requerimientos del proyecto de software no sean
expresados con claridad, o bien, se documenten de manera inapropiada. Aunque existen técnicas y
herramientas para ejecutar estas tareas con efectividad, muchas veces se dejan de lado o no se usan de
forma correcta debido a su complejidad, llegando a ser incomprensibles para los usuarios y, algunas
veces no reflejan la realidad. En este sentido, un problema común son los cambios en los requerimientos
del proyecto de software, cambios que, de actualizarse en la documentación, o no ser comunicados a
todos los grupos involucrados en el desarrollo, impactarán de manera importante y radical en la
planeación y arquitectura del proyecto.

Recuerda

Según la naturaleza del proyecto es posible definir distintos tipos de requerimientos, cada uno con
varios niveles de detalle. Realmente, la cantidad de requerimientos de un proyecto podría ser muy
grande y difícil de controlar, requiriendo de una alta participación del usuario en el proceso, para
identificar y validar cada requerimiento, garantizando así que sean los correctos y se cubran sus
necesidades.

Para evitar o disminuir la presencia de problemas en la clasificación de la información y el origen o fuente

de ella, podemos considerar la jerarquización de los requerimientos como sigue:

Dominio del Problema

(Cliente):
•Necesidades del Negocio

Dominio de Solución
(Proveedor)
•Especificaciones del Software
•Características del Sistema

Jerarquía de requerimientos

Pág. 10
 Módulo: 1
Curso: Taller de analítica avanzada

2. Análisis FODA del negocio

En el ámbito empresarial el análisis FODA es una estrategia que
permite el reconocimiento de amenazas, debilidades,
oportunidades y fortalezas. Para el desarrollo de software será una
herramienta de suma importancia, puesto que sus aspectos
fundamentales permitirían la obtención de un producto final bastante
pulido y acoplado a las necesidades del usuario.

El análisis FODA es entonces una herramienta de planificación estratégica, empleada por las empresas
para realizar dos tipos de análisis, uno interno para identificar las fortalezas y debilidades y, uno externo
para revisar las oportunidades y amenazas de la empresa.

Realizando este análisis buscaremos los factores que pueden afectar el cumplimiento efectivo de un
proceso. Por supuesto, el tener claridad en ello, nos permitirá anticiparnos a escenarios de riesgo, poder
hacer frente a las amenazas y aprovechar las oportunidades. Desarrollándose así una estrategia de
negocio sólida y se tomen decisiones teniendo en presente los factores más importantes.

Importante

En el desarrollo de software, especialmente en la gestión de requerimientos, es recomendable es

que todos los tipos de usuario participen y que al finalizar el análisis este sea sencillo y práctico de
entender, pudiendo sobre el tomar decisiones y mejorar los productos.

•Para cada proceso debemos añadir los atributos o puntos positivos que
Fortalezas pueden servir para alcanzar los objetivos.

•En este punto se debe tener en cuenta las condiciones externas, revisando
Oportunidades la industria y otros factores como las regulaciones que pueden afectar de
forma positiva a los procesos y por ende a los objetivos de desarrollo.

•Se deben identificar los elementos perjudiciales o los factores de impacto

Debilidades negativo para nuestro objetivo. Son factores internos, por lo tanto, la
opinión del usuario y el cliente juegan un papel importante.

•Se debe identificar todo aspecto que puede amenazar el funcionamiento

Amenazas de un proceso y la potencial ganancia de resultados de forma externa.

Pág. 11
 Módulo: 1
Curso: Taller de analítica avanzada

Para desarrollar el análisis FODA se requieren cuatro listas:

Crear una lista de fortalezas actuales

Crear una lista de debilidades actuales

Crear una lista de oportunidades para el futuro

Crear una lista con las amenazas para el futuro

Cada lista debe contener información real y con especificaciones sencillas de fácil comprensión. Luego
de construirlas se deberán evaluar los distintos resultados obtenidos, definiendo sobre ellos estrategias
a corto y largo plazo.

Ejemplo

Una empresa de telecomunicaciones posee un software especializado y definido como una

plataforma de BI (Business Intelligence), es decir, orientada a la solución y centrada en procesos.
Particularmente este software conforma una infraestructura de herramientas de análisis e informes,
integrada con un motor de workflow para procesos de negocio. La plataforma podrá ejecutar reglas
de negocio, indicadas en forma de procesos y actividades, presentando la información
adecuadamente y en el momento oportuno.

Su modelo de solución se basa en software libre e incorpora distintas soluciones de código abierto,
desarrollados a partir de proyectos comunitarios de larga trayectoria, en el segmento de Business
Intelligence. En función de esto, a continuación, presentamos el Análisis FODA respectivo, sobre los
que se deberán implementar estrategias de mejora o cambio:

Pág. 12
 Módulo: 1
Curso: Taller de analítica avanzada

3. Entrevista a usuarios destacados

Resulta común que en la fase de inicio de un software
presentar la necesidad de recolectar información
directamente desde el usuario, y la mejor forma de hacerlo es
a través de una entrevista, que da como resultado una
herramienta bastante poderosa en el análisis de sistemas,
distinguiendo allí dos tipos de información cualitativa y
cuantitativa. La primera se relaciona con opiniones, políticas
y descripciones narrativas de actividades o problemas y la
segunda con números, frecuencias o cantidades.

Constantemente la entrevista es vista como la mejor fuente de información cualitativa y la técnica más
utilizada en la recolección de información durante las fases de análisis de los sistemas de un proyecto de
desarrollo de software, siendo incluso la mayor fuente de información del analista.

Durante la entrevista el analista no

Las entrevistas pueden relaizarse
se enfoca solo a informarse sobre
sobre la base de un cuestionario
aspetos particulares, sino que
rígido o de una guía con cierto
además aprovecha para explicar su
detalle, orientada siempre hacia
trabajo a los usuarios mejorando la
puntos específicos.
interacción.

La entrevista permite a los analistas

exponer sus necesidades con Con ella el analista puede conocer
detalle y claridad, verificando en las el grado de aceptación o resistencia
respuestas que recibe, si la que existe entre los usuarios hacia
interpretación dada a las preguntas el sistema que se desea diseñar.
es la correcta.

Preparación de la entrevista
No debe ser vista como un interrogatorio sino como una conversación donde el analista se prepara de
antemano para obtener la información necesaria, para ello debe considerar lo siguiente:

▪ Acordar con el usuario la fecha, la hora y el lugar de la entrevista.

▪ Dar garantías de la privacidad de la información, evitando interrupciones y disponiendo del
tiempo suficiente para ejecutarla.
▪ Definir criterios previos de las personas a entrevistar con miras de desarrollar una conversación
más natural.
▪ preparar cuidadosamente las preguntas a realizar o la guía de la entrevista

Pág. 13
 Módulo: 1
Curso: Taller de analítica avanzada

Ejecución de la entrevista
Dependiendo del tipo de entrevista varía la ejecución, por
ejemplo, si es abierta el entrevistado podrá expresar más de lo
que se le pregunta., si es cerrada, responderá solo conforme a
las preguntas de una lista.

También se debe considerar la estructura, por ejemplo, si es

de tipo pirámide se comienza con los detalles, y se pasa a
preguntas más generales. De tipo embudo se inicia con
aspectos generales y se finaliza con preguntas más cerradas.
De tipo diamante, se combinan las dos anteriores.

Finalmente, algunos aspectos adicionales a considerar para alcanzar un proceso de ejecución exitoso, se
debe iniciar dejando claro el tema de la entrevista y estableciendo la naturaleza del proyecto sobre el
cual se trabaja, abordar cuestionamientos o dudas generales que puedan presentar los entrevistados
sobre puntos intermedios, evitando utilizar más tiempo del debido. Tratar de no preguntar sobre otros
temas cuya información pueda obtenerse por otras vías, a menos que se desee comprobar algo.

El tacto, la imparcialidad e incluso la vestimenta apropiada contribuyen a tener una entrevista exitosa. No
olvidar prestar la máxima atención durante el desarrollo, creando un clima favorable, evitando discusiones
inapropiadas, no hacer críticas, utilizar términos adecuados, no adelantarse a ningún criterio ni opinión
de los usuarios y mucho menos sacar conclusiones sobre la información que se recibe.Evitar que la
entrevista sea larga o se convierta en inoportuna por razones no definidas previamente, en ese caso debe
posponerse. Al finalizar, resuma la información recabada e indique que se preparará para quienes
respondieron un resumen escrito que podrán revisar con detalle posteriormente.

Dificultades que pueden presentarse durante las entrevistas

Es posible que se presenten dificultades durante el desarrollo de la entrevista, siendo pertinente por parte
del analista tomar ciertas acciones, entre ellas:

Pág. 14
 Módulo: 1
Curso: Taller de analítica avanzada

4. Análisis de procesos actuales

Los encargados de recoger los requisitos, a pesar de su formación
y experiencia no conocerán la actividad profesional de los
usuarios, siendo conveniente entonces adquirir cierto
conocimiento desde el punto de vista organizativo y, como
consecuencia, de la terminología que se utiliza.

Importante

A este procedimiento se le denomina contexto del software, descrito como el modelo del dominio
(forma simplificada), y como el modelo del negocio (forma más detallada). En cualquier caso, se
debe elaborar un glosario con los términos de mayor uso. Incluso si no se realiza ninguno de los
dos modelos, conviene confeccionarlo.

En la ingeniería de software, el análisis de procesos es una tarea tanto del desarrollador como del cliente
tienen un papel activo, pues juntos definen con detalle los requisitos del sistema a desarrollar y los pasos
a seguir.

Características principales de este análisis

5. Mantiene como
1. Se profundiza a foco la entrega del
2. Permite 3. Se respalde con
partir de una proyecto dentro
especificar las entrevistas,
necesidad 4. Describe el plan del tiempo y
características de observaciones,
tecnológica en la del proyecto a presupuesto
operación del indagaciones y
empresa, seguir. establecido, sin
software a otras técnicas
organización o salirse de los
desarrollar. específicas.
negocio. objetivos de
negocio.

En este análisis también suelen presentarse problemas y errores, entre ellos:

▪ Quejas y sugerencias sobre cómo se realiza una tarea propia de un proceso.
▪ Esta información no se documenta de manera formal.
▪ Una tarea o secuencia de tareas no siempre se representa a través de un diagrama de actividad
simplificado, dificultando la comprensión.

Pág. 15
 Módulo: 1
Curso: Taller de analítica avanzada

5. Toma de requerimientos
Tal como se ha mencionado con anterioridad, los requisitos
son la especificación de lo que debe hacer el software,
específicamente descripciones del comportamiento,
propiedades y restricciones del software a desarrollar.

Lo ideal sería que los requisitos indiquen qué tiene que realizar
el software, sin necesidad de decir cómo debe hacerlo; esto se
dificulta por varias razones: Desde el conocimiento de los
desarrolladores puede resultarles difícil entender unos requisitos con al nivel de abstracción. También
debe al menos existir alguna referencia mínima a la tecnología utilizada. Por último, el software deberá
ser compatible con el entorno técnico y organizativo.

▪ Objetivos
Dentro de la toma de requisitos se consideran dos objetivos:
a) Servir de base para un acuerdo entre los
usuarios, clientes y desarrolladores acerca
del software a desarrollar. Esto quiere decir
que la documentación de los requisitos
deberá llevarse a cabo de una manera
inteligible para los usuarios, quienes
tendrán que revisarlo.

b) Los requisitos representan la

información de partida para el desarrollo
del software; son realmente el suministro
de entrada de la etapa de análisis.

▪ Clases de requisitos
Existen dos clases de requisitos, los funcionales y los no funcionales.

Los primeros, describen qué debe realizar el software para sus usuarios, por ejemplo: aceptar, verificar y
registrar datos, transformarlos, presentarlos, etc. Quedan todo ellos recogidos en los casos de uso.

Los segundos, consisten en restricciones impuestas por el entorno y la tecnología, especificaciones sobre
tiempo de respuesta o volumen de información tratado por unidad de tiempo, por ejemplo: requisitos
asociados a interfaces, extensibilidad, facilidad de mantenimiento, etc.

Pág. 16
 Módulo: 1
Curso: Taller de analítica avanzada

▪ Fuentes de información
Con la finalidad de recoger información a partir de los requisitos que
debe cumplir el software, es necesario recurrir a las fuentes de
información siguientes, destacando entre ellas:

a) Entrevistas y encuestas: dirigidas a los usuarios finales del

software, sin olvidar la importancia de acompañar la
información que se puede obtener por estas vías junto a la
observación directa del trabajo de estos.
b) La documentación asociada al sistema actual: Efectivamente, si el sistema está automatizado,
deben existir manuales, los cuales se deberán estudiar para comprender la aplicación,
funcionamiento e incluso procedimientos manuales de apoyo.
c) Otros usuarios. Es posible que los usuarios finales del software ejecuten sus tareas siempre del
mismo modo, trayendo como consecuencia la necesidad de conocer otros puntos de vista, esto
para encontrar ayuda adicional para salir de los esquemas prefijados. En este caso es posible
entonces hablar con los colegas de los usuarios mismos, los desarrolladores o unos y otros.
d) Finalmente, resulta de mucha utilidad realizar una revisión comparativa con sistemas parecidos
que puedan existir en el mercado.

Importante

Los usuarios pueden llegar a considerar evidente que algunas funciones forman parte del dominio
general, haciendo innecesario mencionarlas, y que, probablemente, están implementadas en
cualquier software parecido que exista.

Esta misma situación se presenta con las denominadas funciones del sistema, no usadas directamente
por los usuarios finales en sus trabajo o tareas particulares, pero que no dejan de ser convenientes, y a
menudo esenciales para el funcionamiento regular del software, por ejemplo:

▪ Reorganización de bases de datos generales

▪ Alta y baja de usuarios
▪ Mantenimiento de parámetros y tablas básicas propias del software.

Pág. 17
 Módulo: 1
Curso: Taller de analítica avanzada

▪ Pasos para la recogida y documentación de requisitos

1) Conocer el contexto
2) Recoger y clasificar y 3) Identificar los
del software a
los guiones. actores.
desarrollar.

5) Identificar las
6) Identificar las
4) Identificar los casos relaciones entre casos
relaciones de
de uso a partir de los de uso considerando
especialización entre
guiones. extensión, inclusión y
actores.
especialización.

7) Documentar todos
los casos de uso.

Paso 1. El contexto del software

Considerar al usuario para adquirir cierto conocimiento desde el punto de vista organizativo,
contextualizándose así sobre los procesos organizacionales que simulará o apoyará el software a
desarrollar.
Como se mencionó con anterioridad, este contexto se puede describir de dos formas, a partir del modelo
del dominio y del modelo del negocio. Sin olvidar el glosario de términos.

Paso 2. Los guiones

En realidad, los usuarios difícilmente identificarán los casos de uso sistemáticamente y con claridad. Por
lo general solo explicarán las operaciones de mayor frecuencia que realizan en su trabajo, siendo estos
considerados como guiones. Los guiones tienen las características siguientes:

▪ Se ven como sesiones ejecutadas por un actor respecto a un software.

▪ En el caso de un sistema de software pueden existir muchos guiones, sin embargo, es suficiente
con describir un subconjunto donde aparezcan al menos una vez, todas las funciones del software.
▪ Se utilizan para extraer los casos de uso.
▪ Los guiones resultan ser la fuente de información principal, donde se expresan las necesidades de
los usuarios desde su perspectiva, sin embargo, conviene no olvidar que cada guion debe describir
de manera precisa y completa la interacción correspondiente entre el usuario y el software,
incluyendo casos particulares y precondiciones.

Pág. 18
 Módulo: 1
Curso: Taller de analítica avanzada

Paso 3. Identificación de los actores

Realmente un actor es un factor o entidad externa que se prevé va a interactuar con el software, dando
información o recibiéndola. Las entidades externas mencionadas podrían ser personas, máquinas, otros
sistemas de software o instantes en el tiempo sobre los que debe ponerse en marcha de forma automática
algún proceso. Cada uno tendrá un papel para cada caso de uso en el que interviene y, un papel primario
será aquel donde el factor o elemento pone en marcha el caso de uso correspondiente.

Algunas consideraciones sobre los actores son:

1) Una persona podría ser un actor, si es que puede tener diferentes conjuntos de papeles
independientes respecto al software (no importa si dos actores resultan ser la misma persona
o no).

2) Los actores no deberian llevar a cabo ninguna secuencia de casos de uso determinada, por
el contrario, cada uno invoca diferentes casos de independientemente según los momentos
definidos por su actividad exterior con el software.

3) Cada actor debe relacionarse al menos a un usuario particular, evitando definir actores
demasiado abstractos.

4) Basta con identificar los actores, no describirlos con tanto detalle.

5) No tiene sentido que dos actores esten definicidos con intervención y pales en los mismos
casos de uso.

Paso 4. Clasificación de los actores

El usuario definitivo o perfil del usuario final, será aquel que describa la interacción directa con el sistema,
mediante funciones específicas.

El usuario privilegiado o gestor del sistema será aquel que defina la forma de funcionamiento del sistema,
utilizando funciones mucho más específicas y robustas sobre este.

Paso 5. Identificación de los casos de uso

1) Los casos de uso tienen estas características:
2) Representan procesos autónomos que son iniciados por un actor o por otro caso de uso. En este
sentido, dos procesos iniciados por actores diferentes no podrán ser parte del mismo caso de uso.
Tampoco podrán serlo aquellos procesos que no sean o hayan sido puestos en marcha
directamente por un actor, excepto los que formen parte de otros casos de uso a través de las
relaciones "include".
3) Se usan para representar funciones ofrecidas por el software, identificando sus entradas y salidas.
En definitiva, debería proporcionar siempre un resultado dirigido al actor primario.

Pág. 19
 Módulo: 1
Curso: Taller de analítica avanzada

4) Describen el qué de estas funciones y no el cómo, excepto las especificaciones no funcionales, a

las cuales a veces se puede dar la forma de casos de uso.
5) Es posible usarlos para pruebas de caja negra.
6) Los casos de uso a describirse por primera vez en una iteración determinada, debiendo encajar
con los de las iteraciones anteriores, sin embargo, es posible modificarlos estos últimos si esto es
necesario.

No podemos olvidar siempre describir todos los casos de uso relativos al software considerado. Sin
embargo, dentro de un ciclo de vida iterativo e incremental, se realizará paso a paso. Los casos de uso se
obtienen de los guiones, y se identifican las partes autónomas y eventualmente comunes a diferentes
guiones indicando donde participa un mismo actor; también suele pasar que un caso de uso contenga
diferentes guiones completos.

Paso 6. Identificación de las relaciones entre casos de uso

Se pueden considerar el siguiente conjunto de reglas:

1) Una relación de extensión estará relacionada con una condición. Por tanto, al haber diferentes flujos
de proceso posibles o casos especiales, o bien, errores que deban tratarse de otra forma, se tendrán
relaciones de extensión. Aún a pesar de esto, el caso de uso ejecutado de forma condicional tiene
autonomía en el sentido de que proporciona cierto resultado concreto al actor que lo ha iniciado, siendo
el mismo del del caso que se extiende.

Ejemplo

Un cliente podría darse de alta si, no está en la situación de uso de registro de un pedido ni en la
planificación de visita de un vendedor; en ambos casos, el actor debería ser quien pueda dar de alta
a los clientes.

2) Una relación vista desde la inclusión es netamente un recurso usado para evitar describir una misma
parte del proceso dentro de diferentes casos de uso.

Ejemplo

Una factura con errores se debe poder rechazar y devolver, sobre todo si la factura es por una
compra y por un servicio. Es decir, el caso de uso de rechazo de una factura deberá incluir tanto el
caso de uso de tratamiento de una factura de compra como el de una factura de servicio.

Pág. 20
 Módulo: 1
Curso: Taller de analítica avanzada

En este sentido, no es necesario que el caso de uso incluido tenga autonomía ni que sea ejecutado
directamente por un actor. Otra alternativa podría ser que la relación es de extensión, puesto que no hay
oposición al hecho de que un caso de uso extienda varios usando al mismo actor.

3) La relación de especialización es indicada si los dos casos de uso están relacionados, es decir, uno es
una versión especializada de la otra, respecto al sentido (ejemplo, el primero se aplica a una subclase de
la clase a la cual es aplicado el segundo).

Ejemplo

Considere un caso de uso de una matrícula estudiantil de nuevo ingreso, tomando en cuenta una
especialización de la matriculación del estudiante en general, por tanto, el proceso adicional a
realizarse en el primer caso será un conjunto de operaciones independientes y dispersas. Pero, si
este proceso adicional tiene entidad propia, la relación podrá ser una extensión entre el caso general
y la parte que sólo se realiza para los estudiantes de nuevo ingreso.

Pág. 21
 Módulo: 1
Curso: Taller de analítica avanzada

6. Determinación de objetivos y KPI del problema a

resolver
Es conveniente recordar que el objetivo primordial de la
ingeniería del software se basa en la producción de un
sistema, aplicación o producto de alta calidad, empleando
para ello métodos efectivos junto con herramientas
modernas dentro del contexto de un proceso maduro de
desarrollo del software. También, se debe considerar
formas para medir si la alta calidad se da.

En este sentido, es posible conocer un conjunto de

métricas del software empleadas para la valoración
cuantitativa de la calidad de este, por ejemplo:

La calidad, siendo esta definida como una característica o atributo de algo, o bien, la totalidad de rasgos
y características de un producto, proceso o servicio, representando la habilidad de satisfacer estados o
necesidades implícitas.

Por ende, la calidad de un sistema, aplicación o producto deberá ser tan buena como los requisitos que
detallan el problema, el diseño que modela la solución, el código que transfiere a un programa ejecutable
y las pruebas que ejercita el software para detectar errores.

Por tanto, se emplearán mediciones para evaluar la calidad del análisis y los modelos de diseño, el código
fuente y los casos de prueba definidos al aplicar la ingeniería del software. Para ello, se utilizarán medidas
técnicas, que evalúan la calidad manteniendo la objetividad, siendo este el principio fundamental de un
buen administrador de proyectos. A medida que el proyecto progresa el administrador deberá valorar la
calidad, considerando siempre el enfoque de medir errores y defectos.

Dentro de este contexto de medición es posible emplear las métricas, las cuales proporcionan una
indicación de la efectividad de las actividades de control, dando garantía de calidad en grupos o en
particulares. Por ejemplo, los errores detectados por hora al realizar una revisión y los errores detectados
por hora al realizar una prueba, suministrando una visión profunda de la eficacia de cada una de las
actividades basadas en la métrica. De esta forma, se pueden usar estos datos para calcular la eficiencia
de eliminación de defectos en presente en cada una de las actividades del marco de trabajo del proceso.
▪ Medida de la calidad
Aun cuando existe una gran cantidad de medidas de calidad de software, la corrección, facilidad de
mantenimiento, integridad y facilidad de uso, son los indicadores más fuertes y útiles para el equipo del
proyecto.
Particularmente, la corrección corresponde al grado en el que el software lleva a cabo una función
requerida. La medida más común de corrección son los defectos por KLDC, en donde un defecto se define
como una falla verificada de conformidad con los requisitos.

Pág. 22
 Módulo: 1
Curso: Taller de analítica avanzada

Por su parte, la facilidad de mantenimiento representa la habilidad con la que es posible corregir un
programa al encontrar un error, adaptándolo si su entorno cambia u optimizándolo si el cliente desea un
cambio de requisitos. Una métrica de este estilo suele ser aquella orientada al tiempo simple, es decir, al
tiempo medio de cambio (TMC) o tiempo que se tarda en analizar la petición de cambio, en diseñar una
modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio a todos los usuarios.

Importante

En general, los programas que se pueden mantener tendrán un TMC más bajo que aquellos que no.
El costo estará en corregir defectos hallados después de haber distribuido el software a sus usuarios
finales.

Cuando la proporción de desperdicios en el costo global del proyecto se simboliza como una función del
tiempo, es aquí donde el administrador logra determinar si la facilidad de mantenimiento del software
mejora, pudiendo emprenderse acciones a partir de las conclusiones obtenidas de esa información.

Respecto a la Integridad, actualmente esta ha llegado a tener mucha importancia, tanto que mide la
habilidad de un sistema para soportar ataques contra su seguridad, accidentales o intencionados. Para
medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. El primero
visto como la probabilidad de que un ataque de un tipo establecido ocurra en un tiempo establecido. La
segunda, como la probabilidad de que se pueda repeler el ataque de un tipo establecido.

Finalmente, la facilidad de uso es un intento de cuantificar que tan accesible y manejable pude ser el
software para el usuario, pudiendo medirse tomando en cuenta cuatro características:

Destreza intelectual y/o física requerida para aprender el sistema.

El tiempo que se necesita para alcanzar un nivel moderado de

eficiencia en el uso del sistema.

Aumento neto en productividad, basado en que el sistema

reemplaza, midiendolo cuando alguien usa el sistema moderada y
eficientemente.

Valoración subjetiva (pude ser obtenida con un cuestionario) de la

disposición de los usuarios hacia el sistema.

Pág. 23
 Módulo: 1
Curso: Taller de analítica avanzada

7. Informe de definición y requerimientos del proyecto

El informe de definición o documentación textual, parte
de la descripción textual de los casos de uso y el glosario
de términos general. En esencia, la descripción textual es
necesaria para conocer con detalle cada caso de uso,
siendo conveniente llevarla a cabo mediante una plantilla
sujeta a unas normas de formato.

Recuerda

Una forma de realizar la documentación textual de un caso de uso es estableciendo convenciones

como: Nombres de actor en negrita, Otra terminología del usuario en cursiva, Referencias a otros
casos de uso subrayadas.

▪ Estructura del documento

La documentación textual debe seguir la estructura siguiente:
Cabecera. Número y nombre del caso de uso, resumen de la funcionalidad, funcionalidad del
caso de uso respecto al trabajo del usuario, casos de uso relacionados, actores.
Cuerpo. Considera la precondición y postcondición del sistema, descripción de etapas, contenido
de las entradas y salidas, definición de alternativas de proceso y excepciones.
Final. Aclaraciones generales, sin olvidar, las respuestas se incluirán, con autor y fecha, dentro de
los comentarios, hipótesis establecidas sobre aspectos no aclarados, comentarios, cambios.
El glosario. esencial para unificar la terminología y su interpretación. Se puede extraer del modelo
del dominio o del negocio, o también obtenerse a partir de entrevistas con usuarios.

▪ La documentación formal
En este caso es de suma importancia contar con un diagrama de casos de uso que muestre todas las
relaciones entre éstos y entre los actores. Además, es posible que, para casos de uso específicos, sea
conveniente emplear algún otro diagrama, complementando la descripción textual: diagrama de
actividades, de estados o de interacción.

Quizá podría crear alguna confusión el hecho de que en el análisis se usen también estos diagramas,
buscando describir de manera detallada y formalizada los casos de uso; sin embargo, hay diferencias
que lo justifican:

a) Para los requisitos, la descripción de los casos de uso será básicamente textual, y los diagramas
solo fungirán una función complementaria y no se elaborarán sistemáticamente para todos los
casos (recordemos que los usuarios deben entender los requisitos, obligando esto a no usar

Pág. 24
 Módulo: 1
Curso: Taller de analítica avanzada

notaciones muy formales). En cambio, en el ámbito de análisis, los diagramas de interacción o de

actividades serán sistemáticos para todos los casos de uso, cumpliendo con un paso de
formalización en términos de objetos antes de ser implementado.
b) Los diagramas del análisis requieren que las clases sean definidas en el diagrama estático, a la par
de que los objetos mostrados en los diagramas de los requisitos sean identificados en el modelo
del dominio, en el modelo del negocio, o en el momento de realizar el diagrama donde se citan,
y por tanto son provisionales.

Pág. 25
 Módulo: 1
Curso: Taller de analítica avanzada

Cierre
En ingeniería de software es de suma importancia ejecutar
procedimientos eficientes asociados para recoger y
documentar los requisitos del software a desarrollar,
considerando dos vertientes, los procesos y la interfaz de
usuario. Previamente a la recogida de requisitos, los
desarrolladores deben adquirir y documentar cierta
información relacionada con el entorno en el cual se usará el
software, usando para ello el modelo del dominio o el modelo
del negocio.

Por otro lado, sabiendo que existen diferentes fuentes desde donde se puede extraer información útil,
buscando delimitar o definir los requisitos, la fuente más importante será siempre el usuario final, quien,
a través de entrevistas, podrá proporcionar información minuciosa sobre cada proceso, que sirva para
especificar los casos de uso y las tareas respectivamente.

Finalmente, es conveniente recordar que, en un caso real, no se ha dado toda la información en un primer
instante, realmente se obtiene luego de diversas iteraciones y mediante la completación de la
documentación de procesos, del glosario de términos y en forma de respuesta proporcionada por el
usuario según participa en el proceso de construcción del software. La documentación es entonces un
factor importante, pues aporta información asociada a las tareas, incluyendo aspectos no descritos en los
casos de uso y viceversa, evitando la contradicción entre ambos momentos.

Pág. 26