Especificación de Requisitos Según El Estándar de IEEE 830 v.2

Especificación de Requerimientos
según el estándar de IEEE 830 2.0

AO&C DEVS
Ixtac, 2022
Las Flores Distribuidor de Café Tostado

Aplicación Web
CONTROL DE VERSIONES DE DOCUMENTO
Nombre Especificación de Requisitos según el estándar de
IEEE 830
Versión 2.0
Fecha de Creación Lunes, 29 de agosto de 2022
Fecha de Modificación Domingo, 02 de octubre de 2022
Razón de Cambio Modificaciones en redacción
Autor Guadalupe Cristina Reyes Lucas
INTEGRANTES DEL EQUIPO

Odraude Méndez Aguirre – Scrum Máster y jefe de Equipo de Desarrollo
Ayrton Raúl Bolaños Waldo – Equipo de desarrollo
Guadalupe Cristina Reyes Lucas – Produc Owner
LÍDER DEL PROYECTO:

Odraude Méndez Aguirre
CLIENTE
Las Flores Distribuidor de Café
Especificación de Requisitos según el estándar

de IEEE 830
IEEE Std. 830-1998
Este documento presenta el formato de Especificación de Requisitos Software (ERS) según la

última versión del estándar IEEE 830. Según IEEE, un buen Documento de Requisitos, pese a no
ser obligatorio que siga estrictamente la organización y el formato dados en el estándar 830, sí
deberá incluir, de una forma o de otra, toda la información presentada en dicho estándar. El
estándar de IEEE 830 no está libre de defectos ni de prejuicios, y por ello ha sido justamente
criticado por múltiples autores y desde múltiples puntos de vista, llegándose a cuestionar incluso si
es realmente un estándar en el sentido habitual que tiene el término en otras ingenierías. El
presente documento no pretende pronunciarse ni a favor ni en contra de unos u otros: tan sólo
reproduce, con propósitos fundamentalmente docentes, cómo se organizaría un Documento de
Requisitos según el estándar IEEE 830.
Contenido
1. Introducción...............................................................................................................................5
1.1. Propósito............................................................................................................................5
1.2. Ámbito del Sistema............................................................................................................5
1.3. Personal Involucrado..........................................................................................................6
1.4. Definiciones, Acrónimos y Abreviaturas............................................................................7
1.5. Referencias.........................................................................................................................8
1.6. Visión General del Documento..........................................................................................8
2. Descripción General...................................................................................................................9
2.1. Perspectiva del Producto....................................................................................................9
2.2. Funcionalidad del Producto..............................................................................................10
2.3. Características de los Usuarios.........................................................................................10
2.4. Restricciones....................................................................................................................10
2.5. Suposiciones y Dependencias...........................................................................................11
2.6. Requisitos Futuros............................................................................................................11
3. Requisitos Específicos..............................................................................................................12
3.1. Requisitos comunes de los interfaces...............................................................................12
3.1.1 Interfaces de Usuario.......................................................................................................12
3.1.2. Interfaces de Hardware...................................................................................................15
3.1.3. Interfaces de software.....................................................................................................16
3.1.4. Interfaces de Comunicación...........................................................................................17
3.2. Requisitos Funcionales.....................................................................................................17
3.3. Requisitos No Funcionales...............................................................................................23
3.3.1. Requisitos de Rendimiento.......................................................................................23
3.3.2. Seguridad........................................................................................................................24
3.3.3. Disponibilidad................................................................................................................24
3.3.4. Mantenibilidad................................................................................................................25
3.3.5. Portabilidad....................................................................................................................25
3.4. Otros Requisitos...............................................................................................................25
1. Introducción
1.1. Propósito
Este informe se encuentra basado en el formato de Especificación de Requisitos de Software (ERS),

regido bajo el estándar IEEE830.
El documento busca definir de forma detallada y clara todos los requisitos, las funcionalidades y las
restricciones que debe poseer el software que desarrollaremos. En este caso: “Las Flores
Distribuidor de Café”.
El informe va orientado, tanto para el cliente como para todos los integrantes del grupo de trabajo,
con el fin de mantener a cada uno de estos informados de las características que tendrá el sistema.
Todos los requerimientos establecidos en este informe debieran ser suficientes para que nuestro
grupo de desarrolladores puedan crear el software, cumpliendo con lo exigido por el cliente y por
futuras revisiones que realizará la entidad QA, para su posterior aprobación
1.2. Ámbito del Sistema
El producto para desarrollar fue definido como: “Las Flores Distribuidor de Café Tostado
Aplicación Web”, sin embargo, el documento está enfocado en el desarrollo de los módulos para
“Las Flores Distribuidor de café”, siendo un sistema de gestión de ventas e información para esta
entidad, propuesta para una aplicación web.
Su función principal es la implementación de un punto de ventas y la filtración de correos para

spam de clientes que deciden aceptar notificaciones de la empresa, así como posibles clientes
prometedores como es el caso de cafeterías.
El sistema también contará con un enriquecido catálago de productos que permitiría realizar las
ventas en línea, El usuario administrador será capaz de editar y/o subir en el catálogo de productos,
información, precios, fotos y/o vídeos, así mismo tener el control del sistema en su respectiva
interfaz.
Además, el sistema tendrá otra interfaz para el usuario final en donde podrá realizar compras en
línea, tener información de los productos y de la empresa.
A su vez el sistema busca solucionar el problema que se presenta actualmente en ya mencionada
compañía, que trata sobre la expansión de zonas de ventas y la falta de una aplicación web dónde se
realicen las ventas en líneas de sus productos de café y sus derivados. La causante de esto sería la
baja efectividad de marketing publicados en redes sociales (Facebook) y la falta de manejo online
de los productos.
En conclusión, nuestro sistema reemplazaría la página web ya existente debido a su baja
productividad, obteniendo así eficiencia en los procesos de ventas e información con el fin de
facilitar las tareas a los usuarios del sistema
1.3. Personal Involucrado
Las siguientes tablas entregan datos relevantes que conforman nuestro equipo:
Jefe de proyecto:
Nombre Odraude Méndez Aguirre
Rol jefe de proyecto, scrum máster
Categoría profesional Ingeniero en software
Responsabilidades Organización de las tareas del equipo, scrum máster
Área de Gestión
Nombre Guadalupe Cristina Reyes Lucas
Rol Analista en gestión
Categoría Profesional Ingeniero en software
Responsabilidades Toma de requerimientos, entrevistas

Rol Ingeniería y Gestión
Responsabilidades Encargado de gestionar, recabar y documentar requerimientos

Rol Gestionar documentación
Responsabilidades Diseñar e implementar la documentación del sistema a crear
Nombre Ayrton Raúl Bolaños Waldo

Rol Gestionar documentación
Responsabilidades Diseñar e implementar la documentación del sistema a crear
Área de desarrollo

Rol Programador en jefe
Responsabilidades Encargado de programar las distintas clases del sistema
Nombre Ayrton Raúl Bolaños Waldo

Rol Desarrollador
Responsabilidades Diseñar y programar la interfaz gráfica (GUI), ensamblar todas las
partes del sistema.
Área de Desarrollo de Base de Datos

Rol Programador
Responsabilidades Encargado de DBA
Área de QA (Testing)

Rol Analista QA (Testing)
Responsabilidades Pruebas durante el desarrollo del software
1.4. Definiciones, Acrónimos y Abreviaturas
El siguiente apartado, describe cada uno de los acrónimos y abreviaturas encontradas a lo largo del
documento.
 ERS: Especificación De Requisitos De Software.

 ERP: Enterprise Resource Planning (Planificación de Recursos Empresariales).
 QA: Quality Assurance (Aseguramiento de la Calidad).
 IEEE 830: Estándar que comprende los requisitos del software.
 Sistema Operativo Windows 10: Programa que gestiona el comportamiento y permite el uso
del computador, Windows 10 se refiere a la versión de este.
 IDE Visual Studio 2020: Plataforma que permite a los desarrolladores crear programas o
aplicaciones.
 Apache NeatBeans: Plataforma que permite a los desarrolladores crear programas o
aplicaciones.
 Java: Es un lenguaje de programación.
 Downtime u Offline: Se refiere al tiempo que el sistema no está funcionando, ya sea por un
factor externo, un corte de luz, o que simplemente el programa esté funcionando mal y no
permita trabajar con él.
 Red Local: Una red de computadores conectados entre sí que pueden interactuar entre ellos.
 PostgreSQL: sistema de base de datos open source
 Source: Código Fuente
 Hardware: Conjunto de elementos físicos o materiales que constituyen una computadora o
un sistema informático.
 Software: Conjunto de programas y rutinas que permiten a la computadora realizar
determinadas tareas.
 SIEM: Sistema de Información Empresarial Mexicano Digital
 Marketing Digital: es la aplicación de las estrategias de comercialización llevadas a cabo en
los medios digitales.
 Interfaz: la conexión física y funcional que se establece entre dos aparatos, dispositivos o
sistemas que funcionan independientemente uno del otro.
 Scrum Máster: es el responsable de que se sigan las prácticas y valores descritos en el
modelo Scrum.
 El Sprint: en donde se realizan todas las acciones y se testea si las acciones realizadas
funcionan.
 El Burn Down: el análisis y control de las tareas ejecutadas y todo lo que queda pendiente
 Plataforma de integración de API de Github: plataforma alojada gratuita para conectar
aplicaciones y desarrollar automatizaciones basadas en eventos.
1.5. Referencias
Mediante el siguiente apartado, se expondrán el material de referencia utilizado para la elaboración

de este documento:
Título IEEE Std. 830-1998 Especificación de requisitos según el estándar

IEEE Computer Society
Ruta https://www.fdi.ucm.es/profesor/gmendez/docs/
iso80/ieee830.pdf
Autor IEEE
Título Modelo TCP/IP

Ruta https://es.wikipedia.org/wiki/Modelo_TCP/IP
Autor Wikipedia
1.6. Visión General del Documento
Desde ahora en adelante el documento estará compuesto por los siguientes puntos:
Una descripción general de lo que será el producto y que es lo que hará y cuál es su utilidad para el
usuario final. Las funcionalidades principales de este, que deben de realizar el cual estará detallado
de tal forma, que se entendible por el cliente, a la vez se mostrarán las descripciones y/o
características de los usuarios que interactuarán con dicho producto.
Una de las partes más importantes que se detallarán serán las restricciones de este, lo cual nos será
de gran ayuda para ver cuáles son los requisitos mínimos de nuestro sistema para lograr que
funcione de acuerdo con lo esperado.
A la vez se detallarán los posibles conflictos que se pueden generar en nuestro sistema al querer
modificarlo, junto a ello se detallarán las posibles evoluciones previsibles del sistema.
Otra de las partes importantes dentro de este documento serán los requisitos específicos, el cual
deberá de ser conciso para que nuestro equipo de desarrollo pueda diseñar el sistema sin problemas
y a cabalidad, dentro de los cuales se les mencionará los requisitos de interfaces, usuario, hardware,
software, comunicación, funcionales, los no funcionales que dentro de estos encontramos los
requisitos de rendimiento, seguridad, fiabilidad, disponibilidad, mantenibilidad y portabilidad.
2. Descripción General
2.1. Perspectiva del Producto
Se proyecta implementar un sistema de ventas, información y una filtración de correos para spam de
usuarios que acepten recibir notificaciones de nuevas promociones de la empresa independiente que
reemplace completamente la página antigua de la empresa, el cual no tendrá relación con otros
sistemas, dentro de sus módulos, éste debe permitir controlar la información y ventas del sistema, el
cual está enfocado este documento, mientras que otros módulos se encargaran de apoyarla.
El módulo del Sistema Gestor dependerá del módulo de Catálago de productos para realizar las
tareas de ventas de productos de café y sus derivados de esta, se necesitará el módulo de pedidos, en
este módulo se obtendrá toda la información necesaria, para él envió de los productos, otro modulo
necesario es el de Pago en línea, puesto que es obligatorio la realización de pagos por los productos,
por otro lado, es de suma importancia llevar el control de los pedidos ya realizados o enviados para
esto, se contará con el módulo Pedidos Realizados. El siguiente módulo imprescindible es el de
visualización de correos spam para establecer contacto con los usuarios que acepten dicho spam.
El siguiente diagrama representa un resumen de lo dicho anteriormente.
2.2. Funcionalidad del Producto
El producto de software a desarrollar, a grandes rasgos y cumpliendo con los requerimientos

descritos en este informe, poseerá diferentes funcionalidades entre las que destacan las ventas,
información y una visualización de correos que acepten spam para establecer un medio de
comunicación recurrente con ellos, así como datos de los productos de café y sus derivados,
información empresarial. Con esta información podremos realizar un catálogo atractivo para el
cliente sobre la mercancía ofrecida.
2.3. Características de los Usuarios
Se describirá las características generales de los usuarios que utilizaran el sistema.
Tipo de usuario Administrador de la aplicación web

Formación Licenciatura
Habilidades Computación nivel usuario, Administrador de ventas
Actividades Ingresar o modificar información de productos, Ingresar o
modificar información empresarial, Ingresar o modificar Contactos
para Spam
Tipo de usuario Usuario Final o Cliente

Formación Sin especificar
Habilidades Cliente o Comprador
Actividades Registrarse, Iniciar sesión, Comprar producto, Agregar al carrito,
Leer información empresarial.
2.4. Restricciones
El producto que se está desarrollando presenta restricciones las cuales se deben tener en cuenta
tanto al momento de desarrollar el software, como cuando esté se implemente.
En el desarrollo de este software para la empresa Café las Flores, utilizaremos lenguaje de
programación Java, por este motivo la funcionalidad del software será solo para equipos con
sistema operativo Windows 10.
El entorno de desarrollo será NeatBeans y Visual Estudio.
Los equipos clientes que se encuentren en funcionamiento deben cumplir con los requisitos
mínimos para el correcto funcionamiento del sistema.
El servidor de Base de Datos debe ser capaces de atender consultas concurrentemente y de atender
la consulta de varios usuarios a la vez.
El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma o del

lenguaje de programación
2.5. Suposiciones y Dependencias
En este punto abordaremos los factores que pudiesen afectar al funcionamiento del sistema, en el
caso de que se produjese algún cambio dentro de los requisitos que se hayan obtenido.
Para el funcionamiento del sistema es necesario que el servidor en el cual se está trabajando deba
contar con una conexión a internet, en caso contrario el programa no funcionaria.
El sistema presenta dependencia en la utilización del sistema operativo Windows 7 o superior, el

cambio de éste daría como resultado, la no ejecución del programa, el programa pudiese funcionar,
pero no se asegura su compatibilidad total, ni menos su integridad, estabilidad y seguridad.
2.6. Requisitos Futuros
La evolución que podría tener el software es:
 Un sistema de control de ventas, que pudiese llevar un rígido monitoreo de ingresos y

aseguramiento de que todos los procesos contables están funcionando de forma eficiente, es
decir, que cada una de estas operaciones está quedando debidamente registradas y que los
valores de dichas actividades poseen los valores correctos.
 Otra evolución que pudiese tener el software es la integración de un inventario de productos
con un registro por Qr o código de barras con el fin de tener un registro más eficiente y fácil
de registrar.
3. Requisitos Específicos
3.1. Requisitos comunes de los interfaces
3.1.1 Interfaces de Usuario

3.1.2. Interfaces de Hardware
El software por desarrollar será utilizado en equipos en el cuál dispone el administrador.

Los equipos para utilizar tendrán las siguientes características:
 Teclado
 Mouse
 Monitor
 RAM de al menos 4Gb
 Tarjeta de red (inalámbrica o alámbrica)
3.1.3. Interfaces de software
En este punto se mencionan las interfaces software, que serán necesarias para el correcto
funcionamiento del sistema.
Entity Framework
Una librería que permite a los desarrolladores crear aplicaciones de acceso a datos, programando
con un modelo de aplicaciones conceptuales, modelo denominado ORM (Mapeo Objeto-
Relacional), en lugar de programar directamente con un esquema de almacenamiento relacional. El
objetivo es reducir la cantidad de código y el mantenimiento necesarios para las aplicaciones
orientadas a datos. Forma para del conjunto de tecnologías en ADO.NET, que dan soporte al
desarrollo de software orientado a datos.
PostgreSQL
Es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su
código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto
más potente del mercado y en sus últimas versiones no tiene nada que envidiarles a otras bases de
datos comerciales.
Su funcionalidad es la creación de bloques de código que se ejecutan en el servidor. PostgreSQL
soporta funciones que retornan "filas", donde la salida puede tratarse como un conjunto de valores
que pueden ser tratados igual a una fila retornada por una consulta. Las funciones pueden ser
definidas para ejecutarse con los derechos del usuario ejecutor o con los derechos de un usuario
previamente definido. El concepto de funciones, en otros DBMS, son muchas veces referidas como
"procedimientos almacenados”.
PostgreSQL JDBC Driver

Es un componente de software que permite que una aplicación pueda interactuar con la base de
datos PostgreSQL
Librerias .NET
Es una librería o un framework diseñado por Microsoft, que permite el desarrollo rápido de
aplicaciones haciendo énfasis en la transparencia de redes, con independencia de plataforma de
hardware.
Sistema Operativo Windows 7 o superior
El equipo cliente utilizará el sistema operativo Windows 7 o superior
3.1.4. Interfaces de Comunicación
En el siguiente tópico, se describirán los requisitos de comunicación con otros sistemas y cuáles
protocolos se utilizarán para ese fin.
Nuestro programa estará en constante comunicación con el sistema de la base de datos suministrada
por PostgreSQL.
Se utilizará TCP/IP en el cual, nos entrega, un conjunto de guías generales de diseño e

implementación de protocolos de red específicos, para permitir que un equipo pueda comunicarse
en una red. TCP/IP provee conectividad de extremo a extremo, especificando como los datos
deberían ser formateados, direccionados, transmitidos, enrutados y recibidos por el destinatario.
Para conseguir un intercambio fiable de datos, entre nuestro sistema y la base de datos, se deben
llevar a cabo muchos procedimientos separados. Con un modelo en capas o niveles resulta más
sencillo agrupar funciones relacionadas e implementar el software modular de comunicaciones.
3.2. Requisitos Funcionales
En este apartado se especificarán todas aquellas acciones que el sistema deberá llevar a cabo.
Número de requisito !!br0ken!!RF01

Nombre de requisito Crear Perfil Administrador
Descripción Se creará un perfil administrador con la capacidad de gestionar la
aplicación web
Tipo Requisito Restricción
Fuente del requisito Documento, “Descripción de Proyecto”
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Nombre de requisito Autenticación del Administrador
Descripción Con el fin de controlar el acceso de los usuarios al sistema, el
software permita la autenticación del personal, para esto se debe
ingresar su nombre y contraseña de usuario. Estos datos deben
encontrarse en los registros de los usuarios de sistema.

Nombre de requisito Registrar producto
Descripción El usuario administrador podrá realizar el registro de los datos
correspondientes del producto, tales como el nombre del producto,
precio, descripción y Cant., estos datos serán registrados en la BD.

Nombre de requisito Modificar Producto
Descripción En el caso que se requiera el usuario administrador podrá alterar los
datos de los productos, a su vez él catálogo y la BD serán
actualizados con dichos cambios.

Nombre de requisito Eliminar Producto
Descripción En caso de que no se encuentre más stock de un producto o por
algún otro motivo, el usuario administrador podrá eliminarlo del
catálogo y de la BD.

Nombre de requisito Registrar Información Empresarial y Novedades
Descripción El usuario administrador podrá registrar información de la empresa y
a su vez novedades o promociones de sus productos, Todos estos
datos permitirán una atractiva visualización para la interfaz del cliente.

Nombre de requisito Modificar Información Empresarial y Novedades
Descripción En el caso que se requiera el usuario administrador podrá alterar los
datos de la información ya registrada en la aplicación web.

Nombre de requisito Eliminar Información Empresarial y Novedades
Descripción En caso de equivocación o por algún otro motivo el usuario
administrador podrá eliminar los datos de información.

Nombre de requisito Registrar Usuario
Descripción El usuario final o cliente tendrá la opción de registrarse en la página si
así lo desea con el fin de facilitar las compras en línea. Para ello es
necesario su nombre completo, teléfono y correo electrónico.
Fuente del requisito Documento, “Descripción de Proyecto
Nombre de requisito Validar Spam
Descripción Una vez que el usuario final o el cliente finalice su registro, deberá
aceptar o rechazar notificaciones de novedades o promociones de los
productos que ofrece la empresa.

Nombre de requisito Autentificación de Usuario
Descripción Con el fin de controlar el acceso de los usuarios al sistema, el
software permita la autenticación del cliente, para esto se debe
ingresar su nombre y contraseña de usuario. Estos datos deben
encontrarse en los registros de los usuarios de sistema.

Nombre de requisito Visualizar Información Empresarial y Novedades
Descripción El usuario final o cliente podrá visualizar los datos de la empresa y
novedades registrados por el administrador desde su interfaz
correspondiente.

Nombre de requisito Visualizar Catálogo
Descripción El usuario final o cliente podrá visualizar un enriquecido catálogo con
contenido multimedia de los productos de café y sus derivados desde
su interfaz correspondiente.

Nombre de requisito Agregar Carrito de Compras
Descripción Una vez que el cliente este interesado por unos de los productos,
este tendrá la opción de agregar los productos deseados al carrito de
compras.

Nombre de requisito Realizar Compra
Descripción Una vez que el usuario final o cliente finalice de agregar productos a
su carrito de compras deberá llenar un formulario para el envío de su
pedido y así se le dará un monto total para proceder con el pago en
línea.

Nombre de requisito Realizar Pago
Descripción El usuario final o cliente deberá realizar el pago en línea por medio de
nuestro sistema, una vez realizado el pedido estará en proceso.
Nombre de requisito Consultar Pedidos Pendientes
Descripción El usuario administrador podrá consultar los pedidos pendientes con
el fin de realizarlos y enviarlos al cliente.

Nombre de requisito Selección de Pedidos Realizados
Descripción El usuario administrador deberá marcar que pedidos ya están
realizados para posteriormente actualizar la lista de pedidos por
hacer.

Nombre de requisito Consultar Pedidos Realizados
Descripción El usuario administrador podrá consultar los pedidos ya realizados sí
así lo desea.

Nombre de requisito Visualizar Correos Spam
Descripción El usuario administrador podrá consultar los correos de los usuarios
que hayan aceptado en su registro recibir spam.

Nombre de requisito Consultar Ventas
Descripción El usuario administrador podrá consultar las ventas realizadas si así
lo desea.
3.3. Requisitos No Funcionales
3.3.1. Requisitos de Rendimiento
En cuanto a los requisitos que se establecen para el correcto funcionamiento del software, se debe
considerar que éste, será un sistema que tendrá constantes ingresos y vistas a la página web, por
esto mismo, se establece como prioridad que dicha actividad debería afectar lo menos posible al
desempeño de la plataforma.
Se calcula que las transacciones que se realizarán, el 80% sea en un tiempo estimado en menos de 1
segundo.
El número de equipos que se necesita estén conectados al servidor son aproximadamente 50

simultáneamente.
Se espera que, al momento de registrar o modificar datos, el sistema demore aproximadamente 10

segundos en realizar los cambios, a su vez lo mismo debiera ocurrir al momento de realizar alguna
compra.
3.3.2. Seguridad
En este apartado, se detallarán los métodos de seguridad que presentará el software.
 El software contara con un sistema de autenticación, denominado “Inicio de sesión” para el

ingreso al sistema correspondiente.
 Cifrar todos los datos de al ingresar y descifrarlos solo cuando lleguen al procesador de
pagos.
 Protocolo HTTPS, se trata de un protocolo muy reconocible que incrementa el nivel de
seguridad de las páginas web destinadas a realizar pagos online. Últimamente, este uso se
ha extendido, de tal forma que son cada vez más las webs que cuentan con HTTPS, tanto en
el propio site como en las plataformas de pago de las que puedan hacer uso
 El servidor estará protegido mediante una UPS, con el fin de proteger la integridad de éste.

3.3.3. Disponibilidad
La disponibilidad es una de las características que mide el grado, con el que los recursos del sistema
estarán disponibles para su uso por el usuario final, a lo largo de un tiempo dado. Ésta no sólo se
relaciona con la prevención de caídas del sistema (también llamadas tiempos fuera de línea,
Downtime u Offline), sino incluso con la percepción de "caída" desde el punto de vista del usuario:
cualquier circunstancia que nos impida trabajar productivamente con el sistema – desde tiempos de
respuesta prolongados, escasa asistencia técnica o falta de estaciones de trabajo disponibles – es
considerada como un factor de baja disponibilidad.
Ya que este sistema será subido a la web, debe de ser un sistema el cual tenga niveles de servicio
que alcancen las 24 horas al día y los 365 días del año.
Tiempo muerto no programado debido a fallas y ajuste de este mismo es de 3 horas anuales
(24 horas x 7 días) – 0.5 hora offline = 167.5 Horas funcionando a la semana.
((167.5 horas / 7 días) * 365 días) - 3 Horas offline = 8730,928571428571 Horas al año
24 x 365 = 8,760 Horas tiene un año
(8730,928571428571 / 8760) * 100 = 99.668%
El sistema tendrá anualmente una disponibilidad total del 99.668% en línea.
3.3.4. Mantenibilidad
El IEEE (19990) Define mantenibilidad como: “La factibilidad con la que un sistema o componente
software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o
adaptarse a cambios en el entorno”.
Dicho esto, se deduce, que un software bien desarrollado, debe tener la flexibilidad necesaria para
adaptarse al futuro, como también, el mantenimiento deberá hacerse de manera rápida y efectiva,
afectando lo menos posible a las labores de la entidad que lo utilice.
El equipo de soporte deberá revisar el sistema una vez por semana durante 15 días, para analizar el
correcto funcionamiento tanto del sistema, como de la base de datos, chequear si los respaldos estén
en buenas condiciones y de manera íntegra, se deberá compactar la base de datos, revisar que
consultas están afectando el funcionamiento del sistema, para seguir mejorando el sistema con el
pasar del tiempo.
3.3.5. Portabilidad
Primero que nada, cabe mencionar que el sistema a crear está siendo programado en leguaje “Java”
por lo que no pierde portabilidad este leguaje es funcional en familia Windows.
El 100% de los componentes del sistema son dependientes del servidor. Ya que sin el servidor el
sistema no podría funcionar.
Para su desarrollo se utilizará la plataforma de desarrollo NeatBeans, y Visual Studio Code

compilador de java
Este sistema solo podrá ser usado en sistemas operativos Windows 7 o superior.
3.4. Otros Requisitos
En este punto definiremos requisitos de carácter legal, cultural o político según lo requerido por la
entidad cliente.
El producto de software que se desarrollará solamente tendrá como opción el idioma español, ya
que el personal encargado de utilizar el software no requiere la opción de visualizar el sistema en
otro idioma, obviamente no se descarta que en futuras actualizaciones exista la traducción a otros
idiomas. Esta última característica del sistema corresponde a un requisito cultural y/o político.

Especificación de Requisitos Según El Estándar de IEEE 830 v.2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Especificación de Requisitos Según El Estándar de IEEE 830 v.2

Cargado por

Copyright:

Formatos disponibles

Especificación de Requerimientos

según el estándar de IEEE 830 2.0

Las Flores Distribuidor de Café Tostado

INTEGRANTES DEL EQUIPO

LÍDER DEL PROYECTO:

Especificación de Requisitos según el estándar

Este documento presenta el formato de Especificación de Requisitos Software (ERS) según la

Este informe se encuentra basado en el formato de Especificación de Requisitos de Software (ERS),

1.2. Ámbito del Sistema

Su función principal es la implementación de un punto de ventas y la filtración de correos para

Nombre Guadalupe Cristina Reyes Lucas

Nombre Guadalupe Cristina Reyes Lucas

Nombre Ayrton Raúl Bolaños Waldo

Nombre Odraude Méndez Aguirre

Nombre Ayrton Raúl Bolaños Waldo

Área de Desarrollo de Base de Datos

Nombre Odraude Méndez Aguirre

1.4. Definiciones, Acrónimos y Abreviaturas

 ERS: Especificación De Requisitos De Software.

Mediante el siguiente apartado, se expondrán el material de referencia utilizado para la elaboración

Título IEEE Std. 830-1998 Especificación de requisitos según el estándar

Título Modelo TCP/IP

1.6. Visión General del Documento

El siguiente diagrama representa un resumen de lo dicho anteriormente.

2.2. Funcionalidad del Producto

El producto de software a desarrollar, a grandes rasgos y cumpliendo con los requerimientos

Se describirá las características generales de los usuarios que utilizaran el sistema.

Tipo de usuario Administrador de la aplicación web

Tipo de usuario Usuario Final o Cliente

El entorno de desarrollo será NeatBeans y Visual Estudio.

El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma o del

2.5. Suposiciones y Dependencias

El sistema presenta dependencia en la utilización del sistema operativo Windows 7 o superior, el

La evolución que podría tener el software es:

 Un sistema de control de ventas, que pudiese llevar un rígido monitoreo de ingresos y

3.1.1 Interfaces de Usuario

El software por desarrollar será utilizado en equipos en el cuál dispone el administrador.

3.1.3. Interfaces de software

PostgreSQL JDBC Driver

3.1.4. Interfaces de Comunicación

Se utilizará TCP/IP en el cual, nos entrega, un conjunto de guías generales de diseño e

3.2. Requisitos Funcionales

Número de requisito !!br0ken!!RF01

Número de requisito !!br0ken!!RF02

Número de requisito !!br0ken!!RF03

Número de requisito !!br0ken!!RF04

Número de requisito !!br0ken!!RF05

Número de requisito !!br0ken!!RF06

Número de requisito !!br0ken!!RF07

Número de requisito !!br0ken!!RF08

Número de requisito !!br0ken!!RF09

Número de requisito !!br0ken!!RF11

Número de requisito !!br0ken!!RF12

Número de requisito !!br0ken!!RF13

Número de requisito !!br0ken!!RF14

Número de requisito !!br0ken!!RF15

Número de requisito !!br0ken!!RF16

Número de requisito !!br0ken!!RF18

Número de requisito !!br0ken!!RF19

Número de requisito !!br0ken!!RF20

Número de requisito !!br0ken!!RF21

3.3. Requisitos No Funcionales

3.3.1. Requisitos de Rendimiento