Embed Size (px)
Citation preview
Clase 15 Requerimientos No Funcionales
Sonia Rueda
Req del Negocio
Req no Funcionales
Req del Usuario
Req Funcionales
Req para los datos
Captura Análisis Especificación Validación
Requerimientos del Negocio
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 No Funcionales
Cada clase de usuarios puede requerir diferentes factores
de calidad y restricciones además de asignarle diferentes
prioridades, según sus tareas y su perspectiva.
Requerimientos del Usuario
Requerimientos No Funcionales
Requerimientos del Negocio
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 restricción, para identificar el factor de calidad implícito.
Requerimientos No Funcionales
Requerimientos del Negocio
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 cómo debe hacerlo.
Los factores de calidad son atributos que influyen en el nivel de satisfacción 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. Más allá de la clasificación que se adopte, es importante capturarlos antes de que se diseñe la solución y no cuando el producto se verifica
Externos son percibidos y valorados
por los usuarios
Internos no pueden observarse
durante la ejecución del sistema,
afectan únicamente al equipo de
desarrollo
Los factores de calidad externos describen características observables cuando el software está ejecutándose.
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 definición del criterio para medir la satisfacción.
Los factores de calidad Internos no son observables durante la ejecución del sistema.
Son propiedades que se perciben durante el desarrollo, verificación o mantenimiento, mientras que se implementa el código, 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 más críticas 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é períodos requiere disponibilidad y durante cuánto tiempo.
La disponibilidad está muy relacionada con confiabilidad y está fuertemente condicionada por la mantenibilidad que es una categoría de la modificabilidiad.
La disponibilidad de considerarse particularmente en sitios web, aplicaciones basadas en la nube y aplicaciones distribuidas geográficamente.
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 capacitación que requiere realizar las operaciones que permiten que el sistema pueda comenzar a usarse.
Por ejemplo descargar una aplicación 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 pérdida de información 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 también los
datos recibidos de otros sistemas.
Es necesario además controlar la recepción
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 cuánta capacidad tiene
el sistema para intercambiar servicios con otros
sistemas y con cuánta facilidad puede integrar a
otros dispositivos de hardware externos.
La principal cuestión 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 algún formato de intercambio de
datos estándar .
Es posible incluir una categoría 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 clasificación adoptada, el
analista debe elegir una categoría 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 irritación y rechazo por parte del usuario pero además puede poner en riesgo a las condiciones de seguridad.
Los requerimientos de performance afectan a las estrategias de diseño de software y a la selección 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 período de tiempo.
Los problemas de confiabilidad se producen cuando se ingresan datos no válidos, el código tiene errores, una componente no está disponible cuándo se la necesita, el hardware falla.
La confiabilidad está entonces íntimamente ligada a robustez y disponibilidad.
La confiabilidad está también 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 período
Promedio de tiempo entre fallas
Los requerimientos de confiabilidad deberían 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 catastrófico.
Por ejemplo si una transacción 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
válidos, 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 batería.
Una manera de que el sistema sea robusto es especificar condiciones de excepción 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 más difícil 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 daños 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 heterogéneo de usuarios.
Una alternativa para lograrlo es parametrizar algunas de las opciones.
La simplicidad se refiere a cuan fácil es un
sistema de aprender a usarse.
Son dos cualidades que pueden enfrentarse.
Para evitarlo el sistema debería 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 degradación 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 diseñador distribuye la computación y las funciones entre las componentes.
El usuario “piensa” la eficiencia en términos 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 diseño y la implementación para interpretarse, modificarse y extenderse.
Es un factor crítico en aplicaciones desarrolladas para entornos dinámicos, desarrolladas con un modelo de ciclo de vida incremental o iterativo.
Está muy ligada a mantenibilidad y verificabilidad.
Tipo de
Mantenimiento
Descripción
Correctivo Corrige defectos que no fueron detectados
en la verificación o no se consideraron
críticos.
Perfectivo Mejora algunas funcionalidades para
aumentar la satisfacción de las necesidades
del negocio nuevas o ya existentes.
Adaptativo Modifica el sistema en respuesta a cambios
en el entorno operativo, sin alterar su
funcionalidad.
Cuando el diseñador 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 diseño 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 metodologías rigurosas y estándares favorece la reusabilidad. Una componente reusable debe ser modular y estar documentada Una componente genérica tiene mayor posibilidad de ser reusada que una específica.
Los paquetes son componentes reusables y su utilización contribuye a implementar nuevos módulos de código reusables.
Idealmente una componente reusable debe ser independiente del entorno operativo de la aplicación para la cual fue desarrollada.
La reusabilidad es un factor difícil 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 aplicación de crecer para adaptarse a un mayor número de usuarios, datos, servidores, localizaciones geográficas, transacciones, etc. sin comprometer la performance o la correctitud.
Está relacionada con modificabilidad y robustez.
La robustez considera cómo se comporta el sistema cuando se excede el límite de su capacidad.
La verificabilidad se refiere a cómo 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 diseño de un software de testing requiere determinar las condiciones iniciales para la verificación, los datos de prueba y los resultados esperados.
La verificabilidad es un factor crítico si el producto incluye algoritmos complejos o existen dependencias entre las funcionalidades.
También es un factor importante cuando el producto va a sufrir cambios frecuentes, porque va a ser necesario controlar que los cambios no dañen la funcionalidad existente.
En un mundo ideal cada sistema debería alcanzar el máximo nivel posible de cada factor de calidad.
Un sistema debería ser accesible en todo momento, jamás fallar, brindar resultados inmediatos y correctos siempre, impedir cualquier intento de acceso no autorizado.
Sin embargo, algunos factores están enfrentados y no es posible maximizar todos simultáneamente.
Los factores de calidad sirven para diseñar los tests de verificación que permiten demostrar si el sistema exhibe las características que el usuario desea.
La valoración del analista puede ser muy diferente a la del usuario con relación a algunos factores.
Medibles directamente pueden cuantificarse. Es posible establecer una escala con valores mínimos y máximos.
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 módulos que requieran un mayor nivel de calidad en cierto factor que otras.
Por ejemplo, algunas partes deben ser muy fáciles de aprender a usar, otras muy eficientes.
La captura de los factores de calidad requiere un procedimiento riguroso de interacción 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?
Difícilmente el usuario pueda responderlas formuladas de este modo.
El analista guía al usuario en la exploración del proceso de negocios buscando cómo 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.
¿Cuál es el tiempo de respuesta que usted considera aceptable para que el sistema responda la consulta q1?
Es una pregunta adecuada, como también es útil incluir preguntas acerca del comportamiento inaceptable
¿Cuál 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 más difíciles de detectar, también son los que pueden tener más aspectos en común 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 técnicas 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 líder 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 precisión cómo 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 líder puede actuar en nombre de la clase o es necesario conocer la opinión 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 decisión 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 debería explicitar esta decisión.
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 demás
Una alternativa es “cruzar” cada par de factores requeridos y marcar cuál 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 precisión cuál es el criterio con el cual va a medirse su satisfacción.
El analista debe elegir cuidadosamente las preguntas que formulará al usuario porque las respuestas le permitirán elaborar la especificación.
La prioritización permite enfocar los encuentros de captura y derivar los requerimientos funcionales vinculados a los factores de calidad con mayor prioridad.
Además, 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, cuál elige? Integridad
< indica que el factor de la fila es el más importante, ˆindica que tiene prioridad el factor de la columna
El factor más 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 más 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 búsqueda de la solución 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 debería especificar toda la información necesaria para valorar cada factor.
El sistema debe ser amigable o El sistema debe estar disponible 24 hs al día los 7 días de la semana no son especificaciones de requerimientos adecuadas. La primera es muy subjetiva e imprecisa. La segunda especificación es bien objetiva y precisa, pero probablemente demasiado ambiciosa. Ninguno permite que el diseñador y el desarrollador tomen decisiones.
Identificador Prefijo que indica el tipo de requerimiento y número unívoco dentro del tipo.
Descripción Breve
Unidad de medida Para los Rangos de valores
Medición/test Procedimiento de medición 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
Descripción de situaciones excepcionales
Rango de valores aceptables en cada situación excepcional
precisos y específicos
medibles
relevantes
accesibles
sensibles al tiempo
¿Qué funcionalidades son más críticas y requieren mayor disponibilidad?
¿Qué consecuencias puede provocar que la disponibilidad del sistema no satisfaga los requerimientos especificados?
¿En qué horarios y días resulta más adecuado planificar las tareas de mantenimiento que afecten a la disponibilidad del sistema? ¿Cuál es la duración máxima tolerable?
¿Cuál es la duración máxima tolerable para un mantenimiento no programado? ¿Cómo se van a manejar los intentos de acceso de los usuarios durante los períodos de mantenimiento programado y no programado?
¿Cómo 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 sería tolerable sobre la confiabilidad y la performance?
¿Cómo podría reducirse el impacto?
¿Qué dependencias existen sobre las funcionalidades que afectan a la disponibilidad?
Por ejemplo si no está funcionando la opción que permite autorizar pagos con tarjeta, el pago con tarjeta no puede estar disponible.
Sí podría 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 especificación 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 especificación más precisa exigiría indicar cuál es la expectativa entre las 20 hs de un día y las 8 hs de la siguiente.
En el caso de que no se aplique a todas las funcionalidades, es necesario indicar a cuáles se refiere.
Disp-2 No se aplicará penalidad cuando se realicen tareas de mantenimiento planificadas con al menos 24 hs de anticipación, para el horario comprendido entre las 21 hs de un día y las 7 hs. del día siguiente.
Instalación inicial Recuperarse de una instalación
incompleta Reinstalar
Instalar una nueva versión Instalar nuevas componentes Retomar una instalación anterior Desinstalar
¿Cuántos minutos debería demandarle a un operador capacitado realizar una instalación completa?
¿Qué operaciones de instalación pueden realizarse sin afectar el trabajo de los usuarios?
¿Qué operaciones de instalación requieren reiniciar el dispositivo?
¿Qué controles pueden realizarse para verificar el éxito de la instalación?
¿Qué usuarios están autorizados para realizar cada una de las operaciones vinculadas con la instalación?
INS-1. Un usuario sin entrenamiento en este sistema específico, pero que ha instalado utilitarios de Microsoft, debe ser capaz de completar la instalación del producto en menos de 10 m. INS-2. Cuando se instala una nueva versión del producto se guardan todos los perfiles personalizados del usuario y se permite que se restauren al terminan la instalación o posteriormente.
INS-3. El programa de instalación verifica que se dispongan de recursos suficientes antes de comenzar la instalación, incluyendo la carga de la batería. INS-4. El usuario que realiza la instalación debe tener privilegios para hacerlo. INS-5. Todos los archivos temporarios que genera el programa de instalación se borran si se completa la instalación satisfactoriamente.
Daños físicos 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. Después 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 código 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 intercambiarán?
¿En qué formato deben realizarse los intercambios?
¿Qué dispositivos de hardware deben interconectarse?
¿Qué protocolo de comunicación se utilizará en cada caso?
¿Qué otros requerimientos impone el sistema con el que se realiza la comunicación?
IOP-1. Cada farmacia de Bahía Blanca debe poder intercambiar información con los sistemas de las droguerías que les proveen fármacos y otros artículos. IOP-2. La farmacia importa datos de la droguería usando la notación SMILES. Este requerimiento de alguna manera se deriva del anterior. Si el usuario especifica este último el analista debería preguntar por qué para obtener la verdadera razón, que en este caso hemos formulado en primer lugar.
Tiempo de respuesta Número de segundos para mostrar
una página web
Capacidad de procesamiento Cantidad de transacciones de la
tarjeta de crédito procesadas por
segundo
Capacidad de almacenamiento
para datos
Número máximo de registros en
una base de datos
Capacidad dinámica Número Máximo de usuarios
simultáneos en una red social
Predictibilidad Tiempo entre que se produce un
evento y se detecta
Latencia Tiempo entre que se detecta un
evento y comienza a ejecutarse la
acción que lo atiende.
Comportamiento en condiciones
de sobrecarga
Sistema telefónico ante un
desastre climático.
Cuando se especifica un requerimiento de performance incluir también en la documentación el argumento que justifica el requerimiento para guiar al desarrollador en la implementación.
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 transacción se registra en la BD y sus espejos.
La mayoría de los usuarios no van a poder contestar las preguntas del analista referidas al número 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.
¿Cuál es el tiempo de respuesta que usted considera adecuado para que el sistema responda la consulta q1?
¿Cuántos usuarios en promedio podrían estar usando simultáneamente el sistema?
¿Cuál es el número máximo de usuarios que el sistema debería poder llegar a atender simultáneamente?
¿Cuál es el horario del día, el día de la semana o la época del año en la que se espera un uso más intenso?
PER-1. Cuando un cliente intenta acceder a un cajero electrónico el sistema debe autorizar o denegar el acceso en a lo sumo 2 segundos PER-2. Una página web debe descargarse en menos de 3 segundo en una conexión 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 después de completarse. (respuesta correcta o incorrecta)
¿Cuánto tiempo debería transcurrir como mínimo entre fallas?
¿Qué tarea estaría dispuesto a rehacer el usuario ante una falla?
¿Qué tareas no pueden repetirse si se produce una falla?
¿Qué funcionalidades del sistema deberían ser superconfiables?
¿Cuánto tiempo puede estar caído el sistema sin afectar significativamente el negocio?
Con-1. En un laboratorio de un centro de investigación se especifica que no más 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 debería fallar a lo sumo cada 90 días.
No hay modo de asegurar que el sistema satisface el requerimiento hasta que transcurren 90 días y aun así puede fallar el día 91 y 92.
El usuario debería 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 acción de autoguardado cada 3 minutos.
ROB-2. Cada parámetro de impresión debe tener valores por omisión
Tamaño de papel, márgenes, 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?
¿Cómo 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 más de 5 grados C por minuto, el sistema apagará la fuente de calor y notificará al operador. SAF-3. Un aparato para hacer radiografías solo puede ser utilizado si el filtro está colocadorcorrectamente.
¿Cuáles son los datos “sensibles”?
¿Quiénes están 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? ¿Cuánto tiempo? ¿Pueden reestablecerse? ¿Qué usuarios pueden reestablecerlos?
¿Con qué frecuencia se ejecuta el software para detectar virus?
Niveles de privilegio para usuarios (usuario común, usuario ocasional, administrador) y control de acceso para cada nivel.
Nivel de privacidad para los datos (ver, copiar, imprimir, modificar, borrar)
Mecanismos de identificación y autenticación (contraseñas, frecuencia de cambios, recuperación de contraseña, máximo de intentos fallidos, computadora no reconocida)
Mecanismos de seguridad de red (firewall), encriptación y auditorias
SEG-1. El sistema debe bloquear al usuario después 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 contraseña 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 electrónica, permanece desbloqueada 8 segundos.
SEG-5. Solo los auditores tienen acceso a información histórica.
¿Cuál es el tiempo promedio para que un usuario entrenado complete una tarea? ¿Cuál es el tiempo promedio para que un usuario complete el entrenamiento que le permita realizar sus tareas básicas? ¿Cuántas transacciones puede completar un usuario en un tiempo dado? ¿Cuántas interacciones (clicks, teclas, toques) se requieren para realizar una tarea?
¿Cuánto tiempo transcurre entre dos solicitudes de ayuda de un usuario? ¿Qué porcentaje de tareas puede realizar el usuario sin pedir ayuda? ¿Cuántos mensajes de error recibe el usuario mientras realiza su tarea? ¿Cuántas 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 debería demandarle a un usuario entrenado entre 3 y 5 minutos, en el 95% de los casos USA-2. Todas las funciones de la pestaña Archivo deben tener asociada una tecla en cortocircuito consistente con las establecidas en el standard de Microsoft
¿Cuál es el máximo número de usuarios simultáneos que tendrá el sistema inicialmente?
¿Cuánto puede llegar a crecer ese número?
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 más del 80% de la capacidad de carga máxima planificada.
Observemos que estamos hablando de un operador, probablemente un técnico con capacidad de interpretar y actuar ante la notificación
MOD-1. Cada bloque de código 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 intervención del usuario?
POR-1. Modificar una aplicación desarrollada para iPhone para que se ejecute en Android debería requerir cambiar menos del 10% de las líneas de código. POR-2. El usuario debería poder importar su libro de marcadores de Chrome a Safari POR-3. La plataforma debería brindar una herramienta para migrar los perfiles personalizados sin intervención del usuario.
un glosario un repositorio de reglas de negocio un patrón de diseño una arquitectura un módulo de código 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 investigación en los servicios médicos. REU-2. Al menos un 60% de las representaciones visuales desarrollados para modelar un sistema de liquidación de sueldos desarrollado para una fábrica de alimentos balanceados van a ser reusados durante el análisis y diseño de un sistema de liquidación de sueldos de un instituto de investigación.
REU-3. Los algoritmos de inserción, eliminación y búsquedas 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 planificación del proyecto actual.
El diseñador 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 más servidores y computadoras más veloces
Aumentar la capacidad de almacenamiento
distribuir el cómputo entre varios procesadores
comprimir datos
optimizar algoritmos
El analista debe conocer el plan de expansión de la organización
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.
¿Cuánto puede llegar a crecer el número de usuarios que acceden simultáneamente al sistema en los próximos meses o años?
¿A cuántos usuarios debería adaptarse el sistema sin afectar la performance y sin cambios de software o de hardware?
¿Cuánto puede llegar a crecer el volumen de datos en los próximos meses o años?
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 día a 800 llamadas por día. SCA-2. Un sitio web debe tener la capacidad de aumentar en un 30% el número de páginas por bimestre sin que el usuario perciba cambios durante dos años SCA-3. El sistema diseñado para gestionar la central y dos sucursales debe permitir duplicar el número de sucursales sin afectar los procesos.
Muchos sitios web de comercio electrónico no están preparados para soportar el crecimiento de usuarios que se produce los días de oferta o promoción. El acceso a los catálogos y los pagos con tarjeta colapsan cuando el número de usuarios se multiplica por 3, 4 o incluso más. Claramente es difícil anticipar el aumento de usuarios y transacciones durante estos días y más difícil 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 también afectada antes crecimientos inesperados en el número de transacciones.
Los ciberdelincuentes aprovechan estas oportunidades para encontrar resquicios en la seguridad.
¿Cómo se puede confirmar que un algoritmo produce el resultado esperado?
¿Existen algoritmos no determinísticos 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 verificación debe ser idéntico al que se usará cuando el sistema esté en funcionamiento. VER-2. El tester debe permitir configurar los parámetros establecidos en el Anexo I y generar un reporte con todas las líneas de código ejecutadas durante la verificación.
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 diseñador.
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 menúes basados en el contexto Barra de herramientas Autocompletado de cambios
Autocorrección de errores
El diseñador de un equipo de diagnóstico puede requerir de una batería adicional para asegurar disponibilidad
El analista deriva el requerimiento funcional que consisten en informar al operador que la batería comenzó a usarse y cuánto 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 móviles: performance, seguridad, Usabilidad
Una restricción limita las alternativas de decisión del diseñador y el resto del equipo de desarrollo.
Las restricciones pueden ser impuestas por participantes externos, por otros sistemas que interactúan con el que se está construyendo o por otras etapas del ciclo de vida del sistema, como por ejemplo una transición o actividad de mantenimiento.
Acuerdos existentes en la organización, decisiones gerenciales, administrativas o técnicas.
Utilizar o utilizar una tecnología específica, 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 diseño o estándares de codificación que hay que mantener. Por ejemplo modelar usando diagramas de flujos de datos y una codificación alfanumérica específica 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 interacción.
Limitaciones impuestas por reglas internas o externas, por ejemplo formatos de los listados, tipo de papel
Restricciones sobre el hardware tales como tamaño de memoria, velocidad del procesador, costos.
Restricciones físicas provocadas por el entorno operativo o por características o limitaciones de los usuarios.
Restricciones provocadas por el tamaño de la pantalla, en particular en los dispositivos móviles.
Convenciones cuando se extiende o modifica un sistema y se requiere mantener las mismas características en la interface de usuario.
Formatos estándar para intercambiar datos.
El analista debe distinguir cuándo se trata de una propuesta del usuario, incluso una idea que escapa al desarrollo de requerimientos y corresponde más bien al diseño de la solución, respecto a un requerimiento que impone una restricción.
El analista puede decidir que el usuario está formulando una restricción que debe respetarse porque va a permitir alcanzar una solución adecuada.
Alternativamente el analista puede descubrir que la verdadera necesidad del usuario está implícita, la restricción puede ser una manera de satisfacerla, pero puede haber otras mejores.
El analista debería preguntar por qué tantas veces como sea necesario para justificar la decisión de adoptar “esa” restricción.
Algunos autores consideran que los factores de calidad son restricciones. Wiegers opina que los requerimientos de calidad son el origen de algunas decisiones de diseño o implementación.
Interoperatibilidad y usabilidad son fuentes potenciales de restricciones de diseño.
La portabilidad impone restricciones sobre la implementación que debe ser desarrollada considerando que pueda ser fácilmente 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 código abierto Restringe la implementación CON-3. La aplicación debe usar Microsoft .NET framework 4.5. Restricción sobre la arquitectura CON-4. ATMs contain only $20 bills. [physical constraint] El cajero electrónico solo puede contener 100 billetes
CON-5. Online payments may be made only through PayPal. [design constraint] El pago online solo puede hacerse a través de PayPal Restricción para el diseño CON-6. Todos los textos usados en la aplicación se almacenan como archivos XML Restricción sobre los datos
Por cada restricción el analista debería preguntar cuál es la razón por la cuál se toma la decisión y analizar si detrás de ese argumento hay un factor de calidad que es el verdadero requerimiento a satisfacer.
¿Por qué se impone la restricción de usar un software de código abierto? Quizá el verdadero requerimiento es mejorar la extensibilidad.
¿Por qué se impone usar .NET? Quizá el verdadero requerimiento es lograr portabilidad.
La especificación de requerimientos no funcionales se incluye en el Documento de especificación de Requerimientos del Sistema (SRS).
La especificación va a ser usada por el mismo analista para derivar requerimientos funcionales y para los datos, por el diseñador y el desarrollador y por el responsable de testing para verificar el sistema.
Requerimientos del Negocio
Documento de Visión y Alcance
Modelo de CU
Requerimientos del Usuario
Requerimientos No Funcionales
Requerimientos Funcionales
Requerimientos para los Datos
SRS
