Elicitación de Requerimientos

Ingeniería de Requerimientos de Software

Instituto IACC

04-05-2020

ÍNDICE

Introducción....................................................................................................................................3
1. Identifica las actividades de elicitacion de requerimientos.................................................3
2. Actividades de Elicitacion....................................................................................................5
3. Técnicas de Elicitacion........................................................................................................6
5. Glosario..............................................................................................................................12
Referencias....................................................................................................................................13

Introducción
 Teniendo presente el contenido de la semana 3 y en base al desarrollo de software que usted

viene realizando en la asignatura Taller de Integración de Software, se solicita que identifique las

actividades de elicitación de requerimientos aplicadas y que desarrolle, mediante ejemplos

aplicativos, las técnicas de elicitación de documentos presentadas (dichas técnicas deben estar

enfocadas directamente en el desarrollo de software). Además, deberá elaborar un glosario de

requerimientos del sistema diseñado.

1. Identifica las actividades de elicitacion de requerimientos

La elicitación de requerimientos es un proceso de manifestación de los requerimientos para

una aplicación o software que a través de la comunicación con los clientes o usuarios del sistema

que tengan algún tipo de conocimiento sobre el proyecto a desarrollar

Uno de los principales efectos del proceso de elicitación es la sucesión de requerimientos

que el equipo de desarrollo de software deberá utilizar, para la creación un producto eficiente y

eficaz. Además de este resultado esperado el proceso debe ofrecer una sucesión de salidas

intangibles.

Un buen proceso de elicitación facilita a los usuarios para entender de mejor forma que es

lo que necesitan, si existe alguna restricción y alternativas, sus ventajas y desventajas.

Para que exista un buen proceso de elicitación, es importante la visión o punto de vista del

Ingeniero de Requerimientos, este ayudara a los usuarios a simplificar el problema o petición, es

decir, lo que realmente desea y necesita el usuario, resolver un problema que sea factible,

entender y obtener la confianza del usuario en conjunto con su cooperación y a ganar

conocimiento sobre el dominio del problema o solicitud.

Para una buena elicitacion se tienen que considerar los siguientes puntos:
 Perspectiva de Negocio:

Los stakeholders relacionados con el negocio y con marketing deben identificar las metas y

los objetivos en alto nivel de la organización u empresa, también como responder a preguntas:

¿de cómo? ¿por qué se está tratando de buscar una solución a la problemática?, el enfoque de

clientes al que va destinado el producto, qué necesidades del negocio se tendrán que compensar,

y cuáles serán las métricas para identificar si el proyecto ha sido exitoso.

Perspectiva del Usuario:

Los requerimientos más característicos son los del usuario. El es el encargado debe

responder las preguntas sobre qué problemas requieren ser solucionados de acuerdo con su

manejo dentro del negocio y cómo se interacciona con el producto.

Perspectiva Técnica:

Los desarrolladores entregan la perspectiva técnica necesaria para responder preguntas

sobre cómo alcanzar los objetivos del proyecto, mejorar que puedan aportar a desarrollo óptimo.

2. Actividades de Elicitacion
 Modelo de datos conceptual

Tiene como objetivo seleccionar la técnica para modelar específica que se utilizará dentro

del proyecto.

Fase Tareas Generales Tareas Específicas Asociadas

Modelo Seleccionar la técnica de modelo Técnicas de modelado
Supuestos del modelado
Generar la prueba de diseño Prueba de diseño
Construir el modelo Configuración de parámetros
Modelos
Evaluar el modelo Evaluación del modelo
Revisión de la configuración de parámetros

Evaluación

El objetivo es el estudio del modelo creado. Se debe analizar si este, cumple o no con los

objetivos del proyecto que fueron identificados. El resultado del análisis realizado determina la

necesidad de aplicar nuevamente alguna de las fases anteriores en caso de haber cometido algún

error.

Fase Tareas Generales Tareas Específicas Asociadas

Evaluació Evaluar Resultados Evaluación de los resultados de la explotación de
n información con respecto a los criterios de éxito
de negocio
Modelos Aprobados
Revisar el Proceso Revisión del Proceso
Determinar los próximos pasos Lista de posibles acciones
Decisión

Implementación:
 El objetivo es la realización del plan para el desarrollo con la documentación y

presentación de los resultados al usuario.

Fase Tareas Generales Tareas Específicas Asociadas

Implementació Realizar el plan de implementación Ejecución del plan de implementación
n Realizar el plan de vigilancia y Ejecución del plan de monitoreo y
mantenimiento mantenimiento

Realizar el informe final Informe final

Presentación Final
Revisar el proyecto Documentación de la experiencia

El plan de implementación debe considerar los resultados de la evaluación y determinar la

estrategia de desarrollo, incluyendo los pasos y su forma de realización.

3. Técnicas de Elicitacion

La metodología o encontrar un método perfecto que logre identificar y elicitar los

requerimientos. Las técnicas más apropiadas para ello son distintas en función del proyecto. No

obstante, las metodologías más utilizadas para ello son:

Entrevistas y Cuestionarios:

Se utilizan para recopilar información. Sin embargo, es necesario tener también considerar

la predisposición del entrevistado, el grado de experiencia que tenga, habilidad o manejo del

negocio, ya que estos elementos tienden a perjudicar la información obtenida durante el proceso

de entrevista.

Análisis Social:
 Es una aproximación simple a la elicitación de requerimientos que transporta la

importancia desde la formalización de los requerimientos escritos hacia la conversación. Las

historias de usuario deberán ser escritas por el usuario, dando énfasis en aquellas funcionalidades

que el sistema o aplicación deberá realizar. Generalmente, estas historias suelen ser un conjunto

reducido de frases u oraciones largas.

Workshops:

Nos entrega la oportunidad para compartir, clarificar y ajustar las perspectivas individuales

sobre los requerimientos del negocio.

Si bien existen diferentes elementos a elicitar durante la fase de requerimientos, metas del

sistema, stakeholders, objetivos, tareas, factibilidad, riesgos. Según a literatura sugiere que la

elicitación de requerimientos se realice de distintas maneras, pudiendo seguir una o más

metodologías disponibles; sin embargo, la habilidad de implementación de este proceso puede

presentar más variables debido a la dificultad de formalizar indicadores directos o indirectos

(métricas) para la evaluación y monitoreo del proceso.

Prototipo

El prototipo es la representación o visualización de las partes real del sistema. El prototipo

está diseñado en las primeras etapas de la ejecución del proyecto. Proporciona la idea general de

las funciones del sistema actual y el flujo de trabajo. Los prototipos se utilizan para recopilar los

requisitos de los usuarios mediante la presentación de las funciones en una interfaz gráfica de

usuario basado en el sistema.

 Un prototipo representa el producto real, tanto en sentido funcional como gráfico.

Proporciona la flexibilidad para los usuarios y las partes interesadas a trabajar con la versión

inicial del producto para entender el sistema y pensar en las necesidades adicionales que el

usuario haya olvidado mencionar. Los prototipos es uno de los métodos más caros.

Reúso de Requerimientos

En el ámbito de la ingeniería de software la reutilización de los requerimientos del sistema

actual es el método común de obtención de requerimientos. Con los actuales conocimientos para

desarrollar el nuevo producto, se tienen muchas ventajas que incluyen bajo costo y menos

tiempo. Aunque cada producto tiene su propio tipo de partes interesadas y usuarios, todavía hay

varias situaciones que la reutilización de los requerimientos lleva a cabo.

Escenarios

Los escenarios son ejemplos de las sesiones de interacción y estos consisten en

descripciones de las acciones secuenciales. Los escenarios son útiles porque a los usuarios

finales y otras partes interesadas del sistema les resulta más fácil relacionarse con ejemplos de la

vida real, en lugar de descripciones abstractas de las funciones. Los escenarios deben incluir al

menos los siguientes tipos de descripciones.

Lluvia de Ideas

Lluvia de ideas (en inglés Brainstorming) es un proceso donde los participantes de

diferentes grupos de interesados participan en un debate informal para generar rápidamente

tantas ideas como sea posible, sin centrarse en ninguno en particular. Tanto la crítica severa no
está permitida en este tipo de técnica, ya que debido a esto la ideas se pueden generar. Las ideas

son libremente explicadas y cada uno tiene que interpretarlo en un ambiente muy agradable con

un debate informal.

4. Selecciona y aplica una técnica de elicitación de requerimientos.

Este trabajo propone una metodología integral para obtener los requerimientos de software

a través del uso de modelos de referencia como dominio del conocimiento. Los sistemas de

planeación de recursos empresariales (Enterprise resource planning, ERP por sus siglas en

ingles) proveen de sistemas de software que ayudan a la automatización de procesos de una

organización. Aunque son muchas las ventajas que los ERP proporcionan a las empresas, en

ocasiones se presentan problemas al intentar implementar un sistema ERP en la empresa, debido

a que se deben adaptar los procesos de negocios que se realizan en la empresa y/o incluso se

puede dar el caso que se tenga que realizarles modificaciones a estos sistemas para poder

implementarlos.

La metodología consta de tres fases: elaboración de modelos de negocio, la detección de

oportunidades y las relaciones de oportunidades. La metodología holística se basa en el

modelado de negocios del modelo de referencia del método orientado al objetivo y apoyo

(BROM por sus siglas en inglés) que plantea adquirir los requerimientos de software para la

implementación del ERP.

 En la figura 1-1 se muestra el marco de la metodología, en donde la idea principal es que

las necesidades de organización y funcionalidades del software se adapten el uno con el otro

Este trabajo propone una herramienta basada en la Notación de Modelado de Procesos de

Negocios (por sus siglas en inglés BPMN), la que modela Procesos de Negocios Decisionales, el

cual considera la toma de decisiones como un proceso a ser modelado. La metodología está

enfocada para el desarrollo de un sistema que no es transaccional, si no a un sistema de apoyo

para la toma de decisiones; “un sistema transaccional es aquel que está diseñado para capturar

información y soportar procesos de negocios desde un punto de vista operacional”.

El Modelo de Procesos de Negocio (MPN) se define como un conjunto de actividades

conectadas, las cuales colectivamente representan un objetivo de negocio. Sin embargo, este tipo

de modelos no contempla los procesos decisionales, es decir, no representan las decisiones que

originan los procesos “operacionales” que modela. En cambio, un Modelo de Procesos de

Negocio Decisionales (MPND) proporciona una “Herramienta conceptual que contiene un

conjunto de elementos, conceptos y sus relaciones, las cuales permiten representar el proceso de
toma de decisiones dentro de la organización y cómo éstas afectan las actividades operacionales

de la misma” . El trabajo propone la heurística que se presenta en la tabla 1-1 para modelar

procesos de negocio decisionales.

5. Glosario

Atributo de Requerimiento
Cada uno de los atributos que se especifican para un requerimiento de software.

Diagrama de Actividad
Diagrama que hace parte del lenguaje UML. Permite modelar el flujo entre un conjunto de

objetos que cooperan entre sí. Son similares a los diagramas de flujo de otras metodologías

diferentes a la orientada a objetos.

Requerimientos de Software
Documento, o conjunto de documentos en el cual se consignan de manera preliminar a la

fase de especificación los requerimientos de software de un sistema.

Casos De Uso
Documento que contiene la especificación de casos de uso definidos para un sistema. Así

mismo, puede contener un diagrama de casos de uso.

Modelo Conceptual
Modelo que define vistas que representan la organización de los componentes, agentes o

elementos de software que participan para lograr la funcionalidad requerida por el sistema.

Stakeholder
Persona interesada o involucrada en el desarrollo de un sistema, bajo una perspectiva. Esta

puede ser económica o relacionada otro beneficio por el desarrollo del sistema.

UML (Unified Modeling Language)

Lenguaje de Modelamiento Unificado. Es un lenguaje para especificar, construir, visualizar

y documentar los artefactos o ítems de un sistema o software orientado a objetos

 Referencias

1. Documentación Semana N°3, IACC.

2. Los 6 principios de la calidad del software, Recuperado de:

https://profesorezequielruizgarcia.wordpress.com/ingenieria-de-software-ues-grupo-01/

3. Técnicas de elicitacion de requerimientos, Recuperado de:

https://www.researchgate.net/publication/290435007_Tecnicas_de_elicitacion_de_requerimi

entos