INGENIERIA DE

REQUISITOS
MAPA MENTAL DE REQUERIMIENTOS

SENA ADSO
FICHA 2626991 | 07/10/2022
 Servicio Nacional de aprendizaje (SENA)

Tema: Caracterización de Procesos.

Actividad de aprendizaje

Evidencia GAI AA 2 mapa mental de requerimientos

Aprendices, Ficha: 2626991

Sorelys Albán, Sirley Céspedes

Nayeli Mendoza, Miguel Montealegre

Presentado a:

Edwin Andrés Flores Orejuela.

Curso: Análisis y Desarrollo de Software

Centro Atención Sector Agropecuario (CASA)

Regional Santander

Octubre 2022
INTRODUCCION

Vamos a realizar este trabajo con el objetivo de conocer todo lo relacionado Con la
ingeniería de requisitos Como un instrumento amplio que se aplica y es común
para empezar un proyecto , para la solución de un problema hoy en día en todas
las áreas del saber, tratamos e concepto de software, tipos de fuente ,clasificación
y organización de requerimientos ,verificación de documentos , con todos estos
procesos de sistema se nos facilitará el mayor de análisis de proceso a nivel de
negocio, determinación de equipo de trabajo por eso creamos el mapa mental del
negocio a estructurar. Al terminar este trabajo estaremos con plena facultad y
facilidad de poder identificar y evaluar, resolver los de problemas de un negocio o
empresa, tomando decisiones que nos permita alcanzar sus objetivos estratégico
para brindar a los consumidores una mejor calidad de productos o servicios para
generar mayor facilidad tanto para nosotros y nuestros clientes.
Mapa mental de requerimientos
 Requisitos funcionales y no funcionales

La diferencia obvia  entre los requisitos funcionales y no funcionales es que el

primero lo especifican sus usuarios, analistas comerciales y es parte de la lista de
funciones del software.
Por ejemplo, el requisito funcional de una aplicación comercial es recibir el pedido,
enriquecerlo, transformarlo y enviarlo a la Bolsa de Valores, pero el requisito no
funcional no lo especifica el usuario, sino que lo piensa un arquitecto de software,
Expertos en la materia. , Líderes técnicos y personas de apoyo.
Por ejemplo, para esta misma aplicación comercial, los requisitos no funcionales
podrían ser Conmutación por error y recuperación, registro , auditoría, latencia y
otras características de rendimiento que, la aplicación debería poder ejecutarse de
forma continua, procesar 5.000 pedidos por segundo, etc. También puede solicitar
la funcionalidad requerida para agregar usuarios, otorgar acceso, revocar el
acceso, monitorear, etc.
Cada aplicación en el desarrollo de software tiene uno u otro tipo de requisitos no
funcionales. 

Acerca de la diferencia entre los requisitos funcionales y no funcionales en el

campo del desarrollo de software. Al estimar el tiempo total de desarrollo, siempre
piense en los requisitos no funcionales y resáltelos lo antes posible. Se utilizan
para establecer expectativas correctamente desde la perspectiva de los
administradores y los usuarios. La mayoría de las veces, su gerente piensa que
una función se puede hacer en días, sin pensar en los requisitos no funcionales
que se le atribuyen, es su trabajo, un programador de software, sacar eso a relucir

Los requerimientos NO funcionales se caracterizan por ser:

 Específicos
 Cuantificables
 Verificables

Los requerimientos NO funcionales se clasifican en:

 Atributos de calidad
 Restricciones
 Interfaces externas
  Interfaces de usuario
 Control de errores

Atributos de calidad

 Características, que, al cumplirse, mejoran en gran medida la calidad del

software.
 Confiabilidad: Estos requerimientos plantean que las aplicaciones no son
perfectas, pero limitan las fallas de la aplicación a determinados valores.
 Disponibilidad: Tiempo en que debe estar disponible la aplicación.
 Seguridad: Medidas de seguridad con relación a procedimientos que
impliquen el uso de información vulnerable como, por ejemplo, las claves de
acceso al software.
 Mantenibilidad: Facilidad de reparar un defecto en el software.
 Portabilidad: El software debe funcionar en determinadas plataformas o
bajo ciertas condiciones.

Restricciones

 Requerimientos que definen los límites y condicione de cómo una

aplicación será diseñada o implementada.
 Exactitud: Indica la exactitud con la que se deben prestar los servicios.
 Restricciones de herramientas o lenguajes: Lenguajes y herramientas que
se deben usar para el desarrollo y puesta en producción de las
aplicaciones.
 Restricciones de diseño: Son restricciones en el diseño del SW como la
necesidad de seguir ciertos estándares.

Interfaces externas

 El SW a veces debe interoperar con otras aplicaciones del cliente.

 Las interfaces pueden ser de hardware, software o de comunicaciones.

Interfaces de usuario

 El diseño de las interfaces de usuario a veces se considera como una tarea

en la fase de requerimientos.
  El diseño de interfaces en borrador (wireframes, mockups y prototipos)
sirven para que el cliente pueda expresar de una mejor manera lo que
quiere.

Control de errores
 Este tipo de requerimientos indica cómo la aplicación debe responder a los
diferentes errores que se puedan presentar.
Confiabilidad:

 El usuario no puede experimentar más de dos fallas por mes en la

aplicación.

Disponibilidad: 
•    La aplicación web debe estar disponible 24/7.
•    La aplicación debe soportar «cinco nueves» en disponibilidad: Esto
significa que la aplicación estará disponible un 99,999% del tiempo al año.
Indica que la aplicación no puede estar caída por más de 5,26 minutos al
año.

Desempeño: 
•    La aplicación de recuperar la información del usuario y mostrarla en menos
de 3 segundos.
•    El computo de la presión en el fluido del freno del carro debe hacerse en
menos de 1 milisegundo.
•    La aplicación debe procesar 100consultas SQL por segundo.

Estos requerimientos son críticos para aplicaciones que funcionan en tiempo

real. Por ejemplo, aplicaciones de control de trenes, tráfico aéreo, etc.

Seguridad:  
•   La longitud de las claves de la aplicación debe ser de mínimo 8 caracteres y
debe incluir símbolos, al menos una mayúscula y al menos un número.

Mantenimiento: 
•   Se debe determinar un tiempo promedio para responder ante un error.
Ejemplo: El tiempo promedio para reparar un error debe no mayor a 8
horas.

Requerimientos de Portabilidad: 
 •       La aplicación debe funcionar en Windows, Linux, IOS.
•       La aplicación web debe funcionar en Firefox, Chrome, IE, etc.
•       La aplicación web debe funcionar en PC, tabletas y dispositivos móviles
(Android, IOS, Windows Phone).
interfaces externas

 La aplicación debe ser compatible con el servidor web Jboss.

 La aplicación debe invocar los servicios tipo REST de la empresa y
procesar sus resultados.
 El formato de intercambio de datos con la aplicación del cliente debe ser
XML.

Interfaces de usuario

El diseño de interfaces en borrador (wireframes, mockups y prototipos) sirve para

que el cliente pueda expresar de una mejor manera lo que quiere.
Control de errores

 •  ¿Cómo debe actuar la aplicación si recibe un mensaje de otra aplicación

indicando que el formato del mensaje enviado es inválido?
 •  ¿Cómo debe actuar la aplicación si encuentra un error grave?

Como se describen y clasifican los requerimientos funcionales

Los requisitos funcionales de un software se suelen registran en la matriz de

trazabilidad de requerimientos y en la especificación de requerimientos de
software, este último, documenta las operaciones y actividades que el sistema
debe poder desempeñar.

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 funcionales de aplicación en smartphone como en
escritorio de capone’s

 el sistema debe permitir el registro con sus datos completos al cliente para
poder registrarse en nuestra base de datos.

 el sistema debe permitir al cliente que cree un usuario con una contraseña
de 8 caracteres incluyendo mayúsculas minúsculas y números para mayor
seguridad

 el sistema debe permitir registrar al cliente sus metodos de pago para

tenerlos guardados no ser necesario volverlos a ingresar si hace varias
compras
o
 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á el envío automatizado de cartas de entrega de órdenes

directamente al almacén.
 A cada orden se le asignará un identificador único, que será utilizado para
identificarla en todos los procesos subsecuentes que se realicen sobre esta.
 Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un
pedido de venta.
 La facturación de pedidos de venta se realizará en lotes, por medio de una
pantalla de pedidos pendientes de facturación, la cual mostrará los pedidos
no facturados. Una vez facturados los pedidos no se mostrarán en esta
lista.
  El sistema también permitirá el registro de facturas manuales no asociadas
a pedidos, sin embargo, estas requerirán autorización por parte del grupo
de Gerentes antes de ser contabilizadas.
 El proceso de compras en el sistema abarcará los siguientes pasos y
transacciones: Ingreso de la requisición, emisión de la solicitud de
cotización y emisión de la orden de compra.
 Los elementos de la solicitud de cotización serán los mismos de la
requisición asociada, al igual que los de la orden de compra. El sistema
permitirá la emisión de solicitudes de cotización y órdenes de compra
parciales.
 La contabilización de transacciones de facturas de venta y facturas de
compra podrá configurarse para realizarse de forma automatizada a su
registro, o manualmente en lotes (Proceso Batch).
 El software debe poder emitir los siguientes estados financieros: Balance
general, Estado de ganancias y pérdidas, Estado de flujos de efectivo.
Además, debe poder emitir un listado de mayor general y mayor analítico.
 Los pedidos de compra que excedan los montos establecidos en el flujo de
liberaciones de pedidos configurados deberán pasar por las aprobaciones
establecidas en dicho flujo de aprobación.

la aplicación contara con una aplicación Para Escritorio de pc además de la del

celular debe contar con un módulo de plantillas Prediseñadas donde se le
permita al cliente guardar las preguntas con sus respectivas respuestas este
modelo se encontrará Modelos de desarrollo

La primera herramienta básica para la ingeniería de requisitos son los modelos de

desarrollo los cuales nos van a permitir organizar la forma de trabajar de modo
que está juste mejor al tipo de producto que se quiere crear.

Hay tres conceptos a diferenciar, estos son:

 Ciclo de vida software: se refiere a la extensión temporal desde la cual el

producto de software es concebido hasta su retirada, pasando por su fase
de desarrollo, despliegue y uso.
 Modelo de ciclo de vida del desarrollo de software: el ciclo de vida del
software que se compone de procesos, actividades, tareas, uso y
mantenimiento del producto software.
 Proceso de desarrollo software: modelo abstracto que describen cómo
realizar tareas durante el ciclo de vida del software se conocen también
como:
  Metodología/ proceso de desarrollo.
 Metodología de proyecto.
 Modelo de proceso o desarrollo.

Algunos modelos de desarrollo destacado son los siguientes:

Cascada

Se extraen todos los requisitos se realiza todo el diseño del producto se

genera todo el código etcétera y finalmente se entrega todo de una sola no
puede haber cambios en las fases intermedias.
 Tradicional
 Cómo en la industria del IT
 El cambio es “anatema”
 Uno de los más populares para ING. De sistemas.
 Requiere que el problema esté bien definido acostado y no sea cambiante.

Prototipo

 Tradicional, evolutivo.
 El cliente no sabes acta mente los requisitos a prioritario .
 El prototipo del producto final se desarrolla, testea y refina según el
feedback del cliente hasta tener un prototipo que conformar a la base del
producto final.
 El sistema se implementa parcialmente en la fase de análisis (el cliente
puede ver el producto en fases tempranas del desarrollo para verificar que
el desarrollo lleva el rumbo adecuado para solventar la necesidad del
negocio).

Modelo en validación

 Éxito en el 42% de los proyectos.

 Está guiado por proceso de verificación y validación: cada fase tiene
asociada otra de verificación previa para poder continuar a la siguiente; es
decir, hay una relación directa entre la fase de diseño y las de testan.
 Trazabilidad de los requisitos clara durante el proceso.

Modelo en espiral
  Se basa en el concepto de (prototipos evolutivos de rápido desarrollo).
 Muchas oportunidades de feedback de usuarios y clientes en cada iteración
hay output en forma de prototipo.
 Identificar rápidamente los cambios (en la fase de concepto) gracias a los
prototipos.

Ágiles

 Iterativo
 Dificultad para testear las funcionalidades (pues que no están definidas con
exactitud).
 Siguen funcionando aún con cambios significativo en el proyecto (51%).
 Bajo porcentaje de entregas a tiempo del producto final (8%) Pero hay
pequeñas y constantes entregas funcionales.

Modelo híbrido

 Modelo incremental ideal para sistemas.

 Sigue la misma estructura general del modelo V y del modelo incremental
pero paralelizado interacciones de especificación, desarrollo verificación-
integración.
 El rendimiento de los ciclos dependerá en el tipo de sistema es decir es
muy útil si se aprovecha su estructura paralelizada.

Fases del desarrollo de software

 Planificación: en la cual se define el planteamiento de la necesidad, la

mesa o el alcance que pretenden lograr con la implementación de la
solución.
 Análisis: encima que tiene el proceso de identificar todas las
características y necesidades del proyecto, realizar el estudio y recolección
de la información necesaria y conocer los requisitos.
 Diseño: tiene como objetivo identificar soluciones establecer métodos de
validación en dónde se establece el presupuesto del proyecto, un
cronograma de actividades, el listado de recurso humano, tecnológicos y
económicos necesarios para el desarrollo del proyecto.
 Pruebas: estafa se buscan evitar fallos cometidos en las etapas anteriores
para corregirlos.
 Mantenimiento: se realizan acciones correctivas en la fase anterior con el
fin de garantizar el perfecto funcionamiento del sistema de información.

 disponible en la aplicación de escritorio cuando vuelva a entrar están sus

datos registrados.
 la aplicación reconoce el código QR del cliente.
 la aplicación reconoce cada alveolo Pregunta mediante la cámara del
smartphone Y determinar si es la correcta o la incorrecta.
 aplicación visualizara las respuestas que son Correctas e incorrectas en la
pantalla una vez Capture la imagen.
 la aplicación permitirá administrar los resultados en la aplicación de
escritorio.
 la aplicación debe estar disponible para su descarga en play store en el
caso de sistema operativo Android y en la tienda Windows Phone
la aplicación debe ser compatible con las nuevas Versiones del sistema
operativo Android y Windows Phone.

 requerimientos no funcionales de aplicación en smartphone como en

escritorio de capone’s

 la aplicación necesita que se haga uso de una cámara.

 la aplicación necesita mínimo de 5 megas de Almacenamiento disponibles
para poder ser Instalada y pueda descargarse tanto como en smartphone
como en el escritorio.
 el software debe tener un tiempo estipulado de 5 minutos después que el
cliente entre ala aplicación si demora mucho sin usarla y estando dentro
 se pueda cerrar automáticamente si el cliente desea entrar otra vez le toca
ingresar de nuevo.
 la aplicación debe generar un código al correo registrado de parte del
cliente si en caso dado se le olvida su clave principal de usuario.
 REQUISITO NO
FUNCIONABLE

requisito requisito del requisitos

del proceso externos
producto

usabilidad espacio
interacción privacidad
entrega

potabilida
eficiencia seguridad
d ética
implementació
n
ejecución fiabilidad

legislación

estándares
 Conclusión

Podemos concluir que la ingeniería de requisitos se convierte en pieza la calidad

de un sistema informático al poder iniciar la definición de la batería de pruebas que
el sistema debe pasar garantizando que estar satisface los requisitos establecidos
y por lo tanto el sistema es válido y funcionalmente es correcto.

Para determinar si el proyecto en el que estamos trabajando es viable y cumple

con todos y cada uno de los requerimientos que nuestro cliente espera.