1. Utilice el video titulado INGENIERÍA DE REQUERIMIENTOS.

1.1.Defina en sus propias palabras Requerimiento, Ingeniería de Requerimientos,

Requerimiento Funcional y No Funcional.

 Requerimiento

Son solicitudes que se hacen para construir un sistema, cuales solicitudes son
documentadas. Es saber o mejor dicho es una exigencia que se tiene para poder
funcionar de manera correcta en este caso de un software.

 Ingeniería de requerimientos

Son aquellas herramientas que utilizan los ingenieros en sistema para obtener los
requerimientos de manera óptima, con el fin de cuantificar un sistema que cumpla
los requisitos prestablecidos.

 Requerimiento funcional

Son aquellos requerimientos que hacen posible lograr los objetivos de un sistema.

 Requerimiento no funcional

Son aquellos no tan notables, pero que trazan frontera en un sistema. Son
características tienen que ver e de una u otra forma puedan limitar el sistema, ya
sea en mantenimiento, equipos, etc.

1.2.Defina en pocas palabras las características que debe tener un Requerimiento.

Deben de ser medibles, se pueden evaluar a ver si cumple con lo requerido, debe
de ser conciso. Las características que debe de tener es que sea conciso,
completo, verificable, que no sea ambiguo, entre otras.

1.3.Resuma las posibles dificultades al definir requerimientos.

Los clientes no suministran:

Información adecuada.
Tienen una idea de lo que requieren, pero tiende a confundir las
necesidades.

El cliente puede:

Cambiar de requerimientos a los largo de desarrollo.

Esto pasa con cuando cambian totalmente, para esto si se hace
requerimiento muy general es difícil de llegar a lo específico.

No expresar exactamente lo que quiere.

Expresan con palabras de varios significados algo diferentes a lo
que quieren lograr.
1.4.Resuma las ventajas al aplicar Ingeniería de requerimientos.

Llegamos a una solución sistemática.

Se llega a la conclusión de lo solicitado por el cliente de forma eficiente.

Ayuda los procesos de negocio.

Ayuda a la toma de decisiones y a eficientica los procesos que aplican de
forma directa e indirecta.

Ayuda a cumplir la solución inicial propuesta.

Cumple con los requisitos pautados desde el inicio.

Mejora la calidad del sistema.

Aplicando formulas y procesos de desarrollo evita mal desempeño para el
sistema.

1.5.Defina las actividades básicas de la IR. Incluya un ejemplo de su proyecto en

cada una.
Extracción.
Es la captación de información por parte de los desarrolladores, para
conocer el problema del cliente.

Ejemplo.
Cliente quiere automatizar los procesos de solicitud de préstamos en una
institución financiera. Aquí se puede aplicar las reuniones TFEA. Al final se
debe tener un sistema que cumpla con este servicio.

Análisis.
En esta parte se conceptúan los requerimientos, se comparten información
para estar claro en todos los requerimientos.

Ejemplo.
Cuando se sabe los requerimientos para llevar a cabo la solicitud del
préstamo, se debe saber de forma detallada que conlleva cada proceso
independiente.

Especificación.
En esta parte se documentan los requerimientos en base los hablado y
establecido en el análisis, llevando técnicas y procedimientos para la
práctica.

Ejemplo.
Si en análisis de describe que para crear una solicitud se debe de registrar
el cliente en el módulo USUARIO, en la especificación se detalla la
características que debe de tener un usuario para ser creado en el sistema.

Validación.
Lleva a cabo la evaluación de que este descrito todo los requerimientos y
que pueda ser leído de forma clara.

Ejemplo.
Crear usuario. Este requerimiento la persona debe de aportar su documento
de identidad y electoral o pasaporte extranjero.
1.6.Elabore un cuadro comparativo con ventajas y desventajas de las técnicas y
herramientas usadas en la IR.
Técnicas.

Extracción.
Ventajas Desventajas
Se trazan objetivos
claros del Se pierde gran tiempo en la práctica
sistema. sino se tiene experiencia.
Se puede aproximar el tiempo de
entrega, de forma más segura.

Análisis.
Ventajas Desventajas
Se abarca más de cada proceso. Si no hay conocimiento del tema
dentro del grupo, hay que buscar
soluciones externas
El conocimiento se comparte.
Surgen nuevos requerimientos.

Especificación.
Ventajas Desventajas
Todos los requerimientos quedan No todas personas tienen capacidad de
plasmado en papel, los cuales sean describir un requerimiento legible.
legibles.

Análisis.
Ventajas Desventajas
Se puede corregir errores.
Se pueden definir nuevos
requerimientos.
Se mejora la calidad de los
requerimientos.
Herramientas.

Entrevistas y cuestionarios.
Ventajas Desventajas
Se obtiene información precisa. Es tedioso y aburrido para los clientes
Se detallan los procesos con personas Es tedioso para el cliente pautar las
indicadas. reuniones.

Sistemas existentes.
Ventajas Desventajas
Se pueden verificar las interfaces del No en todos los casos hay sistemas
sistema con el objetivo de mejorar. existentes.
No todos los clientes permiten
verificar el sistema existente.

Lluvias de ideas.
Ventajas Desventajas
Brote de ideas, don hay muchas Se debe de calificar un buen personal
buenas. que cumpla con el objetivo.
Se debe tomar en cuenta todas las Los participantes deben de tener
ideas mucha experiencia.
Se permite la evolución de todas las
ideas.
De una idea se puede tomar otra idea

Prototipos.
Ventajas Desventajas
Se tiene una idea clara de lo que se Toma tiempo en fabricarlo.
quiere.
se puede reutilizar, Cliente debe tener tiempo para
evaluarlos.
2. Utilice el documento PDF titulado ESPECIFICACION DEL SISTEMA.

2.1.Sobre las estadísticas expuestas a inicio del documento, tanto del Chaos
REPORT como de otras fuentes, y según su experiencia o lo que usted conoce
del mercado nacional de software, establezca una lista ordenada de los
problemas especificados, en orden de gravedad del problema. Explique su
razonamiento en cada una.

Problema Razonamiento
31.1% cancelados. Por falta de continuidad de los
requerimientos.
52.7% costara más de lo estimado. Se estima un costo sin una base.
16.2% se cumple pero no completo. No se hace un diagrama de tiempo.
45% tiene origen en los requisitos. No se elabora una ingeniera de
requerimiento que cumplan con las
necesidades.

 Otras:

1. Falta del involucramiento del usuario 12.8% (Falta de comunicación)

2. Requerimientos y especificaciones poco claras 12.3% (Requisitos incompletos)
3. Cambio de requerimientos y especificaciones 11.8% (Cambios y requisitos
contienen muchos errores)
4. Poco apoyo de las gerencias involucradas 7.5% (Desacuerdos entre usuarios y
desarrolladores)
5. Tecnología deficiente 7.0% (Requisitos contienen demasiados errores)
6. Falta de recursos 6.4% (No Satisface)
7. Expectativas poco realistas 5.9% (Imposible demostrar si cumple o no)
8. Objetivos poco claros 5.3%
9. Tiempos poco realistas 4.3% (Se gastara tiempo y dinero)
10. Nuevas tecnologías 3.7%
11. Otros 23.0% (No detectar errores, Expectativas no realistas, Falta de
planeamiento)

Para evitar estos problemas es necesario realizar una toma adecuada de requerimientos,
identificando claramente el proceso actual del que se está trabajando, los objetivos que
espera el cliente con el proyecto e identificar los riesgos que pudiesen existir para
conseguir este objetivo involucrado a las diferentes gerencias o referente a este para
conseguir el apoyo adecuado, esto nos permitirá tener una visión global del sistema para así
dimensionar su verdadera complejidad y planificar acorde al mismo.

La cual evitaríamos estos problemas específicos de errores, cambios e no detectar algún

tipo de problema anteriormente, puesto que estos mismo problemas producirían retratos en
el tiempo y costo.
2.2.Sobre los factores que conducen a fracaso en los proyectos de software,
especifique para cada uno una acción que debemos evitar para no provocar ese
factor.

Falta de comunicación con los usuarios.

Esto lleva a que los desarrollado deban de implementar un sin número de

citas para hablar vía tecnológica o física con los usuarios, con el fin de tener
una estrecha comunicación.

Requisito incompleto.

Aquí se debe detallar de forma profunda todas las características del

¿Qué? Y el ¿Cómo? Para llegar a los detalles mínimos de un requerimiento.

Cambios de los requerimientos.

Esto es debido a la inexperiencia del cliente, o cambios drásticos que ha n
surgido. Esto es algo inusual en un cliente, al menos que este sea inseguro de
su situación.

2.3.Elabore una definición de IR lo más completa posible a partir de la definición

expuesta.

Trata los principios, métodos, técnicas y herramientas que permiten descubrir,

documentar y mantener los requisitos para sistemas informáticos, en forma
sistemática y repetible, esta ingeniería aplicada por ingenieros de sistema está
basada en hacer que los sistemas funcionen en base a lo acordado realmente, lo
cual permite tener un buen final, partiendo de un buen inicio.
 2.4.Para el ejemplo del avión en la pista, detalle un ejemplo similar aplicable a un
proceso de su sistema.

Joan Tejada

Proceso de evaluación personal para otorgar un préstamo. En este sistema se

establece que se va a seguir el proceso de evaluación si y solo si califica en el buró
de crédito.

R: Proceso evaluación – sigue-> análisis externo

Para determinar si el cliente tiene antecedentes en el buró o no, existe un

contrato mediante la compañía financiera y la de consultoría de datos, la cual
permite tener un procedimiento que verifique el estado del cliente en el buró de
crédito.

D1- Procedimiento devuelto- buró limpio

D2- buró Limpio – análisis externo

M-ex: Proceso evaluación – sigue-> procedimiento devuelto

Bernardo Santos

Sistema de cotización de PC’S

En este sistema hay un requisito que establece, que la cotización puede ser habilitada si y
solo si los perfiles de la cotización se encuentra completos.

R: realizar_cotización -> perfiles_completos

Para detectar si la cotización se realizó, existen algunas especificaciones conectados con

los escenarios.

D1: especificaciones -> escenarios

D2: escenarios -> perfiles_completos

M-B: realizar_cotización -> especificaciones

Podemos comprobar que cuando M-B y dadas las descripciones D, se cumple R.

2.5.Para cada una de las áreas de esfuerzo de la IR, elabore un producto a
entregar relativo a su proyecto.

Conocimiento del problema.

Cuando se va a evaluar un cliente para otorgar préstamo, se debe de tener
en cuenta que se va a evaluar y que proporción tiene cada característica.

Evaluación y síntesis.
Se debe documentar lo anterior, para tener una base fija.

Modelado.
Son todos los burós de crédito que hay.

Especificación.
Características de cada buro.

Revisión.
Estar seguro de la información suministrada.

2.6.Especifique alguna recomendación para una correcta TFEA que no hayamos

incluido antes.

Recomendar una variación de las entrevistas buscando identificar el problema,

proponer elementos de solución, negociar diferentes enfoques y especificar un
conjunto preliminar de requisitos de la solución. A pesar de ir un paso más allá de
las entrevistas convencionales, participación del analista, utilizando caso de
estudios, técnicas de comunicación, entre otras.

2.7.Para cada uno de los problemas con la educción, especifique 2

recomendaciones prácticas que nos ayuden a evitarlos.

Los usuarios no pueden / saben describir sus tareas.

-Ayudarles a detallar las tareas con un orden cronológicos, se pueden tomar

notas de los pasos y después ordenarlos.

-Asegurarse de que el cliente en frente es la persona encargada o

conocedora de dicho proceso

Mucha información importante no llega verbalizarse.

-Se debe agotar toda la información de un proceso, preguntar desde quien

la inicia y como se termina.

-La persona que lleve la minuta o apunte, debe de ser capaz de llevar las
informaciones principales para luego culminar de organizar ideas.

La educción es un proceso cooperativo.

 -Se deben aceptar y cumplir su rol en el proyecto.

2.8.Para cada uno de los tipos de requisitos expuestos, especifique uno de su

proyecto, incluyendo un requisito en negativo.

Joan Tejada

-Los equipos deberán trabajar a 15 grado selacio.

-El sistema evaluara a los usuarios de forma automática.
-Se requiere de 20 minutos para interpretar el sistema sin ayuda.
-El sistema no dependerá de la web para trabajar de forma óptima.

Bernardo Santos

Requisitos que definen efectos sobre el entorno

- El sistema tendrá 5 tipos de perfiles.
- El sistema no puede tener más de 5 perfiles.

Requisitos muy generales

- El sistema mantendrá un registro de todos los accesorio de las PC’S, memoria,
Discos.
- El sistema tiene que mantener todos sus registros.

2.9.Especifique un requisito donde crea necesaria utilizar negociación de

requisitos, aplicable a su proyecto.

Joan Tejada

- El sistema no proveerá información a usuarios sin estar bajo revisión de

seguridad.
Bernardo Santos

Cotización de Pc’s

Ejemplo:

En desarrollo de cierta aplicación en este caso para TRENDING CONSULTING el

departamento de cotizaciones quiere tener acceso total a todos los recursos almacenados
de los perfiles, escenario y lista de clientes, mientras que en la seguridad y venta quieren
controlar dichos recursos y permitir solo un acceso restringido.

Negociación
- Discutir los requisitos conflictivos.
- Establecer prioridades en los requisitos.
- Compromiso final de los conjunto de requisitos.

2.10. Defina los documentos DRU y ERS y proporcione un ejemplo de cada uno.

 DRU (Documento de Requisitos de Usuario)

Describe el punto de vista del usuario/cliente/interesado. Esta mayoría de

veces no poseen muchos detalles, incluyen la descripción del problema actual
y metas que se espera lograr con la construcción del sistema.

 ERS (Especificación de Requisitos Software)

Es un conjunto de casos de uso que describe todas las interacciones que tendrán
los usuarios con el software, descripción del comportamiento del sistema que se va
a desarrollar.

Ejemplo (Visualizando la diferencia DRU & ERS):

Definición de requisitos
 El Software debe acceder a ficheros externos creados por otras herramientas.
Especificación de Requisitos
 El usuario debe poder elegir el tipo de fichero externo.
 Cada tipo de fichero externo se puede asociar con la herramienta que produce ese
tipo de fichero.
 Cada tipo de fichero externo puede ser representado por un icono en la barra de
herramientas.
 Este icono puede ser definido por el usuario.
 Cuando el usuario selecciona uno de estos iconos el efecto es aplicar la herramienta
asociada a ese tipo de fichero.

Podemos notar como un único Requisito de Usuario (DRU), da lugar a varios Requisitos de
Software (ERS) con mucho más detalle.
2.11. Sobre las características de una buena ERS, elabore un ejemplo que
cumpla y no cumpla con cada una, aplicable a su proyecto y justificando
cada uno.

No Ambigua.

Cumpla. El usuario deberá tener identificación nacional y electoral para

solicitar préstamos.
Justificación. De esta forma no hay manera de interpretar si es una
cedula o pasaporte, tanto nacional o internacional. Solo cumple la
cedula nacional.

No cumpla. El usuario deberá tener cedula para realizar la solicitud de

préstamos.
Justificación. De esta roma el requerimiento se puede interpretar
de varias formas, si se acepta cedula dominicana y/ o extranjera.

Completa

Cumpla. Cedula debe de estar en buen estado y se extraerá toda la

información del cliente de la cedula de identificación y electoral.
Justificación. Para cumplir con la captación de información de
cedula, se debe cumplir la condición de buen estado, y la información
a extraer es todas en cuanto a la persona.

No cumpla. S e extraerá toda la información de la cedula de identidad y

electoral.
Justificación. En este caso no se determina cual es la información a
extraer y no hay ningún tipo de seguridad de que toda la información sea
legible.
2.12. Revise los estándares IEEE 830 y PSS-05 de la ESA y mencione 3 reglas
de cada uno para especificar requisitos correctamente.

IEEE 830 PSS-05

El documento deberá ser Se necesita menos de dos años
perfectamente legible por personas hombres de esfuerzos para el
de muy distintas formaciones e desarrollo.
intereses.
Deberán referenciarse aquellos Se quiere un equipo único de
documentos relevantes que poseen desarrollo de cinco o menos
alguna influencia sobre los personas.
requerimientos.
Todo requisito deberá ser La cantidad de código fuente es
unívocamente mediante algún código o inferior a 10000 líneas
sistema de numeración adecuado.

2.13. Mencione 5 sugerencias prácticas para efectuar una buena revisión de

requerimientos.

1) Que sea verificable.

(Son realmente probable)

2) Que sea entendible.

(Son comprendidos propiamente)

3) Que sea probable.

(Están claramente establecidos)

4) Que sea adaptables.

(Puede realizar cambios sin causar impacto en otros requerimientos).

2.14. Investigue en la web sobre una herramienta de Gestión de Requisitos y

evalúela a la luz de lo aprendido hasta ahora.

Herramienta:

Doors (IBM RATIONAL DOORS)

Se elige esta herramienta basándome en todo los aspecto de la Ingeniería de

Requerimientos, puedo decir que esta herramienta DOORS es muy completa
siguiendo las reglas de implementar una buena ingeniería de requerimientos,
DOORS crea planes de prueba y mediciones de rendimiento, posee las
características básicas de una buena gestión y ERS.

Esta herramienta nos permitirá mejorar la colaboración entre los equipos e

clientes y proveedores, también tiene un control de trabajo de cambios, es
ambiguo y mantiene la trazabilidad entre los requisitos.
3. Utilice el video COMO IDENTIFICAR REQUERIMIENTOS DE UN SISTEMA.

3.1. Evalúe si en la definición de requerimiento o en sus características existe

algún elemento nuevo que no hayamos visto hasta ahora.

Definición.

Si, anteriormente no se había dicho que es una capacidad del sistema

necesario por el usuario para resolver un problema.

Características.

Evita detalle del diseño. Esta parte no se había contemplado en las

características de los requerimientos de sistemas.

3.11. Basado en el organigrama de requerimientos no funcionales, mencione uno

correspondiente a cada tipo, investigando datos adicionales si es necesario.

Producto
1. La aplicación no podrá ocupar más de 2 GB de espacio en disco.
2. La interfaz de usuario será implementada para navegadores web
únicamente con HTML5 y JavaScript.

Organizacionales
1. Debe especificarse un plan de recuperación ante desastres para el
sistema a ser desarrollado.
 2. Cada dos semanas deberán producirse reportes gerenciales en los cuales
se muestre el esfuerzo invertido en cada uno de los componentes del nuevo
sistema.

Externos
1. Las páginas web a ser desarrolladas deben cumplir con la ley de
tratamiento en condiciones de igualdad para personas con discapacidad.
2. El sistema no revelara a sus operadores otros datos personales de los
clientes distintos a nombres y números de referencia.

Eficiencia
1. El sistema tiene que ser capaz de procesar N transacciones por segundo.
2. Toda funcionalidad del sistema y transacción de negocio debe responder
al usuario en menos de 10 segundos.

Fiabilidad
1. El sistema debe ser tolerante ante los fallos y las operaciones a realizar
deben ser transaccionales.

Portabilidad
1. El sistema diseñado y sus componentes deben ser portables en
plataformas GNU/Linux y Windows, con máquinas que presentan
arquitecturas de 64 bits.

Interoperabilidad
1. El sistema debe estar en capacidad de interactuar con los otros sistemas
de la PGN y con sistemas de entidades externas a través de la herramienta
de middleware seleccionada para el sistema.

Usabilidad
1. El sistema debe proporcionar mensajes de error que sean informativos y
orientados a usuario final.
2. El sistema debe contar con un módulo de ayuda en línea.

Implementación
1. El sistema posee menús que ayuden con una ágil navegación.

Legislativos
1. La aplicación debe cumplir con lineamientos, políticos y/o regulaciones de
la entidad que utilice el sistema.

Rendimiento
1. El sistema deberá responder en el mínimo de tiempo posible ante las
solicitudes de información por parte de otros sistemas y en el
procesamiento de la información.
Seguridad
1. Los permisos de acceso al sistema podrán ser cambiados solamente por el
administrador de acceso a datos.
4. Utilice el video titulado TIPOS DE REQUERIMIENTOS - EJEMPLO CASA DE
CAMBIO. El mismo detalla las especificaciones de requerimientos para un caso
particular. Aplique este ejemplo paso a paso a su proyecto, elaborando cada uno
de los detalles incluidos.

Joan Tejada

Evolución de crediticia de un cliente para préstamos.

Objetivo. Definir los procesos automáticos, para mejora la velocidad y asegurar la

toma de decisiones.

Roles.

Cliente.

A – Plataforma web

*Realizar consultas de:

Tipos de préstamos.
Requisitos por cada préstamo.
Tasa por tipo de préstamo.
Términos y condiciones.
Creación de solicitud.
Verificación de estado de solicitud.

Representante de servicio.

*Operaciones presenciales
Solicitud de préstamos.
Verificación de solicitud.
Captación de información para solicitud.

Representante de crédito.

*Realizar consultas de:

Tipos de préstamos.
Requisitos por cada préstamo.
Tasa por tipo de préstamo.
Términos y condiciones.
Creación de solicitud.
Verificación de estado de solicitud.

*Operaciones presenciales
Consulta las solicitudes.
Modificación de datos.
Integra los usuarios.

Modulo.
Presencial.

1. Creación de solicitud. Aquí el representante de servicio al cliente introduce los

datos del cliente o en dicho caso verifica y actualiza si es necesario. Llevando así el
historial de las solicitudes.
2. Verificación de crédito. Se solicita la evaluación del cliente más la solicitud, para
hacer toma de decisión de si el cliente aplica o no para dicha solicitud.
3. Verificación de solicitudes. Aquí se verifica los estados de cada solicitud realizada,
y se puede cambiar manualmente en caso de anomalía o falla de proceso.

Vía WEB.
-El cliente no debe de registrarse para visualizar los servicios
 Bernardo Santos
 Introducción

Consiste en un Software de Cotizaciones y operaciones de venta, para TREDNDING

CONSULTING, se cumplirá con las etapas de la ingeniería de Software s que permiten
obtener un producto de calidad.

En estos momentos nos encontramos en la primera fase del proceso de desarrollo para una
nueva implementación y servicio para lograr la máxima satisfacción del cliente, la etapa de
especificación de requisitos. Esta etapa es fundamental pues indicara lo que el cliente
necesita y lo que finalmente hace el software. Debe ser validado por el cliente para luego
presentar una cotización de los perfiles obtenidos y el modelo conceptual del software.

 Objetivo

Del sistema propuesto el objetivo es apoyar las actividades de inventario, la generación de

cotizaciones, así como también entregar una herramienta ágil, para el manejo de esas
cotizaciones que se generan, proporcionando por ejemplo, un método de búsqueda de datos,
una relación directa con los perfiles y una mayor productividad en los formatos de
cotizaciones para los clientes, para mejorar los procesos de venta y obtener indicadores de
gestión por medio de reportes donde se puede hacer seguimientos de los clientes.

 Roles (Cliente-Operador-Administrador)
- Requerimientos

 Cliente:

 Operaciones Virtuales

1. Página Web debe ser Multilenguaje

Tener Reportes

2. Realizar pagos virtuales (Modalidades de Pago)

- Tarjeta de Crédito/ Debito
 Visa
 MasterCard
 PayPal
- Cheques
 3. Realizar Consultas
- Disponibilidad de Equipos
- Tipos de Perfiles
- Límite de crédito
- Precios
- Garantía

4. Servicio de Delivery
5. Servicio Al Cliente
- Operadores Online
- Chat Online

6. Ruta Online
7. Factura Electrónica

 Operador:

 Operaciones Presenciales

1. Realizar Ventas
2. Realizar Asistencia
- Quejas
- Verificación
- Consulta
- Asesoría
3. Consultar las modalidades de pago
- Tarjeta de Crédito/Debito
- Cheques
- Transacciones
- Conciliación Bancaria
4. Emitir Facturas

 Administrador:

 Operaciones Virtuales

1. Seguimiento de las Estadísticas de ventas

2. Seguimiento de las Estadísticas de Modalidades de Pago
3. Seguimiento de las Estadísticas de los escenario (Cotizaciones)
4. Consultar quejas
5. Consultar las Estadísticas de las rutas realizadas (Envíos)

 Operaciones Presenciales
1. Tener Acceso al Inventario: modificar/agregar/borrar los productos, los tipos de
productos que existen, imprimir reportes del listado actual del inventario
(Cotizaciones), por Día-Mes-Año.
2. Realizar Consulta de los procesos realizado con mayor influencia.
3. Acceso a las conciliaciones de bancos.
4. Consultar contabilidad.

 Requerimientos Funcionales

 Modulo WEB

1. “Trending Consulting” ofrecerá informaciones de índole de la empresa y equipos

afines, opción de multilenguaje básicos (Español, Inglés, Francés)
2. Conciliación de bancos
3. Consulta de precios
4. Consulta de Estado de Crédito del cliente
5. Venta vía domicilio, donde se cancela la realización de la entrega a través de un
IPAD.
6. Identificación del cliente, cada cliente que ingrese al portal tiene el deber de
registrarse para tener un control de sus operaciones.
7. Este módulo tendrá Operadores Online para cualquier problema, sugerencia, ayuda,
entre otras adyacente que tenga un cliente.
8. El Cliente podrá realizar comparaciones o consultas de los escenarios presentados
de su cotización.
9. El Sistema debe generar cotizaciones, además debe dar la opción de imprimir el
documento, se registraran las cotizaciones emitidas con la información del cliente,
productos y servicios cotizados y fecha de cotización.

 Módulo de Operaciones

1. Permitirá verificar disponibilidad de los productos en el Stock.

2. El Sistema debe entregar reportes de inventario.
3. El Sistema debe generar Cotizaciones.
4. Registro de ventas, donde se realizara un formulario con las siguientes
características.
- Datos Personales
- RNC
- Cedula
- Pasaporte
- NCF
- Monto
5. Permitirá almacenar la información asociada a cada producto(PC’S) esta
información:
- Código
- Nombre
- Marca
- Modelo
- Descripción
- Precio
6. Luego se efectuara de esas operaciones realizadas:
- Factura o Bauche de esas operaciones

7. A la finalización de todo se genera un reporte final donde se especificaran todo los

detalles de la venta (Monto, Especificaciones, Perfiles).

8. Permitirá verificar disponibilidad de los productos en el Stock, al momento de

generar una cotización.

9. Registrar – Modificar cotizaciones y ordenes de trabajos

10. Realizara búsqueda sobre productos y servicios
11. Realizara consulta
 Buscar Clientes
 Verificar Informaciones
12. Orden de trabajo tendrá un estado (En proceso, terminada)
13. Podrá realizar modificaciones a una orden de trabajo

 Módulo de Administración

1. WEB

Ya que el administrador tiene control absoluto del sistema, pues pondrá ingresar al
módulo del sistema ya sea por código o pasando su carnet de identidad que contiene
una barra encriptada que le permitida el acceso y realización de sus operaciones
siguientes:

- Consultar Estadificas de venta

 Por Tarjetas (Debito/Crédito)
 Por Cheques
 Por Transacciones
- Consultar la disponibilidad del Stock de los equipos
- Consultar las conciliaciones de bancos
- Consultar Destinos de entrega
- Consultar Cotizaciones
- Consultar Quejas
 2. Presencial

Podrá Realizar:
- Registro - Modificación de los productos
- Registro – Modificación de Entregas
- Registro – Modificación de los clientes
- Registro de identidades clasificadas de los clientes
- Reportes de todas las operaciones que se realicen
 Grafico
 Por Excel
 Tablas
- Realizar operaciones con los bancos
- Medicación de Stock de los productos en cada compra que se realice.
- Permitirá eliminar clientes

 Requerimientos No Funcionales

 Desempeño

Por desempeño se hace referencia a la habilidad del sistema de procesar las operaciones de

un usuario individual dentro de unos tiempos de respuesta deseados. Para el sistema

TREDING CONSULTING se definen cuatro operaciones básicas que deben cumplir con

tiempos de respuesta deseados. A continuación se presenta una tabla con estas operaciones

y los tiempos de respuesta promedio esperados por el usuario para los mismos.
 PROCESO TIEMPO DE RESPUESTA ACEPTADO

100 Mbps
Presentación de pantallas con

información descriptiva o Entre 5 y 10 segundos

informativa. (Arboles

jerárquicos)
Presentación de formularios y Entre 5 y 10 segundos.

pantallas de Administración
Validación y confirmación de Entre 5 y 10 segundos

datos enviados.

 Legislativo

El Sistema debe cumplir con lineamientos, políticas y/o regulaciones de la entidad que
utilice el sistema.

 Implementación

El sistema posee menús que ayuden con una ágil navegación.

 Usabilidad

El sistema debe contar con un módulo de ayuda en línea.

Imagen Corporativa.

El sistema debe tener el logo de TRENDING CONSULTING además de un logo

identificador del sistema.

  Operacional

Por robustez se hace referencia a la capacidad del sistema de continuar en operación a

pesar de la entrada de datos inválidos o fallos en los diferentes componentes que lo

conforman.

Tolerancia a datos inválidos. La capacidad del sistema para tolerar tipos de datos

invalidados se evalúa cuando los datos son ingresados por el usuario en cada uno de los

diferentes campos de los formularios.

A continuación se describen las validaciones que debe tener en cuenta el sistema:

 Verificación de campos obligatorios:

El sistema debe verificar que los datos correspondientes a los campos obligatorios de los

formularios fueron ingresados por el usuario final.

 Verificación de campos numéricos.

El sistema debe verificar que los campos correspondientes a datos exclusivamente

numéricos no contengan caracteres de texto o caracteres especiales tales como comas,

puntos, asteriscos.

 Verificación de reglas de negocio.

En algunos casos el contenido de uno o varios campos de los formularios son válidos si

cumplen con unas reglas propias del negocio. El sistema debe hacer uso de estas reglas para

validar la integridad de la información ingresada.

 Eficiencia

El Sistema debe soportar una gran cantidad de datos.

 Externos

Las páginas web a ser desarrolladas deben cumplir con la ley de tratamiento en condiciones
de igualdad para personas con discapacidad.
  Seguridad

Se hace referencia a la habilidad del sistema de controlar el acceso a los servicios e

información del negocio; así como la capacidad de detectar, aislar y restablecer
continuidad ante una falla de seguridad.

La aplicación debe cumplir con unos requisitos mínimos de seguridad estas

características se describen a continuación:

 Seguridad de acceso al sistema

De acuerdo al nivel de seguridad, la aplicación permitirá a los usuarios registrados en

el Sistema el ingreso hacia las diversas funcionalidades, permitiendo el filtrado de

datos de acuerdo al rol o perfil del usuario.

 Tiempo activo de la sesión del usuario

La sesión de un usuario puede permanecer inactiva por un tiempo máximo de 20

minutos. El valor de este timeout debe poder ser parametrizado en los archivos de

configuración del sistema y se irá ajustando de acuerdo al análisis de rendimiento de la

aplicación una vez se encuentre en ambiente de producción.

 Navegación en el sistema

El usuario solo podrá navegar entre las páginas del sistema a través de las opciones que

le presenta la aplicación y solo podrá acceder a aquellas autorizadas para el rol

correspondiente.

 Manejo de Contraseñas

El sistema debe proveer las funcionalidades de autenticación. Para tal fin debe

proveer las interfaces de usuario necesarias para permitir las siguientes

funcionalidades:

o Pantalla para autenticación de usuarios en el sistema (Login y Password).

o Pantalla para cambio de contraseña del usuario. Debe pedir la contraseña

anterior y la nueva contraseña.

o Retroalimentación hacia el usuario si se producen errores durante el

proceso de autenticación.
Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de
acceso a datos.

 Desarrollo (Software / Instalación)

Para este sistema son: motor de base de datos, servidor Web/aplicaciones, navegador

Web, y máquina virtual de java.

- Base De Datos

El sistema utilizará el motor de bases de datos MySQL. El sistema no garantiza su

funcionalidad sobre otros motores de Base de Datos.

- Servidor Web De Aplicaciones

El sistema está diseñado para ser desplegado en un servidor JBoss o Tomcat.

- Navegador Web

El sistema debe ser implementado teniendo en cuenta que su funcionalidad debe poder ser

soportada sobre Microsoft Internet Explorer 6.0 en adelante.

- Máquina Virtual De Java

El sistema debe estar implementado teniendo en cuenta la versión 1.6 o superior de la

máquina virtual de java. El sistema no garantiza su funcionalidad sobre versiones

anteriores.