Agencia de

Aprendizaje
a lo largo
de la vida

Requerimientos Funcionales y no Funcionales

¿Qué son los requeri ientos funcionales?

Los requisitos funcionales son declaraciones detalladas que describen las funciones
y características que un sistema de software debe proporcionar. Estos requisitos definen lo
que el sistema debe hacer y establecen las expectativas de su comportamiento. En el
contexto del testing de software, los requisitos funcionales son fundamentales para entender
qué funcionalidades deben ser probadas y verificar si el software las cumple correctamente.

Algunas características comunes de los requisitos funcionales incluyen:

Descripción de la función: Se debe proporcionar una explicación detallada de la función

que se espera del software.

Entradas y salidas: Se deben especificar las entradas que el sistema aceptará y las
salidas que generará como resultado de la función.

Requisitos de rendimiento: Pueden incluir especificaciones sobre el tiempo de respuesta

del sistema, la velocidad de procesamiento, la capacidad de manejo de datos, entre otros.

Condiciones de operación: Pueden detallar el entorno en el que se espera que el software

funcione, como los sistemas operativos compatibles, la configuración de hardware, etc.

Requisitos de seguridad: Si la función tiene implicaciones de seguridad, es importante

especificar cómo se abordarán estas preocupaciones.

Restricciones y limitaciones: Se pueden incluir restricciones específicas que limitan la

funcionalidad del software en ciertos escenarios.

Los requisitos funcionales son esenciales para el desarrollo y testing de software, ya

que sirven como la base para diseñar, implementar y validar las funciones del sistema.
Durante el proceso de testing, se verifica si el software cumple con estos requisitos
funcionales, asegurando que el producto final satisfaga las necesidades y expectativas del
usuario.

¿Qué son los requerimientos no funcionales?

Los requisitos no funcionales son criterios que describen aspectos del sistema que
no estan directamente relacionados con las funciones especificas que el software debe
realizar, sino más bien con cómo esas funciones deben realizarse o qué caracteristicas
generales debe tener el sistema. A diferencia de los requisitos funcionales, que se centran
en lo que el sistema debe hacer, los requisitos no funcionales se centran en cómo debe
hacerlo y en las características generales que deben estar presentes.

Algunas categorías comunes de requisitos no funcionales incluyen:

Rendimiento: Establece criterios relacionados con la eficiencia del sistema, como la

velocidad de respuesta, la capacidad de procesamiento, el rendimiento bajo carga, etc.
Agencia de
Aprendizaje
a lo largo
de la vida

Fiabilidad: Describe la confiabilidad y disponibilidad del sistema, incluidos los tiempos de

actividad, la tolerancia a fallos y la capacidad de recuperación.

Seguridad: Define los aspectos relacionados con la seguridad del sistema, como la
autenticación, la autorización, el cifrado de datos y la resistencia a ataques.

Usabilidad: Describe la facilidad con la que los usuarios pueden interactuar con el sistema,
incluida la interfaz de usuario, la accesibilidad y la experiencia del usuario.

Mantenibilidad: Se refiere a la facilidad con la que el software puede ser mantenido y

modificado, incluyendo aspectos como la legibilidad del código, la modularidad y la
capacidad de realizar actualizaciones.

Portabilidad: Indica la capacidad del software para ejecutarse en diferentes entornos,

sistemas operativos, o plataformas sin requerir modificaciones significativas.

Compatibilidad: Se refiere a la capacidad del sistema para funcionar correctamente con

otros sistemas, software o hardware específicos.

Estos requisitos no funcionales son esenciales para asegurar que el sistema cumpla
con expectativas más allá de la funcionalidad básica, garantizando aspectos críticos como
rendimiento, seguridad y usabilidad. Durante el proceso de testing, se evalúa el
cumplimiento de estos requisitos para asegurar que el sistema en su conjunto sea robusto,
confiable y cumpla con los estándares deseados.

Ejemplos de requerimientos No funcionales del producto

Eficiencia:

e El sistema deberá procesar N transacciones por segundo, medido mediante la

herramienta JMeter para pruebas de servicios web.
e Todas las funcionalidades y transacciones deberán responder al usuario en menos
de 5 segundos.
e El sistema deberá operar adecuadamente con hasta 100,000 usuarios
concurrentes.
e Las modificaciones en la base de datos deben reflejarse para todos los usuarios en
menos de 2 segundos.

Seguridad Lógica y de Datos:

e Los permisos de acceso solo podrán ser modificados por el administrador de

acceso a datos.
e El desarrollo del nuevo sistema deberá aplicar patrones y recomendaciones de
programación para incrementar la seguridad de los datos.
e Serealizarán respaldos diarios del sistema, almacenados en una localidad segura
fuera del edificio principal.
e Todas las comunicaciones externas entre servidores y clientes deberán estar
encriptadas con RSA.
Agencia de
Aprendizaje
a lo largo
de la vida

e Ante ataques de seguridad, el sistema se bloqueará y requerirá la intervención de

un administrador de seguridad para reactivarse.

Seguridad Industrial:

e El sistema no operará si la temperatura externa es inferior a 4 grados Celsius.

e Encaso de incendio, el sistema se apagará automáticamente (por ejemplo, en
ascensores).

Usabilidad:

El tiempo de aprendizaje del sistema para un usuario no deberá superar las 4 horas.
e Latasa de errores del usuario no deberá ser superior al 1% de las transacciones
totales.
El sistema contará con manuales de usuario estructurados y mensajes de error
informativos.
e Se proporcionará un módulo de ayuda en línea y la aplicación web será
"responsive" para múltiples dispositivos.

Disponibilidad:

El sistema estará disponible el 99.99% del tiempo.

El tiempo para iniciar o reiniciar el sistema no excederá los 5 minutos.
La tasa de fallos no superará el 0.5% del tiempo total de operación.
El promedio de duración de las fallas no excederá los 15 minutos.
La probabilidad de fallo no será mayor al 0.05.

Otros Ejemplos de Requerimientos del Producto:

Desarrollo para plataformas PC y Mac.

e Compatibilidad con todas las versiones de Windows desde Windows 95 en
adelante.
e Consumo de menos de 500 MB de memoria RAM y ocupación de menos de 2 GB
en disco.
Manejo de fuentes en varios idiomas, incluyendo inglés, español, francés,
portugués, italiano, árabe y chino.
Interfaz de usuario implementada para navegadores web con HTML5 y JavaScript.

Ejemplos de requerimientos funcionales del producto

Funcionalidad de Procesamiento:

e El sistema deberá permitir la ejecución de N transacciones por segundo, verificadas

mediante la herramienta JMeter para pruebas de servicios web.
e Cada funcionalidad y transacción de negocio deberá ofrecer una respuesta al
usuario en menos de 5 segundos.
e El sistema debe ser capaz de manejar eficientemente hasta 100,000 usuarios
concurrentes.
Agencia de
Aprendizaje
a lo largo
de la vida

e Lasactualizaciones de datos en la base de datos deben reflejarse para todos los

usuarios en menos de 2 segundos.

Gestión de Acceso y Seguridad de Datos:

e Únicamente el administrador de acceso a datos podrá modificar los permisos de

acceso.
e El desarrollo del sistema deberá seguir patrones y prácticas de programación que
aumenten la seguridad de los datos.
e Serealizarán respaldos diarios, almacenados en un lugar seguro fuera del edificio
principal.
e Todas las comunicaciones externas entre servidores y clientes deberán ser
encriptadas utilizando el algoritmo RSA.
e Ante ataques de seguridad, el sistema se bloqueará automáticamente y requerirá la
intervención de un administrador de seguridad para su reactivación.

Seguridad Industrial:

e El sistema se apagará si la temperatura externa es inferior a 4 grados Celsius.

e En caso de detectarse un incendio, el sistema se apagará automáticamente (por
ejemplo, en ascensores).

Usabilidad:

e El tiempo de aprendizaje del sistema para un usuario no deberá exceder las 4

horas.
e Latasa de errores del usuario no deberá superar el 1% de las transacciones totales.
e El sistema contará con manuales de usuario estructurados y mensajes de error
informativos.
e Se proporcionará un módulo de ayuda en línea, y la aplicación web será
"responsive" para garantizar la visualización adecuada en múltiples dispositivos.
e El diseño de las interfaces gráficas deberá ser claro y bien estructurado.

Disponibilidad:

El sistema estará disponible el 99.99% del tiempo.

El tiempo necesario para iniciar o reiniciar el sistema no excederá los 5 minutos.
La tasa de fallos del sistema no superará el 0.5% del tiempo total de operación.
El promedio de duración de las fallas no excederá los 15 minutos.
La probabilidad de fallo del sistema no deberá ser mayor al 0.05.

Otros Requerimientos Funcionales del Producto:

Desarrollo para plataformas PC y Macintosh.

Compatibilidad con todas las versiones de Windows desde Windows 95.
Consumo de memoria RAM inferior a 500 MB y ocupación de disco inferior a 2 GB.
Manejo de fuentes en varios idiomas, incluyendo inglés, español, francés, portugués,
italiano, árabe y chino.
Agencia de
Aprendizaje
a lo largo
de la vida

e Lainterfaz de usuario será implementada para navegadores web utilizando HTML5 y

JavaScript.

Requerimientos no funcionales y requerimientos funcionales

Los requerimientos no funcionales y funcionales son elementos clave en la especificacion

de un sistema. Aqui hay una explicación adicional y algunos ejemplos adicionales:

Requerimientos No Funcionales:

Los requerimientos no funcionales describen las características del sistema que no

están directamente relacionadas con funciones específicas. Suelen ser aspectos de calidad,
restricciones o características que afectan la operación general del sistema.

Aquí hay un ejemplo:

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

Criterios de Aceptación: Solo usuarios autorizados pueden acceder a los datos. Se

implementarán medidas de autenticación, como nombre de usuario y contraseña, para
garantizar la seguridad de los datos.

Observación: Este requerimiento no funcional establece la necesidad de seguridad en el

sistema, pero no especifica cómo se logrará. Puede derivar en requerimientos funcionales,
como la implementación de un procedimiento de autorización.

Requerimientos Funcionales Derivados:

A partir de los requerimientos no funcionales, se pueden derivar requerimientos funcionales

especificos que describen cómo se implementarán las caracteristicas mencionadas. Aquí
hay un ejemplo derivado del requerimiento no funcional anterior:

Ejemplo: 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. Solo los usuarios
autorizados de esta forma podrán acceder a los datos del sistema.

Observación: Este es un ejemplo de cómo un requerimiento no funcional sobre seguridad

se traduce en un requerimiento funcional específico. Aquí se especifica cómo se
implementará la seguridad mediante un procedimiento de autorización.

Importancia de los Criterios de Aceptación:

Incluir criterios de aceptación es crucial para medir y verificar que los requerimientos se
cumplen. Estos criterios proporcionan una base objetiva para evaluar si el sistema cumple
con las expectativas establecidas.
Agencia de
Aprendizaje
a lo largo
de la vida

Limitaciones de la Derivación:

No todos los requerimientos no funcionales se pueden derivar fácilmente en requerimientos

funcionales. Algunos requerimientos no funcionales, como la usabilidad o la escalabilidad,
pueden ser más desafiantes de traducir directamente en funciones específicas y pueden
requerir un enfoque más holístico.

En resumen, tanto los requerimientos no funcionales como los funcionales son

esenciales en el proceso de desarrollo del software, y su definición clara, junto con criterios
de aceptación, contribuye al éxito del proyecto.

Descripción y Clasificación de Requerimientos Funcionales

Registro de Requerimientos Funcionales

Los requerimientos funcionales de un software se registran comúnmente en la matriz de

trazabilidad de requerimientos y en la especificación de requerimientos de software. La
matriz de trazabilidad ayuda a rastrear la relación entre los requisitos y otros artefactos del
proyecto, mientras que la especificación de requerimientos documenta las operaciones y
actividades que el sistema debe realizar.

Tipos de Requerimientos Funcionales

Entre los posibles requerimientos funcionales de un sistema, se incluyen:

Descripciones de Datos: Detalla la información que debe ser ingresada en el sistema,

incluyendo tipos de datos, formatos y validaciones.

Operaciones en Pantallas: Describe las operaciones específicas que deben llevarse a

cabo en cada pantalla o interfaz del sistema.

Flujos de Trabajo: Define las secuencias de acciones que el sistema debe seguir para
realizar un proceso especifico.

Reportes y Salidas: Especifica los informes y resultados que el sistema debe generar,
incluyendo su formato y contenido.

Gestión de Acceso: Define quién tiene el derecho de ingresar datos en el sistema y como
se gestionan los permisos de acceso.

Cumplimiento de Reglamentaciones: Establece cómo el sistema cumplirá con las

regulaciones y normativas específicas, ya sea del sector o generales.

Clasificación según Finalidad: Los requerimientos funcionales, al igual que otros tipos de
requerimientos de software, se pueden clasificar según su finalidad. Algunas categorías
comunes incluyen:

Requerimientos de Negocio: Relacionados con las funciones centrales del negocio y las
metas comerciales.
Agencia de
Aprendizaje
a lo largo
de la vida

Requerimientos Regulatorios: Impuestos por normativas y regulaciones específicas que

el sistema debe cumplir.

Requerimientos de Seguridad: Relativos a la protección de datos, control de accesos y

otros aspectos relacionados con la seguridad del sistema.

Otros Requerimientos Específicos: Pueden incluir requerimientos específicos del

proyecto, requisitos de usuarios clave o cualquier otro aspecto particular del sistema.

La clasificación de requerimientos funcionales facilita su gestión y comprensión,

permitiendo que los equipos de desarrollo se enfoquen en áreas específicas de importancia.
Además, asegura que el sistema cumpla con todas las funciones necesarias para satisfacer
las necesidades del usuario y los objetivos del proyecto.

Ejemplos de Requerimientos Funcionales de Proceso o Área de Negocio:

Notificación por Correo Electrónico: 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.

Registro de Pedidos de Compra Incompletos: Se permitirá el registro de pedidos de

compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente
modificando el pedido. Antes de aprobarse, los datos del pedido deben estar completos.

Flujo de Trabajo para Aprobación de Pedidos: Al aprobar un pedido, la solicitud pasará al

siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el sistema.

Gestión de Planes y Cronogramas de Proyecto: El sistema permitirá a los usuarios

autorizados ingresar, aprobar, cambiar o actualizar planes y cronogramas de proyecto.

Envío Automatizado de Cartas de Entrega: El sistema permitirá el envío automatizado de

cartas de entrega de órdenes directamente al almacén.

Identificación Única de Órdenes:A cada orden se le asignará un identificador único,

utilizado para identificarla en todos los procesos subsecuentes.

Relación entre Órdenes de Entrega y Pedidos de Venta:Al ingresar órdenes de entrega,

cada una estará asociada a un pedido de venta.

Facturación de Pedidos de Venta: La facturación de pedidos de venta se realizará en

lotes a través de una pantalla de pedidos pendientes de facturación. Una vez facturados, los
pedidos no se mostrarán en esta lista.

Registro de Facturas Manuales: El sistema permitirá el registro de facturas manuales no

asociadas a pedidos, pero requerirán autorización por parte del grupo de Gerentes antes de
ser contabilizadas.
Agencia de
Aprendizaje
a lo largo
de la vida

Proceso de Compras Completo: El proceso de compras abarcará los pasos de ingreso de

la requisición, emisión de la solicitud de cotización y emisión de la orden de compra.

Emisión de Estados Financieros: El software debe poder emitir estados financieros como
el balance general, estado de ganancias y pérdidas, estado de flujos de efectivo, así como
listados de mayor general y mayor analítico.

Aprobaciones de Pedidos de Compra: 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.

Ejemplos de Requerimientos Funcionales de Interfaz Gráfica:

Validación Automática de Cliente: La solución validará automáticamente el cliente

asociado a una orden con el sistema de gestión de contactos.

Validación de Monto Numérico: El campo de monto acepta únicamente valores numéricos

con dos decimales.

Restricción de Fecha de Transacción: El campo fecha de transacción acepta únicamente

fechas anteriores al día de hoy (día actual).

Validación de Campo de Nombre: El campo nombre acepta caracteres alfabéticos

únicamente.

Validación de Campo de Dirección: El campo dirección acepta caracteres alfabéticos,

numéricos y especiales.

Selección de País desde Lista Preseleccionada: El campo país consistirá en una lista de
preselección. El país asociado a una dirección debe ser previamente registrado en el
sistema.

Selección de Estado/Provincia desde Lista Preseleccionada: El campo estado,

provincia o departamento consistirá en una lista de preselección. A los usuarios se les
presentará únicamente los estados asociados al país seleccionado previamente. El
departamento o provincia a seleccionar deberá ser registrado en la funcionalidad
correspondiente.

Selección de Material desde Lista Preseleccionada: El campo material de elemento de la

pantalla de requisiciones de compra será una lista de preselección, que mostrará
unicamente los materiales registrados en el maestro de materiales.

Validación de Fecha Contable: El campo fecha contable acepta únicamente fechas que
correspondan con periodos contables que estén abiertos en el sistema.

Impresión de Datos en Pantalla de Registro de Pago: La pantalla de registro de pago

puede imprimir los datos en pantalla a la impresora.
Agencia de
Aprendizaje
a lo largo
de la vida

Visualización de Datos de Pen Drive o Flash Drive: 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:

Control de Acceso Autorizado: El sistema controlará el acceso y lo permitirá únicamente

a usuarios autorizados. Se aplicarán medidas de seguridad, como autenticación de
usuarios, para garantizar el cumplimiento de normativas de privacidad y seguridad de datos.

Implementación de Trazas de Auditoría en la Base de Datos: La base de datos será

implementada con trazas de auditoría. Se registrarán eventos y cambios en la base de
datos para cumplir con requisitos regulatorios y facilitar auditorías internas o externas.

Firmas Electrónicas en Hojas de Cálculo: Las hojas de cálculo asegurarán los datos
mediante el uso de firmas electrónicas. Este requerimiento busca cumplir con regulaciones
relacionadas con la integridad y autenticidad de la información contenida en las hojas de
cálculo.

Generación de Reporte Regulatorio Específico: El sistema permitirá elaborar y emitir el

reporte regulatorio XX, según los requerimientos establecidos en el reglamento y ley
aplicable. Este requerimiento asegura que el sistema pueda generar informes específicos
necesarios para cumplir con regulaciones específicas.

Formato Estándar para Libros de Venta y Compras: Los libros de venta y de compras
serán emitidos en el formato establecido por las autoridades tributarias de dicha materia.
Este requerimiento asegura que los registros contables cumplan con los estándares legales
y tributarios establecidos por las autoridades pertinentes.

Ejemplos de Requerimientos de Seguridad:

Control de Acceso con Nombre de Usuario y Contraseña: El sistema controlará el

acceso y permitirá únicamente a usuarios autorizados. Los usuarios deben ingresar al
sistema con un nombre de usuario y contraseña, asegurando una autenticación segura.

Alertas de Eventos Sensibles: El sistema enviará una alerta al administrador del sistema
en eventos sensibles como el registro de una nueva cuenta, ingreso al sistema por parte del
cliente, 2 0 más intentos fallidos en el ingreso de la contraseña de usuario y cambio de
contraseña de usuario. Estas alertas buscan identificar posibles actividades sospechosas.

Restricciones de Acciones según Grupos de Usuarios: 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 usuarios administradores no pueden
ingresar o aprobar solicitudes, pero sí pueden borrarlas. Estos requerimientos establecen
restricciones específicas basadas en roles para garantizar el principio de privilegios mínimos
necesarios.
Agencia de
Aprendizaje
a lo largo
de la vida

Intercambio de Datos encriptado vía HTTPS: Cualquier intercambio de datos vía internet
que realice el software se realizará mediante el protocolo encriptado HTTPS. Este
requerimiento asegura la seguridad de la comunicación entre el sistema y otros
componentes a través de internet, evitando posibles interceptaciones no autorizadas.

Acerca de los Requerimientos Funcionales:

Claridad para el Lector no Técnico:

Consideración: Los requerimientos funcionales deben redactarse de manera que el lector

pueda entender el funcionamiento del sistema sin tener conocimientos técnicos particulares
de su funcionamiento. Esto asegura la comprensión universal de los requisitos, facilitando la
colaboración entre los equipos técnicos y no técnicos.

Definición de una Forma Estándar:

Consideración: Es importante definir una forma estándar para expresar los requerimientos
y ser consistente con la misma en todos los documentos. La estandarización mejora la
legibilidad, facilita la gestión de requisitos y evita posibles confusiones.

Variedad de Formatos para Expresar Requerimientos:

Consideración: Los requerimientos funcionales no necesariamente tienen que definirse en

forma de narrativas escritas. También pueden utilizarse diagramas o flujos de procesos, los
cuales se incluyen en la especificación funcional del software o sistema a desarrollar. Esta
variedad de formatos permite una representación más visual y comprensible de los
requisitos.

Pasos para Identificar y Documentar Requerimientos Funcionales:

Proceso: Para identificar y documentar los requerimientos funcionales de software, se

siguen dos pasos. En primer lugar, se aplican técnicas de levantamiento de requisitos, tales
como la observación, entrevistas, observación, entre otras. Estas técnicas permiten
recopilar información valiosa sobre las necesidades y expectativas de los usuarios y otras
partes interesadas.

Documento de Requerimientos de Software:

Resultado: El resultado del levantamiento de requisitos se documenta en el documento de

requerimientos de software. Este documento sirve como referencia central para todos los
interesados, proporcionando una visión clara y completa de los requisitos funcionales del
sistema a desarrollar.
Agencia de
Aprendizaje
a lo largo
de la vida

Atributos Generales de los Requisitos:

ID (Identificador):

o Descripción: Proporciona un número único para identificar cada requisito. Facilita

la trazabilidad y referencia cruzada en la gestión de requisitos.
e Ejemplo: IRQ0001, FRQ0025, CU0143.

Nombre o Título:

. Descripción: Proporciona un nombre breve y descriptivo para el requisito. Ayuda

en la identificación rápida y la comprensión del propósito del requisito.
o Ejemplo: "Gestionar la presentación de solicitudes".

Descripción:

. Descripción: Detalla la funcionalidad o característica que se espera del sistema.

Brinda información detallada para comprender el comportamiento deseado.

Estado:

. Descripción: Indica la condición actual del requisito (por ejemplo, propuesto,

aprobado, implementado, etc.). Facilita el seguimiento del progreso y la gestión del
ciclo de vida del requisito.

Prioridad:

. Descripción: Asigna un nivel de importancia al requisito en relación con otros.

Ayuda a los equipos a enfocarse en los requisitos más críticos o prioritarios.

Origen:

. Descripción: Indica la fuente o el origen del requisito (por ejemplo, cliente,

usuario, regulación). Proporciona contexto sobre la razón detrás del requisito.

Fecha de Creación:

o Descripción: Registra la fecha en que se creó el requisito. Ayuda en la gestión del

tiempo y la trazabilidad histórica.

Fecha de Modificación:

o Descripción: Registra la fecha en que se realizó la última modificación al

requisito. Facilita el seguimiento de cambios y actualizaciones.

Autor:

. Descripción: Identifica a la persona o entidad responsable de la creación del

requisito. Brinda claridad sobre la fuente del requisito.
Agencia de
Aprendizaje
a lo largo
de la vida

Información de Versión:

e Descripción: Indica la versión del requisito para su control de configuración.

Puede coincidir con la versión del documento en el que se describe.
e Ejemplo: 1.0, 2.3, 1.0Beta.

Trazabilidad:

e Descripción: Establece las trazas hacia adelante y hacia atrás del requisito
en el proceso de desarrollo. Incluye trazas hacia autores, fuentes y
dependencias.
e Ejemplo: Trazabilidad hacia autores (quien lo redactó), fuentes (información
proporcionada por clientes o usuarios), y dependencias (productos de
desarrollo relacionados).

Importancia:

e Descripción: Indica la relevancia del requisito para clientes y usuarios. Se

expresa mediante valores numéricos o enumerados.
e Ejemplo: Alta, Media, Baja o asignación de valores numéricos (por ejemplo,
0, 1,2).

Estabilidad:

e Descripción: Estima la probabilidad de que el requisito no cambie durante el

resto del desarrollo. Ayuda a prever posibles fuentes de cambios en el
proyecto.
e Ejemplo: Alta, Media, Baja o asignación de valores numéricos (por ejemplo,
80%, 50%, 20%).

Comentarios:

e Descripción: Permite agregar comentarios adicionales o información no

prevista inicialmente sobre el requisito. Algunas herramientas pueden incluir
funcionalidades tipo foro para discusiones.
e Ejemplo: Espacio abierto para comentarios adicionales o discusiones.

Atributos Relacionados con la Gestión del Proyecto:

Estado:

o Descripción: Indica la situación en la que se encuentra el requisito en el ciclo de

vida de los requisitos definido en el proyecto. Útil para conocer la evolución del
proceso de Ingeniería de Requisitos y gestionarlo adecuadamente.
. Ejemplo: Propuesto, Aprobado, Implementado, etc.
Agencia de
Aprendizaje
a lo largo
de la vida

Prioridad:

. Descripción: Indica la prioridad del requisito para decidir en qué iteraciones se

acomete su implementación. Facilita la planificación del desarrollo.
. Ejemplo: Alta, Media, Baja o asignación de valores numéricos (por ejemplo, 0, 1,
2).

Versión del Sistema en la que se Implementará:

. Descripción: Indica en qué versión del sistema está prevista la implementación

del requisito. Establecido por la dirección del proyecto una vez definida la prioridad y
planificadas las versiones.
. Ejemplo: V1.0, V2.1, etc.

Costo Estimado:

. Descripción: Estimador del coste de la implementación del requisito, normalmente

basado en la complejidad del mismo. Puede expresarse en horashombre o en su
correspondiente coste económico.
. Ejemplo: 50 horas, $5000, etc.

Estos atributos proporcionan información específica para la gestión del proyecto y

son útiles para el seguimiento y la planificación de las actividades de desarrollo. Es
recomendable mantener esta información aparte de los documentos que requieren
aprobación externa, ya que sus valores cambian con frecuencia sin necesidad de una
petición formal de cambio en los requisitos.

Atributos Relacionados con los Casos de Uso:

Precondición:

o Descripción: Condiciones sobre el estado del sistema o su entorno que deben

cumplirse para iniciar el caso de uso. Expresadas en lenguaje natural.
. Ejemplo: El usuario debe haber iniciado sesión.

Postcondición:

o Descripción: Condiciones sobre el estado del sistema o su entorno que deben

cumplirse después de la terminación exitosa del caso de uso. Expresadas en
lenguaje natural.
o Ejemplo: La información del perfil del usuario se actualiza.

Secuencia Normal:

o Descripción: Secuencia de interacciones del caso de uso cuando se desarrolla

con normalidad y termina con éxito. Cada paso implica acciones realizadas por un
actor o el sistema. Puede incluir condiciones de realización para determinar si el
caso termina con éxito en esa secuencia o se cancela.
Agencia de
Aprendizaje
a lo largo
de la vida

o Ejemplo:
1. El usuario selecciona la opción "Editar perfil".
2. El sistema muestra el formulario de edición.
3. El usuario modifica la información y confirma.
4. El sistema guarda los cambios.

Excepciones:

o Descripción: Comportamiento del sistema en el caso de que ocurra alguna

situación excepcional durante la realización de un paso específico. Después de
manejar la excepción, el caso de uso puede continuar con la secuencia normal o
cancelarse, dejando al sistema en el mismo estado que antes de comenzar el caso
de uso.
. Ejemplo: Si la conexión a la base de datos falla, mostrar un mensaje de error.

5. Rendimiento:

o Descripción: Opcionalmente, indica el tiempo máximo que el sistema puede

tardar en realizar la acción especificada en los pasos del caso de uso.
. Ejemplo: El sistema debe completar la operación en menos de 5 segundos.

6. Frecuencia:

o Descripción: Opcionalmente, se indica el número de veces por unidad de tiempo

que se espera que se realice el caso de uso cuando el sistema esté en explotación.
Importante para casos de uso con alta frecuencia, que deben cumplir posibles
requisitos de rendimiento.
. Ejemplo: Se espera que el caso de uso de "Procesar Pago" se realice cientos de
veces por hora.

Estos atributos proporcionan detalles específicos para mejorar la especificación y

comprensión de los casos de uso, facilitando así la gestión del proyecto y el desarrollo del
sistema.

Atributos Relacionados con los Requisitos de Conducta:

Interfaz de Servicios:

. Descripción: Atributo booleano que indica si el sistema a desarrollar debe

disponer de una interfaz de servicio para la funcionalidad descrita en el requisito. Se
completa con el literal Sí o No.
o Ejemplo: Sí (indica que se requiere una interfaz de servicio).

Buenas Prácticas y Recomendaciones de Uso:

A la hora de establecer los atributos de los requisitos, es fundamental considerar las

siguientes recomendaciones:
Agencia de <
/>

1. Asegurarse de Cumplimentar Todos los Atributos:

. Descripción: Es crucial completar todos los atributos asociados a los requisitos.

Esto garantiza la trazabilidad, el mantenimiento a lo largo del tiempo de la
información y facilita la planificación del desarrollo del proyecto.
. Consejo: Una información completa y precisa contribuye a una gestión efectiva de
los requisitos.

2. Establecer el Coste Estimado en Función de una Metodología de Planificación:

. Descripción: Se recomienda establecer el coste estimado del requisito en función

de una metodología de planificación. Esto es especialmente útil cuando se relaciona
con los casos de uso derivados del requisito establecido.
. Consejo: La estimación precisa del costo facilita la asignación adecuada de
recursos y contribuye a una planificación realista del desarrollo del proyecto.

Ejemplos de Atributos de Requisitos:

1. Requisito de Sistema de Gestión de Contenidos:

Identificador Único: SYSREQ001

Nombre Descriptivo: Administrar Usuarios del Sistema

Información de Versión: Versión 1.0, creada el 20230515

Trazabilidad:

Autores: Equipo de Desarrollo de Aplicaciones

Fuentes: Documento de Requisitos del Cliente

Dependencias: SYSREQ002 (Gestión de Roles)

Importancia: Alta (3 en una escala de 0 a 5)

Estabilidad: Media (50% de probabilidad de cambio)

Comentarios: Requiere integración con el módulo de autenticación.

[Estado]: En revisión

Prioridad: Alta

Versión del Sistema en la que se Implementará: 2.1

Agencia de
Aprendizaje
a lo largo
de la vida

Coste Estimado: 40 horashombre

2. Caso de Uso Registro de Usuario:

Identificador Único: UCREG001

Nombre Descriptivo: Registrar Nuevo Usuario

Precondición: El usuario debe acceder al formulario de registro.

Postcondición: El sistema almacena la información del nuevo usuario.

Secuencia Normal:

1. El usuario completa el formulario con sus datos.

2. El sistema valida la información.

3. El sistema crea una cuenta para el usuario.

4. El sistema muestra un mensaje de registro exitoso.

Excepciones: Si la dirección de correo ya está registrada, muestra un mensaje de error.

Rendimiento: 5 segundos por registro.

Frecuencia: Esperado varias veces al día en condiciones normales de uso.

3. Requisito de Conducta Seguridad del Sistema:

Identificador Único: BEHSEC001

Descripción: El sistema debe garantizar la seguridad de la información del usuario.

Interfaz de Servicios: Sí

[Comentarios]: Requiere colaboración con el equipo de seguridad.

Coste Estimado: $10,000

Estos ejemplos ilustran cómo cumplimentar los atributos de requisitos en diferentes

contextos, proporcionando información esencial para la gestión del proyecto y su
implementación.

Uso de Plantillas

La plantilla para requisitos de información puede variar según la organización y el

proyecto, pero a continuación se proporciona una plantilla básica que puedes utilizar como
punto de partida. Asegúrate de adaptarla a tus necesidades específicas y a las prácticas de
tu organización.
Agencia de
Aprendizaje
a lo largo
de la vida

Ejemplos:

Plantilla de Requisitos de Información:

1. Identificador Único:

Proporciona un identificador único para el requisito.

Ejemplo: INFOREQ001

2. Nombre Descriptivo:

Describe el requisito de información de manera concisa.

Ejemplo: Información de Cliente para Proceso de Facturación

3. Descripción:

Detalla el propósito y contexto del requisito de información.

Ejemplo: Este requisito establece la necesidad de recopilar y almacenar información

detallada del cliente para facilitar el proceso de facturación. La información incluirá nombre,
dirección, historial de transacciones y cualquier dato relevante para la generación de
facturas.

4. Fuentes de Información:

Identifica las fuentes de donde se obtendrá la información.

Ejemplo: Base de Datos de Clientes, Formularios de Pedido en Línea.

5. Formato de la Información:

Especifica el formato en el que se debe presentar la información.

Ejemplo: Datos estructurados en campos separados (por ejemplo, CSV).

6. Destino de la Información:

Indica dónde se almacenará la información.

Ejemplo: Base de datos centralizada para el sistema de facturación.

7. Frecuencia de Actualización:

Establece con qué frecuencia se actualizará la información.

Ejemplo: La información del cliente se actualizará en tiempo real después de cada

transacción.
Agencia de
Aprendizaje
a lo largo
de la vida

8. Nivel de Acceso:

Define quiénes tienen acceso a esta información.

Ejemplo: Solo personal autorizado en el departamento de facturación.

9. Seguridad y Privacidad:

Especifica cualquier consideración de seguridad o privacidad asociada con esta

información.

Ejemplo: La información del cliente estará cifrada y solo será accesible a través de
autenticación segura.

10. Responsable:

Asigna la responsabilidad de gestionar y mantener esta información.

Ejemplo: Departamento de Facturación.

11. Impacto en Otros Requisitos:

Indica si este requisito de información tiene algún impacto en otros requisitos del
sistema.

Ejemplo: Requisitos relacionados con la generación de informes financieros.

12. Aprobado por:

Identifica a la persona o equipo responsable de aprobar este requisito de

información.

Ejemplo: [Nombre del Responsable de Proyecto]

Recuerda adaptar esta plantilla según las necesidades específicas de tu proyecto y

asegúrate de involucrar a las partes interesadas relevantes en el proceso de definición y
aprobación de requisitos de información.
 Ejemplos gráficos

<id>-999 <nombre descriptivo>

[Versión] <n? versión> (<fecha versión>)

[Dependencias] |e <requisitos generales de los que depende>

e <otros requisitos de los que depende>
.
Descripción El sistema deberá almacenar la información correspondiente
a <concepto relevante>. En concreto:
Datos * <datos específicos sobre el concepto relevante>
específicos ha
[Importancia] <importancia del requisito para el cliente>.

[Prioridad] <prioridad del requisito para la dirección del proyecto>

[Estado] < estado del requisito según el ciclo de vida adoptado por el proyecto >

Comentarios <comentarios adicionales sobre el requisito>

Plantilla para requisitos de información

<id>-999 <nombre descriptivo>

[Versión] <n? versión> (<fecha versión>)

[Dependencias] e <requisitos generales de los que depende>

* <otros requisitos de los que depende>
.

Descripción El sistema deberá <descripción de la conducta del sistema>.

Interfaz de ,
servicio {SiNo}
[Importancia] <importancia del requisito para el cliente>.

[Prioridad] <prioridad del requisito para la dirección del proyecto>

[Estado] < estado del requisito según el ciclo de vida adoptado por el proyecto >
Comentarios <comentarios adicionales sobre el requisito>

Plantilla para casos de usos de solicitud de una conducta del sistema.

 <nombre descriptivo>

[Versión] <n? versión> (<fecha versión>)

[Dependencias] <requisitos generates de los que depende>

<lista de casos de uso que invoca>
<otros requisitos de los que depende>

Precondición <precondición del caso de uso del sistema>

Descripción El sistema deberá comportarse como se describe en el siguiente caso de

uso:
Secuencia Paso | Accion
normal
1 (El actor <actor de sistema>, El sitema} <acción/es realizada/s
por el actor o el sistema>
2 |Serealizael caso de uso <caso de uso de sistema>
3 $i <condición>,

3.n | (El caso de uso termina con éxito, El caso de uso se

cancela)

Postcondición | <postcondicion del caso de uso del sistema>

Excepciones Paso | Acción

P Si <condición de excepción>,

E.m | (El caso de uso continúa, El caso de uso se cancela)

[Rendimiento] | Paso | Cota

de tiempo

q k <unidad de tiempo>

[Frecuencia) <n? de veces> / <unidad de tiempo>

[Importancia] | <importancia del caso de uso para el cliente>.

[Prioridad] <prioridad del caso de uso para la dirección del proyecto>

[Estado] < estado del caso de uso según el ciclo de vida adoptado por el proyecto >

Comentarios <comentarios adicionales sobre el caso de uso>

Plantilla completa para casos de usos.

Agencia de
Aprendizaje
a lo largo
de la vida

Ciclo de Vida de un requerimiento

El ciclo de vida de un requerimiento se refiere a las diferentes etapas por las que
pasa un requerimiento desde su concepción hasta su satisfacción y, en algunos casos, su
eventual obsolescencia o eliminación. El ciclo de vida proporciona una estructura para
gestionar y rastrear los cambios en los requerimientos a lo largo del tiempo. A continuación,
se describen las principales etapas en el ciclo de vida de un requerimiento:

1. Identificación:

En esta etapa, se identifican y documentan los requerimientos. Pueden surgir de diversas

fuentes, como los clientes, usuarios, stakeholders, análisis de negocio, etc.

2. Captura y Análisis:

Los requerimientos identificados se capturan y analizan en detalle. Se busca comprender

completamente los objetivos, características y restricciones asociadas a cada requerimiento.

3. Documentación:

Los requerimientos se documentan formalmente en un formato específico. Esto puede

incluir detalles como descripciones, criterios de aceptación, prioridades y cualquier
información relevante.

4. Revisión y Validación:

Los requerimientos documentados se someten a revisiones y validaciones. Esto implica

la revisión por parte de stakeholders clave para asegurar que los requerimientos sean
comprensibles, claros y consistentes.

5. Aprobación:

Después de la revisión y validación, los requerimientos son aprobados oficialmente. Esta

aprobación puede provenir de los clientes, usuarios o cualquier entidad responsable de la
toma de decisiones en el proyecto.

6. Gestión de Cambios:

A lo largo del desarrollo del proyecto, pueden surgir cambios en los requerimientos
debido a diversas razones, como cambios en el entorno empresarial, nuevos conocimientos
o evolución de los objetivos del proyecto. La gestión de cambios se encarga de evaluar,
aprobar y aplicar esos cambios.

7. Implementación:

Los requerimientos aprobados se implementan en el sistema. Este paso puede implicar

actividades de diseño, desarrollo, pruebas y despliegue, según la naturaleza del
requerimiento.
Agencia de
Aprendizaje
a lo largo
de la vida

8. Validación de Implementación:

Una vez implementados, los requerimientos se validan para asegurarse de que cumplen
con los criterios de aceptación y satisfacen las necesidades del cliente o usuario.

9. Operación y Mantenimiento:

Después de la implementación exitosa, los sistemas entran en la fase operativa. Durante

esta fase, es posible que se realicen ajustes, mejoras y correcciones de errores, lo que
implica cambios en los requerimientos.

10. Retiro u Obsolescencia:

Algunos requerimientos pueden volverse obsoletos con el tiempo debido a cambios

en el entorno empresarial, avances tecnológicos u otras razones. En este caso, se pueden
retirar formalmente del sistema.

Es importante señalar que el ciclo de vida de un requerimiento puede variar según la

metodología de desarrollo utilizada (por ejemplo, enfoques ágiles, enfoques tradicionales de
cascada, etc.) y la naturaleza del proyecto. La gestión efectiva del ciclo de vida de los
requerimientos contribuye a la entrega exitosa de un sistema que cumple con las
expectativas del cliente o usuario.