Clase 02 Tecnicas de Busqueda de Requerimientos 15 12 23

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION
Curso
Técnicas de búsqueda de requerimientos.
Clase 2: Actividades del análisis de requerimientos. Técnicas Para la
Obtención de Requerimientos. Ejemplos para desarrollar el Trabajo
Lima, 15 de diciembre de 2023

Prof. Juan Daniel Daza Hermoza
Diapositiva 2 Fecha: 13/12/2023
ingenieria.sistemas.2030@gmail.com
1. Tener los micrófonos apagados.
2. Sólo active su micrófono si va a participar,

después lo desactiva.

Para participar levante la
mano, indique su nombre y
el lugar de donde se conecta

Participación de todos ustedes
¡¡¡¡¡Poner en
el Zoom sus
nombres
completos!!!!!

¿Que vimos la clase pasada?

Ingeniería de requerimientos
La ingeniería de requerimientos es el proceso de
identificar, documentar y gestionar los requisitos que
deben cumplir un sistema, producto o servicio.
Este proceso implica la comprensión y el análisis de las
necesidades de los usuarios, así como la traducción de
esas necesidades en especificaciones claras y detalladas
que guíen el desarrollo del producto o sistema.
La ingeniería de requerimientos es fundamental en la
ingeniería de software y en otros campos de la ingeniería,
ya que sienta las bases para el diseño y la implementación
exitosa de un producto o sistema que satisfaga las
necesidades y expectativas de los usuarios.
Ingeniería de Software
La ingeniería de software es una disciplina que se encarga
de aplicar principios de la ingeniería al desarrollo,
mantenimiento y gestión de software.
Se centra en la creación de software de alta calidad,
confiable y eficiente, utilizando métodos y herramientas
que permiten controlar el proceso de desarrollo y asegurar
que el software cumpla con los estándares de calidad.
La ingeniería de software abarca desde la planificación y
análisis de requisitos, hasta el diseño, implementación,
pruebas y mantenimiento del software.

Requerimientos Funcionales
“Los requerimientos funcionales son las descripciones explicitas del comportamiento que
debe tener una solución de software y que información debe manejar.”
Por lo tanto, los requerimientos funcionales:
✓ Expresan las capacidades o cualidades que debe tener la solución para satisfacer los
requerimientos de los interesados de proyecto.
✓ Se expresan en términos de cuál debe ser el comportamiento de la solución y que
información debe manejar.
✓ Deben proporcionar una descripción lo suficientemente detallada para permitir el
desarrollo e implementación de la solución.
✓ Son los que más influyen en si la solución será aceptada o no por los usuarios.
Entre los posibles requerimientos funcionales de un
sistema, se incluyen:
 Descripciones de los datos a ser ingresados en el

sistema.
 Descripciones de las operaciones a ser realizadas por
cada pantalla.
 Descripción de los flujos de trabajo realizados por el
sistema.
 Descripción de los reportes del sistema y otras salidas.
 Definición de quien puede ingresar datos en el sistema.
 Como el sistema cumplirá los reglamentos y
regulaciones de sector o generales que le sean
aplicables.
Requerimientos No Funcionales
Se refieren a las cualidades, restricciones y características del software. A diferencia
de los funcionales, no determinan una funcionalidad del sistema a desarrollar.
Los requisitos no funcionales, también conocidos como "requisitos de calidad" o
"requisitos de atributos del sistema", son características y criterios que describen cómo
debe ser el rendimiento, la seguridad, la usabilidad y otros aspectos de un sistema o
software más allá de su funcionalidad básica.
Ejemplos de requisitos no funcionales
Los requisitos no funcionales variarán según el contexto y los objetivos específicos de

cada sistema, aquí algunos ejemplos por tipo de sistema:

Ejemplos de requisitos no
funcionales
Sistema de comercio electrónico:
❑ Rendimiento: El sistema debe cargar páginas en un tiempo promedio de menos

de 2 segundos.
❑ Escalabilidad: El sistema debe ser capaz de manejar un aumento del 50% en el

tráfico durante la temporada de ventas sin degradar el rendimiento.
❑ Disponibilidad: La tasa de disponibilidad objetivo debe ser del 99.9%, por lo que
el sistema debe estar disponible las 24 horas del día, los 7 días de la semana, con
un tiempo de inactividad máximo de 1 hora al mes para mantenimiento
programado.
Sistema de gestión de inventario:
❑ Eficiencia: Las consultas de búsqueda y filtrado de inventario deben

completarse en menos de 1 segundo.
❑ Estabilidad: El sistema debe poder funcionar durante al menos 6 meses

continuos sin requerir reinicios debido a fallos.
❑ Capacidad de recuperación: En caso de una caída del servidor, el sistema debe

ser capaz de recuperar y restaurar los datos de inventario desde la última copia
de seguridad.

Red social:
Interoperabilidad: El sistema debe ser capaz de autenticar usuarios a través de sus

cuentas de Google, Facebook y Twitter.
Privacidad: Los datos personales de los usuarios deben estar protegidos según las
regulaciones de protección de datos y no se compartirán con terceros sin el
consentimiento explícito del usuario.
Localización y globalización: La interfaz de usuario debe ser localizable para diferentes

idiomas y culturas, y mostrará contenido relevante según la ubicación del usuario.

Empecemos
la Clase!!!!

Actividades del análisis de requerimientos
El proceso del establecimiento de requerimientos de un sistema de
software, como ya mencionamos, es el primer paso esencial en
entregar lo que el cliente desea. A pesar de esto, la insuficiencia de
tiempo y esfuerzo son a menudo encontrado en esta actividad y
existen pocos métodos sistemáticos para soportarlo. Entre los
métodos conocidos se puede citar a los siguientes:
Para Pressman, en el proceso de análisis de requerimientos del

software se puede identificar cinco tareas o etapas fundamentales:

Reconocimiento del problema.
Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto
del software. Realmente se necesita llegar a comprender el software dentro del contexto
del sistema. El analista debe establecer un canal adecuado de comunicación con el equipo
de trabajo involucrado en el proyecto. En esta etapa la función primordial del analista en
todo momento es reconocer los elementos del problema tal y como los percibe el usuario.
Evaluación y síntesis.
En esta etapa el analista debe centrarse en el flujo y estructura de la información,
definir las funciones del software, determinar los factores que afectan el desarrollo de
nuestro sistema, establecer las características de la interfaz del sistema y descubrir las
restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la
determinación del problema de forma sintetizada.
Modelización.
Durante la evaluación y síntesis de la solución, se crean modelos
del sistema que servirán al analista para comprender mejor el
proceso funcional, operativo y de contenido de la información. El
modelo servirá de pilar para el diseño del software y como base
para la creación de una especificación del software.
Especificación.
Las tareas asociadas con la especificación intentan proporcionar
una representación del software. Esto más adelante permitirá
llegar a determinar si se ha llegado a comprender el software, en
los casos que se lleguen a modelar se pueden dejar plasmados
manuales.
Revisión.
Una vez que se han descrito la información básica, se
especifican los criterios de validación que han de
servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito
el software.
La documentación del análisis de requerimientos y
manuales, permitirán una revisión por parte del
cliente, la cual posiblemente traerá consigo
modificaciones en las funciones del sistema por lo
que deberán revisarse el plan de desarrollo y las
estimaciones previstas inicialmente.

Método CORE
El método Controlled Requirements Expression (CORE)
[Norris] es un conjunto de notaciones textuales y
gráficas, con guías especificadas para la captura y
Modelación
validación de requerimientos del sistema, en las Definición del
Problema
combinada de
Análisis de
restricciones
Puntos de Vista
etapas iniciales del diseño del sistema.
CORE ha sido, por tradición, pensado como Estructuración
del Punto de
Modelación
individual de
puramente una técnica de captura y análisis de vista Puntos de Vista
requerimientos (RCA), aunque soporta algunos

Colección Estructuración
aspectos de diseño tales como estructuras de datos. Tabular de datos
CORE está basada en el principio de primero definir el

problema a ser analizado (definición del problema), y
luego dividirlo en unidades o puntos de vista a
considerar.
Definición del problema.
El propósito de la definición del
problema es identificar los límites del
mismo.
Contiene detalles de los objetivos de
la empresa de los usuarios del
sistema, la base para la necesidad de
un nuevo sistema, limitaciones de
costo y tiempo, y quién va a ser el
responsable de la revisión y
aceptación de los resultados finales.
Estructuración del punto de vista.
El propósito de esta etapa es descomponer el
ambiente del sistema en los elementos para que el
sistema propuesto pueda ser analizado desde los
puntos de vista de todas las entidades que se
comunican con él, la más importante de las cuales son
los usuarios.
Durante esta etapa, todas las entidades que son
fuentes potenciales de información deben ser
identificadas.

Colección tabular.
Flujo de datos Esta etapa es cuando la información
Puntos de Procesami sobre los flujos de datos entre los
Vista ento puntos de vista y el procesamiento
de éstos son reunidos. Esto ayuda a
establecer la totalidad y
consistencia.

Estructuración de datos.
En la etapa previa, los
elementos de información que
pasan entre los puntos de vista
son referidos por sus nombres
generales.
En esta etapa, se da una vista
más cercana al contenido, a la
estructura y a la derivación de
datos, al producir diagramas
de estructura de datos.

Modelación individual de puntos de vista.
Esta etapa puede dividirse en dos partes.
Lo único concerniente a la primera es convertir
las TCF'S en una notación diferente para
producir los diagramas individuales del modelo
de punto de vista.
La segunda parte se refiere a agregar alguna
información nueva perteneciente a flujos de
datos internos, control de acciones y tiempo de
acciones.

Modelación combinada de punto de
vista.
Esta etapa facilita el análisis de una
secuencia de eventos de más de un
punto de vista. Cada diagrama de
modelo combinado de punto de vista
producido durante esta etapa es una
representación del procesamiento de
información que ocurre entre puntos
de vista.

Análisis de restricciones.
En esta etapa, se consideran
restricciones adicionales tales como
desempeño y seguridad.
Éstas pueden afectar los diagramas
de puntos de vista ya producidos.
Las restricciones se documentan en
una especificación de restricción
del sistema.

Procesos de Búsqueda de Requerimientos
Como sabemos, un área de conocimiento de
gran importancia en el desarrollo de
software, es la ingeniería de requerimientos.
Esta comprende las actividades de obtención
(captura, descubrimiento y adquisición),
análisis (y negociación), especificación, y
validación de requisitos.
Además, establece una actividad de gestión
de requerimientos para manejar los cambios,
mantenimiento y rastreabilidad de los
requerimientos.

Técnicas Para la Obtención de
Requerimientos
Existe un gran número de técnicas para

obtener requerimientos.
A continuación describo las más
utilizadas.
Hay que aclarar que ninguna de estas
técnicas es suficiente por sí sola y que es
recomendable combinarlas para
obtener requerimientos completos.

Entrevistas
La entrevista es de gran utilidad para obtener información
cualitativa como opiniones, o descripciones subjetivas de
actividades.
Es una técnica muy utilizada, y requiere una mayor preparación y
experiencia por parte del analista. La entrevista se puede definir
como un “intento sistemático de recoger información de otra
persona” a través de una comunicación interpersonal que se
lleva a cabo por medio de una conversación estructurada.
Debe quedar claro que no basta con hacer preguntas para
obtener toda la información necesaria.
Es muy importante la forma en que se plantea la conversación y
la relación que se establece en la entrevista.
Estos son algunos de los aspectos más importantes a tener en cuenta
al realizar entrevistas:
❖ Preparación. Es necesario documentarse e investigar la situación de la organización
analizando los documentos disponibles, de tal forma que la entrevista se enfoque en
aquellos aspectos que están solamente en la mente del entrevistado y que no son
accesibles por otros medios como la observación o el análisis de documentos.
❖ Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-
down, comenzando a entrevistar a directivos para que brinden un panorama general
de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que
aportan detalles importantes de la operación.
❖ Duración. Una entrevista debería durar a lo sumo un par de horas.
❖ Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan
elaborar y dar detalles, más allá de simplemente responder “si” o “no”.
Desarrollo Conjunto de Aplicaciones ( JAD )
Es una técnica que se utiliza para promover la
cooperación y el trabajo en equipo entre
usuarios y analistas.
Consiste en realizar sesiones en las que
participan usuarios expertos del dominio junto
a analistas de software.
La idea es aprovechar la dinámica de grupos
aplicando un proceso de trabajo sistemático y
organizado, apoyado por elementos visuales de
comunicación y comprensión de soluciones.

Las razones que sirven de base a JAD son las siguientes:
❖ Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino

también en redactar un conjunto de requisitos coherente a partir de opiniones
diferentes de los distintos entrevistados.
❖ Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo
el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y
detectar defectos.
❖ El JAD propugna una participación más profunda de los usuarios en el proyecto,
hasta tal punto que los usuarios que participan adquieren un cierto sentido de
propiedad en el sistema que se construye.

Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas,
demos o conjuntos de pantallas (que no son totalmente
operativos) de la aplicación pedida. Esta técnica es
particularmente útil cuando:
❖ El área de la aplicación no está bien definida

(posiblemente por ser algo muy novedoso).
❖ El costo del rechazo de la aplicación por los usuarios es
muy alto.
❖ Es necesario evaluar previamente el impacto del
sistema en los usuarios y en la organización.

Los prototipos de sistema permiten a los usuarios
experimentar para ver cómo éste ayuda a su trabajo.
Fomentan el desarrollo de ideas que desembocan en
requerimientos. Además de permitir a los usuarios mejorar
las especificaciones de requerimientos, el desarrollo de un
prototipo tiene otras ventajas:
1. Al demostrar las funciones del sistema se identifican las

discrepancias entre los desarrolladores y los usuarios.
2. Durante el desarrollo del prototipo, el personal del
desarrollo de software puede darse cuenta de que los
requerimientos son inconsistentes y/o están
incompletos.

3. Aunque limitado, se dispone rápidamente de un sistema
que funciona y demuestra la factibilidad y usabilidad de la
aplicación a administrar.
4. El prototipo se utiliza como base para escribir la
especificación para la producción.
En general, el uso de esta técnica es un medio que permite
solventar objeciones del usuario del tipo: “No sé exactamente
lo que quiero, pero lo sabré cuando lo vea”.
Por lo general, la construcción de prototipos incrementa los
costos en las etapas iniciales de un proyecto, pero esto se
recupera en etapas posteriores gracias al mejor
entendimiento de los requerimientos por parte de los
desarrolladores
Observación
Por medio de esta técnica el analista obtiene
información de primera mano sobre la forma en
que se efectúan las actividades.
Este método permite observar la forma en que se
llevan a cabo los procesos y, por otro, verificar que
realmente se sigan todos los pasos especificados.
Como sabemos, en muchos casos los procesos son
una cosa en papel y otra muy diferente en la
práctica. Los observadores experimentados saben
qué buscar y cómo evaluar la relevancia de lo que
observan.

Estudio de documentación
Varios tipos de documentación, como
manuales y reportes, pueden proporcionar
al analista información valiosa con respecto
a las organizaciones y a sus operaciones.
La documentación difícilmente refleja la
forma en que realmente se desarrollan las
actividades, o donde se encuentra el poder
de la toma de decisiones.
Sin embargo, puede ser de gran
importancia para introducir al analista al
dominio de operación y el vocabulario que
utiliza.
Cuestionarios
El uso de cuestionarios permite a los analistas
reunir información proveniente de un grupo
grande de personas.
El empleo de formatos estandarizados para las
preguntas puede proporcionar datos más
confiables que otras técnicas; por otra parte, su
amplia distribución asegura el anonimato de los
encuestados, situación que puede conducir a
respuestas más honestas.

Tormenta de ideas ( Brainstorming )
Consiste en reuniones con cuatro a diez personas
donde como primer paso sugieren toda clase de
ideas sin juzgar su validez –por muy disparatadas
que parezcan–, y después de recopilar todas las
ideas se realiza un análisis detallado de cada
propuesta.
Esta técnica se puede utilizar para identificar un
primer conjunto de requisitos en aquellos casos
donde no están muy claras las necesidades que hay
que cubrir, o cuando se esta creando un sistema
que habilitará un servicio nuevo para la
organización.

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde
los puntos de vista Humano y Técnico )
Constituye un método bastante evolucionado para
fomentar la participación de los usuarios en los proyectos.
Creado por E. Mumford en 1979, coordina la perspectiva
social de los sistemas con su implementación técnica.
Un sistema no tiene éxito si no se ajusta a los factores
sociales y organizacionales que rigen a la empresa.
Se busca la satisfacción de los empleados en el trabajo a
través de estudios integrales.
Los requisitos técnicos del sistema serán los necesarios
para mejorar la situación de los empleados (y, por lo
tanto, su productividad) en función de dichos análisis.
Puntos de Vista
Cualquier sistema de software no trivial debe
satisfacer las necesidades de un grupo diverso
de interesados (stakeholders). Cada uno de
estos puede tener intereses diferentes en el
sistema de software, y por lo tanto sus
necesidades pueden generar requerimientos
que tengan conflicto entre sí, o incluso se
contradigan.

Las etapas principales de este método son:
1. Identificación de puntos de vista, que implica descubrir los que reciben los servicios
del sistema e identificar los servicios específicos que se suministran a cada punto
de vista.
2. Estructuración de puntos de vista, que comprende agrupar los relacionados en una
jerarquía. Los servicios comunes se ubican en los niveles altos de la jerarquía y se
heredan los puntos de vista de bajo nivel.
3. Documentación de puntos de vista, que comprende refinar la descripción de éstos
y los servicios identificados.
4. Trazado del punto de vista del sistema, que comprende identificar los objetos en un
diseño orientado a objetos utilizando la información del servicio encapsulado en los
puntos de vista.
Escenarios
Estos se utilizan para documentar el comportamiento
del sistema cuando se le presentan eventos específicos.
Cada evento de interacción distinto, o la selección de un
servicio del sistema, se documentan como un escenario
de eventos distinto.
Los escenarios de eventos incluyen una descripción del
flujo de datos y las acciones del sistema, y documenta
las excepciones que puedan surgir.
Las convenciones para los diagramas utilizados en los
escenarios de eventos son:

1. Los datos proporcionados desde un punto de vista o proporcionados a éste se
representan como elipses.
2. Las entradas y salidas de la información de control se ubican en la parte superior de
cada recuadro.
3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas,
significa que pertenecen al sistema.
4. Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, éstas se encierran en un recuadro.
5. El nombre del siguiente evento esperado después de completar el escenario se
muestra en un recuadro sombreado.

Etnografía
La etnografía es una técnica de observación que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por sí solo en el
entorno laboral donde el sistema se utilizará. El trabajo diario se observa y se hacen notas
de las tareas reales en las que los participantes están involucrados.
La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:
1. Los requerimientos que se derivan de la forma en la que la gente
trabaja realmente más que de la forma en la que las definiciones de
los procesos establecen que debería trabajar.
2. Los requerimientos que se derivan de la cooperación y conocimiento
de las actividades de la gente.

Estrategia para la obtención de requerimientos
1. Aprender todo lo que se pueda de los documentos, formularios, informes y archivos
existentes. Es sorprendente lo que se puede aprender de un sistema sin necesidad de
quitarle tiempo a la gente.
2. De ser posible, se observará el sistema en acción. No se plantearán preguntas. Tan sólo
se observará y se tomarán notas o dibujos. Conviene asegurarse de que las personas
observadas saben que no se les está evaluando. En caso contrario, harán su trabajo de
manera más eficaz que lo normal.
3. Diseñar y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien.
Será también buen momento para solicitar opiniones sobre los problemas y las
limitaciones. Los cuestionarios requieren que los usuarios inviertan una parte de su
tiempo. Pero son ellos los que pueden elegir cuándo les viene mejor hacerlo.
4. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha
recogido una base de requerimientos iniciales en los pasos anteriores, se pueden
utilizar las entrevistas para verificar y aclarar las cuestiones y los problemas de
mayor dificultad. En este punto se pueden llegar a aplicar algunas de las otras
técnicas cómo Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo
de Prototipos.
5. Se verifican los requerimientos a través del uso de técnicas como Entrevistas,
Observación y orientados a Puntos de Vista.

¿Preguntas?

DESARROLLAR UN SISTEMA WEB PARA
LA INTEGRACIÓN DE OPERACIONES
COMERCIALES DE LA EMPRESA
JUNIOR SAC

El Negocio:
La empresa Junior S.A.C. está
situado dentro de la industria
del comercio de dulces
tradicionales de diferentes
departamentos del Perú.
La empresa está ubicada en
Jr. Montevideo N°580 –
Departamento: Lima
Centro de Lima, Interior 271.
Esta empresa actualmente
cuenta con 3 tiendas en el
lugar ya descrito.

Distrito: Lima
Provincia: Lima

Jr. Montevideo 580
Junior S.A.C.

Misión:
La empresa Junior S.A.C., es una empresa que satisface los gustos de sus clientes con
productos de calidad, ricos y que cumplan con los altos requerimientos de sanidad. Nos
distinguimos de la competencia por precios más bajos, horario de atención conveniente
y calidad de servicio
Visión:
Seremos la cadena de dulcería tradicional más grande dentro de la industria de la
confitería, con presencia nacional, líder por su calidad de atención y respaldado por
una organización de clase nacional, caracterizándonos como la cadena de mayor
cobertura y ventas del país.

Organigrama de la Empresa Junior SAC

Con respecto a la organización de la empresa Distribuidora Junior
S.A.C. en el tercer nivel están los de contabilidad, recursos
humanos, compras, ventas, almacenes, empaquetado y despachados, en el segundo nivel
están Departamento administrativo, departamento comercial y departamento de
operaciones, y por último en el primer nivel se encuentra el Gerente General
DESCRIPCIÓN DEL PROBLEMA
La empresa Junior S.A.C. tiene problemas en sus operaciones de comercialización,

especialmente en las áreas de compra, venta y almacenes, presentando demoras en la
realización de las ventas y en las consultas de stock de los productos en los almacenes.

Otro problema que señalar es que existe una descoordinación
con el área encargada de las compras, debido que se realiza de
forma tradicional, en otras palabras, se registra en formularios de Excel además que no
cuenta con una herramienta de integración que gestione las distintas áreas del sistema de
comercialización.
El problema con el sistema actual es que no se lleva un control dentro de los almacenes y
el stock de los productos, ya que es un sistema basado netamente en el uso de papeles y
cuentas a base de calculadoras; el stock se controla mediante el conteo de los productos a
través de los empleados, llegando a tener fallas y datos erróneos; Las compras se realizan
mediante el conteo de los pedidos con anticipación y cálculo mental de las supuestas
ventas a realizar al día siguiente.

Requerimientos Funcionales
Representación de las necesidades del cliente, orientadas a realizar una función en el
sistema.
a) RF01: Inicio de sesión.

Dentro de la página Web, el sistema podrá Administrar a un cliente o podrá
iniciar sesión con una cuenta el cliente.
b) RF02: Creación de roles y perfiles.
El sistema permitirá crear y asignar los distintos roles a los trabajadores
registrados.
c) RF03: Registro de los clientes.
El sistema permitirá registrar los datos esenciales de los clientes como
nombres, apellidos, DNI, RUC, teléfono, dirección, etc.
d) RF04: Búsquedas de los productos y sus detalles.
Los clientes y vendedores podrán ver los detalles del producto antes de realizar una
venta, los datos a mostrar serán el stock y los detalles de los componentes del
producto, fecha de producción, fecha de vencimiento, marca, nombre, etc.
e) RF05: Búsqueda por filtros (Tipo de producto, trabajadores, fechas, etc.).

Los usuarios del sistema podrán realizar búsqueda con filtros de la diversa
información de la empresa según su rol. Ejemplo: Los trabajadores podrán filtrar al
cliente por DNI, nombre, etc. Los clientes podrán filtrar los productos por: Marca,
nombre, fecha de producción, fecha de vencimiento, etc.

f) RF06: Movimientos de los productos (entradas y salidas).
El sistema deberá de registrar las entradas y las salidas de los productos con su
respectiva fecha y cantidad.
g) RF07: Administrar el catálogo de productos.

El administrador podrá registrar nuevos productos y sus detalles, así como la
modificación y/o eliminación de algún producto.
h) RF08: Creación de Órdenes de Compra.

Los vendedores podrán registrar las órdenes de compra en el sistema.

i) RF09: Registrar las ventas.
Los vendedores podrán registrar las ventas en el sistema, luego de reconocer el pago
efectuado en la orden de compra.
j) RF10: Consultas de las ventas registradas para el despacho de los productos.

El área de almacén podrá ver las ventas registradas para poder alistar los productos a
despachar.
k) RF11: Ventas en línea.

El sistema deberá permitir generar cotizaciones a vendedores para poder concretar
una venta.

Requerimientos No Funcionales
a) RNF01: Tiempo de Respuesta.
El sistema deberá emitir las respuestas solicitadas por cada usuario en un tiempo
menor a 5 segundos.
b) RNF02: Destreza en el manejo del Sistema.

El usuario será capaz de utilizar cualquier función del sistema sin mayores
complicaciones, haciendo uso de los elementos de ayuda del sistema en un tiempo
menor a 8 minutos y dependiendo del grado del conocimiento del usuario (Novato,
intermedio, avanzado).
c) RNF03: Encontrar una función del Sistema.

El usuario será capaz de encontrar una función del sistema en un periodo de
tiempo menor a 1 minuto, en el 90% de los casos.
d) RNF04: Seguridad
El ingreso al sistema estará restringido por contraseñas cifradas y usuarios definidos.
e) RNF05: Tiempos de Reparación.

El tiempo medio de reparación será menor a 30 minutos dependiendo de la
magnitud.
f) RNF06: Disponibilidad.
La disponibilidad del sistema será según el horario de trabajo de la empresa (lunes –
sábado de 9:00am .17:00pm)

Cualquier duda o consulta escribir al
correo
visita mi página web
repasovirtual.jimdofree.com

Eres dueño de tu propio destino!!!!!
Gracias Totales!!!

Clase 02 Tecnicas de Busqueda de Requerimientos 15 12 23

Cargado por

Información del documento

Descripción original:

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

Clase 02 Tecnicas de Busqueda de Requerimientos 15 12 23

Cargado por

Copyright:

Formatos disponibles

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION

Lima, 15 de diciembre de 2023

2. Sólo active su micrófono si va a participar,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

 Descripciones de los datos a ser ingresados en el

Los requisitos no funcionales variarán según el contexto y los objetivos específicos de

Prof. Juan Daniel Daza Hermoza

Sistema de comercio electrónico:

❑ Rendimiento: El sistema debe cargar páginas en un tiempo promedio de menos

❑ Escalabilidad: El sistema debe ser capaz de manejar un aumento del 50% en el

❑ Eficiencia: Las consultas de búsqueda y filtrado de inventario deben

❑ Estabilidad: El sistema debe poder funcionar durante al menos 6 meses

❑ Capacidad de recuperación: En caso de una caída del servidor, el sistema debe

Prof. Juan Daniel Daza Hermoza

Interoperabilidad: El sistema debe ser capaz de autenticar usuarios a través de sus

Localización y globalización: La interfaz de usuario debe ser localizable para diferentes

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Para Pressman, en el proceso de análisis de requerimientos del

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

requerimientos (RCA), aunque soporta algunos

CORE está basada en el principio de primero definir el

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Existe un gran número de técnicas para

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

❖ Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino

Prof. Juan Daniel Daza Hermoza

❖ El área de la aplicación no está bien definida

Prof. Juan Daniel Daza Hermoza

1. Al demostrar las funciones del sistema se identifican las

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

DESCRIPCIÓN DEL PROBLEMA

La empresa Junior S.A.C. tiene problemas en sus operaciones de comercialización,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza