Elaboración de las historias de usuario

Evidencia: Elaboración de historias de usuario del proyecto.
GA2- 220501093-AA1-EV03.
APRENDIZ
Yuver Harbey Martínez Parra
Ficha 2977409
TECNOLÓGO ANÁLISIS Y DESARROLLO DE SOFTWARE
2 de septiembre de 2024
Introducción:
En el presente documento se plantean diferentes historias de usuario y casos de uso
respecto a los requisitos del proyecto de software que se busca desarrollar, para poder tener
un plan de desarrollo más claro y poder realizar un análisis más exhaustivo de los
requerimientos que el software debe cumplir. Dicho esto, se procede a detallar el proyecto y
sus requisitos.
Detalles del proyecto:
Para el proyecto de software se planea desarrollar un software de contratación para mejorar
el área de contratación de una empresa, para lo cuál se debe crear una herramienta virtual que
le sea de utilidad a empresas que quieran mejorar su contratación a través de dicha
herramienta. La herramienta debe ser clara, intuitiva y sencilla de usar, contar con un apartado
exclusivo para una comunidad de soporte y de ayuda mutua. Esta herramienta debe contar
principalmente con 2 apartados dentro de sí o, en su defecto, 2 formas de misma aplicación,
pero de diferente forma, para dividir los apartados a los que el software va dedicado. Dichos
sistemas se explican en perspectivas: perspectiva de un posible empleado (usuario común) y
perspectiva de un administrador de la empresa que coloca una postulación de empleo
(usuario administrativo).
Requisitos del software y casos de usuario:
Para detallar los requisitos que el software debe solucionar, se dividen los requisitos en 3
grupos: requisitos generales, funcionales y no funcionales, requisitos de los cuales se
retratarán los requisitos generales con un caso de uso y una historia de usuario para poder
cumplir con los criterios de calificación de la guía de aprendizaje. Los requisitos funcionales
y no funcionales contarán únicamente con historias de usuarios respectivamente organizadas
para cada situación.
Para los casos de uso, los requisitos serán declarados siguiendo una estructura basada
En el estándar de documentación IEEE830.
Así pues, a continuación, se presenta el listado de requerimientos (generales, no específicos)
que el software busca solucionar, adicional a los casos de uso de dichos requerimientos:
- El software debe tener un soporte constante 24 horas los 7 días a la semana (para
una captura exacta de fallos que vayan surgiendo para posteriores actualizaciones).
Identificador:
VRF01-2024
Título:
“Verificación del soporte del software”.
Descripción:
Se procede a verificar que el software mantenga
un soporte constante de 24 horas los 7 días a la
semana para que se puedan capturar fallos y
errores presentes en el sistema al momento de
su ejecución.
Actor primario:
El software (estando activo)
Condiciones previas:
El software debe haber arrancado correctamente
para proceder con su monitoreo. Además, debe
estar con todos sus servicios en línea y
funcionales.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de
desarrollo de un 7.
Escenario de éxito principal:
El software puede mantener un monitoreo
constante y dicho monitoreo permite atrapar
errores y fallas en la ejecución del programa.
Flujos alternativos del programa:
a) El software presenta problemas con su
monitoreo y no puede mantener una
revisión constante.
Frecuencia de uso:
Éste requisito se estará usando cada vez que el
software se inicie en un computador,
monitoreando todo el tiempo de actividad.
Criterios de aceptación:
El requisito será aceptado cuando se evidencie
que el programa puede mantener un registro
constante de todo el tiempo de actividad del
software para capturar y especificar errores.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
Éste requisito debe ser de los primeros en ser
implementados. El poder revisar cada error que
vaya saliendo de forma entrante hará que el
desarrollo del software conste de mejor revisión
y de mejor calidad de uso.
- El software debe ser capaz de enviar solicitudes (peticiones de empleo) desde los
posibles empleados a los administradores de la empresa de manera fluida.
Identificador:
VRF02-2024
Título:
“Envío de solicitudes de empleo por medio de
la plataforma.”
Se procede a verificar que el software sea capaz
de enviar, desde la perspectiva de un usuario
común, solicitudes de empleo a una postulación
Descripción:
de empleo que haya sido, desde la perspectiva de
un administrador, publicada previamente por la
empresa.
Actores primarios:
Usuario común.
Usuario administrativo.
Condiciones previas:
El usuario común debe haber iniciado el
programa, iniciado sesión y haber localizado
dentro de la plataforma una publicación de
esfuerzo vigente para poder hacer una petición de
empleo.
El usuario administrativo debe haber iniciado el
programa, iniciado sesión y tener acceso al
repositorio de solicitudes de empleo para
gestionar la solicitud que el usuario común envió
en la postulación.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 5.
Escenario de éxito principal:
El usuario común pudo enviar satisfactoriamente
su solicitud de empleo mediante la postulación
de empleo.
El
usuario
administrativo
pudo
gestionar
correctamente la solicitud de empleo enviada por
el usuario común.
Flujos alternativos del programa:
-
El usuario común tuvo problemas
para acceder a la postulación de
empleo.
-
El usuario común no pudo adjuntar su
solicitud en la postulación de empleo.
-
El usuario común no pudo presionar
el botón correcto para el envío de su
solicitud por problemas de la interfaz
gráfica.
-
El usuario administrativo no tuvo
acceso al repositorio de las solicitudes
de empleo de la empresa.
-
El usuario administrativo no pudo
gestionar correctamente la solicitud
del empleado por falta de claridad e
información en ésta.
-
El usuario administrativo no pudo
encontrar la solicitud del empleado
por problemas con el repositorio.
Frecuencia de uso:
Éste requisito se estará usando cada vez que un
usuario común quiera intentar postularse a un
empleo y cada que un administrador deba
gestionar una o varias solicitudes de empleo de
dicha postulación.
Criterios de aceptación:
El requisito será aceptado cuando se evidencie
que cualquier usuario común puede enviar su
solicitud de empleo sin problemas a una
postulación y cuando un usuario administrativo
pueda gestionar dicha solicitud y darle una
respuesta a dicho usuario común.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
El usuario común, aunque envíe su solicitud de
empleo, no tendrá seguridad de que será Sí o Sí
el seleccionado para el empleo: al ser una
postulación, la empresa está en derecho de
escoger al perfil más apto, capacitado o
recomendado para el empleo, por lo que siempre
que se envíe una solicitud de empleo se debe
estar mentalizado que se puede llegar a recibir un
“No”.
- El software debe ser capaz de Administrar dichas solicitudes. Además, debe contar
con un conjunto de herramientas (tales como filtros, referencias bibliográficas y
espacios de almacenamiento) para operar con estas solicitudes.
Identificador:
VRF03-2024
Título:
“Verificación de las herramientas de gestión
de solicitudes del software administrativo”
Descripción:
Se procede a verificar que el software, desde la
perspectiva de un administrador de la empresa,
cuente con un conjunto de herramientas
adecuadas para la gestión y administración de las
solicitudes de empleo que lleguen desde una
postulación de empleo.
Actor primario:
Usuario administrativo de parte de la empresa.
Condiciones previas:
El usuario administrativo debe haber iniciado
sesión en el sistema y debe tener previamente
permitido el acceso al repositorio donde se
almacenan y gestionan las solicitudes de empleo
de la empresa para poder gestionar dichas
solicitudes. Así pues, la empresa debe saber todo
movimiento que el administrador haga en el
repositorio de las solicitudes para evidenciar qué
sale y qué entra.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 7.
Escenario de éxito principal:
El administrador pudo gestionar las solicitudes
de empleo entrantes de manera satisfactoria,
filtrando la cantidad total de solicitudes gracias a
las herramientas de la plataforma y encontrando
la solicitud más apta para el empleo.
Flujos alternativos del programa:
-
El administrador no pudo encontrar
ninguna solicitud conveniente para el
empleo.
-
El administrador no pudo diligenciar
ninguna respuesta al perfil alternativo
por problemas de la plataforma o de
conectividad.
-
La respuesta que el administrador le
envió al perfil más apto no fue
recibida por éste, por problemas de
conectividad de la empresa.
Frecuencia de uso:
Éste requisito será empleado con una frecuencia
media, con cierta regularidad, ya que puede que
no todos los días una solicitud tenga nuevos
postulados, así como puede que en un día se
deban administrar varias solicitudes de empleo.
Criterios de aceptación:
El requisito será aceptado cuando se evidencie
que el usuario administrativo puede gestionar
satisfactoriamente solicitudes de empleo que
residan en el repositorio de la empresa que
guarde todas éstas solicitudes.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
El
usuario
administrativo
debe
saber
perfectamente lo que hace, ya que al tener acceso
al repositorio de solicitudes de empleo debe ser
consciente de todo cambio que realice dentro de
éste para que no se ocasionen problemas futuros
y fallos dentro del repositorio. Se debe tener una
seguridad
y
compromiso
total
con
éste
repositorio.
- El software debe ser capaz de crear y mantener activo un perfil por persona, ya sea
un posible empleado o administrador.
Identificador:
VRF04-2024
Título:
“Verificación del tiempo de vigencia de la
sesión de los usuarios activos”
Descripción:
Se procede a verificar cuánto tiempo puede
permanecer activa la sesión de un usuario en la
plataforma
antes
de
que
se
cierre
por
programación interna del software.
Actor primario:
Usuario de la plataforma ya sea común o
administrativo.
Condiciones previas:
El usuario debe tener muy en claro sus datos de
inicio de sesión, ya que la plataforma no tendrá
atajos de acceso fácil, por lo que no se deben
perder los datos de inicio de sesión.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 3
Escenario de éxito principal:
El requisito será desarrollado satisfactoriamente
cuando se evidencie que éste puede mantener una
sesión activa durante un periodo de 10 minutos:
al llegar los primeros 5 minutos de inactividad en
la aplicación, aparecerá un anuncio en la pantalla
que diga “Su sesión está por expirar. ¿Desea
extenderla?” seguido de un botón confirmando la
opción. De ser así, la sesión podrá durar otros 5
minutos extendida en un periodo de inactividad.
Cuando acaben estos 5 minutos, la sesión se
cerrará por inactividad.
Flujos alternativos del programa:
-
El software no podrá contabilizar el
tiempo en línea de un usuario por
fallas en la programación.
-
El botón para extender la sesión en los
primeros 5 minutos no funcionará por
fallas en la programación y la sesión
expirará igualmente.
-
La sesión no durará 10 minutos, sino
5 por problemas dentro del programa.
Frecuencia de uso:
Al contabilizar el tiempo dentro del software, la
frecuencia con la que se empleará este requisito
será bastante alta.
Criterios de aceptación:
El requisito será aceptado cuando se evidencie
que las sesiones de los usuarios pueden durar 5
minutos sin extensión manual o 10 con extensión
manual.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
El
tiempo
de
funcionamiento
de
requerimiento
se
busca
reinicie
que
se
este
automáticamente cada que el usuario haga algún
movimiento o interacción con el sistema: si el
cursor se mueve, si se oprime una tecla, si se
cambia de pestaña, cualquier interacción manual
con el sistema será un reinicio para el contador
interno del programa.
- El software, al ser desarrollado, debe contar con licencias de uso, las cuales la
empresa posteriormente al desarrollo y uso de este software decidirá si se va a volver
una licencia comercial apta para todo público.
Identificador:
VRF05-2024
Título:
“Revisión de licencias legales de uso del
software.”
Descripción:
Se procede a validar el aspecto de la
permisividad y licencias de uso que el software
en cuestión debe contener para su uso seguro y
correcto según los marcos de las leyes
cibernéticas.
Actor primario:
Equipo especializado en la revisión de licencias
de uso, términos y condiciones y seguridad en
internet.
Condiciones previas:
-
El software debe ya tener un prototipo
del acuerdo a qué permisos y términos
se le van a ofrecer a los usuarios para
usar el software.
-
El equipo que se encargará de revisar
las licencias de usuario debe actuar
bajo un conjunto de parámetros que
establece qué condiciones se pueden
añadirle al software y qué no, además
de información sobre el equipo
desarrollador (número de contacto,
correo electrónico, redes sociales,
página oficial, entre otros elementos).
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 8.
Escenario de éxito principal:
Cuando el equipo de revisión especializado haya
podido hacerle las revisiones adecuadas al
prototipo del acuerdo de licencia de usuario,
dicho equipo será el encargado de confirmar que
todos los aspectos del acuerdo de licencia estén
bien establecidos, tengan criterios justos, que
todo el contrato de licencia tenga una perspectiva
válida para todos los usuarios.
Flujos alternativos del programa:
-
Si el prototipo del acuerdo de licencia
presenta fallas en su desarrollo o no es
un prototipo útil para la ocasión, se
deberá
replantear
de
manera
satisfactoria la idea del contrato de
términos y hacer un nuevo prototipo
para su posterior ejecución.
-
Si el prototipo de software no termina
siendo aprobado por el equipo, dicho
prototipo
será
posteriormente
modificado y repensado para llegar a
unos mejores términos.
Frecuencia de uso:
Ya que éste requisito se verá aplicado cada vez
que un usuario nuevo entre y se registre en la
plataforma, por lo que su frecuencia y relevancia
será muy alta para cumplir con las demandas del
tratamiento de datos de los usuarios.
Criterios de aceptación:
El requisito será aceptado cuando se evidencie
que el software cuenta con un contrato de
licencia y términos de uso decentes, aceptables
por el usuario y que especifiquen qué se hará con
los datos proporcionados por el usuario y
también qué cosas acepta el usuario en dicho
contrato.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
Éste contrato de licencia debe ser completamente
específico respecto a cómo se comercializarán
los datos del usuario, además de tomar en
consideración si dentro del software se mostrarán
anuncios. De ser así, el sistema deberá poder
recopilar los datos de los usuarios, entender sus
gustos y búsquedas más frecuentes y poder
recomendarles anuncios a partir de lo que el
sistema detecte como intereses potenciales y
necesidades del usuario.
- El software debe ser ensamblado de tal forma que su tiempo de respuesta, bases de
datos y conexiones con servidores tengan un tiempo de respuesta lo más corto posible,
para evitar contratiempos y esperas innecesarias por ineficiencias de factores externos
al software.
Identificador:
VRF06-2024
Título:
“Identificación y verificación de la eficiencia
de los tiempos de respuesta de servicios ajenos
al software.”
Descripción:
Se procede a verificar que todos los servicios de
terceros relacionados con el software en cuestión
sean fiables, ágiles y dinámicos al momento de la
ejecución del sistema. Además, se procede a
darle un espacio de análisis y compilación a
dichos resultados de análisis para una posterior
retroalimentación.
Actor primario:
Condiciones previas:
El software en cuestión.
-
El sistema ya debe tener afianzadas
las conexiones con los servicios de
terceros, además debe haberse tenido
un desarrollo previo
de dichas
conexiones con el software.
-
Los servicios de terceros deben tener
conexiones seguras y verificadas, y al
ser conexiones para un servicio
empresarial deben tener aspectos de
seguridad
verificados
constantemente.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 7.
Escenario de éxito principal:
Cuando las conexiones con los servicios de
terceros sean verificadas y estén afianzadas, se
podrá analizar el tiempo que le toma al software
interactuar
con
cada
servicio
para,
posteriormente, poder reconocer qué elementos
intervienen con la velocidad de respuesta. Esto
para poder mejorarlos y hacerlos más eficientes
a través de una codificación más exhaustiva.
Flujos alternativos del programa:
-
Los servicios de terceros o algunos de
éstos no estarán disponibles al
momento
del
análisis
de
comunicaciones, por lo que se deberá
pausar la etapa del chequeo de tiempo
de respuesta hasta que los servicios se
puedan activar y monitorear.
-
Si los servicios de terceros están
activos, pero demuestran errores de
conectividad ajenos al software, el
equipo especializado se comunicará
con
los
propietarios
servicios
para
de
dichos
comentarles
el
problema y que los servicios puedan
volver a serle de utilidad al software.
Frecuencia de uso:
La frecuencia de uso de éste requisito constará de
importancia total. El software necesitará estar
con la mejor conectividad posible para poder
recibir y enviar datos entre servicios de terceros
con total eficacia, ya que todos los días (en
promedio) se estará utilizando el software.
Criterios de aceptación:
El requisito será aceptado cuando se demuestre
cómo actúan las conexiones con servicios de
terceros, qué tanto es su tiempo de respuesta y
qué aspectos son retroalimentables y mejorables
partiendo
desde
la
primera
hacia
las
consiguientes etapas de desarrollo del software.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
Éste requisito en específico necesita una atención
especial por parte del equipo de desarrolladores.
Al ser las conexiones entre servicios un elemento
clave para poder hacer del software una
herramienta fluida y completa para el usuario
final, se debe Bajo cualquier circunstancia,
asegurar que los servicios que el software utilice
estén siempre funcionales o, en el peor de los
casos, la mayor cantidad de tiempo posible.
- El software debe contar con su propia documentación desde los instantes previos a
su creación hasta las versiones que vayan saliendo con el pasar del tiempo. Esto ya
que se debe tener un registro exacto de toda modificación y cambio que se le realiza
a éste.
Identificador:
VRF07-2024
Título:
“Creación
e
implementación
de
la
documentación del producto final.”
Descripción:
Se procede a asegurar que, en los momentos del
desarrollo del software, éste tenga el registro de
todo lo que se vaya realizando conforme salgan
nuevas versiones de desarrollo del software,
elementos tales como arreglos, adiciones,
cambios internos y externos y funcionalidades
del software.
Actor primario:
El software en cuestión (en sus etapas de
desarrollo).
Condiciones previas:
-
El software ya debe tener una versión
previa a la oficial tal como una
“Alpha” o una “Beta” en la que se
revisará
lo
más
elemental
y
característico del software.
-
Se
debe
tener
destinado
un
documento o archivo para destinarlo
al encuentro de errores, arreglos de
éstos y demás cambios que vayan
surgiendo con el pasar del tiempo.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 4.
Escenario de éxito principal:
Cuando el software tenga sus primeras versiones
de desarrollo ya listas y funcionales, se podrá
hacer el registro de todos los errores, fallas,
inconvenientes
y
problemas
que
fueron
surgiendo, además de características de dichos
problemas (cómo y qué los producía, con cuánta
frecuencia aparecían, cuánto daño le hacía a la
ejecución del programa) y cómo se llegó a una
solución para cada error. En el caso principal de
éxito de éste requisito quedará evidenciado que
se pudo crear una documentación de errores y
fallos para futuras retroalimentaciones en el
desarrollo.
Flujos alternativos del programa:
-
Si, sea por la razón que sea, no se
llega a una documentación con el
suficiente nivel de complejidad, éste
requerimiento
no
podrá
ser
completado, por lo que se deberá
tener una nueva etapa para crear este
registro de errores.
-
Si dado el caso se llega a perder la
documentación exhaustiva, se deberá
rehacer dicho documento con la
adición de respaldarlo con copias de
seguridad
pérdidas.
para
evitar
futuras
Frecuencia de uso:
Al ser un registro que no afecta directamente el
flujo de ejecución del programa ni la forma en la
que éste actúa, su frecuencia de uso será baja,
casi inusual, ya que solo se empleará cuando un
desarrollador deba hacerles una revisión a los
errores presentes.
Criterios de aceptación:
El requisito será aceptado cuando se pueda
evidenciar que existe una documentación sobre
todo fallo existente ya solucionado dentro del
software, además de cambios y ajustes que le fue
conveniente añadir a éste.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
Al ser un recurso de documentación se debe tener
en cuenta que no se tratará como un requisito de
funcionalidades del programa, sino como brújula
que dirigirá al equipo de desarrolladores hacia un
software estable y capaz de responder a todo tipo
de problemas. La documentación debe abarcar la
mayor cantidad de errores posibles, ya que será
gracias a éstos errores que el software funcione
de manera estable y dinámica.
- El software debe contar con un manual de usuario, redactado de tal manera que
cualquier persona pueda entenderlo, aprenderlo y dominarlo.
Identificador:
VRF08-2024
Título:
“Verificación del manual de instrucciones de
uso del software”
Descripción:
Se procede a validar que exista un manual de
instrucciones acerca del software en el que se le
especifique al usuario (ya sea del tipo común o
administrativo) las funcionalidades y opciones
de personalización del software. Éste manual
también debe contener información sobre cómo
se desarrolló el software, qué herramientas se
emplearon, cuál es la finalidad del software (qué
innovación busca implementar al mercado) y qué
comentarios se le buscan dejar al usuario de parte
de los desarrolladores.
Actor primario:
Equipo de desarrollo (encargado del desarrollo
del software y, por ende, del manual de usuario).
Condiciones previas:
-
El equipo de trabajo debe tener ya
pensadas o establecidas un conjunto
de normas y pautas que el usuario
debe seguir para poder plasmarlas y
ampliarlas.
-
Se debe tener seleccionada una
metodología para redactar el manual
de usuario.
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un
Escenario de éxito principal:
Luego de que el equipo de desarrollo tenga una
idea de qué quiere lograrse con el software, éste
redactará el manual de usuario en su totalidad,
pudiendo crear un documento donde se le
especifique al usuario qué debe hacer con el
software, como hacerlo y definirle para qué sirve
cada opción de éste.
Flujos alternativos del programa:
-
El equipo de desarrollo no tiene una
idea clara de qué instrucciones se le
quieren dar al usuario, por lo que
deberán pensar desde cero en normas
e instrucciones para plasmar en el
manual de usuario.
Frecuencia de uso:
El manual de usuario deberá ser como una
recopilación de todas las funcionalidades del
software, es decir, deberá tener información
sobre cada opción presente al momento de usar
el software, por lo que se deberá especificar muy
claramente qué opciones de uso tiene cada
apartado del software.
Criterios de aceptación:
El requisito será aceptado cuando se evidencie
que existe un documento en el que se especifique
(desde la perspectiva de cualquier usuario) qué
opciones de uso tiene el software y cómo actúa
cada opción de éste.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
El manual de usuario debe ser fácilmente
localizable, desde los ajustes propios de la
aplicación, además de que su estructura debe ser
la de un documento común (debe constar de
portada, introducción, índice, tabla de contenido
y contenidos, además de bibliografías y recursos
externos).
-El software No necesariamente debe ser de código abierto. Si fuera un software de
código cerrado, sería una privatización de los derechos de desarrollo de éste, por lo
que, si se llegan a considerar futuras ganancias monetarias, dichas ganancias irían
dedicadas exclusivamente al equipo que se encargó de desarrollar el software y
semejantes.
o En caso de que el software se decida publicar como código abierto, otros
agentes externos al equipo de trabajo (tales como desarrolladores de
plataformas como LinkedIn, StackOverflow y GitHub) tendrían acceso a su
código fuente. Si esto llega a suceder, se podría propulsar un desarrollo libre
para el software, pudiendo llegar a más desarrolladores y equipos para su
constante evolución. El software también debe contar con un apartado de
declaraciones de derechos de autor, bibliografías y referencias.
Identificador:
VRF9-2024
Título:
“Verificación de la legitimidad legal de los
derechos de desarrollo del software”
Descripción:
Se procede a validar qué legalidad tiene el equipo
de desarrollo del software sobre éste, es decir qué
aspectos legales tocará el software acerca de Uso
de licencias, desarrollo por otros equipos
independientes o monetización del producto.
Actor primario:
El equipo de desarrollo del software.
Condiciones previas:
-
El
software
ya
debe
estar
terminado.
-
El equipo de trabajo debe haber
considerado la posibilidad de que
el software sea tanto de código
cerrado como de código abierto
(los pros y contras de ambas
opciones.)
Calificación de esfuerzo
En la escala del 1 al 10, éste requisito tiene una
calificación respecto a su dificultad de desarrollo
de un 3.
Escenario de éxito principal:
Dependiendo los intereses y la finalidad de las
herramientas del desarrollo del software, el
equipo de desarrollo podrá tomar una decisión
final en cuanto a la legitimidad que se le quiere
dejar al software:
-
Si el software se decide publicar
como código abierto, puede que
no
tenga
una
monetización
demasiado grande, pero permitirá
que
diferentes
equipos
y
desarrolladores
Freelancer’s
(trabajadores
independientes)
puedan modificar y documentar
sus
propias
versiones
del
software.
-
Si el software se decide publicar
como código cerrado, su uso
empresarial puede que sea más
considerado desde la perspectiva
empresarial, pudiendo llegar a
una monetización superior gracias
a anuncios y tráfico de datos a
terceros para publicitar éstos
además de que el proyecto pueda
ser financiado o remunerado por
una empresa/entidad concreta.
A final de cuentas, ambas opciones de
publicación tienen sus características, por lo que
el caso de éxito principal será aquel en el que los
desarrolladores
lleguen
a
una
decisión
concreta sin complicaciones mayores.
Flujos alternativos del programa:
-
El equipo de desarrollo no llega a
una conclusión concreta cuando
se termina el desarrollo del
software, por lo que el equipo
pospondrá la publicación del
software hasta que se acuerde una
decisión fija.
Frecuencia de uso:
La legitimidad y los derechos del software son un
aspecto que puede influenciar de muchas
maneras la forma en la que el usuario final pueda
calificar el producto, por lo que desarrollar
satisfactoriamente éste requisito será de vital
importancia, teniendo una frecuencia de uso
constante.
Criterios de aceptación:
El requisito será aceptado cuando se publique
satisfactoriamente el software bajo un modelo de
publicación, ya sea de código abierto como
código cerrado.
Estado de su desarrollo:
EN PROCESO DE DESARROLLO
Observaciones:
Este requisito no es funcional, pero será gracias
a él que se decidirá el futuro del software. Luego
del desarrollo y la publicación, se le debe crear
atracción al usuario para que use el producto
constantemente, por lo que se debe tomar una
sabia decisión en cuanto a la legitimidad de su
desarrollo,
ya
sea
desde
el
aspecto
documentativo como financiero.
Historias de usuario de los demás requisitos:
Como se mencionó anteriormente, solo los requisitos generales cuentan con un caso de uso
para evidenciar su funcionamiento de manera más mecánica y ajustable. Así, pues, los demás
requisitos funcionales se plantean a continuación haciendo uso de las historias de usuario,
para poder evidenciar su uso de una forma más objetiva respecto a lo que los usuarios desean.
(NOTA: no se plantearon historias de usuario a los requisitos no funcionales debido a
que, como su nombre lo indica, no se refieren a funcionalidades básicas y verificables
en su totalidad, sino a pautas a seguir en el desarrollo del software cuando se esté
desarrollando éste mismo para lograr un sistema más completo, accesible y, de forma
práctica, más intuitivo.)
Dicho esto, a continuación, los requisitos funcionales y no funcionales:
Requisitos funcionales desde la perspectiva de un usuario común:
-
Registro de usuario: el potencial empleado debe ser capaz de registrarse e
iniciar sesión en la plataforma, con su nombre, usuario o correo y con su
respectiva contraseña la cuál involucrará caracteres ASCII. También se puede
hacer un registro y un inicio de sesión con Facebook o Google.
-
Acceso al menú: el potencial empleado debe ser capaz de desplazarse por el
menú de la plataforma: navegar entre opciones, ver postulaciones disponibles,
gestionar su perfil, etc.
-
Búsqueda de postulaciones de empleo: El potencial empleado debe ser capaz
de buscar, filtrar y encontrar diferentes solicitudes de empleo abiertas por
diferentes empresas. A su vez, este motor de búsqueda puede ser mediante
palabras clave, nombre de la empresa, fecha de postulación, cargo o salario,
entre otros filtros de búsqueda más.
-
Presentación de solicitudes: El potencial empleado debe ser capaz de
seleccionar una postulación de trabajo acorde a su hoja de vida. Esto debe
incluir un apartado de comunicación entre la empresa y el potencial empleado,
unos términos a aceptar y un apartado para que el potencial empleado adjunte
sus documentos para enviarlos en la postulación de empleo. La postulación
debe contar con información de la empresa, el cargo, los equipos de trabajo y
requisitos para llevar a cabo dicho cargo dentro de la empresa, entre otros
datos acerca del trabajo.
-
Información sobre el estado de la solicitud: Luego de que el potencial
empleado presentara su solicitud a una postulación de empleo de una empresa,
esta solicitud deberá ser procesada por un equipo interno de la empresa. Dicho
equipo será el encargado de aceptar, rechazar y justificar la elección acerca de
la solicitud de empleo del posible empleado.
-
Apartado de respuesta: El sistema debe ser capaz de notificarle eficazmente
al posible empleado de la empresa que su solicitud de empleo fue O aceptada
o bien rechazada por X o Y motivo. El software debe ser capaz de desempeñar
ésta tarea con eficacia y manteniendo una línea de comunicación sólida entre
la empresa y el posible empleado.
-
Opciones en caso de rechazo: Si la solicitud previamente enviada a la empresa
llegase a ser rechazada, entonces el posible empleado debe ser consciente de
los motivos que la empresa tuvo de esa decisión. Así, pues, el posible
empleado podrá volver a juntar información suya y podrá postularse a más
solicitudes de empleo.
-
Opciones en caso de aceptación: Si la solicitud redimida por el posible
empleado llegase a ser aceptada, entonces la empresa le haría saber la decisión
al posible empleado, haciendo que éste se convierta en un empleado oficial de
la empresa. Lo siguiente sería que acuerden un contrato y se charlen mediante
el chat de la plataforma los horarios, salarios, prestaciones y otros temas
legales en cuanto al empleo.
A continuación, las historias de usuario:
Número
Nombre de la
Descripción de
Observacione
Puntos
Criterios de
de la
historia
la historia de
s acerca de la
estimado
aceptación
usuario
historia
s de
historia
(priorizada
esfuerzo
)
1
Iniciar sesión
como usuario
común.
2
Desplazamient
o a través del
menú principal
3
Búsqueda y
localización de
Como usuario no
administrativo de
la aplicación,
quiero poder
iniciar sesión en
el software a
través de mi
correo
electrónico y
contraseña para
acceder a mi
página de inicio.
Como usuario
común, quiero
poder
desplazarme
sencillamente a
través del menú
principal del
software, el cual
se presentará
justo luego del
inicio de sesión.
Como usuario,
quiero poder
utilizar la barra
Esta historia
debería ser la
más sencilla
de programar,
con tal de un
correo
(usuario) y
una contraseña
ya debería ser
posible el
acceso fácil.
2
El usuario
debe poder
acceder al
menú principal
sin
complicacione
s ni tiempos de
espera
innecesarios.
3
Los filtros de
búsqueda
deben
4
La historia
será aceptada
cuando se
evidencie que
es posible para
el rol de
usuario común
acceder a la
plataforma a
través de
correo y
contraseña.
La historia
será aceptada
cuando se
evidencie que
el usuario,
luego de
iniciar sesión,
es redirigido al
menú principal
sin
complicacione
s.
La historia
será aceptada
cuando se
4
postulaciones
de empleo.
de búsqueda del
software
(ubicada en el
menú principal)
para poder
buscar
solicitudes de
empleo a través
de palabras clave
y demás
opciones de
búsqueda.
Envío de
postulaciones
de empleo
Como usuario,
quiero poder
enviar
postulaciones de
empleos
emergentes en el
software. Dichas
postulaciones
deberán poder
ser redactadas en
una pantalla
aparte del menú
principal y deben
contener una
hoja de vida,
descripción del
perfil y unas
palabras de
introducción
propia del
usuario que envíe
la solicitud. A su
vez, la
postulación debe
tener, en la
descripción del
empleo,
información del
cargo y de la
empresa.
contener
opciones como
búsqueda
manual y
filtros por
letras,
palabras,
números,
fecha de
publicación,
salario y
empresa que
publicó la
postulación
Las
postulaciones
deben ser
redactadas
correctamente
por el usuario
a una
solicitud, y a
su vez las
solicitudes
deben
contener una
buena
información
de parte de la
empresa.
evidencie que
el menú
principal tiene
una barra de
búsqueda para
filtrar y
encontrar
solicitudes y
empresas.
4
La historia
será aceptada
cuando se
evidencie que
el usuario
puede enviar
su solicitud de
empleo a
través de la
plataforma, en
el aparado de
Enviar
solicitud
dentro de una
postulación de
empleo.
5
Información
sobre el estado
de la solicitud
enviada.
Como usuario,
quiero poder
revisar el estado
de las solicitudes
que envié
previamente en
una solicitud de
empleo.
El estado de
las solicitudes
será
visualizado en
un cuadro
horizontal,
similar a una
línea de
tiempo en, el
que se verá
desde el
primer paso
(la adjunción
de
documentos)
hasta la etapa
presente de la
solicitud.
5
La historia
será aceptada
cuando se
evidencie que
existe una
forma de
revisar el
estado de la
solicitud del
empleado.
Dicha forma
se estima sea
un cuadro
similar a una
línea de
tiempo con
datos sobre la
solicitud.
6
Respuesta de
la solicitud
previamente
enviada por el
usuario
(positivamente
)
Como usuario,
quiero poder ser
informado por la
aplicación, a
través de un
cuadro en el
menú principal,
que la solicitud
que envié a una
postulación de
empleo fue
aceptada
satisfactoriament
e.
7
La historia
será aceptada
cuando se
evidencie que
el sistema le
puede notificar
al usuario que
su solicitud
fue analizada
de manera
exitosa y que
dicha
notificación
pueda dirigir
al usuario a un
chat con la
empresa.
7
Respuesta de
la solicitud
previamente
enviada por el
usuario
Como usuario,
quiero poder ser
informado por la
aplicación, a
través de un
cuadro en el
Cuando el
apartado que
indique la
aceptación de
la solicitud
aparezca,
dicho cuadro
debe contener
un botón
dinámico que
permita ir
directo a un
chat con la
empresa para
acordar cómo
se firmará el
contrato de
empleo y bajo
qué términos.
Al contrario
que en el caso
de éxito, la
plataforma
deberá mostrar
una pequeña
4
La historia
será aceptada
cuando se
evidencie que
el software es
capaz de
(negativament
e)
menú principal,
que la solicitud
que envié a una
postulación de
empleo fue
rechazada,
además de que
dicho cuadro
cuente con
detalles del
porqué se
rechazó y un
mensaje de
agradecimiento
de la empresa
por el interés
hacia el empleo
notificación en
un apartado de
la plataforma
informando
que la
solicitud se
rechazó. Dicha
notificación se
podrá ampliar
y se podrá leer
a detalle a qué
se debe este
rechazo
enviar una
notificación
ampliable
acerca del
rechazo de la
solicitud de
empleo de un
usuario hacia
una
postulación.
Requisitos funcionales desde la perspectiva de un usuario administrativo:
-
Ingreso a la plataforma: El ingreso al sistema no debe tardar más de 15
segundos,
de
lo
contrario
los
campos
llenados
se
blanquearán
automáticamente.
-
Ingreso al menú de usuario: Desde la perspectiva del usuario, el acceso al
menú debe ser claro, sencillo e intuitivo con un apartado a la izquierda de la
pantalla que despliegue una tabla con las opciones que tendrá el usuario:
Perfil, postulaciones del usuario, noticias, novedades, configuración y demás
apartados.
-
Redacción de solicitudes: Al momento de redactar una solicitud de empleo, el
software no debe ser solamente capaz de adjuntar documentos de formato
PDF, también debe ser capaz de adjuntar archivos Word y tablas de cálculo
Excel, además de presentaciones PowerPoint, archivos de texto plano y otros
formatos como Java, Python, C/C++ y otros lenguajes. Adicional a esto,
también debe contar con su propio apartado de escritura con diferentes
fuentes, tamaños, títulos y subtítulos, colores, negrilla y subrayado y otras
cuantas opciones de personalización.
-
Envío de solicitudes: la plataforma debe ser capaz de avisarle al empleado
cada revisión que la empresa le realice a su solicitud: desde que la solicitud es
recibida hasta cuando es revisada, comentada y se le da un veredicto a la
solicitud.
-
Comunicación con la empresa: el chat con la empresa debe ser visualmente
atractiva, dinámica y con atajos de chat para una mayor personalización y, por
ende, un mayor gusto de utilizar la plataforma. Además, de manera opcional,
se pueden personalizar aspectos como los sonidos de notificación del software
y programar mensajes para enviarse en determinada hora del día, entre otras
funciones.
-
Funciones de perfil de usuario: El perfil del usuario debe ser capaz de
personalizarse de tal forma que cuente con un apartado para sincronizar con
redes sociales del usuario, una pequeña biografía, una foto de portada de perfil
y una foto de perfil propia del usuario, entre otras opciones de personalización.
-
Funciones de notificación: las notificaciones deben ser claras y sencillas, debe
saltar un anuncio en la esquina de la pantalla incluso cuando la aplicación esté
cerrada, además de un sonido característico del software.
A continuación, las historias de usuario de estos requerimientos:
Número de
Nombre de la
Descripción
Observacione
Puntos
Criterios de
la historia
historia
de la historia
s acerca de la
estimado
aceptación
de usuario
historia
s de
(priorizada
)
1
esfuerzo
Inicio de
Como usuario
Esta historia
6
La historia
sesión del
administrativo,
debe ser
será aceptada
administrador.
quiero poder
sencilla de
cuando se
registrarme e
programar,
evidencie que
iniciar sesión
debe ser capaz
el software es
en el software
de acceder con
capaz de
haciendo uso
un usuario
permitirle el
de mi correo
(correo
acceso a un
(usuario)
empresarial) y
usuario
empresarial y
una contraseña,
administrativo
mi contraseña,
además de que
usando su
además de que
cada vez que se
correo y
dicho inicio de
inicie sesión el
contraseña y
sesión debería
sistema emplee
también
contar con la
una
gracias a la
autenticación
autenticación
autenticación
de 2 pasos
de 2 pasos, tal
de 2 pasos.
como un
mensaje a un
celular o al
correo
electrónico del
usuario.
2
Acceso al
Como usuario
Esta historia
3
La historia
menú
administrativo,
debería ser la
será aceptada
administrativo.
quiero que
más sencilla de
cuando
justo luego de
hacer realidad
haber iniciado
ya que será
sesión pueda
sencillo
acceder al
programar que,
menú principal
luego del inicio
del software
de sesión y la
donde luego
autenticación
podré realizar
de 2 pasos, el
diferentes
usuario sea
acciones.
redirigido al
menú principal.
3
Administració
Como usuario
El software,
6
La historia
n de
administrativo,
para poder
será aceptada
solicitudes de
quiero pode
cumplir con
cuando se
empleo
administrar
este requisito
evidencie que
entrantes.
solicitudes de
deberá contar
un usuario de
una vacante de
con conexiones
tipo
empleo gracias
con servicios
administrativo
a las
de terceros
está en
herramientas
(como bases de
capacidad de
que me brinda
datos y
administrar,
el software.
servidores)
modificar y
para almacenar
verificar la
el total de
integridad y
solicitudes de
disponibilidad
una vacante, y
de las
a su vez, el
solicitudes de
sistema deberá
empleo de la
poder
vacante de su
modificar
empresa.
dicho
repositorio:
leerlo, cambiar
el orden, añadir
y quitar
solicitudes
4
Chequeo de
Como usuario
El software
5
La historia
las solicitudes
administrativo,
debe contener
será aceptada
de empleo.
quiero poder
un botón, como
cuando se
hacer una
un acceso
evidencie que
prueba sencilla
directo de cada
el sistema
(como un
solicitud para
tiene un
reconocimiento
verificar si está
protocolo en
) de la
disponible en
caso de fallas
integridad de
el sistema. Si
en una
determinada
no llega a estar
solicitud de
solicitud para
disponible, el
empleo. Dicho
ver si sigue
sistema dará un
protocolo
disponible en la
mensaje
deberá poder
plataforma y si
diciendo que el
enviar un
se puede hacer
documento no
mensaje
comunicación
está disponible
acerca de lo
con el usuario
y se debe pedir
que sucede y
que la envió
un reenvió por
también
parte el usuario
deberá
que la adjuntó.
redirigir el
sistema a un
chat con el
usuario para
pedirle un
reenvío.
5
6
Selección y
Como usuario
El usuario
4
filtrado de
administrativo,
administrativo
será aceptada
solicitudes
quiero poder
debe ser
cuando se
adecuadas.
utilizar
consciente de
evidencie que
herramientas
qué busca de
el software es
propias del
un empleado
capaz de filtrar
software para
para la
y organizar las
filtrar todas las
postulación:
solicitudes de
solicitudes de
qué actitudes,
empleo para
empleo
aptitudes y
que el
entrantes y
expectativas se
administrador
seleccionar la
le estima a un
de la empresa
más adecuada
empleado para
pueda
para el trabajo
que sea
seleccionar el
dependiendo
considerado un
perfil más apto
los criterios de
posible
para el
mi empresa.
empleado.
empleo.
Comunicación
Como usuario
Para cumplir
con el usuario
administrativo,
con este
será aceptada
de la solicitud
quiero poder
requerimiento
cuando se
más apta para
entablar una
se debe
evidencie que
el empleo.
conversación
desarrollar un
el software
con el
sistema de
tiene su propio
candidato más
mensajería
servicio de
7
La historia
La historia
apto para el
dentro del
mensajería de
empleo
software que
texto para que
previamente
sea capaz de
diferentes
seleccionado de
enviar y recibir
usuarios tanto
forma eficiente
mensajes de un
comunes como
y dinámica a
usuario a otro,
administrativo
través del
además de
s puedan
servicio de
adjuntar
entablar
mensajería del
documentos,
conversacione
software.
videos e
s privadas
imágenes.
acerca del
empleo.
Listado de requisitos no funcionales:
Para mantener al tanto la mayor parte de especificaciones posibles del software en este
documento, a continuación se presentan los listados de requisitos no funcionales desde las
perspectivas de un usuario común y un usuario administrativo:
Requisitos no funcionales desde la perspectiva de un usuario común:
-
Ingreso a la plataforma: El ingreso al sistema no debe tardar más de 15
segundos,
de
lo
contrario
los
campos
llenados
se
blanquearán
automáticamente.
-
Ingreso al menú de usuario: Desde la perspectiva del usuario, el acceso al
menú debe ser claro, sencillo e intuitivo con un apartado a la izquierda de la
pantalla que despliegue una tabla con las opciones que tendrá el usuario:
Perfil, postulaciones del usuario, noticias, novedades, configuración y demás
apartados.
-
Redacción de solicitudes: Al momento de redactar una solicitud de empleo, el
software no debe ser solamente capaz de adjuntar documentos de formato
PDF, también debe ser capaz de adjuntar archivos Word y tablas de cálculo
Excel, además de presentaciones PowerPoint, archivos de texto plano y otros
formatos como Java, Python, C/C++ y otros lenguajes. Adicional a esto,
también debe contar con su propio apartado de escritura con diferentes
fuentes, tamaños, títulos y subtítulos, colores, negrilla y subrayado y otras
cuantas opciones de personalización.
-
Envío de solicitudes: la plataforma debe ser capaz de avisarle al empleado
cada revisión que la empresa le realice a su solicitud: desde que la solicitud es
recibida hasta cuando es revisada, comentada y se le da un veredicto a la
solicitud.
-
Comunicación con la empresa: el chat con la empresa debe ser visualmente
atractiva, dinámica y con atajos de chat para una mayor personalización y, por
ende, un mayor gusto de utilizar la plataforma. Además, de manera opcional,
se pueden personalizar aspectos como los sonidos de notificación del software
y programar mensajes para enviarse en determinada hora del día, entre otras
funciones.
-
Funciones de perfil de usuario: El perfil del usuario debe ser capaz de
personalizarse de tal forma que cuente con un apartado para sincronizar con
redes sociales del usuario, una pequeña biografía, una foto de portada de perfil
y una foto de perfil propia del usuario, entre otras opciones de personalización.
-
Funciones de notificación: las notificaciones deben ser claras y sencillas, debe
saltar un anuncio en la esquina de la pantalla incluso cuando la aplicación esté
cerrada, además de un sonido característico del software.
Requisitos no funcionales desde la perspectiva de un usuario administrativo:
-
Ingreso a la plataforma: A diferencia del ingreso a la plataforma de un usuario
común, el administrador contará con menos tiempo de inicio de sesión para
un inicio de sesión más estricto, más exactamente 10 segundos.
-
Gestión de perfil: El perfil del administrador debe tener vinculado en todos
los aspectos de redes sociales las cuentas oficiales de la empresa, además de
contar con una pequeña insignia de la plataforma que le permita ver que dicho
administrador es parte de la empresa en cuestión.
-
Administración de solicitudes: El administrador de solicitudes de la empresa
debe contar con un apartado del menú para gestionar las solicitudes de empleo.
Esto quiere decir que el apartado de las solicitudes debe contar con filtro y
organización mediante letras, fecha de subida, última actualización, entre
otros filtros.
-
Administración de equipos de trabajo: El administrador de la empresa, al ser
parte de un equipo de contratación, deberá contar con una vía de mensajería
especialmente diseñada para comunicarse con otros miembros de su equipo,
para que las diferentes líneas de gestión mantengan una constante
comunicación.
-
Distribución de las solicitudes: la cantidad de solicitudes que le lleguen a la
empresa puede sobrepasar las cantidades promedio que un solo administrador
pueda gestionar, por lo que distribuir la tarea entre varios administradores
sería una alternativa viable para la empresa. Así, pues, dependiendo la
cantidad de solicitudes que lleguen, se destinarán diferentes equipos de trabajo
a la tarea de gestionar solicitudes de empleo gracias al software.
Conclusiones:
Gracias a los casos de uso, historias de usuario y listado de diferentes tipos de requerimientos
que el software debe cumplir, se pudieron establecer las diferentes perspectivas de dichos
requerimientos y, por ende, el desarrollo del software podrá continuar sin complicaciones
mayores.
Bibliografía:
https://www.atlassian.com/es/agile/project-management/user-stories
https://thedigitalprojectmanager.com/es/gestion-alcance/guia-de-recopilacion-de-requisitos/