Clase 15

Requerimientos No
Funcionales
Sonia Rueda
Req del
Negocio

Captura

Req no
Funcionales

Anlisis

Req del
Usuario

Req
Funcionales

Especificacin

Req para los

datos

Validacin

Requerimientos del
Negocio
Requerimientos
No Funcionales

Desde los primeros encuentros el analista captura las

necesidades de clientes y usuarios, incluyendo los
requerimientos que cubren sus expectativas de calidad
y los que imponen restricciones.

Requerimientos del
Negocio
Requerimientos
No Funcionales
Requerimientos del
Usuario

Cada clase de usuarios puede requerir diferentes factores

de calidad y restricciones adems de asignarle diferentes
prioridades, segn sus tareas y su perspectiva.

Requerimientos del
Negocio
Requerimientos
No Funcionales
Requerimientos del
Usuario

Durante la captura de requerimientos con frecuencia el

usuario tiende a especificar restricciones sobre el
sistema que en verdad esconden factores de calidad.
El analista debe indagar acerca del por qu de la
restriccin, para identificar el factor de calidad implcito.

Los factores de calidad y las restricciones

conforman los requerimientos no
funcionales.
Mientras que los requerimientos
funcionales especifican qu debe hacer el
sistema, los requerimientos no funcionales
establecen cmo debe hacerlo.

Los factores de calidad son atributos que influyen

en el nivel de satisfaccin que brinda el producto
al cliente e incluso pueden determinar el xito del
proyecto.
Si los requerimientos funcionales especifican el
comportamiento del sistema, los factores de
calidad establecen las cualidades del
comportamiento.
Existen diferentes maneras de clasificarlos. Ms
all de la clasificacin que se adopte, es
importante capturarlos antes de que se disee la
solucin y no cuando el producto se verifica

Externos son percibidos y valorados

por los usuarios
Internos no pueden observarse
durante la ejecucin del sistema,
afectan nicamente al equipo de
desarrollo

Los factores de calidad externos describen

caractersticas observables cuando el software
est ejecutndose.
Influyen poderosamente en el nivel de calidad
que percibir el usuario.

Es el usuario quien debe indicar sus

expectativas relacionadas con cada atributo de
calidad externo y participa en la definicin del
criterio para medir la satisfaccin.

Los factores de calidad Internos no son

observables durante la ejecucin del sistema.
Son propiedades que se perciben durante el
desarrollo, verificacin o mantenimiento,
mientras que se implementa el cdigo, se lo
modifica, se lo usa o mueve a otra plataforma.
Afectan indirectamente al usuario cuando una
ineficiencia en la funcionalidad degrada la
performance o cuando un cambio en los
requerimientos demanda un tiempo o costo
excesivo.

Disponibilidad
Instalabilidad
Integridad
Interoperatibilidad
Performance
Confiabilidad
Robustez
Safety
Seguridad
Usabilidad

La disponibilidad se refiere al tiempo durante

el cual el sistema estar en servicio
ofreciendo toda su funcionalidad.
El sistema est en servicio desde que
comienza a funcionar hasta que deja de
ejecutarse por una falla o por una parada de
mantenimiento planificada o no.

Las tareas de mantenimiento pueden ser

borrar archivos temporarios, transferir datos
o recibirlos, defragmentar el disco, etc.
Observemos que la palabra mantenimiento se
est utilizando para referirse a una tarea y a
una etapa en el proceso de desarrollo.

Hay funcionalidades ms crticas que otras en

el sentido de que son esenciales para el que
el usuario realice tu tarea.
Para cada funcionalidad o conjunto de
funcionalidades, el usuario debe indicar en
qu perodos requiere disponibilidad y
durante cunto tiempo.

La disponibilidad est muy relacionada con

confiabilidad y est fuertemente condicionada
por la mantenibilidad que es una categora de la
modificabilidiad.
La disponibilidad de considerarse
particularmente en sitios web, aplicaciones
basadas en la nube y aplicaciones distribuidas
geogrficamente.

En todos los casos la disponibilidad depende de

la conectividad.

El software puede comenzar a usarse a partir del

momento en que est correctamente instalado en
el dispositivo que corresponde sobre una
plataforma adecuada.
La instalabilidad se refiere al tiempo y
capacitacin que requiere realizar las operaciones
que permiten que el sistema pueda comenzar a
usarse.

Por ejemplo descargar una aplicacin en un

celular, mover un software desde una PC a un
servidor web o actualizar un sistema operativo

La integridad se ocupa de prevenir la prdida

de informacin y preservar cierto nivel de
correctitud en los datos.
Los datos deben protegerse de errores
accidentales e intencionales.
Los ataques deliberados pueden tener las
mismas consecuencias que los accidentes.

Los controles de validez en los datos

ingresados por el usuario permiten
garantizar cierto nivel de integridad.
La integridad requiere controlar tambin los
datos recibidos de otros sistemas.
Es necesario adems controlar la recepcin
de software para proteger a los datos.

El sistema puede preservar la integridad sin

comprometer otros factores, como por
ejemplo la usabilidad.
Un sitio web que inicializa todo un formulario
cuando detecta que el usuario complet
incorrectamente un campo, seguramente no
satisfaga el factor usabilidad.

La integridad de los datos suele considerarse

como parte de los requerimientos de
seguridad.
En ocasiones se considera que la seguridad
es una parte de la integridad, porque los
requerimientos de seguridad suelen
enfocarse a prevenir el acceso a los datos por
usuarios no autorizados.

La interoperatibilidad indica cunta capacidad tiene

el sistema para intercambiar servicios con otros
sistemas y con cunta facilidad puede integrar a
otros dispositivos de hardware externos.

La principal cuestin a averiguar es qu aplicaciones

usa el usuario en conjunto con el producto y qu
datos intercambian estos sistemas.
A partir de los requerimientos de interoperatibilidad
pueden elegirse algn formato de intercambio de
datos estndar .

Es posible incluir una categora de

requerimientos no funcionales para los
requerimientos para las interfaces externas.

En ese caso, muchos requerimientos de

interoperatibilidad pueden especificarse como
requerimientos con interfaces externas.
Cualquiera sea la clasificacin adoptada, el
analista debe elegir una categora e incluir cada
requerimiento en un solo lugar.

La performance o rendimiento es uno de los

factores de calidad que aparece con mayor
frecuencia, incluye a varios atributos y depende de
varias cuestiones como la velocidad de la
computadora y las conexiones en red
La performance es una cualidad externa ntimamente
relacionada con una cualidad interna: la eficiencia.

Una baja performance ante una consulta provoca

irritacin y rechazo por parte del usuario pero
adems puede poner en riesgo a las condiciones de
seguridad.

Los requerimientos de performance afectan a las

estrategias de diseo de software y a la seleccin
del hardware y tienen un impacto importante en
el costo, de modo que tienen que ser
cuidadosamente establecidas.
El usuario va a querer siempre tiempo de
respuesta inmediato, pero claramente la
criticidad del traductor de un procesador de
texto no es la misma que la de un radar de
misiles.

La confiabilidad se refiere a la capacidad del software

para ejecutarse sin fallar por un perodo de tiempo.
Los problemas de confiabilidad se producen cuando
se ingresan datos no vlidos, el cdigo tiene errores,
una componente no est disponible cundo se la
necesita, el hardware falla.
La confiabilidad est entonces ntimamente ligada a
robustez y disponibilidad.
La confiabilidad est tambin muy ligada a
verificabilidad. Los sistemas con grandes
requerimientos de confiabilidad deben ser
verificados rigurosamente.

La manera de medir la confiabilidad puede

ser:

Porcentaje de operaciones que se ejecutan

correctamente en un perodo

Promedio de tiempo entre fallas

Los requerimientos de confiabilidad deberan

cuantificarse considerando el impacto que
provoca cada tipo de falla y el costo que
provoca aumentar la confiabilidad.

Una falla puede provocar que el usuario tenga

que rehacer su tarea. Es engorroso pero no
catastrfico.

Por ejemplo si una transaccin no se pudo

completar y se cancela completa, el usuario va a
tener que repetirla.
Si se completa parcialmente y el usuario no lo
percibe los datos pueden ser inconsistentes.
Ejemplo cajero, se recibe la plata y no se
modifica el saldo.

La robustez o tolerancia a fallas es la

capacidad de un sistema de seguir
funcionando adecuadamente ante situaciones
anormales como fallas de hardware, datos no
vlidos, ataques externos o condiciones
operativas inesperadas.
Un software robusto se recupera de
situaciones imprevistas sin consecuencias
graves.

El sistema operativo se estaba actualizando en el

momento que se termin la batera.
Una manera de que el sistema sea robusto es
especificar condiciones de excepcin y
mecanismos para manejarlos.
Para el usuario es natural describir escenarios de
fallas previsibles, condiciones de error que el
sistema debe detectar y reaccionar.
Es ms difcil identificar situaciones anormales o
excepcionales.

La seguridad es un concepto muy amplio.

Los requerimientos de seguridad se orientan
a mitigar el riesgo de ataques y prevenir
amenazas.
No hay tolerancia a fallas de seguridad, un
sistema se considera seguro hasta que se
detecta que es vulnerable.
La confiabilidad en cambio puede medirse en
niveles de intensidad.

Los dispositivos de hardware controlados por un

sistema de software pueden poner en riesgo la
vida y la salud de las personas.
El software que controla esto sistemas tiene
requerimientos de safety.
Con frecuencia se especifican como condiciones
o acciones que el sistema debe evitar que
ocurran.
Safety se refiere a la capacidad del sistema para
prevenir daos a las personas y pueden estar
establecidos por regulaciones externas o
internas.

La usabilidad se refiere al esfuerzo que el

usuario debe hacer para ingresar datos e
interpretar la salida.
La usabilidad incluye a todas las cualidades que
hacen que un sistema se perciba como
amigable

Uno de los aspecto claves de usabilidad es lograr

satisfacer a un espectro heterogneo de
usuarios.
Una alternativa para lograrlo es parametrizar
algunas de las opciones.

La simplicidad se refiere a cuan fcil es un

sistema de aprender a usarse.
Son dos cualidades que pueden enfrentarse.
Para evitarlo el sistema debera permitir un
aprendizaje incremental, que pueda permitir
incorporar nuevas funciones a medida que
aumenta el entrenamiento.

Eficiencia

Modificabilidad

Portabilidad

Reusabilidad

Escalabilidad

Verificabilidad

La eficiencia mide que tan bien utiliza el

sistema a

el procesador

el espacio en memoria

el ancho de banda

Si el sistema consume demasiados recursos,

el usuario percibe una degradacin en la
performance, son factores fuertemente
ligados.

La eficiencia es uno de los principales factores

que determina la arquitectura del sistema e
influye en la manera que el diseador distribuye
la computacin y las funciones entre las
componentes.
El usuario piensa la eficiencia en trminos de
tiempo de respuesta.
Es necesario que el analista lo estimule a
considerar otros aspectos vinculando eficiencia
con performance y anticipando el crecimiento de
la demanda o la carga.

La modificabilidad es la capacidad del diseo

y la implementacin para interpretarse,
modificarse y extenderse.
Es un factor crtico en aplicaciones
desarrolladas para entornos dinmicos,
desarrolladas con un modelo de ciclo de vida
incremental o iterativo.

Est muy ligada a mantenibilidad y

verificabilidad.

Tipo de
Mantenimiento

Descripcin

Correctivo

Corrige defectos que no fueron detectados

en la verificacin o no se consideraron
crticos.
Mejora algunas funcionalidades para
aumentar la satisfaccin de las necesidades
del negocio nuevas o ya existentes.
Modifica el sistema en respuesta a cambios
en el entorno operativo, sin alterar su
funcionalidad.

Perfectivo

Adaptativo

Cuando el diseador y el desarrollador

anticipan cambios pueden tomar decisiones
que favorezcan la modificabilidad.

La modificabilidad puede medirse

considerando el tiempo promedio requerido
para realizar un mantenimiento correctivo,
perfectivo o adaptativo.

La portabilidad se refiere al esfuerzo que

requiere migrar un producto de software de
un entorno operativo a otro.
Algunos autores incluyen en este factor el
esfuerzo requerido para internacionalizar un
producto.
Los aspectos de diseo que influyen en la
portabilidad son similares a los que afectan a
la portabilidad.

Es un requerimiento importante en
aplicaciones que deben ejecutarse en
distintos sistemas operativos o dispositivos,
como PC tablets y celulares.

La reusabilidad indica que esfuerzo relativo

requiere convertir una componente de
software para que sea utilizada en otras
aplicaciones.
El uso de metodologas rigurosas y
estndares favorece la reusabilidad.
Una componente reusable debe ser modular
y estar documentada
Una componente genrica tiene mayor
posibilidad de ser reusada que una
especfica.

Los paquetes son componentes reusables y

su utilizacin contribuye a implementar
nuevos mdulos de cdigo reusables.
Idealmente una componente reusable debe
ser independiente del entorno operativo de la
aplicacin para la cual fue desarrollada.

La reusabilidad es un factor difcil de

cuantificar pero el objetivo de reusar se
aplica en dos niveles:
Ante un nuevo producto reusar todas las
componentes que resulten adecuadas
Desarrollar nuevas componentes
considerando la posibilidad de que en el
futuro puedan reusarse en otras
aplicaciones.

La escalabilidad es la habilidad de una

aplicacin de crecer para adaptarse a un
mayor nmero de usuarios, datos,
servidores, localizaciones geogrficas,
transacciones, etc. sin comprometer la
performance o la correctitud.
Est relacionada con modificabilidad y
robustez.
La robustez considera cmo se comporta el
sistema cuando se excede el lmite de su
capacidad.

La verificabilidad se refiere a cmo las

componentes de software el producto integrado
puede evaluarse para demostrar si el
comportamiento del sistema es el esperado.

Con frecuencia el responsable de testing

desarrolla software para verificar el sistema. El
diseo de un software de testing requiere
determinar las condiciones iniciales para la
verificacin, los datos de prueba y los resultados
esperados.

La verificabilidad es un factor crtico si el

producto incluye algoritmos complejos o
existen dependencias entre las
funcionalidades.
Tambin es un factor importante cuando el
producto va a sufrir cambios frecuentes,
porque va a ser necesario controlar que los
cambios no daen la funcionalidad existente.

En un mundo ideal cada sistema debera

alcanzar el mximo nivel posible de cada
factor de calidad.
Un sistema debera ser accesible en todo
momento, jams fallar, brindar resultados
inmediatos y correctos siempre, impedir
cualquier intento de acceso no autorizado.

Sin embargo, algunos factores estn

enfrentados y no es posible maximizar todos
simultneamente.

Los factores de calidad sirven para disear

los tests de verificacin que permiten
demostrar si el sistema exhibe las
caractersticas que el usuario desea.
La valoracin del analista puede ser muy
diferente a la del usuario con relacin a
algunos factores.

Medibles directamente pueden cuantificarse. Es

posible establecer una escala con valores
mnimos y mximos.
Por ejemplo eficiencia (tiempo, espacio de
almacenamiento), confiabilidad (tiempo entre
fallas, fallas por unidad de tiempo)

Medibles indirectamente no se les puede

asociar valores concretos pero s indicadores
que permitan decidir si se cumplieron o no
Por ejemplo usabilidad, mantenibilidad.

En un mismo sistema puede haber mdulos

que requieran un mayor nivel de calidad en
cierto factor que otras.

Por ejemplo, algunas partes deben ser muy

fciles de aprender a usar, otras muy
eficientes.
La captura de los factores de calidad requiere
un procedimiento riguroso de interaccin
entre el analista y el resto de los
participantes.

Usted considera que el sistema tiene que ser

seguro? Necesita que sea eficiente?
Estas no son preguntas relevantes como
tampoco lo son:

Qu nivel de seguridad debe garantizar el

sistema? Qu tan eficiente debe ser el
software?
Difcilmente el usuario pueda responderlas
formuladas de este modo.

El analista gua al usuario en la exploracin

del proceso de negocios buscando cmo
valorar cada factor.
Nuevamente, no se trata solo del software, es
el sistema completo el que debe analizarse
desde la perspectiva de cada factor de
calidad seleccionado.

Cul es el tiempo de respuesta que usted

considera aceptable para que el sistema
responda la consulta q1?
Es una pregunta adecuada, como tambin es
til incluir preguntas acerca del
comportamiento inaceptable

Cul es el tiempo de respuesta que usted

considera inaceptable para que el sistema
responda la consulta q1?

Si bien los requerimientos no funcionales

pueden ser por un lado los ms difciles de
detectar, tambin son los que pueden tener
ms aspectos en comn entre un proyecto y
otro.
El analista puede tener una lista de preguntas
prestablecidas y luego seleccionar o
reformular las que considera relevantes.

Una buena alternativa es combinar dos tcnicas de

captura: un cuestionario con un encuentro de
captura.
Los usuarios reciben el cuestionario
anticipadamente, tienen oportunidad de pensar la
respuesta con tiempo, pero la elaboran guiados
por el analista durante un encuentro.
Pueden opinar varios representantes de la clase y
el lder de usuarios decide.

1. Examinar la lista de factores de calidad

2. Seleccionar los factores que son
requerimientos para el proyecto

3. Explicitar qu factores no son

requerimientos
4. Prioritizar
5. Especificar con precisin cmo va a
cuantificarse cada factor

1. Examinar con el usuario la lista de factores

de calidad, acordando el significado de cada
uno de ellos.
El analista tiene la responsabilidad de
identificar las clases de usuarios relevantes y
decidir si el lder puede actuar en nombre de
la clase o es necesario conocer la opinin de
un grupo de representantes.

2. Seleccionar con el usuario los factores que

deben considerarse requerimientos y para
cada uno especificar el argumento que
fundamenta la decisin de incluirlo como
requerimiento.
Cuando en el proceso opinan diferentes
participantes, puede haber distintos criterios
y es importante registrar qu opin cada
uno.

3. Explicitar los factores que no se

consideraron requerimientos.
El sistema probablemente no tenga los
atributos que no se seleccionaron como
requerimientos, de modo que el SRS debera
explicitar esta decisin.
Esto no exime al analista de su
responsabilidad porque puede no haber
elegido adecuadamente a los participantes.

4. Establecer la prioridad de cada factor de

calidad respecto a los dems
Una alternativa es cruzar cada par de
factores requeridos y marcar cul de los dos
es prioritario.
Una vez realizados todos los cruces se asigna
un puntaje a cada factor y se los ordena por
puntaje.

5. Refinar cada requerimiento de un factor de

calidad especificando con precisin cul es el
criterio con el cual va a medirse su
satisfaccin.
El analista debe elegir cuidadosamente las
preguntas que formular al usuario porque
las respuestas le permitirn elaborar la
especificacin.

La prioritizacin permite enfocar los

encuentros de captura y derivar los
requerimientos funcionales vinculados a los
factores de calidad con mayor prioridad.
Adems, cuando surgen conflictos entre
requerimientos funcionales, se adoptar la
perspectiva que quede mejor alineada con los
factores de calidad.

Si tiene elegir entre disponibilidad e

integridad, cul elige? Integridad
< indica que el factor de la fila es el ms
importante, indica que tiene prioridad el
factor de la columna
El factor ms importante en la tabla es
seguridad (score 7)
Claramente es importante verificar la
consistencia si A > B y B > C
no puede ser que C > A

Si la prioridad es la seguridad, la eficiencia

puede verse afectada porque van a
establecerse controles que van a provocar
que las transacciones sean ms lentas.
El problema surge cuando los conflictos
aparecen entre clases de usuarios que
adoptan diferentes perspectivas respecto a
los factores de calidad en s mismos.

En ese caso, el analista debe plantear el

conflicto tan pronto como lo detecte y
colaborar para que se resuelva, aunque
participe en la bsqueda de la solucin no es
su responsabilidad hallara.
Una vez que se han establecido los factores
de calidad que son requerimientos y se han
prioritizado, es necesario especificar cada
uno refinando el conocimiento acerca de las
expectativas del usuario.

Cada requerimiento puede especificarse en

lenguaje estructurado usando una plantilla.
La plantilla debera especificar toda la
informacin necesaria para valorar cada
factor.

El sistema debe ser amigable o El sistema

debe estar disponible 24 hs al da los 7 das
de la semana no son especificaciones de

requerimientos adecuadas.
La primera es muy subjetiva e imprecisa.
La segunda especificacin es bien objetiva y
precisa, pero probablemente demasiado
ambiciosa.
Ninguno permite que el diseador y el
desarrollador tomen decisiones.

Identificador

Prefijo que indica el tipo de requerimiento

y nmero unvoco dentro del tipo.

Descripcin

Breve

Unidad de medida

Para los Rangos de valores

Medicin/test

Procedimiento de medicin directa. Si el

requerimiento no puede medirse
directamente describe el test que permite
verificarlo

Rango de valores
aceptables

Valores planificados

Rango de valores
inaceptables

Valores que perjudican al proceso de

negocios

Descripcin de situaciones
excepcionales
Rango de valores
aceptables en cada
situacin excepcional

precisos y especficos
medibles
relevantes
accesibles
sensibles al tiempo

Qu funcionalidades son ms crticas y

requieren mayor disponibilidad?
Qu consecuencias puede provocar que la
disponibilidad del sistema no satisfaga los
requerimientos especificados?
En qu horarios y das resulta ms adecuado
planificar las tareas de mantenimiento que
afecten a la disponibilidad del sistema? Cul
es la duracin mxima tolerable?

Cul es la duracin mxima tolerable para un

mantenimiento no programado? Cmo se van
a manejar los intentos de acceso de los
usuarios durante los perodos de
mantenimiento programado y no programado?
Cmo se notifica a un usuario que est
usando el sistema, que dej de estar
disponible por completo o algunas funciones?

Si una tarea de mantenimiento puede

realizarse con el sistema funcionando,
Qu impacto sera tolerable sobre la
confiabilidad y la performance?
Cmo podra reducirse el impacto?

Qu dependencias existen sobre las

funcionalidades que afectan a la
disponibilidad?
Por ejemplo si no est funcionando la opcin
que permite autorizar pagos con tarjeta, el
pago con tarjeta no puede estar disponible.
S podra estar reservar entradas en el teatro
notificando al usuario que debe completar el
pago antes de x hs.

Disp-1. El sistema debe estar disponible de

lunes a viernes el 95% del tiempo entre las 8 y

las 20 y el 99% entre las 12 y las 16.
Esta especificacin no es lo suficientemente
precisas si el contrato entre la empresa que
desarrolla el sistema y la que lo requiere
establece una penalidad para los
requerimientos de calidad no satisfechos.

Una especificacin ms precisa exigira indicar

cul es la expectativa entre las 20 hs de un da
y las 8 hs de la siguiente.
En el caso de que no se aplique a todas las
funcionalidades, es necesario indicar a cules
se refiere.

Disp-2 No se aplicar penalidad cuando se

realicen tareas de mantenimiento planificadas

con al menos 24 hs de anticipacin, para el
horario comprendido entre las 21 hs de un da
y las 7 hs. del da siguiente.

Instalacin inicial
Recuperarse de una instalacin
incompleta
Reinstalar
Instalar una nueva versin
Instalar nuevas componentes
Retomar una instalacin anterior
Desinstalar

Cuntos minutos debera demandarle a un

operador capacitado realizar una
instalacin completa?
Qu operaciones de instalacin pueden
realizarse sin afectar el trabajo de los
usuarios?
Qu operaciones de instalacin requieren
reiniciar el dispositivo?

Qu controles pueden realizarse para

verificar el xito de la instalacin?

Qu usuarios estn autorizados para

realizar cada una de las operaciones
vinculadas con la instalacin?

INS-1. Un usuario sin entrenamiento en

este sistema especfico, pero que ha
instalado utilitarios de Microsoft, debe ser
capaz de completar la instalacin del
producto en menos de 10 m.
INS-2. Cuando se instala una nueva versin
del producto se guardan todos los perfiles
personalizados del usuario y se permite que
se restauren al terminan la instalacin o
posteriormente.

INS-3. El programa de instalacin verifica

que se dispongan de recursos suficientes
antes de comenzar la instalacin,
incluyendo la carga de la batera.
INS-4. El usuario que realiza la instalacin
debe tener privilegios para hacerlo.
INS-5. Todos los archivos temporarios que
genera el programa de instalacin se borran
si se completa la instalacin
satisfactoriamente.

Daos fsicos en los dispositivos de

almacenamiento
El usuario sobrescribe un archivo sobre
otro
Una falla del software provoca que se
pierdan las referencias
Una falla en los dispositivos de lectura
provoca que el formato de los datos se
corrompa

INT-1. Despus de ejecutar un backup, el

sistema verifica que la copia sea igual al
original.

Requiere que los datos no cambien durante

el backup.

INT-2. El sistema controla el acceso de

quienes pueden modificar los datos
INT-3. Cuando se importan datos se
establecen controles de validez a partir de
los tipos de datos.

INT-4. El sistema controlar diariamente

que el cdigo ejecutable no ha sido
modificado por usuarios no autorizados.
INT-5. El sistema controlar que las
transacciones se completen o se cancelen
volviendo al estado inicial.

Realizar backups regularmente y disponer

de un sistema para recuperar datos del
backup.
Proteger los backups
Son requerimientos imprecisos y el equipo de
desarrollo puede tomar decisiones que luego
no satisfagan las necesidades de los
usuarios.

Con qu sistemas externos interactuar el

producto?
Qu estructuras de datos y qu servicios se
intercambiarn?
En qu formato deben realizarse los
intercambios?

Qu dispositivos de hardware deben

interconectarse?

Qu protocolo de comunicacin se utilizar

en cada caso?
Qu otros requerimientos impone el sistema
con el que se realiza la comunicacin?

IOP-1. Cada farmacia de Baha Blanca debe poder

intercambiar informacin con los sistemas de las
drogueras que les proveen frmacos y otros
artculos.
IOP-2. La farmacia importa datos de la droguera
usando la notacin SMILES.

Este requerimiento de alguna manera se deriva del

anterior. Si el usuario especifica este ltimo el
analista debera preguntar por qu para obtener la
verdadera razn, que en este caso hemos
formulado en primer lugar.

Tiempo de respuesta
Capacidad de procesamiento

Capacidad de almacenamiento
para datos
Capacidad dinmica

Predictibilidad
Latencia

Comportamiento en condiciones
de sobrecarga

Nmero de segundos para mostrar

una pgina web
Cantidad de transacciones de la
tarjeta de crdito procesadas por
segundo
Nmero mximo de registros en
una base de datos
Nmero Mximo de usuarios
simultneos en una red social
Tiempo entre que se produce un
evento y se detecta
Tiempo entre que se detecta un
evento y comienza a ejecutarse la
accin que lo atiende.
Sistema telefnico ante un
desastre climtico.

Cuando se especifica un requerimiento de

performance incluir tambin en la documentacin el
argumento que justifica el requerimiento para guiar
al desarrollador en la implementacin.
Por ejemplo, una alternativa para lograr la integridad
de los datos ante fallas en los dispositivos es
mantener un espejo de la base de datos.
Claramente este provoca una sobrecarga que afecta
la performance.

Observemos que es necesario garantizar que cada

transaccin se registra en la BD y sus espejos.

La mayora de los usuarios no van a poder

contestar las preguntas del analista referidas
al nmero de transacciones por segundo o la
dependencia entre los eventos en un sistema
de tiempo real.
Como siempre es fundamental identificar a
los usuarios adecuados.

Cul es el tiempo de respuesta que usted

considera adecuado para que el sistema responda
la consulta q1?
Cuntos usuarios en promedio podran estar
usando simultneamente el sistema?
Cul es el nmero mximo de usuarios que el
sistema debera poder llegar a atender
simultneamente?
Cul es el horario del da, el da de la semana o la
poca del ao en la que se espera un uso ms
intenso?

PER-1. Cuando un cliente intenta acceder a un

cajero electrnico el sistema debe autorizar o
denegar el acceso en a lo sumo 2 segundos
PER-2. Una pgina web debe descargarse en menos
de 3 segundo en una conexin a internet de 30
megabits/second Internet connection.
PER-3. En un sistema de entrenamiento el 98% de
las actividades deben provocar un cambio de
estado 1 segundo despus de completarse.
(respuesta correcta o incorrecta)

Cunto tiempo debera transcurrir como mnimo

entre fallas?
Qu tarea estara dispuesto a rehacer el usuario
ante una falla?

Qu tareas no pueden repetirse si se produce

una falla?
Qu funcionalidades del sistema deberan ser
superconfiables?
Cunto tiempo puede estar cado el sistema sin
afectar significativamente el negocio?

Con-1. En un laboratorio de un centro de

investigacin se especifica que no ms de 5
experimentos de cada 1000 pueden perderse
por fallas de software.
Como otros de los factores de calidad no va a
poder verificarse hasta que el sistema est en
funcionamiento.

Con-2. La lectora de tarjetas debera fallar a

lo sumo cada 90 das.
No hay modo de asegurar que el sistema
satisface el requerimiento hasta que
transcurren 90 das y aun as puede fallar el
da 91 y 92.
El usuario debera manifestar su tolerancia a
fallas.

ROB-1. Si el editor de textos falla antes de

que el usuario salve su archivo el sistema
recuperar el contenido del archivo en dos
versiones, tal como estaba al ser salvado y
a lo sumo 3 minutos antes de la falla.
Nuevamente un requerimiento no funcional
se deriva en uno funcional. El desarrollador
debe incluir una accin de autoguardado
cada 3 minutos.

ROB-2. Cada parmetro de impresin debe

tener valores por omisin
Tamao de papel, mrgenes, color, etc.
ROB-3. Cuando el editor de texto no
reconoce una fuente utiliza una
prestablecida

Bajo qu condiciones una persona puede

verse perjudicada por el uso del producto?
Qu fallas del sistema pueden provocar
heridas en las personas?

Cmo pueden detectarse dichas

condiciones?
Qu acciones del operador debe detectar el
sistema porque provocan un riesgo?

SAF-1. El cliente debe conocer los

ingredientes con los que se prepara cada
tem del men
SAF-2. Si un reactor aumenta su temperatura
por ms de 5 grados C por minuto, el
sistema apagar la fuente de calor y
notificar al operador.
SAF-3. Un aparato para hacer radiografas
solo puede ser utilizado si el filtro est
colocadorcorrectamente.

Cules son los datos sensibles?

Quines estn autorizados a ver, copiar,

modificar, borrar datos sensibles?
Qu funcionalidades del sistema quedan
restringidas a ciertas clases de usuarios?
Qu chequeos se establecen para asegurar
que el usuario est trabajando en un entorno
seguro?

Qu tems cuando son eliminados, se

mantienen almacenados en un tarro de
basura? Qu usuarios pueden acceder al
tarro de basura? Cunto tiempo? Pueden
reestablecerse? Qu usuarios pueden
reestablecerlos?

Con qu frecuencia se ejecuta el software

para detectar virus?

Niveles de privilegio para usuarios (usuario

comn, usuario ocasional, administrador) y
control de acceso para cada nivel.

Nivel de privacidad para los datos (ver,

copiar, imprimir, modificar, borrar)

Mecanismos de identificacin y
autenticacin (contraseas, frecuencia de
cambios, recuperacin de contrasea,
mximo de intentos fallidos, computadora
no reconocida)
Mecanismos de seguridad de red (firewall),
encriptacin y auditorias

SEG-1. El sistema debe bloquear al usuario

despus de cuatro intentos SEGUIDOS y fallidos
de ingresar.
SEG-2. El sistema debe reportar al administrador
todos los intentos fallidos de acceder a datos sin
disponer de los privilegios necesarios.
SEG-3. El usuario debe modificar la contrasea
que le asign el administrador en el momento de
registrarlo, antes de comenzar a usar el sistema.

SEG-4. Cuando una puerta se desbloquea al

usar una tarjeta electrnica, permanece
desbloqueada 8 segundos.

SEG-5. Solo los auditores tienen acceso a

informacin histrica.

Cul es el tiempo promedio para que un

usuario entrenado complete una tarea?
Cul es el tiempo promedio para que un
usuario complete el entrenamiento que le
permita realizar sus tareas bsicas?
Cuntas transacciones puede completar un
usuario en un tiempo dado?
Cuntas interacciones (clicks, teclas, toques)
se requieren para realizar una tarea?

Cunto tiempo transcurre entre dos

solicitudes de ayuda de un usuario?
Qu porcentaje de tareas puede realizar el
usuario sin pedir ayuda?
Cuntos mensajes de error recibe el usuario
mientras realiza su tarea?
Cuntas pantallas visita el usuario hasta que
encuentra la que busca?
En todos los casos no se est evaluando al
usuario, sino al sistema

USA-1. Completar un formulario de pedido a

un proveedor debera demandarle a un
usuario entrenado entre 3 y 5 minutos, en el
95% de los casos
USA-2. Todas las funciones de la pestaa
Archivo deben tener asociada una tecla en
cortocircuito consistente con las establecidas
en el standard de Microsoft

Cul es el mximo nmero de usuarios

simultneos que tendr el sistema
inicialmente?
Cunto puede llegar a crecer ese nmero?
En cada uno de los indicadores de
performance, a partir de qu valor se
comprometen los objetivos del negocios?

EFI-1. Al menos un 30% de la capacidad de

procesador y de la memoria disponible deben
permanecer sin usarse en condiciones normales, para
asegurar que el sistema pueda atender un pico de
carga
EFI-2. El sistema debe notificar al operador cuando se
est utilizando ms del 80% de la capacidad de carga
mxima planificada.
Observemos que estamos hablando de un operador,
probablemente un tcnico con capacidad de
interpretar y actuar ante la notificacin

MOD-1. Cada bloque de cdigo tiene un nico punto

de entrada y un nico punto de salida.
MOD-2. Cada servicio proviso por una clase incluye
un comentario que describe su funcionalidad, sus
requisitos y responsabilidades.
MOD-3. Cada atributo de una clase queda
encapsulado de modo que solo es accesible en la
clase y sus clases derivadas.

Sobre qu plataformas se ejecutar el

software?
Qu partes del software tienen mayores
requerimientos de portabilidad?
Qu datos o componentes deben tener la
capacidad de migrar con o intervencin del
usuario?

POR-1. Modificar una aplicacin desarrollada

para iPhone para que se ejecute en Android
debera requerir cambiar menos del 10% de
las lneas de cdigo.
POR-2. El usuario debera poder importar su
libro de marcadores de Chrome a Safari
POR-3. La plataforma debera brindar una
herramienta para migrar los perfiles
personalizados sin intervencin del usuario.

un glosario
un repositorio de reglas de negocio
un patrn de diseo
una arquitectura
un mdulo de cdigo
un diagrama de conceptos
una pieza de testing
un modelo de datos
un documento que describe los perfiles de
los usuarios

En general el analista no pregunta

directamente al usuario respecto a las
oportunidades de reuso, sino que analiza
los documentos del sistema actual, de los
sistemas previos y de otros sistemas
relacionados para evaluar qu componentes
pueden reusarse.

REU-1. El 50% de modelo de datos desarrollado para

el sistema de farmacia de un hospital puede
reusarse en el sistemas desarrollados para soportar
actividades de investigacin en los servicios
mdicos.
REU-2. Al menos un 60% de las representaciones
visuales desarrollados para modelar un sistema de
liquidacin de sueldos desarrollado para una fbrica
de alimentos balanceados van a ser reusados
durante el anlisis y diseo de un sistema de
liquidacin de sueldos de un instituto de
investigacin.

REU-3. Los algoritmos de insercin, eliminacin y

bsquedas en estructuras de datos van a ser
reusados en todas las aplicaciones desarrolladas por
la empresa.

El analista puede desarrollar requerimientos

pensando en que puedan ser reusados.
Sin embargo, debe cuidar que ese objetivo
no comprometa la planificacin del
proyecto actual.
El diseador y el desarrollador tienen
mayores posibilidades de percibir
oportunidades de reuso y aprovecharlas.

Especificar el perfil de algunas personas que

no son participantes relevantes para el
producto que se est desarrollando pensando
en un modelo completo y reusable, puede
afectar al plan de desarrollo
Elaborar durante el desarrollo de
requerimientos un diagrama con la
expectativa de que pueda ser reusado puede
provocar que el modelo no se ajuste
adecuadamente al problema actual.

Incrementar la capacidad de la red

Adquirir ms servidores y computadoras
ms veloces
Aumentar la capacidad de almacenamiento

distribuir el cmputo entre varios

procesadores
comprimir datos
optimizar algoritmos

El analista debe conocer el plan de expansin

de la organizacin
El presidente de la empresa, el directorio o
los niveles gerenciales son responsables de
brindar estos aspectos
El analista como siempre es responsable de
requerirlos.

Cunto puede llegar a crecer el nmero de

usuarios que acceden simultneamente al
sistema en los prximos meses o aos?
A cuntos usuarios debera adaptarse el
sistema sin afectar la performance y sin
cambios de software o de hardware?
Cunto puede llegar a crecer el volumen de
datos en los prximos meses o aos?

SCA-1. La capacidad de un sistema de control de

activaciones y desactivaciones de alarmas debe tener
la capacidad de crecer de 500 llamadas por da a 800
llamadas por da.
SCA-2. Un sitio web debe tener la capacidad de
aumentar en un 30% el nmero de pginas por
bimestre sin que el usuario perciba cambios durante
dos aos
SCA-3. El sistema diseado para gestionar la central y
dos sucursales debe permitir duplicar el nmero de
sucursales sin afectar los procesos.

Muchos sitios web de comercio electrnico

no estn preparados para soportar el
crecimiento de usuarios que se produce los
das de oferta o promocin.
El acceso a los catlogos y los pagos con
tarjeta colapsan cuando el nmero de
usuarios se multiplica por 3, 4 o incluso ms.
Claramente es difcil anticipar el aumento de
usuarios y transacciones durante estos das y
ms difcil aun soportar estos requerimientos
con recursos planificados para otra escala.

Ante los reclamos de mal funcionamiento

muchas empresas deciden deshabilitar el
sistema comprometiendo la disponibilidad.
La confiabilidad suele verse tambin afectada
antes crecimientos inesperados en el nmero
de transacciones.
Los ciberdelincuentes aprovechan estas
oportunidades para encontrar resquicios en
la seguridad.

Cmo se puede confirmar que un algoritmo

produce el resultado esperado?
Existen algoritmos no determinsticos que
aumentan la dificultad de confirmar el
resultado?
Es posible definir un conjunto de datos que
tenga alta probabilidad de detectar errores,
si existen?

VER-1. El entorno operativo en el que se

realiza la verificacin debe ser idntico al
que se usar cuando el sistema est en
funcionamiento.
VER-2. El tester debe permitir configurar los
parmetros establecidos en el Anexo I y
generar un reporte con todas las lneas de
cdigo ejecutadas durante la verificacin.

Cada factor de calidad va a derivar en uno o

varios requerimientos funcionales y
probablemente requerimientos para los
datos.
El analista es responsable de derivar
requerimientos funcionales, en ocasiones en
forma directa y en otros casos
indirectamente, a partir de decisiones
tomadas por el diseador.

Un nivel importante de usabilidad exige

derivar requerimientos funcionales
vinculados a la interface de usuario, que
faciliten el entrenamiento y el uso del
sistema:
Asistentes y menes basados en el contexto
Barra de herramientas
Autocompletado de cambios
Autocorreccin de errores

El diseador de un equipo de diagnstico

puede requerir de una batera adicional para
asegurar disponibilidad
El analista deriva el requerimiento funcional
que consisten en informar al operador que la
batera comenz a usarse y cunto tiempo
permitir mantener el equipo en
funcionamiento

Algunos factores de calidad son

particularmente importantes en algunos tipos
de proyectos:
Sistemas Embebidos: Performance, eficiencia,
confiabilidad, robustez, seguridad,
usabilidad.
Aplicaciones corporativas: disponibilidad,
integridad, interoperatibilidad, performance,
escalabilidad, seguridad, usabilidad.
Aplicaciones para dispositivos mviles:
performance, seguridad, Usabilidad

Una restriccin limita las alternativas de

decisin del diseador y el resto del equipo
de desarrollo.
Las restricciones pueden ser impuestas por
participantes externos, por otros sistemas
que interactan con el que se est
construyendo o por otras etapas del ciclo de
vida del sistema, como por ejemplo una
transicin o actividad de mantenimiento.

Acuerdos existentes en la organizacin,

decisiones gerenciales, administrativas o
tcnicas.
Utilizar o utilizar una tecnologa especfica,
herramientas, lenguajes, sistemas de bases
de datos.
Considerar el sistema operativo o
plataforma que conforma el entorno para el
producto. (por ejemplo web browser)

Notaciones para el diseo o estndares de

codificacin que hay que mantener. Por
ejemplo modelar usando diagramas de
flujos de datos y una codificacin
alfanumrica especfica para los
requerimientos.
Compatibilidad con sistemas previos o
potenciales, especialmente convertir datos
entre distintos formatos.

Compatibilidad con otros sistemas con los

que el sistema debe comunicarse, formatos
de los archivos, protocolos de interaccin.
Limitaciones impuestas por reglas internas
o externas, por ejemplo formatos de los
listados, tipo de papel

Restricciones sobre el hardware tales como

tamao de memoria, velocidad del
procesador, costos.
Restricciones fsicas provocadas por el
entorno operativo o por caractersticas o
limitaciones de los usuarios.
Restricciones provocadas por el tamao de
la pantalla, en particular en los dispositivos
mviles.

Convenciones cuando se extiende o

modifica un sistema y se requiere mantener
las mismas caractersticas en la interface de
usuario.
Formatos estndar para intercambiar datos.

El analista debe distinguir cundo se trata de

una propuesta del usuario, incluso una idea
que escapa al desarrollo de requerimientos y
corresponde ms bien al diseo de la
solucin, respecto a un requerimiento que
impone una restriccin.
El analista puede decidir que el usuario est
formulando una restriccin que debe
respetarse porque va a permitir alcanzar una
solucin adecuada.

Alternativamente el analista puede

descubrir que la verdadera necesidad del
usuario est implcita, la restriccin puede
ser una manera de satisfacerla, pero
puede haber otras mejores.
El analista debera preguntar por qu
tantas veces como sea necesario para
justificar la decisin de adoptar esa
restriccin.

Algunos autores consideran que los factores

de calidad son restricciones.
Wiegers opina que los requerimientos de
calidad son el origen de algunas decisiones
de diseo o implementacin.
Interoperatibilidad y usabilidad son fuentes
potenciales de restricciones de diseo.
La portabilidad impone restricciones sobre la
implementacin que debe ser desarrollada
considerando que pueda ser fcilmente
trasladada a otra plataforma o entorno.

CON-1. Un click en el nombre de la columna

modifica el ordenamiento de los items.
Impone un requerimiento para la GUI

CON-2.
El producto solo puede ser implementado
usando software de cdigo abierto
Restringe la implementacin

CON-3.
La aplicacin debe usar Microsoft .NET
framework 4.5.
Restriccin sobre la arquitectura

CON-4. ATMs contain only $20 bills. [physical

constraint]
El cajero electrnico solo puede contener 100
billetes

CON-5. Online payments may be made only

through PayPal. [design constraint]
El pago online solo puede hacerse a travs de
PayPal
Restriccin para el diseo

CON-6.
Todos los textos usados en la aplicacin se
almacenan como archivos XML
Restriccin sobre los datos

Por cada restriccin el analista debera

preguntar cul es la razn por la cul se
toma la decisin y analizar si detrs de
ese argumento hay un factor de calidad
que es el verdadero requerimiento a
satisfacer.

Por qu se impone la restriccin de usar

un software de cdigo abierto?
Quiz el verdadero requerimiento es
mejorar la extensibilidad.
Por qu se impone usar .NET?
Quiz el verdadero requerimiento es
lograr portabilidad.

La especificacin de requerimientos no
funcionales se incluye en el Documento de
especificacin de Requerimientos del Sistema
(SRS).
La especificacin va a ser usada por el mismo
analista para derivar requerimientos
funcionales y para los datos, por el diseador
y el desarrollador y por el responsable de
testing para verificar el sistema.

Documento de
Visin y Alcance

Requerimientos
Funcionales
Requerimientos
del Negocio

Requerimientos
para los Datos
Requerimientos
No Funcionales

Requerimientos
del Usuario

Modelo de CU

SRS