Testing de Calidad de Software

Proyectos de Testing

1. Ejemplos de Requerimientos Funcionales y no Funcionales

2. Atributos de cada requisito.
 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 JMeter aplicada al Software Testing de servicios web.

 Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de
5segundos.
 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.

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 contar con manuales de usuario estructurados adecuadamente.
 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.
 La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada visualización
en múltiples computadores personales, dispositivos tableta y teléfonos inteligentes.
 El sistema debe poseer interfaces gráficas bien formadas.
 Disponibilidad

 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.
 La tasa de tiempos de falla del sistema no podrá ser mayor al 0,5% del tiempo de operación total.
 El promedio de duración de fallas no podrá ser mayor a 15 minutos.
 La probabilidad de falla del Sistema no podrá ser mayor a 0,05.

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 95.
 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.
 La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos (Español,
Frances,Portugués, Italiano), Arábico y Chino.
 La interfaz de usuario será implementada para navegadores web únicamente con HTML5 y
JavaScript.
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á Behaviour Driven Development (BDD) apoyada
enSelenium.
 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.
 Debe especificarse un plan de recuperación ante desastres para el sistema a ser desarrollado.
 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.
 Las pruebas de software se ejecutarán utilizando Selenium y Java como herramienta y lenguaje
Scripting para automatizació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.

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.

Como se describen y clasifican los requerimientos funcionales

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

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

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

 Descripciones de los datos a ser ingresados en el sistema.

 Descripciones de las operaciones a ser realizadas por cada pantalla.

 Descripción de los flujos de trabajo realizados por el sistema.

 Descripción de los reportes del sistema y otras salidas.

 Definición de quien puede ingresar datos en el sistema.

 Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean
aplicables.
Al igual que otros tipos de requerimientos de software, como por ejemplo los requerimientos no
funcionales, 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.

 A cada orden se le asignará un identificador único, que será utilizado para identificarla en todos
los procesos subsecuentes que se realicen sobre esta.

 Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un pedido de venta.
 La facturación de pedidos de venta se realizara en lotes, por medio de una pantalla de pedidos
pendientes de facturación, la cual mostrará los pedidos no facturados. Una vez facturados los
pedidos no se mostrarán en esta lista.

 El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin

embargo, estas requerirán autorización por parte del grupo de Gerentes antes de ser
contabilizadas.
 El proceso de compras en el sistema abarcará los siguientes pasos y transacciones: Ingreso de la
requisición, emisión de la solicitud de cotización y emisión de la orden de compra.
 Los elementos de la solicitud de cotización serán los mismos de la requisición asociada, al igual
que los dela orden de compra. El sistema permitirá la emisión de solicitudes de cotización y
órdenes de compra parciales.
 La contabilización de transacciones de facturas de venta y facturas de compra podrá
configurarse para realizarse de forma automatizada a su registro, o manualmente en lotes
(Proceso Batch).
 El software debe poder emitir los siguientes estados financieros: Balance general, Estado de
ganancias y pérdidas, Estado de flujos de efectivo. Además, debe poder emitir un listado de
mayor general y mayor analítico.
 Los pedidos de compra que excedan los montos establecidos en el flujo de liberaciones de
pedidos configurados, deberán pasar por las aprobaciones establecidas en dicho flujo de
aprobación.

Ejemplos de requerimientos funcionales de interfaz gráfica

 La solución validara automáticamente el cliente asociado a una orden con el sistema de gestión
de contactos.

 El campo de monto acepta únicamente valores numéricos con dos decimales.

 El campo fecha de transacción acepta únicamente fechas anteriores al día de hoy (día actual).

 El campo nombre acepta caracteres alfabéticos únicamente.

 El campo dirección acepta caracteres alfabéticos, numéricos y especiales.

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

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

 El campo material de elemento de la pantalla de requisiciones de compra será una lista de

preselección,que mostrará únicamente los materiales registrados en el maestro de materiales.

 El campo fecha contable acepta únicamente fechas que correspondan con periodos contables
que estén abiertos en el sistema.

 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

 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 dela 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.

Acerca de los requerimientos funcionales

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

 Asimismo, los requerimientos funcionales no necesariamente tienen que definirse en forma de

narrativas escritas, sino que también pueden utilizarse diagramas o flujos de procesos, los cuales
se incluyen en la especificación funcional del software o sistema a desarrollar.

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

 El resultado del levantamiento de requisitos se documenta en el documento de requerimientos

de software.
 Atributos de los requisitos Descripción
Los atributos de los requisitos son información que se añade a la descripción de
los requisitos por diversos motivos (identificación, trazabilidad, facilitar su gestión, etc.).
En cierta forma, son la meta información de los requisitos.
A continuación, se describen los atributos generales de los requisitos y los
relacionados de manera específica con la gestión del proyecto. Otros atributos que
dependen de la naturaleza del requisito se definen las plantillas de requisitos específicas
de cada tipo de requisito.

Atributos generales de los requisitos

Los atributos habituales en los requisitos de sistemas software (requisitos de
producto en terminología CMMI-DEV) suelen ser los que se describen a continuación.
Algunos tipos de requisitos pueden tener atributos más específicos, que se describen
en las plantillas correspondientes a cada tipo de requisito propuesto.

Identificador único
Para permitir la trazabilidad, todo requisito debe tener un identificador que no debe
cambiar a lo largo de su ciclo de vida, o al menos no debe cambiar una vez que el requisito
se incluya en una línea base. Aunque un requisito se elimine, su identificador no debe
reutilizarse, sobre todo si el requisito ha formado parte de alguna línea base.
Existen múltiples alternativas para la construcción de identificadores únicos de requisitos.
La mayoría suelen estar formadas por una etiqueta (denominada en algunas herramientas
de gestión de requisitos como contador) y un número secuencial, por ejemplo: IRQ-0001,
MAD-CU-0062, ACZ-GO-FRQ-0039, etc. En cada proyecto se deberá determinar la
forma de construir las etiquetas.
Por ejemplo:
Tipo De Requisito-9999: IRQ-0001, FRQ-0025, CU-0143, etc. La etiqueta indica únicamente
el tipo del requisito que identifica mediante su abreviatura.

Subsistema-Tipo De Requisito-9999: GOF-IRQ-0001, BUS-FRQ-0025, MAD-CU-0143, etc.

La etiqueta indica el prefijo propio de un subsistema, el tipo de requisito y un número
secuencial relativo a la combinación subsistema-tipo de requisito. En el caso de que haya
una jerarquía de subsistemas, la etiqueta puede contener varios elementos, por ejemplo
MAD-IR-CU-0143.

En caso de que exista una descomposición jerárquica de requisitos, si el padre tiene el

identificador ID-XXX, sus requisitos hijos pueden utilizar ese mismo identificador
seguido de un punto y un número secuencial. Así, los hijos del requisito identificado
como RG-001, podrían identificarse como RG-001.01, RG-001.02, y así sucesivamente.
Nombre descriptivo
Normalmente, aparte de un identificador único, los requisitos suelen atribuirse con
un nombre corto para hacer referencia a ellos de forma algo más humana que si sólo se
usara el identificador. Es precisamente la dificultad de generar nombres únicos lo que
hace imprescindible a los identificadores únicos.
Ejemplos de nombres descriptivos de requisitos pueden ser: Gestionar la
presentación de solicitudes, Información sobre incidencias, Registrar una nueva
incorporación, etc.

Información de versión
Los requisitos deben estar bajo control de configuración, por lo que se van
generando diferentes versiones a lo largo de un proyecto. Para evitar confusiones entre
distintas versiones de un mismo requisitos, es importante conocer el número o etiqueta
de la versión de un requisito (por ejemplo 1.0, 2.3, 1.0Beta, 2.1RC2, etc.) y la fecha en
que se creó dicha versión.
En el caso de que no se dispongan de herramientas de gestión de requisitos que
permitan un control de configuración a nivel de requisitos individuales, la versión de los
requisitos puede hacerse coincidir con la versión del documento en el que se describen.

Trazabilidad
Para mantener la trazabilidad, los requisitos deben estar convenientemente
trazados hacia adelante y hacia atrás en el proceso de desarrollo. Así, se suelen mantener
las trazas hacia:
Autores: son los autores del requisito. Lo habitual es atribuir los requisitos con el
nombre y organización a la que pertenecen las personas que lo han redactado. Esta
información es importante para poder gestionar posibles no conformidades de calidad
de los requisitos y para solventar dudas o conflictos que puedan surgir.
Fuentes: son las personas (casi siempre clientes y/o usuarios) o documentos que
han proporcionado información sobre el requisito. Esta información es importante
para poder solventar posibles dudas o conflictos que puedan surgir.
Dependencias: otros productos de desarrollo de los que depende el requisito. Es
el concepto más habitual de trazabilidad, en el que se atribuyen los requisitos con la
información de otros productos de desarrollo que, en caso de cambio, podrían
tener impacto sobre el requisito. Esta información es fundamental para poder
realizar un análisis de impacto de un cambio dentro del Procedimiento de Control
de Cambios establecido en el proyecto. Estas dependencias suelen ser con
productos previos en el desarrollo (por ejemplo dependencias desde requisitos
específicos hacia requisitos generales, desde casos de uso hacia modelos de negocio,
etc.) o con productos simultáneos en el desarrollo (por ejemplo dependencias entre
requisitos específicos, entre casos de uso, etc.).
La información de las dependencias no siempre se muestra asociada a cada
requisito, sino que es habitual representarla en forma de matriz de trazabilidad o de
listas de trazabilidad.
Importancia

La importancia de un requisito indica la relevancia del requisito para los clientes y

usuarios, y suele estar relacionada con la importancia de los objetivos de negocio que el
requisito ayuda a cumplir. La importancia se suele expresar de diversas formas:
Valores numéricos: se asigna un valor numérico a la importancia del requisito,
normalmente entre 0 y 3 o entre 0 y 5. Algunas propuestas asumen que el valor mínimo
(cero o uno normalmente) es la máxima importancia, mientras que otras asumen que
es el valor máximo el que representa la importancia.
Valores enumerados: se crea una escala de prioridad con valores como alta, media y
baja. También se pueden usar una escala ordinal con literales con expresiones como
vital, importante y quedaría bien y se asigna a cada requisito un valor. Puede existir
una correspondencia directa con valores numéricos (por ejemplo alta = 0, media = 1
y baja = 2).

Estabilidad

La estabilidad de un requisito indica una estimación de la probabilidad de que el

requisito no cambie durante el resto del desarrollo. Este atributo es especialmente
interesante para detectar posibles fuentes de cambios en un proyecto y prepararse para
ello. Puede expresarse como un valor numérico (como un porcentaje de probabilidad por
ejemplo) o como un valor enumerado (por ejemplo alta, media o baja).

Comentarios

Es conveniente dejar abierta la posibilidad de atribuir los requisitos con alguna otra
información no prevista inicialmente. Algunas herramientas de gestión de requisitos
permiten definir nuevos atributos de requisitos de forma dinámica. Si no se dispone de
esta posibilidad, se debe recurrir a atribuirlos con los comentarios que se crea oportuno.
De hecho, algunas herramientas de gestión de requisitos no sólo permiten
comentarios, sino que incorporan funcionalidades similares a los foros para que se
puedan desarrollar discusiones sobre los requisitos.
Atributos relacionados con la gestión del proyecto
Para facilitar la gestión del proyecto se suelen añadir algunos atributos específicos a
los requisitos. Estos atributos no son propiedades intrínsecas de los requisitos, sólo tienen
sentido en el contexto de un proyecto. Por esta razón, suele ser conveniente mantener la
información de estos atributos separada de los documentos que deben aprobarse por
clientes y usuarios y de los que se deben generar líneas base, ya que sus valores cambian
con frecuencia sin necesidad de una petición de cambio en los requisitos que lo justifique.
En el caso de herramientas de gestión de requisitos, esta información se
mantiene pero no se incluyen en los documentos generados para ser aprobados. Si no
se dispone de herramientas de gestión de requisitos, esta información se puede
mantener aparte, por ejemplo en una hoja de cálculo, mientras que los requisitos y los
demás atributos se mantienen en un documento de texto.
Algunos de los atributos más habituales de este tipo se describen a continuación.
Estado

El estado de un requisito indica la situación en la que se encuentra el requisito en el

ciclo de vida de los requisitos definido en el proyecto. El estado de los requisitos es útil
para conocer la evolución del proceso de Ingeniería de Requisitos y poder gestionarlo
adecuadamente.
El ciclo de vida de los requisitos se establecerá antes de comenzar el proceso de
Ingeniería de Requisitos en las Normas de Gestión del Proyecto al objeto de adaptarse a
las características particulares de cada proyecto.

Prioridad
En desarrollos no lineales, la prioridad de un requisito es un indicador para decidir
en qué iteraciones se acomete su implementación. Los de mayor prioridad se
acometerán en las primeras iteraciones, los de prioridad media en las iteraciones
intermedias, y los de prioridad baja se acometerán en las últimas iteraciones si se
disponen de los recursos necesarios.
La prioridad de un requisito la establece la dirección del proyecto en función de la
importancia del mismo para clientes y usuarios y de otros factores como aspectos
técnicos, de recursos humanos, relación con otros proyectos, etc.
Al igual que en el caso de la importancia, se puede asignar un valor numérico o un
valor enumerado, por ejemplo alta, media y baja o usar literales como inmediatamente,
hay presión y puede esperar.

Versión del sistema en la que se implementará

 Este atributo indica en qué versión del sistema está prevista la implementación del
requisito. Lo establece la dirección del proyecto una vez establecida la prioridad y
planificadas las versiones que se van a desarrollar y entregar al cliente.
Normalmente, los requisitos de prioridad más alta se implementarán en las
primeras versiones, aunque razones técnicas pueden postergar su implementación
hasta versiones más avanzadas.

Coste estimado
Este atributo es un estimador del coste de la implementación del requisitos,
normalmente basado en la complejidad del mismo. Puede expresarse en horas-hombre
o en su correspondiente coste económico.

Atributos relacionados con los Casos de Uso

Para facilitar la gestión del proyecto se suelen añadir algunos atributos específicos a
los casos de uso que aumentan su especificación y comprensión. A continuación se
detallan las características de los mismos:

Precondición: condiciones sobre el estado del sistema o su entorno, expresadas en

lenguaje natural, que deben cumplirse para que se pueda iniciar el caso de uso.
Post-condición: condiciones sobre el estado del sistema o su entorno, expresadas
en lenguaje natural, que deben cumplirse después de la terminación con éxito del
caso de uso.
Secuencia normal: secuencia de interacciones del caso de uso cuando se desarrolla
con normalidad y termina con éxito. En cada paso, un actor o el sistema realiza una
o más acciones, o se realiza otro caso de uso. Una secuencia de pasos puede tener
una condición de realización, en cuyo caso debe indicarse si el caso termina con
éxito en esa secuencia o se cancela (si no se especifica nada se asume que continúa
en el siguiente paso).
Excepciones: comportamiento del sistema en el caso de que se produzca alguna
situación excepcional durante la realización de un paso determinado. Después de
realizar los pasos asociados al tratamiento de la excepción, el caso de uso puede
continuar la secuencia normal o cancelarse, dejando al sistema en el mismo estado que
antes de comenzar el caso de uso.
Rendimiento: opcionalmente, en los pasos del caso de uso que realiza el sistema, se
puede indicar el tiempo máximo que puede tardar el sistema en realizar la acción
especificada.
Frecuencia: opcionalmente, se puede indicar el número de veces por unidad de tiempo
que se espera que se realice el caso de uso cuando el sistema a desarrollar esté en
explotación. Aquellos casos de uso con una frecuencia elevada (varias veces por
segundo, por ejemplo), deben implementarse de forma que cumplan posibles requisitos
de rendimiento.
 Atributos relacionados con los Requisitos de Conducta
Para facilitar la gestión del proyecto se suelen añadir algunos atributos específicos a
los requisitos de conducta que aumentan su especificación y comprensión. A continuación
se detallan las características de los mismos:
Interfaz de servicios: Este atributo booleano indica si el sistema a desarrollar debe
disponer de una interfaz de servicio para la funcionalidad descrita en el requisito. Para
indicar el valor del atributo puede cumplimentarse con el literal Sí o No, como aparece
en la plantilla.

Buenas prácticas y recomendaciones de uso

A la hora de establecer los atributos de los requisitos se deben de considerar las siguientes
recomendaciones:
Asegurarse que se cumplimentan todos los atributos asociados a los requisitos, ya que
de ellos dependen cuestiones como la trazabilidad, el tiempo de vida de la información,
la planificación del desarrollo , etc.
Establecer el coste estimado en función de una metodología de planificación,
especialmente útil si se relaciona con los casos de uso que se deriven del requisito
establecido.

Ejemplos
A continuación se ofrecen varios ejemplos que recogen los diferentes atributos
definidos dentro de un requisito. Como reglas general, en la primera columna figura el
nombre del atributo en negrita y en la columna de la derecha el valor o descripción de dicho
atributo que debe cumplimentar el ingeniero de requisitos. Al usar las plantillas, el texto que
figura entre los símbolos < y > se sustituye por texto descriptivo original. El resto del texto
son los patrones lingüísticos que no hay que modificar y que facilitan la escritura, por
ejemplo, indicando cómo debe comenzar una frase. También puede aparecer texto entre
llaves {} que indica que hay que escoger una de las opciones, separadas por comas, que se
indican dentro de las llaves.
Por último, aquel atributo cuyo nombre aparece entre corchetes en la plantilla tiene
carácter de opcional. Por ejemplo, en la plantilla de la figura, el atributo versión se considera
opcional ya que se puede vincular a la versión del documento en cuyo caso no hay que
indicarlo. En caso de disponer de una herramienta de Gestión de la Configuración, que
puede actualizar automáticamente la versión cuando se produzca un cambio en el requisito,
sí se incluirá este atributo.
Como caso de ejemplo, se han utilizado la Plantilla para requisitos de información

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

Plantilla completa para casos de usos.