Directriz: Especificación de requisitos de software
La especificación de requisitos de software (SRS) se centra en la recopilación y la organización de todos los requisitos que envuelven el proyecto. En esta directriz se explica cómo desarrollar un SRS.
Relaciones
Descripción principal

Explicación

La especificación de requisitos de software (SRS) se centra en la recopilación y la organización de todos los requisitos que envuelven el proyecto. Si dispone de un plan de gestión de requisitos, debe consultarlo para determinar la organización y la ubicación correcta de los requisitos. Por ejemplo, quizá sea aconsejable tener un SRS separado para describir los requisitos de software completos para cada característica en un release determinado del producto. Puede incluir varios casos de uso del modelo de caso de uso del sistema para describir los requisitos de funcionamiento de dicha característica, junto con el conjunto adecuado de requisitos detallados en especificaciones suplementarias.

Puesto que es posible que se encuentre con varias herramientas diferentes para recopilar los requisitos, es importante que sepa que la recopilación de requisitos se puede encontrar en varias herramientas y artefactos distintos. Por ejemplo, quizá le resulte adecuado recopilar requisitos textuales, tales como requisitos no funcionales o restricciones de diseño, entre otros, con una herramienta de documentación de texto en especificaciones suplementarias. Por otra parte, le puede resultar útil recopilar algunos (o todos) los requisitos de funcionamiento en los casos de uso , y le puede venir bien utilizar una herramienta adecuada para definir el modelo de caso de uso .

¿Un documento o un paquete?

Parece que no existe una razón de peso para tratar las diferencias entre las herramientas utilizadas. Al fin y al cabo, va a recopilar requisitos y, en realidad, se va a centrar en la organización y la recogida eficaz de los requisitos sin tener en cuenta las herramientas que maneja. Puesto que se van a tratar los requisitos y no las herramientas, se da por supuesto que la recogida de requisitos en SRS constituye un paquete  de información. La elaboración de los distintos requisitos para el sistema se representa en un paquete que se denomina especificación de requisitos de software (SRS).

De Visión a SRS

Obviamente, el paquete SRS está relacionado con el documento Visión. En realidad, el documento Visión sirve como la entrada a SRS. Pero ambos artefactos sirven para necesidades diferentes y, por lo general, los escriben autores diferentes. En esta fase del proyecto, el centro del proyecto se mueve de la sentencia general de las necesidades, metas y objetivos del usuario, características y mercados de destino del sistema, a los detalles sobre el modo en el que se van a implementar dichas características en la solución.

Lo que se necesita ahora es una recopilación o paquete de artefactos que describa el comportamiento externo completo del sistema, es decir, un paquete que indique, específicamente, "Aquí se encuentra lo que debe realizar el sistema para entregar las características". Esto es a lo que se hace referencia como paquete SRS.

Un artefacto vivo

El paquete SRS no es un tomo congelado, creado para asegurar el cumplimiento con ISO 9000 y, a continuación, escondido en una esquina e ignorado mientras el proyecto continúa, sino que es un artefacto activo y vivo. En realidad, tiene múltiples usos cuando los desarrolladores se embarcan en su esfuerzo de implementación: sirve como una base de comunicación entre todas las partes, es decir, entre los desarrolladores en sí mismos, y entre los desarrolladores y los grupos externos (usuarios y otros interesados) con los que se deben comunicar. Formal o informalmente, representa un acuerdo contractual entre las distintas partes; si no se encuentra en el paquete SRS, los desarrolladores no deben trabajar en ello. Y, si está en el paquete SRS, son responsables de entregar dicha funcionalidad.

El estándar de referencia de los miembros del proyecto

SRS sirve como estándar de referencia del gestor de proyectos. Es poco probable que el gestor de proyectos disponga de tiempo, energía o formación para leer el código que generan los desarrolladores y compararlo directamente con el documento Visión. Debe utilizar el paquete SRS como referencia estándar para discusiones con el equipo del proyecto.

Tal como se ha indicado anteriormente, sirve como entrada para los grupos de implementación y diseño. En función de cómo se haya organizado el proyecto, los implementadores pueden estar implicados en las primeras tareas de definición de características y resolución de problemas que, finalmente, produce el documento Visión. Pero necesitan el paquete SRS para centrarse al tomar decisiones sobre lo que debe llevar a cabo su código. Sirve como entrada para los grupos QA y la prueba de software. Dichos grupos también se han implicado en algunas de las primeras discusiones y, obviamente, les ayuda a tener una comprensión adecuada de la "visión" trazada en los documentos de Visión. Pero su privilegio es crear guiones de prueba y procedimientos QA a fin de garantizar que el sistema desarrollado cumple, en realidad, los requisitos trazados en el paquete SRS. El paquete SRS también sirve como referencia estándar para sus tareas de prueba y planificación.

Definición de requisitos funcionales

Consulte los apartados Directriz: Modelo de caso de uso y Directriz: Caso de uso para obtener información detallada sobre la propuesta recomendada para definir requisitos funcionales en el modelo de caso de uso y los Casos de uso .

Definición de requisitos no funcionales

Los requisitos no funcionales del sistema se deben documentar en Producto de trabajo: Especificaciones suplementarias.  Para definir dichos requisitos, siga las directrices que se indican a continuación:

1 General

1.1 Suposiciones y problemas

Mientras recoge y valida requisitos no funcionales, mantenga listas de Suposiciones y problemas. 

Algunas tareas no ofrecen respuestas satisfactorias. Puede deberse a falta de información o, simplemente, debido a que se considera que la respuesta amenaza a la viabilidad del diseño. Por este motivo, cree dos listas y manténgalas a lo largo de todo el estudio del diseño:

Todas las suposiciones que se hacen durante los requisitos y el proceso de diseño, incluidos los procesos de reflexión o fundamentos que están detrás de dichas suposiciones. Los supuestos se pueden utilizar para identificar subproyectos relacionados o elementos de trabajo que se encuentran fuera del ámbito o después de este proyecto.

Todos los principales problemas (preocupaciones importantes que podrían convertirse en tapones)

Los problemas se deben revisar con el cliente al final de cada fase. Las suposiciones también se deben revisar al final de cada fase, pero es posible que el cliente no sea siempre la persona correcta para las menos importantes.

Las suposiciones y los problemas se aplican a todos los productos de trabajo, pero son especialmente comunes para los requisitos no funcionales.

1.2 Organización geográfica

Documente la organización geográfica del cliente.

Documente las ubicaciones geográficas de la parte empresarial a la que afecta este sistema. La definición también debe incluir los sitios no afectados, que albergan recursos de IT importantes. Preste una atención especial a cualquier componente de la organización que sea itinerante. Por ejemplo, el personal de ventas que viaja y utiliza estaciones de trabajo. Observe todas las ubicaciones geográficas a las que es posible que deba proporcionar soporte del idioma natural (NLS) especial.

2 Supuestos

2.1 ¿Paquetes de aplicaciones preseleccionadas?

¿Especifican los requisitos el uso de algún paquete de aplicaciones? Un "supuesto" muy importante que puede dictar con firmeza algunas de las decisiones de diseño del sistema es el uso de un paquete de aplicaciones específico que proporcione organización de datos y lógica de software predefinidos. Algunos paquetes de software son flexibles y permiten un alto nivel de personalización; otros son muy rígidos y no lo permiten. Los paquetes pueden dictar componentes y decisiones como, por ejemplo:

  • Tipo de estación de trabajo
  • Métodos de conexión
  • Procesador y tipo de DASD (dispositivo de almacenamiento de acceso directo)
  • Programa de control del sistema
  • Organización, ubicación y gestión de los datos
  • Lenguaje de programación
  • Interfaces de proceso por lotes
  • Relaciones del proceso y los datos
  • Lógica empresarial
  • Diseño de pantalla e interfaz de usuario
  • Características de rendimiento y disponibilidad
  • Cualquier arquitectura existente o necesaria para imprimir, tales como formatos de datos de impresión preferidos (por ejemplo, PostScript, PCL, IPDT)
  • Soporte del idioma nacional (NLS)

Es importante comprender las influencias que puede tener un paquete determinado en el diseño. Si dispone de un paquete determinado, asegúrese de que puede disponer de los conocimientos y la formación adecuada en relación con dicho paquete. Puede proceder de:

  • El proveedor del paquete
  • Consultores externos
  • Miembros del equipo de diseño formados específicamente para ello

No dé por supuesto que podrá disponer de los conocimientos en seguida. Asegúrese de que pueda disponer de ellos cuando los necesite.

2.2 Otros supuestos

Documente todos los demás supuestos en los requisitos que limiten la flexibilidad del diseño.

Capture todos los requisitos específicos que no se han tratado, explícitamente, en tareas anteriores y que puedan limitar la flexibilidad del diseño, por ejemplo, cualquiera de las siguientes:

  • Uso de imágenes del sistema operativo o procesadores existentes
  • Uso de equipo de estación de trabajo existente
  • Uso de una red existente
  • Uso de prácticas de gestión de sistemas existentes
  • Uso de un modelo específico como, por ejemplo: "debe utilizar un modelo cliente/servidor para el diseño que muestre claramente la lógica de acceso de datos/empresarial/presentación y dónde y cómo intercambian información".

¿Puede afectar alguno de estos supuestos al nuevo sistema? Si el nuevo sistema se va a ejecutar en una configuración de red, imagen del sistema operativo o procesador existentes, ¿pueden afectar las características de la plataforma existente y la carga de trabajo al nuevo sistema?

¿Cuánta capacidad de proceso y conexión han tomado ya las cargas de trabajo existentes?

¿Qué controles de seguridad utilizan las cargas de trabajo existentes? Anótelos y compruébelos en comparación con los requisitos de seguridad del nuevo sistema cuando considere éste último.

¿Cuáles son las características de disponibilidad de la carga de trabajo existente?

Anote cualquier aspecto que pueda afectar al diseño de disponibilidad del nuevo sistema. Por ejemplo, ¿insiste la carga de trabajo existente en concluir el conjunto de un procesador cada noche?

2.3 ¿Hardware especial?

¿Especifican los requisitos el uso de algún hardware especial?

Es posible que se haya establecido en términos genéricos ("el sistema debe dar soporte a un trazador flat-bed de alta velocidad"), o bien, que sean más específicos ("se da soporte a los cajeros automáticos Panda Corp"). Documente tanto como pueda:

  • Todos los requisitos previos de hardware o de software
  • Los proveedores y sus organizaciones de soporte
  • Las consideraciones de idioma nacional (NLS)
  • El equipo de cifrado
2.4 ¿Datos existentes?

¿Especifican los requisitos el uso de datos existentes? Si es así, este hecho influye en el diseño del sistema. Documente:

  • Los sistemas en los que existen los datos actualmente
  • La estructura (por ejemplo, archivo plano o relacional)
  • El tamaño
  • Qué usuarios y qué sistemas utilizan los datos en la actualidad
  • Consideraciones de disponibilidad (por ejemplo, períodos en los que los datos no están disponibles debido a tareas de proceso por lotes o mantenimiento de la base de datos)
  • ¿Se pueden mover o copiar dichos datos?

3 Estándares

3.1 Arquitectura técnica / Plan estratégico

¿Tiene el cliente una arquitectura técnica o plan estratégico de IT (o conjunto de estándares equivalente)?

Una arquitectura técnica es más o menos equivalente a lo siguiente:

  • Plataforma técnica empresarial
  • Infraestructura técnica empresarial
  • Arquitectura tecnológica

Es posible que en una arquitectura técnica se haya definido automáticamente lo siguiente:

  • El número y el uso de centros informáticos
  • La conectividad de red de la empresa (WAN)
  • La conectividad localizada de determinados establecimientos (LAN)
  • Servicios de infraestructura cliente/servidor (middleware)

Servicios de directorio y de denominación que realizan un seguimiento de los recursos y los atributos de la red
Servicios de seguridad que protegen los recursos de red contra el uso no autorizado por medio del registro de los usuarios y sus niveles de autorización
Servicios de tiempo que regulan la fecha y la hora a través de la red
Servicios de gestión de transacciones que coordinan la recuperación de los recursos a través de distintos sistemas de una red

  • Los métodos de desarrollo que va a utilizar las nuevas aplicaciones 
  • El conjunto aceptado de productos soportados como, por ejemplo:

· Hardware
· Software de control de sistemas
· Amplio software de aplicaciones, por ejemplo, "Office"
· Uso del escritorio de ayuda
· Reglas de seguridad

  • Arquitectura del subsistema de impresión

La lista puede ser muy extensa y los elementos de la misma se pueden vigilar sobre una base muy rígida, o bien, puede no imponer en absoluto.

Documente todos los requisitos que necesiten o excluyan, específicamente, el uso de subarquitecturas como, por ejemplo:

  • OSI o SNA
  • UNIX**
  • SAA
  • PS/2* con OS/2* EE.

Arquitecturas especiales que puede implicar el uso de una solución de aplicaciones empaquetada. Recuerde que algunos paquetes de aplicaciones son definiciones arquitectónicas independientes.

Documente el grado de apertura (es decir, interoperatividad e independencia del proveedor) que necesita el cliente. Si existe una arquitectura técnica, es casi indudable que el diseño deberá ajustarse a la misma. Debe leer y comprender las reglas que van a influir en el diseño del sistema.

3.2 Arquitectura de red

¿Tiene el cliente una arquitectura de red a la que se deba ajustar el sistema? Una arquitectura de red es un conjunto de reglas comunes para conectividad de alto nivel, además de una infraestructura de transporte común. Puede incluir una definición de una red troncal, incluidos concentradores y líneas. Si se trata de este tipo de arquitectura, comprenda la topología y las reglas esenciales y documente:

Consideraciones para la topología física (es decir, si la red es, básicamente, rural o urbana y si la conexión de red está densamente poblada en contraposición a distribuida libremente).

Nivel de funciones de conexión de alto nivel para las que ofrece soporte la infraestructura de red actual.

Estándares de comunicación utilizados (por ejemplo, SNA, OSI, TCP/IP) para dar soporte a las funciones de las conexiones.

Interfaces de programación a las que se da soporte.

Todas las definiciones de arquitectura de red de la conectividad entre las capas cliente/servidor o las capas del modelo de sistema de base, por ejemplo:

  • El acceso a datos relacionales entre estaciones de trabajo cliente y servidores relacionales LAN se debe llevar a cabo a través de los protocolos de un producto de base de datos relacional específico.
  • La lógica de presentación siempre debe estar en la estación de trabajo, y la lógica de acceso a los datos siempre se debe encontrar en un sistema principal centralizado.
3.3 Políticas de conexión

¿Tiene el cliente alguna política establecida para las conexiones?

Aunque no tenga arquitecturas técnicas o de red, es posible que tenga algunas políticas de conexión.

Documente todas las políticas relacionadas con:

  • La utilización de recursos de comunicación o protocolos determinados (para las conexiones con un único edificio o externas al edificio u organización).
  • Si no se requiere de forma implícita ningún protocolo determinado para dar soporte a software o equipos existentes.
  • Si se van a utilizar los recursos de conectividad física existentes (es decir, cableado, controladores periféricos o de red y recursos de portadora comunes). En el caso contrario, es posible que existan restricciones sobre el tipo de recursos físicos que se pueden utilizar (políticas, normativas gubernamentales, espacio físico, propiedad del local, implicación de terceras partes). Documéntelos.
  • Si es probable que se requiera la instalación o modificación de recursos físicos, quizá se necesite implicar a una o más terceras partes (por ejemplo, contratistas o portadoras comunes). Debe comprender cómo se va gestionar la contratación o la responsabilidad. Es especialmente importante si las interacciones empresariales van a implicar conexiones internacionales.
  • Soporte para usuarios itinerantes.
3.4 ¿Otras políticas?

¿Tiene el cliente otras políticas, estándares o reglas no establecidas, explícitamente, en los requisitos? Por ejemplo:

  • Se deben diseñar todas las nuevas interfaces de sistemas para los usuarios a principios orientados a objetos a fin de permitir acciones de arrastrar y soltar.
  • Todos los nuevos sistemas se deben basar en el modelo de aplicación cliente/servidor.
  • Todos los nuevos sistemas se deben definir con estándares abiertos.
  • Estándares y políticas para el soporte del idioma nacional (NLS), en especial, todo lo que relacionado con la operación de texto de izquierda a derecha.
  • Política de seguridad que defina la responsabilidad de gestión y los estándares para la autenticación de usuario, el control de acceso y la protección de los datos.
  • Estándares de intercambio de aplicaciones (por ejemplo, UNEDIFACT o VISA) que pueden implicar la utilización de equipo especial para la conexión o la seguridad.

Si existen otras políticas, asegúrese de que las comprende y tiene acceso a las mismas con el objeto de garantizar que el diseño cumple con los estándares en las fases siguientes del proceso de diseño. Es posible que la utilización de una solución de aplicaciones empaquetada conlleve estándares implícitos.

Podría ser la política que permita a los usuarios o departamentos añadir o desarrollar sus propios programas locales en:

  • Estaciones de trabajo
  • Servidores (en especial, uso del espacio en disco)

Es posible que sin controles observe que el uso local utiliza rápidamente recursos que necesitan los sistemas de producción para los que se han adquirido los componentes locales en origen, y quizá no pueda instalar el sistema de producción cuando esté, por fin, preparado para el despliegue.

4 Números

4.1 "Unidades de medida"

Trabaje con el personal de desarrollo de aplicaciones para dividir los procesos empresariales en unidades más granulares, por ejemplo, transacciones o procesos empresariales más pequeños.

El motivo para ello es que va a capturar números en la pregunta siguiente, y debe decidir lo que va a contar.

Tenga en cuenta que un proceso empresarial puede iniciar varias instancias de transacciones empresariales más pequeñas (por ejemplo, varios pedidos de elementos por pedido de cliente), y se deben recordar dichos multiplicadores al documentar los números. Sin embargo, no se deje atrapar con demasiados detalles, en especial, en el caso de un sistema complejo.

Normalmente, una "aplicación" (un término IT), o más de una aplicación, implementan un proceso "empresarial" (por ejemplo, "gestión de pedidos de clientes"). En cada aplicación hay, por lo general, varias "transacciones" IT, por ejemplo, "consultar nivel de existencias" o "generar carta de cliente".

Comunidades diferentes utilizan sus propios nombres para identificar las unidades que se están intentando convenir. Por ejemplo, "transacción" puede significar una cosa para personas que tengan un fondo de desarrollo de aplicaciones y otra cosa completamente diferentes para el equipo de la infraestructura. Es importante trabajar unidos a fin de correlacionar los nombres y recopilar la información.

4.2 "Tamaños y volúmenes empresariales"

Identifique y documente la información de tamaños y volúmenes para cada una de las unidades del punto 4.1: "Unidades de medida", por ejemplo:

  • Cuántos usuarios se espera que utilicen cada aplicación o proceso empresarial de promedio y en las horas punta
  • Cuándo se producen las puntas (por ejemplo, diaria, semanal o mensualmente, según proceda)
  • Cuál es el índice de proceso de las transacciones en las puntas o de media
  • Número de instancias y elementos de datos en cada grupo de datos y sus tamaños.
4.3 "Criterios de rendimiento del proceso empresarial"

Es posible que el cliente tenga criterios de rendimiento especificados para parte o todos los procesos empresariales. No obstante, no olvide documentar también los objetivos de rendimiento para los procesos de soporte del sistema (por ejemplo, una copia de seguridad del sistema) y procesos de desarrollo de aplicaciones, si se han identificado. Para cada categoría, documente:

  • Los requisitos de respuesta para cada categoría
  • Dónde se van a medir
  • Si se aceptan criterios diferentes en horas distintas (por ejemplo, fuera de las horas punta/durante la noche)
  • Si se deben cumplir los criterios durante la recuperación
  • Si se requiere una garantía de rendimiento
  • Si va a influir en una de las partes en caso de que no se cumplan los requisitos de rendimiento
  • Exprese las condiciones mínimas de rendimiento que se necesitan para que el proceso empresarial se considere disponible (es decir, el punto por debajo del cual se considera que el sistema "no está disponible", en lugar de "lento").
  • Si ya se ha elegido una solución de aplicaciones empaquetada, asegúrese de que tiene acceso a sus características de rendimiento. Es posible que no las necesite todas en este momento, pero debe conocer dónde obtenerlas, puesto que probablemente las necesite en futuras tareas. Por otra parte, es posible que las otras empresas tarden bastante en entregarle los números que necesita, de modo que solicíteselos ahora.

5 Disponibilidad

5.1 Consejo sobre disponibilidad

La propuesta que se recomienda para establecer los requisitos de disponibilidad es la siguiente:

  1. Identifique los usuarios verdaderos del sistema, los procesos empresariales que llevan a cabo y las horas a las que los usuarios realizan dichos procesos
  2. Analice el impacto de la disponibilidad (o la no disponibilidad) del servicio en base a la posibilidad de los usuarios para cumplir objetivos empresariales
  3. Especifique los requisitos de disponibilidad que reflejan directamente lo que necesitan los usuarios para cumplir sus objetivos empresariales
  4. Tenga en cuenta que si ya se ha elegido una solución de aplicaciones empaquetada, la estructura y el diseño de la misma pueden tener una influencia importante en las características de disponibilidad de la aplicación desde el punto de vista de los usuarios. Un paquete que no se ha diseñado para operar de modo continuado es difícil que funcione continuamente, en especial, en lo que respecta al mantenimiento y las ventanas de proceso por lotes.

Cuando desarrolle los requisitos de disponibilidad, considere las directrices siguientes:

  • En lugar de especificar requisitos "globales" para todo el sistema, especifique requisitos de disponibilidad en un nivel de granularidad inferior (por ejemplo, por proceso individual, grupo de usuarios o grupo de datos). lo que permite que el diseñador disponga de mayor flexibilidad para ajustarse a las necesidades de los usuarios. En especial, es importante para los sistemas que tienen un alto nivel de requisitos de disponibilidad continua.

Algunos ejemplos:

  • La sentencia "El sistema debe estar en funcionamiento 24 horas al día para ajustarse a los usuarios de Nueva York y Hong Kong" deja al diseñador mucha menos flexibilidad que la sentencia "Los usuarios de Nueva York deben poder realizar transacciones en SUS datos desde las 7AM hasta las 7PM, huso horario de Nueva York, y los usuarios de Hong Kong deben poder realizar transacciones en SUS datos desde las 7AM hasta las 7PM, huso horario de Hong Kong. En el segundo caso, el diseñador tiene flexibilidad para realizar el mantenimiento en los componentes del sistema o los datos de un huso horario mientras que el otro huso horario aún se encuentra en la mitad de su día de producción.
  • En una aplicación de cajeros automáticos, puede resultar crítica la aceptación de depósitos y la dispensación de dinero efectivo el lunes a las 3AM de la mañana, mientras que la posibilidad de facilitar saldos contables exactos a dicha hora pueden ser menos crítico.
  • Distinga entre las características de disponibilidad que ACONSEJABLES y las que son OBLIGATORIAS. Por ejemplo, "El cajera automático DEBE poder aceptar depósitos y dispensar dinero efectivo las 24 horas del día. Se ACONSEJA que el cajero automático facilite al cliente el saldo contable exacto las 24 horas del día; sin embargo, se pueden ajustar interrupciones fortuitas en el proceso de consulta de los saldos contables, pero DEBE TENER una duración inferior a 10 minutos y tener lugar entre las 3:00 y las 4:00 AM".
  • Si el impacto de no satisfacer un objetivo de disponibilidad concreto no se puede relacionar directamente con la disponibilidad de los usuarios para cumplir sus objetivos empresariales, es posible que el objetivo no sea el adecuado para establecerlo como requisito de disponibilidad para el sistema.
  • Los requisitos de disponibilidad que sólo reflejan indirectamente la disponibilidad como la percibe el usuario (por ejemplo, "La región de control IMS debe estar activada") tienden a no ser tan útiles como los que sí lo hacen (por ejemplo, "Los cajeros bancarios deben poder realizar procesos X e Y").
5.2 "Horas de servicio planificadas"

Para cada uno de los procesos empresariales y los grupos de usuarios que los deben realizar, identifique las horas durante las que el usuario debe poder realizar dicho proceso. Recuerde hacerlo también para los procesos que no están asociados directamente a los grupos de usuarios.

Si hay grupos de usuarios en husos horarios diferentes (por ejemplo, el descrito anteriormente en el ejemplo sobre Nueva York y Hong Kong), trátelos como grupos de usuarios separados.

Muestre también si habrá períodos esporádicos como, por ejemplo, vacaciones, en los que no se necesite la aplicación (lo que proporciona al diseñador la flexibilidad para utilizar dichos períodos para mantenimiento ampliado). ¿Qué cambios se prevén en las horas de servicio durante la vida proyectada de la aplicación?

También puede afectar a las horas de servicio de este sistema las de otros sistemas con los que intercambia información.

¿Cómo se espera que cambien las horas de servicio planificadas de este sistema durante su vida proyectada?

5.3 "Costes de interrupción del servicio"

Comprenda el IMPACTO EMPRESARIAL, los COSTES FINANCIEROS y los RIESGOS asociados a las interrupciones de servicio durante las horas de servicio planificadas.

Para identificar cuáles son los requisitos de disponibilidad realmente importantes para el sistema, considere el conjunto de grupos de usuarios y procesos empresariales e identifique el impacto empresarial que podría resultar debido a:

  • Una breve interrupción o período de tiempo de respuesta inaceptablemente lento durante las horas planificadas. Defina "breve" e "inaceptablemente lento" en la medida en que se refieren a esta aplicación particular (consulte el apartado "Criterios de rendimiento del proceso empresarial")
  • Varias interrupciones de mayor duración en el servicio durante las horas indicadas más arriba (por ejemplo, un minuto, unos minutos, 15 minutos, una hora, dos horas, cuatro horas).
  • Interrupciones prolongadas del servicio (por ejemplo, un turno, un día, varios días).
  • Tenga en cuenta también todos los procesos que no están asociados directamente a un grupo de usuarios (por ejemplo, compensación de cheques durante la noche).

Al valorar el impacto de cada interrupción, identifique los procedimientos de recuperación y considere cómo pueden reducir el impacto empresarial real de la interrupción.

Intente cuantificar el impacto en términos financieros (coste de la pérdida de productividad del equipo o del personal, valor de la pérdida empresarial actual, pérdida calculada empresarial futura debido a la insatisfacción del cliente, gastos de intereses o penalizaciones reglamentarias, entre otros)..

Proporcione tantas respuestas como sean necesarias con objeto de reflejar las diferencias en los costes y los riesgos asociados a interrupciones de distintas duraciones, a diferentes horas del día, si se han planificado o no o, por ejemplo, a qué procesos empresariales afectarían.

¿Cómo se prevé que cambie el impacto empresarial/financiero de una interrupción de servicio durante la vida proyectada del sistema?

Revise cada uno de los procesos empresariales importantes acordados para identificar alternativas que permitan que los elementos críticos de dichos procesos continúen en caso de que algunas partes del sistema no estén disponibles temporalmente. La posibilidad de operar temporalmente con funciones empresariales reducidas puede ser un procedimiento que ayude a reducir el impacto de disponibilidad de interdependencias entre datos y procesos críticos.

Algunos ejemplos:

  • FUNCIÓN COMPLETA 1 Leer y actualizar el registro de existencias.
  • FUNCIÓN REDUCIDA 1 Entrar actualización del registro de existencias y ponerlo en cola para la actualización futura.
  • FUNCIÓN COMPLETA 2 Leer el saldo más reciente del cliente.
  • FUNCIÓN REDUCIDA 2 Leer el saldo del cliente de un origen alternativo, que puede no estar actualizado.
  • FUNCIÓN COMPLETA 3 Actualizar el sistema a diario.
  • FUNCIÓN REDUCIDA 3 Actualizar la copia en papel impreso de diario.

Recuerde que cuando el sistema está en funcionamiento con funciones reducidas es posible que exista un límite de lo que puede ser aceptable para los procesos empresariales. Por ejemplo, un saldo obsoleto de cliente no puede estar obsoleto más de 24 horas.

Si el servicio se interrumpe durante las horas planificadas (consulte el apartado "Horas de servicio planificadas"), por lo general, el impacto de la interrupción varía en función de la duración de la interrupción, entre otras consideraciones. Algunas interrupciones puede tener un impacto mínimo en la disponibilidad de los usuarios para llevar a cabo sus procesos empresariales (interrupciones breves, las que tienen lugar durante períodos del día en los que se utilizan menos, las que afectan sólo a un subconjunto del grupo de usuarios, o bien, aquellas para las que existe un procedimiento de recuperación manual aceptable). Otras interrupciones como, por ejemplo, las que tienen mayor duración o se producen durante un período "crítico" del día, puede tener un mayor impacto. 

Algunos ejemplos:

  • Una interrupción breve de los procesos de control de la cadena de fabricación puede tener un impacto mínimo en la productividad, puesto que el trabajo continúa en base a los pedidos de trabajo impresos previamente y los cambios se pueden anotar de modo manual para entrarlos más tarde. Sin embargo, una interrupción cuya duración sea superior a sesenta minutos puede tener como resultado la suspensión del trabajo de la cadena para el resto del turno.
  • Una interrupción de un sistema de liquidación financiera de un volumen importante de dólares durante la última hora de las operaciones puede tener como resultado costes por pago de intereses y penalizaciones reglamentarias importantes.
  • En las respuestas de los departamentos de policía y bomberos frente a emergencias que amenazan a la vida se pueden continuar utilizando procedimientos de recuperación manual si el sistema de envío no está disponible. No obstante, los tiempos de respuesta se pueden incrementar y pueden amenazar vidas debido al aumento de carga de trabajo del despachador.
  • Una interrupción en un período punta del sistema de reservas de un hotel o aerolínea puede tener como resultado, no sólo una pérdida empresarial actual cuando los clientes llaman a un competidor para hacer sus reservas, sino también una pérdida empresarial futura, si los clientes se descontentan y la próxima vez que necesitan dichos servicios llaman antes a otra aerolínea u hotel.
5.4 "Criterios de recuperación y disponibilidad"

Identifique los CRITERIOS DE RECUPERACIÓN Y DISPONIBILIDAD que aplicar en situaciones "normales".

Excluya las situaciones de "desastre" como, por ejemplo, una pérdida o suspensión prolongada de todo el servicio informático.

Basado en los riesgos y los costes empresariales/financieros identificados en el apartado "Costes de interrupción del servicio", desarrolle una especificación de los criterios de disponibilidad que se deben cumplir para evitar que se impida en la medida de lo posible que grupos de usuarios realicen sus procesos empresariales asignados. Tales criterios se pueden especificar en formatos como los siguientes:

  • Porcentaje de interrupciones recuperadas en un número determinado de minutos/segundos
  • Tiempo máximo en una semana/mes/año determinado en el que el usuario no ha podido realizar una función concreta.

Sea tan específico como sea necesario a fin de reflejar factores como, por ejemplo, las diferencias entre las interrupciones planificadas y no planificadas, la hora durante la que se produce la interrupción (por ejemplo, períodos "críticos" en contraposición a períodos de menor utilización), si afecta a todos los usuarios o sólo a algunos usuarios, etc.

No especifique criterios de disponibilidad rigurosos innecesariamente, puesto que podría afectar considerablemente al coste de implementación. Por lo general, si no se pueden identificar riesgos o costes empresariales/financieros importantes con un conjunto de condiciones de interrupción determinado, puede indicar que el conjunto de condiciones de interrupción no se debe incluir en los criterios de disponibilidad establecidos.

Si las "Horas de servicio planificadas" sugieren que es probable que cambien las horas de servicio planificadas, o bien, los "Costes de interrupción del servicio" sugieren que es probable que cambien los riesgos o costes empresariales/financieros asociados a la interrupción del servicio durante la vida proyectada del sistema, calcule cómo pueden cambiar los criterios de disponibilidad.

Si se va a utilizar cifrado, existen consideraciones de disponibilidad y recuperación adicionales. Por ejemplo:

  • La posibilidad de recuperar información secreta que se puede mantener fuera del sistema.
  • La necesidad de garantizar que los datos protegidos por cifrado se recuperan en coordinación con la recuperación de las claves de cifrado adecuadas.
5.5 "¿Recuperación en caso de desastre?"

¿Se requiere recuperación en caso de desastre en el ámbito del proyecto de diseño (disponibilidad durante situaciones de "desastre" como, por ejemplo, una pérdida o suspensión prolongada de todo el servicio informático)? Si la respuesta es afirmativa, ¿cuáles son los criterios para la recuperación?

Tenga en cuenta que, probablemente, no todos los procesos empresariales requieran recursos de recuperación en caso de desastre. Seleccione sólo aquellos procesos que sean críticos y no requieran recuperación en caso de desastre e, incluso en dichos procesos, es posible que no se necesite abarcar todas las funciones.

  • ¿Con qué rapidez se debe restaurar el servicio? ¿Se ha medido a partir del momento en el que ha ocurrido el desastre o cuando se ha tomado la decisión de ir a un sitio remoto?
  • ¿Bajo qué condiciones decide la organización recuperar de un sitio remoto, en lugar de localmente?
  • ¿Qué nivel de actualización deben tener los datos del sitio remoto para que la empresa siga en funcionamiento (al segundo; unos minutos a partir de la anomalía, se aceptan los datos del día anterior)?
  • ¿Cuándo se ha recuperado primero el servicio desde le sitio remoto?
  • ¿En algún momento futuro?
  • ¿Cuál es la prioridad de recuperación del sitio remoto de este conjunto de aplicaciones en relación con las otras aplicaciones empresariales que dependen del mismo servicio informático?

Tenga en cuenta que puede haber conjuntos de criterios diferentes para partes distintas del sistema o en función del tipo de desastre.

¿Qué cambios de los requisitos de recuperación en caso de desastre anteriores se han previsto durante la vista proyectada de la aplicación?

5.6 "Otras consideraciones de diseño de disponibilidad"

Para diseñar un sistema que se recupere tan pronto como sea posible, el diseñador debe conocer la flexibilidad de la que dispone al implementar la aplicación, además de ajustarse a los requisitos de funcionamiento de la aplicación. A continuación se plantean algunas preguntas que pueden ayudar al diseñador:

1. Para ajustar las tareas de mantenimiento necesarias, el sistema puede funcionar en períodos breves durante los cuales puede:

a. ¿Realizar consultas, pero no actualizaciones?

b. ¿Aceptar solicitudes de actualización del usuario, pero no actualizar en realidad la base de datos hasta después de completar las tareas de mantenimiento?

2. Para una interrupción que requiera recuperación de datos, es más importante:

c. ¿Restaurar el servicio tan pronto como sea posible, aunque signifique utilizar datos que no se han actualizado completamente?, o bien:

d. ¿Recuperar todos los datos a su estado actual antes de restaurar el servicio, aunque se tarde más tiempo?

3. En caso de que un solicitud de usuario esté "en curso" en el momento de producirse la anomalía, ¿debe el usuario contar con volver a entrar la solicitud una vez que se ha recuperado el servicio?

4. ¿Existen consideraciones no técnicas que puedan afectar a la disponibilidad del sistema (por ejemplo, una política empresarial que indique que el proceso A no se debe poner a disposición de los usuarios a menos que el proceso B también esté disponible)?

¿Se espera que cambie alguna de las consideraciones de diseño anteriores con el tiempo?

Para procesos que son críticos a nivel empresarial, resulta útil identificar alternativas que permitan que los elementos más críticos de dichos procesos se mantengan en funcionamiento, aunque otras partes del sistema no estén disponibles temporalmente. La posibilidad de operar temporalmente con funciones empresariales reducidas puede ser un procedimiento que ayude a reducir el impacto de disponibilidad de interdependencias entre datos y procesos críticos.

6 Seguridad

6.1 "Requisitos de seguridad"

1. Identifique los datos que proteger

2. Identifique el tipo de amenazas a las que está expuesto cada tipo de datos:

  • Destrucción o daños accidentales
  • Destrucción o daños deliberados
  • Inteligencia comercial
  • Fraude
  • Piratas informáticos ("Hackers")
  • Virus

1. Identifique las amenazas a la seguridad física:

  • Robo de componentes
  • Acceso físico no autorizado
  • Seguridad física de los usuarios

2. Identifique las personas que pueden ser el origen de las amenazas:

  • Personal del centro de datos
  • Otro personal de IT (por ejemplo, desarrollo)
  • Personal que no es de IT de la organización
  • Personas ajenas a la organización

3. Identifique todos los requisitos de seguridad especiales o extraordinarios, en especial con respecto a:

  • Acceso al sistema
  • Cifrado de datos
  • Auditoría

4. ¿Existen políticas generales como, por ejemplo, documentos de Libertad de información, que puedan influir en el diseño de seguridad del sistema?

5. Algunas soluciones de aplicaciones empaquetadas tienen sus propios subsistemas de seguridad. Si dispone de un paquete "concreto", infórmese sobre sus servicios de seguridad.

Con el objeto de establecer y clasificar los requisitos de seguridad, es posible que desee utilizar la propuesta siguiente:

1. Liste los objetos que requieren protección por seguridad lógica o física.

2. Identifique la exposición adecuada a cada objeto. Las categorías típicas son las siguientes:

  • Acceso de visualización (vulneración de la confidencialidad), por ejemplo, información de cuenta, lista de clientes, patentes.
  • Acceso de actualización, es decir, modificación de los datos para fraude, encubrimiento, diversificación de fondos.
  • Pérdida de activos, es decir, otra persona se apodera de algo que ya no está disponible para el propietario (a diferencia de la pérdida debida a un desastre). Algunos ejemplos son las listas de clientes y candidatos probables, contratos, etc.

Tenga en cuenta que no todos los objetos son sensibles a todas las exposiciones anteriores.

3. Identifique todas las amenazas aplicables a su entorno. Los ejemplos son:

  • Empleados disgustados
  • Empleados no autorizados
  • Sesiones de terminales abiertos en lugares públicos
  • Piratas informáticos ("Hackers")
  • Interceptación de línea
  • Pérdida de equipo (por ejemplo, PC portátiles)

4. Para cada objeto establezca la amenaza que se puede aplicar y asóciele la exposición concreta.

Es posible que deba revisar los requisitos de seguridad para el objeto tanto en una ubicación estática (por ejemplo, en un disco duro), como en tránsito (por ejemplo, durante la transmisión).

Puesto que el diseño puede ampliar la ubicación del objeto a áreas no protegidas, probablemente deba retornar a este asunto.

Los aspectos de seguridad de algunos diseños de sistemas pueden ser muy exigentes. Pueden dominar sus decisiones de diseño y, por otra parte, podrían hacer que buenas opciones de selección de componentes y estructuras resulten inaceptables. Por ello, elija ahora una opción definitiva por si el sistema que está diseñando necesita requisitos de seguridad especialmente exigentes. Por ejemplo:

  • Un sistema militar confidencial
  • Un sistema de transferencia de dinero
  • Un sistema que maneje información personal confidencial

Si cree que tiene exigencias de seguridad especiales, debe identificar a un profesional o experto en seguridad que le ayude en los aspectos de diseño del sistema.

7 Utilización

Los requisitos de utilización definen el nivel de utilización que debe tener la interfaz de usuario.

Los requisitos de utilización se deben establecer en el nivel inferior de utilización que debe alcanzar el sistema para que se pueda utilizar. No se deben establecer en el nivel que cree que puede alcanzar el sistema. En otras palabras, los requisitos de utilización no se deben considerar un destino, es decir, un límite máximo. Los requisitos de utilización definen la utilización aceptable más baja absoluta del sistema. Por ello, no tiene que detener necesariamente la mejora de la utilización una vez que se han cumplido los requisitos de utilización.

El nivel que debe alcanzar el sistema para que se pueda utilizar depende, básicamente, de cuál es la alternativa a la utilización del sistema. Lo razonable es requerir que, con respecto a las alternativas, el sistema ofrezca importantes mejoras de utilización. Las alternativas pueden ser utilizar:

  • Procedimientos manuales existentes.
  • Sistemas heredados.
  • Productos de la competencia.
  • Versiones anteriores del sistema.

Los requisitos de utilización también provienen de la necesidad de justificar económicamente el nuevo sistema: si el cliente tiene que pagar 3 millones de dólares por el nuevo sistema, es posible que desee imponer requisitos de utilización que impliquen que se podrá ahorrar, quizá, 1 millón de dólares al año debido a la reducción de la carga de trabajo en recursos humanos.

A continuación, se incluyen algunos ejemplos de algunos requisitos de utilización general:

  • Tiempo de ejecución máximo - cuánto tiempo debe tardar un usuario con experiencia en ejecutar un caso de ejemplo común.
  • Índice máximo de errores - promedio de errores puede tener un usuario con experiencia para un caso de ejemplo común.
    Los únicos errores que son adecuados para medir son los que son irrecuperables y van a tener efectos negativos en la organización como, por ejemplo, pérdida empresarial, o bien, que causen daños en hardware supervisado. Si la única consecuencia de un error es que requiere tiempo para arreglarlo, afecta al tiempo de ejecución medido.
  • Tiempo de aprendizaje - cuánto tiempo pasa antes de que el usuario pueda ejecutar un caso de ejemplo más rápidamente que el tiempo de ejecución máximo.

Lo siguiente es un ejemplo de algunos requisitos de utilización específicos para un caso de uso "Gestionar mensajes de correo entrantes":

  • El usuario de correo debe poder disponer los mensajes de correo con una sola pulsación del ratón.
  • El usuario de correo debe poder desplazar los textos de los mensajes de correo pulsando botones del teclado.
  • Al usuario de correo no le deben molestar los mensajes de correo entrantes al leer mensajes de correo existentes.