Tarea: Desarrollar especificaciones suplementarias |
|
 |
Esta tarea captura los requisitos que no se aplican a guiones de uso específicos. |
|
Objetivo
Capturar requisitos que no se capturan fácilmente en los Guiones de uso. |
Relaciones
Roles | Principal:
| Adicional:
| Asistencia:
|
Entradas | Obligatoria:
| Opcional:
| Externa:
|
Salidas |
|
Descripción principal
Durante las actividades de requisitos, según las solicitudes recopiladas de los interesados, los requisitos que no se
pueden aplicar a los Guiones de uso se capturan en la especificación suplementaria. En la
especificación suplementaria se pueden capturar requisitos funcionales y no funcionales.
Para obtener más información sobre la categorización y la captura de requisitos, consulte Concepto: Requisitos.
Cuando se ejecuta esta tarea, es importante asegurarse de que se especifican todos los requisitos con el nivel de
detalle necesario para distribuirlos a los diseñadores, verificadores y escritores de documentación. Si los
requisitos se rastrean o se gestionan formalmente de otro modo, asegúrese de que cada requisito esté bien identificado
y etiquetado.
|
Pasos
Capturar requisitos funcionales que no son específicos del guión de uso
Los requisitos funcionales describen los comportamientos (funciones y servicios) del sistema que dan soporte a los
objetivos, las tareas o las actividades de los usuarios [MAL2001].
Aunque muchos de los requisitos funcionales se documentarán en Guiones de
uso, existen algunos requisitos funcionales que no se pueden aplicar a guiones de uso específicos. Por
ejemplo, los requisitos de informes, auditoría, impresión, seguridad, soporte de licencia/aplicación, autenticación,
etc. Estos requisitos funcionales se deben documentar en la especificación suplementaria.
Si existe un número significativo de requisitos funcionales en todo el sistema, es importante dedicar un tiempo a la
organización de este apartado. Una organización típica es por característica/conjunto de características, pero
también son posibles métodos de organización alternativos. Por ejemplo, la organización por usuario o por
subsistema también puede ser adecuada.
Los requisitos funcionales representan la 'F' en "FURPS+. Para obtener más información sobre "FURPS+", consulte
Concepto: Requisitos.
|
Capturar calidades del sistema
Los requisitos no funcionales incluyen calidades y restricciones [MAL2001].
En este paso se describen las calidades. Las restricciones se tratan en otro paso.
Las calidades del [sistema] son propiedades o características del sistema que preocupan a los interesados y que
afectarán a su grado de satisfacción con el sistema. [MAL2001]
Las calidades representan "URPS" en "FURPS+". Los temas a tener en cuenta en cada una de estas categorías de
requisitos son:
-
Utilización: estética y coherencia en la interfaz de usuario.
-
Fiabilidad: disponibilidad (la cantidad de "tiempo de actividad" del sistema),
precisión de los cálculos del sistema y la capacidad del sistema para recuperarse de errores.
-
Rendimiento: productividad, tiempo de respuesta, tiempo de arranque y tiempo de conclusión.
-
Soportabilidad: comprobabilidad, adaptabilidad, mantenimiento, compatibilidad, capacidad de
configuración, capacidad de instalación, escalabilidad y capacidad de localización.
Para obtener más información sobre "FURPS+", así como sobre la captura de requisitos no funcionales, consulte Concepto: Requisitos.
Dependiendo del número de calidades que se van a documentar para el sistema, puede proporcionar subsecciones para cada
uno de estos tipo de calidad.
En las siguientes secciones se proporcionan algunos ejemplos de los tipos de información que puede capturar para cada
una de estas calidades:
Utilización
Cuando describa los requisitos de utilización, puede especificar:
-
El tiempo de formación necesario para usuarios normales y usuarios avanzados para ser productivos en determinadas
operaciones
-
Los tiempos de tarea medibles de las tareas típicas
-
Los requisitos de cumplir estándares comunes de utilización, por ejemplo, los estándares CUA de IBM o los
estándares de GUI de Microsoft
Fiabilidad
Cuando describa los requisitos de fiabilidad, puede especificar:
-
Disponibilidad: especifique el porcentaje de tiempo disponible (xx,xx%), las horas de uso, el acceso al
mantenimiento, las operaciones de modalidad degradada, etc.
-
Tiempo medio entre errores (MTBF): normalmente se especifica en horas, pero también se puede especificar en días,
meses o años.
-
Tiempo medio de reparación (MTTR): ¿cuánto tiempo puede estar el sistema sin funcionar después de fallar?
-
Precisión: especifique la exactitud (resolución) y la precisión (según algún estándar conocido) que se necesita en
la salida de los sistemas.
-
Índice de máximo de errores o defectos: normalmente se expresa en errores/KLOC (miles de líneas de código), o
errores/punto de función.
-
Índice de errores o defectos: se categorizan en errores menores, significativos y graves: los requisitos deben
definir qué significa un error "grave"; por ejemplo, una pérdida completa de datos o la incapacidad completa de
utilizar determinadas partes de la funcionalidad del sistema.
Rendimiento
Cuando describa los requisitos de rendimiento, puede especificar:
-
Tiempo de respuesta de una transacción (medio, máximo)
-
Productividad (por ejemplo, transacciones por segundo)
-
Capacidad (por ejemplo, el número de clientes o transacciones que puede albergar el sistema)
-
Modalidades de degradación (cuál es la modalidad aceptable de operación cuando el sistema se ha degradado de alguna
manera)
-
Uso de recursos: memoria, disco, comunicaciones, etc.
Cuando se documenten los requisitos de rendimiento, asegúrese de incluir tiempos de respuesta específicos. Siempre que
sea aplicable, haga referencia a los los Guiones de
uso relacionados por su nombre.
Capacidad de soporte
Cuando describa los requisitos de soportabilidad, puede especificar:
-
Estándares de codificación
-
Convenios de denominación
-
Bibliotecas de clases
-
Acceso al mantenimiento
-
Programas de utilidad de mantenimiento
|
Capturar restricciones
En este paso, se documentan y diseñan las restricciones del sistema que se está creando. En términos
generales, una restricción es una limitación del grado de libertad que tenemos para proporcionar una solución [LEF2000]. Las restricciones de diseño representan decisiones de diseño que
son obligatorias y que se deben cumplir.
El signo '+' en "FURPS+" representa una restricción, que se puede categorizar más de la siguiente manera:
-
Restricción de diseño: especifica o limita las opciones para crear una arquitectura de un sistema
y/o diseñarlo. Por ejemplo, el requisito de que se utilice una base de datos relacional para la
persistencia.
-
Restricción de implementación: especifica o restringe la codificación o la construcción de un
sistema. Por ejemplo, los estándares necesarios, los procesos, las herramientas, los lenguajes de implementación,
las plataformas de hardware, los sistemas operativos, los componentes de terceros, las bibliotecas de clases y los
límites de los recursos (uso de memoria o espacio de disco).
-
Restricción de interfaz: especifica un elemento externo con el que debe interactuar un sistema, o
restricciones en los formatos u otros factores utilizados en dicha interacción. Por ejemplo, la interacción
con un sistema externo mediante colas de mensajes.
-
Restricción física: especifica una restricción física impuesta en el hardware utilizado para
albergar el sistema, por ejemplo, la forma, el tamaño o el peso.
Dependiendo del número de restricciones que se van a documentar para el sistema, puede proporcionar subsecciones para
cada uno de los tipos de restricción. Asimismo:
-
Si los requisitos incluyen la adquisición de componentes de terceros, asegúrese de documentar la licencia aplicable
o las restricciones de uso, así como los estándares de interfaz o compatibilidad/interoperatividad asociados. Se
recomienda una sección aparte para cada componente adquirido.
-
Si se incluyen requisitos específicos de cada interfaz, se recomienda proporcionar secciones aparte para los
distintos tipos de interfaces (por ejemplo, usuario, hardware, software). Para cada interfaz, asegúrese de incluir
la especificidad adecuada, los protocolos, los puertos, las direcciones lógicas, etc., para que el software se
pueda desarrollar y verificar con los requisitos de la interfaz. Específicamente:
-
Para las interfaces de usuario, describa las interfaces de usuario que va a implementar el software.
-
Para las interfaces de hardware, incluya la estructura lógica, las direcciones físicas, el comportamiento
esperado, etc.
-
Para las interfaces de software, incluya una descripción de las interfaces en los otros componentes del
sistema de software. Estos pueden ser componentes adquiridos, componentes reutilizados de otras
aplicaciones o componentes que se están desarrollando para los subsistemas fuera del ámbito de este
sistema, pero con los que la aplicación de software debe interactuar.
Para obtener más información sobre "FURPS+", así como sobre la captura de restricciones, consulte Concepto: Requisitos.
|
Capturar requisitos de cumplimiento
Por cumplimiento entendemos el cumplimiento de estándares (incluidos los estándares normativos, los estándares de
codificación o las guías de estilo de las interfaces), así como el cumplimiento de las declaraciones de limitación de
responsabilidad, las garantías, los avisos de copyright, los avisos de patentes, las logomarcas, las marcas registradas
y/o los logotipos.
El cumplimiento de requisitos se debe realizar en términos de otros requisitos (funcionales, no funcionales y
restricciones). En tales casos, los detalles de esos requisitos se deben documentar en las secciones aplicables
de la especificación suplementaria, tal como se ha descrito en los pasos anteriores. No obstante, es importante
resumir los estándares y las políticas que debe cumplir un sistema. Los requisitos de cumplimiento resultantes
pueden hacer referencia a los requisitos detallados aplicables, según sea necesario.
Dependiendo del número de requisitos de cumplimiento que se van a documentar para el sistema, puede proporcionar
subsecciones para los distintos tipos de requisitos de cumplimiento que afectan al sistema.
En las siguientes secciones se proporcionan algunos ejemplos de los tipos de información que puede capturar para los
distintos tipos de cumplimiento:
Requisitos de licencia
Defina los requisitos de aplicación de licencias u otros requisitos de restricción de uso que se incluyan en el
software.
Avisos legales, de copyright o de otro tipo
Describa los requisitos de cumplimiento de las declaraciones de limitación de responsabilidad, las garantías, los
avisos de copyright, los avisos de patente, las logomarcas, las marcas registradas y los logotipos del software.
Estándares aplicables
Describa (por referencia) los estándares aplicables y las secciones específicas de tales estándares que se apliquen al
sistema que se está describiendo. Por ejemplo, pude incluir estándares leales, cualitativos o normativos, estándares
del sector para la utilización, interoperatividad, internacionalización, cumplimiento del sistema operativo, etc.
|
Capturar requisitos de documentación
En este paso, se describen los requisitos, si existen, de la documentación. Los requisitos de documentación pueden
incluir requisitos de ayuda en línea, así como documentación de usuario final (por ej., guías de instalación, guías de
usuario, material de formación, etc.).
Como los requisitos de cumplimiento, los requisitos de documentación controlan otros tipos de requisitos. En
concreto, los requisitos funcionales (el sistema debe proporcionar acceso funcional de soporte a la ayuda en línea),
así como los requisitos de utilización (el acceso bajo demanda a la información de uso del sistema da soporte a la
utilización general del sistema).
Por lo tanto, como los requisitos de cumplimiento, los requisitos detallados que dan soporte a los requisitos de
documentación se deben documentar en las secciones aplicables de la especificación suplementaria, tal como se ha
descrito en los pasos anteriores, pero también es importante documentar y resumir los requisitos de documentación
generales del sistema. Los requisitos resultantes pueden hacer referencia a los requisitos detallados aplicables.
Dependiendo del número de requisitos de documentación que se van a documentar para el sistema, puede proporcionar
subsecciones para los distintos tipos de documentación que se van a proporcionar para el sistema.
|
|
Propiedades
Varias apariciones |  |
Condicionado por sucesos |  |
Continuo |  |
Opcional |  |
Planeado |  |
Se puede repetir |  |
Factores clave
Los requisitos que abarcan guiones de uso (probablemente requisitos en todo el sistema) tienden a controlar el
desarrollo de la arquitectura del sistema. De hecho, en algunos proyectos, estos requisitos pueden ser mucho más
importantes que sus equivalentes más específicos del dominio (o específicos del guión de uso). Por ejemplo, si
desarrolla sistemas médicos de respiración asistida, los requisitos de fiabilidad serán críticos.
Sin embargo, estos requisitos son difíciles de recopilar y, por lo tanto, suelen pasarse por alto. En esta tarea se
describe el enfoque global para recopilar estos requisitos. Para obtener más información sobre un enfoque
"sistemático" para recopilar estos requisitos utilizando cuestionarios específicos, consulte [EEL2004].
|
Más información
Instrucciones de la herramienta |
|
© Copyright IBM Corp. 1987, 2006. Reservados todos los derechos.
|
|