20 DE FEBRERO DE 2022

Fase de Elicitación de Requisitos

Presentado por: Andrés Hernando Rodriguez Espinel

Presentado a: Instructora Natalia Carolina Pardo

SERVICIO NACIONAL DE APRENDIZAJE SENA.

CENTRO DE GESTION ADMINISTRATIVA CGA.
Modalidad: Virtual.
 1

Introducción

Elicitación de requisitos. Es el punto de partida de todo trabajo, se debe investigar y

analizar requisitos y datos para poder comenzar a programar.

Por medio de este trabajo de investigación quiero primeramente aprender y además dar a

conocer a ustedes lectores la identificación de las fuentes de requisitos y tareas,

Identificar interesados (Stakeholders). Entre muchos otros temas a tratar en este trabajo

escrito.
 2

Tabla de contenido
Introducción ...................................................................................................................................1
Fase de Elicitación de Requisitos .................................................................................................3
 3

La Fase de Elicitación de Requisitos

Su objetivo principal es obtener los conocimientos más importantes del problema, estos luego

serán utilizados para especificar de forma formal el software necesario para su resolución.

Arquitecto, Programador, Desarrollador y cliente deben tener una comunicación eficaz, eficiente

y efectiva para saber las necesidades y requerimientos del cliente. También al terminar de

analizar los requerimientos, se podrá tener un gran dominio del tema.

Objetivos: Dominar y conocer el problema para al comunicarse con los Steakholders entender

sus requerimientos, necesidades y exigencias.

Tener conocimiento del sistema actual sea físico o virtual y sus Pros y Contras.

Identificación de necesidades, Implícitas y Explícitas de los Stakeholders y sus expectativas

sobre lo que se desarrollará.

Planeación:

Define tareas a realizar para escoger y planificar las técnicas a emplear durante la actividad

durante la elicitación.

Tareas Procesos

A Identificar las fuentes Lista de fuentes de requerimientos

B Identificar interesados del producto Categorías de los interesados (stakeholder)

C Matriz Stakeholders Perfil de stakeholder

 4

D Revisar Técnicas Identificar combinaciones de técnicas tales

como entrevistas, grupos focales, encuestas, prototipos

E Capturar interesados Plan de captura de interesados

Procesos de tareas:

A. Identificar las fuentes de requerimientos.

Existen muchos requisitos en cada proyecto, gracias a estos todos se abastecen de información

detallada sobre el problema y necesidades del usuario. También representan fuentes de

requisitos, pero también existen otros documentos como libros, manuales, formularios, informes,

revistas e incluso reportes o especificaciones de requisitos anteriores, que pueden otorgar

información muy útil acerca de la organización y su entorno.

Se identifican:

• Interesados relevantes

• Fuentes de información ajenas a la organización

• Documentos que pueden ser usados como base de requerimientos

Clasificación de las fuentes:

Primarias: Es información de primera mano, tiene la información original publicada por

primera vez que no ha sido adulterada ni analizada.

Secundarias: Sintetizan, resumen y reorganizan la información de las anteriores fuentes, son

utilizadas mas que todo para facilitar el acceso a las ya mencionadas anteriormente.
 5

Terciarias: Guías físicas o virtuales con contenido de las fuentes secundarias, hacen parte de la

colección de referencia de las bibliotecas.

Soportes de fuentes de Información:

B. Identificar interesados del producto.

Se debe analizar e identificar a cada individuo que tiene cierto interés en el proyecto. Los

Stakeholders son los individuos u organizaciones interesados y relacionados activamente en el

proyecto de software, directa o indirectamente están involucrados en los requisitos, o sus

intereses se ven afectados de buena o mala forma por el proyecto. O sea, están interesados en el

producto final del software que se desarrollará y además necesitan y deben ser informados y

estar al tanto del progreso, retraso, conflictos, cambios y prioridades del proceso y el producto a

desarrollar.

División: Estos se dividen en dos grandes grupos:

 6

Stakeholders primarios: Son 100% importantes y no pueden faltar porque si faltan la

organización no puede funcionar bien, son unos de los engranajes principales de la máquina, y

tienen relación económica directa con la empresa. Ejemplos de estos son los clientes, socios e

inversionistas.

Stakeholders secundarios: No participan directamente en la compañía, pero también son

afectados bien sea positiva o negativamente por los resultados, se encuentra aquí la competencia,

el mercado y la gente.

Roles más generales:

• Líder de proyecto/Administrador de proyecto/Gerente de proyecto

• Analista/Ingeniero de requisitos

• Ingeniero de sistemas/Arquitecto

• Programador/Desarrollador/Ingeniero de Software

• Control de calidad

• Administrador de DB.

Rol Descripción

Cliente Persona u organización que solicita la creación de una

aplicación, página Web, proyecto, etc. Y es quien realiza el

pago, negocia con tiempo, costo y alcance del proyecto.

Pueden ser usuarios o no

 7

Usuario Interactúa con el sistema, proporciona información

fundamental para que el proyecto sea exitoso porque

conocen y conviven

Líder de proyecto Hace parte del equipo de desarrollo, lo representa ante el

cliente. Es el responsable de completar el proyecto con éxito

con los recursos dados

Analista Se encarga de la ingeniería de requisitos, los identifica,

analiza, modela y documenta. Establece contacto directo con

el cliente y utiliza distintas y eficientes técnicas de

comunicación y de recopilación de información para lograr

su objetivo.

Programador Basándose en los requisitos recibidos de los ingenieros de

requisitos, realiza la codificación para realizar el pedido.

Asegurador de la calidad Garantiza el cumplimiento del proceso y de los estándares

del producto. Verifica y valida los requisitos para imprimir

el sello de la calidad desde los inicios del desarrollo. A la

vez realiza planes de prueba con esos requisitos del sistema.

Arquitecto Es el responsable del diseño de alto nivel y es crucial a la

hora de precisar los atributos de calidad del producto final.

C. Matriz de Stakeholders:
 8

Al usarlo se permite clasificar a los involucrados en el proyecto según sus niveles de interés y

poder sobre él, por lo que es más fácil priorizar los Stakeholders mas importantes para

desarrollar las estrategias de gestión correspondientes.

Importancia matriz Stakeholders en los proyectos de desarrollo:

La buena gestión de Stakeholders es super importante si se quiere tener éxito porque cuando se

identifican los involucrados y se definen los niveles de interés e influencia en el proyecto marcan

el punto de partida para realizar estrategias para alcanzar los objetivos del proyecto emprendido.

Por tanto, la matriz de Stakeholders es una herramienta que no puede faltar y debe ser elaborada

desde el principio del proyecto, porque ayudara a gestionar las expectativas de los involucrados

en el proyecto, aumentando lo positivo y tratando en lo posible de disminuir o erradicar los

puntos negativos.

Proceso de armado de Stakeholders:

Componentes de la Matriz Stakeholders:

Stakeholder: Es como se conoce al usuario.

 9

Tipo: Rol interno o externo al proyecto. Interno, personal de las unidades ejecutoras, personal

administrativo o ejecutivo, entidades financieras de alto nivel de poder e influencia en el

proyecto y sus recursos; Externo, beneficiarios del proyecto, las instituciones del sector o las

organizaciones de la sociedad, los cuales de una forma u otra son impactados por el resultado

positivo o negativo del proyecto.

Objetivo o resultados: Se enlistan los objetivos o resultados en los cuales el stakeholder se

muestra interesado o en los cuales se puede influir positiva o negativamente con sus acciones.

Puede ser suministrada por el acto de constitución de proyectos, la estructura organizacional, la

estructura del desglose de trabajo, los diferentes planes que conforman el proyecto, entrevistas a

los interesados, etc.

Acciones posibles con impacto positivo/negativo: Cosas que el stakeholder puede hacer y

puede repercutir de forma positiva o negativa, los objetivos del proyecto que le interesan, o en

los que puede influir según su jerarquía, estatus, recursos, entre otros.

Estrategias: Listado de acciones a emprender para obtener el apoyo necesario o evitar

obstáculos por los Stakeholders en medio de la ejecución y conclusión del proyecto. Estas se

desarrollan según el tipo de stakeholder, los objetivos en los cuales se interesa, el nivel de

interés, y el poder a ejercer en el proyecto, y además si puede afectar positiva o negativamente el

proyecto.

Conclusiones: Resumen de los momentos clave para gestionar de forma efectiva las expectativas

de los Stakeholders. Luego de relacionar, analizar y sintetizar toda la información de la matriz de

Stakeholders se pueden sacar las conclusiones.

 10

Categorización de Stakeholders y estrategias de gestión de las expectativas:

En la Matriz de Stakeholders se clasifica a los involucrados en el proyecto, priorizando a los más

importantes y desarrollando así las estrategias correspondientes para gestionar sus expectativas.

También su clasificación tiende a cambiar durante la vida del proyecto. Por tanto, aunque el

principio algunos fuesen clasificados con un nivel de influencia bajo, pueden ser reclasificados

con un nivel más alto en otra u otras etapas de vida del proyecto. Se organizan en una matriz de

2x2.

Técnicas e instrumentos para elicitar requisitos

Entrevista: “Forma de recoger información de otra persona por medio de una

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

estructurada” -(Braude, 2003)

Existen 3 fases:

Preparación: Se debe documentar e investigar la situación organizacional, analizando los

documentos de la empresa disponible.

 11

• Debe minimizarse el número de entrevistados.

• Analizar perfil de los entrevistados.

• Definir los objetivos, (General y específicos) y el contenido de la entrevista

• Definir hora y lugar de la entrevista

• Enviarle un cuestionario.

Realización: Tiene 3 etapas.

Apertura: Presentarse e informar el porqué de la entrevista

Desarrollo: Cumplir las reglas protocolarias, se debe llegar a un acuerdo sobre como se ha de

registrar la información obtenida

Pueden emplearse distintas técnicas:

• Preguntas abiertas: Permiten la comunicación y evitan el complejo de interrogatorio.

• Utilizar palabras adecuadas: Sin tecnicismos, palabras en otro idioma o cosas por el estilo

que dejen desubicado al interlocutor.

• Mostrar interés en todo momento: Cuidar la comunicación no verbal, posición del cuerpo,

movimientos, expresiones faciales, y sobre todo no quitar la vista del interlocutor, se debe

evitar mirar a otra parte mientras se habla.

Terminación: Se agradece el esfuerzo y deja abierta la posibilidad de volver a contactar para

aclarar conceptos o bien citándole a otra entrevista.

Análisis: Leer las notas, pasarlas en limpio, reorganizar la información, contrastarla con otras

entrevistas o fuentes de información, analizar como estuvo la entrevista. El equipo de IR realiza

 12

preguntas sobre el sistema que utilizan y sobre el sistema a desarrollar. Los requerimientos

surgen de la respuesta a estas preguntas.

Clasificación: Se clasifican en tres grandes grupos:

• Entrevista estructurada: Recoge de la mejor forma la mayor información sobre los

aspectos que quiere explorar

Preguntas definidas, las respuestas son esperadas e incluso se le da al entrevistado en

forma de varias opciones.

Las etapas son planificadas

La interpretación se realiza con ciertos criterios establecidos.

• Entrevista semiestructurada: Parten de preguntas planeadas que se pueden ajustar a los

entrevistados.

Se planifican previamente las preguntas, pero con cierto grado de libertad de acción para

abordar temas que pueden surgir durante la misma

Suele usarse un protocolo para facilitar al entrevistador seguir un modelo preestablecido.

• Entrevista no estructurada:
Es una simple charla, pero con un propósito definido en mente.
Encuesta:
Pueden variar en propósito, diseño y apariencia, pero consiste en una lista de preguntas escritas.
Simplifican el proceso de recolección de datos, preguntando directamente a los individuos
participantes para obtener datos de forma rápida y directa y se pueden aplicar a un gran numero
de sujetos.
 13

Observación: Permite obtener datos para una investigación cualitativa, desde el punto de vista

de lo que se ve y percibe el investigador en un escenario de primera mano. Debe cumplir cuatro

condiciones:

• Debe servir a un objeto formulado de investigación

• Debe ser planificada sistemáticamente

• Controlada y relacionada con proposiciones generales

• Debe estar sujeta a comprobaciones y controles de validez y fiabilidad.

En resumen: Sigue normas, reglas y procedimientos. Permite a los sujetos y objetos estar en

contacto y tener relaciones de manera directa.

Tipos de Observación:

Pasiva: El observador no hace pregunta alguna, solo se mantiene al margen y toma nota

Activa: El observador puede conversar con el usuario

 14

Elaboración guía de observación:

1. Datos y características de los sujetos a evaluar
2. Propósitos de la observación o de las observaciones a realizar
3. Temporalidad de la observación
Técnicas usadas en las Sesiones grupales:
Lluvia de ideas: Creatividad empresarial=Interacción y trabajo en equipo todos juntos pueden
dar opiniones y sugerencias sobre un cierto tema.
Sesiones JAD: Talleres donde trabajadores del conocimiento y especialistas en TI se reúnen a
veces por días a definir y revisar requerimientos de negocio para el sistema. Incluyen oficiales de
alto nivel quienes se aseguran de que el producto otorgue los reportes y la información solicitada
al final esto es conocido como proceso de administración.
Método Delphi:
Es un método de estructuración de un proceso de comunicación grupal el cual consiste en la
selección de un grupo de expertos a los que se les pregunta su opinión frente a distintas
temáticas.
Fase uno. Formulación del problema: Se define el campo de investigación.
Fase dos. Elección de expertos: El experto se elige según su preparación y su capacidad de
proyección
Fase tres. Elaboración de cuestionarios: Las preguntas deben hacerse de acuerdo con la
temática que se quiere obtener
Fase cuatro. Desarrollo y explotación de resultados: El cuestionario se entrega a los expertos
para ser contestado por ellos.

Herramientas para captura de requisitos

Existen diversas herramientas para capturar requisitos de un sistema nuevo o una actualización
de software.
Diagramas de uso:
Antes de desarrollar un proyecto se debe hacer un exhaustivo análisis de las funcionalidades
principales del software, y quienes podrán ejecutar esas funcionalidades. Para poder ver e
identificar eficazmente los elementos se debe elaborar diagramas de casos de uso, desde el
principio de un proyecto se deben elaborar para poder usarlos de referencia en etapas posteriores.
Componentes:
 15

Actor
Se representa por medio de un “Hombre de palo”. Se emplea para indicar el tipo de usuario que
hará algo en el sistema.
Caso de uso
Se representa mediante un óvalo e indica una de las funciones que el sistema deba proveer. Se
debe usar un verbo conjugado en infinitivo y representar la función a realizar (Administrar,
gestionar, registrar, programar).
Ejemplo centro médico:
• Administrar datos pacientes.
• Administrar datos tratamientos.
• Gestionar citas.
• Generar reportes.

Identificar casos de uso

Anteriormente observamos los casos de uso identificados en el sistema, lo que quiere decir,
funciones del sistema. Se encuentran en los casos de uso (óvalos).
Identificación de actores:
Se logran identificar el médico y el paciente.
Documentación:
Además de realizar el diagrama de casos de uso tambien se debe describir la funcionalidad de
cada uno de estos. Permite identificar el flujo de eventos entre el sistema y el actor para poder
llevar a cabo los casos de uso.
Historias de usuario:
 16

Se usan en métodos agiles para especificar requisitos, es una breve descripción de la

funcionalidad del software tal y como lo percibe el usuario. (Cohn, 2004)
Se basa en la regla de las 3 palabras: Como <rol>, Quiero <eventos> y Para <funcionalidades>.
Por tanto, el <rol> que sea seleccionado requiere de una <acción>/<evento> que ocurra, porque
se desea cubrir una <funcionalidad>. Corto, preciso y conciso.

Conversación para explicar de mejor forma la historia de usuario

Como fue mencionado un numeral antes, las historias de usuario son frases cortas, precisas y
concisas, pero eso no es impedimento alguno para que exista un diálogo (conversación) entre
todos los miembros del equipo. Es más, debe llevarse a cabo esta plática, para poder explicar de
mejor manera la historia de usuario y conseguir objetivos tales como:
• Detallar a mayor nivel como será realizada la solución.
• Clarificar aspectos de valor, funcionamiento y técnicos.
• Resolver las dudas que aparezcan.
Al llevar a cabo las conversaciones se pueden llegar a acuerdos acerca de los diversos puntos
tratados, los cuales quedarán reflejados en los criterios de aceptación y también permitirán
checar cuando la historia de usuario este reflejada.
Confirmación de los criterios de aceptación:
Son criterios claros y específicos que todo el equipo de trabajo debe ser capaz de entender y que
permitirán dar cierto valor en el futuro si la implementación o las pruebas a realizar están
culminadas.
Ejemplo historia de usuario usando plantilla:

Storyboard
 17

¿Qué es?:

Son prototipos ampliamente utilizados, consiste básicamente en ir mostrando por medio de una

secuencia de imágenes un proceso, acción, o ejercicio que se podrá realizar en el sistema una vez

finalizado, las imágenes mostraran la evolución del sistema conforme el usuario interactúa con el

sistema.

Se pretenden crear vistas distintas del sistema en las primeras etapas de la implementación de la

forma más veloz y económica posible. Para ejemplificar los storyboards casi siempre se usan las

revistas de cómics, ya que muestran una secuencia de imágenes en cuadros con un orden

establecido, Izquierda a derecha, los cuales permiten entender la línea de la historia contada, pero

también se puede hacer estilo panel de manga, de derecha a izquierda. Permite generar modelos

o esquemas visuales como esbozos de interfaces graficas de usuario (GUI)

Características:

• Se conserva el punto de vista del proceso del negocio.

• Puede ser validado un escenario.

• Validan escenarios integradores logrando una visión global.

• Tienen grado mínimo de no comprensión.

• No genera falsas expectativas.

• El usuario trabaja con herramientas conocidas para él.

• Tienen gran facilidad de ser mantenidos y adaptarse a los cambios.

• Permiten agregar modificaciones durante la validación.

Ejemplo Storyboard actual:

18
19
 20

Ejemplo Storyboard futuro:

 21

Herramientas de modelado:

Las herramientas de modelado de sistemas informáticos se emplean para crear modelos de

sistemas existentes o desarrollo a futuro; estas herramientas permiten simular un sistema a bajo

costo y riesgo mínimo. Bajo costo porque es solamente un conglomerado de gráficos y texto en

los cuales se representa el sistema.

El Lenguaje Unificado de Modelado (UML, en inglés) es el lenguaje de modelado de sistemas de

software más conocido y usado en nuestro siglo; es un lenguaje grafico el cual permite

especificar, modelar, construir y documentar los elementos que conforman un sistema de

software.

Por otra parte, las herramientas CASE son un conjunto de programas y procesos guiados que

ayudan a los analistas, desarrolladores, ingenieros de software y diseñadores web en una o varias

etapas del ciclo de vida de un software, para facilitar el desarrollo de software.

 22

Referencias
Documentos de Territorium