EvaluaciónFinal 58

Especificación de requisitos de
software
Proyecto: COSMETICSOFT
Revisión 1.0
Mayo, 2019
Instrucciones para el uso de este formato
Este formato es una plantilla tipo para documentos de requisitos del software.
Está basado y es conforme con el estándar IEEE Std 830-1998.
Las secciones que no se consideren aplicables al sistema descrito podrán de forma

justificada indicarse como no aplicables (NA).
Notas:
Los textos en color azul son indicaciones que deben eliminarse y, en su caso, sustituirse
por los contenidos descritos en cada apartado.
Los textos entre corchetes del tipo “[Inserte aquí el texto]” permiten la inclusión directa de
texto con el color y estilo adecuado a la sección, al pulsar sobre ellos con el puntero del
ratón.
Los títulos y subtítulos de cada apartado están definidos como estilos de MS Word, de
forma que su numeración consecutiva se genera automáticamente según se trate de
estilos “Titulo1, Titulo2 y Titulo3”.
La sangría de los textos dentro de cada apartado se genera automáticamente al pulsar

Intro al final de la línea de título. (Estilos Normal indentado1, Normal indentado 2 y Normal
indentado 3).
El índice del documento es una tabla de contenido que MS Word actualiza tomando como
criterio los títulos del documento.
Una vez terminada su redacción debe indicarse a Word que actualice todo su contenido
para reflejar el contenido definitivo.
De la plantilla de formato del documento © & Coloriuris http://www.qualitatis.org

.
Ficha del documento
Fecha Revisión Autor Verificado dep. calidad.

Luis Eduardo Obando Bonilla
Mayo Luis Eduardo Obando Bonilla 1.105.614.452
1.0
2019 Mateo Cardoso González Mateo Cardoso González
1.005.720.195
Documento validado por las partes en fecha: Mayo 2019
Por el cliente Por la empresa suministradora

La Colmena Grupo 58 Análisis de sistemas UNAD 2018
Fdo. D./ Don Josué Barona Fdo. D./Don Luis Eduardo Obando Bonilla
COSMETICSOFT Rev. 1.0
Especificación de requisitos de software Pág. 4
Contenido
FICHA DEL DOCUMENTO 3
CONTENIDO 4
1 INTRODUCCIÓN 6
1.1 Propósito 6
1.2 Alcance 6
1.3 Personal involucrado 6
1.4 Definiciones, acrónimos y abreviaturas 6
1.5 Referencias 6
1.6 Resumen 6
2 DESCRIPCIÓN GENERAL 7
2.1 Perspectiva del producto 7
2.2 Funcionalidad del producto 7
2.3 Características de los usuarios 7
2.4 Restricciones 7
2.5 Suposiciones y dependencias 7
2.6 Evolución previsible del sistema 7
3 REQUISITOS ESPECÍFICOS 7
3.1 Requisitos comunes de los interfaces 8

3.1.1 Interfaces de usuario 8
3.1.2 Interfaces de hardware 8
3.1.3 Interfaces de software 8
3.1.4 Interfaces de comunicación 8
3.2 Requisitos funcionales 8

3.2.1 Requisito funcional 1 9
3.2.4 Requisito funcional n 9
3.3 Requisitos no funcionales 9

3.3.1 Requisitos de rendimiento 9
3.3.2 Seguridad 9
3.3.3 Fiabilidad 9
3.3.4 Disponibilidad 9
3.3.5 Mantenibilidad 10
Descripción de requisitos del software

3.3.6 Portabilidad 10
3.4 Otros requisitos 10
4 Apéndices 10

1 Introducción
El presente documento contiene el planteamiento de los requerimientos previamente
identificados, así como su respectivo planteamiento a la solución esperada, además de
establecer los objetivos del software y así mismo determinar el alcance de este.
La introducción de la Especificación de requisitos de software (SRS) debe proporcionar una
vista general de la SRS. Debe incluir el objetivo, el alcance, las definiciones y acrónimos,
las referencias, y la vista general del SRS.
1.1 Propósito
El propósito de este documento es enseñar todas las especificaciones necesarias para
suplir las necesidades de la empresa “La Colmena” por medio del aplicativo
Cosmeticsoft, siendo este dirigido hacia el cliente y los desarrolladores que esperamos
vean viables estos planteamientos como solución a cada requerimiento
 Propósito del documento
 Audiencia a la que va dirigido
1.2 Alcance
El sistema Cosmeticsoft se basa en un aplicativo web online que se encargará de la
administración de clientes, administración de rutas y entregadores, administración de
productos y servicios que ofrece la empresa, administración de ventas y por último
administración de los proveedores, todo esto manejando subsistemas que permitan
desde cada área el acceso restringido de sus respectivos usuarios y sus especificas
funciones dentro de la empresa.
Esto nos traerá el gran beneficio de controlar y dar un óptimo manejo de la información,
optimizando tiempos y facilitando de manera favorable el trabajo de cada dependencia
de la empresa
 Identificación del producto(s) a desarrollar mediante un nombre
 Consistencia con definiciones similares de documentos de mayor nivel (ej.
Descripción del sistema) que puedan existir
1.3 Personal involucrado

Nombre Luis Eduardo Obando Bonilla
Rol Analista de requerimientos
Categoría profesional Ingeniería
Responsabilidades Requerimientos para el área de Administración de los
inventarios de los productos y servicios.
Información de contacto Celular 313 246 2315 Skype luis.obando.
Aprobación [Inserte aquí el texto]
Nombre Mateo Cardoso González

Rol Analista de requerimientos
Categoría profesional Ingeniería
Responsabilidades Requerimientos para el área de Administración de ventas
Información de contacto Celular 300 792 6405 Skype solefenix2027@gmail.com
Aprobación [Inserte aquí el texto]
Relación de personas involucradas en el desarrollo del sistema, con información de

contacto.
Esta información es útil para que el gestor del proyecto pueda localizar a todos los
participantes y recabar la información necesaria para la obtención de requisitos,
validaciones de seguimiento, etc.

1.4 Definiciones, acrónimos y abreviaturas

Usuario: Persona que va a operar el aplicativo en determinado momento.
Requerimiento: Petición o exigencia que necesita ser suplida dentro del proyecto.
Cosmeticsoft: Nombre del software.
Definición de todos los términos, abreviaturas y acrónimos necesarios para interpretar
apropiadamente este documento. En ella se pueden indicar referencias a uno o más
apéndices, o a otros documentos.
1.5 Referencias
Referencia Titulo Ruta Fecha Autor
IEEE IEEE 830 [Ruta] [Fecha] [Autor]
Relación completa de todos los documentos relacionados en la especificación de

requisitos de software, identificando de cada documento el titulo, referencia (si
procede), fecha y organización que lo proporciona.
1.6 Resumen
El presente documento esta dividido en tres secciones, primero pasamos por la
introducción y presentación del mismo en donde obtenemos una amplia perspectiva del
sistema en concreto
Luego pasamos por una visión que describe en términos generales el aplicativo
visionado, enseñando sus funciones principales y las dependencias o subsistemas que
lo han de componer.
Para terminar en la última parte veremos a detalle los requerimientos a los que
esperamos dar solución óptima por medio del sistema.
 Descripción del contenido del resto del documento
 Explicación de la organización del documento
2 Descripción general
2.1 Perspectiva del producto
El aplicativo Cosmeticsoft será un software independiente que desarrollará sus funciones
a nivel online, permitiendo estar en constante actualización de sus estados y permitiendo
su acceso desde cualquier sede de la empresa para la que fue diseñado supliendo los
requerimientos de cada dependencia.
Indicar si es un producto independiente o parte de un sistema mayor. En el caso de
tratarse de un producto que forma parte de un sistema mayor, un diagrama que sitúe el
producto dentro del sistema e identifique sus conexiones facilita la comprensión.
2.2 Funcionalidad del producto

El sistema deberá funcionar online, y proveer las necesidades respecto a la
administración de clientes, administración de rutas y entregadores, administración de
productos y servicios que ofrece la empresa, administración de ventas y por último
administración de los proveedores.
Resumen de las funcionalidades principales que el producto debe realizar, sin entrar en
información de detalle.
En ocasiones la información de esta sección puede tomarse de un documento de
especificación del sistema de mayor nivel (ej. Requisitos del sistema).
Las funcionalidades deben estar organizadas de manera que el cliente o cualquier
interlocutor pueda entenderlo perfectamente. Para ello se pueden utilizar métodos
textuales o gráficos.

2.3 Características de los usuarios

Tipo de usuario Gerente
Formación Administración de empresas
Habilidades Manejo de la empresa
Actividades Administración y acceso a todas las dependencias del
sistema.
Tipo de usuario Gerente Comercial

Formación Ventas
Habilidades Comercial
Actividades Administración y acceso a los inventarios y reportes del
área de ventas.
Tipo de usuario Gerente Administrativo

Formación Administración de empresas
Habilidades Manejo de personal, manejo de contabilidad
Actividades Administración y acceso al área contable del software, así
como al manejo del recurso humano.
Tipo de usuario Vendedores

Formación Comercial
Habilidades Atención a clientes
Actividades Administración y acceso al área de ventas, administración
de inventarios y facturación.
Descripción de los usuarios del producto, incluyendo nivel educacional, experiencia y

experiencia técnica.
2.4 Restricciones
- El sistema debe ser usado con acceso a internet.
- Se debe programar en lenguaje de etiquetas HTML optimizado en php.
- Debe permitir acceso a los servidores en horarios laborales solamente.
- El acceso al sistema se hará desde los equipos autorizados de la compañía
validando los usuarios.
Descripción de aquellas limitaciones a tener en cuenta a la hora de diseñar y desarrollar
el sistema, tales como el empleo de determinadas metodologías de desarrollo, lenguajes
de programación, normas particulares, restricciones de hardware, de sistema operativo
etc.
2.5 Suposiciones y dependencias

Los equipos deben completar las restricciones anteriormente mencionadas para
garantizar el funcionamiento correcto del aplicativo.
Constantemente se dará soporte al software teniendo en cuenta las nuevas tecnologías.
Descripción de aquellos factores que, si cambian, pueden afectar a los requisitos. Por
ejemplo una asunción puede ser que determinado sistema operativo está disponible
para el hardware requerido. De hecho, si el sistema operativo no estuviera disponible, la
SRS debería modificarse.
2.6 Evolución previsible del sistema

Ampliación para alojar nuevas sedes y nuevos usuarios en el sistema.
Aplicativo móvil
Demás requerimientos que solicite el cliente.
Identificación de futuras mejoras al sistema, que podrán analizarse e implementarse en
un futuro.

3 Requisitos específicos
Esta es la sección más extensa y más importante del documento.
Debe contener una lista detallada y completa de los requisitos que debe cumplir el sistema
a desarrollar. El nivel de detalle de los requisitos debe ser el suficiente para que el equipo
de desarrollo pueda diseñar un sistema que satisfaga los requisitos y los encargados de las
pruebas puedan determinar si éstos se satisfacen.
Los requisitos se dispondrán en forma de listas numeradas para su identificación,

seguimiento, trazabilidad y validación (ej. RF 10, RF 10.1, RF 10.2...).
Para cada requisito debe completarse la siguiente tabla:

Funcionales
Número de requisito RF 003-1
Nombre de requisito El sistema debe permitir que el inventario permanezca
actualizado.
Tipo Requisito Restricción
Fuente del requisito Administración de inventarios de los productos y servicios.
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Nombre de requisito El sistema en la actualización de inventarios debe permitir
agregar productos por medio de las compras.

Nombre de requisito El sistema en la actualización de inventarios debe descontar
los productos por medio de la elaboración de facturas de
venta.

Nombre de requisito El sistema en la actualización de los inventarios debe
descontar los productos por medio de la elaboración de
remisiones.

Nombre de requisito El sistema en la actualización de inventarios debe retomar por
medio de un documento de devolución los productos
ingresados de vuelta a la bodega.

Nombre de requisito El sistema en la actualización de los inventarios debe
descontar los productos devueltos a los proveedores.


Nombre de requisito El sistema en la actualización de los inventarios deberá
permitir únicamente al gerente, la modificación de estos por
medio de un documento de ajuste.

Nombre de requisito El sistema debe emitir reportes con los datos reales de los
inventarios.

Nombre de requisito El sistema en su emisión de reportes debe permitir a los
vendedores conocer en tiempo real la disponibilidad de
cantidades y tipos de productos en el inventario.

Nombre de requisito El sistema en su emisión de reportes deberá permitir a la
gerencia revisar un rango de fechas de las devoluciones
realizadas hacia la empresa y hacia los proveedores.

Nombre de requisito El sistema en su emisión de reportes debe permitir a la
gerencia saber cuales son los productos de mayor y menor
rotación de acuerdo con el promedio de compra – venta.

Nombre de requisito El sistema debe permitir al inventario clasificar los productos
en una lista de averiados aparte del inventario disponible para
las ventas.
Número de requisito RNF 003-13

Nombre de requisito El sistema deberá tener un registro de cada venta en
particular
Fuente del requisito Administración de Ventas


Nombre de requisito El sistema deberá permitir ingresar un código que identifique
individualmente cada venta

Nombre de requisito El sistema deberá entregar un informe de venta
periódicamente para el análisis de estos datos

Nombre de requisito El sistema deberá actualizar correctamente cada uno de los
saldos a la hora de generar una venta
NO FUNCIONALES
Nombre de requisito El sistema deberá funcionar bajo la administración de un
servidor local en la sede principal, pero también deberá tener
acceso online en tiempo real.

Nombre de requisito El sistema deberá solicitar a los empleados un usuario y una
contraseña

Nombre de requisito El sistema debe identificar en cada documento el usuario que
lo elaboró.

Nombre de requisito El sistema no debe permitir que los documentos sean
modificados por cualquiera, y en caso de hacerlo se debe
marcar el registro de dicha modificación.


Nombre de requisito El sistema debe tener restricciones de acuerdo al usuario que
acceda al mismo.

Nombre de requisito El sistema deberá mostrar los errores en español y con
advertencias claras de que está fallando

Nombre de requisito El sistema deberá permitir la opción de acceder a la base de
datos donde se alojan las copias de la información de las
ventas

Nombre de requisito El sistema deberá tener una interfaz que sea fácil de utilizar,
mostrando las opciones de forma clara y organizada

Nombre de requisito El sistema deberá tener en la interfaz los mismos colores que
la empresa

Nombre de requisito El sistema deberá mostrar el logo de la empresa en la sección
principal de este
Y realizar la descripción del requisito
La distribución de los párrafos que forman este punto puede diferir del propuesto en esta
plantilla, si las características del sistema aconsejan otra distribución para ofrecer mayor
claridad en la exposición.
3.1 Requisitos comunes de los interfaces

[Inserte aquí el texto]
Descripción detallada de todas las entradas y salidas del sistema de software.

3.1.1 Interfaces de usuario

Los usuarios contarán con una interfaz web intuitiva que los guiará por medio de
ventanas que contendrán campos de texto, botones, opciones de menú,
instrucciones y mensajes de alerta de manera clara y en español a lo largo de su
utilización.
Describir los requisitos del interfaz de usuario para el producto. Esto puede estar
en la forma de descripciones del texto o pantallas del interfaz. Por ejemplo
posiblemente el cliente ha especificado el estilo y los colores del producto.
Describa exacto cómo el producto aparecerá a su usuario previsto.
3.1.2 Interfaces de hardware

Cada punto de acceso al sistema podrá ser un computador, Tablet o incluso
celular, cada uno con la opción de conectividad web principalmente.
Para el caso de los puntos de venta se deberá contar con un computador y su

respectiva impresora.
Especificar las características lógicas para cada interfaz entre el producto y los
componentes de hardware del sistema. Se incluirán características de
configuración.
3.1.3 Interfaces de software

Se requerirá 100% de un navegador web de preferencia, aunque como
recomendación se sugiere Mozilla Firefox o Google Chrome.
Esto para poder acceder al aplicativo web y todas sus funcionalidades.
Indicar si hay que integrar el producto con otros productos de software.
Para cada producto de software debe especificarse lo siguiente:
 Descripción del producto software utilizado
 Propósito del interfaz
 Definición del interfaz: contiendo y formato
3.1.4 Interfaces de comunicación

Cada punto de acceso al aplicativo web podrá acceder a los servidores y bases
de datos por medio de protocolos accediendo a la página web de la empresa.
Describir los requisitos del interfaces de comunicación si hay comunicaciones con
otros sistemas y cuáles son los protocolos de comunicación.
3.2 Requisitos funcionales

Definición de acciones fundamentales que debe realizar el software al recibir
información, procesarla y producir resultados.
En ellas se incluye:
 Comprobación de validez de las entradas
 Secuencia exacta de operaciones
 Respuesta a situaciones anormales (desbordamientos, comunicaciones,
recuperación de errores)
 Parámetros
 Generación de salidas
 Relaciones entre entradas y salidas (secuencias de entradas y salidas, formulas
para la conversión de información)
 Especificación de los requisitos lógicos para la información que será almacenada en
base de datos (tipo de información, requerido)
Los requisitos funcionales pueden ser divididos en sub-secciones.

3.2.1 Requisito funcional 003- 1

 El sistema debe permitir que el inventario permanezca actualizado.
 Los inventarios deberán actualizarse constantemente dependiendo
de los movimientos realizados en el área de facturación y bodega.
 La actualización se llevará a cabo al grabar cada factura,
devolución, remisión o documento que afecte el inventario
directamente.

 El sistema en la actualización de inventarios debe descontar los productos
por medio de la elaboración de facturas de venta.
 Estos nuevos productos y cantidades estarán disponibles
automáticamente para la venta en cada punto.

 El sistema en la actualización de inventarios debe descontar los productos
por medio de la elaboración de facturas de venta.
 Estos productos y cantidades vendidas se restarán
automáticamente al grabar la factura, manteniendo así el inventario
en constante actualización.

 El sistema en la actualización de los inventarios debe descontar los
productos por medio de la elaboración de remisiones.
 Las remisiones son documentos que evidencian la salida de mercancía
de los puntos de venta.
 Cada vez que se genere una en el sistema, este entenderá que las
cantidades requeridas ya no podrán estar disponibles para su venta y
se restarán del inventario disponible para las ventas
 Una vez se devuelvan estas cantidades y se anule la remisión los
productos volverán a la bodega y por tanto se actualizará nuevamente
el inventario.

 El sistema en la actualización de inventarios debe retomar por medio de un
documento de devolución los productos ingresados de vuelta a la bodega.
 Al presentarse una devolución se elaborará un documento
correspondiente en el sistema.
 Dicho documento regresará al inventario los productos devueltos
por el cliente y estarán nuevamente disponibles para su
comercialización.
 El inventario actualizará sus cantidades una vez sea grabado el
nuevo documento.
 Los productos deben estar en buen estado para su respectivo
ingreso a la bodega de ventas.

 El sistema en la actualización de los inventarios debe descontar los
productos devueltos a los proveedores.
 Al elaborar un documento de devolución a un proveedor dicho
producto ya no hará parte de la disponibilidad para comercializar

 Por tanto, estos productos deberán desaparecer del inventario al

grabar dicho documento.
 Las razones pueden ser por mercancía en mal estado o que
simplemente no llegó en las cantidades ingresadas por el documento
de compra.
 Este documento debe llevar el visto bueno de la persona encargada de
la bodega.

 El sistema en la actualización de los inventarios deberá permitir
únicamente al gerente, la modificación de estos por medio de un
documento de ajuste.
 Tan solo el usuario ligado al gerente podrá generar un documento de
ajuste a los inventarios.
 Dichos movimientos deben quedar grabados y solicitarán una
justificación.
 También tendrán el visto bueno de la persona encargada de los
inventarios.

 El sistema debe emitir reportes con los datos reales de los inventarios.
 Gracias a las actualizaciones constantes en los inventarios, al
momento de emitir un reporte sobre los mismos la información será
real.
 Debido a dichas actualizaciones constantes el reporte deberá indicar la
hora exacta de su creación, ya que es muy posible que al poco tiempo
los inventarios sean modificados gracias a una venta etc.
 Los reportes podrán ser exportados a Excel.

 El sistema en su emisión de reportes debe permitir a los vendedores
conocer en tiempo real la disponibilidad de cantidades y tipos de productos
en el inventario.
 Al momento de consultar los inventarios o realizar una factura de
venta, los empleados podrán visualizar con anterioridad las cantidades
disponibles en unidades del producto requerido.
 Cuando el empleado intente facturar más cantidades de las existentes
el sistema bloqueará el documento hasta que se modifiquen dichas
cantidades.

 El sistema en su emisión de reportes deberá permitir a la gerencia revisar
un rango de fechas de las devoluciones realizadas hacia la empresa y
hacia los proveedores.
 Seleccionando rangos de fechas el usuario ligado al gerente podrá
emitir reportes de devolución.
 Estos reportes podrán ser exportados a Excel.
3.2.11Requisito funcional 003- 11

 El sistema en su emisión de reportes debe permitir a la gerencia saber
cuáles son los productos de mayor y menor rotación de acuerdo con el
promedio de compra – venta.

 El usuario ligado al gerente tendrá la opción de generar reportes con

rangos de fecha que le permitan evaluar su rotación.
 Para esto el sistema validará los promedios de venta y compra de
estos productos.
 Dichos reportes podrán ser exportados a Excel.

 El sistema debe permitir que al inventario clasificar los productos en una
lista de averiados aparte del inventario disponible para las ventas.
 Cuando haya reporte de productos en mal estado estos deberán ser
ingresados a un inventario diferente al de las ventas.
 Cuando haya devoluciones y estos productos estén en mal estado se
ingresarán a este inventario de averías.
 Esto permitirá tener los inventarios un poco mejor optimizados a la
realidad.

 El sistema deberá tener un registro de cada venta en particular
 El vendedor ingresa los datos de cada uno de los productos como lo
son: cantidad, precio de venta, se realiza el caso de uso Cuando haya
devoluciones y estos productos estén en mal estado se ingresarán a
este inventario de averías.
 El sistema almacena los datos ingresados anteriormente
 Si un producto posee descuento, el vendedor ingresara o activara el
descuento pertinente
 El sistema almacena los datos del producto con descuento
 El vendedor verificara que la digitación en el sistema de los productos
a vender sea correcta
 El sistema almacena todos los datos ingresados durante todo el
proceso anterior, incluyendo la fecha y hora en la que se archivó,
además del nombre del vendedor que realizo el proceso de venta

 El sistema deberá permitir ingresar un código que identifique
individualmente cada venta
 El sistema almacena todos los datos correspondientes de la venta
realizada
 El sistema genera un código único e irrepetible que identifique dicha
venta
 Si se requiere de ingresar dicho código de nuevo, el sistema deberá
permitir acceder a toda la información almacenada de la venta en
cuestión

 El sistema deberá entregar un informe de venta periódicamente para el
análisis de estos datos
 El sistema luego de x periodo de tiempo, el sistema selecciona cada
una de las ventas y las ordena en base a su código, para ser enviadas
en un solo archivo
 El sistema mostrara atributos de las ventas como, fecha, hora y
descripción de la venta
 El sistema realizara un copia de cada informe en una base de datos

3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento
El sistema deberá permanecer en constante actualización de acuerdo a las
operaciones realizadas por los usuarios, se debe garantizar el rendimiento fluido
de cada dispositivo conectado.
Especificación de los requisitos relacionados con la carga que se espera tenga
que soportar el sistema. Por ejemplo, el número de terminales, el número
esperado de usuarios simultáneamente conectados, número de transacciones por
segundo que deberá soportar el sistema, etc.
Todos estos requisitos deben ser mesurables. Por ejemplo, indicando “el 95% de
las transacciones deben realizarse en menos de 1 segundo”, en lugar de “los
operadores no deben esperar a que se complete la transacción”.
3.3.2 Seguridad
El sistema deberá filtrar el tráfico entrante en la red para de esta forma aislar los
puertos específicos del host, además de deshabilitar los servicios innecesarios
con base en las políticas de la empresa. Por otro lado, realizar las actualizaciones
pertinentes del software y realizar pruebas con un software de escaneado de
vulnerabilidades esto con el fin de disminuir la explotación de errores de
configuración del sistema operativo.
El sistema deberá eliminar cuentas predeterminadas y cuentas no utilizadas,
cambiar las contraseñas predeterminadas
El usuario deberá actualizar las contraseñas periódicamente.
Se deberá de implementar una funcionalidad de detección de contraseñas
vulnerables.
Especificación de elementos que protegerán al software de accesos, usos y
sabotajes maliciosos, así como de modificaciones o destrucciones maliciosas o
accidentales. Los requisitos pueden especificar:
 Empleo de técnicas criptográficas.
 Registro de ficheros con “logs” de actividad.
 Asignación de determinadas funcionalidades a determinados módulos.
 Restricciones de comunicación entre determinados módulos.
 Comprobaciones de integridad de información crítica.
3.3.3 Fiabilidad
El sistema deberá tener como máximo un tiempo de espera de 8 minutos para su
recuperación en caso de fallo de caída total, además se deberá de detectar y
recuperación de fallos.
Especificación de los factores de fiabilidad necesaria del sistema. Esto se
expresa generalmente como el tiempo entre los incidentes permisibles, o el total
de incidentes permisible.
3.3.4 Disponibilidad
Especificación de los factores de disponibilidad final exigidos al sistema.

Normalmente expresados en % de tiempo en los que el software tiene que
mostrar disponibilidad.
3.3.5 Mantenibilidad
Identificación del tipo de mantenimiento necesario del sistema.
Especificación de quien debe realizar las tareas de mantenimiento, por ejemplo
usuarios, o un desarrollador.
Especificación de cuando debe realizarse las tareas de mantenimiento. Por
ejemplo, generación de estadísticas de accesos semanales y mensuales.

3.3.6 Portabilidad
Especificación de atributos que debe presentar el software para facilitar su
traslado a otras plataformas u entornos. Pueden incluirse:
 Porcentaje de componentes dependientes del servidor.
 Porcentaje de código dependiente del servidor.
 Uso de un determinado lenguaje por su portabilidad.
 Uso de un determinado compilador o plataforma de desarrollo.
 Uso de un determinado sistema operativo.
3.4 Otros requisitos

Cualquier otro requisito que no encaje en ninguna de las secciones anteriores.
Por ejemplo:
Requisitos culturales y políticos
Requisitos Legales
4 Apéndices
Diagramas de casos de uso:
Pueden contener todo tipo de información relevante para la SRS pero que, propiamente, no
forme parte de la SRS.
1. El sistema en la actualización de los inventarios debe agregar productos por

medio de la elaboración de documentos de compras.

2. El sistema en la actualización de los inventarios debe descontar los productos por

medio de la elaboración de facturas de venta.

EvaluaciónFinal 58

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

EvaluaciónFinal 58

Cargado por

Copyright:

Formatos disponibles

Especificación de requisitos de

Está basado y es conforme con el estándar IEEE Std 830-1998.

Las secciones que no se consideren aplicables al sistema descrito podrán de forma

La sangría de los textos dentro de cada apartado se genera automáticamente al pulsar

De la plantilla de formato del documento © & Coloriuris http://www.qualitatis.org

Fecha Revisión Autor Verificado dep. calidad.

Documento validado por las partes en fecha: Mayo 2019

Por el cliente Por la empresa suministradora

1.3 Personal involucrado 6

1.4 Definiciones, acrónimos y abreviaturas 6

2.1 Perspectiva del producto 7

2.2 Funcionalidad del producto 7

2.3 Características de los usuarios 7

2.5 Suposiciones y dependencias 7

2.6 Evolución previsible del sistema 7

3.1 Requisitos comunes de los interfaces 8

3.2 Requisitos funcionales 8

3.3 Requisitos no funcionales 9

Descripción de requisitos del software

3.4 Otros requisitos 10

Descripción de requisitos del software

1.3 Personal involucrado

Nombre Mateo Cardoso González

Relación de personas involucradas en el desarrollo del sistema, con información de

Descripción de requisitos del software

1.4 Definiciones, acrónimos y abreviaturas

Relación completa de todos los documentos relacionados en la especificación de

2.2 Funcionalidad del producto

Descripción de requisitos del software

2.3 Características de los usuarios

Tipo de usuario Gerente Comercial

Tipo de usuario Gerente Administrativo

Tipo de usuario Vendedores

Descripción de los usuarios del producto, incluyendo nivel educacional, experiencia y

2.5 Suposiciones y dependencias

2.6 Evolución previsible del sistema

Descripción de requisitos del software

Los requisitos se dispondrán en forma de listas numeradas para su identificación,

Para cada requisito debe completarse la siguiente tabla:

Número de requisito RF 003-2

Número de requisito RF 003-3

Número de requisito RF 003-4

Número de requisito RF 003-5

Número de requisito RF 003-6

Descripción de requisitos del software

Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito RF 003-7

Número de requisito RF 003-8

Número de requisito RF 003-9

Número de requisito RF 003-10

Número de requisito RF 003-11

Número de requisito RF 003-12

Número de requisito RNF 003-13

Descripción de requisitos del software

Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito RNF 003-14

Número de requisito RNF 003-15

Número de requisito RNF 003-16

Número de requisito RNF 003-18

Número de requisito RNF 003-19

Número de requisito RNF 003-20

Descripción de requisitos del software

Número de requisito RNF 003-21