REQUERIMIENTOS DE SOFTWARE

Camilo Andres Zapata Prieto

Moises Camilo Arias Herrera

06 de Mayo del 2020

Corporación Unificada Nacional de Educación Superior – CUN.

Ingeniería de Sistemas.

2020
1. TITULO DEL PROYECTO

2. PLANTEAMIENTO DEL PROBLEMA

En el mundo tecnificado en el que vivimos todos los nuevos dispositivos electronicos necesitan un
mantenimiento preventivo periodico, y de vez en cuando un mantenimiento correctivo por alguna falla en
especifico, para una gran parte de las personas que usan estos nuevos dispositivos electronicos se les hace
muy dificil encontrar personas capacitadasque les ayuden a resolver estas fallas.
3. OBJETIVO GENERAL
Desarrollar una APP en la que se puedan registrar tecnicos, tecnologos e ingenieros de sistemas y carreras
afines , que deseen ofrecer sus servicios y conocimientos a la comunidad.
4. OBJETIVOS ESPECIFICOS
• Realizar un analisis de los productos electronicos mas usados que presenten fallas frecuentes.
• Analizar la facilidad de reparación de las diferentes fallas presentadas para determinar cuales son mas
recurrentes y faciles de solucionar.
• Estimar costos y tiempos de desarrollo de la aplicación.
5. REQUERIMIENTOS FUNCIONALES
5.1. Requerimientos de Proceso
• La APP debe manejar distintos niveles de acceso según el tipo de usuario, por ejemplo: Especialista,
usuario estandar, administrador de la app.
• La APP debe solicitar una contraseña de acceso para que los usuarios puedan interactuar según el
nivel del usuario registrado.
• La APP debe manejar una base de datos de conocimiento de las fallas reportadas y la solucion dada por
el especialista.
• La APP puede programar una visita tecnica ya sea en sitio o de forma remota para la atencion de la
falla.
5.2. Requerimientos de Interfaz Grafica
• La APP sera compatible para plataformas iPhone y Android.
• La interfaz grafica del usuario estandar mostrara un menu para filtrar el tipo de periferico con la falla,
luego mostrara un cuadro de texto donde el usuario podra realizar la descripcion de la falla y adjuntar
imágenes descriptivas.
• La interfaz del especialista mostrara una lista de las fallas asignadas, si el especialista puede dar la
solucion podra aceptar esta asignacion o de lo contrario devolvera la falla al administrador de fallas de la
app.
• La interfaz del administrador mostrara una lista de las fallas registradas por todos los usuarios, tendra
filtros de informacion para mostrar los usuarios estandar, los especialistas por area de especialidad y las
fallas podran ser clasificadas para una mejor tipificacion ,administracion y asi poder realizar el respectivo
cobro por el servicio.
• La APP arrojara alertas en los distintos tiempos de atencion informando del limite de tiempo para dar la
solucion.
• La APP arrojara reportes de las fallas reportadas, solucionadas, pendientes, cerradas y comentarios de
los usuarios.
5.3. Requerimientos de Seguridad
• La APP controlara el acceso de los usuarios dependiendo su perfil creado.
• Los usuarios ingresaran a la APP indicando nombre de usuario y contraseña.
• La APP enviara mensaje al correo electronico del usuario cuando ingresa a la plataforma y/o cuando alla
actualizacion o cambios en los datos del usuario.
• Los especialistas no podran eliminar o modificar las fallas registradas en el sistema.
• Los administradores podran editar o actualizar las fallas y soluciones mas no eliminar dichos registros.
5.4. Requerimiendos de Interfaz Externas
• La APP estara implementada bajo las plataformas iPhone y Android.
• La APP sera compatible con los dispositivos moviles de gama media y gama alta.
• La APP no requiere de licenciamiento de software adicional para su funcionamiento.

6. REQUERIMIENTOS NO FUNCIONALES

6.1. Requerimientos de Eficiencia

• La APP debe se capaz de operar con minimo mil (1000) sesiones concurrentes a la vez.
• Las actualizaciones realizadas a las fallas registradas deben reflejarse de forma inmediata en todas las
sesiones activas, igualmente que las soluciones.

6.2. Requermientos de Seguridad Logica y de la Informacion

• El administrador de la APP es el unico que puede cambiar los permisos o rol de los usuarios.
• La APP debe ser desarrollada bajo los estandares de seguridad y buenas practicas de desarrollo de
software para disminuir vulnerabilidades en el codigo.
• Se debe realizar un backup quincenal de la base de datos en un equipo externo al que se encuentra
alojada la base de datos.

6.3. Requerimientos de Usabilidad

• El usuario debera aprender a manejar la aplicación en un tiempo no mayor a 3 horas.
• La APP contara con manuales de manejo de la aplicación en un lenguaje sencillo de comprender para los
usuarios.
• Se le informara a los usuarios de una manera clara y precisa en caso de fallas de la plataforma.

7. SELECCIÓN METODOLOGIA DE CILO DE VIDA

7.1. Metodologia Seleccionada

Despues de un riguroso y minucioso analisis de todas las metodologias y de comprar los pros y los
contras, decidimos escoger la metodologia en espiral, ya que es la que menos riesgos nos representa y
nos ofrece muchas ventajas para el proyecto.
7.2. Porque de esa Metodologia
Consideramos que esta metodologia se adapta mejor al proyecto debido a que los requerimientos no
estan muy claros en este momento debido a que pueden variar mas adelante con el desarrollo del
proyecto, esto depende de la acogida que tenga la app y de las necesidades que exponga el cliente que
sean mas importantes, por eso el modelo en espiral se acomoda mucho mejor al proyecto ya que
podriamos ralizar modificaciones tanto pequeñas como grandes a lo que ya se halla prediseñado y se
tenga en ejecucion.
7.3. Cuadro Comparativo

METODOLOGIA VENTAJAS OTRA METODOLOGIA DESVENTAJAS

SELECCIONADA
En este modelo en En cambio en este
cualquier modelo no se puede
momento realizar este proceso
podemos ya que de acuerdo con
ESPIRAL empezar de nuevo CASCADA el concepto este
de acuerdo a los modelo solo avanza
requeremientos cuando la primera
del usuario o fallas parte este completa
de la app
En este modelo se En este modelo se
determinan los realizan repeticiones
ESPIRAL objetivos y las REPETITIVO pero en cada repeticion
limitaciones del se construye un nuevo
software software con las
nuevas modificaciones
Este modelo En este modelo se
plantea un primer realiza un bosquejo y
prototipo y se en paralelo realiza
ESPIRAL pone en ejecucion MODELO V pruebas para validar
y posteriormente fallas del software
se realizan las
mejoras
Este modelo si Para este modelo, se
requiere de mucha requiere poca
planificacion ya planificación,no sigue
que es el modelo ningún proceso en
ESPIRAL que considera los MODELO BIG BANG concreto, y por este
mayores riesgos motivo el cliente no
del software está seguro de las
futuras fallas y
requisitos