ESPECIFICACIÓN DE LOS REQUERIMIENTOS FUNCIONALES Y NO

FUNCIONALES DEL SISTEMA

Valentina Trujillo Alvarez

Ficha: 2104563

Tecnólogo en Análisis y Desarrollo de Sistemas de la Información

Agosto 2020
Bogotá D.C
 GUADAÑAS Y MOTORES PRADO NORTE
PROYECTO DESARROLLO DE SOFTWARE
PLANTILLA STAKEHOLDERS

Código Rol o cargo Descripción del rol o interés Nivel de influencia Interés en el
proyecto
STK-01 Líder de Colaborador encargado del análisis, 100% ALTO
desarrollo del desarrollo e implementación del
proyecto sistema de información que servirá
como herramienta que permita
mantener en orden los inventarios,
ordenes de trabajo del personal técnico,
resguardo y recopilación de la
facturación del taller.
STK-02 Gerente Es el dueño y responsable legal de la 100% ALTO
empresa “Guadañas y motores prado
norte” en el que se implementará el
sistema de información. Participa
activamente en la definición de
objetivos y de las funcionalidades que
debe tener el sistema para cumplir
con los fines propuestos.
STK-02 Administrador Colaborador encargado de todas las 100% ALTO
tareas administrativas y de atención al
cliente de la empresa “Guadañas y
Motores” también se encarga de brindar
la primera atención al cliente y sus
requerimientos, manejar el inventario,
entradas de recursos, así mismo el
manejo de entradas de maquinaria y
asignación de OT (ordenes de trabajo) al
personal técnico. A través del sistema
de información a implementar, se
pueden automatizar varias tareas a su
cargo y mejorar el desempeño del
cargo.
STK-03 Personal Personal encargado de brindar el 70% MEDIO
técnico soporte y mantenimiento de maquinaria
de acuerdo con las necesidades de los
clientes.
STK-04 Cliente Usuario que se ve beneficiado en la 50% MEDIO
automatización del proceso actual
ejecutado por la empresa, ya que se
disminuyen tiempos de espera, se
ajustan ANS y se brinda una gestión
mucho más organizada.
NOTA: Se asignaron las siguientes nomenclaturas para tener en consideración al momento de
interpretar la tabla que se presenta a continuación
RF: para identificar a los Requisitos Funcionales
RNF: para identificar a los Requisitos No Funcionales
MODRU: Modulo roles de usuarios

GUADAÑAS Y MOTORES PRADO NORTE Formato: GMPN-

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE GRU01
MODULO: ROLES DE USUARIO - MODRU - 001

ID Nombre Descripción Prioridad

RF- Creación de perfiles de Se requiere la creación de los perfiles usuario con 4 niveles ALTO
MODRU- usuario diferentes de acceso, los perfiles son:
01 • Gerente
• Líder de proyecto
• Administrador
• Técnico

RF- Especificaciones de Cada perfil debe ingresar con un usuario y una contraseña
MODRU- perfiles asignada por el líder de proyecto una vez finalice el desarrollo e
02 implementación del sistema de información. Dichas credenciales
se enviarán por correo de verificación al correo electrónico
registrado para su autenticación.

A fin de proceder con la creación de roles y perfiles, cada usuario

RF- Datos de ingreso de deberá facilitar los siguientes datos básicos:
MODRU- perfiles • Nombre Completo
03 • Genero
• Número de documento de identidad
• Dirección de residencia actual
• Teléfono de contacto
• Contacto y teléfono en caso de emergencia
• EPS

Cada perfil de usuario tendrá acceso a determinada información

RF- Permisos por rol de
y permisos de edición/creación dentro del sistema:
MODRU- usuario
• Perfil de Gerente: Debe tener acceso y visibilidad a fin
04
de ejercer la acción de monitoreo de los diferentes
procesos y módulos del sistema de información
• Perfil de líder de proyecto: tiene acceso a todos los
módulos del sistema de información y tiene permisos
para crear y editar todas las entradas.
• Perfil de administrador: Debe tener acceso y permisos
de edición a los módulos de gestión de OT, modulo de
atención al cliente, entradas y salidas de facturas,
modulo de inventarios y recursos y módulo de gestión
técnica. Ya que es el encargado del correcto
funcionamiento de dichos procesos.
• Perfil Técnico: Debe tener acceso únicamente al
modulo técnico y al modulo de gestión de OT (como rol
técnico) a fin de gestionar, realizar seguimiento y
monitorear las ordenes de trabajo asignadas y las
comisiones cargadas.
Cambio de contraseña
 RF- Por política, el sistema debe solicitar el cambio de contraseña a
MODRU- cada usuario máximo cada 3 meses, en dado caso el usuario haya
05 olvidado su contraseña, debe existir un botón para tener la
posibilidad de recuperar y cambiar contraseña.

RNF - Controles y Requisitos No Funcionales:

MODRU restricciones
01. La contraseña deberá ser de mínimo 8 caracteres y tener al menos una
mayúscula y un número.
02. El campo nombre acepta caracteres alfabéticos únicamente.
03. Los campos para números de teléfono tendrán la restricción de solamente
aceptar campos numéricos.
04. El campo de fecha estará estandarizado para recibir solamente números en
un formato establecido: dd/mm/aaaa.
05. Los datos básicos de cada uno de los perfiles creados sólo podrán ser
modificados por el dueño del perfil que se quiera modificar y por el líder del
proyecto.
06. El único dato inmodificable en los datos básicos es el documento de
identidad asociado al perfil, pues será el código de ID del usuario en el
sistema.
07. Los perfiles creados solo podrán ser borrados por el líder de proyecto o en
quién se delegue la administración del sistema previa solicitud escrita de la
eliminación de dicho o dichos perfiles.
08. Se debe generar un sistema de alerta que notifique cuando una OT (orden
de trabajo) supere o este próximo a superar el tiempo optimo de entrega
del producto (vencimiento o próximo vencimiento de los ANS establecidos.
09. Deben aparecer las fechas de seguimiento y actividades realizadas sobre las
OT por parte del personal técnico y el administrador.
10. El sistema controlará el acceso y lo permitirá solamente a quienes tengan
un usuario y una contraseña autenticados en el sistema.
11. La aplicación debe poder utilizarse sin necesidad de instalar ningún
software adicional además de un navegador web.
12. El sistema permitirá la opción de restablecimiento de contraseña a través
del envío de una contraseña provisional al correo electrónico registrado.
13. El sistema bloqueará el ingreso del usuario luego de 3 intentos fallidos, la
cual se desbloqueará transcurridos 15minutos, o en su defecto escalar la
solicitud al líder de proyecto para desbloquear el usuario afectado o en su
defecto si el usuario no recuerda su contraseña, deberá recurrir a la opción
de restablecimiento de contraseña para asignar una contraseña nueva.
Criterios de Aceptación El sistema cumple con los requisitos funcionales solicitados.
El sistema cumple con los controles y restricciones solicitados.
La prueba de creación de perfiles de usuario es exitosa

Fecha de especificación 27/08/2020

Flor M. Gallo Julian Ramirez

________________________ ________________________ ______________________
Firma Firma(s) Firma(s)
( Dueño del proceso ) Usuarios participantes Demás usuarios involucrados
en la especificación en la especificación

NOTA: Se asignaron las siguientes nomenclaturas para tener en consideración al momento de

interpretar la tabla que se presenta a continuación
RF: para identificar a los Requisitos Funcionales
RNF: para identificar a los Requisitos No Funcionales
MODOT: Modulo Ordenes de trabajo

GUADAÑAS Y MOTORES PRADO NORTE Formato: GMPN-

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE GOT01
MODULO: GESTIÓN DE OT’S (ORDENES DE TRABAJO) - MODOT -
002

ID Nombre Descripción Prioridad

RF- Gestión de acceso al Deben existir dos tipos de acceso al módulo ALTO
MODOT- módulo:
01 • El primero debe ser con permisos de edición,
visualización y creación los cuales serán asignados al
administrador, quien también tendrá la posibilidad de
asignar OT’s al personal técnico, realizar seguimiento de
estas y edición de las mismas en caso de ser necesario,
también debe tener dichos permisos sobre el campo de
comisión.
• El segundo, el perfil técnico de acceso al módulo solo
tendrá permisos de visibilidad de la OT y deberá tener
habilitado el campo de “Seguimiento” y “Solución”
para gestionar las OT’s, deberá tener inhabilitados los
demás campos a fin de no modificar la OT original y no
poder reasignar la OT a otro técnico ya que esa función
debe ser netamente del administrador.

Se requiere un campo para cada uno de los siguientes datos:

RF- Campos del módulo:
MODOT- ✓ nombre del cliente
02 ✓ teléfono de contacto del cliente
✓ marca, tipo y color de la máquina que se deja en el
taller
✓ campo para seleccionar la gestión a realizar
(reparación, mantenimiento etc)
✓ técnico asignado
✓ campo para asignar el ANS para la gestión de la OT
✓ campo de descripción sobre el cual el administrador en
conjunto con el técnico describe el estado en el cual se
recibe la maquina y la gestión que se espera ejecutar
sobre ella.
✓ Campo de seguimiento, sobre el cual el técnico debe
describir los avances o novedades evidenciadas
durante el proceso con la maquina
✓ Campo de solución, sobre la cual el técnico debe
describir la gestión completa realizada hasta su
solución.
✓ Campo de comisión sobre el cual el administrador
asigna la comisión equivalente a la OT
RNF - Controles y Requisitos No Funcionales:
MODOT restricciones
01. Los permisos sobre cada perfil del módulo únicamente deberán ser
otorgados por el rol de líder de proyecto.
02. El campo “Nombre del cliente” acepta caracteres alfabéticos únicamente.
03. El campo para “Teléfono de contacto del cliente” tendrá la restricción de
solamente aceptar campos numéricos.
04. Debe existir una lista de maquinas para tener la posibilidad de seleccionar y
completar el campo de “tipo de maquina” así mismo una lista para
 seleccionar y completar el campo “Marca” y “Color” en caso de que en
dicha no se encuentre los datos que describen la maquinaria, debe existir
una opción que diga “otro” y habilite la edición del campo.
05. Para diligenciar el campo “tipo de gestión” deben estar solo 3 opciones
para seleccionar y completar el campo las cuales son:
• Mantenimiento 5 días hábiles
• Reparación 3 días hábiles
• Otro (si se selecciona este campo, se debe habilitar la edición del mismo) y
su prioridad asignada
También se debe asignar una prioridad a cada tipo de gestión, para
contabilizar los ANS de gestión. Las cuales se señalan en rojo
06. El campo para texto de “descripción”, “seguimiento” y “solución” será de
500 caracteres
07. El campo comisión debe ser editable, ya que el administrador es el
encargado de asignar la comisión de cada OT generada.
08. Debe existir un dashboard general en donde se podrán evidenciar todas las
OT’s generadas durante el día, semana, mes y últimos 6 meses así mismo se
evidenciará el técnico asignado de cada OT, ANS y estado (seguimiento o
solución) dicho dashboard será de ayuda para la gestión del administrador
sobre el personal técnico y sus actividades laborales.
Criterios de Aceptación El sistema cumple con los requisitos funcionales solicitados.
El sistema cumple con los controles y restricciones solicitados.
La prueba de creación, asignación y solución de una OT sobre un perfil de pruebas fue
exitoso.
Fecha de especificación 27/08/2020

Flor M. Gallo Julian Ramirez

________________________ ________________________ ______________________
Firma Firma(s) Firma(s)
( Dueño del proceso ) Usuarios participantes Demás usuarios involucrados
en la especificación en la especificación

NOTA: Se asignaron las siguientes nomenclaturas para tener en consideración al momento de

interpretar la tabla que se presenta a continuación
RF: para identificar a los Requisitos Funcionales
RNF: para identificar a los Requisitos No Funcionales
MODIRGA: Modulo de Inventarios, Recursos y Gestión Administrativa

GUADAÑAS Y MOTORES PRADO NORTE Formato: GMPN-

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE GIRGA01
MODULO: INVENTARIOS, RECURSOS Y GESTIÓN
ADMINISTRATIVA - MODIRGA - 003

ID Nombre Descripción Prioridad

 RF- Plantillas de gestión de Deben existir dos plantillas modificables, las cuales se podrán ALTO
MODIRGA- inventarios y recursos alimentar con nuevos datos. Ajustar y o modificar los datos
01 previstos, así se mantendrá una plantilla para la gestión de
inventarios y otra para la gestión de recursos o insumos de
entrada. Cada plantilla deberá tener las columnas obligatorias
que se describe a continuación:
• ID del insumo
• Nombre del insumo
• Descripción del insumo
• Fecha de existencia (desde)
• Ultima fecha de suministro
• Existencia total

El sistema Deberá permitir hacer una búsqueda sobre los

RF- Función de búsqueda insumos descritos en ambas plantillas a partir de ID asignado a
MODIRGA- cada insumo y así realizar modificación después de cada acción
02 de inventario ejecutada cada semana, así mismo se señalará de
color característico el insumo de acuerdo con su existencia.

El sistema debe contener una pestaña adicional sobre el mismo

RF – Gestión de factura modulo, que permita manejar las entradas y salidas de
MODIRGA- facturación, de esta manera el sistema le permitirá al
03 administrador ingresar información referente a los pagos
realizados y así mismo controlar y centralizar las entradas
económicas de acuerdo con la facturación emitida. Allí se
considerará la siguiente información:
• Nº de factura
• Entrada (ó) salida
• Fecha
• Valor
• Método de pago
• Estado de la factura
RNF - Controles y Requisitos No Funcionales:
MODIRGA restricciones
01. Las plantillas podrán ser modificadas en su totalidad por el líder del
proyecto, a fin de agregar nuevas columnas o datos y funciones
especificas que requiera la operación
02. El administrador no podrá modificar las columnas solo la información en
el contenido de las plantillas.
03. En los campos de fecha estará estandarizado para recibir solamente
números en un formato establecido: dd/mm/aaaa
04. En el campo de existencia total solo se debe permitir la digitalización
numérica.
05. Se debe crear una lista de selección en donde solo debe estar la opción
Entrada y la opción salida
06. El campo “valor” solo se debe permitir la digitalización numérica con dos
decimales.
07. El campo método de pago debe contener una lista desplegable sobre la
que se seleccione:
• Crédito
• Debido
• Cheque
• Efectivo
0.8. El campo “Estado de la factura solo debe contener las opciones para
seleccionar Pagada o en deuda
0.9. Se debe configurar un sistema de alerta para contemplar dos escenarios:
 • Debe configurarse un sistema de alerta que indiqué cuando un
recurso esta por agotarse en la gestión de inventarios.
• Debe configurarse un sistema de alerta para la pestaña de
factura que indique cuando una factura en estado “En
deuda” supere los 5 días hábiles posterior a la fecha
registrada en el sistema.
0.10. La aplicación debe poder utilizarse sin necesidad de instalar
ningún software adicional además de un navegador web.
0.11.
Criterios de El sistema cumple con los requisitos funcionales solicitados.
Aceptación El sistema cumple con los controles y restricciones solicitados.
La prueba control de inventarios, recursos y gestión de facturación fue exitosa

Fecha de 27/08/2020
especificación

Flor M. Gallo Andres Escobar G.

________________________ ________________________ ______________________
Firma Firma(s) Firma(s)
( Dueño del proceso ) Usuarios participantes Demás usuarios involucrados
en la especificación en la especificación