Fase 3.

Elicitación de requerimientos

Cristhian Fernando Ledesma Ropero

Grupo 87
Análisis y Especificación de Requerimientos 202016894A_1394

Presentado a:
Anivar Chaves Torres

Universidad Nacional Abierta y a Distancia – UNAD

Escuela de Ciencias Básicas, Tecnología e Ingeniería
Ingeniería de Sistemas
Octubre 2023
Paso 2:
Requerimientos de interfaz de usuario: Este tipo de requisitos especifica las
características que deberá tener el sistema en su comunicación con el usuario.
Se debe ser cuidadoso con este tipo de requisitos, ya que en esta fase de desarrollo todavía
no se conocen bien las dificultades que pueden surgir a la hora de diseñar e implementar las
interfaces, por esto no es conveniente entrar en detalles demasiado específicos.

Definición de requerimientos funcionales: Los requisitos funcionales hacen referencia a

la funcionalidad que debe proporcionar el sistema y los datos que tiene que conocer y
guardar. Nos indican
qué cálculos hace el sistema, qué datos mantiene, cómo los manipula, etc.
Podemos distinguir, dentro de los requisitos funcionales, entre los requisitos
de funcionalidad y los de datos.
LOS REQUISITOS DE FUNCIONALIDAD, en general, describen cuál tiene que
ser el comportamiento del sistema explicando qué respuesta debe dar ante los estímulos que
le llegan desde el exterior. Por respuesta nos referimos a qué respuesta observable desde
fuera, considerando el sistema como una caja negra.

Algunos ejemplos de requisitos funcionales de funcionalidad del caso práctico son:

• Como usuario quiero poder consultar las recomendaciones de los agentes sobre un
hotel.
• Como directora de marketing, quiero que los clientes puedan recomendar en las
redes sociales los viajes que ofrecemos.

LOS REQUISITOS DE DATOS describen qué datos tiene que conocer el sistema.
Estos son, típicamente, datos que el sistema guardará de modo persistente.
Analizando el plan de viaje proporcionado por Joan Salvat podemos descubrir
muchos requisitos de datos del caso práctico. Un par de ejemplos pueden ser:

• El sistema tiene que conocer el cliente de un viaje; en particular, debe saber el

nombre, los apellidos, la dirección de correo electrónico, la dirección postal y el
teléfono.
• El sistema tiene que conocer el hotel u hoteles de un viaje. De los hoteles tiene que
saber el nombre, la dirección y el teléfono. En relación con el viaje tiene que saber
las fechas de entrada y salida, las horas de check-in y check-out, el tipo de
habitación, las observaciones del hotel y la opinión del agente que ha reservado el
viaje.
Requisitos no funcionales
Los requisitos no funcionales son aquellos requisitos de producto que, como su nombre
indica, no son funcionales sino calidades esperadas del sistema, como por ejemplo
usabilidad, fiabilidad, rendimiento o mantenibilidad. Son, por lo tanto, restricciones sobre
el conjunto de soluciones tales que, si una solución no satisface aquella calidad, no se
considera válida.
Los requisitos no funcionales suelen afectar a gran parte del sistema.

Por ejemplo, si decimos que el sistema de Viajes UOC tiene que ser portátil a otras
plataformas, esto no afecta solamente a la recomendación de hoteles o a la
publicación de la opinión en Facebook, sino que afecta a todo el sistema.

Los requisitos no funcionales se denominan, también, requisitos de calidad.

Distintos autores han propuesto diferentes requisitos no funcionales, un resumen y mas

comunes entre ellos son:
Consulte los tipos de requerimientos más comúnmente utilizados, sus características y
su utilidad en el proceso de desarrollo de software.

Además de los mencionados anteriormente los requerimientos mas utilizados son:

Requerimientos de rendimiento
Los requerimientos de rendimiento suelen dividirse en dos categorías: tiempo de respuesta
y rendimiento. El tiempo de respuesta es el tiempo que tarda un sistema en responder a la
solicitud de un usuario, mientras que el rendimiento es el número de solicitudes que un
sistema puede manejar. Son más críticos para los sistemas interactivos, como las
aplicaciones de escritorio y los sitios web, donde los usuarios esperan respuestas inmediatas
a sus acciones.

Requerimientos de seguridad

Los requerimientos de seguridad especifican las medidas que un sistema debe tomar para
proteger los datos del acceso no autorizado. En algunos casos, los requerimientos de
seguridad también pueden especificar el nivel de protección requerido, como confidencial o
de alto secreto. Implica autenticación, autorización y cifrado.

Requerimientos de calidad

Especifica el nivel de calidad que debe cumplir un sistema. En algunos casos, los
requerimientos de calidad también pueden especificar los métodos utilizados para medir la
calidad, como la densidad de defectos o la satisfacción del cliente. Los requerimientos de
calidad son generalmente cuatro medidas de calidad: conformidad, usabilidad,
confiabilidad y mantenibilidad.

Paso 3:
En este paso se lleve a cabo la obtención de información desarrollando el
plan propuesto por su grupo colaborativo en la fase 2. Se trata de
establecer los objetivos que el software debe alcanzar, las necesidades
de los usuarios que debe satisfacer y las condiciones o restricciones en
las que debe funcionar.
En el foro de trabajo colaborativo comunique a su grupo cuáles de las
actividades de obtención de requerimientos planeadas en la fase 2
llevará a cabo en su actividad individual. Esto con el fin de que sus
compañeros selecciones otras actividades y no se repitan.
Si en su entorno no encuentra personas que jueguen ajedrez o que
conozcan sobre los campeonatos de este deporte, puede recurrir a
fuentes en Internet. Hay muchos foros y grupos de ajedrecistas, blogs y
páginas sobre el tema.
El prototipo lo pueden utilizar como herramienta para el levantamiento
de requerimientos, tanto en las entrevistas como en las JAD.
Tomen evidencia de aplicación de las técnicas de obtención de
requerimientos para anexar tanto en el trabajo individual como
colaborativo.

Objetivos del software:

• Organizar y administrar la información de los torneos de ajedrez programados.
• Análisis e interpretación de datos recolectados.
• Actualización y visualización de datos en tiempo real.

Necesidades del usuario:

Tener un software donde ingresar la información de los torneos
La información a recolectar es: la lista de inscripción de los jugadores, flujo de jugadores que
asisten, campeonatos, sus participantes, partidas jugadas, resultados, fechas, ubicación del
evento, tácticas, normas, puntuación, fichas, puntuaciones obtenidas, récords de cada partida,
las formaciones de partidas dobles, movimientos del juego, tiempo de partida, visualización
del tablero electrónico con los datos de puntuaciones o resultados.

Condiciones y Restricciones:
Acceso de datos restringidos
Cumplimiento de leyes y normas.

Obtención de requerimientos
Prototipo
Desarrollar un software sencillo con el cual puedan interactuar los distintos actores
implicados y relacionados con uso del sistema.
Se podrían incluir funciones básicas como el registro de usuarios.
Dependiendo el tipo de usuario que seas como un (administrador, jugador, espectador, juez,
etc) que tipo de permiso o restricciones se les puede conceder a cada uno.
A que tipo de datos puede acceder cada perfil de usuario.
Creación de Perfiles para cada uno, en especial de los jugadores los cuales podrán expondrán
y se registrarán sus datos, como en representación de quien está, edad, categorías, partidas
ganadas, partidas perdidas, records, amonestaciones, etc.
Confidencialidad de datos personales.
Listados de campeonatos disponibles
Mientras se desarrolla una partida, datos que se puedan llevar en tiempo real, para interés de
cada perfil.

Paso 4:
Analice la información obtenida mediante la aplicación de las técnicas, en el paso anterior, e
identifique los objetivos y los requerimientos para el software.
En cada requerimiento obtenido asegúrese de registrar toda la información relacionada con
el mismo, como: quien lo solicita, por qué los solicita, casos excepcionales, condiciones y
restricciones para el requerimiento.

Objetivos para el software del prototipo:

• Recolectar información de los torneos de ajedrez programados.
• Análisis e interpretación de datos ingresados
• Mostar datos en tiempo real.
Requisitos:
Recolectar información de los torneos de ajedrez programados.
Registrar los distintos tipos de usuarios que van acceder al sistema.
Quien lo solicita: Organizadores
Por qué los solicitan: Obtener la información de cada persona involucrada en el torneo de
forma segura y especifica.
Casos excepcionales: Extraer datos confidenciales o privados por orden legal.
Condiciones y restricciones para el requerimiento: Mantener la información de forma privada
y segura

A qué tipo de datos puede acceder cada perfil de usuario.

Quien lo solicita: Organizadores
Por qué los solicitan: tener disponible los datos de cada persona implicada en el torneo, parte
administrativa, Visualizaciones de perfil en el caso de jugadores y espectadores.
Visualización de estadísticas, predicciones y jugadas en tiempo real para los espectadores.
Casos excepcionales: Cambios de decisión o actualización de reglas y normas.
Condiciones y restricciones para el requerimiento: Cumplir con los requisitos establecidos
previamente por los organizadores, los cuales informa quienes pueden registrarse o no a los
torneos.

• Análisis e interpretación de datos ingresados

Quien lo solicita: Espectadores
Por qué los solicitan: Disponer de información en tiempo real acerca del juego, además
de hacerla fácil de comprender.
Casos excepcionales: Jugadas interpretadas de forma unánime por arbitro.
Condiciones y restricciones para el requerimiento: Mantener datos actualizados en
tiempo real.
 Bibliografía

Duran Toro, A., & Bernadez Jimenez, B. (2000). MetodologíaparalaElicitación

deRequisitosdeSistemasSoftware Versión2.1 [Proyecto"MENHIR"delaCICYTTIC97–
0593–C05–01"]. Universidad de Sevilla. http://www.lsi.us.es/docs/informes/lsi-2000-10.pdf

Northware. (2022). Requerimientos en el desarrollo de software y aplicaciones. Northware.

https://www.northware.mx/blog/requerimientos-en-el-desarrollo-de-software-y-

aplicaciones/

Alonso, F.; Martínez, L.; Segovia, J. (2005). 8.2 Análisis de los requisitos del software. En

Introducción a la Ingeniería del Software: modelos de desarrollo de programas (pp. 97 –

99). Madrid: Delta Publicaciones. https://elibro-

net.bibliotecavirtual.unad.edu.co/es/ereader/unad/170188?page=97

Taibi D., Lenarduzzi V., Janes A., Liukkunen K., Ahmad M.O. (2017) Comparing

Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana

Development Processes. In: Baumeister H., Lichter H., Riebisch M. (eds) Agile Processes

in Software Engineering and Extreme Programming. XP 2017. Lecture Notes in Business

Information Processing, vol 283. Springer, Cham. https://doi.org/10.1007/978-3-319-

57633-6_5

Chaves, A. (2022). Elicitación de requerimientos. Repositorio institucional UNAD.

https://repository.unad.edu.co/handle/10596/53902