Especificación de Requerimientos de Software

Especificación De Requerimientos De Software
APRENDIZ
Daniel Esteban Perez Perez
Andrés Felipe Pico Meza
David Segundo Navarro Bolaño
Elvia María López Espitia
EDNA MARGARITA ESTEBAN REGINO

INSTRUCTORA
TECNOLOGÍA EN ANÁLISIS Y DESARROLLO DE SOFTWARE

MONTERÍA
2022
Diseño e implementación de una tienda virtual
Tabla de contenido
INTRODUCCIÓN...........................................................................................................................3
Descripción: Tienda Virtual...................................................................................................6
Definiciones.................................................................................................................................8
Características de los requerimientos.............................................................................13
Diagramas de secuencia.......................................................................................................15
Arquitectura del software....................................................................................................22
Historias de Usuarios................................................................................................................ 22
Diagrama UML............................................................................................................................. 23
Diagrama de actividades.......................................................................................................... 23
Casos de uso..............................................................................................................................25
Prototipo de Inicio de sesión:................................................................................................. 32
MATRIZ DE TRAZABILIDAD..................................................................................................... 33
Diagramas del Modelo de dominio del proyecto..........................................................35
Diagrama....................................................................................................................................... 35
Diagrama de actividades.......................................................................................................... 36
Interfaz.......................................................................................................................................37
Propuesta técnica...................................................................................................................41
FICHA TÉCNICA............................................................................................................................ 41
CRONOGRAMA DE ACTIVIDADES........................................................................................... 48
Documentación........................................................................................................................49
2
INTRODUCCIÓN
En la actualidad en la Industria de Software existe una tendencia al crecimiento del
volumen y complejidad de los productos, y se exige mayor calidad y productividad en
menos tiempo. El proceso de desarrollo de software se encarga de traducir las
necesidades del usuario en requerimientos de software. Estos requerimientos
transformados en diseño y el diseño implementado en código, el código es probado,
documentado y certificado para su uso operativo.
La Ingeniería de Software, se considera la rama de la ingeniería que aplica los

principios de la ciencia de la computación y las matemáticas para lograr soluciones
costo-efectivas a los problemas de desarrollo de software, es decir, permite elaborar
consistentemente productos correctos, utilizables y costos-efectivos. La misma
requiere llevar a cabo varias tareas, una de ellas es el análisis de requisitos. El análisis
de requisitos permite extraer los requisitos de un producto de software. La Ingeniería
de Software es una tecnología que indica "CÓMO" construir técnicamente un software:
económico, fiable y que funcione eficientemente.
La ingeniería de requisitos es una disciplina de la Ingeniería de software. Esta

disciplina considera diferentes líneas de trabajo, pero una de las más importantes es la
gestión de requisitos, la cual se encarga de proveer la dirección y alcance del
proyecto. Los requisitos deben ser la base de cualquier desarrollo de software. La
obtención de una especificación de requisitos de alta calidad es fundamental para
asegurar que el software se corresponde con las necesidades del cliente. En el
análisis de requisitos se investiga la parte del mundo real que se va a modelar para
tener en cuenta todas las necesidades de los usuarios finales y así dejarlas
documentadas de la forma más completa posible.
Objetivos
Para el desarrollo de un software se deben tener en cuenta ciertos parámetros que
permitan el fácil desarrollo y diseño de esto, con el fin de que sean lo más eficaces y
exequibles para una empresa y sus respectivos usuarios. Es por esto que el principal
objetivo de este trabajo es dar a conocer un modelo funcional para la ingeniería de
requisitos.
Las entrevistas son reuniones normalmente de dos personas, en las que se

plantean una serie de preguntas para obtener las correspondientes respuestas
en el contexto de un determinado dominio de problemas. En el ámbito de la
ingeniería de requisitos, las entrevistas suelen realizarlas los ingenieros de
requisitos al personal de la organización del cliente, con el objeto de abordar
asuntos relacionados con los procesos de negocio o con características del
software a desarrollar.
3
Las entrevistas deben planificarse, determinando su duración, los temas a

tratar y seleccionando el número mínimo de personas a entrevistar dentro de la
organización en función de su perfil profesional. En las primeras entrevistas los
participantes suelen ser directivos que poseen una visión global de la
organización y en ellas se abordan aspectos generales. Posteriormente, se
suelen realizar entrevistas a los futuros usuarios para conocer las prácticas
profesionales que llevan a cabo a diario y sus necesidades.
Es recomendable hacer llegar a los participantes, con antelación a la
entrevista, un resumen de los temas a tratar y los objetivos a alcanzar durante
la misma. También puede ser útil enviar cuestionarios al objeto de situar al
ingeniero de requisitos ante determinadas situaciones, conocer la opinión de
los usuarios sobre el sistema actual y sus expectativas ante el desarrollo del
nuevo sistema
Cuestionario de requerimientos iniciales
1. Establecer el perfil del usuario o Afectado
Nombre:
Compañía/Organización:
Puesto:
¿Cuáles son sus principales responsabilidades?
¿Qué entregables o productos produce?
¿Para quién?
¿Como determine el éxito en lo que hace?
¿Qué problemas interfieren con su éxito?
¿Qué tendencias? Si las hay. ¿Contribuyen a hacer su trabajo
más fácil o difícil?
2. Evaluando el problema
¿Hay problemas de <tipo de Aplicación> (en caso particular
puede ser administración de inventarios) para los cuales
carece usted de soluciones adecuadas?
Para cada problema

¿Por qué existe este problema?
¿Cómo lo resuelve ahora?
¿Cómo le gustaría que se resolviera?
3. Evaluando y Entendiendo el ambiente de usuario

¿Quiénes son los usuarios?
4
¿Cada dependencia u organismo, depende de una misma

delegación?
¿Cuál es su nivel educativo?
¿Tiene los usuarios experiencia con aplicación informática?
¿Qué plataformas se utilizan para estas aplicaciones?
¿Cuáles son sus planes futuros con respecto a plataformas?
¿Cuáles son sus expectativas con respecto a la facilidad de uso de
esta aplicación?
¿Cuáles son sus expectativas con respecto al tiempo de
entrenamiento?
¿Qué tipos de documentación impresa y en línea necesita?
4. Resumen para validar el Entendimiento del Problema

-Describa los problemas del usuario o afectado usando sus propias
palabras:
5. Evaluando las soluciones del analista (si esto es aplicable)

Que le parece se pudiéramos resolver esto de la siguiente
manera. (sumarizar las principales características de la
solución o aplicación que propone) Que importancia le daría
usted a esta aplicación
6. Evaluando la oportunidad
¿Quiénes necesitan esta aplicación en su organización?
¿Cuántos de estos tipos de usuarios utilizaría la aplicación?
¿Qué valor le daría Ud. a la solución acertada?
7. Evaluando las necesidades esta aplicación en su organización

¿Cuáles son sus expectativas sobre la confiabilidad de la
aplicación?
¿Cuáles son sus expectativas sobre la capacidad (rendimiento) de
la aplicación?
¿Dará Ud. Soporte a la aplicación? ¿Lo hará alguien más?
¿Tiene Ud. Necesidades especiales con respecto al soporte?
¿Cuál será el nivel de acceso para el mantenimiento y servicio?
¿Cuáles son los requerimientos de seguridad?
¿Cuáles son los requerimientos de instalación y configuración?
¿Hay requerimientos especiales de licenciamiento?
¿Cómo será distribuida la aplicación?
¿Cuáles son los requerimientos de etiquetado y de empaquetado?
8. Otros requerimientos
5
¿Cuáles, si los hay, son los requerimientos sobre

estándares ambientales o regulaciones legales que
deben cumplirse?
9. Resumen del Analista
Descripción: Tienda Virtual

Este proyecto que tiene por nombre plan de negocio para la creación de una
tienda online de artículos tecnológicos, el cual justifica la necesidad de contar
con mecanismos adecuados de comercialización y venta de productos y
servicios tecnológicos en Colombia, en base a esta premisa nace nuestro
actual proyecto: “El alcance” (Aun estamos trabajando en el nombre de la
marca) como una tienda online en la cual se podrá adquirir productos y
servicios tecnológicos con una intención y asesoría personalizada a través del
servicio de chatbots.
Caso de uso
Al momento de desarrollar un proyecto se debe pensar en cuáles serán las

principales funcionalidades que el software debe permitir llevar a cabo y
quiénes serán los que podrán ejecutar dichas funcionalidades. La
identificación de estos elementos se puede visualizar de manera efectiva
a través de la elaboración de diagramas de casos de uso; estos diagramas,
que son elaborados durante las etapas iniciales de un proyecto, se convierten
en referente para cada una de las etapas siguientes del desarrollo del proyecto.
6
7
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De

las muchas definiciones que existen para requerimiento, a continuación se presenta la
definición que aparece en el glosario de la IEEE.
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar
un objetivo. (2) Una condición o capacidad que debe estar presente en un
sistema o componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal. (3) Una representación documentada
de una condición o capacidad como en (1) o (2).
En el enfoque de esta actividad va relacionada con los conceptos de requisitos y
requerimientos para elaboración de un sistema de software tradicional y ágil
introduciendo plantillas y estándares para realizar el proceso de documentación
Definiciones
1. Técnicas de análisis de requisitos

Este proceso de análisis de requisitos permite principalmente el estudio de los
usuarios, para definir requisitos del sistema por medio de la producción de
documentos
en donde el sistema describe lo que debe hacer, pero no el cómo. Así es como este
proceso no solo involucra un proceso de análisis, también requiere de información
existente.
A. Priorización de requisitos
Esta una actividad clave para el éxito en la construcción en un producto de
software y su objetivo es minimizar el valor entregado por el proyecto a sus
Clientes, es decir, que requisitos deben priorizar tomando en cuenta factores
Como la complejidad, la dependencia y el retorno de inversión a los clientes
B. Técnica de clasificación de lista
Esta técnica de clasificación no requiere ningún tipo de entrenamiento o
preparación, ya que es una forma de priorización natural que se usa en la vida
cotidiana. Consiste en darle valor numérico a cada requerimiento.
C. Técnica de punto de historia y valor de negocio
Esta consiste en realizar el proceso de priorización de acuerdo en factores
como
El proceso y con la opinión de los gerentes del proyecto o dueños de producto,
los clientes, el grupo de desarrollo o incluso una combinación de los
anteriores.
Requerimientos Valor del Puntos de Cociente
8
negocio historia
R01 6 3 2
R02 7 1 7
R03 9 5 1,8
R04 3 3 1
R05 4 2 2
R06 5 4 1,25
R07 2 8 0,25
D. Matriz de priorización
Esta técnica consiste en construir una tabla donde cada requerimiento es
valorado en escala como del 0 al 10 – 0 al 100 para cada dimensión alineada
con los objetivos del producto.
2. Especificación de requisitos
Se describen algunos estándares y/o técnicas que pueden ser usadas para las
las organizaciones para describir formalmente cada uno de los requisitos del
sistema.
2.1 Estándar IEEE 830

Este estándar presenta un conjunto de prácticas recomendadas para la
redacción de un documento de especificación de requerimiento mejor
conocido como SRS. Se encuentra dividido en secciones y cada una de ellas
aborda aspectos particulares.
2.2 Estándar IEEE 29148:2018

Este estándar remplaza los estándares IEEE 830, 1233, 1362. Y contiene
disposiciones para los procesos y productos relacionados con la ingeniería de
requisitos para sistemas, productos y servicios de software a lo largo del siclo
de vida. Además, define la construcción de un buen requisito proporciona
atributos,
Características de los requisitos.
A. Está estructurado de la siguiente forma
 Introducción, resumen y tabla de contenido.
9
 Propósito, alcance de estándar, generalidades.

 Explicación de los otros estándares que lo conforman.
 Referencias a normas que lo conforman
 Clasificación de terminología, lo cual es muy valioso para cuando se
quiere establecer nuevos. Procesos de ingeniería de requerimientos
de una empresa.
 Clasificación de conceptos y procesos
 Explicación y contenido de los ítems de información que vienen a
través de la especificación de requerimientos.
 Anexos adicionales para mayor detalle.
B. Esta norma propone un listado de requerimientos como:

 Requerimientos funcionales: representan necesidades de los
interesados del software.
 Requerimientos de usabilidad: utilizados directamente por los
involucrados en la solución.
 Requerimientos de desempeño: disponibilidad de servicio y procesos
transaccionales.
 Interfaces del sistema: interacción de personas con el software.
 Operaciones del sistema.
 Modos y estados del sistema.
 Características físicas (hardware)
 Condiciones del ambiente (operativas y operacionales).
 Seguridad del sistema.
 Manejo de información.
 Políticas y regulación: normas y estándares que fundamentan el
software.
 Ciclo de vida del sistema: establece las etapas y duración del
desarrollo y uso en producción.
2.3 La especificación de requisitos a través de marcos de trabajos agiles.

Los marcos de trabajos agiles promueven la comunicación oral sobre el
documento exhaustiva en la mayoría de los procesos del ciclo de vida,
particularmente en los procesos se identifican necesidades y diseño. Sin
embargo, uno de los artefactos presentes para el modelado de
requerimientos son las historias de usuario.
Las historias de usuario son una explicación general e informal de una
función del software escrita desde la perspectiva del usuario
HISTORIAS DE USUARIO
Número# Nombre de la historia de usuario
10
Usuario:
Prioridad Puntos estimados
Descripción:
Observaciones:
Criterios de aceptación:
Las historias de usuario tienen otros beneficios con respecto a otros

instrumentos de redacción de requisitos.
 Se centran en solucionar problemas a usuarios reales

 Permiten la colaboración, ya que como su descripción se
necesita que el equipo colabore para decidir cómo dar
solución.
 Las historias impulsan la creatividad, ya que fomentan que el
equipo piense de forma crítica y creativa sobre cómo
solucionar de mejor manera el objetivo.
 Las historias de usuario motivan, pensar en una mejor
solución para una problemática particular representan retos
y pequeñas victorias.
2.4 Scrum y la especificación de requisitos

Soportado en un marco de trabajo interactivo e incremental educativo, en el
que se identifican tres roles principales: el equipo de trabajo (TEAM)
conformado por los desarrolladores, diseñadores, personal de calidad y de
infraestructura requerido para la construcción del producto del software; el
scrum master es el que realiza funciones parecidas a las de un productor de
proyecto. Garantiza que el equipo de trabajo tenga todas las herramientas y
recursos necesarios para el desarrollo de su trabajo.
Scrum establece el concepto de Sprint para referirse a una interacción que
contempla tiempos fijos entre 2 y 4 semanas dependiendo del equipo de
trabajo, dentro de este tiempo se incluye la planeación de Sprint.
El artefacto mediante el cual se condensan todos los requerimientos del
sistema se denomina pila de producto (Product backlog).
2.5 Kanban y la especificación de requisitos
Es una metodología que surge para gestionar el trabajo que surge del sistema
de producción Toyota Production System surge a finales de la década de
1940, el cual representaba un sistema de producción basado en la demanda
de los clientes y no en la producción masiva. A principios del siglo XXI, la
industria del software adoptó a Kanban para cambiar la forma en que se
producía y entregaban productos y servicios, además tiene en cuenta los
11
principios de las metodologías Scrum. Pero también con el fin de una mejora
continua.
Kanban en la industria se basa en cuatro principios fundamentales
 Calidad garantizada, todo lo que se produce debe salir bien sin
márgenes de errores, prima la calidad sobre la rapidez.
 Reducción del desperdicio. Hacer solo lo justo y necesario, pero
hacerlo bien.
 Mejora continua.
 Flexibilidad: se pueden priorizar tareas entrantes según las
necesidades del momento.
3. Validación de requerimientos
La validación de requerimientos busca ratificar que los requerimientos

realmente están especificando lo que el cliente desea y necesita. Este proceso
es de mucha importancia, un error en los documentos de requerimientos
puede ocasionar desgaste en los proyectos de diseño, construcción o
despliegue de producción. También los costos en una etapa muy avanzada del
proyecto pueden ser muy costoso.
Verificación en los procesos de validación de requerimientos
 Verificación de validez: los requerimientos son razonables e
identifican realmente todas las funciones necesarias para cumplir con
las necesidades del cliente.
 Verificación de consistencia: los requerimientos no presentan
contradicciones.
 Verificaciones de completitud: se incluyen todas las funcionalidades y
restricciones definidas por los usuarios del sistema.
 Verificaciones de realismo: los requerimientos son realizables de
acuerdo con la tecnología existente, el presupuesto y lo tiempo
definidos.
 Verificabilidad: es posible demostrar la realización de cada
requerimiento y que hace lo que debe hacer. Es decir, se pueden
realizar pruebas de forma clara.
Existen técnicas para la validación de requisitos.
1.1 Revisiones de requerimientos

Es un proceso manual que involucra la participación de personas de parte
de la organización constructora del software, así como el de los clientes.
Por lo general, en este proceso se revisa el documento de requerimientos
tratando de encontrar alguna anomalía.
12
1.2 Construcción de prototipos

Es la versión inicial del sistema que permite probar conceptos, diseños y
flujos por medio de la interacción directa de clientes o usuarios.
 El prototipado puede estimular un número excesivo de cambios
de peticiones.
 Los prototipos operativos pueden inducir a pensar a la directiva y
a los clientes que el producto final está prácticamente dispuesto
para su salida del mercado.
 Los prototipos pueden encarecer el producto.
Para la fase de verificación de requisitos se recomienda el uso de prototipos

de baja fidelidad (presentación de escenarios en maquetas estática) y de tipo
exploratorio (prototipos no reutilizables, utilizados únicamente para la
clarificación e identificación de requerimientos.
Herramientas para creación de prototipos: Adobe XD, Marvel APP, Moqups,
Lucidchart, Proto.io, Balsamiq.
Características de los requerimientos
Los requerimientos deben especificarse antes de intentar comenzar la construcción del

producto, sin ellos no podrá ser posible llevar a cabo las etapas de diseño y
construcción correctamente. Los mismos pueden verse como una declaración
abstracta de alto nivel de un servicio que el sistema debe proporcionar, como una
definición matemática detallada y formal. Los requisitos cumplen una doble función ya
que son la base para una oferta de contrato, por lo tanto deben estar abiertos a la
interpretación. Además son la base para redactar el contrato en sí mismo.
Los requisitos una vez establecidos y documentados, sufren cambios continuos, en
este sentido, no se trata la obtención ni el análisis de los mismos, se trata de su
gestión, es decir, el seguimiento respecto a los cambios que se generan durante el ciclo
de vida del proyecto y las herramientas de gestión de requisitos que auxilian y/o
automatizan estas tareas. El uso de herramientas para auxiliar la gestión de requisitos
se ha convertido en un aspecto importante de la Ingeniería de Sistemas y el diseño.
Considerando el tamaño y la complejidad del desarrollo, las herramientas vienen
siendo algo esencial. Las herramientas que los gestores de requisitos utilizan para
automatizar los procesos de Ingeniería de Requisitos han disminuido el trabajo duro en
el mantenimiento de requisitos, añadiendo beneficios significativos al reducir errores.
13
Las características de un requerimiento son sus propiedades principales. Un conjunto

de requerimientos en estado de madurez, deben presentar una serie de características
tanto individualmente como en grupo. A continuación, se presentan las más
importantes.
 Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia

en el sistema a construir, y además su capacidad, características físicas o factor
de calidad no pueden ser reemplazados por otras capacidades del producto o
del proceso.
 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su

redacción debe ser simple y clara para aquellos que vayan a consultarlo en un
futuro.
 Completo: Un requerimiento está completo si no necesita ampliar detalles en

su redacción, es decir, si se proporciona la información suficiente para su
comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio con otro

requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola

interpretación. El lenguaje usado en su definición, no debe causar confusiones
al lector.
 Verificable: Un requerimiento es verificable cuando puede ser cuantificado de

manera que permita hacer uso de los siguientes métodos de verificación,
inspección, demostración o pruebas.
Requisitos funcionales
Declaración de los servicios que el sistema debe proporcionar, cómo debe reaccionar a
una entrada particular y cómo se debe comportar ante situaciones particulares.
Describen la funcionalidad del sistema, y dependen del tipo de software, del sistema a
desarrollar y de los usuarios del mismo.
Por lo general se describen mejor a través del modelo de Casos de uso y los Casos de
uso como tal. Por lo tanto los requerimientos funcionales especifican el
comportamiento de entrada y salida del sistema y surgen de la razón fundamental de
la existencia del producto.
14
 El sistema enviará un correo electrónico cuando se registre alguna de las

siguientes transacciones: pedido de venta de cliente, despacho de mercancía al
cliente, emisión de factura a cliente y registro de pago de cliente.
 Se permitirá el registro de pedidos de compra con datos obligatorios
incompletos, los cuales podrán completarse posteriormente modificando el
pedido. Antes de poder aprobarse los datos del pedido deben estar completos.
 Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo
(workflow) de aprobación configurado en el sistema.
 El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas
de proyecto.
 El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de
proyecto.
 El sistema permitirá el envío automatizado de cartas de entrega de órdenes
directamente al almacén.
Requisitos no funcionales
Los requerimientos no funcionales son propiedades o cualidades que el producto debe
tener. Restricciones que afectan a los servicios o funciones del sistema, tales como
restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.
Los requerimientos no funcionales tienen que ver con características que de una u otra
forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, etc. Algunas propiedades de los
requerimientos no funcionales que hacen al producto atractivo, usable, rápido o
confiable, son las siguientes
 El sistema será desarrollado para las plataformas PC y Macintosh.

 La aplicación debe ser compatible con todas las versiones de Windows, desde
Windows 95.
 La aplicación deberá consumir menos de 500 Mb de memoria RAM.
 La aplicación no podrá ocupar más de 2 GB de espacio en disco.
 La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas
latinos (Español, Frances, Portugués, Italiano), Arábico y Chino.
 La interfaz de usuario será implementada para navegadores web únicamente
con HTML5 y JavaScript
Diagramas de secuencia.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una
aplicación a través del tiempo y se modela para cada método de la clase. El diagrama de
15
secuencia contiene detalles de implementación del escenario, incluyendo los objetos y

clases que se usan para implementar el escenario, y mensajes intercambiados entre los
objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son
necesarios para la implementación del escenario. Si se dispone de la descripción de cada
caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos
pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas
discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Escenario: Registrar.
Desde esta opción, el usuario no registrado podrá darse de alta en la base de datos de nuestra
aplicación.
Inicialmente se nos pedirá que rellenemos un formulario con los datos personales, así como
nuestro identificador y contraseña. Se comprobará que el identificador elegido no este
dado de alta por otro usuario en nuestra base de datos, si ya existe mostraremos un
mensaje advirtiéndolo, en caso contrario se efectuará el alta, con su respectiva pantalla de
confirmación.
22
Escenario: Buscar producto.
16
Desde esta opción cualquier usuario puede efectuar la búsqueda de un producto. Se

buscarán las coincidencias dentro de la categoría seleccionada y se mostrarán los
resultados en un listado.
Escenario: identificarse.
En la pantalla principal nos aparecerá la opción de identificación, para que los usuarios
registrados o los usuarios administradores puedan introducir su identificador y
correspondiente contraseña, para poder tener la funcionalidad correspondiente a su rol.
17
Escenario: Comprar producto.

Una vez seleccionados los productos a comprar, se confirma que se quiere realizar la
compra, se guardan los datos del pedido en nuestra base de datos se envía un mensaje de
confirmación o en caso contrario un mensaje de advertencia.
Escenario: alta categoría.

El administrador una vez identificado, tiene la opción de introducir nuevas categorías en
nuestro catálogo de productos. Para ello introducirá el nombre de la nueva categoría y se
realizará el alta en nuestra base de datos.
18
Escenario: baja categoría.

Al igual que la operación de alta será el administrador el encargado de efectuar las bajas de
categorías. Se seleccionará la categoría que queremos borrar de nuestra base de datos y
pulsando el botón de eliminar efectuaremos la operación indicada.
Escenario: alta producto.

Nuestro administrador, tendrá la función de dar de alta productos, para realizar esta operación
deberá rellenar un pequeño formulario con el nombre del producto, precio, características…
Una vez enviado el formulario se procederá al alta del producto.
Escenario: Baja producto.
19
Esta operación consiste en seleccionar un producto y proceder a su eliminación de nuestra

base de datos.
Escenario: Listar usuarios registrados.

Dentro de esta opción el usuario realiza una petición de todos los usuarios que están
registrados dentro de nuestra base de datos.
Escenario: Eliminar usuario registrado.

Una vez listado los usuarios seleccionaremos el usuario que se desee eliminar de la base de
datos.
20
Escenario: listar pedidos.

El administrador desde esta opción obtiene un listado con los pedidos efectuados.
Escenario: Cambio estado pedido.

El administrador dispone de esta funcionalidad consistente en seleccionar el producto y
modificar el estado en que se encuentra.
21
Arquitectura del software

Historias de Usuarios
22
ID DE LA
ROL FUNCIONALIDAD RAZÓN/RESULTADO
HISTORIA
Que pueda crear y Mantener un control sobre quien ingresa
Como
001 modificar los usuarios del al sistema.
Administrador
sistema.
Que pueda hacer una Pueda vender sus productos más fácil
002 Como vendedor
gestión de sus artículos. mente
Poder gestionar la
Servirá para que se puedan hacer
003 Como Comprador cantidad de artículos
compras más eficientes y rápidas
comprados
El poder tener la base de datos con los
Como Gerente de Que pueda gestionar los
004 proveedores que suministran los
ventas proveedores.
artículos que la empresa usa.
Los clientes serán administrados para
Como Analista de Poder gestionar los
005 poder conocer las preferencias de
Usuario Clientes.
consumo.
Poder digitalizar y controlar los
Como
Poder manejar las productos que ingresan a la empresa, a
006 Administrador de
entradas de inventario. través de la comercialización con los
almacén
proveedores.
Poder controlar la entrega de productos
Como Analista de Poder manejar las
007 y que se haga de la manera más eficaz
logística salidas de inventario.
y rápida posible
Diagrama UML
Diagrama de actividades
23
24
Casos de uso.
Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o
una actualización de software.
Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el
sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente,
en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje
más cercano al usuario final
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre
un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio
sistema.
Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento

de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual,
un diagrama que muestra la relación entre los actores y los casos de uso en un sistema.
Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y
la generalización son relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Después de esta breve introducción de los casos de uso pasamos a mostrar cada uno de ellos.
Comenzamos por mostrar los actores que intervienen en nuestro sistema, que como ya
sabemos son usuario, usuario registrado y administrador. Estos dos últimos especializan del
usuario.
25
En el siguiente diagrama tenemos las funcionalidades de todos los actores, empezamos por el
usuario, las funciones que podrá realizar serán, identificarse, registrarse, realizar búsqueda de
productos y ver la información general de los productos del catálogo, es decir navegar a nivel
general por la Web.
Además el usuario puede proceder al registro, convirtiéndose en usuario registrado.
El usuario registrado además de poder realizar todo lo comentado anteriormente se le añadirá

la funcionalidad de realizar los pedidos de los productos que crea oportuno.
26
27
28 | P á g i n a
Por último el administrador dispone de las funcionalidades de gestión de productos, añadiendo, listando o quitando productos de nuestro
listado, administración de categorías, pudiendo añadir nuevas categorías, listarlas o bien eliminar alguna de ellas, gestión de usuarios, teniendo
la posibilidad de realizar un listado de usuarios registrados además de poder borrarlos, y por ultimo gestión de pedidos, consistente en el cambio
de estado del pedido y la posibilidad de listarlos.
1. CASO DE USO: CREAR CUENTA
CASO DE USO Crear cuenta
IDENTIFICADOR 1
DESCRIPCIÓN Crear una cuenta en el sistema
ACTOR PRINCIPAL Usuario y/o administrador
El Usuario debe tener correo electrónico

PRECONDICIONES
para crear la cuenta
∙Inicia cuando usuario ingresa a la pantalla

de crear sesion
∙El usuario digita los datos de nombre,

FLUJO PRINCIPAL correo y contraseña
∙El sistema envia mensaje de verificaion al

correo del usuario
POST CONDICIONES El usuario Valida la creación de una cuenta

29 | P á g i n a
Si no se valida el correo esta cuenta no se

FLUJO ALTERNATIVO
activa
2. CASO DE USO: INICIAR SESION
CASO DE USO Iniciar sesión
IDENTIFICADOR 2
DESCRIPCION Se inicia sesión
ACTOR PRINCIPAL Administrador o Usuario
El usuario ya debió haber creado una

PRECONDICIONES
cuenta
∙Escribe su correo y contraseña

FLUJO PRINCIPAL
∙ El usuario Inicia sesión
POST CONDICIONES El usuario accede al sistema
Se equivoca escribiendo el correo o la

FLUJO ALTERNATIVO contraseña, lo cual impide el inicio de
sesion
3. CASO DE USO VENDER ARTICULO
CASO DE USO Comprar
Documento de Especificación de Requerimientos de Software

30 | P á g i n a
IDENTIFICADOR 3
DESCRIPCION Crea y actualiza los artículos del sistema.
ACTOR PRINCIPAL Usuario
∙Debe existir el usuario en la base de datos
∙El usuario se debe iniciar sesión en el

PRECONDICIONES
sistema..
∙En la pantalla principal el usuario deberá

darle clic en la viñeta “vender articulo” del
menú izquierdo y posteriormente en la
opción “seleccionar”.
∙El usuario tendrá 3 opciones para llenar:
FLUJO PRINCIPAL ∙Debe poner una imagen del articulo
∙Debe poner le titulo del articulo
∙Debe poner una descripción detallada del

articulo y su precio
∙Dar clic en el botón crear para crear un

nuevo artículo
El articulo es creado con éxito y será

POST CONDICIONES
publicado después de una ligera revisión

31 | P á g i n a
Si el articulo esta incompleto este no será

FLUJO ALTERNATIVO publicado
6. CASO DE USO COMPRAR ARTICULOS
CASO DE USO Gestionar Artículos
IDENTIFICADOR 6
DESCRIPCION Compra articulo del sistema.
ACTOR PRINCIPAL Usuario
∙Debe existir el usuario en la base de datos
∙El usuario se debe iniciar sesión en el

PRECONDICIONES
sistema.
Después de seleccionar el artículo, este

debe elegir el método de compra, si se
hará por tarjeta (crédito o debito) o en su
FLUJO PRINCIPAL lugar pagara en efectivo
Después ingresa la ubicación de entrega
del producto
POST CONDICIONES Se realiza la compra
FLUJO ALTERNATIVO Si la tarjeta (crédito o débito) no posee el

32 | P á g i n a
dinero suficiente, la compra se cancela
7. CASO DE USO CERRAR SESION

CASO DE USO Cerrar Sesión
IDENTIFICADOR 7
DESCRIPCION Cierra sesión de Usuario en el sistema
ACTOR PRINCIPAL Usuario, administrador
Debe existir el usuario en la base de datos

PRECONDICIONES El usuario se debe iniciar sesion en el
sistema.
En la pantalla principal el usuario deberá

dar clic en el botón “Salir” ubicado en la
FLUJO PRINCIPAL parte izquierda de la pantalla.
Se cerrará la sesión del usuario y retornará

POST CONDICIONES
a la página de inicio de sesión.
Prototipo de Inicio de sesión:

33 | P á g i n a
MATRIZ DE TRAZABILIDAD

34 | P á g i n a

35 | P á g i n a
Diagramas del Modelo de dominio del proyecto

Diagrama

36 | P á g i n a
Diagrama de actividades

37 | P á g i n a
Interfaz
La interfaz gráfica con la que el usuario final interactúa deberá ser intuitiva de manera que, sin un manual de uso, el usuario identifique
rápidamente los componentes y las secciones del sistema. La interfaz además deberá contar con colores agradables a la vista para que el usuario
pueda trabajar por horas con el mismo sin problemas.

38 | P á g i n a
De igual forma, la interfaz deberá ser compatible con los navegadores mas comunes
(Firefox, Explorer, Chrome, Opera, Brave).

Sistema de inicio de sesión
 Correo y contraseña
 Diez intentos erróneos se bloqueará el acceso por 1 día y se notificara al correo oficial
 Cuando el usuario confirme los datos se le permitirá entrar
Menú principal
 Categorías
 Ofertas
 Historial
 Supermercado
 Moda
 Vender
 Ayuda
Modulo “Categorias”
 Tecnologia
 Vehiculos
 Electrodomesticos
 Muebles
 Fitness
 Belleza
 Accesorios
 Herramientas
 Construcion
 Compra internacional
 Juegos y juguetes

39 | P á g i n a
 Bebes
 Salud
Modulo “Ofertas”
 Todas las ofertas
 Ofertas relámpago
 Productos exclusivos
 Celulares
 Menos de $50.000(Precio sujeto a cambios)

40 | P á g i n a

41 | P á g i n a
Propuesta técnica
FICHA TÉCNICA
COMPUTADOR
Nombre del dispositivo: computador o PC (para aplicación de uso general)
Solución-proyecto: para proyecto de software de aplicación
Especificaciones mínimas requeridas: características mínimas del dispositivo
Características físicas:
Tabla 1
Características físicas – computador
Ítem Cantidad por Componente Descripción

componente
1 1 Mouse Óptico inalámbrico 2.4 GHz
2 1 CPU Core i7-6950x
3 1 Monitor plano LCD de Asus VG248QE I 24 pulgadas

24 -144Hz

42 | P á g i n a
4 4 Cables de poder Enchufe Black Awin 2mm
5 1 Cámara web Cámara web Logitech Hd Pro

Webcam C920
6 1 Cable de conexión para Cable VGA.
el monitor
7 1 Teclado Microsoft Teclado Bluetooth Español
Wedge Mobile (29,8 x 14,2 x 5 cm), negro
keyboard
8 1 Fuente de Poder FSP Haxa+400W
9 1 Mouse Inalámbrico Logitech Wireless Mouse

M320
10 1 Tarjeta madre INTEL DG41TY
Especificaciones técnicas:
Tabla 2
Características técnicas – computador
Ítem Cantidad por Componente

equipo

43 | P á g i n a
1 1 Procesador i5-7600k.
2 2 Slots Modulo memoria RAM puede soportar 8 Gbytes de
memoria RAM.
3 1 Disco duro de 1 tera
4 1 Mainboard
5 1 Sistema Operativo Microsoft Windows 10 Pro 32/64 bit
6 1 Adaptador de red (tarjeta red)10/100/100Mbps, conector RJ-
45. (Integrado, que soporte IEEE802.1x.)
7 - Adaptador inalámbrico (Tarjeta de red para conexiones
inalámbricas) con antena integrada, que soporte IEEE
802.11b/g WEP, WPA, IEEE802.1X. debe ir a un slot del
computador. No se permiten que se conecten de forma
externa a puertos USB u otros puertos del computador.
8 1 Modulo de memoria RAM de 4 Gbytes
9 1 Sistema operativo Linux Ubuntu
10 - El fabricante de los equipos debe certificar que las partes que
conforman el equipo son interoperables y compatibles

44 | P á g i n a
Garantía:
Tabla 3
Garantía – computador
Ítem Cantidad Componente

1 1 Garantía para el computador y todas sus partes
FICHA TÉCNICA SERVIDOR
Ítem Característica Valor

(Debe ser diligenciado por la
empresa)
1 Cantidad de usuarios
estimados.
2 Ubicación de los usuarios

estimados.
3 Software que va a ser

45 | P á g i n a
Nombre de Versión Fabricante

instalado en el servidor
software
YUCATECO 1.1.2 Grupo # 3
Características físicas:
Tabla 4
Características físicas – servidor

1 1 Servidor
Especificaciones técnicas
Tabla 5
Especificación técnica – servidor

46 | P á g i n a
Ítem Cantidad Componente Descripción

1 1 Procesador Intel Xeon E5-2600 hasta dos ranuras
disponibles.
2 1 Almacenamiento B140i estándar para acceder

rendimiento de prestaciones
adicionales.
3 1 Conectividad red 4X integrada- independiente de 1 GB.
4 1 Formato Torre ultramicro.
5 2 Memoria SmartMemory (24) DDR4 hasta 2.133
Mhz. (768 GB máx)
6 1 Ranura de expansión Ranura AGP 3.3 Volts Esquema de la
ranura AGP 1.5 Volts.
7 1 Cache de procesador 2MB L2.
8 1 Núcleo de procesador INTEL Core 2 Dúo E8400 CPU DE
disponible. DOBLE NÚCLEO Del procesador INTEL
E8400.
9 1 Tarjetas de red Adaptador Ethernet NC107i de 2 GB.
100/1000Mbps – RJ45
10 - Tipo de memoria 2R X8 PC3-10600E-0

47 | P á g i n a
Garantía:
Tabla 3
Garantía – computador

1 1 Garantía para el computador y todos sus componentes.

48 | P á g i n a
CRONOGRAMA DE ACTIVIDADES

49 | P á g i n a
Documentación
INVITACION A COTIZAR SOFTWARE YUCATECO PARA PÁGINA WED
1.1 OBJETO DE LA INVITACION
La Preston Inc. contratará con Empresa debidamente constituida, para la, instalación
adecuación, implementación y acompañamiento del software YUCATECO
1.2 VALOR DEL CONTRATO
El valor del contrato resultante de esta invitación será hasta por la suma de QUINCE
MILLONES CUATROCIENTOS OCHENTA MIL PESOS MCTE ($15.480.000)
1.3 ESPECIFICIACIONES TECNICAS
- Instalación (Última Versión) e implementación del software de aplicación
-prestaciones de servicio en venta de artículos por medios web.
- Configuración, parametrización del sistema y migración de datos desde el
sistema de información.
- Automatización de Catálogos e Integración de los datos y acceso a los mismos a
través de Internet.
- Capacitación (Usuarios, Administradores del Sistema) y visitas a Comfenalco
Tolima de acompañamiento 6 Visitas / 8 horas (Total 48 horas).
- Mantenimiento y soporte anual.
- Horario de atención para acceso remoto 7/24.
- Entrega de Manuales.

Especificación de Requerimientos de Software

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 Requerimientos de Software

Cargado por

Copyright:

Formatos disponibles

Especificación De Requerimientos De Software

EDNA MARGARITA ESTEBAN REGINO

TECNOLOGÍA EN ANÁLISIS Y DESARROLLO DE SOFTWARE

La Ingeniería de Software, se considera la rama de la ingeniería que aplica los

La ingeniería de requisitos es una disciplina de la Ingeniería de software. Esta

Las entrevistas son reuniones normalmente de dos personas, en las que se

Las entrevistas deben planificarse, determinando su duración, los temas a

Cuestionario de requerimientos iniciales

1. Establecer el perfil del usuario o Afectado

Para cada problema

3. Evaluando y Entendiendo el ambiente de usuario

¿Cada dependencia u organismo, depende de una misma

4. Resumen para validar el Entendimiento del Problema

5. Evaluando las soluciones del analista (si esto es aplicable)

7. Evaluando las necesidades esta aplicación en su organización

¿Cuáles, si los hay, son los requerimientos sobre

9. Resumen del Analista

Descripción: Tienda Virtual

Al momento de desarrollar un proyecto se debe pensar en cuáles serán las

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De

1. Técnicas de análisis de requisitos

Requerimientos Valor del Puntos de Cociente

2.1 Estándar IEEE 830

2.2 Estándar IEEE 29148:2018

 Propósito, alcance de estándar, generalidades.

B. Esta norma propone un listado de requerimientos como:

2.3 La especificación de requisitos a través de marcos de trabajos agiles.

Las historias de usuario tienen otros beneficios con respecto a otros

 Se centran en solucionar problemas a usuarios reales

2.4 Scrum y la especificación de requisitos

La validación de requerimientos busca ratificar que los requerimientos

Existen técnicas para la validación de requisitos.

1.1 Revisiones de requerimientos

1.2 Construcción de prototipos

Para la fase de verificación de requisitos se recomienda el uso de prototipos

Características de los requerimientos

Los requerimientos deben especificarse antes de intentar comenzar la construcción del

Las características de un requerimiento son sus propiedades principales. Un conjunto

 Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia

 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su

 Completo: Un requerimiento está completo si no necesita ampliar detalles en

 Consistente: Un requerimiento es consistente si no es contradictorio con otro

 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola

 Verificable: Un requerimiento es verificable cuando puede ser cuantificado de

 El sistema enviará un correo electrónico cuando se registre alguna de las

 El sistema será desarrollado para las plataformas PC y Macintosh.

secuencia contiene detalles de implementación del escenario, incluyendo los objetos y

Escenario: Buscar producto.

Desde esta opción cualquier usuario puede efectuar la búsqueda de un producto. Se

Escenario: Comprar producto.

Escenario: alta categoría.

Escenario: baja categoría.

Escenario: alta producto.

Escenario: Baja producto.

Esta operación consiste en seleccionar un producto y proceder a su eliminación de nuestra

Escenario: Listar usuarios registrados.

Escenario: Eliminar usuario registrado.

Escenario: listar pedidos.

Escenario: Cambio estado pedido.

Arquitectura del software

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento

Además el usuario puede proceder al registro, convirtiéndose en usuario registrado.

El usuario registrado además de poder realizar todo lo comentado anteriormente se le añadirá