Título de la tarea: Modelo de gestión de requerimientos

Nombre Alumno: Alvaro Nicolas Donoso Alvarez

Nombre Asignatura: Ingeniería en requerimiento de software

Instituto IACC

21/12/2020
 Desarrollo

1.Crear un diagrama que conduzca el flujo o los pasos para su

implementación.

Diagrama de Nivel 1.1 Cliente para el Sistema gestión Venta y reparación del servicio
técnico.
Bodega para el Sistema de gestión de Venta y reparación para el servicio técnico.
EL MODELO ESPIRAL DE BOEHM

· Determinar o fijar objetivos

Para el mejoramiento de todos los procesos que se llevan a cabo dentro del negocio, a la
vez de controlar y adquirir información importante de los resultados de ventas es necesaria
la solución informática presentada como Sistema para Control y Venta. Dada la solución
informática se detallarán los diferentes requerimientos:

 Control de las ventas realizadas por cada uno de los funcionarios.

 Desplegar información útil tanto gráfica como tabular a nivel gerencial para la toma
de decisiones.
 El Sistema de Bodega y Asignaciones deberá almacenar información relevante de los
proveedores de la empresa, para permitir consultas en forma exacta y rápida.
 Llevar un catastro exacto del Hardware que entran y salen del servicio técnico
 Agilizar los procesos de reparación, tanto en el estado de recibir los pedidos como en
la entrega del mismo.
 El Sistema de gestión deberá almacenar todos los datos respectivos a la venta, datos
de la reparación, los productos vendidos, el valor total, funcionario que la realizó,
etc.
 Lograr un proyecto exitoso (Tiempo, Dinero y Objetivos).

· Planificar
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases
siguientes y planificamos la próxima actividad.

· Desarrollar y probar
Decidí usar el modelo en espiral, esto porque se sujeta a previos cambios.
Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se
hayan podido cometer en las etapas anteriores del proyecto y eventualmente corregirlos, es
bueno detectar estos errores antes de lo detecte el usuario final. De hecho, una prueba es
un éxito cuando se detecta un error.
Caso 1
Entrad Pedido de compra con un monto inferior al primer límite de aprobación
a configurado
Salida El sistema registra el pedido con estatus “aprobado”.

Caso 2
Entrad Pedido de compra con un monto superior al primer límite de aprobación
a configurado.
Salida El sistema coloca el pedido con estado “pendiente de aprobación” y lo
clasifica en la bandeja de entrada del aprobador. El aprobador puede
configurarse en el sistema (usando el nombre de usuario).

Caso 3
Entrad Modificar el límite de aprobación y registrar un pedido de compra con un
a monto inferior al nuevo límite
Salida El sistema registra el pedido con estatus “aprobado”.

Caso 4
Entrad cadena de 5 caracteres
a
Salida La aplicación no permite el ingreso del dato y muestra un mensaje de
error.

Caso 5
Entrad cadena de 7 caracteres, incluyendo uno o más caracteres no alfabéticos
a
Salida La aplicación no permite el ingreso del dato y muestra un mensaje de
error.

Caso 6
Entrad Cadena de 7 caracteres, solo de caracteres alfabéticos.
a
Salida La aplicación permite el ingreso del dato.

Caso 7
Entrad Cadena de 11 caracteres.
a
Salida La aplicación no permite el ingreso del dato y muestra un mensaje de
error.
Caso 8
Entrad Fecha de hoy más un día (Fecha de mañana).
a
Salida No se permite el ingreso de la transacción y se muestra un mensaje de
error.

Caso 9
Entrad Fecha de hoy más un día (Fecha de mañana).
a
Salida No se permite el ingreso de la transacción y se muestra un mensaje de
error.
 Bibliografía

Material de estudio semana 8 IACC.