Informe Final

UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA
FACULTAD DE INGENIERÍA EN INFORMÁTICA Y SISTEMAS
INFORME FINAL DE PRÁCTICAS PRE PROFESIONALES
“INGENIERÍA DE REQUISITOS DEL SISTEMA DE FACTURACIÓN PARA LA EMPRESA

ROUILLON CONSULTING E.I.R.L”
Presentado por : Fátima Pierina ROUILLON SIXTO
Asesor : Ing. Brian PANDO SOTO
Periodo de Prácticas Pre Profesionales : 12/03/2018 – 12/06/2018
Lugar de las Prácticas Pre Profesionales : ROUILLON CONSULTING E.I.R.L.
Tingo María – Perú
2018
DEDICATORIA
Dedicado a Dios y a mi familia,
ya que ellos son las personas
más importantes en mi vida,
en mi formación personal y profesional.

AGRADECIMIENTO
A nuestro señor Jesucristo, por bendecirme y nunca
desampararme, dándome las fuerzas para cumplir mis metas.
A mis padres, María y Rodolfo, por ser mis pilares,
por inculcarme valores en mi vida y por su apoyo incondicional.
A mis hermanos, César y Eleazar, por ser mis guías
y por los ánimos que me dan.
A mi asesor Brian Pando, por orientarme en el

desarrollo de mis practicas pre profesionales.
RESUMEN
Rouillon Consulting E.I.R.L. es una empresa que brinda servicios como pagos online,
consultoría de sistemas, gestión de proyectos, outsourcing e integración entre sistemas.
Actualmente la empresa realiza sus ventas sus productos sin registrarlos y hace sus facturas
de manera manual, lo cual es una desventaja ya que perjudica con respecto al tiempo.
La presente práctica pre profesional tiene como objetivo solucionar este gran problema,
participando en la ingeniería de requisitos teniendo como fases obtención de requisitos,
análisis de requisitos, especificación de requisitos y validación de requisitos para que el
programador pueda construir el sistema de facturación, teniendo en cuenta las buenas
prácticas de SCRUM y SWEBOK.
4
ÍNDICE GENERAL
RESUMEN ........................................................................................................................................... 4
INTRODUCCIÓN ............................................................................................................................... 10
CAPITULO I ....................................................................................................................................... 11
CARACTERÍSTICAS GENERALES DE LA ORGANIZACIÓN .................................................................. 11
1.1. DESCRIPCIÓN ................................................................................................................... 11
1.1.1. Nombre .................................................................................................................... 11
1.1.2. Ubicación ................................................................................................................. 11
1.2. MISIÓN Y VISIÓN ............................................................................................................. 11
1.2.1. Misión ...................................................................................................................... 11
1.2.2. Visión........................................................................................................................ 11
CAPÍTULO II ...................................................................................................................................... 12
MARCO TEÓRICO Y CONCEPTUAL ................................................................................................... 12
2.1. MARCO TEÓRICO ............................................................................................................. 12
2.1.1. Ingeniería de requisitos ........................................................................................... 12
2.1.2. Requisitos funcionales ............................................................................................. 13
2.1.3. Elicitación de requisitos ........................................................................................... 13
2.1.4. Análisis de requisitos ............................................................................................... 15
2.1.5. Especificación de requisitos .................................................................................... 17
2.1.6. Validación de requisitos .......................................................................................... 18
2.1.7. Requisitos no funcionales ....................................................................................... 19
2.1.8. Características de los requisitos .............................................................................. 20
2.2. MARCO CONCEPTUAL...................................................................................................... 20
2.2.1. Requisito del software............................................................................................. 20
2.2.2. Scrum ....................................................................................................................... 21
2.2.3. Swebok ..................................................................................................................... 21
2.2.4. Prototipado .............................................................................................................. 21
CAPITULO III ..................................................................................................................................... 22
DESARROLLO DE ACTIVIDADES ....................................................................................................... 22
3.1. SITUACIÓN ACTUAL ......................................................................................................... 22
3.1.1. Problemática ............................................................................................................ 22
3.2. OBJETIVOS........................................................................................................................ 22
3.2.1. General ..................................................................................................................... 22
5
3.2.2. Específicos ................................................................................................................ 22
3.3. ALCANCE .......................................................................................................................... 23
3.4. JUSTIFICACIÓN ................................................................................................................. 23
3.5. ORGANIZACIÓN DE ACTIVIDADES ................................................................................... 23
3.6. ESCENARIO DE TRABAJO ................................................................................................. 25
3.6.1. Dirección de proyectos ............................................................................................ 25
3.6.2. Equipo de trabajo .................................................................................................... 25
3.6.3. Recursos ................................................................................................................... 26
3.7. MÉTODO DE TRABAJO ..................................................................................................... 27
3.7.1. Enfoque metodológico ............................................................................................ 27
3.7.2. Proceso de ingeniería .............................................................................................. 29
3.8. SPRINT I - OBTENCIÓN DE REQUISITOS........................................................................... 30
3.8.1. Fuentes de los requisitos ......................................................................................... 30
3.8.2. Técnicas de captura de requisitos ........................................................................... 30
3.8.3. Definición de módulos............................................................................................. 32
3.8.4. Identificación de roles de los usuarios .................................................................... 33
3.8.5. Acceso de usuarios por módulo .............................................................................. 33
3.8.6. Usuario líder............................................................................................................. 33
3.9. SPRINT II- MÓDULO USUARIOS ....................................................................................... 34
3.10. SPRINT III- MÓDULO DATOS DE LA EMPRESA ............................................................ 40
3.11. SPRINT IV- MÓDULO PRODUCTOS .............................................................................. 45
3.12. SPRINT V- MÓDULO CLIENTES ..................................................................................... 51
3.12.1. ANÁLISIS DE REQUISITOS ........................................................................................ 51
6
3.13. SPRINT VI- MÓDULO VENTAS ...................................................................................... 55
3.13.1. ANÁLISIS DE REQUISITOS ........................................................................................ 55
3.14. LECCIONES APRENDIDAS ................................................................................................. 60
CONCLUSIONES ................................................................................................................................ 65
RECOMENDACIONES ....................................................................................................................... 66
Bibliografía ....................................................................................................................................... 67
7
ÍNDICE DE FIGURAS
Figura 1: Descomposición de materias para el área de conocimiento requisitos del software ...... 13
Figura 2: Categoría de los Stakeholders ........................................................................................... 14
Figura 3: Proceso para realizar la fase de análisis de requisitos ...................................................... 16
Figura 4: Proceso de especificación de requisitos de software ....................................................... 17
Figura 5: Actividades de validación de requisitos ............................................................................ 18
Figura 6: Tablero Kanban en TFS ...................................................................................................... 28
Figura 7: Entrevista al dueño del producto ...................................................................................... 31
Figura 8: Reunión con el dueño del producto.................................................................................. 31
Figura 9: Proceso Módulo Usuarios ................................................................................................. 36
Figura 10. Proceso del módulo Productos ....................................................................................... 47
Figura 11: Proceso del módulo Clientes........................................................................................... 52
Figura 12: Proceso del módulo Ventas ............................................................................................ 57
Figura 13: Evolución requisitos módulo usuarios ........................................................................... 61
Figura 14: Evolución requisitos módulo datos de la empresa ......................................................... 61
Figura 15: Evolución requisitos módulo productos ......................................................................... 62
Figura 16: Evolución requisitos módulo clientes ............................................................................. 63
Figura 17: Evolución requisitos módulo ventas ............................................................................... 63
8
ÍNDICE DE CUADROS
Cuadro 1: Herramientas y técnicas para análisis de requisitos ....................................................... 16

Cuadro 2: Técnicas de validación de requisitos ............................................................................... 18
Cuadro 3: Organización de actividades............................................................................................ 24
Cuadro 4: Equipo de trabajo ............................................................................................................ 26
Cuadro 5: Iteraciones del Team Developer ..................................................................................... 28
Cuadro 6: Módulos del sistema de facturación ............................................................................... 32
Cuadro 7: Roles de los usuarios ...................................................................................................... 33
Cuadro 8: Usuarios por módulo ....................................................................................................... 33
Cuadro 9: Tabla de requisitos funcionales del módulo Usuarios..................................................... 35
Cuadro 10: Validación módulo Usuarios.......................................................................................... 38
Cuadro 11: Requisito del Módulo Datos de la empresa .................................................................. 43
Cuadro 12: Tabla de requisitos funcionales del módulo Productos ................................................ 46
Cuadro 13: Validación Módulo Productos ....................................................................................... 49
Cuadro 14: Tabla de requisitos funcionales del módulo Clientes .................................................... 51
Cuadro 15: Validación Módulo Clientes........................................................................................... 53
Cuadro 16: Tabla de requisitos funcionales del Módulo Ventas ..................................................... 56
Cuadro 17: Lecciones aprendidas .................................................................................................... 60
9
INTRODUCCIÓN
En la actualidad muchos desarrolladores de software tienen como gran inquietud saber si

lo que están construyendo es lo que el cliente quiere en realidad y si éste tendrá éxito. Por
ello, la ingeniería de requisitos pretende expresar las necesidades del cliente, definir lo que
se va a producir con claridad, especificando sus características de cada requisito y
mostrando un prototipo funcional para mejor entendimiento.
La empresa Rouillon Consulting necesita del sistema de facturación, y solicitaron 3

practicantes para el equipo, un encargado de la ingeniería de requisitos, programador y
tester. Para lo cual en la presente práctica pre profesional se desarrolló la ingeniería de
requisitos.
En el capítulo 1: Describe algunas características de la empresa Rouillon Consulting,

organización donde se desarrolló las prácticas pre profesionales, ya que se encuentra en la
ciudad de Lima, la comunicación constante fue mediante videollamadas y correos.
En el capítulo 2: Se describen el marco teórico y marco conceptual que sirvió para el

entendimiento y desarrollo de la practica pre profesional.
En el capítulo 3: Se explica el desarrollo de actividades realizado durante el periodo de la

práctica pre profesional: Obtención de Requisitos, Análisis de Requisitos, Especificación de
requisitos y Validación de requisitos.
Finalmente se detalla los resultados, conclusiones y anexos.
10
CAPITULO I
CARACTERÍSTICAS GENERALES DE LA ORGANIZACIÓN
1.1. DESCRIPCIÓN
1.1.1. Nombre
ROUILLON CONSULTING E.I.R.L.
1.1.2. Ubicación
Departamento: Lima
Provincia: Lima
Distrito: San Juan de Lurigancho
Dirección: Av. Central Mza. L lote 15 Urb. Los Heraldos
1.2. MISIÓN Y VISIÓN
1.2.1. Misión
Brindar soluciones que cubran las necesidades estratégicas de nuestros

clientes a través de la tecnología de información, involucrándonos desde la concepción del
proyecto, y posterior al proyecto en la operativa diaria a través del soporte y
mantenimiento, trabajando en base a nuestra experiencia y las buenas prácticas de las
metodologías de clase mundial en la gestión de proyectos como en la ingeniería de manera
eficiente y de calidad.
1.2.2. Visión
Ser reconocidos como una de las principales empresas de soluciones de

tecnología de la información en el Perú, y convertirnos en el socio estratégico en
tecnologías de información de las empresas, así como en agentes de cambios disruptivos
en tecnología e innovación.
11
CAPÍTULO II
MARCO TEÓRICO Y CONCEPTUAL
2.1. MARCO TEÓRICO
2.1.1. Ingeniería de requisitos

Los requisitos del software expresan las necesidades y los apremios
colocados en un producto de software que contribuye a la solución de un cierto problema
del mundo real. El término “ingeniería de requisitos” es ampliamente utilizado en el campo
para denotar la dirección sistemática de requisitos. (Abran & W. Moore, 2004)
Un requisito de software es una propiedad que debe ser exhibido para

resolver algún problema en el mundo real. Se refiere a los requisitos en "Software" porque
se ocupa de los problemas que se deben resolver dirigido por el software. (Bourque &
Dupuis, 2004)
La Ingeniería de Requisitos (IR) cumple un papel primordial en el proceso de

producción de software, ya que se enfoca un área fundamental: la definición de lo que se
desea producir. Su principal tarea consiste en la generación de especificaciones correctas
que describan con claridad, sin ambigüedades, en forma consistente y compacta, las
necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los
problemas relacionados por la mala gestión de los requerimientos en el desarrollo de
sistemas. (Chaves, 2005)
La ingeniería de requisitos es en esencia la aplicación de principios, métodos,

técnicas y herramientas con el propósito de descubrir los requisitos de un producto de
software, al igual que el análisis, la documentación de objetivos, funciones y restricciones
de dichos sistemas; sin embargo, existe una falencia, es decir, no hay consenso sobre
lenguajes, métodos o herramientas para su ejecución (De La Cruz Londoño & Castro
Guevara, 2014).
12
Figura 1: Descomposición de materias para el área de conocimiento requisitos del
software
Fuente: (Bourque & Dupuis, 2004)
2.1.2. Requisitos funcionales

Estas son las capacidades de software que deben estar presentes para el
usuario para llevar a cabo la función de los servicios o llevar a cabo un caso de uso. Describir
cómo el producto debe responder anticipadamente a las condiciones de error y entradas
no válidas y acciones. (Cueva, 2014).
2.1.3. Elicitación de requisitos

La elicitación consiste en identificar las fuentes de obtención de requisitos y
luego utilizando técnicas evocar esas fuentes. La captura de requisitos es una actividad
humana intensa que se basa en la participación de los Stakeholders, como fuente principal
de obtención de requisitos. (Cueva, 2014).
13
2.1.3.1. Listar las fuentes de requisitos
Se realiza para identificar fuentes potenciales de documentación

de requisitos y permitir a los analistas, elicitar, revisar, documentar, y verificar información
de requisitos con los Stakeholders. (Cueva, 2014).
2.1.3.2. Categorías de los Stakeholders
Es necesario definir las categorías de los Stakeholders para

entender quienes están interesados o influencian en el proyecto, quienes utilizarán el
producto y sus salidas; y a quien de alguna manera afectaría el producto. (Cueva, 2014).
Figura 2: Categoría de los Stakeholders
Stakeholders
Clientes Usuarios Otros
Patrocinador Product Usuarios Usuarios Consejeros Proveedores

(Sponsor) Champios Directos Indirectos
Fuente: (Wiegers, 2003)
2.1.3.3. Perfil de los Stakeholders
El perfil de los Stakeholders es una descripción que caracteriza a

cada Stakeholder y explica su relación con el proyecto. Es necesario definir el perfil para
entender los intereses, preocupaciones y criterios de éxito del producto para cada
Stakeholder. (Cueva, 2014).
14
Los perfiles de los Stakeholders permiten:
- Educar al equipo acerca de las expectativas del cliente.

- Provee al equipo un alto nivel de entendimiento de las necesidades del usuario.
- Destaca potenciales obstáculos en el proceso de aceptación del producto de software
por parte de los Stakeholders.
2.1.3.4. Identificar técnicas combinadas de elicitación
Técnicas que permiten obtener información relevante a partir de

los Stakeholders, por lo que es importante analizar tales técnicas que la ingeniería de
requisitos considera apropiadas para obtener información.
- Entrevistas con los Stakeholders.

- Talleres.
- Entrevistas a grupos focales.
- Observación.
- Análisis de tareas del usuario.
- Estudio de la documentación existente.
- Encuestas
2.1.4. Análisis de requisitos

El análisis Incluye la descomposición al detalle de requisitos de alto nivel,
la construcción de prototipos, evaluación de viabilidad, y la negociación de prioridades.
(Cueva, 2014)
Para analizar los requisitos:
- Modelo de negocio (Si es necesario)

- Defina el alcance del proyecto
- Crear modelos de requisitos de usuario detallados
- Priorizar las necesidades
15
Figura 3: Proceso para realizar la fase de análisis de requisitos
Análisis de requisitos
Crear
Definir el modelos de
Modelo de Priorizar los
alcance del requisitos de
negocio requisitos
proyecto usuario
detallados
Fuente: (Gottesdiener, 2009)
2.1.4.1. Herramientas y técnicas para analizar requisitos
A continuación, en la tabla se indican las técnicas y herramientas

para analizar requisitos de acuerdo a:
Cuadro 1: Herramientas y técnicas para análisis de requisitos

Cuando necesite: Entonces crear:
Modelar el negocio Combinar entre mapa de relaciones y/o

mapa de procesos
Entender el alcance del proyecto Combinar entre diagramas de contexto, tablas

de evento respuesta y/o políticas de negocio
Adicionar detalle a los requisitos de usuario Combinar o variación de tabla de actores,

casos de uso, mapas de dialogo, modelo de
datos, diagramas de estado y/o reglas de
negocio
Negociar la importancia entre los requisitos Priorizar requisitos
16
2.1.5. Especificación de requisitos
La Especificación de Requisitos de Software (ERS) es también llamada una
especificación funcional, la especificación de un producto, el documento de requisitos, o la
especificación del sistema, sin embargo, las organizaciones no utilizan estos términos de la
misma manera.
La ERS es la base para la planificación del proyecto, diseño y codificación,

así como la base para las pruebas del sistema y la documentación de usuario. (Cueva, 2014).
2.1.5.1. Proceso de la especificación de requisitos
a) Documentar requisitos
Documentar los requisitos donde se describirá las características y

comportamiento del sistema.
b) Verificar las necesidades
Los Stakeholders deben comprobar que los requisitos estén completos,

consistentes y de alta calidad. Revisar la documentación según sea
necesario.
Figura 4: Proceso de especificación de requisitos de software
Especificaciones de requisitos
Documentar los Verificar las Documentar los Verificar los

Validar
requisitos de necesidades del requisitos de requisitos de
usuario usuario software software
Validar
17
2.1.6. Validación de requisitos
Se entiende como validación de los requisitos al proceso de comprobación
de que estos requisitos fueron especificados de acuerdo a las necesidades de los clientes.
(Cueva, 2014)
Figura 5: Actividades de validación de requisitos
Documentar Verificar las Documentar Verificar los

los requisitos necesidades los requisitos requisitos de
de usuario del usuario de software software
Actividades de
Desarrollo de
requisitos
a) Seleccionar e integrar la técnica de validación de requisitos

b) Asegurar la participación adecuada de usuario
c) Validar los requisitos
d) Revisar la documentación de requisitos
Cuadro 2: Técnicas de validación de requisitos
Cuando Ud. necesite Se debe realizar
Revisión de pares Revisar requisitos
Documentar requisitos
Crear pruebas de validación Pruebas de aceptación de usuario
Pruebas sobre modelos de requisitos Valide los modelos
Mostrar partes del sistema Prototipos Operacionales
18
- Revisión de pares
La revisión por pares es la formación de un grupo de partes interesadas

para evaluar la documentación de los requisitos o de los modelos con el fin de
encontrar errores y mejorar la calidad de los mismos.
- Crear pruebas de validación
Las pruebas de aceptación de los usuarios se los denomina también como

criterios de aceptación, pruebas de aceptación, pruebas de usuario final o
pruebas funcionales; las mismas que constituyen casos específicos de
prueba que los usuarios utilizan para decidir si aceptan la entrega de un
sistema.
- Validar los modelos
La validación del modelo utiliza simulaciones de pruebas en lugar de casos de

prueba real para pasar por múltiples modelos de análisis que permitan
descubrir la falta de información y corregir errores de documentación.
- Prototipos operacionales
Los prototipos sirven para demostrar cómo una parte del software funcionará
una vez que esté en desarrollo, para demostrar si los requisitos satisfacen a
los clientes, y para validar los requisitos de interfaz externa.
2.1.7. Requisitos no funcionales
Los requisitos no funcionales son propiedades que el producto debe tener

lo que no puede ser evidente al usuario, incluyendo atributos de calidad, coacciones, e
interfaces externos. (Gottesdiener, 2009).
19
2.1.8. Características de los requisitos
Los requisitos permiten que los desarrolladores expliquen cómo han

entendido lo que el cliente pretende del sistema. También, indican a los diseñadores qué
funcionalidad y que características va a tener el sistema resultante. Y, además, indican al
equipo de pruebas qué demostraciones llevar a cabo para convencer al cliente de que el
sistema que se le entrega es lo que solicitó: (Fuentes, 2011).
- Deben ser correctos. Tanto el cliente como el desarrollador deben revisarlos

para asegurar que no tienen errores.
- Deben ser consistentes. Dos requerimientos son inconsistentes cuando es
imposible satisfacerlos simultáneamente.
- Deben estar completos. El conjunto de requisitos está completo si todos los
estados posibles, cambios de estado, entradas, productos y restricciones
están descritos en alguno de los requisitos.
- Deben ser realistas. Todos los requisitos deben ser revisados para asegurar
que son posibles.
- ¿Cada requisito describe algo que es necesario para el cliente? Los requisitos
deben ser revisados para conservar sólo aquellos que inciden directamente
en la resolución del problema del cliente.
- Deben ser verificables. Se deben poder preparar pruebas que demuestren que
se han cumplido los requisitos.
- Deben ser rastreables. ¿Se puede rastrear cada función del sistema hasta el
conjunto de requisitos que la establece?
2.2. MARCO CONCEPTUAL
2.2.1. Requisito del software
Un requisito del software es una característica que debe exhibir para

solucionar cierto problema del mundo real. Por lo tanto, un requisito del software es una
20
característica que se debe exhibir por el software desarrollado o adaptado para solucionar
un problema particular. (Bourque & Dupuis, 2004)
2.2.2. Scrum
Scrum es un marco de trabajo de procesos que ha sido usado para
gestionar el desarrollo de productos complejos desde principios de los años 90. Scrum no
es un proceso o una técnica para construir productos; en lugar de eso, es un marco de
trabajo dentro del cual se pueden emplear varias técnicas y procesos. Scrum muestra la
eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo, de
modo que podamos mejorar. (Schwaber, 2013).
2.2.3. Swebok
Es una guía al conocimiento en el área de la Ingeniería del Software. Su
propósito es describir que parte del cuerpo de conocimiento es generalmente aceptada,
organizar esa parte y proporcionar acceso a los temas de interés. (Bourque & Dupuis, 2004).
2.2.4. Prototipado
Prototipar es comúnmente el medio para validar la interpretación del

ingeniero de software de los requisitos del software, así como para sacar nuevos requisitos.
(Bourque & Dupuis, 2004).
21
CAPITULO III
DESARROLLO DE ACTIVIDADES
3.1. SITUACIÓN ACTUAL
3.1.1. Problemática
En la actualidad la tecnología está avanzando, y uno de los objetivos es
facilitarnos algunos aspectos de nuestras vidas, entre ellas reducir nuestro tiempo en
realizar alguna acción.
En la empresa Rouillon Consulting E.I.R.L. realizan ventas de productos/

servicios, para ello hacen sus reportes y facturas de manera manual. Esto es un problema
porque ocupa aproximadamente 1 hora y media en realizar este proceso y le da más trabajo
al personal.
3.2. OBJETIVOS
3.2.1. General
Determinar y gestionar los requisitos para el desarrollo de un sistema de

facturación para la empresa Rouillon Consulting E.I.R.L.
3.2.2. Específicos
- Conocer el funcionamiento del negocio a grandes rasgos.

- Obtener los requisitos de cada módulo del sistema facturador.
- Analizar lo requisitos de cada módulo del sistema facturador.
- Especificar los requisitos de cada módulo del sistema facturador.
- Validar los requisitos de cada módulo del sistema facturador.
- Coordinar con el equipo de desarrollo y el cliente.
22
3.3. ALCANCE
El alcance es la obtención, análisis, especificación y validación de los requisitos por

módulo del sistema de facturación, así como la determinación y gestión de estos.
Los módulos del software a construir son:
- Módulo Usuarios
- Módulo Datos de la Empresa
- Módulo Productos
- Módulo Clientes
- Módulo Ventas
3.4. JUSTIFICACIÓN
La empresa no cuenta con un sistema que le ayude a registrar sus ventas y realizan
sus facturas a mano, entonces la presente práctica pre profesional busca apoyar en el
proceso de la construcción del sistema de facturación para que se ayude en la gestión de
las ventas de la empresa, y agilizar la generación de las facturas.
3.5. ORGANIZACIÓN DE ACTIVIDADES
Para organizar los requisitos se realizaron las siguientes actividades:
23
Cuadro 3: Organización de actividades
SPRINTS ACTIVIDADES FECHA

Obtención - Entrevistas 12/03/18
de - Determinar módulos del sistema
Requisitos - Asignar usuarios por módulo
- Clasificación de requisitos 26/03/18
- Elaboración de procesos por módulo
Análisis de
- Elaboración de casos de uso por módulo
Requisitos - Elaboración de documento de
Módulo arquitectura de software
Usuarios Especificación - Elaboración de documento de 30/03/18

de Requisitos especificación de requisitos
Validación de - Elaboración de prototipos funcionales 04/04/18

Requisitos
Análisis de - Elaboración de procesos por módulo
Módulo Requisitos
- Elaboración de documento de
Datos de arquitectura de software
la Especificación - Elaboración de documento de 12/04/18
especificación de requisitos
empresa de Requisitos
Validación de - Elaboración de prototipos funcionales 13/04/18
Requisitos
Requisitos
arquitectura de software
Módulo - Elaboración de documento de 20/04/18
Especificación
Productos especificación de requisitos
de requisitos
- Elaboración de prototipos funcionales 25/04/18

Validación de
requisitos
24
Requisitos
Módulo - Elaboración de documento de 04/05/18
Especificación
Clientes especificación de requisitos
de Requisitos

Validación de
Requisitos

Requisitos
Módulo
Especificación - Elaboración de documento de 24/05/18
Ventas
especificación de requisitos
de Requisitos

Validación de
Requisitos
Fuente. Elaboración Propia
3.6. ESCENARIO DE TRABAJO
3.6.1. Dirección de proyectos
El jefe del proyecto es el gerente de la empresa Rouillon Consulting E.I.R.L.:

César Elías Rouillon Sixto.
3.6.2. Equipo de trabajo
El Scrum master también es parte del Team Developer. A continuación, se

muestra los miembros del equipo:
25
Cuadro 4: Equipo de trabajo
Analista de requisitos
Nombre Fátima Pierina Rouillon Sixto
Categoría profesional Estudiante de ingeniería en informática
y sistemas – Practicante
Contacto fatima.rouillon@unas.edu.pe
Programador de software
Nombre Aldair Albenis Vasquez Rubio
Contacto aldair.vasquez@unas.edu.pe
Tester de software
Nombre Naira Miriam Masgo Villanueva
Contacto naira.masgo@unas.edu.pe
Fuente. Elaboración Propia
3.6.3. Recursos
Durante el periodo de la prácticas pre-profesional, para la realización de las
actividades, se usaron las herramientas:
a) Herramientas de software.
• Hangouts: Hangouts es una aplicación de mensajería multiplataforma

desarrollada por Google, que se usó con los miembros del equipo para
realizar las reuniones mediante videollamadas.
• Team Foundation Service. Administración del ciclo de vida de las
aplicaciones de software, administra las tareas y actividades del proceso
Scrum y realizando el seguimiento de las tareas asignadas.
• Balsamiq Mockups 3. Es una herramienta para Windows y Linux, que
facilita y agiliza la creación de bocetos. Se usó para realizar los prototipos
funcionales de los requisitos, para mostrar al cliente y éste pueda
validarlo antes de su construcción.
26
• Microsoft Word 2016. Este software es usado para el procesamiento de
textos, es una herramienta de suma importancia que se usó para la
documentación de la presente practica pre profesional, y otros
documentos.
• Power Point 2016. Este software es usado para la comunicación entre
personas, organización y grupos de trabajo; esta herramienta se usó para
realizar las presentaciones con el Stakeholder.
• Excel 2016: Este software es usado para utilizarla en tareas financieras y
contables, con fórmulas, gráficos y un lenguaje de programación. Y se usó
para realizar los gráficos de los cambios que hubo durante el tiempo, en
los requisitos.
• Enterprise Architect. es una herramienta de modelado y diseño visual
basada en UML . La plataforma admite: el diseño y la construcción de
sistemas de software; modelar procesos comerciales; y modelado de
dominios basados en la industria.
• Bizagi Modeler. Es una herramienta se usó con el objetivo de plasmar los
procesos del sistema por módulo.
3.7. MÉTODO DE TRABAJO
3.7.1. Enfoque metodológico
El proyecto de sistema de facturación, fue desarrollado basado en el marco

de las buenas prácticas de Scrum. Se asignaron las tareas a cada miembro del equipo de
desarrollo, en el cual, en las reuniones se vieron su cumplimiento, también las tareas que
se hacen y las que se harán.
Esas reuniones se llaman Daily Scrum, que tiene como objetivo hacer
seguimiento a los procesos que tuvimos dentro del Sprint, se usó Team Foundation Service,
el modelo Kanban, donde se organizó las tareas.
Así mismo, se estimó el tiempo total para desarrollar la etapa de análisis de
requisitos, construcción del sistema y las pruebas del sistema.
27
Figura 6: Tablero Kanban en TFS
Fuente. Elaboración propia
Los Sprints se dividieron de forma que cada miembro pueda realizar sus
tareas de forma organizada por módulos del sistema de facturación. Los Sprints son las
siguientes:
Cuadro 5: Iteraciones del Team Developer
SPRINTS DESCRIPCION
I Sprint Obtención de requisitos
II Sprint Módulo Usuarios
III Sprint Módulo Datos de la empresa
IV Sprint Módulo Productos
V Sprint Módulo Clientes
VI Sprint Módulo Ventas
Fuente. Elaboración propia
28
3.7.2. Proceso de ingeniería
El proceso de ingeniería de requisitos se basó según lo mencionado en el

marco teórico de la siguiente manera:
3.7.2.1. Obtención de requisitos
En la figura 2 se presenta la categoría de los Stakeholders que no

todas fueran necesarias identificarlas, según la presencia de los que pertenecen en la
empresa. Se identificaron al Cliente-Patrocinador y a los Usuarios-Directos.
Y en cuanto a las técnicas sólo se usaron las entrevistas mediante

Hangouts.
3.7.2.2. Análisis de requisitos
En esta fase se usaron todo lo descrito en el marco teórico.
3.7.2.3. Especificación de requisitos
En esta fase se usaron todo lo descrito en el marco teórico.
3.7.2.4. Validación de requisitos
En el cuadro 2, se presenta las técnicas mostrándose que para

este proyecto no eran necesarias aplicarse todas, sino las más idóneas según la necesidad
y criterios del equipo de trabajo. Para ello se usaron los prototipos operacionales.
29
3.8. SPRINT I - OBTENCIÓN DE REQUISITOS
3.8.1. Fuentes de los requisitos
La fuente principal para obtener los requisitos fueron las reuniones

constantes que se tuvo con el usuario líder, éste es el usuario principal que tendrá acceso
a todo el sistema, y es dueño del producto.
Estas reuniones permiten estar en constante comunicación con el

Stakeholder para verificar si los requisitos que se están documentando están correctos.
3.8.2. Técnicas de captura de requisitos
a) Entrevistas
Se realizaron 2 entrevistas la primera semana con el gerente de la empresa,

mediante hangouts, esto sirvió para conocer los objetivos del sistema que
requiere y obtener los requisitos generales.
Se preguntó:
- ¿Cuáles son los objetivos de la empresa?

- ¿Quiénes integran la empresa y cuáles son sus roles?
- ¿Cuál es el problema que quiere dar solución?
- ¿Qué características generales requiere para el sistema?
- ¿Qué campos requiere para cada módulo?
30
Figura 7: Entrevista al dueño del producto
Fuente: Screenshot de la videollamada realizada por Hangouts
b) Reuniones
Al haber capturado los primeros requisitos generales, se fue
documentando, y mediante las reuniones constantes por Hangouts se
verifican o refinan las ideas de los requisitos por módulo.
Figura 8: Reunión con el dueño del producto
Fuente: Screenshot de la videollamada realizada por Hangouts
31
3.8.3. Definición de módulos
Luego de las entrevistas realizadas se decidió organizar el sistema de

facturación por módulos:
Cuadro 6: Módulos del sistema de facturación
Módulos Descripción
Módulo Usuarios Este módulo tiene como objetivo, dar acceso a los
usuarios al sistema, indicando sus roles para que se
pueda aplicar privilegios a estos.
Módulo Datos de la empresa Este módulo tiene como objetivo tener registrado la
información de la empresa, y estar actualizándolo.
Módulo Productos Este módulo tiene como objetivo tener el listado de

productos, con su información respectiva y así, se
pueda dar a conocer que productos ofrece la empresa.
Y, al momento de realizar la venta se busque al
producto que el cliente comprará.
Módulo Clientes Este módulo tiene como objetivo tener el listado de los
clientes de la empresa, con sus datos
correspondientes. Esto es necesario para que, al
momento de realizar ventas, el administrador busque
al cliente que venderá un producto.
Módulo Ventas Este módulo es el principal del sistema, porque se

realiza la función de la empresa que es realizar las
ventas de sus productos/ servicios, y generar facturas,
dando la opción de imprimirlas.
Fuente: Elaboración propia
32
3.8.4. Identificación de roles de los usuarios
Se identificaron 3 roles, cada uno con funciones distintas, los roles permiten
dar restricciones al acceso del sistema. Los roles que tendrán los usuarios son los siguientes:
Cuadro 7: Roles de los usuarios
Roles Función
Administrador Será el gerente de la empresa y tendrá acceso a todas las

funcionalidades del sistema.
Operador Será el jefe de operaciones de la empresa y tendrá la

funcionalidad de crear, editar, exportar clientes y
productos, y realizar las ventas.
Consultor Tendrá la función de visualizar clientes y producto.
3.8.5. Acceso de usuarios por módulo
Cuadro 8: Usuarios por módulo
Módulos Responsables
Módulo Usuarios Administrador
Módulo Datos de la empresa Administrador
Módulo Productos Administrador, Consultor, Operador
Módulo Clientes Administrador, Consultor, Operador
Módulo Ventas Administrador, Operador
3.8.6. Usuario líder

El usuario líder, que guio el proceso de la ingeniería de la ingeniería de
requisitos en cada proceso (obtención, análisis, especificación y validación)
fue:
• Gerente de la empresa: Ing. César Elías Rouillon Sixto
33
3.9. SPRINT II- MÓDULO USUARIOS
El módulo sirve para administrar los accesos al sistema según roles, esta capacidad
la tendría el administrador del sistema, las reuniones permitieron llegar a determinar con
exactitud los accesos que debía tener cada rol.
Para el análisis del módulo Usuarios, se clasificaron los requisitos, se modeló

con el objetivo de entender el proceso y se ilustró de forma arquitectónica.
3.9.1.1. Clasificación de los requisitos
En el Módulo Usuarios, los requisitos, se clasificaron en:

- Requisitos funcionales
- Requisitos no funcionales: se encuentran en el Anexo 2.
Documento especificación de requisitos según el estándar
IEEE 830 – 98.
- La prioridad del requisito
Se identificaron los Requisitos funcionales y no funcionales,

indicando su prioridad a cada uno de ellos, de acuerdo al grado de impacto que causa en
el sistema.
34
Cuadro 9: Tabla de requisitos funcionales del módulo Usuarios
MODULO CODIGO REQUISITOS PRIORIDAD

FUNCIONALES
RFAD1. Registrar usuarios Alta
RFAD2. Actualizar lista de Media

usuarios
RFAD3. Listar usuarios Alta
USUARIOS RFAD4. Buscar usuario por filtro Media
RFAD5. Editar usuarios Alta
RFAD6. Eliminar usuarios Alta
RFAD7. Registrar tipo de rol Media
RFAD8. Editar tipo de rol Media
RFAD9. Eliminar tipo de rol Media
RFADOPCO10. Iniciar sesión de usuario Alta
RFADOPCO11. Verificar tipo de usuario Alta
RFADOPCO12. Recordar contraseña Alta
RFADOPCO13. Cambiar contraseña Alta
3.9.1.2. Modelo conceptual
El desarrollo del modelo del sistema es clave para el análisis de

requisitos, para entender el proceso que se debe realizar por módulo y para modelar cada
módulo del sistema, se desarrolló diagrama de procesos con el software Bizagi Modeler v.
3.1. El proceso del Módulo Usuario es el siguiente:
35
Figura 9: Proceso Módulo Usuarios
3.9.1.3. Asignación arquitectónica del diseño y de los requisitos

Teniendo en claro los procesos que se debe realizar en cada
módulo, se realizó el diseño arquitectónico ilustrando los requisitos en el software
Enterprise Architect, se encuentra en el Anexo 1. Documento de arquitectura de software
según el estándar IEEE 1471 – 2000.
36
En este proceso de la ingeniería de requisitos, se refiere al documento en

producción, es decir se verifican los requisitos y se registran en un documento a detalle.
En esta fase se realizó la Especificación de requisitos del software, tiene

como objetivo de que el Stakeholder pueda revisar y mostrar conformidad, y se encuentra
en el Anexo 2. Documento especificación de requisitos según el estándar IEEE 830 – 98.
Para la validación de requisitos es importante verificar la conformidad del

Stakeholder por cada documento, y se aseguró de que el software se está definiendo
correctamente mediante:
En esta fase se usó el prototipado, se realizó de los 13 requisitos funcionales

del Sprint I – Módulo Usuarios. A continuación, se presenta un ejemplo del prototipado del
Requisito funcional Registrar usuarios. Los demás requisitos funcionales están en el Anexo
3. Validación de requisitos funcionales:
37
Cuadro 10: Validación módulo Usuarios
RFAD1. REGISTRAR USUARIOS
Objetivo:
Dar acceso a usuarios, registrando sus roles y de acuerdo a eso, tengan privilegios en
el acceso del sistema. Y al registrar los usuarios se contará con el listado de ellos.
Descripción:
El sistema debe ser capaz de registrar y guardar a los usuarios, para tener la lista de
quiénes tienen acceso al sistema y sus roles, al mismo tiempo se debe enviar el correo
al usuario con su username y contraseña para que pueda acceder al sistema.
Los campos a registrar son:
- Nombre: Debe permitir ingresar 50 caracteres.

- Apellido: Debe permitir ingresar 50 caracteres.
- Correo: Debe permitir ingresar 50 caracteres.
- Rol: Están registrados en un combo box, debe permitir seleccionar uno de ellos.
- Username: Debe permitir ingresar sólo hasta 30 caracteres.
- Contraseña: Debe permitir ingresar sólo hasta 30 caracteres.
- Estado: Sólo puede ser “Activo” o “Inactivo”.
Al registrar debe salir un mensaje confirmando que se guardó el usuario:
Este rol lo realiza sólo el administrador.
Prioridad:
Alta
Prototipo:
A continuación, se visualiza la pantalla donde se llena los campos requeridos y dar clic
en el botón “Registrar” para que se guarde el usuario, y así mismo, enviar el correo a
este con sus credenciales de acceso al sistema.
38
Ahora se visualiza la ventana que muestra el mensaje confirmando que el usuario se guardó:
Fuente: Elaboración Propia
39
3.10. SPRINT III- MÓDULO DATOS DE LA EMPRESA
En este módulo, se recaudó pocos requisitos, ya tiene como objetivo sólo registrar
los datos importantes de la empresa.
En el Módulo Datos de la Empresa, los requisitos, se clasificaron

en:
IEEE 830 – 98.

el sistema.
Cuadro 8. Tabla de requisitos funcionales del Módulo Datos de la Empresa
MODULO CODIGO REQUERIMIENTOS PRIORIDAD

FUNCIONALES
RFAD14. Registrar datos de la Alta

empresa
RFAD15. Editar datos de la Alta

USUARIOS
empresa
RFAD16. Visualizar datos de la Media

empresa
40
Para entender el proceso que se debe realizar en el módulo

Datos de la empresa, se desarrolló diagrama de procesos con el software Bizagi Modeler v.
3.1.
Fig 11. Proceso del módulo Datos de la Empresa
Teniendo en claro el proceso que se debe realizar en el módulo

Datos de la empresa, se realizó el diseño arquitectónico ilustrando los requisitos en el
software Enterprise Architect, se encuentra en el Anexo 1. Documento de arquitectura de
software según el estándar IEEE 1471 – 2000.
41

En esta fase se realizó el prototipado se realizó de los 3 requisitos

funcionales del Sprint III – Módulo Datos de la Empresa. A continuación, se presenta un
ejemplo del prototipado del Requisito funcional Registrar Datos de la empresa. Los demás
requisitos funcionales están en el Anexo 3. Validación de requisitos funcionales.
42
Cuadro 11: Requisito del Módulo Datos de la empresa
RFAD16. REGISTRAR DATOS DE LA EMPRESA
Objetivo:
Identificar la información de la empresa que se podrá brindar a los clientes.
Descripción:
El sistema debe ser capaz que el administrador registre los datos principales de la
empresa, al guardar, los campos se deben bloquear.
Los datos de la empresa que se registran son:
- Razón social: Debe permitir ingresar hasta 50 caracteres.

- RUC: Debe permitir ingresar ni más ni menos de 11 números.
- Titular: Debe permitir ingresar hasta 50 caracteres
- Contactos: Debe permitir ingresar hasta 50 caracteres.
- Domicilio fiscal: Debe permitir ingresar hasta 200 caracteres
- Correo: Debe permitir ingresar hasta 50 caracteres.
- Persona contacto: Debe permitir ingresar hasta 50 caracteres.
- Cargo: Debe permitir ingresar hasta 50 caracteres.
- Correo contacto: Debe permitir ingresar hasta 50 caracteres.
- Teléfono: Debe permitir ingresar sólo números y hasta 20 caracteres.
Si existe algún campo vacío, no debe guardarse y debe dar aviso que falta llenar
campos.
Prioridad:
Alta
Prototipo:
A continuación, se visualiza la pantalla donde se llena los datos de la empresa.
43
Al dar en guardar, muestra un mensaje de que la información fue guardada:
44
3.11. SPRINT IV- MÓDULO PRODUCTOS
Este módulo tiene como objetivo registrar los productos y servicios que vende la
empresa, y listarlos, así como editar o eliminar.
En el Módulo Productos los requisitos, se clasificaron en:

IEEE 830 – 98.

el sistema.
45
Cuadro 12: Tabla de requisitos funcionales del módulo Productos

FUNCIONALES
RFADOP17. Registrar productos Alta
RFADOPCO18. Actualizar lista de Media

productos
RFADOPCO19. Listar productos Alta
RFADOPCO20. Buscar producto por filtro Media
PRODUCTOS RFADOP21. Editar productos Alta
RFAD22. Eliminar productos Alta
RFADOP23. Registrar tipo de producto Media
RFADOP24. Editar tipo de producto Media
RFAD25. Eliminar tipo de producto Media
RFADOP26. Exportar lista de Alta

productos

Productos, se desarrolló diagrama de procesos con el software Bizagi Modeler v. 3.1.
46
Figura 10. Proceso del módulo Productos

Productos, se realizó el diseño arquitectónico ilustrando los requisitos en el software
47


3.11.3.1. Prototipado:
El prototipado se realizó de los 10 requisitos funcionales del

Sprint IV – Productos. A continuación, se presenta un ejemplo del prototipado del Requisito
funcional Registrar Productos. Los demás requisitos funcionales están en el Anexo 3.
Validación de requisitos funcionales.
48
Cuadro 13: Validación Módulo Productos
RFAD16. REGISTRAR PRODUCTOS
Objetivo:
Contar con el listado de productos que ofrece la empresa.
Descripción:
El sistema debe ser capaz de registrar y guardar los productos que ofrece la empresa,
para poder contar con el listado de su información.
Entre los datos que se pide son:
- Código de producto: Debe permitir ingresar hasta 50 caracteres.

- Nombre del producto: Debe permitir ingresar hasta 200 caracteres.
- Tipo de producto: De permitir
- Descripción: Debe permitir ingresar hasta 300 caracteres.
- Stock: Debe permitir ingresar sólo enteros.
- Estado: Debe permitir ingresar hasta 50 caracteres.
- Costo: debe permitir ingresar números decimales
- Precio: debe permitir ingresar números decimales
- Tipo de moneda: Debe permitir ingresar hasta 200 caracteres.
campos.
Este rol lo realizan el administrador y operador.
Prioridad:
Alta
Prototipo:
A continuación, se visualiza la ventana donde se registrarán y guardarán los productos.
Para añadir el producto también hay una opción, que redireccionará al registro de
productos:
49
Al guardar el producto salió un mensaje confirmando que el producto fue guardado:
50
3.12. SPRINT V- MÓDULO CLIENTES
Este módulo tiene como objetivo registrar a los clientes de la empresa y listarlos,
así como editar o eliminar.
3.12.1. ANÁLISIS DE REQUISITOS
En el Módulo Clientes los requisitos, se clasificaron en:

- Requisitos no funcionales: Anexo 2. Documento
especificación de requisitos según el estándar IEEE 830 –
98.
el sistema.
Cuadro 14: Tabla de requisitos funcionales del módulo Clientes
MODULO CODIGO REQUERIMIENTOS FUNCIONALES PRIORIDAD
RFADOP27. Registrar clientes Alta
RFADOPCO28. Actualizar lista de clientes Media
RFADOPCO29. Visualizar clientes Alta
RFADOPCO30. Buscar cliente por filtro Media
RFADOP31. Editar cliente Alta

CLIENTES
RFAD32. Eliminar cliente Alta
RFADOP33. Exportar listado de clientes Alta
51

Clientes, se desarrolló diagrama de procesos con el software Bizagi Modeler v. 3.1.
Figura 11: Proceso del módulo Clientes

Clientes, se realizó el diseño arquitectónico ilustrando los requisitos en el software
52


En esta fase se realizó el prototipado, contando con 7 requisitos funcionales

del Sprint V – Clientes. A continuación, se presenta un ejemplo del prototipado del
Requisito funcional Registrar Clientes. Los demás requisitos funcionales están en el Anexo
3. Validación de requisitos funcionales.
Cuadro 15: Validación Módulo Clientes
RFADOP27. REGISTRAR DE CLIENTES
Objetivo:
Contar con el listado de clientes que compraron productos/servicios de la empresa.
Descripción:
El sistema debe ser capaz de registrar y guardar los clientes de la empresa, para poder
contar con el listado de su información.
Así cuando se realiza las ventas, se elige a que cliente se le venderá el producto o
servicio, en caso sea cliente nuevo, registrarlo.
Los datos a registrar son:

- Ruc: Debe permitir ingresar ni menos, ni más de 11 números.
- Titular: Debe permitir ingresar hasta 50 caracteres.
- Domicilio Fiscal: Debe permitir ingresa sólo 100 caracteres.
53
- Rubro: Debe permitir ingresar hasta 50 caracteres
- Persona contacto Debe permitir ingresar hasta 50 caracteres
- Cargo: Debe permitir ingresar hasta 50 caracteres
- Correo contacto: Debe permitir ingresar hasta 50 caracteres
- Teléfono: Debe permitir ingresar hasta 20 números
campos.
Prioridad:
Alta
Prototipo:
A continuación, se visualiza la ventana donde se registra a los clientes:
54
3.13. SPRINT VI- MÓDULO VENTAS
El esfuerzo en esta fase consiste en velar por que el programador construya el

software teniendo bien el claro los requisitos, para llegar a ese fin se realizaban
exposiciones y discusiones con el equipo, para asegurar en entendimiento de estos según
lo solicitado por el usuario.
Este módulo es el corazón del sistema de facturación, ya que aquí se registran las
ventas realizadas y se generan las facturas.
3.13.1. ANÁLISIS DE REQUISITOS

En el Módulo Ventas los requisitos, se clasificaron en:

- Requisitos no funcionales: Anexo 2. Documento
especificación de requisitos según el estándar IEEE 830 –
98.

el sistema.
55
Cuadro 16: Tabla de requisitos funcionales del Módulo Ventas

FUNCIONALES
RFADOP34. Realizar venta Alta
RFADOP35. Buscar producto Alta
RFADOP36. Revisar stock de producto Alta
RFADOP37. Seleccionar producto Alta
RFADOP38. Buscar cliente Alta
RFADOP39. Seleccionar cliente Alta
RFADOP40. Confirmar la venta Alta
RFADOP41. Registrar pagos Alta
RFADOP42. Registrar estado de pago Alta
RFADOP43. Registrar fecha de venta Alta
RFADOP44. Listar ventas Alta
RFADOP45. Editar las ventas Alta
RFADOP46. Exportar reporte de las ventas Alta
VENTA RFADOP47. Generar factura Alta
RFADOP48. Registrar factura Alta
RFADOP49. Imprimir factura Alta
RFADOP50. Enviar factura al correo del Alta

cliente
RFADOP51. Registrar tipo de moneda Alta
RFADOP52. Editar tipo de moneda Alta
RFADOP53. Eliminar tipo de moneda Alta

56

Ventas, se desarrolló diagrama de procesos con el software Bizagi Modeler v. 3.1.
Figura 12: Proceso del módulo Ventas

Ventas, se realizó el diseño arquitectónico ilustrando los requisitos en el software
57


En esta fase se realizó el prototipado, se contó de los 20 requisitos funcionales

del Sprint VI – Ventas. A continuación, se presenta un ejemplo del prototipado del Requisito
funcional Realizar Venta. Los demás requisitos funcionales están en el Anexo 3. Validación
de requisitos funcionales.
RFADOP27. REGISTRAR VENTAS
Objetivo:
Registrar las ventas realizadas para contar el reporte de estas.
Descripción:
El sistema debe ser capaz de registrar las ventas para tener el listado de los productos
que se vendieron y qué cliente lo compró.
Los datos que se registran son:

- Código de venta: De permitir ingresar hasta 50 caracteres.
- Fecha de venta: Debe permitir ingresar datos de tipo DATE.
- Producto: Debe permitir ingresar hasta 100 caracteres.
- Cantidad: Debe permitir ingresar sólo números.
- Cliente: Debe permitir ingresar hasta 100 caracteres.
- Monto total: Debe permitir ingresar sólo números.
- Pago: Debe permitir ingresa sólo números.
- Estado de pago: Debe permitir ingresar 50 caracteres.
campos.
58
Prioridad:
Alta
Prototipo:
A continuación, se visualiza la ventana donde se realizan las ventas:
59
3.14. LECCIONES APRENDIDAS
El desarrollo de los Sprint con el equipo no se pudo realizar según lo planeado, se

tuvo que trabajar de forma paralela con la encarga de realizar pruebas.
A continuación, se describe como como se planeó organizar los Sprint y como sucedió:
Cuadro 17: Lecciones aprendidas
PLAN REAL
Sprint 1 Sprint 1 Sprint 5
Sprint 2 Sprint 2 Sprint 6
Sprint 3 Sprint 3
Sprint 4
Sprint 4
Sprint 5
Sprint 6
También se vio la evolución de los requisitos por módulo, que es de suma importancia
contar con esta información para poder estimar el tiempo de la búsqueda de requisitos y
que cantidad de cambios hubo:
3.14.1. Módulo usuarios
A continuación, se visualiza la evolución de la cantidad de requisitos del

módulo usuarios, se comenzó con 7 requisitos funcionales y terminó con 13 requisitos
funcionales.:
60
Figura 13: Evolución requisitos del módulo usuarios
Módulo usuarios
25
20
15 15
14
13 13 13 13
12 12
10 10
7
5
0
M1V1 M1V2 M1V3 M1V4 M1V5 M1V6 M1V7 M1V8 M1V9 M1V10
3.14.2. Módulo datos de la empresa

A continuación, se visualiza la cantidad de requisitos del módulo datos de la
empresa, ya que es un módulo con pocas características en las 10 versiones se contó con 3
requisitos:
Figura 14: Evolución requisitos módulo datos de la empresa
Módulo datos de la empresa

25
20
15
10
5
3 3 3 3 3 3 3 3 3 3
0
61
3.14.3. Módulo productos
módulo productos, se comenzó con 6 requisitos funcionales y terminó con 10 requisitos
funcionales.:
Figura 15: Evolución requisitos módulo productos
Módulo productos
25
20
15
11
10 10 10
9 9
8 8 8
6 6
5
0
3.14.4. Módulo Clientes

módulo clientes, se comenzó con 4 requisitos funcionales y terminó con 7 requisitos
funcionales.:
62
Figura 16: Evolución requisitos módulo clientes
Módulo clientes
25
20
15
10
8 8 8
7 7
6 6
5 5 5
4
0
3.14.5. MÓDULO VENTAS

módulo ventas, se comenzó con 9 requisitos funcionales y terminó con 20 requisitos
funcionales.:
Figura 17: Evolución requisitos módulo ventas
Módulo ventas
25
20 20 20
17
15 15 15
14 14
13
10
9
8
0
63
En conclusión,
La evolución de los requisitos cambia durante el tiempo por muchas razones, pueden
aumentar los requisitos porque el cliente agrega más características al sistema o pueden
disminuir los requisitos porque el cliente los quita. A continuación, se muestra los gráficos
con la evolución de requisitos por módulo:
Módulo usuarios Módulo datos de la empresa

25 25
20 20
15 14 15 15
12 12 13 13 13 13
10 10 10
7
5 5
3 3 3 3 3 3 3 3 3 3
0 0
Módulo productos Módulo clientes

25 25
20 20
15 15
10 10 11 10 10
9 8 9 8 8 8 8 8
6 6 6 6 7 7
5 5 4 5 5
0 0
Módulo ventas
25
20 20 20
17
15 15 14 14 15
13
10 9 8
5
0
64
CONCLUSIONES
Se logró conocer el funcionamiento de la empresa, los servicios, productos que ofrece y

cómo es su manera de trabajar.
Se obtuvo los requisitos mediante las reuniones constantes con el Stakeholder y se

identificó 5 módulos en que se clasifica el sistema.
Se analizó los requisitos y se logró clasificar en requisitos funcionales, no funcionales, y se

determinó la prioridad de cada uno de ellos según la importancia que tiene en el sistema.
Se especificó 53 requisitos funcionales, 9 requisitos no funcionales, y se realizó la

descripción de cada una de ellas por módulo.
Se validó los requisitos funcionales mediante el prototipado en calidad Li-FI, siendo un total
de 70 prototipos validados por el usuario.
Se realizaron las fases de la ingeniería de requisitos para el sistema facturación y determinó

y gestionó cada uno de ellos por módulo, contando satisfactoriamente con la aprobación
del usuario.
65
RECOMENDACIONES
- Se pide al equipo revisar el DOCUMENTO DE ARQUITECTURA DE SOFTWARE SEGÚN

EL ESTÁNDAR IEEE 1471 que describe los casos de uso realizados, el DOCUMENTO
ESPECIFICACIÓN DE REQUISITOS SEGÚN EL ESTÁNDAR IEEE 830 que describe los
requisitos funcionales y no funcionales del sistema de facturación, y el
DOCUMENTO DE REQUISITOS FUNCIONALES, porque describe los requisitos a
detalle y los prototipos funcionales.
- Se recomienda también seguir los lineamientos basado en el marco de buenas

prácticas de Scrum, ya que ella permite gestionar y controlar las tareas, actividades
y estimar el tiempo de duración de una tarea.
66
Bibliografía
Abran, A., & W. Moore, J. (2004). Guide to the Software Engineering Body of Knowledge.
California.
Bourque, P., & Dupuis, R. (2004). Guide to the Software Engineering Body of knowledge.
California.
Chaves, M. A. (2005). La ingeniería de requerimientos y su importancia en el desarrollo de

proyectos de software. InterSedes, pp. 2.
Cueva, S. (2014). Ingeniería de Requisitos.
De La Cruz Londoño, C. A., & Castro Guevara, G. A. (2014). LA INGENIERÍA DE REQUERIMIENTOS

EN LAS PEQUEÑAS EMPRESAS DEL DEPARTAMENTO DE RISARALDA. 10.
Fuentes, M. d. (2011). Análisis de requerimientos. Cuajimalpa: 2011.
Gottesdiener, E. (2009). The Software Requirements Memory Jogger.
Laguna, M. A. (s.f.). Ingeniería del Software I.
Schwaber, K. (2013). La Guía de Scrum.
Wiegers, K. (2003). Software Requirements .
67
ANEXOS
68
ANEXO I
DOCUMENTO DE ARQUITECTURA DE SOFTWARE SEGÚN EL

ESTÁNDAR IEEE 1471
IEEE Std. 1471 - 2000
69
1. Introducción
1.1. Propósito
Este documento proporciona una descripción comprensiva arquitectónica
del sistema de facturación. Con estos, se podrá capturar y transportar las
decisiones significativas que han sido hechas sobre el sistema.
1.2. Alcance
El presente documento contiene el diseño de casos de uso elaborado para
el proyecto Sistema de facturación el cual es producto de un análisis de los
requisitos del sistema.
El documento está organizado alrededor de 3 ideas principales:

a) Las características generales del diseño de casos de uso
b) Los requisitos atendidos por el diseño de casos de uso
c) Los modelos y vistas que lo detallan
Los modelos son utilizados tanto para el análisis como para el diseño de la
solución, así como para la especificación, construcción y despliegue del
sistema en su ambiente de explotación.
Los modelos son presentados por UML. Los casos de uso se dividieron por
módulos.
Los modelos fueron hechos en Enterprise Architect Versión 8.0.
1.3. Usuarios interesados

Este documento de Arquitectura de Software (DAS), será usado por el
programador, para que puedan construir el sistema, y por el tester para que
pueda verificar que todo se cumplió en el sistema.
70
2. Definiciones, acrónimos y abreviaciones
CU: Casos de uso
3. Framework conceptual
3.1. Descripción de la arquitectura en contexto

La arquitectura usada son los casos de uso, realizados en Enterprise
Architect versión 8.0, estos fueron realizados de acuerdo a los requisitos
para analizarlos.
3.2. Referencias
Título del documento Referencias
Standard IEEE 1471 – 2000 IEEE
3.3. Stakeholders y sus roles

Tipo de usuario Administrador
Formación Ingeniero en informática y Sistemas
Funciones Control y manejo de todo el sistema. Tiene

acceso a todas las actividades que se
realizan en el sistema.
Tipo de usuario Operador
Formación Administrador
Funciones Registrar y editar los productos y clientes

de la empresa.
71
Tipo de usuario Consultor
Formación Ingeniero en informática y

Sistemas
Funciones Visualizar el listado de los

productos y clientes de la
empresa
4. Descripciones prácticas de arquitectura
4.1. La arquitectura
Para la arquitectura, se realizaron casos de uso divididos en 5 módulos.
4.2. Identificación de los stakeholders y sus responsabilidades

Stakeholder Descripción Escenario Vistas
El gerente de la empresa - Módulo - CU

Rouillon Consulting, será el Productos Productos
administrador del sistema - Módulo - CU Clientes
facturador y tendrá acceso Clientes - CU Usuarios
a todos los procesos. - Módulo - CU Ventas
Usuarios - CU Datos de
- Módulo la Empresa
Ventas
- Módulo
Datos de la
Empresa
72
El usuario operador podrá
crear, editar y visualizar a - Módulo - CU
los clientes y productos. Productos Productos
- Módulo - CU Clientes
Clientes - CU Ventas
- Módulo
Ventas
El usuario consultor sólo

podrá visualizar el listado - Módulo - CU
de clientes y productos. Productos Productos
- Módulo - CU Clientes
Clientes
4.3. Selección de puntos de vista de la arquitectura

Vistas UML
Módulo Productos Casos de uso
Módulo Clientes Casos de uso
Módulo Usuarios Casos de uso
Módulo Ventas Casos de uso
Módulo Datos de la empresa Casos de uso
73
4.4. Vistas de la arquitectura
4.4.1. Módulo Usuarios – Caso de uso
74
4.4.2. Módulo Datos de la empresa – Caso de uso
75
4.4.3. Módulo Productos – Caso de uso
76
4.4.4. Módulo Clientes – Caso de uso
77
4.4.5. Módulo Ventas – Caso de uso
78
ANEXO II
DOCUMENTO ESPECIFICACIÓN DE REQUISITOS SEGÚN EL

ESTÁNDAR IEEE 830
IEEE Std. 830 - 1998
79
1. Introducción
Este documento presenta la Especificación de requisitos del sistema facturador

para la empresa Rouillon Consulting. Se ha estructurado de acuerdo con el
estándar IEEE 830.
1.1. Propósito
El propósito de este documento es especificar los requisitos funcionales, no

funcionales del sistema facturador para la empresa Rouillon Consulting que
ayudará a gestionar las ventas de sus productos y generar facturas.
1.2. Ámbito del sistema
El sistema facturador tiene como objetivo principal generar factura de las

ventas que hace la empresa y dar la opción de imprimirlo.
El sistema tendrá 5 partes:
- Módulo Usuarios: En este módulo se registrará a los usuarios que

tendrán acceso al sistema, se asignará sus roles para que tengan
restricciones.
También se contará con el listado de los usuarios y tendrá las opciones

de editar y eliminar.
- Módulo Clientes: En este módulo se registrará a los clientes de la

empresa.
También se contará con el listado de los clientes y tendrá las opciones

de editar y eliminar.
- Módulo Productos: En este módulo se registrará a los productos o

servicios que vende la empresa.
También se contará con el listado de los productos y tendrá las

opciones de editar y eliminar.
- Módulo Datos de la empresa: En este módulo se registrará los datos

principales de la empresa.
- Módulo Ventas: En este módulo se registrará las ventas que se hacen

de acuerdo con la fecha.
También se contará con el listado de las ventas.
80
1.3. Personal involucrado
Nombre César Elias Rouillon Sixto
Rol Administrador
Categoría profesional Ingeniero en informática y sistemas
Información de contacto crouillon@rouillonconsulting.com
Nombre Luisa Lorena Moreto Yarise
Rol Operador
Categoría profesional Administradora de empresas
Información de contacto lmoreto@rouillonconsulting.com
Nombre Raúl Montoya Sanchez
Rol Consultor
Categoría profesional Ingeniero en informática y sistemas
Información de contacto mmontoya@rouillonconsulting.com
1.4. Definiciones, Acrónimos y Abreviaturas
Nombre Descripción
Usuario Encargado de usar el sistema.
RFAD Requisito funcional realizado sólo por el

administrador.
RFADOP Requisito funcional realizado por el

administrador y operador.
81
RFADOPCO Requisito funcional realizado por el
administrador, operador y consultor.
RNF Requisito no funcional.
1.5. Referencias
Título del documento Referencias
Standard IEEE 830 – 1998 IEEE
1.6. Visión general del documento
El presente documento constará de 3 secciones.
La primera sección trata sobre una visión general de la especificación de

requisitos.
En la segunda sección se dará una descripción general del producto, se

describirá la perspectiva del producto, sus funcionalidades, características y
restricciones. Y esto, con el objetivo de dar a conocer las funciones que éste
realizará.
Y, por último, en la tercera sección, se definirá la especificación de

requisitos.
2. Descripción General
2.1. Perspectiva del producto
El sistema facturador será realizado en entorno web, este producto ayudará

a la empresa a registrar las ventas realizadas y generará sus facturas, así
mismo, tendrá la opción de imprimir.
2.2. Funciones del producto
Para describir mejor el producto, los requisitos se realizaron por módulos.
Se cuenta con 5 módulos:
82
2.2.1. Módulo Productos
En este módulo el sistema tendrá la función de registrar los

productos que ofrece la empresa.
También tendrá una ventana donde listará los productos

registrados, y tendrá las opciones de editar y eliminar. Así mismo,
para mayor facilidad de encontrar un producto, habrá la opción
de buscar.
2.2.2. Módulo Clientes
En este módulo el sistema tendrá la función de registrar a los

clientes que realizaron sus compran en la empresa.
También contará con una ventana donde estará el listado de los

clientes, y tendrá las opciones de editar y eliminar. Así mismo para
mayor facilidad de encontrar a un cliente en específico, habrá la
opción de buscar.
2.2.3. Módulo Usuarios
En este módulo el sistema tendrá la función de registrar a los

usuarios que tendrán acceso al sistema, así mismo le asignará los
roles para controlar los privilegios de acceso al sistema.
También se contará con una ventana donde se listará a los

usuarios, y se podrá editar o eliminar. Así mismo se podrá buscar
al usuario por su nombre.
2.2.4. Módulo Datos de la empresa
En este módulo el sistema tendrá la función de registrar los datos

de la empresa, y mostrarlos en los campos correspondientes.
También se bloqueará los campos y si en caso se desea editar, los

campos se desbloquearán.
83
2.2.5. Módulo Ventas
En este módulo el sistema tiene como función realizar ventas, se

podrá elegir el producto que se venderá y el cliente a quién se
venderá.
Al confirmar la venta, el sistema generará una factura con los

detalles de la venta. Y, así mismo, el usuario podrá imprimirlo.
2.3. Características de los usuarios
Tipo de usuario Administrador
Funciones Control y manejo de todo el sistema. Tiene

acceso a todas las actividades que se
realizan en el sistema.
Tipo de usuario Operador
Formación Administrador
Funciones Registrar y editar los productos y clientes

de la empresa.
Tipo de usuario Consultor
Funciones Visualizar el listado de los productos y

clientes de la empresa
2.4. Restricciones
Las restricciones que tendrán los desarrolladores del producto son:
- Lenguajes de programación: Html, C#

- Debe ser un diseño responsive.
- Por el tema de seguridad, se debe restringir accesos.
84
2.5. Suposiciones y dependencias
- Se asume que los requisitos presentados en el documento cumplirán el

objetivo del sistema y mantendrán su estabilidad.
- El sistema depende de las restricciones presentadas para contar con una

mejor funcionalidad.
2.6. Requisitos futuros
Los requisitos futuros dados por la empresa harán que el sistema facturador
pase a ser sistema de facturación electrónica.
3. Requisitos específicos
3.1. Requisitos Funcionales
3.1.1. Módulo Usuarios
Código del requisito RFAD1
Nombre del requisito Registrar usuarios
Características Requisito disponible para el

administrador
Descripción de requisito El sistema debe ser capaz de registrar

y guardar a los usuarios, para tener la
lista de quiénes tienen acceso al
sistema y sus roles, al mismo tiempo se
debe enviar el correo al usuario con su
username y contraseña para que
pueda acceder al sistema. Este rol lo
realiza sólo el administrador.
Prioridad del requisito Alta
85
Nombre del requisito Actualizar lista de usuarios

administrador
Descripción de requisito El sistema debe ser capaz de actualizar

la lista de usuarios
Prioridad del requisito Media
Nombre del requisito Listar usuarios

administrador
Descripción de requisito El sistema debe ser capaz de visualizar

la lista de usuarios registrados para
poder obtener sus datos, roles y
conocer quienes tienen acceso al
sistema.
Nombre del requisito Buscar usuario por filtro

administrador
Descripción de requisito El sistema debe ser capaz de buscar

usuario de acuerdo a su nombre, para
ver su información y/o realizar alguna
acción.
86
Nombre del requisito Editar usuario

administrador
Descripción de requisito El sistema debe ser capaz, que el

administrador edite los datos de los
usuarios, en caso exista alguna
equivocación en el registro.
Nombre del requisito Eliminar usuario

administrador
Descripción de requisito El sistema debe ser capaz, que el

administrador elimine usuarios, en caso
dejen de trabajar en la empresa.
Nombre del requisito Registrar tipo de rol

administrador

tipo de rol para que el administrador
defina que función tendrá cada usuario.
87
Nombre del requisito Editar tipo de rol

administrador
Descripción de requisito El sistema debe ser capaz de editar el

tipo de rol, porque puede haber
errores.
Nombre del requisito Eliminar tipo de rol

administrador
Descripción de requisito El sistema debe ser capaz de eliminar

un tipo de rol, en caso esa función no
exista para el usuario.
Código del requisito RFADOPCO10
Nombre del requisito Iniciar sesión
Características Requisito disponible para los usuarios.
Descripción de requisito El sistema debe validar la cuenta de

acceso y la contraseña de ingreso al
sistema para tener acceso a ciertos
privilegios según el rol del usuario que
está ingresando.
88
Nombre del requisito Verificar tipo de usuario
Descripción de requisito Al momento de loguearse, el sistema

debe verificar internamente el rol del
usuario que está ingresando para que
se puedan hacer restricciones según
los privilegios.
Nombre del requisito Recordar contraseña
Descripción de requisito El sistema debe mostrar una ventana,

al dar recordar contraseña, donde pida
el correo de usuario, y se debe enviar
un correo a éste.
Nombre del requisito Cambiar contraseña
Descripción de requisito El sistema debe ser capaz de

reemplazar la contraseña anterior con
una nueva.
89
3.1.2. Módulo Datos de la empresa
Nombre del requisito Registrar datos de la empresa

administrador.
Descripción de requisito El sistema debe ser capaz que el

administrador registre los datos
principales de la empresa, al guardar,
los campos se deben bloquear
Nombre del requisito Editar datos de la empresa

administrador.
Descripción de requisito El sistema debe desbloquear los

campos, para que se pueda editar los
datos de la empresa, en caso exista
cambios o algún error.
Nombre del requisito Visualizar datos de la empresa

administrador.
Descripción de requisito El sistema debe ser capaz de mostrar

los datos registrados de la empresa,
con lo campos bloqueados
90
3.1.3. Módulo Productos
Código del requisito RFADOP17
Nombre del requisito Registrar productos


y guardar los productos que ofrece la
empresa, para poder contar con el
listado de su información.
Nombre del requisito Actualizar lista de productos


la lista de productos
Nombre del requisito Listar productos


la lista de productos con su
información.
91
Nombre del requisito Buscar producto por filtro

Descripción de requisito El sistema debe ser capaz de realizar la

búsqueda de producto por su nombre,
y así visualizar su información.
Nombre del requisito Editar productos

Descripción de requisito El sistema debe ser capaz de editar

productos, por si existe cambio en la
información o hubo alguna
equivocación.
Nombre del requisito Eliminar producto

administrador.

productos, en caso la empresa ya no
los ofrezca.
92
Nombre del requisito Registrar tipo de producto


el tipo de producto, en caso la
empresa cuente con más de éstos.
Nombre del requisito Editar tipo de producto


tipo de producto, porque puede existir
algún error.
Nombre del requisito Eliminar tipo de producto

administrador.

el tipo de producto, en caso la
empresa ya no cuente con esa.
93
Nombre del requisito Exportar lista de productos

administrador.
Descripción de requisito El sistema debe ser capaz de exportar

la lista de productos registrada en
formato .xslx con su información
respectiva.
3.1.4. Módulo clientes
Nombre del requisito Registrar de clientes


y guardar los clientes sw la empresa,
para poder contar con el listado de su
información
Nombre del requisito Actualizar lista de clientes


la lista de clientes.
94
Nombre del requisito Listar clientes


la lista de clientes con su información.
Nombre del requisito Buscar cliente por filtro


búsqueda de cliente por su nombre, y
así visualizar su información.
Nombre del requisito Editar cliente

administrador, operador.

cliente, por si existe cambio en la
información o hubo alguna
equivocación.
95
Nombre del requisito Eliminar cliente

administrador.

cliente, en caso la empresa ya no los
ofrezca.
Nombre del requisito Exportar lista de clientes

administrador.

la lista de clientes registrada en
formato .xslx con su información
respectiva.
3.1.5. Módulo Ventas
Nombre del requisito Realizar venta


venta.
96
Nombre del requisito Buscar producto

Descripción de requisito El sistema debe ser capaz de buscar a

un producto mediante su nombre.
Nombre del requisito Revisar stock de producto


el stock del producto para prevenir la
cantidad que se venderán.
Nombre del requisito Seleccionar producto


seleccionar el producto que se
venderá.
97
Nombre del requisito Buscar cliente

Descripción de requisito El sistema debe ser capaz de buscar al

cliente que comprará el producto, en
caso no exista el cliente, se le
registrará.
Nombre del requisito Seleccionar cliente


seleccionar al cliente que comprará el
producto.
Nombre del requisito Confirmar venta

Descripción de requisito El sistema debe ser capaz de confirmar

la venta que se está realizando.
98
Nombre del requisito Registrar pagos

Descripción de requisito El sistema debe ser capaz de que el

administrador registre los pagos, si
existe pago en partes de igual manera,
registrar pago inicial y final.
Nombre del requisito Registrar estado de pago

Descripción de requisito El sistema debe ser capaz de que se

registre el estado de pago, si en caso el
cliente aún no terminó de pagar.
Nombre del requisito Registrar fecha de venta

Descripción de requisito El sistema debe ser capaz de que al

registrar la venta se registre la fecha de
venta.
99
Nombre del requisito Listar ventas

Descripción de requisito El sistema debe ser capaz de listar las

ventas realizadas.
Nombre del requisito Editar venta


venta, sólo en caso de que se quiera
corregir los pagos y el estado.
Nombre del requisito Exportar reporte de las ventas


el reporte de las ventas realizadas.
100
Nombre del requisito Generar factura

Descripción de requisito El sistema debe ser capaz de generar la

factura de la venta que se está
realizando. Si existe pago en partes, se
generará factura por pago.
Nombre del requisito Registrar factura


las facturas que se están generando
Nombre del requisito Imprimir factura

Descripción de requisito El sistema debe ser capaz de dar la

opción de imprimir la factura
generada.
101
Nombre del requisito Enviar factura al cliente

Descripción de requisito El sistema debe ser capaz de enviar la

factura generada al cliente que está
comprando.
Nombre del requisito Registrar tipo de moneda


el tipo de moneda.
Nombre del requisito Editar tipo de moneda


tipo de moneda.
102
Nombre del requisito Eliminar tipo de moneda


el tipo de moneda.
3.2. Requisitos No Funcionales
Código del requisito RNF1
Nombre del requisito Eficiencia de desempeño
Descripción de requisito El sistema debe contar con un buen

desempeño al momento de realizar sus
funciones por módulo.
El usuario podrá buscar a productos o
clientes, en un horario de operación
normal, obteniendo el resultado en un
tiempo máximo de 3 segundos.
Nombre del requisito Seguridad
Descripción de requisito El sistema hacer referencia a la

protección de la información
registrada en el sistema, es decir, que
personas no autorizadas no podrán
acceder al sistema.
103
Nombre del requisito Estética
Descripción de requisito El sistema debe incluir colores según el

dueño del producto quiere para su
empresa.
Nombre del requisito Usabilidad
Descripción de requisito El sistema debe ser fácil de usar y

manejar.
Nombre del requisito Comprobabilidad
Descripción de requisito El sistema debe permitir ser probado

en un determinado contexto.
Nombre del requisito Disponibilidad
Descripción de requisito El sistema estará disponible a tiempo

completo para el administrador, es el
quién indicará el periodo de uso para
el operador y consultor.
104
Nombre del requisito Extensibilidad
Descripción de requisito El sistema permitirá facilitar su

crecimiento en un futuro.
Nombre del requisito Escalabilidad
Descripción de requisito El sistema manejará una creciente

carga de trabajo por el número de
usuarios que tienen acceso a esta.
Nombre del requisito Mantenibilidad
Descripción de requisito El sistema podrá dar la facilidad de dar

mantenimiento al producto, con la
finalidad de desarrollar nuevos
requisitos, corregir defectos.
105
ANEXO III
DOCUMENTO REQUISITOS FUNCIONALES
106
1. REQUISITOS FUNCIONALES
CUADRO 1. MODULO USUARIOS
MODULO CODIGO REQUISITOS PRIORIDAD

FUNCIONALES
RFAD1. Registrar usuarios Alta
RFAD2. Actualizar lista de Media

usuarios
RFAD3. Listar usuarios Alta
USUARIOS RFAD4. Buscar usuario por filtro Media
RFAD5. Editar usuarios Alta
RFAD6. Eliminar usuarios Alta
RFAD7. Registrar tipo de rol Media
RFAD8. Editar tipo de rol Media
RFAD9. Eliminar tipo de rol Media
RFADOPCO10. Iniciar sesión de usuario Alta
RFADOPCO11. Verificar tipo de usuario Alta
RFADOPCO12. Recordar contraseña Alta
RFADOPCO13. Cambiar contraseña Alta
Sprint 2. MODULO REGISTRO DE USUARIOS

En este módulo el sistema debe ser capaz de registrar, guardar, editar y eliminar. Es
importante contar con el listado de usuarios, para que el administrador o jefe pueda
controlar los accesos de los demás usuarios, y conocer los datos de ellos.
Así cuando un usuario se identificará y tendrá acceso a ciertos permisos al ingresar al

sistema.
107
1.1. RFAD1. Registrar usuarios
1.1.1. Objetivo:
Dar acceso a usuarios, registrando sus roles y de acuerdo a eso, tengan

privilegios en el acceso del sistema. Y al registrar los usuarios se
contará con el listado de ellos.
1.1.2. Descripción:
El sistema debe ser capaz de registrar y guardar a los usuarios, para

tener la lista de quiénes tienen acceso al sistema y sus roles, al mismo
tiempo se debe enviar el correo al usuario con su username y
contraseña para que pueda acceder al sistema.
Los campos a registrar son:
- Nombre: Debe permitir ingresar 50 caracteres.

- Apellido: Debe permitir ingresar 50 caracteres.
- Correo: Debe permitir ingresar 50 caracteres.
- Rol: Están registrados en un combo box, debe permitir seleccionar
uno de ellos.
- Username: Debe permitir ingresar sólo hasta 30 caracteres.
- Contraseña: Debe permitir ingresar sólo hasta 30 caracteres.
- Estado: Sólo puede ser “Activo” o “Inactivo”.
Al registrar debe salir un mensaje confirmando que se guardó el

usuario.
Si existe algún campo vacío, no debe guardarse y debe dar aviso que
falta llenar campos.
1.1.3. Prioridad:
Alta
1.1.4. Prototipo:
A continuación, se visualiza la pantalla donde se llena los campos

requeridos y dar click en el botón “Registrar” para que se guarde el
usuario, y así mismo, enviar el correo a este con sus credenciales de
acceso al sistema.
108
Ahora se visualiza la ventana que muestra el mensaje confirmando que el usuario se
guardó:
109
1.2. RFAD2. Actualizar lista de usuarios
1.2.1. Objetivo:
Visualizar todos los usuarios registrados.
El sistema debe ser capaz de actualizar la lista de usuarios. Para poder
visualizar todas las actualizaciones. Esta opción estará en la ventana
del listado de usuarios. Este rol lo realiza sólo el administrador.
1.2.3. Prioridad:
Media
1.2.4. Prototipo:
A continuación, se visualiza la pantalla con la lista de usuario, y el
botón de actualizar.
110
1.3. RFAD3. Listar de usuarios:
1.3.1. Objetivo:
El objetivo es dar a conocer al administrador quiénes son los usuarios
que tienen acceso al sistema y cuáles son sus roles.
El sistema debe ser capaz de visualizar la lista de usuarios registrados
para poder obtener sus datos, roles y conocer quiénes tienen acceso
al sistema.
Se visualizarán los campos:
- Nombre
- Apellido
- Correo
- Rol
- Username
- Contraseña
También habrá un campo de acciones, con las opciones de “Editar” y
“Eliminar”. Este rol lo realiza sólo el administrador.
1.3.3. Prioridad
Alta
1.3.4. Prototipo:
A continuación, se visualiza la ventana con el listado de los usuarios
registrados:
111
1.4. RFAD4. Buscar usuarios
1.4.1. Objetivo:
El objetivo es encontrar con facilidad y menor tiempo al usuario
indicado.
El sistema debe ser capaz de buscar usuario de acuerdo a su nombre,
para ver su información y/o realizar alguna acción. Mientras escribe el
nombre va el sistema va buscando y mostrado al usuario. Este rol lo
realiza sólo el administrador.
1.4.3. Prioridad:
Media
1.4.4. Prototipo:
A continuación, se visualizará la ventana donde está la opción de
buscar al usuario:
112
1.5. RFAD5. Editar usuarios
1.5.1. Objetivo:
El objetivo es actualizar los datos correctos de los usuarios, ya sea por

algún error o cambio.
El sistema debe ser capaz, que el administrador edite los datos de los
usuarios, en caso exista alguna equivocación o cambio en el registro.
Esta opción se debe mostrar en el listado de usuarios, en el campo de

“Acciones”. Al dar editar, se abre otra ventana donde se dará en
guardar, y volverá a la ventana de la lista de usuarios. Este rol lo realiza
sólo el administrador.
1.5.3. Prioridad:
Alta
1.5.4. Prototipo:
A continuación, se visualiza la opción de editar que se encuentra en
“Acciones”:
113
Al dar editar se abre la siguiente ventana:
114
1.6. RFAD6. Eliminar usuarios
1.6.1. Objetivo:
El objetivo es quitar el acceso a los usuarios eliminados.
El sistema debe ser capaz, que el administrador elimine usuarios, en
caso dejen de trabajar en la empresa.
La opción de eliminar estará en el listado de usuarios en un campo más

de “Acciones”. Este rol lo realiza sólo el administrador.
1.6.3. Prioridad:
Alta
1.6.4. Prototipo:
A continuación, se visualiza la pantalla, donde al dar eliminar, muestra
un mensaje de confirmación:
115
1.7. RFAD7. Registrar tipo de rol
1.7.1. Objetivo:
Registrar los roles de los usuarios que tendrán acceso al sistema.
El sistema debe permitir registrar los roles de los usuarios para que al
registrar a los usuarios se puedan asignar a cada uno de ellos
seleccionando en un combobox.
1.7.3. Prioridad:
Media
1.7.4. Prototipo:
A continuación, se visualiza la ventana donde se registra el tipo de
rol:
116
1.8. RFAD8. Editar tipo de rol
1.8.1. Objetivo:
Actualizar los datos correctos registrados del tipo de rol.
El sistema debe permitir editar los datos del tipo de rol, porque
puede existir errores, guardar las correcciones.
Si existe algún campo vacío, no debe editar y debe dar aviso que falta
llenar campos.
Este rol lo realiza sólo administrador.
1.8.3. Prioridad:
Media
1.8.4. Prototipo:
A continuación, se visualiza la ventana donde se edita el tipo de rol:
117
1.9. RFAD9. Eliminar tipo de rol
1.9.1. Objetivo:
Quitar los tipos de rol que no tendrán acceso al sistema.
El sistema debe permitir eliminar a los tipos de usuarios para sólo
contar con los que se puede asignar a los usuarios y accedan al sistema
según el rol.
1.9.3. Prioridad:
Media
1.9.4. Prototipo:
A continuación, se visualiza la venta donde está la opción de eliminar
el tipo de rol:
118
1.10. RFADOPCO10. Iniciar sesión
1.10.1. Objetivo:
Acceder al sistema para realizar las actividades correspondientes.
El sistema debe validar el username y la contraseña ingresados, para
confirmar que el usuario está registrado por el administrador y así,
tenga acceso al sistema. Este rol lo realiza cualquier usuario.
1.10.3. Prioridad:
Alta
1.10.4. Prototipo:
A continuación, se visualiza la ventana donde pide las credenciales del
usuario, username y password.
119
1.11. RFADOPCO11. Verificar tipo de usuario
1.11.1. Objetivo:
El sistema debe verificar el tipo de usuario para que pueda hacer

restricciones a los privilegios de acceso al sistema.
Al momento de iniciar sesión, el sistema debe verificar internamente el
rol del usuario, según el username ingresado, para que se puedan hacer
restricciones según los privilegios.
1.11.3. Prioridad:
Alta
1.11.4. Prototipo:
A continuación, se visualiza la misma pantalla de “Iniciar sesión”, ya que
es el mismo momento donde se debe verificar el tipo de usuario.
120
1.12. RFADOPCO12. Recordar contraseña
1.12.1. Objetivo:
Enviar un link que le ayudará al usuario cambiar su contraseña e
ingresar al sistema para realizar sus actividades.
Al dar click, en la opción de “Recordar contraseña”, el sistema debe
mostrar una ventana, donde pida el correo del usuario, e
internamente se debe verificar que éste exista. Si es así, se mandará
un link al correo, para que el usuario pueda acceder, este link abrirá la
ventana donde el usuario podrá cambiar su contraseña. Este rol lo
realiza cualquier usuario.
1.12.3. Prioridad:
Alta
1.12.4. Prototipo:
A continuación, se visualiza la pantalla donde muestra la opción para
que permita recordar contraseña:
121
Luego, muestra la ventana donde pedirá el correo al usuario:
122
1.13. RFADOPCO13. Cambiar contraseña
1.13.1. Objetivo:
Permitir al usuario ingresar al sistema.
El sistema debe ser capaz de reemplazar la contraseña anterior con
una nueva. Como campos estarán la contraseña nueva y pedirá
repetirla, por si hubo una equivocación en escribir la contraseña. Y al
dar guardar, se ingresará al sistema. Este rol lo realiza sólo el
administrador.
1.13.3. Prioridad:
Alta
1.13.4. Prototipo:
A continuación, se visualiza la ventana donde se cambia la contraseña:
123
CUADRO 2. MODULO DATOS DE LA EMPRESA

FUNCIONALES
RFAD14. Registrar datos de la Alta

empresa
RFAD15. Editar datos de la Alta

USUARIOS
empresa
RFAD16. Visualizar datos de la Normal

empresa
Sprint 3. MODULO DATOS DE LA EMPRESA

En este módulo el sistema debe ser capaz de registrar, editar los datos de la empresa. Es
importante contar con estos datos para poder dar a conocer a los clientes.
1.14. RFAD14. Registrar datos de la empresa
1.14.1. Objetivo:
Identificar la información de la empresa que se podrá brindar a los
clientes.
El sistema debe ser capaz que el administrador registre los datos
principales de la empresa, al guardar, los campos se deben bloquear.
Los datos de la empresa que se registran son:

- RUC: Debe permitir ingresar ni más ni menos de 11 números.
- Titular: Debe permitir ingresar hasta 50 caracteres
- Contactos: Debe permitir ingresar hasta 50 caracteres.
- Domicilio fiscal: Debe permitir ingresar hasta 200 caracteres
- Correo: Debe permitir ingresar hasta 50 caracteres.
- Persona contacto: Debe permitir ingresar hasta 50 caracteres.
- Cargo: Debe permitir ingresar hasta 50 caracteres.
- Correo contacto: Debe permitir ingresar hasta 50 caracteres.
124
- Teléfono: Debe permitir ingresar sólo números y hasta 20
caracteres.
1.14.3. Prioridad:
Alta
1.14.4. Prototipo:
A continuación, se visualiza la pantalla, donde se llena los datos de la
empresa:
125
Al dar en guardar, muestra un mensaje de que la información fue guardada:
1.15. RFAD15. Editar los datos de la empresa
1.15.1. Objetivo:
Actualizar la información de la empresa.
El sistema debe desbloquear los campos, para que se pueda editar los datos
de la empresa, en caso exista cambios o algún error.
Si existe algún campo vacío, no debe editarse y debe dar aviso que
1.15.3. Prioridad:
Alta
1.15.4. Prototipo:
A continuación, se visualiza la pantalla donde se podrá editar:
126
1.16. RFAD16. Visualizar los datos de la empresa
1.16.1. Objetivo:
Mostrar la información registrada en los campos correspondientes.
El sistema debe ser capaz de mostrar los datos registrados de la
empresa, con lo campos bloqueados. Este rol lo realiza sólo el
administrador.
1.16.3. Prioridad:
Media
127
1.16.4. Prototipo
A continuación, se visualiza la ventana donde se visualiza los campos
registrados.
128
Cuadro 3. MODULO PRODUCTOS

FUNCIONALES
RFADOP17. Registrar productos Alta
RFADOPCO18. Actualizar lista de Media

productos
RFADOPCO19. Listar productos Alta
RFADOPCO20. Buscar producto por filtro Media
PRODUCTOS RFADOP21. Editar productos Alta
RFAD22. Eliminar productos Alta
RFADOP23. Registrar tipo de producto Media
RFADOP24. Editar tipo de producto Media
RFAD25. Eliminar tipo de producto Media
RFADOP26. Exportar lista de Alta

productos
Sprint 4. MODULO PRODUCTOS:

En este módulo el sistema debe ser capaz de registrar, guardar, editar y eliminar. Es
importante contar con el listado de productos que ofrece la empresa, para que, al
momento de realizar la venta, se obtenga el listado y se visualice los productos
disponibles con sus detalles.
1.17. RFADOP17. Registrar productos
1.17.1. Objetivo:
Contar con el listado de productos que ofrece la empresa.
129
El sistema debe ser capaz de registrar y guardar los productos que
ofrece la empresa, para poder contar con el listado de su información.
Entre los datos que se pide son:
- Código de producto: Debe permitir ingresar hasta 50 caracteres.

- Nombre del producto: Debe permitir ingresar hasta 200
caracteres.
- Tipo de producto: De permitir
- Descripción: Debe permitir ingresar hasta 300 caracteres.
- Stock: Debe permitir ingresar sólo enteros.
- Estado: Debe permitir ingresar hasta 50 caracteres.
- Costo: debe permitir ingresar números decimales
- Precio: debe permitir ingresar números decimales
- Tipo de moneda: Debe permitir ingresar hasta 200 caracteres.
1.17.3. Prioridad:
Alta
1.17.4. Prototipo:
A continuación, se visualiza la ventana donde se registrarán y guardarán los

productos.
Para añadir el producto también hay una opción, que redireccionará al

registro de productos:
130
Al guardar el producto salió un mensaje confirmando que el producto fue
guardado:
131
1.18. RFADOPCO18. Actualizar lista de productos
1.18.1. Objetivo:
Visualizar todos los productos registrados.
El sistema debe ser capaz de actualizar la lista de usuarios. Para poder

visualizar todas las actualizaciones. Esta opción estará en la ventana
del listado de usuarios. Este rol lo realizan el administrador, operador
y consultor.
Este rol lo realizan el administrador, operador y consultor.
1.18.3. Prioridad:
Media
1.18.4. Prototipo:
A continuación, se muestra la ventana donde está la opción de

actualizar:
132
1.19. RFADOPCO19. Listar productos
1.19.1. Objetivo:
Listar los productos que vende la empresa y conocer los detalles de

cada uno de ellos.
El sistema debe ser capaz de visualizar la lista de productos con su

información. Se visualizarán los campos:
- Código
- Nombre
- Tipo
- Descripción
- Stock
- Estado
- Costo
- Precio
Y acciones con las opciones de “Editar” y “Eliminar”. En la opción de

“Ver”, saldrá un modal para visualizar los demás campos.
1.19.3. Prioridad:
Media
1.19.4. Prototipo:
A continuación, se visualiza la ventana del listado de productos:
133
Al dar en la opción de ver se abrirá un modal:
134
1.20. RFADOPCO20. Buscar producto por filtro
1.20.1. Objetivo:
Encontrar con facilidad y menor tiempo un producto específico.
El sistema debe ser capaz de realizar la búsqueda de producto por su

nombre o codigo, y así visualizar su información.
1.20.3. Prioridad:
Media
1.20.4. Prototipo:
A continuación, se visualiza la venta donde se encuentra la opción

donde se podrá escribir el producto que se va a buscar:
135
1.21. RFADOP21. Editar productos
1.21.1. Objetivo:
El objetivo es actualizar la información correcta de los productos, ya

sea por algún error o cambio.
El sistema debe ser capaz, de dar la opción de editar la información de

los productos, en caso exista alguna equivocación o cambio en el
registro.
Esta opción se debe mostrar en el listado de productos, en el campo

de “Acciones”. Al dar editar, se abre otra ventana donde se dará en
guardar, y volverá a la ventana de la lista de productos.
Este rol lo realizan el administrador, operador.
1.21.3. Prioridad:
Alta
1.21.4. Prototipo:
136
A continuación, se visualiza la ubicación de la opción de editar:
Ahora, se abrirá la venta con los campos del producto seleccionado:
137
1.22. RFAD22. Eliminar productos
1.22.1. Objetivo:
El objetivo es quitar el producto o servicio si en caso la empresa ya no
lo ofrece.
El sistema debe ser capaz, de eliminar usuarios, en caso que la

empresa ya no venda esos productos.
La opción de eliminar estará en el listado de productos en un campo

más de “Acciones”.
1.22.3. Prioridad:
Alta
1.22.4. Prototipo:
El sistema debe ser capaz de eliminar productos, en caso la empresa ya no
los ofrezca.
138
1.23. RFADOP23. Registrar tipo de producto
1.23.1. Objetivo:
El objetivo es contar con la información de los tipos de productos que

la empresa ofrece.
El sistema debe ser capaz de registrar y guardar el tipo de producto

que ofrece la empresa.
El tipo debe ser varchar(100).
1.23.3. Prioridad:
Media
1.23.4. Prototipo:
A continuación, se muestra la ventana donde se registrará el tipo de

producto:
139
1.24. RFADOP24. Editar tipo de producto
1.24.1. Objetivo:
El objetivo es contar corregir un registro erróneo, para contar con la

información correcta de los tipos de productos.
El sistema debe ser capaz de editar el tipo de producto que ofrece la

empresa.
El tipo debe ser varchar(100).
1.24.3. Prioridad:
Media
1.24.4. Prototipo:
A continuación, se muestra la ventana donde se editará el tipo de

producto:
140
1.25. RFAD25. Eliminar tipo de producto
1.25.1. Objetivo:
El objetivo es eliminar el tipo de producto que la empresa ya no ofrece.
El sistema debe ser capaz de eliminar el tipo de producto que ofrece

la empresa.
1.25.3. Prioridad:
Media
1.25.4. Prototipo:
A continuación, se muestra la ventana donde se eliminará el tipo de

producto:
141
1.26. RFADOP26. Exportar lista de productos
1.26.1. Objetivo:
Contar con el reporte de productos y su información de cada uno de

ellos.
El sistema debe ser capaz de exportar la lista de productos registrada

en formato .xslx con su información respectiva.
Esta opción estará en la ventana de la lista de productos. Se exportará
todos los datos de cada producto.
1.26.3. Prioridad:
Alta
1.26.4. Prototipo:
.
142
Cuadro 4. MODULO CLIENTES
MODULO CODIGO REQUERIMIENTOS FUNCIONALES PRIORIDAD
RFADOP27. Registrar clientes Alta
RFADOPCO28. Actualizar lista de clientes Media
RFADOPCO29. Visualizar clientes Alta
RFADOPCO30. Buscar cliente por filtro Media
RFADOP31. Editar cliente Alta

CLIENTES
RFAD32. Eliminar cliente Alta
RFADOP33. Exportar listado de clientes Alta
Sprint 5. REGISTRO DE CLIENTES:

En este módulo el sistema debe ser capaz de registrar, guardar, editar y eliminar. Se
debe contar con la lista de clientes para tenerlos registrados, y saber son los clientes
más recurrentes.
143
1.27. RFADOP27. Registrar de clientes
1.27.1. Objetivo:
Contar con el listado de clientes que compraron productos/servicios

de la empresa.
El sistema debe ser capaz de registrar y guardar los clientes de la

empresa, para poder contar con el listado de su información.
Así cuando se realiza las ventas, se elige a que cliente se le venderá el
producto o servicio, en caso sea cliente nuevo, registrarlo.
Los datos a registrar son:

- Ruc: Debe permitir ingresar ni menos, ni más de 11 números.
- Titular: Debe permitir ingresar hasta 50 caracteres.
- Domicilio Fiscal: Debe permitir ingresa sólo 100 caracteres.
- Rubro: Debe permitir ingresar hasta 50 caracteres
- Persona contacto Debe permitir ingresar hasta 50 caracteres
- Cargo: Debe permitir ingresar hasta 50 caracteres
- Correo contacto: Debe permitir ingresar hasta 50 caracteres
- Teléfono: Debe permitir ingresar hasta 20 numeros
1.27.3. Prioridad:
Alta
1.27.4. Prototipo:
144
1.28. RFADOPCO28. Actualizar lista de clientes
1.28.1. Objetivo:
Visualizar todos los clientes registrados.
El sistema debe ser capaz de actualizar la lista de clientes, la opción

será un botón que se mostrará en la lista de clientes.
1.28.3. Prioridad:
Media
1.28.4. Prototipo:
A continuación, se visualiza la ventana donde se encuentra la opción de
actualizar la lista de clientes:
145
1.29. RFADOPCO29. Visualizar clientes
1.29.1. Objetivo:
Conocer quiénes son los clientes de la empresa y sus datos.
El sistema debe ser capaz de visualizar la lista de clientes con su

información.
En la ventana de la lista de clientes se visualizarán los datos:
- Razón social
- RUC
- Titular
- Domicilio Fiscal
- Rubro
Y también “Acciones” que serán las opciones de editar o eliminar, y
“Ver”. Al dar click en ver, se visualizará todos los datos registrados del
cliente seleccionado.
1.29.3. Prioridad:
Media
146
1.29.4. Prototipo:
A continuación, se visualiza la ventana de listado de clientes y la

opción de “Ver”y se abriá un modal con todos los campos registrados:
147
1.30. RFADOPCO30. Buscar cliente por filtro
1.30.1. Objetivo:
Encontrar con facilidad y a menor tiempo un cliente.
El sistema debe ser capaz de realizar la búsqueda de cliente por su nombre

o apellido, y así visualizar su información.
1.30.3. Prioridad:
Media
1.30.4. Prototipo:
A continuación, se visualiza la venta donde está la opción de buscar:
148
1.31. RFADOP31. Editar cliente
1.31.1. Objetivo:
El objetivo es actualizar la información correcta de los clientes, ya sea

por algún error o cambio.
El sistema debe ser capaz, de dar la opción de editar la información de

los clientes, en caso exista alguna equivocación o cambio en el
registro.
Esta opción se debe mostrar en el listado de clientes, en el campo de

“Acciones”. Al dar editar, se abre otra ventana donde se dará en
guardar, y volverá a la ventana de la lista de productos.
Este rol lo realizan el administrador, operador.
1.31.3. Prioridad:
Alta
1.31.4. Prototipo:
A continuación, se visualiza la ventana donde está la opción de editar:
149
Y se abrirá la siguiente ventana para editar:
150
1.32. RFAD32. Eliminar cliente
1.32.1. Objetivo:
El objetivo es quitar a los que ya no serán más clientes de la empresa.
El sistema debe ser capaz de eliminar el cliente que deja de realizar compras
de la empresa.
El botón de Eliminar se encuentra ubicado como un campo de

“Acciones”, en el listado de clientes, para poder escoger que cliente
eliminar.
1.32.3. Prioridad:
Alta
1.32.4. Prototipo:
151
A continuación, se visualiza la ventana donde está la opción de
eliminar:
1.33. RFADOP33. Exportar lista de clientes
1.33.1. Objetivo:
Contar con el listado de cliente en formato Excel.
El sistema debe ser capaz de exportar la lista de clientes registrada en

formato .xslx con su información respectiva
1.33.3. Prioridad:
Alta
1.33.4. Prototipo:
152
A continuación, se visualiza la venta donde está la opción de exportar
el listado de clientes:
153
Cuadro 5. MODULO VENTAS

FUNCIONALES
RFADOP34. Realizar venta Alta
RFADOP35. Buscar producto Alta
RFADOP36. Revisar stock de producto Alta
RFADOP37. Seleccionar producto Alta
RFADOP38. Buscar cliente Alta
RFADOP39. Seleccionar cliente Alta
RFADOP40. Confirmar la venta Alta
RFADOP41. Registrar pagos Alta
RFADOP42. Registrar estado de pago Alta
RFADOP43. Registrar fecha de venta Alta
RFADOP44. Listar ventas Alta
RFADOP45. Editar las ventas Alta
RFADOP46. Exportar reporte de las Alta

ventas
VENTA RFADOP47. Generar factura Alta
RFADOP48. Registrar factura Alta
RFADOP49. Imprimir factura Alta
RFADOP50. Enviar factura al correo Alta

del cliente
RFADOP51. Registrar tipo de moneda Alta
RFADOP52. Editar tipo de moneda Alta
RFADOP53. Eliminar tipo de moneda Alta
154
Sprint 6. MODULO VENTA:
En este módulo el sistema debe ser capaz de gestionar las ventas de la empresa, se debe
visualizar los productos, y clientes, si es cliente nuevo, debe registrarlo, controlar la
cantidad de productos, el sistema debe ser capaz de registrar la venta.
1.34. RFADOP35. Realizar venta:
1.34.1. Objetivo:
Registrar las ventas realizadas para contar el reporte de estas.
El sistema debe ser capaz de registrar las ventas para tener el listado
de los productos que se vendieron y qué cliente lo compró.
Los datos que se registran son:

- Código de venta: De permitir ingresar hasta 50 caracteres.
- Fecha de venta: Debe permitir ingresar datos de tipo DATE.
- Producto: Debe permitir ingresar hasta 100 caracteres.
- Cantidad: Debe permitir ingresar sólo números.
- Cliente: Debe permitir ingresar hasta 100 caracteres.
- Monto total: Debe permitir ingresar sólo números.
- Pago: Debe permitir ingresa sólo números.
- Estado de pago: Debe permitir ingresar 50 caracteres.
1.34.3. Prioridad:
Alta
1.34.4. Prototipo:
155
A continuación, se visualiza la ventana donde se realizan las ventas:
1.35. RFADOP36. Buscar producto:
1.35.1. Objetivo:
Encontrar el o los productos que se va a vender.
El sistema debe ser capaz de buscar el producto por el código o
nombre para poder seleccionar y registrar cuál o cuáles se venderá.
Este rol lo realiza el administrador y operador.
1.35.3. Prioridad:
Alta
1.35.4. Prototipo:
A continuación, se visualiza la ventana donde se muestra la opción de

buscar el producto
156
Y si se quiere agregar más productos sale la siguiente ventana:
157
1.36. RFADOP37. Revisar stock de producto
1.36.1. Objetivo:
Controlar la cantidad de productos para realizar la venta.
El sistema debe ser capaz de avisar si el producto no cuenta con la
cantidad de productos que se está solicitando.
1.36.3. Prioridad:
Alta
1.36.4. Prototipo:
A continuación, se visualiza la ventana donde se muestra el stock de
los productos seleccionados.
158
1.37. RFADOP38. Seleccionar producto
1.37.1. Objetivo:
Indicar el producto o productos que se venderán.
El sistema debe ser capaz de seleccionar el o los productos buscamos
que se venderán al cliente y poder registrar la venta.
1.37.3. Prioridad:
Alta
1.37.4. Prototipo:
A continuación, se muestra las ventanas donde se seleccionan los
productos:
159
160
1.38. RFADOP39. Buscar cliente
1.38.1. Objetivo:
Encontrar el cliente que comprará el producto.
El sistema debe ser capaz de buscar el cliente por el nombre o apellido
para poder seleccionar a quién se venderá.
1.38.3. Prioridad:
Alta
1.38.4. Prototipo:
A continuación, se visualiza la ventana donde se muestra la opción de
buscar el cliente:
161
1.39. RFADOP40. Seleccionar cliente
1.39.1. Objetivo:
Indicar quién está realizando la compra.
El sistema debe ser capaz de seleccionar un cliente que realizará la
compra del producto.
1.39.3. Prioridad:
Alta
1.39.4. Prototipo:
A continuación, se visualiza la venta donde se selecciona el cliente:
162
1.40. RFADOP41. Confirmar la venta
1.40.1. Objetivo:
Realizar la venta.
El sistema debe ser capaz de confirmar la venta que se está realizando,
para ello muestra los datos que se están registrando, y “Aceptar” si
todo está correcto.
1.40.3. Prioridad:
Alta
1.40.4. Prototipo:
A continuación, se visualiza la ventana donde se realiza la
confirmación de la venta:
163
1.41. RFADOP42. Registrar pagos
1.41.1. Objetivo:
Indicar los pagos que realiza el cliente.
El sistema debe ser capaz de registrar los pagos que realiza el cliente,
puede darse el caso, que el cliente paga en partes, entonces el estado
indica si debe o no.
1.41.3. Prioridad:
Alta
1.41.4. Prototipo:
A continuación, se visualiza la venta donde indica el registro de pagos.
164
1.42. RFADOP43. Registrar estado de pago
1.42.1. Objetivo:
Indicar si el cliente debe.
El sistema debe ser capaz de indicar el estado de pago, y esto será de
acuerdo si el cliente realizó el pago total de la venta.
1.42.3. Prioridad:
Alta
1.42.4. Prototipo:
A continuación, se visualiza la ventana donde muestra el estado de
pago:
165
1.43. RFADOP44. Registrar fecha de venta
1.43.1. Objetivo:
Conocer la fecha que se realizó la venta.
El sistema debe ser capaz de registrar la fecha de venta que se realiza,
para poder conocer que mes se vendieron más productos.
1.43.3. Prioridad:
Alta
166
1.43.4. Prototipo:
A continuación, se visualiza la ventana donde se registra la fecha de la
venta:
1.44. RFADOP45. Listar ventas
1.44.1. Objetivo:
Contar con el registro de las ventas.
Al registrar cada ventar el sistema debe ser capaz de listarla, para que
se pueda visualizar las ventas realizadas.
1.44.3. Prioridad:
Alta
167
1.44.4. Prototipo:
A continuación, se visualiza la ventana donde se listan las ventas:
168
Luego al dar en “Ver” se podrá visualizar todos los datos registrados de la
venta:
1.45. RFADOP46. Editar las ventas
1.45.1. Objetivo:
Corregir el registro de la venta.
El sistema debe ser capaz de editar sólo los datos del producto, o
cliente, porque puede existir errores. Al dar click en la opción de
editar, debe mostrar un modal con los datos registrados para poder
corregir.
Este rol debe realizar el administrador y operador.
1.45.3. Prioridad:
Alta
1.45.4. Prototipo:
169
A continuación, se visualiza la ventana donde se encuentra la opción
de editar:
1.46. RFADOP47. Exportar reporte de las ventas
1.46.1. Objetivo:
Contar con el listado de ventas en formato Excel.
El sistema debe ser capaz de exportar el lisado de ventas en formato
.xlsx, esto permite tener guardado los archivos de listado de ventas y
poder limpiar el listado que se encuentra en el sistema.
1.46.3. Prioridad:
Alta
170
1.46.4. Prototipo:
A continuación, se muestra la ventana donde se encuentra la opción
de exportar el listado de las ventas.
1.47. RFADOP48. Generar factura
1.47.1. Objetivo:
Demostrar la venta que se realizó.
El sistema será capaz de generar una factura o boleta para entregar al
cliente, registrando el producto que se vendió.
1.47.3. Prioridad:
Alta.
1.47.4. Prototipo:
171
A continuación, se visualiza la ventana donde se indica el tipo de
comprobante que se va a generar:
1.48. RFADOP49. Registrar factura
1.48.1. Objetivo:
Guardar los comprobantes de pago de las ventas que se realizaron.
El sistema debe ser capaz de guardar las facturas que han sido
generadas por venta.
1.48.3. Prioridad:
Alta
1.48.4. Prototipo:
A continuación, se visualiza la ventana donde se guarda la factura:
172
1.49. RFADOP50. Imprimir factura
1.49.1. Objetivo:
Entregar el comprobante de pago al cliente.
El sistema debe ser capaz de dar la opción de imprimir el comprobante
de pago de la venta realizada al cliente. Esto permite entregar de
forma física al cliente.
1.49.3. Prioridad:
Alta
1.49.4. Prototipo:
173
A continuación, se visualiza la ventana donde muestra la opción de
imprimir factura:
1.50. RFADOP51. Enviar factura al correo del cliente
1.50.1. Objetivo:
Permitir al cliente tener guardada la factura de forma digital.
El sistema debe ser capaz de enviar la factura al correo del cliente que
realizó la compra. Porque el cliente puede perder la factura impresa y
permite tenerlo guardada.
1.50.3. Prioridad:
Alta
174
1.50.4. Prototipo:
A continuación, se visualiza la ventana donde al dar “Generar” se envía
la factura al correo del cliente:
1.51. RFADOP52. Registrar tipo de moneda:
1.51.1. Objetivo:
Registrar que forma de pago habrá como opciones.
El sistema debe ser capaz de registrar los tipos de moneda, y estos se
visualizarán cuando realiza la venta.
1.51.3. Prioridad:
Alta
1.51.4. Prototipo:
A continuación, se visualiza la ventana donde se registran los tipos de moneda:
175
1.52. RFADOP53. Editar tipo de moneda:
1.52.1. Objetivo:
Corregir los tipos de monedas registrados.
El sistema debe ser capaz de editar los tipos de moneda, y así corregir algún
error.
1.52.3. Prioridad:
Alta
1.52.4. Prototipo:
A continuación, se visualiza la ventana donde se editan los tipos de moneda:
176
1.53. RFADOP52. Eliminar tipo de moneda:
1.53.1. Objetivo:
Quitar el tipo de moneda que no será como opción de pago para las ventas.
El sistema debe ser capaz de eliminar los tipos de moneda, esto para quitar la
forma de pago que ya no permitirá la empresa para las ventas.
1.53.3. Prioridad:
Alta
1.53.4. Prototipo:
A continuación, se visualiza la ventana donde se eliminan los tipos de moneda:
177
178

Informe Final

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Informe Final

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA

FACULTAD DE INGENIERÍA EN INFORMÁTICA Y SISTEMAS

INFORME FINAL DE PRÁCTICAS PRE PROFESIONALES

“INGENIERÍA DE REQUISITOS DEL SISTEMA DE FACTURACIÓN PARA LA EMPRESA

Presentado por : Fátima Pierina ROUILLON SIXTO

Asesor : Ing. Brian PANDO SOTO

Periodo de Prácticas Pre Profesionales : 12/03/2018 – 12/06/2018

Lugar de las Prácticas Pre Profesionales : ROUILLON CONSULTING E.I.R.L.

Tingo María – Perú

Dedicado a Dios y a mi familia,

ya que ellos son las personas

más importantes en mi vida,

en mi formación personal y profesional.

A nuestro señor Jesucristo, por bendecirme y nunca

desampararme, dándome las fuerzas para cumplir mis metas.

A mis padres, María y Rodolfo, por ser mis pilares,

por inculcarme valores en mi vida y por su apoyo incondicional.

A mis hermanos, César y Eleazar, por ser mis guías

y por los ánimos que me dan.

A mi asesor Brian Pando, por orientarme en el

Cuadro 1: Herramientas y técnicas para análisis de requisitos ....................................................... 16

En la actualidad muchos desarrolladores de software tienen como gran inquietud saber si

La empresa Rouillon Consulting necesita del sistema de facturación, y solicitaron 3

En el capítulo 1: Describe algunas características de la empresa Rouillon Consulting,

En el capítulo 2: Se describen el marco teórico y marco conceptual que sirvió para el

En el capítulo 3: Se explica el desarrollo de actividades realizado durante el periodo de la

Finalmente se detalla los resultados, conclusiones y anexos.

CARACTERÍSTICAS GENERALES DE LA ORGANIZACIÓN

ROUILLON CONSULTING E.I.R.L.

Distrito: San Juan de Lurigancho

Dirección: Av. Central Mza. L lote 15 Urb. Los Heraldos

1.2. MISIÓN Y VISIÓN

Brindar soluciones que cubran las necesidades estratégicas de nuestros

Ser reconocidos como una de las principales empresas de soluciones de

MARCO TEÓRICO Y CONCEPTUAL

2.1. MARCO TEÓRICO

2.1.1. Ingeniería de requisitos

Un requisito de software es una propiedad que debe ser exhibido para

La Ingeniería de Requisitos (IR) cumple un papel primordial en el proceso de

La ingeniería de requisitos es en esencia la aplicación de principios, métodos,

Fuente: (Bourque & Dupuis, 2004)

2.1.2. Requisitos funcionales

2.1.3. Elicitación de requisitos

Se realiza para identificar fuentes potenciales de documentación

2.1.3.2. Categorías de los Stakeholders

Es necesario definir las categorías de los Stakeholders para

Figura 2: Categoría de los Stakeholders

Clientes Usuarios Otros

Patrocinador Product Usuarios Usuarios Consejeros Proveedores

Fuente: (Wiegers, 2003)

2.1.3.3. Perfil de los Stakeholders

El perfil de los Stakeholders es una descripción que caracteriza a

- Educar al equipo acerca de las expectativas del cliente.

2.1.3.4. Identificar técnicas combinadas de elicitación

Técnicas que permiten obtener información relevante a partir de

- Entrevistas con los Stakeholders.

2.1.4. Análisis de requisitos

Para analizar los requisitos:

- Modelo de negocio (Si es necesario)

Fuente: (Gottesdiener, 2009)

2.1.4.1. Herramientas y técnicas para analizar requisitos

A continuación, en la tabla se indican las técnicas y herramientas

Cuadro 1: Herramientas y técnicas para análisis de requisitos