Está en la página 1de 37

Identificación y Desarrollo de los

Requerimientos

Competencia a desarrollar

El estudiante hace uso de las actividades, acciones y tareas que se llevan


a cabo en la gestión de requerimientos en una organización, para dar
soluciones a situaciones problemas planteadas en diferentes contextos.

Paola Andrea Marmolejo Hurtado |


1
DEFINICIONES

Software

Es el conjunto de los programas informaticos, procedimientos, reglas,


documentación y datos asociados que forman parte de las operaciones
de un sistema de computación. Extraído del estándar 729 del IEEE6

El término «software» fue usado por primera vez en este sentido por John
W. Tukey en 1957. En las ciencias de la computación y la ingeniería de
software, el software es toda la información procesada por los sistemas
informáticos: programas y datos.

Requerimiento:

• Según Benet (2003:110) “Los requisitos son la especificación de lo que


debe hacer el software, son descripciones del comportamiento,
propiedades y restricciones del software que hay que desarrollar”.

• “Un requisito del software es una característica que debe exhibir para
solucionar cierto problema del mundo real. Por lo tanto, un requisito del
software es una característica que se debe exhibir por el software
desarrollado o adaptado para solucionar un problema particular.”
(SWEBOK, 2004: 2-1).

• Los requerimientos son características que debe tener el software. Un


requerimiento funcional es un área de funcionalidad que debe soportar el
sistema y el requerimiento no funcional es una restricción sobre la
operación del sistema.

El requerimiento expresa el propósito del sistema sin considerar como


se va a implementar, es decir, que se identifica el qué del sistema,
mientras que el diseño establece el como del sistema.

Participantes y Papeles

El desarrollo de un sistema de información requiere la colaboracón de


muchas personas con diferentes formaciones e intereses:

Paola Andrea Marmolejo Hurtado |


2
• El cliente ordena y paga el sistema.
• Los desarrolladores construyen el sistema.
• El gerente del proyecto planea y cálcula el presupuesto del proyecto y
coordina a los desarrolladores y al cliente.
• Los usuarios finales son apoyados por el sustema.

Nos referimos a todas estas personas que estan involucradas en el


proyecto como participantes.

Al conjunto de responsabilidades en el proyecto o en el sistema como un


papel. Este papel es el conjunto de tareas que serán asignadas a cada
participante.

Características de los requerimientos

Las características de los requerimientos mencionados en el estándar


IEEE830 los explica [Pfleeger, 2002] como sigue:

• Correctos: El requerimiento debe poder ser interpretado


inequívocamente de una sola manera y sin errores.
• Verificable: Su implementación debe poder ser comprobada. El test
debe dar como resultado CORRECTO o INCORRECTO.
• Claro: Los requerimientos no deben contener terminología
innecesaria. Deben ser establecidos de forma clara y simple.
• Viable (realista y posible): El requerimiento debe ser factible según las
restricciones actuales de tiempo, dinero y recursos disponibles.
• Necesario: Un requerimiento no es necesario si ninguno de los
interesados necesita el requerimiento o bien si la retirada de dicho
requerimiento no tiene ningún efecto.

Paola Andrea Marmolejo Hurtado |


3
INGENIERÍA DE REQUISITOS

Ingeniería de Requisitos, es el proceso de identificar y desarrollar una


especificación de Software. Las especificaciones pretenden comunicar las
necesidades del sistema del cliente a los desarrolladores del sistema.
Trata de los principios, métodos, técnicas y herramientas que permiten
descubrir, documentar y mantener los requisitos para sistemas
basados en computadora, de forma sistemática y repetible.

La tarea de análisis de los requerimientos es un proceso de


descubrimiento y refinamiento, donde el el cliente y el
analista/desarrollador tienen un papel activo en la ingeniería de
requerimientos de software. El cliente intenta plantear un sistema donde
en ocasiones es confuso para él, sin embargo, es necesario que describa
los datos, que especifique las funciones y el comportamiento del sistema
que desea. El objetivo de los analistas es actuar como un negociador, un
interrogador, un consultor, o sea, como persona que consulta y propone
para resolver las necesidades del cliente.

Importancia

Los principales beneficios que se obtienen de la Ingeniería de Requisitos


son:

• Permitir la gestión de las necesidades del del proyecto en forma


estructurada: Cada actividad de la Ingeniería de Requisitos consiste
de una serie de pasos organizados y bien definidos.
• Mejorar y refinar las estimaciones del proyectos, así como sus
resultados, tales como estimación de costos, tiempo y recursos
necesarios.
• Disminuye los costos y retrasos del proyecto. Ya se tienen en cuenta
las lecciones aprendidas y porque permite que se tomen decisiones
adecuadas durante la Especificación de Requisitos.
• Mejora la calidad del software: La calidad en el software tiene que ver
con cumplir un conjunto de requisitos (Funcionalidad, Facilidad de Uso,
Confiabilidad Desempeño, etc.).
• Mejora la comunicación entre equipos: La especificación de requisitos
representa una forma de consenso entre clientes y desarrolladores. Si
este consenso no ocurre, el proyecto no será exitoso.
• Evita rechazos de usuarios finales: La Ingeniería de Requisitos obliga
al cliente a considerar sus requisitos cuidadosamente y revisarlos

Paola Andrea Marmolejo Hurtado |


4
dentro del marco del problema, por lo que se le involucra durante todo
el desarrollo del proyecto.

RIESGOS

De acuerdo a lo anterior, el no definir los requisitos correctamente tiene


un precio bastante alto ya que se ocasionan requisitos mal definidos;
estos errores pueden causar requisitos incompletos, incorrectos o
requisitos contradictorios, entre los que se pueden mencionar a:

• Sobrecosto ya que un error en los requisitos puede ser de 10 hasta


100 veces más costoso que un error en el código.
• Reproceso costoso,. Una equivocación en la etapa de requisitos se
arrastra en las demás fases.
• Mala calidad
• Retraso en la entrega
• Clientes descontentos
• Miembros de equipo agotados y desmoralizados

PROCESOS DE LA INGENIERÍA DE REQUISITOS

El Análisis de Requerimientos es todo un proceso al cual [Sommerville,


2005] llama “Ingeniería de Requerimientos” cuya meta es crear y
mantener un documento de requerimientos del sistema. Este proceso
general consta de cuatro subprocesos:

Paola Andrea Marmolejo Hurtado |


5
1. ESTUDIO DE LA VIABILIDAD

Se evalúa si el sistema es útil para el negocio.


[Sommerville, 2005] define el estudio de viabilidad como un estudio corto
y orientado a resolver las siguientes preguntas:

1. ¿El sistema contribuye a los objetivos generales de la organización


o empresa?
2. ¿El sistema se puede implantar utilizando tecnología actual dentro
de las restricciones de tiempo y presupuesto?
3. ¿El sistema puede integrarse a otros sistemas existentes en la
empresa?

El resultado de este estudio es un informe que recomiende si se debe


seguir o no con el proceso de desarrollo del desarrollo del sistema. En el
informe se pueden proponer
cambios en el alcance, el presupuesto o sugerir requerimientos
adicionales de alto nivel.

Paola Andrea Marmolejo Hurtado |


6
2. OBTENCIÓN Y ANÁLISIS DE REQUERIMIENTOS

En esta actividad, los analistas/ingenieros de software trabajan con los


clientes y los usuarios finales del sistema para determinar el dominio de
la aplicación, los servicios que debe brindar el sistema, el rendimiento
requerido del sistema, las restricciones hardware, etcétera.
Para ello es necesario:

• Revisar y entender la situación actual


• El dominio del problema. Comprender el contexto, los problemas y
las relaciones desde el punto de vista del usuario.
• Identificar las fuentes de información para la obtención de los
requisitos. Entre estos estan los actores del proceso (Los tipos de
usuarios que van a soportar el SW).
• Entorno de operación (Observación a los usuarios y funcionalidad
típica con el fin proporcionar información para el sistema futuro).
• Entorno de la organización.
• Hacer uso de diferentes tecnicas y herramientas para la
identificación de la información.
• Observar las estructuras y los patrones, tanto en la operación como
en la organización

Paola Andrea Marmolejo Hurtado |


7
Cuando se va a identificar los actores, puede realizar las siguientes
preguntas:

• ¿Cuales grupos de usuarios son apoyados por el sistema para


realizar su trabajo?
• ¿Cuales grupos de usuarios ejecutan las funciones principales del
sistema?
• ¿Cuales grupos de usuarios realizan funciones secundarias, como
el mantenimiento y la administración?
• ¿Interactuará el sistema con algún sistema de hardware o software
externo?

Una vez identificado los actores, el siguiente paso es determinar la


funcionalidad a la que tiene acceso cada actor, y para ello puede realizar
las siguientes preguntas:

• ¿Cúales son las tareas que el actor quiere que realice el sistema?
• ¿qué información consulta el actor? ¿Quíen crea esos datos? ¿Se
les puede modificar o eliminar?, ¿quién lo hace?

Paola Andrea Marmolejo Hurtado |


8
• ¿qué cambios externos necesita informar el actor del sistema?¿Con
cuanta frecuencia? ¿Cuándo?
• ¿Cúales eventos necesita el actor que le informe el sistema? ¿Con
cuanta latencia?

Tecnicas de obtención de los requisitos

El ingeniero de requisitos/software debe saber hacer las preguntas


precisas, investigar puntos oscuros, etc., en una labor dinámica de
extración de información. Existen varias técnicas, las mas usadas son:

• Entrevistas
• Encuestas o cuestionarios
• Mesas de trabajo
• Observación
• Analisis de Documentación
• Otros: Tales como escenarios, prototipos y formularios en uso,
visitas a otras instalaciones similares, presentaciones comerciales,
estudio de productos, tormentas de ideas e historias de usuario,
entre otras:

Paola Andrea Marmolejo Hurtado |


9
A continuación se especifican las siguientes técnicas:

a. Análisis de documentación

• Consiste en obtener la información sobre los requerimientos


funcionales y requerimientos no funcionales de software a partir de
documentos que ya están elaborados.
• Es útil cuando los expertos en la materia no están disponibles para
ser entrevistados o ya no forman parte de la organización.
• Utiliza la documentación que sea relevante al requerimiento que se
está levantando.
• Ejemplos de documentación: Planes de negocio, actas de
constitución de proyecto, reglas de negocio, contratos, definiciones
de alcance, memorándums, correos electrónicos, documentos de
entrenamiento, entre otros.

b. Observación

• Consiste en estudiar el entorno de trabajo de los usuarios, clientes


e interesados de proyecto (Stakeholders).
• Es una técnica útil cuando se está documentando la situación actual
de procesos de negocio.
• Puede ser de dos tipos, pasiva o activa.
• En observación pasiva, el observador no hace preguntas,
limitándose solo a tomar notas y a no interferir en el desempeño
normal de las operaciones.
• En observación activa, el observador puede conversar con el
usuario.

c. Entrevistas

• Se realizan con los usuarios o interesados clave.


• Direccionan al usuario hacia aspectos específicos del requerimiento
a levantar.
• Son útiles para obtener y documentar información detallada sobre
los requerimientos y sus niveles de granularidad.
• Pueden ser entrevistas formales o informales.
• Una clave es mantenerse enfocado en los objetivos de la entrevista.
• Las preguntas abiertas son útiles para identificar información
faltante.

Paola Andrea Marmolejo Hurtado |


10
• Las preguntas cerradas son útiles para confirmar y validar
información.
• El éxito de las entrevistas depende del grado de conocimiento del
entrevistador y entrevistado, disposición del entrevistado de
suministrar información, buena documentación de la discusión y en
definitiva de una buena relación entre las partes.

d. Encuestas o cuestionarios

• Es una técnica útil para recopilar eficientemente los requerimientos


de muchas personas.
• La clave para el éxito es que tengan un propósito y audiencia
claramente definida, establecer fechas topes para llenar la
encuesta, con preguntas claras y concisas.
• Deben enfocarse en los objetivos de negocio que se necesitan
identificar.
• Pueden apoyarse con entrevistas de seguimiento con usuarios
individuales.
• Pueden contener tanto preguntas cerradas como preguntas
abiertas.

e. Mesas de trabajo (Workshops)

• Es una técnica efectiva para obtener información rápidamente de


varias personas.
• Es recomendable tener una agenda predefinida y preseleccionar a
los participantes, siguiendo buenas prácticas para reuniones
efectivas.
• Se puede utilizar un facilitador neutral y un transcriptor (que no sea
el mismo facilitador).
• Se puede utilizar un material común sobre el cual enfocar la
atención y conversar, por ejemplo una presentación con un
desglose del proceso que se está estudiando o un flujograma.
• Se pueden combinar con otras técnicas como pueden ser las
entrevistas y cuestionarios.

f. Tormenta de ideas

• Es una sesión de trabajo estructurada orientada para obtener la


mayor cantidad de ideas posibles.
• Es recomendable limitarlas en el tiempo, utilizar ayudas visuales y
designar un facilitador.

Paola Andrea Marmolejo Hurtado |


11
• Las reglas son importantes, por ejemplo los criterios para evaluar
ideas y asignarles un puntaje, no permitir las críticas a las ideas y
limitar el tiempo de discusión.
• En una primera fase, se deben identificar la mayor cantidad de
ideas, para luego evaluarlas. Todas las ideas deben ser
consideradas y deben limitarse que una idea se le ahogue o critique
antes de tener tiempo de desarrollarla.

g. Historia del usuario

• Las historias de usuario, son una aproximación simple al


levantamiento de requerimientos de software, en la cual la
conversación pasa a ser más importante que la formalización de
requerimientos escritos.
• Es recomendable que sean escritas por el mismo cliente o
interesado (con apoyo del facilitador si es necesario), con énfasis
en las funcionalidades que el sistema deberá realizar.
• Al redactar una historia de usuario deben tenerse en cuenta
describir el Rol, la funcionalidad y el resultado esperado de la
aplicación en una frase corta.
• Las historias de usuario son una de las técnicas más difundidas para
levantar requerimientos de software en metodologías ágiles.

NOTA: Se sugiere leer el siguiente documento que le orientará como debe


realizar una entrevista, lluvia de ideas y Casos de uso:
http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-
_Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4
Desde la página 10 a la página 18

Principales riesgos en la obtención de los requerimientos


A continuación, se muestran algunos elementos de riesgo identificados
por [McConnell,
1997]:

• Los clientes no conocen o no tienen claro lo que quieren.


• Los clientes no quieren comprometerse a tener un conjunto de
requerimientos escritos.

Paola Andrea Marmolejo Hurtado |


12
• Los clientes insisten en establecer nuevos requerimientos una vez
que se han fijado la planificación y el coste.
• La comunicación con los clientes es lenta.
• Los clientes no participan en las revisiones o son incapaces de
hacerlas.
• Los clientes no están preparados técnicamente.
• Los clientes no dejan realizar el trabajo a la gente.
• Los clientes no entienden el proceso de desarrollo de software.

Según [Sommerville, 2005], obtener y comprender los requerimientos de


los stakeholders (interesados) es difícil por varias razones:

• Los clientes a menudo no conocen lo que desean obtener del


sistema informático excepto en términos muy generales. Pueden
hacer demandas irreales o resultarles difícil expresar lo que quieren
que haga el sistema.
• Los ingenieros de requerimientos, sin experiencia en el dominio del
cliente, deben comprender los requerimientos que los stakeholders
expresan con sus propios términos y con un conocimiento implícito
de su trabajo.
• Diferentes clientes tienen requerimientos distintos. Es necesario
descubrir las concordancias y los conflictos entre éstos.
• Los factores políticos pueden influir en los requerimientos del
sistema. Por ejemplo, los directivos pueden solicitar requerimientos
específicos del sistema que incrementarán su influencia en la
organización.
• Pueden emerger nuevos requerimientos de nuevos clientes que no
habían sido consultados previamente.

Además [Soto & González, 2010] identifican los siguientes:


• No se comprende claramente el alcance del sistema.

Paola Andrea Marmolejo Hurtado |


13
• No se logran identificar con claridad los productos resultantes del
proyecto.
• Ni los integrantes del equipo de desarrollo ni el cliente logran
especificar de forma apropiada el área de aplicación.

Establecer buenas relaciones con los clientes permite identificar mejor los
riesgos y controlarlos durante el desarrollo del proyecto.

3. ESPECIFICACIÓN DE LOS REQUERIMIENTOS

La Especificación es un documento que define, de forma completa,


precisa y verificable, los requisitos, el diseño y el comportamiento u otras
características, de un sistema o componente de un sistema.
Para realizar bien el desarrollo de software es esencial tener una
especificación completa de los requerimientos. Independientemente de
lo bien diseñado o codificado que esté, un sistema pobremente
especificado decepcionará al usuario y hará fracasar el desarrollo.

Paola Andrea Marmolejo Hurtado |


14
REQUISITOS FUNCIONALES

Los requerimientos funcionales de un sistema son aquellos que describen


cualquier actividad que este deba realizar, en otras palabras, el
comportamiento o función particular de un sistema o software cuando se
cumplen ciertas condiciones.
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.

Paola Andrea Marmolejo Hurtado |


15
• Como el sistema cumplirá los reglamentos y regulaciones de sector
o generales que le sean aplicables.

Los requerimientos funcionales deben redactarse de tal forma


que el lector pueda entender el funcionamiento del sistema sin
tener conocimientos técnicos particulares de su
funcionamiento.

Lo importante es definir una forma estándar para expresar los


requerimientos y ser consistente con la misma en todos los documentos.

Los requerimientos funcionales se pueden clasificar según su finalidad,


como por ejemplo requerimientos de negocio, requerimientos originados
en aspectos regulatorios, de seguridad, entre otros.

Ejemplos de requerimientos funcionales de proceso o área de


negocio

• 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.

• La pantalla de registro de pago puede imprimir los datos en pantalla


a la impresora.
• Se mostrará el nombre, tamaño total, espacio disponible y formato
de un pen drive o flash drive conectado al puerto USB del
computador.

Ejemplos de requerimientos funcionales legales o regulatorios

Paola Andrea Marmolejo Hurtado |


16
• El sistema controlará el acceso y lo permitirá solamente a usuarios
autorizados.
• La base de datos será implementada con trazas de auditoría.
• Las hojas de cálculo aseguraran los datos usando firmas
electrónicas.
• El sistema permitirá elaborar y emitir el reporte regulatorio XX,
según los requerimientos establecidos en el reglamento y ley
aplicable.
• Los libros de venta y de compras serán emitidos en el formato
establecido por las autoridades tributarias de dicha materia.

Ejemplos de requerimientos de seguridad

• El sistema controlará el acceso y lo permitirá solamente a usuarios


autorizados. Los usuarios deben ingresar al sistema con un nombre
de usuario y contraseña.
• El sistema enviará una alerta al administrador del sistema cuando
ocurra alguno de los siguientes eventos: Registro de nueva cuenta,
ingreso al sistema por parte del cliente, 2 o más intentos fallidos en
el ingreso de la contraseña de usuario y cambio de contraseña de
usuario.
• Los integrantes del grupo de usuarios de analistas pueden ingresar
solicitudes pero no pueden aprobarlas o borrarlas.
• Los integrantes del grupo de usuarios de gerentes pueden ingresar
y aprobar solicitudes, pero no pueden borrarlas.
• Los integrantes del grupo de usuario de administradores no pueden
ingresar o aprobar solicitudes, pero si pueden borrarlas.
• Cualquier intercambio de datos vía internet que realice el software
se realizará por medio del protocolo encriptado https.

Ejemplos de requerimientos de interfaces externas (Hardware y


Software)

• El software podrá ser utilizado en los sistemas operativos Windows,


Linux y OSX.
• La aplicación debe poder utilizarse sin necesidad de instalar ningún
software adicional además de un navegador web.
• La aplicación debe poder utilizarse con los navegadores web
Chrome, Firefox e Internet Explorer.

REQUISITOS NO FUNCIONALES

Paola Andrea Marmolejo Hurtado |


17
Los requerimientos no funcionales representan características
generales y restricciones de la aplicación o sistema que se esté
desarrollando.
Describen una restricción sobre el sistema que limita nuestras elecciones
en la construcción de una solución al problema. Restringen los servicios
o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, el
tipo de proceso de desarrollo a utilizar, fiabilidad, tiempo de respuesta,
capacidad de almacenamiento, seguridad, dependibilidad y usabilidad del
sistema. También presentamos ejemplos de requerimientos no
funcionales organizacionales y externos.
Los requerimientos no funcionales, en tTodos los Servicios de Tecnología
de Información (TI) en algún punto de su ciclo de vida, necesitan
considerar los requerimientos no funcionales y las pruebas asociadas a
los mismos.

Para algunos proyectos, estos requerimientos implican una cantidad


considerable de trabajo y esfuerzos, mientras que para otros no.

Con frecuencia, los requerimientos no funcionales son ignorados o


subestimados en la fase de análisis de requerimientos. El error, termina
identificándose en la fase de implementación cuando remediarlos implica
más trabajo y costo, pudiendo ocasionar que no sean adoptados por los
usuarios y clientes.
Por lo general, el Plan para implementarlos requerimientos no funcionales
se detalla en la Arquitectura del Sistema, mientras que el de los
requerimientos funcionales se especifica en el Diseño.

Una clasificacion amplia de este tipo de requisitos, permite identificar tres


categorias:
• Requisitos de Productos
• Requisitos de la organización
• Requisitos Externos.

Paola Andrea Marmolejo Hurtado |


18
Algunos ejemplos de requerimientos no funcionales son:

• Comprobabilidad: Grado en que un sistema, software o servicio


de TI permite y facilita que sea probado en un determinado
contexto.

• Disponibilidad: Corresponde al tiempo total en que un sistema


puede ser usado en un período determinado. También puede
definirse el grado en que un sistema está en un estado operable
definido cada vez que se necesite.

• Extensibilidad: Grado en que la implementación del sistema toma


en consideración y facilita su crecimiento en el futuro.

• Escalabilidad: Capacidad de un sistema o servicio de TI de


manejar una creciente carga de trabajo, por ejemplo mayor número
de conexiones o usuarios. No debe confundirse con extensibilidad,
que mide la capacidad del sistema de crecer en funcionalidades.

Paola Andrea Marmolejo Hurtado |


19
• Mantenibilidad: Mide la facilidad con que puede darse
mantenimiento al producto (en este caso al software o servicio de
TI), con la finalidad de: Desarrollar nuevos requerimientos, Aislar
los defectos y sus causas, corregir estos defectos y atender las
demandas del entorno cambiante.

• Seguridad: Grado de protección de los datos, software y


plataforma de tecnología de posibles pérdidas, actividades no
permitidas o uso para propósitos no establecidos previamente.

• Usabilidad: Definido como la facilidad de uso y aprendizaje de un


Sistema, Software o Servicio de Tecnología de Información.

Ejemplos de requerimientos no funcionales de producto

Eficiencia

• El sistema debe ser capaz de procesar N transacciones por segundo.


Esto se medirá por medio de la herramienta SoapUI aplicada al
Software Testing de servicios web.
• Toda funcionalidad del sistema y transacción de negocio debe
responder al usuario en menos de 5 segundos.
• El sistema debe ser capaz de operar adecuadamente con hasta
100.000 usuarios con sesiones concurrentes.
• Los datos modificados en la base de datos deben ser actualizados para
todos los usuarios que acceden en menos de 2 segundos.

Seguridad lógica y de datos

• Los permisos de acceso al sistema podrán ser cambiados solamente


por el administrador de acceso a datos.
• El nuevo sistema debe desarrollarse aplicando patrones y
recomendaciones de programación que incrementen la
seguridad de datos.
• Todos los sistemas deben respaldarse cada 24 horas. Los respaldos
deben ser almacenados en una localidad segura ubicada en un edificio
distinto al que reside el sistema.
• Todas las comunicaciones externas entre servidores de datos,
aplicación y cliente del sistema deben estar encriptadas utilizando el
algoritmo RSA.
• Si se identifican ataques de seguridad o brecha del sistema, el mismo
no continuará operando hasta ser desbloqueado por un administrador
de seguridad.

Paola Andrea Marmolejo Hurtado |


20
Seguridad industrial

• El sistema no continuará operando si la temperatura externa es menor


a 4 grados Celsius.
• El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).

Usabilidad

• El tiempo de aprendizaje del sistema por un usuario deberá ser menor


a 4 horas.
• La tasa de errores cometidos por el usuario deberá ser menor del 1%
de las transacciones totales ejecutadas en el sistema.
• El sistema debe proporcionar mensajes de error que sean informativos
y orientados a usuario final.
• El sistema debe contar con un módulo de ayuda en línea.
• El sistema debe poseer interfaces gráficas bien formadas.

Dependibilidad

• El sistema debe tener una disponibilidad del 99,99% de las veces en


que un usuario intente accederlo.
• El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5
minutos.
• El promedio de duración de fallas no podrá ser mayor a 15 minutos.

Otros ejemplos de requerimientos de producto

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


• La aplicación debe ser compatible con todas las versiones de Windows,
desde Windows XX.
• 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.

Ejemplos de requerimientos no funcionales organizacionales

• El procedimiento de desarrollo de software a usar debe estar definido


explícitamente (en manuales de procedimientos) y debe cumplir con
los estándares ISO 9000.
• La metodología de desarrollo de software será XXXXX.
• El sistema debe ser desarrollado utilizando las herramientas CASE XYZ.
• El proceso de desarrollo se gestionará por medio de una
determinada herramienta web para gestionar el proceso de
desarrollo de software.

Paola Andrea Marmolejo Hurtado |


21
• Cada dos semanas deberán producirse reportes gerenciales en los
cuales se muestre el esfuerzo invertido en cada uno de los
componentes del nuevo sistema.
• Las pruebas de software se gestionaran con una herramienta de
gestión de software testing.

Ejemplos de requerimientos no funcionales externos


• Sistemas de datos médicos: El nuevo sistema y sus procedimientos de
mantenimiento de datos deben cumplir con las leyes y reglamentos de
protección de datos médicos.
• El nuevo sistema se acogerá a las reglas de las licencias generales
públicas (GNU), es decir será gratuito, código abierto en el que
cualquiera podrá cambiar el software, sin patentes y sin garantías.
• Las páginas web a ser desarrolladas deben cumplir con la ley de
tratamiento en condiciones de igualdad para personas con
discapacidad.
• El sistema no revelara a sus operadores otros datos personales de los
clientes distintos a nombres y números de referencia.

Requerimientos no funcionales y requerimientos funcionales

Los requerimientos no funcionales suelen expresarse de una manera


general y sin hacer referencia a algún modulo, transacción o característica
del sistema, pues sino pasarían a ser requerimientos funcionales. Por
ejemplo:

El sistema debe asegurar que los datos estén protegidos del acceso
no autorizado.

Es recomendable acompañar las definiciones de requerimientos no


funcionales con criterios de aceptación que puedan medirse.

Los requerimientos no funcionales pueden a su vez derivar en


requerimientos funcionales, tomando como ejemplo el anterior:

El sistema incluirá un procedimiento de autorización de usuarios, en


el cual los usuarios deben identificarse usando un nombre de
usuario y contraseña. Sólo los usuarios autorizados de esta forma
podrán acceder a los datos del sistema.

Escrito de esta forma, el requerimiento pasa a ser funcional.

Paola Andrea Marmolejo Hurtado |


22
Sin embargo, no todos los requerimientos no funcionales pueden
derivarse en requerimientos funcionales, por lo cual es muy importante
definir los criterios de aceptación.

REDACCIÓN DE REQUERIMIENTOS
✓ Vital para entendimiento
✓ Buena redacción, facilita interpretación
✓ Redacción estándar, facilita comprensión
✓ La redacción cumple un papel principal en la etapa de validación de
requerimientos
✓ La consistencia en redacción agiliza todos los procesos con
los requerimientos (Todos los requerimientos tienen el mismo
estilo de redacción)
✓ Escribir requerimientos no es facil.
✓ Sabemos que la experiencia nos ayudará a que estos sean mejores
✓ Tengamos en cuenta siempre:
✓ Mantenga sentencias y parrafos CORTOS
✓ Escriba sentencias completas, con una apropiada gramatica,
ortografía y puntuación
✓ Asegurse de que el proyecto tenga definido un glosario.
✓ Utilice siempre términos consistentes y definidos en el glosario.
✓ No olvidar utilizar sentencia “El sistema debe”, “deberá”, seguidas
de una acción y finalmente un resultado
✓ Para reducir ambiguedades evite terminos subjetivos como:
✓ Amigable, facil, simple, rapido, eficiente, soporte, fuerte, superior,
aceptable, robusto.
✓ Dado que los requerimientos pueden ser identificados en diferentes
niveles de abstracción, realice ejercicios de descomponer estos en
varios requerimientos.

Paola Andrea Marmolejo Hurtado |


23
Paola Andrea Marmolejo Hurtado |
24
✓ Parrafos NARRATIVOS:
Debe tener en cuenta que una narración, puede tener muchos
requerimientos escondidos.
Cada condición, actividad, acción que usted encuentra en un párrafo,
debe ser evaluada para especificarla como un requerimiento por
separado.

Paola Andrea Marmolejo Hurtado |


25
Si encuentra “y” o “o”, “etc”, esto puede representar varios
requerimientos separados.
EJEMPLO Parrafos NARRATIVOS:
Requerimos que en el momento de realizar una factura de crédito que el
sistema automáticamente despliegue la pantalla de recaudo, donde el
vendedor deberá digitar el valor del recaudo para esa factura. Ese valor
de recaudo deberá ser igual al valor de la factura que acabó de crear, y
además las opciones de pago que deberán aparecer deben ser solo las
de cheque postfechado o credito firmado. De igual forma el sistema valida
si el vendedor tiene autorización para recibirle cheque a ese cliente y si
no la tiene deberá esconder la opción de cheque postfechado. Cuando
acabe de grabar ese recaudo, ese valor no deberá afectar la cartera, y si
se recibió cheque, esta información de cheque deberá ser guardada para
que sea impresa en la factura que se va a grabar.

Requerimientos identificados en el ejemplo:


REQ 1: El sistema deberá abrir el módulo de recaudo cuando el usuario
indique que terminó de digitar la factura de crédito.
REQ 2: Cuando se cargue el módulo de recaudo después de haber
grabado una factura de crédito el sistema deberá validar que el valor
recaudado es igual al valor de la factura.
REQ 3: Cuando se cargue el módulo de recaudo después de haber
grabado una factura de crédito el sistema deberá mostrar unicamente las
opciones de CHEQUE POSTFECHADO o CREDITO FIRMADO
REQ 4: Cuando se cargue el módulo de recaudo después de haber
grabado una factura de crédito el sistema deberá mostrar unicamente las
opciones de CHEQUE POSTFECHADO o CREDITO FIRMADO

Características de especificaciones de requerimientos

Recuerde que no es suficiente tener excelentes declaraciones de los


requisitos individuales; sino que también deben cumplir condiciones
dentro del conjunto de requerimientos, las mismas que se detallan a
continuación:

Paola Andrea Marmolejo Hurtado |


26
• Completo: Ningún requerimiento o información necesaria deberían
estar ausentes, sin embargo los requisitos que faltan son difíciles
de detectar porque no están descritos.
• Consistente: Los requisitos de conformidad no entren en
conflicto con otros requisitos del mismo tipo o con un mayor nivel de
negocios, sistema o necesidades de los usuarios (Wiegers, 2003).
• Modificable: Debe ser capaz de revisar en el SRS cuando sea
necesario y para mantener un historial de los cambios realizados de
acuerdo a cada necesidad surgida;
cada requisito debe aparecer solo una vez en el SRS.
• Trazable: El requisito de trazabilidad puede estar vinculado a
su origen hacia atrás y hacia adelante a los elementos de
diseño y código fuente que aplicarla a uno de los casos de
prueba que verifique la aplicación como correcta.

Los requisitos trazables están escritos en una forma estructurada, de


granularidad fina en lugar de párrafos largos. Se debe evitar
agrupar múltiples requerimientos en una sola instrucción, los diferentes
requisitos pueden rastrear hasta el diseño y elementos de código.

(Gottesdiener E. , 2005), recomienda las siguientes prácticas clave que


promueven desarrollar requisitos de calidad:

Desarrollar una visión clara para el producto final.

• Desarrollar una comprensión bien definida, del alcance del proyecto.


• Involucrar a los stakeholders durante el proceso de requisitos.
• Representar y descubrir los requisitos usando múltiples modelos.
• Documentar los requisitos con claridad y coherencia.
• Validar continuamente que los requisitos sean correctos con el enfoque
del proyecto.
• Verificar la calidad de los requisitos frecuentemente.
• Priorizar los requerimientos y eliminar los innecesarios.
• Establecer una línea base para los requerimientos, ya que pueden
servir para futuros proyectos.
• Rastrear los orígenes de los requisitos y la forma de vinculación con
otros requisitos y con los elementos del sistema. • Anticipar y
gestionar todos los cambios de los requisitos.

4. Validación de requisitos

Paola Andrea Marmolejo Hurtado |


27
Los requisitos deben ser validados para asegurarse que el equipo de
desarrollo de software haya entendido los requisitos; además se verifica
que los documentos de los requisitos contempla estándares, es
comprensible, constante y finito. Con esta premisa se puede concluir que
la validación de los requisitos es el proceso de examinar el documento de
los requisitos para asegurarnos que este define el software
correctamente.

5. Gestión de requisitos

La gestión de requisitos es un conjunto de actividades que ayudan al


equipo de desarrollo a identificar, controlar y seguir los requisitos y los
cambios en cualquier momento. La gestión o administración de requisitos
se definió para sistemas grandes y cambiantes, debido a que durante el
proceso del software, la comprensión del problema por el desarrollador
está cambiando constantemente y estos cambios retroalimentan a los
requerimientos. (Sommerville, 2005).

A continuación se detallan las actividades de esta fase:

• Establecer una línea base: Se establece una línea de base mediante la


documentación del estado actual de las necesidades a un punto en el
tiempo, para usar como punto de partida. La línea de base muestra
una serie de requisitos con los atributos de estado acordados en un
punto determinado en el tiempo y captura atributos importantes
acerca de los requisitos. El desarrollo de una línea de base crea una
referencia a utilizar para realizar un seguimiento de las necesidades
evolucionan con el tiempo.

• Control de cambios: Se deben establecer mecanismos y políticas para


reconocer, evaluar y decidir como integrar las nuevas necesidades e
ir evolucionando hacia una línea de base de las necesidades
existentes.

• Seguimiento de requisitos: Mediante la identificación y


documentación de cómo los requisitos están relacionados de forma
lógica y de los tipos de estos requisitos. La Trazabilidad de los
requisitos le permite identificar la forma en el que los requisitos se
relacionan con las metas y objetivos de negocio; y cuáles son los
entregables del desarrollo futuro. Para terminar esta sección sobre el
proceso de ingeniería de software le invito a que

Paola Andrea Marmolejo Hurtado |


28
Matriz de trazabilidad de requerimientos

Todo proyecto comienza con el establecimiento de una base para el


alcance del producto y de proyecto, pero antes de poder definir el alcance
debemos reunir a los interesados y registrar cada requerimiento
específico. La matriz de trazabilidad de requerimiento es el lugar donde
documentamos esas necesidades.

Una vez comenzado el proyecto, la matriz de trazabilidad facilita gestión


de los requerimientos a lo largo del ciclo de vida, los proyectos
complejos puede llegar a tener cientos de requerimientos específicos y la
matriz de trazabilidad nos ayuda con el seguimiento al alcance, evaluación
del impacto de cambios y nos mantiene enfocados en los beneficios que
esperamos obtener.

Trazabilidad de requerimientos

La guía del Business Analysis Body of Knowledge (BABOK) en su


versión 3, nos aporta esta definición:

La trazabilidad e requerimientos es la capacidad de registrar las relaciones


existentes entre la necesidad dada por un interesado (stakeholder), el
requerimiento de proyecto y la solución implementada finalmente.

Cuando realizamos la gestión de cambios de alcance del proyecto, la


trazabilidad nos ayuda a identificar la necesidad original de
requerimientos específicos que se estén cambiando, los interesados que
debemos involucrar en el cambio de alcance y cuales entregables del
proyecto serán afectados.

29
Paola Andrea Marmolejo Hurtado |
La trazabilidad de requerimientos es la base para el control del alcance,
riesgo, cronograma, costo y comunicaciones a lo largo del proyecto.

Que es la matriz de trazabilidad de requerimientos?

La guía del PMBOK le da esta definición:

La matriz de trazabilidad de requerimientos es un cuadro que cumple con


la función de relacionar cada requisito del proyecto con el entregable que
lo satisface.

La trazabilidad de requerimientos de proyecto es bidireccional, esto es,


partiendo de un determinado requisito del proyecto se puede referir al
entregable que lo satisface, de la misma forma, si tenemos un entregable
de proyecto podemos establecer cuales requisitos han sido abarcados por
este.

Adicionalmente, la matriz de trazabilidad de requerimientos también


relaciona cada requisito con los objetivos de proyecto y objetivos
estratégicos organizacionales que satisface, garantizando de esta forma
que cada requisito esté agregando valor al presente y futuro del negocio.

Con la matriz de trazabilidad podemos:

• Tener una mejor y más rápida visualización sobre la complejidad de


los cambios propuestos durante el ciclo de vida (cambios de
alcance).

• Analizar el impacto de cambios de alcance propuestos de manera


más sencilla y rápida.

• Identificar inconsistencias y brechas en los requerimientos respecto


a beneficios que se espera obtener del proyecto.

• Tener una mejor y más rápida visualización de cuales


requerimientos han sido abordados y cuáles no.

Como llenar una matriz de trazabilidad

30
Paola Andrea Marmolejo Hurtado |
La matriz de trazabilidad registra los atributos relacionados con cada
requerimiento de proyecto, entre los atributos típicos que se pueden
asociar a cada requerimiento se encuentran:

• Un identificador único: La organización define un estándar para


numerar cada requisito de proyecto e identificarlo unívoca-mente.
Puede definirse una numeración (por ejemplo 001, 002, 003).

• Vinculación de requisitos de alto nivel con requisitos más


detallados (Sub Identificación): Pueden definirse numeraciones
separadas por punto para asociar requerimientos específicos con un
requerimiento general (por ejemplo 1.1, 1.2 y 1.3 para requisitos
asociados al requerimiento 001).

• Descripción textual del requisito: Narrativa que describe en que


consiste el requerimiento de proyecto. Al escribir esta descripción
debe tenerse en cuenta el tipo de requerimiento de proyecto que se
esté documentando. La guía del PMBOK establece los siguientes
tipos de requisitos:

o Requerimientos del negocio.

o Requerimientos de los interesados.

o Requerimientos de la solución: Estos a su vez se clasifican en:


▪ Requisitos funcionales.
▪ Requisitos no funcionales.

o Requerimientos del proyecto.

o Requerimientos de calidad.

• Versión: Los requerimientos se pueden ir modificando o agregando


información en versiones sucesivas, por lo que es conveniente llevar
el control por número de versión.

• Estado actual: La guía del PMBOK establece los siguientes


estados en los que puede encontrarse un requerimiento:

o Activo
o Cancelado
o Diferido

31
Paola Andrea Marmolejo Hurtado |
o Agregado
o Aprobado
o Asignado
o Completado

• Propietario: Persona responsable de velar por que se logren los


resultados con el requerimiento.

• Prioridad: Se toma en cuenta el grado de importancia del


requerimiento para el logro de objetivos del proyecto y realización
de sus beneficios, para asignar un nivel de prioridad. También
puede tenerse en cuenta el grado de influencia del interesado
solicitante (stakeholder) según determine la gestión de los
interesados del proyecto.

• Criterios de estabilidad, complejidad y aceptación: La


complejidad puede establecerse de forma cualitativa, por ejemplo
baja, moderada o alta. Los criterios de aceptación son una lista de
condiciones específicas que debe cumplir el requerimiento para
poder pasar a estado “completado”. Es importante que los criterios
sean específicos, medibles de forma objetiva y respondan a un
estándar organizacional.

• Necesidades, oportunidades, metas y objetivos de negocio:


Son los elementos de planificación estratégica que dieron origen al
requerimiento. Todo requerimiento debe estar alineado con
beneficios específicos que la organización espera obtener. Estos
beneficios responden a nuevas oportunidades, objetivos y metas de
crecimiento, o necesidades emergentes específicas (por ejemplo
aspectos regulatorios o necesidades obligatorias para responder a
amenazas de competidores).

• Objetivos del proyecto: Establece la trazabilidad entre el requisito


y los objetivos específicos del proyecto definidos en su alcance. Los
objetivos de proyecto a su vez deben estar asociados a necesidades,
oportunidades, metas u objetivos de negocio.

• Alcance del proyecto y entregables de la estructura de


desglose de trabajo (EDT): Entregables de la estructura de
desglose de trabajo (EDT) en los cuales está inmerso el requisito.
Puede especificarse tanto el nombre del elemento de la EDT como
su código EDT.

32
Paola Andrea Marmolejo Hurtado |
• Diseño del producto: Si el requerimiento tiene implicaciones de
cómo debe diseñarse el producto, aquí se explican cómo se
incorporarán los compontes necesarios al diseño para satisfacerlo.

• Desarrollo de productos: Describe como los procedimientos de


trabajo, metodología o estándares usados incorporan el requisito.
Esto aplica para requisitos que definen la forma de trabajar y
estándares a cumplir, como por ejemplo requerimientos de
proyecto o de calidad.

• Estrategia escenarios de prueba: Partiendo de los criterios de


aceptación que debe cumplir el requerimiento, se establecen
estrategias y escenarios de prueba específicos, según el sector
industrial o área técnica en la que se desenvuelve el proyecto. Esta
información servirá de insumo para planificar el control de calidad
del proyecto.

Importancia de la matriz de trazabilidad

La información registrada por la matriz de trazabilidad de requerimientos,


es valiosa para el Director de proyecto y para los interesados
(stakeholders), proporcionando un medio para rastrear los requisitos a lo
largo del ciclo de vida del proyecto y garantizar que los requisitos
aprobados se entreguen.

Para ilustrar la importancia de la matriz de trazabilidad de requerimientos,


a continuación haremos un recorrido por todo el ciclo de vida de proyectos
y especificaremos en cada paso como la matriz de trazabilidad nos ayuda
a tener una gestión más efectiva.

1.- Recopilar los requerimientos

La matriz de trazabilidad de requerimientos nos ayuda a registrar los


requisitos identificados, quien fue la persona (interesado / stakeholders)
que nos dio la información, como contribuye al logro de los objetivos del
proyecto, y mucha más información de suma importancia para el
proyecto.

La recopilación de requerimientos puede ocurrir en una fase inicial de

33
Paola Andrea Marmolejo Hurtado |
planificación del proyecto o en ciertos momentos durante la ejecución de
iteraciones.

Durante la recopilación, aplicamos técnicas de levantamiento de


requerimientos como por ejemplo las entrevistas con los interesados,
encuestas, mesas de trabajo, sesiones de tormentas de ideas, entre otras.

Una vez recopilada la información, podemos aplicar técnicas de análisis


de requerimiento, como por ejemplo la descomposición funcional,
modelado de procesos, inspecciones, entre otras. Estas técnicas nos
ayudan a una mejor definición del alcance e identificación de brechas
(requisitos faltantes).

2.- Definir el alcance

La matriz de trazabilidad de requerimientos es el principal insumos en la


definición del alcance de proyecto. Es de allí donde obtendremos la
información necesaria para establecer una narrativa unificada del alcance
y luego desglosar el trabajo (descomposición funcional) en los paquetes
de trabajo de la Estructura de desglose de trabajo (EDT).

Durante la elaboración del alcance y descomposición funcional, podemos


identificar nueva información que nos lleve a pedir más información o
inclusive a definir nuevos requisitos que nadie había contemplado. La
matriz de trazabilidad recibe todos estos registros y es donde se controla.

3.- Planificar la gestión de calidad del proyecto

Para planificar los procedimientos de control de calidad sobre los


entregables del proyecto, se necesita definir las pruebas requeridas para
validarlos.

La matriz de trazabilidad de requerimientos vincula los requisitos del


producto con los entregables y las pruebas requeridas para validarlos, por
lo tanto es de ella de donde obtendremos la información necesaria.

Un proyecto puede tener requerimientos de calidad, independientemente


de los requerimientos del negocio. Estos también se incluyen en la matriz
de trazabilidad.

Durante la planificación de calidad, deben crearse documentos de pruebas

34
Paola Andrea Marmolejo Hurtado |
y evaluaciones, basándose en las necesidades del sector industrial y de
las plantillas con que cuente la organización. Entre los documentos de
pruebas y evaluación puede incluirse matrices de trazabilidad detalladas.

4. Planificar la gestión de adquisiciones del proyecto

La matriz de trazabilidad de requisitos vincula los requerimientos del


producto desde su origen con los entregables. Podemos usarla para tomar
decisiones sobre que entregables del proyecto se pueden externalizar,
conociendo en cada caso cuales requerimientos pasarían a depender de
proveedores.

5. Dirigir y gestionar el proyecto

Una vez comenzado el proyecto, la matriz de trazabilidad de


requerimiento ayuda al equipo y a la organización a enfocarse en
actividades que contribuirán a lograr los objetivos. Esta sirve de
referencia en todo momento sobre como los entregables que se están
desarrollando están relacionados con los requerimientos de producto y
estos a su vez con los beneficios que se esperan obtener del proyecto.

6. Validar el alcance

La matriz de trazabilidad contiene información sobre cómo deben


validarse los requerimientos del proyecto cuando sean entregados, por lo
cual es uno de los principales insumos para los procedimientos de
validación del alcance establecidos en los estándares del Project
Management Institute (PMI).

7. Controlar el alcance

La matriz de trazabilidad establece la relación entre requerimientos y


objetivos del proyecto, por lo tanto esta nos puede ayudar a evaluar qué
impacto tienen los cambios en los requerimientos sobre la línea base de
alcance y en última instancia de los objetivos. Adicionalmente la matriz
de trazabilidad de requerimientos también registra el estatus de los
requerimientos, siendo por tanto una herramienta de control del alcance.

8. Gestión de cambios integrada (cambios de alcance)

La matriz de trazabilidad de requerimientos ayuda a evaluar el impacto


de los cambios de alcance, para determinar el posible desplazamiento de

35
Paola Andrea Marmolejo Hurtado |
tiempo, costos y expectativas, siendo clave para la toma de decisión sobre
su aprobación o no.

9. Efectuar las adquisiciones

En la medida en que los proveedores son incorporados al proyecto,


podemos recibir nueva información o más detalles dada su
especialización, esto puede ocasionar que revisemos y modifiquemos los
requerimientos, por lo tanto la matriz de trazabilidad de modifica para
acomodar estos cambios, ajustándose los requerimientos a las
capacidades de cada proveedor específico.

10. Controlar las adquisiciones

Se puede utilizar la matriz de trazabilidad para determinar el estatus de


cada requerimiento, a partir del estatus de los entregables que nos
reporte el proveedor. Adicionalmente, una vez los entregables sean
satisfechos, a satisfacción de ambas partes (organización y proveedor)
según el contrato, la matriz de trazabilidad se modifica en consecuencia.
Esto brinda mayor control sobre el avance del proyecto, estado del
alcance y logro de objetivos.

36
Paola Andrea Marmolejo Hurtado |
BIBLIOGRAFÍA

Sommerville, I. (2011). Ingeniería de Software. In I. Sommerville (Ed.), 4.


Ingeniería de Requerimientos (9ª ed., pp. 83-115). Naulcalpan de Juárez,
Mexico: Pearson.

Project Management Institute. (2014). Capitulo 13 – Gestión de los interesados


del proyecto. Guía de Los Fundamentos para la Dirección de Proyectos (guía Del
PMBOK) (5ª ed., pp 391 - 415). Newtown Square, Pensilvania, EE.UU.: Project
Management Institute.

http://www.ofnisystems.com/services/validation/functional-
requirements/

https://reqtest.com/requirements-blog/understanding-the-
difference-between-functional-and-non-functional-requirements/

https://reqtest.com/requirements-blog/functional-vs-non-functional-
requirements/

Paola Andrea Marmolejo Hurtado |


37