Software Requirements Specification

Software Requirements Specification
Códigos Prepago
Camilo Baquero Jiménez – Andrés Camilo Martínez Pérez
TABLA DE CONTENIDO
1. Introducción ................................................................................................................. 4
1.1.
1.2.
Propósito ............................................................................................................................ 4
Objetivos ............................................................................................................................. 4
1.2.1.
1.2.2.
1.3.
1.4.
Objetivo general ..................................................................................................................... 4
Objetivos específicos ............................................................................................................ 4
Alcance................................................................................................................................. 4
Referencias ........................................................................................................................ 5
2. Descripción global ...................................................................................................... 6
2.1.
Perspectiva del producto .............................................................................................. 6
2.1.1.
2.1.2.
2.1.3.
2.1.4.
2.1.5.
2.1.6.
2.1.7.
2.1.8.
2.2.
2.3.
2.4.
2.5.
2.6.
Interfaces con el sistema..................................................................................................... 6
Interfaces con el usuario ..................................................................................................... 6
Interfaces con el hardware ................................................................................................ 6
Interfaces con el software .................................................................................................. 7
Interfaces de comunicación ............................................................................................... 7
Restricciones de memoria .................................................................................................. 7
Operaciones.............................................................................................................................. 7
Requisitos de adaptación del sitio .................................................................................. 7
Funciones del producto ................................................................................................. 8
Características del usuario........................................................................................... 8
Restricciones ..................................................................................................................... 8
Suposiciones ...................................................................................................................... 9
Distribución de reqerimientos ................................................................................... 9
3. Elaboración de requerimientos .......................................................................... 10
3.1.
Obtención de requerimientos ...................................................................................10
3.1.1.
3.2.
3.3.
3.4.
3.5.
3.6.
Identificación de necesidades ........................................................................................ 10
Refinamiento de casos de uso ...................................................................................10
Identificación de requerimientos ............................................................................10
Especificación de requerimientos ...........................................................................11
Obtención de requerimientos funcionales ...........................................................11
Obtención de requerimientos no funcionales .....................................................12
4. Gestión de requerimientos................................................................................... 13
4.1.
4.2.
4.3.
4.4.
Organización y Responsables ....................................................................................13
Validación de requerimientos ..................................................................................13
Trazabilidad de requerimientos ..............................................................................15
Avance del producto .....................................................................................................15
5. Requerimientos específicos ................................................................................. 17
5.1.
5.2.
Características del producto de software .............................................................17
Atributos de calidad del sistema ..............................................................................17
1. INTRODUCCIÓN
1.1. PROPÓSITO
El propósito del presente documento es identificar, especificar y priorizar
los requerimientos del proyecto Códigos Prepago, para comprender sus
requisitos funcionales y no funcionales que presenta la aplicación.
1.2. OBJETIVOS
Los siguientes serán los objetivos por lograr con la elaboración del
presente documento
1.2.1. OBJETIVO GENERAL
Determinar las características que debe tener el sistema Códigos Prepago
para su posterior desarrollo. La especificación de estos requerimientos se
realizará con base en las necesidades de los clientes potenciales durante
la etapa del análisis del entorno.
1.2.2. OBJETIVOS ESPECÍFICOS



Identificar las necesidades requeridas para la posterior
implementación del sistema de monetización virtual.
Verificar y validar los requerimientos recolectados que cumplan
con el desarrollo de la aplicación, durante el transcurso del
proyecto
Fijar indicios para la construcción de un primer prototipo a partir
de los requerimientos recolectados durante este hito.
1.3. ALCANCE
El alcance del proyecto de software se establece de acuerdo a los
siguientes parámetros:


Identificación y especificación de los requerimientos funcionales y
no funcionales dl sistema, para estipular los que este debe
ejecutar. (Ver secciones 3.5. Obtención de requerimientos
funcionales y 3.6. Obtención de requerimientos no funcionales)
Determinar el porcentaje de implementación del producto para
establecer el estado que se encuentra cada requerimiento (Ver
sección 4.6. Avance del producto).
1.4. REFERENCIAS
[1] TechTarget, «What is software requirements specification (SRS)? Definition from Whatis.com», Search Software Quality. [Online].
Available:
http://searchsoftwarequality.techtarget.com/definition/softwarerequirements-specification.
[2] Karl Wiegers, «Software Requirements 2 (9780735618794): Karl
Wiegers: Books». [Online]. Available: http://www.amazon.com/SoftwareRequirements-2-KarlWiegers/dp/0735618798/ref=sr_1_1?ie=UTF8&qid=1333229381&sr=8-1.
[3] IEEE STANDARD, «IEEE SA - 830-1998 - IEEE Recommended Practice
for Software Requirements Specifications», IEEE STANDARDS
ASSOCIATION.
[Online].
Available:
http://standards.ieee.org/findstds/standard/830-1998.html.
[4] «SISCOOP;
Specificacion
Requerimientos
Software;
http://dspace.espoch.edu.ec/bitstream/123456789/188/1/Especificacion
RequerimientosSoftware.pdf». .
[5] Pontificia Universidad Javeriana, «Facultad de Ingeniería»,
Departamento de ingenieria de Sistemas. [Online]. Available: http://pujportal.javeriana.edu.co/portal/page/portal/Facultad%20de%20Ingenieria
/plt_dpto_sistemas/Profesores.
[6] Miguel Torres, «Página de Miguel Torres», Pagina de Miguel Torres.
[Online]. Available: http://sophia.javeriana.edu.co/~metorres/.
[7] Craig Larman, Begoña Moros Valle, «UML y patrones : una
introducción al análisis y diseño orientado a objetos y al proceso
unificado: Craig Larman, Begoña Moros Valle: 9788420534381: Englische
Bücher»,
UMl
Y
patrones.
[Online].
Available:
http://www.amazon.de/UML-patrones-introducci%C3%B3n-orientadounificado/dp/images/8420534382.
[8] Ian Sommerville, Maria Isabel Alfonso Galipienso, Antonio Botia
Martinez, «Amazon.com: Ingenieria del Software (Spanish Edition)
(9788478290741): Ian Sommerville, Maria Isabel Alfonso Galipienso,
Antonio
Botia
Martinez:
Books».
[Online].
Available:
http://www.amazon.com/Ingenieria-del-Software-SpanishEdition/dp/8478290745/ref=sr_1_2?ie=UTF8&qid=1330812902&sr=8-2.
[9] Gonzalo Mena Mendoza, «Procesos de la Ingeniería de
Requerimientos», Procesos de la ingeniería de requerimientos, jul-2005.
[Online].
Available:
http://mena.com.mx/gonzalo/maestria/ingreq/presenta/procesos_ir/.
[10]
Peter Zielcynski, Ph D., «Amazon.com: Requirements
Management Using IBM® Rational® RequisitePro® (9780321383006):
Peter
Zielczynski:
Books»,
Amazon.
[Online].
Available:
http://www.amazon.com/Requirements-Management-Using-RationalRequisitePro/dp/0321383001.
2. DESCRIPCIÓN GLOBAL
Este documento brinda un panorama general que concierne a la
funcionalidad del software y a la forma en la cual se espera que el producto
funcione de acuerdo a las necesidades de los clientes. De igual manera, el
documento contribuye al soporte para la fase de implementación,
contribuyendo el desarrollo del producto.
2.1. PERSPECTIVA DEL PRODUCTO
2.1.1. INTERFACES CON EL SISTEMA
Estas especifican las interacciones con otros sistemas que interactúan con
el presente producto de software, logrando una mayor integración del
sistema por implementar. La manera en que estás se comunicaran con el
software serán por medio de servicios web. Estas interfaces son:



Sitios web de tiendas virtuales: Portales web de los almacenes
que toman propiedad de elementos por vender.
Terminales de pago: Sitios autorizados que recaudan dinero y
notifican al sistema el depósito de los clientes.
Portal virtual del banco: Interacción entre el sistema y el banco en
donde se abre una cuenta corriente.
2.1.2. INTERFACES CON EL USUARIO
Representa los dispositivos de entrada y de salida en los cuales el cliente
logrará una interacción con el producto. Los componentes necesarios
son:


Pantalla: Recurso utilizado para la interacción visual del usuario
con la aplicación web. También proveerá interacción táctil en los
dispositivos que soporten esta característica.
Interfaz gráfica de usuario: Ambientación visual para acoger al
usuario y facilitar el uso de la aplicación.
2.1.3. INTERFACES CON EL HARDWARE
Estas son relacionadas con los dispositivos físicos que se utilizan para
ingreso, procesamiento y acceso a datos. Es indispensable contar un
puerto Ethernet o con conectividad WiFi, y una tarjeta de red para
establecer conexión con la tienda y los métodos de pago promovidos por
el producto. Así mismo, se debe contar con las interfaces de usuario
previamente expuestos.
2.1.4. INTERFACES CON EL SOFTWARE
Los siguientes son los programas y software indispensables para lograr la
interacción con el sistema:


Sistema operativo: Software que gestiona los recursos de
hardware del dispositivo móvil y brinda servicios para la
aplicación, por donde se accederá a la solución de software.
Aplicación móvil: Aplicación para recuperar y presentar la
información visual y funcional del sistema web.
2.1.5. INTERFACES DE COMUNICACIÓN
Se debe disponer del protocolo TCP/IP orientado a conexión, entre la
aplicación visual mostrada en el dispositivo del usuario y el servidor
donde se aloja la solución. De igual forma, es necesario establecer una
conexión segura HTTPS.
2.1.6. RESTRICCIONES DE MEMORIA
Para que el cliente soporte la aplicación, se puede contar con una
terminal que contenga por lo menos 1GB de memoria RAM. Las
restricciones del servidor pueden variar de acuerdo al la cantidad de
peticiones que se realizan desde varios servidores. Los recursos
requeridos pueden ser escalables, aprovechando una de las ventajas de la
computación en la nube.
2.1.7. OPERACIONES



Operación del usuario
Durante la ejecución de este sistema a través del navegador web,
el usuario puede iniciar sesión, adjuntar productos y efectuar una
compra, entre otras capacidades enunciadas en los casos de uso.
(Ver documento CasosdeUso.docx)
Ejecución con el servidor
El servidor ejecuta de manera automatizada tareas de comprobar
información, compras, códigos y puntos de usuario.
Modos de error
El servidor mostrará el rastro de operaciones para identificar el
inconveniente.
2.1.8. REQUISITOS DE ADAPTACIÓN DEL SITIO
En los dispositivos móviles, debe contar con memoria de 1GB, procesador
de 1.2 GHz y que soporte el sistema operativo android. Además, debe
disponer de la aplicación instalada en el dispositivo.
2.2. FUNCIONES DEL PRODUCTO
Los siguientes serán las restricciones que se han contemplado en el
transcurso de la implementación:
 Se manejara mediante una arquitectura N-tier, permitiendo a ser
accedido por múltiples modalidades de cliente e integrando
sistemas externos.
 Se debe manejar estricto control en la identificación del usuario,
mediante el inicio y cierre de sesiones.
 Se debe mantener la integridad de la información, sin permitir que
sus funcionalidades y el acceso a los datos no sean vulnerados por
ataques cibernéticos.
Para una descripción más detallada de las funciones del sistema, los
documentos adicionales de casos de uso y requerimientos explicarán más
las propiedades de los actores y los privilegios que cada uno tienen en el
acceso al sistema (Ver documentos CP-CasosdeUso, CPRequerimientosFuncionales.docx y RequerimientosNoFuncionales.docx).
2.3. CARACTERÍSTICAS DEL USUARIO
Las características del usuario se definen el la documentación expresada
para los casos de uso (Ver documento CasosdeUso.docx).
2.4. RESTRICCIONES
Restricción
Arquitectura
Cliente
Interfaz de usuario
Descripción

Se debe lograr el acceso a este a través
de una aplicación móvil, inicialmente en
andoroid.

Se espera que se asemeje a una habitual
tienda en línea, permitiendo una
interacción intuitiva con el sistema.
Se utilizarán escala de verdes para
mantener uniformidad en la interfaz de
usuario.

Lenguaje de
programación

Para la aplicación móvil en android, será
implementada en Java.
Legales

Todo el contenido obtenido de otras
fuentes será referenciado.
Se respetarán los aspectos de propiedad


industrial para convención de logos y
marcas.
Se respetaran todos los derechos
expresados para comercio electrónico.
Persistencia

Se manejará la persistencia en base de
datos en “MongoDB”, ofrecida en
Amazon Web Services.
Sistema operativo

El sistema operativo dependerá de cada
dispositivo y terminal que acceda al
aplicativo
2.5. SUPOSICIONES
La aplicación debe ejecutarse en teléfonos con los siguientes requisitos
mínimos:
-
Pantalla de 3,7 pulgadas.
Procesador Dual-Core de 1GHz
Memoria RAM de 1GB.
Android Jelly Bean 4.1
2.6. DISTRIBUCIÓN DE REQERIMIENTOS
Para la distribución de estos, se identificaron las necesidades que en el
mercado del comercio electrónico existen y las encuestas realizadas a
usuarios potenciales y la investigación de mercados realizada. Obtenido
estos, se realizan los casos de uso, se realiza su documentación y se
redactan los requerimientos asociados a los datos obtenidos. Por último,
se identifican y dividen en requerimientos funcionales y no funcionales
(Ver sección 3. Elaboración de requerimientos).
3. ELABORACIÓN DE REQUERIMIENTOS
3.1. OBTENCIÓN DE REQUERIMIENTOS
3.1.1. IDENTIFICACIÓN DE NECESIDADES
Para entender el entorno a la cual se desea ataca con el presente servicio,
se han leído noticias respecto al comercio en línea, visitado los portales
web de los sistemas de monetización y tiendas electrónicas para evaluar
sus fortalezas y debilidades en el mercado. Este estudio exploratorio se
complementó con el estudio de mercados que se realizó para obtener la
propuesta de valor.
3.2. REFINAMIENTO DE CASOS DE USO
Luego de realizarse y redactar los casos de uso del sistema, se procede a
seleccionar aquellos que eran necesarios y muy relevantes
arquitecturalmente. Así mismo, se procede a corregirlos y a redactarse
nuevos requerimientos que no estaban contemplados con todos los casos
de uso.
3.3. IDENTIFICACIÓN DE REQUERIMIENTOS
En la siguiente figura, se mostrarán cómo se clasifican los requerimientos,
de acuerdo a su tarea por expresar en el sistema:
Requerimientos funcionales
• Desarrollo de las
transacciones
• Gestión de puntos
• Conexión
• Gestión de sesiones
• Integración con otros
sistemas
• Gestión de productos
• Cambios de tasa de puntos
Requerimientos no
funcionales
• Interfaz de usuario
• Desempeño
• Restricciones de diseño
• Restricciones de
implementación
• Calidad de software
• Recursos de hardware
3.4. ESPECIFICACIÓN DE REQUERIMIENTOS
Los requerimientos recolectados para el presente proyecto contienen
parámetros requeridos para realizar una correcta documentación de
ellos. Estos son consignados con las siguientes descripciones.
 ID: Identificador único del requerimiento
 Versión: Representa los cambios que se efectúan en el
requerimiento.
 Autor: Nombre de la persona encargada de especificar el
requerimiento y la gestión del mismo (Ver sección 4. Gestión de
requerimientos).
 Prioridad: Relevancia del requerimiento dentro del sistema por
desarrollar (Ver sección 3.7. Priorización de requerimientos).
 Fecha de creación: Creación del requerimiento, este debe estar en
formato DD/MM/AAAA.
 Fecha de modificación: Modificación del requerimiento en formato
de fecha DD/MM/AAAA.
 Origen: Se define si el requerimiento se obtuvo a partir de casos de
uso, necesidades de negocio o funcionamiento esencial del
sistema.
 Verificación: Define cómo el sistema hace para que ese
requerimiento cumpla con lo que se especifica.
 Estado: Define el seguimiento del requerimiento. Para este fin, se
establecen los parámetros Aprobado, Implementado, Verificado,
Eliminado o Rechazado.
 Requerimientos asociados: Son aquellos requerimientos que se
complementan con el descrito.
3.5. OBTENCIÓN DE REQUERIMIENTOS FUNCIONALES
En esta sección, se define el proceso de identificar las necesidades de los
clientes y la obtención de los requerimientos funcionales del sistema.
Para este proceso de obtención, se basa en los siguientes recursos:
 Casos de uso (Ver documento CasosdeUso.docx y diagrama
UseCaseCP.png).
 Plan de negocios (Ver documento Plan de Negocios.docx)
Luego de ser contemplados estos factores, se listan y realizan en
documento en el cual se describe cada uno de los requerimientos
funcionales del sistema de manera detallada (Ver documento
RequerimientosFuncionales.docx).
3.6. OBTENCIÓN DE REQUERIMIENTOS NO FUNCIONALES
En esta sección, se define la obtención de los requerimientos no
funcionales del presente proyecto. Para este proceso, se recurrió a estas
fuentes:
 Restricciones del sistema (Ver sección 2.4. Restricciones).
 Suposiciones y dependencias (Ver secciones 2.5 Suposiciones y
2.6. Dependencias).
Después de analizados estos recursos, se listan y se documentan cada
uno de los requerimientos recolectados describiéndolos detalladamente
(Ver documento RequerimientosNoFuncionales.docx).
4. GESTIÓN DE REQUERIMIENTOS
4.1. ORGANIZACIÓN Y RESPONSABLES
En las siguientes tablas, se define quién será el responsable de cada uno
de los requerimientos del sistema y de llevar a cabo la correspondiente
gestión de estos.
 Requerimientos funcionales
Responsabilidad
Requerimientos




Arquitecto

Requerimientos
Elementos del Usuario
Conexión
Características del sistema
Desarrollo la sesión de usuario
Requerimientos No Funcionales
Responsabilidad
Documentación









Requerimientos
Interfaz de Usuario
Interfaz de Hardware
Interfaz de Software
Desempeño
Calidad Software (Usuario)
Calidad Software (Desarrollador)
Operación
Restricciones de Diseño
Restricciones de Implementación
4.2. VALIDACIÓN DE REQUERIMIENTOS
La validación de los requerimientos consiste en comprobar que los
requerimientos recolectados sean consistentes con las exigencias del
cliente.
En esta etapa, es indispensable la corrección de los requerimientos para
evitar costos adicionales durante el desarrollo o la implementación del
producto. Se realizará esta labor siguiendo estos pasos:

Verificación de Validez: Cuando se trabajan con los
requerimientos, es común analizar durante la construcción que
estos enunciados carecen especificación sobre la funcionalidad.
Para evitar retrasos y discusiones con los desarrolladores, se
redefinen estos requisitos del sistema.




Verificación de Consistencia: Después de la recolección de
requerimientos, es habitual que en cada requisito se encuentren
contradicciones. Lo cual significa que se deben analizar estas
aseveraciones que especifican contrariamente lo que otros
requisitos afirman, y se decide si se debe replantearlo o
rechazarlo.
Verificación de integridad: Los miembros de trabajo se
encargarán de analizar si se ha pasado por alto algún requisito,
realizando una discusión entre los integrantes respecto a las
funcionalidades del producto y comparando con el contenido del
documento
de
requerimientos
(Ver
documentos
RequerimientosFuncionales.docx
y
RequerimientosNoFuncionales.docx).
Verificación de Trazabilidad: Se debe asegurar que estos
requerimientos logren ser implementados completamente en el
producto por entregar, teniendo en cuenta restricciones de
planeación.
Verificabilidad: Se procede a la redacción de los requerimientos
con el fin de confrontar las expectativas del cliente frente a las
aseveraciones recolectadas.
Todas estas exigencias, anteriormente planeados, facilitarán el control de
buenos requerimientos cumpliendo con las siguientes características:










No ambiguo: Debe ser claro, alcanzable, preciso y tener una única
interpretación posible.
Correcto: Debe estar bien redactado.
Completo: deben contener en sí mismos toda la información
necesaria, y no remitir a otras fuentes externas que los expliquen con
más detalle
Consistente: Ningún requisito debe entrar en conflicto con otro
requisito diferente, ni con parte de otro. Asimismo, el lenguaje
empleado entre los distintos requisitos debe ser consistente también.
Escrito en forma de “Debe”: Debe iniciar en forma “Debe”.
No repetido: puede existir uno redactado de otra forma que tenga el
mismo objetivo.
Verificable: poder verificar con absoluta certeza, si el requisito fue
satisfecho o no. Esta verificación puede lograrse mediante inspección,
análisis, demostración o testeo.
Escrito en lenguaje natural: Debe ser claro para los que necesitan
hacer uso de los requerimientos.
Necesario: Lo que pida un requisito debe ser necesario para el
producto.
Puede seguirse: Deben tener artefactos asociados a lo largo del ciclo
de vida del producto.
El equipo encargado de esta labor realizará las respectivas revisiones
haciendo una comparativa con las reglas de juego y las plantillas de casos
de uso (Ver Documento CasosdeUso.docx).
4.3. TRAZABILIDAD DE REQUERIMIENTOS
Esta sección define la trazabilidad de los requerimientos funcionales y no
funcionales del sistema. La trazabilidad es el seguimiento que se puede
hacer sobre cada uno de los requerimientos del sistema. Se podrá decir
que un requerimiento es trazable si se pueden identificar y relacionar con
las siguientes partes del sistema que se muestra a continuación:




Origen
(Casos
de
uso
Asociados) (Ver
documentos
RequerimientosFuncionales.docx
y
RequerimientosNoFuncionales.docx).
Relación con otros Requerimientos.
Relación con otros elementos (Clases, Métodos, Atributos).
Pruebas unitarias.
4.4. AVANCE DEL PRODUCTO
El avance del producto representa el porcentaje que llevamos
implementado del producto para cada entrega; con los requerimientos
resultantes del proyecto se pasará a evaluar y supervisar qué
requerimientos ya fueron propuestos, aprobados, implementados y
verificados, esto se realiza en la especificación de requerimientos (Ver
Sección 3.4 Especificación de requerimientos) donde se obtiene un valor
porcentual para cada etapa del requerimiento.
Con lo mencionado anteriormente calculamos mediante la siguiente
fórmula el porcentaje de avance del producto:
n = Total de requerimientos.
i = Número de requerimientos.
Valor requerimiento =
Valor obtenido de la priorización de
requerimientos (Ver Sección 4.2 Priorización de requerimientos).
Porcentaje Propuesto = 5%. Porcentaje obtenido de la especificación de
requerimientos (Ver Sección 3.4 Especificación de requerimientos).
Porcentaje Aprobado = 10%. Porcentaje obtenido de la especificación de
requerimientos (Ver Sección 3.4 Especificación de requerimientos).
Porcentaje
Implementado = 65%. Porcentaje obtenido de la
especificación de requerimientos (Ver Sección 3.4 Especificación de
requerimientos).
Porcentaje Verificado = 20%. Porcentaje obtenido de la especificación de
requerimientos (Ver Sección 3.4 Especificación de requerimientos).
𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑎𝑗𝑒 𝑑𝑒𝑙 𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑜
𝑛
= ∑ 𝑉𝑎𝑙𝑜𝑟 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑚𝑖𝑒𝑛𝑡𝑜 ∗ 𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑎𝑗𝑒 𝑃𝑟𝑜𝑝𝑢𝑒𝑠𝑡𝑜
𝑖=0
𝑛
+ ∑ 𝑉𝑎𝑙𝑜𝑟 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑚𝑖𝑒𝑛𝑡𝑜 ∗ 𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑎𝑗𝑒 𝐴𝑝𝑟𝑜𝑏𝑎𝑑𝑜
𝑖=0
𝑛
+ ∑ 𝑉𝑎𝑙𝑜𝑟 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑚𝑖𝑒𝑛𝑡𝑜
𝑖=0
∗ 𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑎𝑗𝑒 𝐼𝑚𝑝𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑑𝑜
𝑛
+ ∑ 𝑉𝑎𝑙𝑜𝑟 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑚𝑖𝑒𝑛𝑡𝑜 ∗ 𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑎𝑗𝑒 𝑉𝑒𝑟𝑖𝑓𝑖𝑐𝑎𝑑𝑜
𝑖=0
5. REQUERIMIENTOS ESPECÍFICOS
5.1. CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE
Para referirse de las características del producto, se enfatiza en los
requerimientos funcionales del sistema en base de las fuentes
mencionadas que detallan las funcionalidades del sistema (Ver sección ) y
los casos de uso desarrollados (Ver Documento CasosdeUso.docx).
Luego de la lectura de estos documentos, se procede a escribir los
requisitos primordiales para el funcionamiento del sistema por
implementar. Para esto, se procede a diligenciar el documento propicio
para este fin, enunciando su descripción, la prioridad, la fuente de origen
en el cual se basó y los requerimientos dependientes (Ver Documento
RequerimientosFuncionales.docx).
5.2. ATRIBUTOS DE CALIDAD DEL SISTEMA
Para la obtención de requerimientos no funcionales, se ha especificado
estos requisitos, tratándose de conexión, soporte a fallos, modo de
persistencia y requisitos mínimos de los equipos donde se probará el
funcionamiento del sistema, entre otras características que no se
enuncian en las reglas del juego.
Para especificación de estos, se hace uso del documento que enuncian los
requerimientos
no
funcionales
(Ver
documento
RequerimientosNoFuncionales.docx).