Introducción






descargar 60.01 Kb.
títuloIntroducción
fecha de publicación09.09.2015
tamaño60.01 Kb.
tipoDocumentos
m.exam-10.com > Documentos > Documentos


MASTER EN INGENIERÍA DE SOFTWARE

UNIVERSIDAD POLITÉCNICA DE CATALUNYA





PROYECTO FINAL DE MÁSTER – MRF FRAMEWORK

Especificación de los Requerimientos del Sistema

Instrucciones

Version 1.0 ● 30 SEP 2008

Tabla de Contenidos

Introducción 1

Uso de la Especificación de los Requerimientos del Sistema 2

Visión 2

Aplicabilidad 2

Gobierno y alcance 2

Sección 1. Introducción 3

1.1Propósito 3

1.2Contexto del Negocio 3

1.3Ámbito 3

1.4Características de los Usuarios 3

Sección 2. Descripción General del Sistema 3

2.1Contexto del Sistema 3

2.2Modos y Estados del Sistema 4

2.3Capacidades Principales del Sistema 4

2.4Condiciones Principales del Sistema 4

2.5Restricciones Principales del Sistema 4

2.6Suposiciones 4

2.7Dependencias 4

2.8Escenarios Operacionales 4

Sección 3. Capacidades, Condiciones y Restricciones del sistema 5

3.1Requerimientos del Negocio 6

3.2Requerimientos Funcionales 6

3.2.XF Función X 6

3.2.YU Caso de Uso Y 7

3.3Requerimientos No Funcionales 7

3.3.1 Construcción 7

3.3.2 Durabilidad 7

3.3.3 Adaptabilidad 8

3.3.4 Condiciones Ambientales 8

3.4Requerimientos de los Datos Lógicos 8

3.5Requerimientos de Usuario 8

3.6Requerimientos de Gestión de la Información 8

3.7Requerimientos del Sistema 9

3.7.1Requerimientos sobre el Rendimiento 9

3.7.2Requerimientos sobre la Calidad 9

3.8Requerimientos sobre Políticas y Regulaciones 11

3.9Requerimientos sobre el Sustento del Ciclo de Vida 11

Sección 4. Interfaces del Sistema 11

Sección 5. Matriz de Trazabilidad de los Requerimientos 12

Sección 6. Referencias 13

Sección 7. Glosario 13

Sección 8. Historial de Revisión 13

Sección 9. Apéndices 13


Introducción


Los proyectos se encuentran frecuentemente con dificultades derivadas de una especificación escasa, poco precisa o documentada de los requerimientos. La definición de los requerimientos forma parte de una actividad más amplia como es la gestión de los requerimientos. Dicha actividad puede verse como la aproximación sistemática para encontrar, documentar, organizar y seguir los requerimientos y las posibles modificaciones que pueden surgir a través del ciclo de vida de un proyecto.

En 1994, el Standish Group realizó un estudio en 350 compañías y cerca de 8000 proyectos, hallando como causas de los proyectos fallidos los siguientes resultados:

    1. Requerimientos incompletos: 13.1%

    2. Falta de compromiso del usuario: 12.4%

    3. Falta de recursos: 10.6%

    4. Requerimientos y especificaciones cambiantes: 8.7%

De ello deriva el hecho de que aproximadamente un 40% de los esfuerzos dedicados a los proyectos software se destinan a la reingeniería. Asimismo, cuanto más avanzado se esté en el ciclo de vida de un proyecto más costosa resulta la corrección de los errores en los requerimientos. Estos hechos muestran la gran importancia de una adecuada definición inicial de los requerimientos del sistema, pues el coste de corregir un error en los requerimientos crece exponencialmente a medida que el proyecto madura. De este modo, una definición correcta de los requerimientos al inicio del proyecto es, posiblemente, una de las prácticas más importantes para prevenir errores altamente costosos y para incrementar el éxito potencial de un proyecto.

El proceso de definir los requerimientos proporciona una base sólida para una finalización exitosa del proyecto. Unos requerimientos bien especificados sirven como primera visión de lo que el proyecto tendrá que realizar y de cómo lo deberá hacer. Además, también proporcionan una base para el diseño del producto, para su testeo y para la aceptación del producto por parte del usuario mediante la identificación de las metas, las necesidades y los objetivos del proyecto.

La definición de los requerimientos normalmente es la práctica principal que sirve como puente de unión entre los miembros del equipo del proyecto y los stakeholders del negocio. En la práctica, se deben definir tanto los requerimientos del producto como los del proyecto, así como los requerimientos funcionales y no-funcionales asociados. Los requerimientos capturados a todos los niveles del negocio y del producto sirven para asegurar que el proyecto converge con sus objetivos dentro de las limitaciones aceptadas de tiempo, ámbito, recursos y calidad.

Para proveer un método consistente para documentar los requerimientos del sistema en los proyectos IT se proporciona como parte del Framework MRF el presente documento de Especificación de los Requerimientos del Sistema. Los requerimientos del sistema describen las expectativas del cliente con respecto al sistema, así como el ambiente en el que se espera que se utilice dicho sistema, su perfil de usabilidad, los parámetros bajo los que se debe ejecutar y la efectividad y calidad que de él se esperan. De este modo, la Especificación de los Requerimientos del Sistema puede considerarse como la recopilación estructurada de información que especifica los requisitos de un sistema. Para ello, describe todas sus entradas y salidas, así como las relaciones requeridas entre las ellas.

El hecho de documentar los requerimientos del sistema influenciará en la reducción de los riesgos de un proyecto, pues permitirá acotar las incertidumbres que pueden surgir durante su implementación. Por ello, una documentación detallada y precisa de los requerimientos contribuirá al éxito del sistema mediante el establecimiento y la comunicación de las expectativas del sistema en los aspectos tanto de caracterización como de realización. Asimismo, la documentación de los requerimientos del sistema proporciona las bases para asegurar que los requerimientos se están ejecutando correctamente durante las etapas de diseño y de testeo del sistema.

Uso de la Especificación de los Requerimientos del Sistema

Visión


Dentro del framework, la Especificación de los Requerimientos del Sistema se debe iniciar en la etapa de Planificación. No obstante esta especificación inicial se revisará, completará, actualizará y aprobará posteriormente, en la fase de Ejecución. Esta Especificación documenta y reporta los requerimientos del cliente al personal técnico encargado de definir y construir el sistema. De esta forma, la colección de requerimientos actúa como el lazo de unión entre los dos grupos y, por ello, debe ser entendible tanto para el cliente como para la comunidad técnica.

La aprobación de la Especificación de los Requerimientos del Sistema constituye la aceptación de que el sistema debe satisfacer todas las especificaciones. Una vez aprobada, los cambios sobre los requerimientos sólo podrán realizarse a través de un proceso de gestión de los cambios.

Aplicabilidad


La Especificación de los Requerimientos debe ser completada para todos los proyectos ya que es primordial para el posterior desarrollo del sistema.

Gobierno y alcance


La Especificación de los Requerimientos del Sistema tiene que desarrollarse coordinadamente entre los miembros adecuados del equipo del proyecto y los stakeholders, siendo accesible para todos ellos. Asimismo, es imprescindible que toda la información contenida en la Especificación de los Requerimientos del Sistema sea consistente con el Plan del Proyecto. Los requerimientos del sistema que se hayan documentado tendrán que dirigirse y gestionarse apropiadamente durante el ciclo de vida completo de un proyecto en todas las documentaciones de requerimientos del proyecto, de diseño, y de testeo.

Sección 1. Introducción


Esta sección proporciona una visión global de la Especificación de Requerimientos del Sistema.
    1. Propósito


Introducir el propósito de la Especificación de Requerimientos del Sistema y su audiencia prevista.
    1. Contexto del Negocio


Proporcionar una visión general del negocio de la organización cliente que sustenta el desarrollo del sistema, incluyendo una declaración de su misión y los objetivos organizacionales de la unidad de negocio.
    1. Ámbito


Describir el ámbito del sistema que se va a producir. Esta descripción debe incluir:

  • la identidad del sistema;

  • una breve descripción de la funcionalidad del sistema;

  • una explicación de lo que el sistema debe y no debe hacer;

  • una descripción de la aplicación del sistema;

  • una descripción de los beneficios relevantes, de los objetivos y de las metas del sistema.

Esta descripción debe ser consistente con declaraciones similares realizadas en documentos del proyecto precedentes.
    1. Características de los Usuarios


Identificar cada tipo de usuario del sistema a partir de su función, localización y tipo de dispositivos. Especificar el número de usuarios en cada uno de los grupos y la naturaleza del uso que hacen del sistema. Las características de los usuarios del producto del sistema pueden afectar a los requerimientos específicos. Gran cantidad de personal interactuará con un sistema durante las fases de operación y mantenimiento del ciclo de vida del sistema. Algunos son usuarios, operarios y personal de mantenimiento. Las características propias de estas personas, como por ejemplo su nivel educacional, o su experiencia y destreza técnica pueden imponer restricciones importantes en el entorno operacional del sistema.

Sección 2. Descripción General del Sistema

    1. Contexto del Sistema


Proporcionar los diagramas apropiados y su correspondiente descripción para presentar una visión global del contexto del sistema, definiendo todas las interfaces significativas que sobrepasan los límites del sistema.
    1. Modos y Estados del Sistema


Describir las diversas modalidades de operar del sistema (por ejemplo, administrativo, tratamiento por lotes (batch), debug, capacidad de entrenamiento incrustado, totalmente operacional, online, desocupado offline o seguro) y las condiciones (por ejemplo, ambiental, configuración u operacional) que determinan los modos de operar.
    1. Capacidades Principales del Sistema


Proporcionar diagramas con sus correspondientes especificaciones para describir las agrupaciones de los requerimientos más importantes.
    1. Condiciones Principales del Sistema


Describir las principales condiciones y sus posibilidades asociadas. Las condiciones pueden limitar las opciones disponibles para el diseñador. Es importante identificar las condiciones como atributos de capacidad y no como aptitudes primarias para asegurar, de esta forma, que los requerimientos definen claramente una necesidad sin limitar innecesariamente la solución.
    1. Restricciones Principales del Sistema


Describir las restricciones más relevantes del sistema. Las restricciones limitan el ámbito y las funcionalidades del sistema. Algunos ejemplos de restricciones son las políticas regulatorias, las limitaciones en la infraestructura, la cantidad de recursos disponibles o las licencias y autorizaciones.

Las restricciones son requerimientos impuestos sobre la solución por las circunstancias, por la fuerza o por la presión y que limitan de forma absoluta las opciones disponibles para el diseñador de la solución y le imponen unos límites inamovibles.
    1. Suposiciones


Describir las suposiciones que pueden afectar a los requerimientos que se han detallado en la Especificación de los Requerimientos del Sistema. Las suposiciones son factores considerados como ciertos durante todo el ciclo de vida de un proyecto y que, si cambian, pueden afectar las negativamente sobre las salidas del proyecto. Algunos ejemplos de suposiciones pueden ser las características de los usuarios finales, la infraestructura tecnológica conocida, la disponibilidad de recursos y la disponibilidad de fondos.
    1. Dependencias


Describir las dependencias que pueden afectar sobre los requerimientos establecidos en la Especificación de los Requerimientos del Sistema. Las dependencias se encuentran fuera del ámbito y del control del proyecto, y deben permanecer como ciertas para que el proyecto sea exitoso.
    1. Escenarios Operacionales


Proporcionar una descripción de los escenarios operacionales para el sistema. Un escenario operacional es una descripción paso a paso de cómo debe operar e interaccionar el sistema con sus usuarios, así como sus interfaces externas para un conjunto de circunstancias dadas. Además, los escenarios también pueden utilizarse para describir lo que el sistema no tiene que hacer.

Sección 3. Capacidades, Condiciones y Restricciones del sistema


En esta sección se especifican todos los requerimientos del sistema hasta el nivel de detalle suficiente que permita a los desarrolladores la especificación y construcción del sistema. Cada uno de los requerimientos enunciados tiene que ser entendible tanto para los usuarios, los desarrolladores, los operarios y el personal de soporte externo a sistemas.

Especificar la transformación de las entradas del sistema en productos de salida y todas las funciones realizadas por el sistema como respuesta a una entrada o como soporte a una salida. Esta descripción consistirá en un modelo de los requerimientos. Por ejemplo, el modelo puede contener diagramas del flujo de los datos, modelos de entidad-relación y glosario de términos.

La especificación de los requerimientos de negocio y de producto ayuda a asegurar que el proyecto logra sus objetivos a todos los niveles. Así, algunos de los principales tipos de requerimientos son:

  • Los Requerimientos de Proyecto definen cómo se tiene que gestionar el trabajo, incluyendo el presupuesto, la gestión de la comunicación, la gestión de los recursos, el aseguramiento de la calidad, la gestión de los riesgos y la gestión del ámbito del proyecto. Estos requerimientos se focalizan en quién, cuándo, dónde y cómo se realizarán las actividades y generalmente se encuentran documentados en los Planes de Gestión del proyecto.

  • Los Requerimientos del Producto incluyen características o capacidades de alto nivel que el equipo de negocio ha decidido entregar al cliente. Estos requerimientos no especifican cómo se diseñarán dichas características.

    • Los Requerimientos Funcionales dirigen qué debe hacer el sistema. Definen cualquier requerimiento que trace de forma específica qué debe hacer un componente o una función del producto.

    • Los Requerimientos No-Funcionales dirigen hechos como las soluciones técnicas, la especificación del número de personas que deberán utilizar el producto, dónde se localizará el producto, los tipos de transacciones a procesar o los tipos de interacciones tecnológicas.

Además, los requerimientos cumplir las siguientes propiedades:

  • correctos, no ambiguos, completos, consistentes, categorizados por importancia y/o estabilidad, verificables, modificables y fáciles de localizar;

  • con referencias cruzadas a los documentos previos con los que se relacionan;

  • identificables de forma única;

  • organizados para una máxima legibilidad.
    1. Requerimientos del Negocio


Describir todos los requerimientos del negocio para el sistema. Los requerimientos del negocio son las áreas del proceso de negocio global que se automatizarán mediante el sistema. Estos requerimientos se deberán definir en forma de casos de uso.
    1. Requerimientos Funcionales


Personalizar esta sección para que contenga las subsecciones necesarias para definir de manera comprensible las acciones fundamentales que deberán tener lugar en el sistema para aceptar y procesar las entradas y generar las salidas.

Las acciones fundamentales en los requerimientos funcionales incluyen:

  • inspecciones de validación de las entradas;

  • secuencias exactas de operaciones;

  • respuestas a situaciones anormales, incluyendo facilidades de comunicación

  • efecto de los parámetros

  • relación entre las salidas y las entradas, incluyendo:

    • secuencias de entrada/salida;

    • fórmulas para la conversión de entradas en salidas;

    • definiciones de las respuestas del sistema en todos los posibles datos de entrada para todas las posibles situaciones.

Los requerimientos funcionales deben incluir requerimientos específicos para las reglas de negocio. Las reglas de negocio describen y documentan los pasos en los procesos de negocio.

Puede ser apropiado dividir los requerimientos funcionales en subprocesos, aunque ello no implica que la arquitectura o el sistema diseñado tengan que dividirse del mismo modo. Los dos modos comunes de especificar los requerimientos funcionales son la descomposición funcional y los casos de uso. A continuación se especifican los templates para cada uno de ellos.

3.2.XF Función X


Cuando se utiliza la descomposición funcional como la forma para especificar los requerimientos funcionales, se tiene que proporcionar una subsección del tipo 3.2.xf para cada función. Cada una de estas subsecciones se deberá etiquetar y titular conforme a la función concreta, donde xf se corresponde con la subsección secuencial y X es el nombre de la función específica.

3.2.xf.1 Propósito de la Función X

Describir el objetivo de la función.

3.2.xf.2 Entradas de la Función X

Describir las entradas de la función, incluyendo las fuentes, los rangos de valores válidos, las consideraciones temporales, los requerimientos operacionales y las interfaces especiales.

3.2.xf.3 Operaciones de la Función X

Describir las operaciones que se ejecutarán dentro de la función, incluyendo las inspecciones de validación, las respuestas a las situaciones anormales y los tipos de procesamiento requeridos.

3.2.xf.4 Salidas de la Función X

Describir las salidas de la función, incluyendo el destino de dichas salidas, los rangos válidos de los valores, las consideraciones temporales, las apreciaciones para manejar los valores ilegales, los mensajes de error y las interfaces requeridas.

3.2.YU Caso de Uso Y


Cuando se utilizan los casos de uso como la forma para especificar los requerimientos funcionales, se debe proporcionar una subsección del tipo 3.2.yu para cada función. Cada subsección se tendrá que etiquetar y titular conforme al caso de uso concreto, donde yu se corresponde con la subsección secuencial y Y es el nombre de la función específica.

Dentro de cada subsección de un caso de uso, especificar la información sobre dicho caso de uso, incluyendo el actor, las precondiciones, las postcondiciones, los escenarios y los escenarios alternativos.
    1. Requerimientos No Funcionales

3.3.1 Construcción


Especificar las características ambientales (por ejemplo, mecánicas, eléctricas, químicas) en las que se instalará el sistema. Así, por ejemplo, es necesario que se identifiquen los límites de peso del sistema, las limitaciones en las dimensiones y el volumen o los accesos para su mantenimiento.

3.3.2 Durabilidad


Especificar las características de durabilidad del sistema.

3.3.3 Adaptabilidad


Especificar las características de crecimiento, expansión, capacidad y contratación. Por ejemplo, si el sistema puede requerir mayor ancho de banda en un futuro, si el rack hardware debe poseer espacios extra para que, si se incrementa la demanda, se pueda dar cabida a nuevas tarjetas de red, etc.

3.3.4 Condiciones Ambientales


Especificar las condiciones ambientales con las que se encontrará el sistema. Algunas de las materias a cubrir que se deben tener en cuenta son: condiciones climatológicas, ambiente inducido (por ejemplo, movimiento, ruido, etc.) y señales electromagnéticas del entorno.
    1. Requerimientos de los Datos Lógicos


Describir los requerimientos lógicos de los datos para el sistema. Estos requerimientos pueden incluir:

  • Tipos de información utilizados por varias funciones

  • Frecuencia de uso

  • Capacidades de accesibilidad

  • Entidades de datos y sus relaciones

  • Restricciones de integridad

  • Requerimientos de la retención de datos
    1. Requerimientos de Usuario


Describir los requerimientos de usuario para el sistema. Los requerimientos de usuario capturan el comportamiento de la interfaz humana previsto para la aplicación. Por ejemplo, si el usuario interacciona a través de un terminal de visualización, especificar el contenido requerido por la pantalla, el contenido de los menús o de los informes, y el tiempo relativo de las entradas y salidas. Estos requerimientos tienen que incluir ejemplos de la pantalla o informes sobre los formatos como prototipos para ilustrar los requerimientos.
    1. Requerimientos de Gestión de la Información


Describir los requerimientos para gestionar la creación, captura, organización, mantenimiento, uso, protección, y disposición de la información en coordinación con las leyes aplicables, las regulaciones, las políticas y los estándares.
    1. Requerimientos del Sistema

      1. Requerimientos sobre el Rendimiento


Describir las condiciones sobre el rendimiento y sus capacidades asociadas. Incluir consideraciones tales como:

  • Acciones dinámicas o cambios ocurridos (por ejemplo, rangos, velocidades, movimientos o niveles de ruido)

  • Criterios cuantitativos que cubren las capacidades de resistencia requeridas por el equipamiento para estar en consonancia con las necesidades del usuario bajo ciertas condiciones, incluyendo su esperanza de vida mínima. Indicar la duración de las sesiones operacionales requeridas y el rango de utilización planeado.

  • Requerimientos de Rendimiento para las fases y modalidades operacionales.

  • El número de terminales que tienen que soportarse.

  • El número simultáneo de usuarios que deberá soportar.

  • El número de transacciones y tareas y la cantidad de datos a procesar dentro de un cierto periodo temporal tanto en condiciones normales como en los picos en el volumen de trabajo.

  • Rendimiento aceptable bajo tensiones atípicas.

Estos requerimientos deben establecerse en términos mesurables. Por ejemplo, especificar que el 95% de las transacciones tiene que ser procesadas en menos de un segundo, en lugar de definir que el operario no tiene que esperar para completar una transacción.

Las características de rendimiento únicas para una función específica (ver la subsección de Requerimientos Funcionales) o fuera de la características de ejecución generales del sistema han de especificarse como parte del procesamiento de la descripción de dicha función.
      1. Requerimientos sobre la Calidad


Describir los requerimientos sobre las características de calidad de un sistema. Estos requerimientos deben especificarse en términos mesurables y verificables. Describir las compensaciones entre las características (por ejemplo, seguridad vs. portabilidad). Las definiciones sobre las propiedades de calidad incluyen:

  • Correctividad – hasta qué punto el programa debe satisfacer las especificaciones y cumplir con los objetivos de misión de los usuarios.

  • Eficiencia – cantidad de recursos computacionales y de código requerido para realizar una función.

  • Flexibilidad – esfuerzo requerido para modificar el programa operacional.

  • Integridad/Seguridad – hasta qué punto se puede controlar el acceso al software o a los datos por parte de personal no autorizado. Ejemplos de requerimientos sobre seguridad pueden ser la especificación de requerimientos de seguridad y privacidad, incluyendo limitaciones de acceso al sistema como la existencia de procesos de loggin y contraseñas, y de protección de datos y métodos de recuperación. Esto puede incluir los factores que protegerán el sistema de accesos, usos, modificaciones y/o destrucciones accidentales o maliciosas.

  • Interoperabilidad – esfuerzo requerido para asociar un sistema con otro.

  • Mantenibilidad – esfuerzo requerido para localizar y corregir un error durante una operación. Los requerimientos de mantenibilidad se aplican a las actividades de mantenimiento planeadas y a los ambientes de soporte. Ejemplos de requerimientos de mantenibilidad cuantitativos son el tiempo (periodo de inactividad medio y máximo, tiempo de reacción, tiempo de recuperación, tiempo medio y máximo para reparar, tiempo medio de las acciones de mantenimiento, etc.), el rango (horas dedicadas por el personal de mantenimiento a una acción específica, tiempo de mantenimiento por hora operacional, frecuencia de los mantenimientos preventivos, etc.), complejidad de los mantenimientos (número de gente y niveles de habilidad, variedad del equipo de soporte, etc.) y índices de acciones de mantenimiento (coste del mantenimiento por hora operacional del sistema, horas de personal de soporte por revisión).

  • Portabilidad – esfuerzo requerido para transferir desde un ambiente hardware o software a otro ambiente.

  • Fiabilidad – hasta qué punto el sistema se ejecuta con la precisión deseada.

  • Reusabilidad – qué software y artefactos asociados podrán reutilizarse en otra aplicación.

  • Testeo – esfuerzo requerido para garantizar con el testeo que el software funciona como se desea.

  • Usabilidad – esfuerzo requerido para aprender, operar, preparar las entradas e interpretar las salidas. Los requerimientos sobre usabilidad incluyen cualquier requerimiento especial o único que identifique y defina factores sobre consideraciones y restricciones relacionadas con los factores humanos (por ejemplo, limitaciones del diseño del espacio, limitaciones climáticas, movimiento de los ojos, ergonomía, limitaciones cognitivas y usabilidad) que afectan a las operaciones del sistema. Tener en cuenta las áreas o el equipamiento específico que requiere de una atención especial a causa de los posibles efectos producidos por los errores humanos.
    1. Requerimientos sobre Políticas y Regulaciones


Especificar las leyes, regulaciones, políticas y estándares aplicables relevantes que pueden afectar las operaciones o la ejecución del sistema, así como cualquier requerimiento de regulación externo o restricción impuesta por las prácticas de negocio usuales. Algunos ejemplos de requerimientos de políticas y regulación son:

  • Soporte multilenguaje

  • Políticas laborales

  • Protección de la información personal

  • Informes a una agencia regulatoria

  • Criterios de seguridad y robusteza, incluyendo los criterios básicos para el diseño del sistema con respecto a las características del equipamiento, métodos de operación e influencias ambientales.
    1. Requerimientos sobre el Sustento del Ciclo de Vida


Describir la revisión, la colección de métricas, y las actividades de análisis de la calidad a ejecutar durante el ciclo de vida completo del sistema.

La capacidad de cambiar o mejorar el producto y los procesos del ciclo de vida pueden diseñarse dentro de la arquitectura del sistema para así poder sustentar de forma efectiva su coste a lo largo de todo el ciclo de vida. Es conveniente que estos atributos de diseño se establezcan en las primeras fases del desarrollo del sistema pues con ellos se establecen las bases para la planificación de cada incremento del esfuerzo destinado al desarrollo. Las estrategias de desarrollo evolutivas deben gestionar aproximaciones para manejar la introducción de nuevas tecnologías, la evolución de los requerimientos o la mejora de las capacidades del producto.

El ciclo de vida del sistema incluye las etapas de:

  • Elaboración

  • Construcción

  • Transición

  • Soporte

  • Entrenamiento

Sección 4. Interfaces del Sistema


Especificar detalladamente los requerimientos para las interfaces para los distintos componentes, así como sus capacidades externas incluyendo todos sus usuarios, tanto los humanos como otros sistemas. También deben incluirse las características de las interfaces para los sistemas que se encuentran en desarrollo o para los sistemas futuros. Asimismo, es necesario identificar cualquier interdependencia o restricción asociada con las interfaces (por ejemplo, los protocolos de comunicación, los mecanismos especiales, los estándares o los formatos fijos). Cada interfaz tiene que representar un flujo de información bidireccional. Cuando sea necesario, puede usarse una representación gráfica de las interfaces para clarificar.

Sección 5. Matriz de Trazabilidad de los Requerimientos


Esta sección proporciona una referencia a la localización de la Matriz de Trazabilidad de los Requerimientos que deberá completarse durante el ciclo de vida del proyecto.

La Matriz de Trazabilidad de los Requerimientos se inicia en la Especificación de los Requerimientos del Sistema y se va actualizando apropiadamente durante la vida de un proyecto para indicar la trazabilidad de los elementos de diseño documentados en la Descripción del Diseño del Sistema, los requerimientos software documentados en la Especificación de los Requerimientos Software, y los elementos de diseño documentados en la Descripción del Diseño Software. La Matriz de Trazabilidad de los Requerimientos completa garantiza que durante el diseño se ha tratado cada requerimiento, así como que cada elemento de diseño dirige un requerimiento. Esta Matriz también proporciona la trazabilidad necesaria para la integración, la aceptación, la regresión y el testeo del rendimiento.

La Matriz de Trazabilidad de los Requerimientos dentro de la Especificación de los Requerimientos del Sistema debe:

  • Contener las columnas que se utilizarán para ilustrar la trazabilidad de los requerimientos del sistema tanto para los elementos de diseño, como para los requerimientos software y para los elementos de diseño del software.

  • Contener las columnas necesarias para ilustrar la trazabilidad para la integración, la aceptación, la regresión y el testeo del rendimiento.

  • Contener todos los requerimientos documentados en la Especificación de los Requerimientos del Sistema.

  • Indicar la fuente o el origen de cada requerimiento.

Los apéndices incluyen una plantilla con la Matriz de Trazabilidad de los Requerimientos como herramienta adicional del Framework MRF.

Nota: Mantener la Matriz de Trazabilidad de los Requerimientos como un documento separado y ejecutar las actualizaciones adecuadas de forma controlada es más eficiente que incluirla dentro de la Especificación de los Requerimientos del Sistema, ya que requeriría una revisión de la Especificación de los Requerimientos del Sistema cada vez que se tuviese que modificar la Matriz de Trazabilidad.

Sección 6. Referencias


Identificar las fuentes de información de la Especificación de los Requerimientos del Sistema y las utilizadas durante su desarrollo. Para cada una de ellas, es necesario incluir el número de documento, el título, la fecha y el autor.

Sección 7. Glosario


Definir todos los términos y acrónimos requeridos para interpretar adecuadamente la Especificación de los Requerimientos del Sistema.

Sección 8. Historial de Revisión


Identificar los cambios a la Especificación de los Requerimientos del Sistema.

Sección 9. Apéndices


Incluir cualquier apéndice relevante.



Añadir el documento a tu blog o sitio web

similar:

Introducción iconTaller com/manual-java/introduccion-java php >Introducción a Java...

Introducción iconNeumática introducción breve historia definiciones y leyes elementos...

Introducción iconDibujo tecnico introducción al curso. Alfabeto de líneas. Letras...

Introducción iconUnidad I introducción y antecedentes 1 Introducción

Introducción iconUnidad I introducción y antecedentes 1 Introducción

Introducción iconLa Casa de los Siete Tejados introduccion
«The Custom House», introducción a The Scarlet Letter, que se gestó entonces, aunque tenga claros precedentes en escritos anteriores,...

Introducción iconIntroduccióN

Introducción iconIntroduccion

Introducción iconIntroduccióN

Introducción iconIntroduccióN






© 2015
contactos
m.exam-10.com