Plantilla de matriz de trazabilidad de requisitos

Código de proyecto: [Código asociado al proyecto en la organización]

Proyecto: [Nombre del Proyecto]

Identificación Sub identificación

Descripción del requisito
El sistema permitirá la realizar una carga masiva
de los pacientes atendidos en los centros de
salud.
1 1.1
El sistema permitirá descargar un reporte de los
pacientes afectados, con la posibilidad de poder
filtrar por varios parámetros dependiendo de lo
que requiera (ciudad, fecha, país).

1.2
El sistema deberá contar con un algoritmo que
determine las características más relevantes en
cada uno de los casos presentados con el fin de
validar cuales son los más significativos.

1.3
 El sistema deberá notificar al administrador
cuando se hayan agregado datos en la base de
datos.
1.4
El administrador delegado de la herramienta por
cada entidad de salud, será el único que podrá
cargar la información.

1.5
A cada paciente se le asignará una identificación
única para su reconocimiento dentro del sistema.

1.6
Se manejará una plantilla con los datos necesarios
y que estén relacionados directamente con la
infección del paciente y no con sus datos
personales.
1.7
Los datos serán enviados a la base de datos por
medio de una ETL encargada de la conversión de
los datos ingresados.
1.8
 La base de datos será implementada con trazas
de auditoría.

1.9
La base de datos deberá ser refrescada cada dos
horas con la información que sea ingresada
dentro de ese lapso de tiempo.

1.10
Los permisos de acceso al sistema podrán ser
cambiados solamente por el administrador de acceso a
datos.

2 2.1
 El sistema debe desarrollarse aplicando patrones y
recomendaciones de programación que incrementen la
seguridad de datos.

2.2
Todos los sistemas deben respaldarse cada 24 horas.

2.3
Los administradores delegados por cada grupo de las
entidades de salud pueden ingresar información, pero
no pueden editarla ni borrarlas.

2.4
 Los integrantes del grupo de usuarios de científicos y
prensa pueden ingresar y consultar la información, pero
no pueden cargar, editarla ni borrarla.

2.5
Los integrantes del grupo de usuario de administradores
del sistema pueden ingresar y modificar la aplicación,
pero no podrá editar ni borrar la información de la base
de datos.

2.6
 Las modificaciones dentro de la base de datos serán
realizadas por el DBA encargado.

2.7
Cualquier intercambio de datos vía internet que realice
el software se realizará por medio del protocolo
encriptado https.

2.8
Se asignarán usuarios y contraseñas a cada uno de las
personas encargadas

2.9
 El sistema deberá notificar cuando un usuario ingrese 2
o más veces mal su contraseña y también cuando
realice un cambio de contraseña.

2.10
El área donde se ubiquen los componentes de
informática deben contar debe contar con autenticación
de usuario (prevenir el acceso a usuarios no autorizado)

3 3.1
Aquellos equipos al servicio de trabajo deben de contar
con protección discrecional (El acceso a distinta
información se realiza mediante identificación de
usuarios)
3.2
Aquellas tomas de red que no se estén utilizando el área
3.3 de tecnología deben estar bloqueadas
Todo cableado del área debe ir organizado, marcado y
3.4 en canaletas (prevenir fractura de estos)
3.5 Estricto control de acceso a instalaciones
El área central debe contar con cámaras de vigilancia de
3.6 circuito cerrado o alarmas
 El área central debe contar con un Sistema de
3.7 alimentación ininterrumpida
El espacio donde se encuentren ubicados los servidores
debe encontrarse ventilado y con acceso restringido
3.8
A cada objeto del sistema (usuario, dato, etc) se le
asigna una etiqueta con nivel de seguridad jerárquico
(alto secreto, secreto, reservado, etc). Cada usuario que
accede a un objeto debe poseer un permiso expreso
para hacerlo y viceversa.
3.9
Dominios de seguridad de acceso no autorizado a la
modificación de objetos de diferentes dominios de
seguridad
3.10
•El sistema debe ser capaz de operar
adecuadamente con hasta 50.000 usuarios para
su primera versión.
4 4.1
•La aplicación deberá consumir menos de 1 GB de
4.2 memoria RAM.
•La aplicación no podrá ocupar más de 1 GB de
4.3 espacio en disco.
 •Las consultas realizadas a la base de datos
tendrán un tiempo de respuesta máximo a 10 seg.
4.4
•Tanto en la aplicación como la base de datos
estará aprovisionado los servicios en un cluster
para garantizar alta disponibilidad y rápida
respuesta.
4.5
4.6 •El sistema debe ser capaz de procesar 117.000
•Toda funcionalidad del sistema y transacción de
negocio debe responder al usuario en menos de 5
seg.
4.7
•Los datos modificados en la base de datos deben
ser actualizados para todos los usuarios que
acceden en menos de 3 seg.
4.8
•El sistema deberá ser compatible con versiones
4.9 de IOS y Android.
•El sistema deberá contar con un balanceador de
cargas para brindar óptima respuesta sobre las
solicitudes de los usuarios.
4.10
•El tiempo de aprendizaje del sistema por usuario
5 5.1 será menor de 4 hrs
5.2 •El sistema debe contar con manuales de usuario
5.3 •El sistema debe proporcionar mensajes de error
5.4 •El sistema debe contar con un modulo de ayuda
•El sistema debe poseer interfaces graficas bien
formadas

5.5
•El sistema tendrá un campo de observaciones
para que los usuarios agreguen un comentario
sobre la plataforma
5.7
•El sistema será intuitivo en cada modulo

5.6
•La plataforma no puede ser accedida
directamente, sino a través de una interfaz
diseñada para estos propósitos
5.8
•El sistema tendrá un modulo de ayuda para el
5.9 usuario final
 • El sistema tendrá disponibilidad herramientas
de entrenamiento de los usuarios para el uso
apropiado del sistema
5.10
•El sistema debe tener una disponibilidad del
99.9% de las veces que el usuario intente acceder.
6 6.1
•El tiempo de inicio no podrá ser mayor a los 10
6.2 min.
•El promedio de duración de fallas no podrá ser
6.3 mayor a 15 min.
•El sistema tendrá un ambiente de contingencia.

6.4
•El sistema tendrá sus servidores alojados en
diferentes regiones en caso de un DRP.

6.5
 •El sistema tendrá la capacidad en su
infraestructura de realizar modificaciones o
reparaciones sin afectar el servicio.
6.6
 Versión Estado actual Última fecha estado registrado Criterios de aceptación

1.0 Solicitado 12/4/2020 La carga realizada debe ser

rápida y fácil para el usuario.

1.0 Solicitado 12/4/2020 El reporte debe ser fácil de

descargar para el usuario.
Los filtros deben ser amigables
y no tan complejos para los
usuarios.

1.0 Solicitado 12/4/2020 La respuesta del algoritmo

debe ser rápida con una
respuesta de las características
mas reelevantes en los
pacientes afectados.
1.0 Solicitado 12/4/2020 La notificación no debe tardar
mas de 15 segundos en llegar.

1.0 Solicitado 12/4/2020 Solo el adminsitrador

encargado por cada entidad de
salud debera ser el que pueda
cargar la información en el
sistema.

1.0 Solicitado 12/4/2020 Cuando se genere el reporte

deberá estar ese campo
dispinible para quienes lo
descargan.

1.0 Solicitado 12/4/2020 La plantilla debe ser facil y

rápida de llenar para los
usuarios.

1.0 Solicitado 12/4/2020 La ETL no debe tardar mas de

10 segundos en cargar la base
de dados.
1.0 Solicitado 12/4/2020 La base de datos debe contar
con todos los requerimientos
de auditoria necesarios y que
no representen un riesgo
cuando la aplicación sea
auditada.

1.0 Solicitado 12/4/2020 El tiempo de actualización se

debe cumplir, reflejando que
los datos sean ingresados
correctamente. Cuando los
datos presenten algún error,
este deberá ser notificado a las
personas encargadas.

1.0 Solicitado 12/4/2020 Solo el adinistrador de la

seguridad del aplicativo debe
ser la única persona que pueda
cambiar los grupos de acceso a
la aplicación.
1.0 Solicitado 12/4/2020 Cuando se realicen los
escaneos de seguridad, estos
deben resultar con el mínimo
de comentarios posibles, de 2 a
3 errores nivel medium o low.

1.0 Solicitado 12/4/2020 Los respaldos del aplicativo

deben ser periodicos, cada 24
horas y se berá verificar que
efectivamente se realice con
todos los datos necesarios.

1.0 Solicitado 12/4/2020 Despues de verificar el

funcionamiento del protal, se
debe validar que los
administradores por cada
entidad de salud solo puedan
ingresar información.
1.0 Solicitado 12/4/2020 Despues de verificar el
funcionamiento del protal, se
debe validar que los
profesionales que pertenecen
al grupo de científicos y prensa
puedan consultar información
pero no puedan cargar, editar
ni borrar la información.

1.0 Solicitado 12/4/2020 Despues de verificar el

funcionamiento del protal, se
debe validar que los
adminsitradores del sistema
pueden editar el aplicativo
pero no podrán modificar los
datos que estan dentor de la
base de datos.
1.0 Solicitado 12/4/2020 Despues de verificar el
funcionamiento del protal, se
debe validar que solo el DBA
encargado pueda modificar los
datos que s eencuentran
dentro de la base de datos.

1.0 Solicitado 12/4/2020 Cuando se realicen

intercambios via internet, se
bebe validar que realmente se
esté haciendo mediante el
protocolo HTTPS.

1.0 Solicitado 12/4/2020 Se debe validar que cuando

ingresen los profesionales al
aplicativo, tengan que digitar
su usuario y contraseña
asignado.
1.0 Solicitado 12/4/2020 Cuando los profesionales
ingresen mal su contraseña
mas de 2 veces el
administrador debe recibir una
notificación en su correo
electrónico.

1.0 Solicitado 12/4/2020 Comprobar derechos de

usuario y validacion de
recursos. La aplicacion
comprueba los derechos de
usuario y conecta sus
transacciones y datos
1.0 Solicitado 12/4/2020

Al navegar sobre las distintas pa

1.0 Solicitado 12/4/2020
La aplicación debe iniciar inme
1.0 Solicitado 12/4/2020
La aplicación debe ser ligera y s
1.0 Solicitado 12/4/2020 La base de datos debe estar act
1.0 Solicitado 12/4/2020
El cluster debe estar siempre ac
1.0 Solicitado 12/4/2020
el cluster debe estar siempre ac
1.0 Solicitado 12/4/2020

Al interactuar con los diferente

1.0 Solicitado 12/4/2020

La informacion actualizada debe

1.0 Solicitado 12/4/2020

La aplicación debe estar disponib

1.0 Solicitado 12/4/2020

El balanceador de cargas debe en

1.0 Solicitado 12/4/2020
El acceso al area de tecnologia
1.0 Solicitado 12/4/2020
Los equipos disponibles en la sal
1.0 Solicitado 12/4/2020

Por seguridad, el area de tecnol

1.0 Solicitado 12/4/2020

Por seguridad en infraestructura

1.0 Solicitado 12/4/2020 No se debe permitir aplicacione
1.0 Solicitado 12/4/2020

El area de tecnologia debe encont

1.0 Solicitado 12/4/2020

Esto garantiza la disponibilidad

1.0 Solicitado 12/4/2020
Los servidores deben encontrars
1.0 Solicitado 12/4/2020

Cada usuario debe cumplir su rol

1.0 Solicitado 12/4/2020
Por seguridad no debe permitirs
1.0 Solicitado 12/4/2020 Con las areas involucradas se
1.0 Solicitado 12/4/2020 Se analizara las condiciones de
1.0 Solicitado 12/4/2020 Se creara un bot con los
1.0 Solicitado 12/4/2020 Nos enfocaremos en simplificar
las acciones de los diferentes
modulos para que sean
intuitivos. Esto sera un diseño
el cual se adaptara a las
necesidades del usuario final

1.0 Solicitado 12/4/2020 Se adaptara la plataforma a las

observaciones recurrentes por
parte de los usuarios

1.0 Solicitado 12/4/2020 Se enfocara la plataforma en

las busquedas directas con la
informacion que brinda

1.0 Solicitado 12/4/2020 Se implementara la interfaz

para los usuarios finales

1.0 Solicitado 12/4/2020 Se creara un bot con los

errores frecuentes y se
realizara pruebas con los
usuarios finales adaptando a
las necesidades
1.0 Solicitado 12/4/2020 Se desarrollara un repositorio
de documetacion frente a la
plaforma y tendra mejoras
frente a las observaciones
1.0 Solicitado 12/4/2020 Se tendralosunusuarios
realicen ambiente de
produccion y contingencia . Se
realizaran pruebas de
contingencias
1.0 Solicitado 12/4/2020 Se haran pruebas recurrentes
de desempeño sobre los
servicios y modulos
1.0 Solicitado 12/4/2020 Se haran pruebas recurrentes
de desempeño sobre los
servicios y modulos
1.0 Solicitado 12/4/2020 Se implementara la
infraestructura de contingencia
en un datacenter diferente al
de produccion y se haran
pruebas de activacion del
ambiente de contingencia

1.0 Solicitado 12/4/2020 Se haran pruebas periodicas de

DRP y se analizara si se
garantizala continuidad del
servicio frente a un desastre
1.0 Solicitado 12/4/2020 Se haran pruebas de las
diferentes areas tanto de
aplicacion, base de datos,
redes, infraestructura para
validar que el sistema tendra la
capacidad de mantener su
servicio y la integridad de los
datos si uno se ve afectado
 Necesidad, oportunidades u
Nivel de complejidad Objetivo del proyecto Entregables (EDT)
objetivos de negocio

Media

Media

Alto
Media

Media

Baja

Baja

Alta
Media

Media

Media
Media

Media

Media
Media

Media
Media

Media

Media
Media

Media

Alta

Alta

Alta
Media

Baja
Alta

Media

Media

Baja

Media

Baja

Baja
Baja

Baja
Media

Media

Alta

Media

Media

Baja
Baja
Baja
Media

Media

Baja

Media

Baja

Media
Baja

Alta

Alta

Alta

Alta

Alta
Alta
 Interesado (Stakeholder) dueño del
Diseño del producto Desarrollo del producto Estrategia y escenarios de pruebas
requisito
Nivel de prioridad
Plantilla de matriz de trazabilidad de requisitos
Descripción de la información a completar en cada columna
Columna
Identificación

Sub identificación

Descripción del requisito

Versión

Estado actual
Última fecha estado registrado
Criterios de aceptación

Nivel de complejidad

Necesidad, oportunidades u objetivos de

negocio

Objetivo del proyecto

Entregables (EDT)
Diseño del producto

Desarrollo del producto

Estrategia y escenarios de pruebas

Interesado (Stakeholder) dueño del requisito

Nivel de prioridad
trazabilidad de requisitos
pletar en cada columna
Instrucciones
Código de identificación de mayor nivel definido para el requisito. Puede definirse con números, por ejemplo 001,
002, 003, y así sucesivamente.
Sub código de identificación que puede utilizarse para definir requisitos detallados y asociarlos a un requisito padre.
De esta forma se define la trazabilidad entre requisitos de alto nivel con requisitos más detallados.

Puede definirse según el número de requisito padre, por ejemplo para el caso de 001 podría definirse el requisito 1.1
y 1.2. Pueden también definirse niveles adicionales de detalle de requisito, por ejemplo el requisito 1.1.1 y 1.1.2
estarían asociados a 1.1.

Se proporciona una descripción de que comprende o en qué consiste el requisito. La descripción del requisito
depende del tipo que sea, por ejemplo requisitos del negocio, requisitos de los interesados, requisitos funcionales,
requisitos no funcionales, requisitos del proyecto o requisitos del producto (solución).

Número de versión del requisito en su estado actual. De esta forma los requisitos se pueden ir detallando o
modificando en versiones sucesivas.
Puede ser solicitado, aprobado, asignado, completado, cancelado, diferido, aceptado, entre otros.
Fecha en la que se realizó el último cambio de estado del requisito.
Lista los criterios de aceptación, una lista de puntos o condiciones específicas que deben cumplirse para poder
registrar que el requisito ha sido satisfecho.
Puede definirse una complejidad de forma cualitativa, por ejemplo baja, moderada o alta. Esto dependerá del
criterio del evaluador.
Vínculo del requisito con la estrategia de la organización, listando necesidades específicas que tenga el área de
negocio, objetivos de la planificación estratégica que busca lograr u oportunidades de negocio o del mercado.

Vínculo del requisito con los objetivos del proyecto. Aquí se establece la trazabilidad entre el requisito y los objetivos
específicos del proyecto definidos e su alcance.
Entregables de la estructura desagregada de tarea (EDT) en los cuales está inmerso el requisito. Puede especificarse
tanto el nombre del elemento de la EDT como su código EDT.
Implicaciones que tiene el requisito desde el punto de vista del diseño del producto. Aquí se especifica como el
diseño del producto incorpora los componentes necesarios para poder satisfacer el requerimiento.

Implicaciones del requisito en el desarrollo del producto. Describe como los procedimientos de trabajo, metodología
o estándares usados incorporan el requisito. Esto aplica principalmente para requisitos que definen la forma de
trabajar, estándares a cumplir, entre otros.

Listado de las estrategias y escenarios de pruebas que se contemplarán para validar la aceptación del requisito. Estos
se definen a partir de los criterios de aceptación.
Nombre, departamento y cargo del interesado (Stakeholder) que originó la solicitud del requerimiento particular.
Debe corresponder con el que es especificado en el registro de interesados del proyecto.
Según la evaluación de la importancia del requisito para el logro de los objetivos del proyecto, se asigna un nivel de
prioridad. Este nivel también puede depender del grado de influencia del interesado y estrategias que se estén
empleando para gestionar la participación de los interesados.