Capitulo 1

Requerimientos de Software

SIGLAS

INTRODUCCION

El Área de Conocimiento de Exigencias de Software el (AC) está preocupado por el análisis, la especificación, y la validación de exigencias de software. Extensamente es reconocido dentro de la industria que el software que traza proyectos es críticamente vulnerable cuando estas actividades son realizadas mal.

Las exigencias de software expresan las necesidades y coacciones colocadas sobre un producto de software que contribuye a la solución de algún problema mundial verdadero.

El término " exigencias de la ingeniería" es extensamente usado en el campo para denotar el manejo sistemático de exigencias. Por motivos de consistencia, el término "ingeniería" no será usado en la Guía sino para otra cosa que el software que trama en sí.

Por la misma razón, "las exigencias del ingeniero," un término que aparece en un poco de la literatura, no será usado tampoco. En cambio, el término "el ingeniero de software" o, en algunos casos específicos, " el especialista de exigencias " será usado, éste el donde el papel en cuestión por lo general es realizado por un individuo otro que un ingeniero de software. Esto no implica, sin embargo, que un ingeniero de software no pueda realizar la función.

Un riesgo inherente en la interrupción propuesta consiste en que un proceso parecido a una cascada puede ser deducido. Para protegerse contra esto, el subárea 2 Proceso de Exigencias, es diseñado para proporcionar una descripción de alto nivel del proceso de exigencias disponiendo de los recursos y coacciones bajo las cuales el proceso funciona y que actúan para configurarlo.

Una descomposición alterna podría usar una estructura a base de producto (exigencias de sistema, exigencias de software, prototipos, casos de empleo, etcétera). La interrupción a base del proceso refleja el hecho que el proceso de exigencias, si debe ser acertado, debe ser considerado como un proceso que implica el complejo, actividades

GDA: Gráfico Dirigido Acíclico

MTF: Medida de Tamaño Funcional.

COINSIS: Consejo internacional sobre Ingeniería de sistemas.

LUM: Lengua Unificada de Modelaje.

SML: Sistemas que Modelan el Lenguaje.

Requerimientos del Software

Requerimientos del software

fundamentales

Definicion de Requerimientos del

Software

Requerimientos del producto y los

procesos.

Requerimientos funcionales y no

funcionales

Propiedades Emergentes

Requerimientos cuantificables

Requerimientos de Software y

Requerimientos de sistemas

Proceso de Requerimientos

Modelo de Procesos

Actores de Procesos

Apoyo y Gestion de Procesos

Proceso de Calidad y Mejora.

Elicitación de Requerimientos

Fuentes de Requerimientos

Tecnicas de Elicitacion

Análisis de Requerimientos

Clasificacion de Requerimientos

Modelado Conceptual

Diseño Arquitectónico y Asignación de Requerimientos

Negociacion de Requerimientos

Analisis Formal

Especificación de Requerimientos

Documento de Definicion de Sistema

Especificacion de los Requerimientos del

Sistema

Especificacion de los Requerimientos del

Software

Validación de Requerimientos

Revisiones de Requerimientos

Creacion de Prototipos

Validacion del Modelo

Pruebas de Aceptacion

Consideración Practica

Naturaleza Interactiva del proceso de requerimientos

Gestion del Cambio

Atributos de los Requerimientos

Rastreo de los Requerimientos

Medicion de los Requerimientos

Herramientas de los Requerimientos del

Software

Figura 1: Interrupción de Asuntos para las Exigencias de Software

Fuerte acopladas (tanto secuencial como simultáneo), más bien como una actividad discreta, única realizada a comienzos de un proyecto de desarrollo de software.

Las Exigencias de Software son relacionadas estrechamente con el Diseño de Software, Pruebas de Software, el Mantenimiento de Software, la Dirección de Configuración de Software, Ingeniería del mantenimiento de software, el Proceso de Ingeniería de Software, Ingeniería de los Modelos y Métodos de Software, y la Calidad de Software.

1. Requerimientos del Software fundamentales

1.1. Definición de un Software de requisito.

En su forma más básica, un requisito de software es una propiedad que debe ser exhibida para solucionar algún problema en el mundo real. La guía se refiere a los requisitos en "software" porque se refiere a los problemas a ser abordados por el software. Por lo tanto, un requisito de software es una propiedad que debe ser exhibida por el software desarrollado o adaptado para resolver un problema particular. Dicho software puede apuntar para automatizar parte de una tarea de quien usará el software, para apoyar los procesos de negocio de las organización que ha encargado el software, las deficiencias correcta del software existente, o para controlar un dispositivo — por nombrar solo algunos de los muchos problemas para que el software soluciones son posibles. Las formas en que los usuarios, los procesos de negocio y dispositivos función son típicamente complejos. Por extensión, por lo tanto, los requisitos de software en particular son típicamente una combinación compleja de los requisitos de diferentes personas en diferentes niveles de organización y del ambiente en el que el software funcionará.

Una característica esencial de todos los requisitos de software es que sean comprobables. Puede ser difícil o costoso para verificar ciertos requisitos de software. Por ejemplo, verificación de los requisitos de rendimiento en un centro de llamadas puede requerir el desarrollo de software de simulación. Tanto los requisitos de software y calidad

personal debe asegurarse de que los requisitos pueden verificarse dentro de las limitaciones de recursos disponibles.

Los Requisitos tienen otros atributos además de las propiedades del comportamiento que expresan. Los ejemplos más comunes incluyen un grado de prioridad a permitir compensaciones ante recursos finitos y un valor de estado para permitir el avance del proyecto a ser monitoreados. Por lo general, requisitos de software únicamente son identificados para que ellos puedan ser sometidos a control de la configuración del software y gestionados por el software todo el ciclo de vida.

1.2. Requerimientos de proceso y producto

Se puede distinguir entre parámetros de producto y proceso. Parámetros del producto son requisitos de software a desarrollarse (por ejemplo, "el software verificará que un estudiante cumple con todos los requisitos antes de que él o ella se registra para un curso").

Un parámetro de proceso es esencialmente una restricción en el desarrollo del software (por ejemplo, "el software deberá estar escrito en Java"). Estos son a veces conocidos como requisitos del proceso.

Algunos requisitos de software generan requisitos de proceso implícito. La elección de la técnica de verificación es un ejemplo. Otro podría ser el uso de técnicas de análisis particularmente riguroso (como los métodos de especificación formal) para reducir fallas que pueden conducir a la insuficiente fiabilidad. También podrán imponer requisitos de proceso directamente por la organización de desarrollo, sus clientes, o terceros como un regulador de seguridad.

1.3. Funcionales y los requisitos no funcionales

Los requisitos funcionales describen las funciones que el software se va a ejecutar; por ejemplo, formato de texto o una señal de modulación. Se conocen a veces como capacidades. Los requisitos no funcionales son los que actúan para restringir la solución.

Los requisitos no funcionales son a veces conocidos como restricciones o requisitos de calidad. Se pueden clasificar más lejos según sean los requisitos de rendimiento, requisitos de mantenimiento, los requisitos de seguridad, requisitos de fiabilidad o uno de muchos otros tipos de requisitos de software (véase también "Características de los modelos y calidad" en el Software de calidad KA)

1.4. Propiedades emergentes

Algunos requisitos representan propiedades emergentes de software — es decir, requisitos que no puede ser tratado por un solo componente, pero que dependen para su satisfacción sobre cómo interoperan todos los componentes de software. El requisito de rendimiento para un centro de llamadas, por ejemplo, depende cómo el sistema telefónico, el sistema de información y los operadores interactuaban bajo condiciones de

funcionamiento reales. Propiedades emergentes dependen crucialmente de la arquitectura del sistema.

.5. Requisitos Cuantificables

Los requisitos de Software, deberían indicarse claramente y sin ambigüedad posible y, cuando proceda, cuantitativamente. Es importante evitar los requerimientos de vagos y no se puede comprobar que dependen para su interpretación en juicio subjetivo ("el software será confiable"; "el software es fácil de usar"). Esto es particularmente importante para los requisitos no funcionales. Dos ejemplos de requisitos cuantificados son los siguientes: software de un centro de llamadas debe aumentar el rendimiento del centro en un 20%; y un sistema tendrá una probabilidad de generar un error fatal durante cualquier hora de operación de menos de 1 * 10−188 8. El requisito de rendimiento es a un nivel muy alto y es necesario utilizar para derivar una serie de requisitos detallados. El requisito de confiabilidad limitará fuertemente la arquitectura del sistema.

1.6. Requisitos del sistema y los requisitos de Software

En este tema, "sistema" significa "una interacción combinación de elementos para lograr un objetivo definido. Estos incluyen hardware, software, firmware, gente, información, técnicas, instalaciones, servicios y otros elementos de apoyo”.

Requisitos del sistema son los requisitos para el sistema como un todo. En un sistema que contiene componentes de software, requisitos de software se derivan de los requisitos del sistema. La literatura sobre los requisitos a veces llama requisitos del sistema "requisitos de usuario". La guía define "necesidades de los usuarios" de manera restringida como los requisitos de los clientes o usuarios finales del sistema. Requisitos del sistema, por el contrario, abarcan los requerimientos del usuario, requisitos de otras partes interesadas (por ejemplo, las autoridades reguladoras) y requisitos sin un origen humano identificable.

2. Proceso de Requisitos

Esta sección presenta el proceso de los requisitos del software, orientando las restantes cinco subareas y mostrando cómo los requisitos concuerdan con el proceso general de ingeniería de software.

2.1 Modelos de procesos.

El objetivo de este tema es proporcionar un entendimiento de que los requisitos del proceso:

No son una actividad de principio a fin discreta, del ciclo de vida del software, sino más bien un proceso iniciado al principio de un proyecto que sigue siendo refinado durante todo el ciclo de vida.

Identifica los requerimientos de software como elementos de configuración y los administra utilizando las mismas prácticas de gestión de configuración del software como otro producto de los procesos de ciclo de vida del software.

Debe ser adaptada al contexto y organización del proyecto.

En particular, el tema se refiere a cómo se configuran las actividades de obtención, análisis, especificación y validación para los diferentes tipos de proyectos y limitaciones. El tema también incluye actividades que proporcionan insumos en el proceso de requisitos, tales como los estudios de Marketing y viabilidad.

2.2 Actores del Proceso

Este tema presenta los roles de las personas que participan en el proceso de requisitos.

Este proceso es fundamentalmente interdisciplinario, y el especialista en requisitos necesita mediar entre el dominio de la parte interesada y la ingeniería de software. A menudo hay muchas personas involucradas además del especialista de requerimientos, cada uno de los cuales tiene una participación en el software. Las partes interesadas variarán a través de proyectos pero siempre incluirá los usuarios y operadores y clientes (que no tiene que ser el mismo).

Los ejemplos típicos de los actores de software incluyen (pero no están limitados a):

Usuarios: Este grupo comprende aquellos que operarán el software. A menudo es un grupo heterogéneo formado por personas con diferentes funciones y requisitos.

Clientes: este grupo está conformado por aquellos que han encargado el software o que representan el mercado objetivo del software.

Los analistas del mercado: un producto de Mercado masivo no tendrá una puesta en servicio al cliente, así que a menudo se necesitan personas de marketing para establecer lo que necesita el mercado y para actuar como clientes.

Reguladores: muchos dominios de aplicación, como lo bancario y el transporte público, se encuentran regulados. El software en estos dominios debe cumplir con los requisitos de las autoridades reguladoras.

Ingenieros de Software: estos individuos tienen un interés legítimo en el beneficio de desarrollar un software, por ejemplo, reutilizando los componentes en otros productos. Si en este escenario, un cliente de un producto en particular tiene necesidades específicas que comprometen las posibilidades de reutilización de componentes, los ingenieros de software deben pensar cuidadosamente su propio juego contra ésos del cliente.

No será posible satisfacer perfectamente las necesidades de todos los interesados, y es trabajo del ingeniero software negociar las compensaciones que sean aceptables a las principales partes interesadas y dentro del presupuesto, técnicas regulatorias y otras restricciones. Un requisito previo para esto es que todas las partes interesadas sean identificadas, la naturaleza de su "inversión" analizadas y sus requerimientos sacados.

2.3. Apoyo y Gestión de Procesos.

Este tema presenta los recursos de gestión de proyectos requeridos y consumidos por el proceso de requisitos. Establece el contexto para la primera subárea (definición de iniciación y alcance) de la Gestión de Ingeniería de Software. Su propósito principal es hacer el vínculo entre las actividades de proceso identificadas en el punto 2.1 y las cuestiones de costo, recursos humanos, capacitación y herramientas.

2.4. Proceso de calidad y mejora.

Este tema se refiere a la evaluación de la calidad y la mejora del proceso de requisitos. Su propósito es hacer hincapié en el papel clave que juega el proceso de requisitos en términos de costo y puntualidad de un producto de software y de la satisfacción del cliente con él. Ayudará a orientar el proceso de requisitos con estándares de calidad y modelos de mejora de procesos de software y sistemas. Calidad del proceso y mejora se relaciona estrechamente tanto el Software calidad KA y KA proceso de ingeniería del Software. Este tema se trata:

Requisitos de proceso, cobertura por estándares de mejora de procesos y modelos;

Requisitos de proceso de medidas y benchmarking (proceso sistemático y continuo para evaluar los productos, servicios y procesos de trabajo de las organizaciones);

Planificación de la mejora e implementación.

3. Elicitacion de Requerimientos

La elicitación de requisitos se refiere a la procedencia de requisitos de software y cómo el ingeniero de software puede juntarlos. Es la primera etapa en la construcción de una comprensión del problema del software que es necesaria para resolver. Es fundamentalmente una actividad humana y es donde se identifican los actores y las relaciones establecidas entre el equipo de desarrollo y el cliente. Varios la denominan "captura de requisitos", "descubrimiento de requisitos" y "adquisición de requisitos".

Uno de los principios fundamentales de la buena Ingeniería de software es que hay buena comunicación entre los actores del software e ingenieros de software. Antes de que comience el desarrollo, especialistas en requisitos pueden formar el conducto para la comunicación. Deben mediar entre el dominio de los usuarios del software (y otras partes interesadas) y el mundo técnico del ingeniero de software.

Un elemento crítico de la elicitación de requisitos es informar el alcance del proyecto. Se trata de proporcionar una descripción del software a ser especificado y su propósito, priorizando las entregas para garantizar que se satisfacen las necesidades del cliente más importantes del negocio, primero. Esto reduce el riesgo de que los especialistas de requisitos demoren más tiempo elicitando requisitos que son de poca importancia o aquellos que resultan ya no ser relevantes cuando el software se es entregado.

3.1. Fuentes de Requisitos.

Los requisitos tienen muchas fuentes en el software típico, y es esencial que todas las fuentes potenciales sean identificadas y evaluadas. Este tema está diseñado para promover el conocimiento de las distintas fuentes de requisitos de software y de los marcos para gestionarlos. Son los puntos principales cubiertos:

Objetivos. El término "objetivo" (a veces llamado "la preocupación de negocio" o "factor crítico de éxito") se refiere a los objetivos generales de alto nivel del software. Los objetivos proporcionan la motivación para el software pero son a menudo vagamente formulados. Los Ingenieros de software necesitan prestar especial atención a la evaluación del valor (en relación con prioridad) y costo de las metas. Un estudio de viabilidad es una forma relativamente barata de hacer esto.

Conocimiento de dominio. El ingeniero de software necesita adquirir o disponer, conocimiento sobre el dominio de aplicación. El conocimiento del dominio proporciona el fondo contra el cual deben establecerse requisitos sacando todos los conocimientos para entenderlo.

Partes interesadas (véase tema 2.2 actores del proceso). Muchos software han demostrado ser satisfactorios porque lo han subrayado las necesidades de un grupo de partes interesadas a expensas de los demás. Por lo tanto, el software suministrado es difícil de usar o subvierte las estructuras culturales o políticas de la organización del cliente. El ingeniero de software debe identificar, representar y administrar los "miradores" de muchos tipos diferentes de las partes interesadas.

Reglas del negocio. Estas son declaraciones que definen o limitan algunos aspectos de la estructura o el comportamiento del negocio propio. "Un estudiante no puede registrarse en cursos del próximo semestre si quedan algunos sin pagar la matrícula" sería un ejemplo de una regla de negocio que sería una fuente de requisito para el software de registro de curso de una universidad.

El entorno operativo. Los requisitos se derivarán del ambiente en el cual se ejecutará el software. Estos pueden ser, por ejemplo, restricciones de sincronización en tiempo real del software o interoperabilidad restricciones en un ambiente de negocios. Estos deben ser activamente buscados porque pueden en grandes proporciones afectar la factibilidad y costo del software así como restringir las opciones de diseño.

El clima organizacional. Un software es a menudo necesario para apoyar un proceso de negocio, la selección de los cuales puede estar condicionada por la estructura, la cultura y la política interna de la organización. Las necesidades del ingeniero de software deben ser sensibles a estos ya que, en general, un nuevo software no debería obligar a un cambio imprevisto en los procesos de negocio.

3.2. Técnicas de Elicitación.

Una vez que se han identificado las fuentes de requisitos, el ingeniero de software puede empezar a obtener la información de requisitos de ellos. Tenga en cuenta que los requisitos son rara vez sacados o confeccionados. Por el contrario, el ingeniero de

software provoca que se formulen los requerimientos de información. Este tema se centra en las técnicas para conseguir actores humanos para articular la información relacionada con los requisitos. Es una tarea muy difícil y el ingeniero de software debe sensibilizarse al hecho de que los usuarios (por ejemplo) pueden tener dificultades para describir sus tareas, pueden dejar importante información que no se expresa o pueden ser incapaces de cooperar. Es particularmente importante entender que la elicitación no es una actividad pasiva y que, incluso si actores cooperativos y articulados están disponibles, el ingeniero de software tiene que trabajar duro para obtener la información correcta. Gran parte de los negocios o los requerimientos técnicos es tácito o en comentarios que aún debe obtenerse de los usuarios finales. No puede exagerarse la importancia de la planificación, verificación y validación en toma de requerimientos. Existe un número de técnicas para la toma de requerimientos, siendo los principales:

Entrevistas. un medio "tradicional" de obtención de requisitos. Es importante comprender las ventajas y limitaciones de las entrevistas y cómo debe realizarse.

Escenarios, significa un valioso contexto para proporcionar la elicitación de requisitos de usuario. Permiten al ingeniero de software proporcionar un marco para preguntas acerca de las tareas del usuario permitiendo que "si" y "Cómo se hace esto" sean preguntas que formular. El tipo más común de escenario es la descripción de casos de uso. Hay un enlace a topic4.2 (modelado Conceptual) porque las notaciones de escenario como diagramas de casos de uso son comunes en software de modelado.

Prototipos, una valiosa herramienta para clarificar los requisitos claros. Pueden actuar de una manera similar a escenarios ofreciendo a los usuarios un contexto dentro del cual puedan entender mejor qué información necesitan proporcionar. Hay una amplia gama de técnicas de prototipos de maquetas de papel, de diseños de pantalla a las versiones beta-test de productos de software y un fuerte compromiso de su propio uso por separado para la toma de requerimientos y validación de requisitos (Ver tema 6.2 Prototipos).

Facilitación de reuniones. El propósito de estos encuentros es tratar de lograr un efecto sumatorio, por el que un grupo de personas puede aportar una visión más clara en sus requerimientos de software que al trabajar individualmente. Pueden pensar y refinar ideas que pueden ser difíciles de llevar a la superficie mediante entrevistas. Otra ventaja es que los requisitos de superficie pueden ser contradictorios desde el principio de una manera que permite a las partes interesadas reconocer donde hay conflicto. Cuando funciona bien, esta técnica puede resultar en una serie de requisitos más rica y más consistente de lo contrario podría ser factible. Sin embargo, las reuniones deben ser manipuladas con cuidado (por lo tanto, la necesidad de un facilitador) para prevenir una situación en la cual las capacidades críticas del equipo están erosionadas por lealtad de grupo o en los requisitos que refleja las preocupaciones de algunas personas abiertamente (y quizás último) son favorecidas en detrimento de otros.

Observación. La importancia del contexto de software en el entorno organizacional ha llevado a la adaptación de las técnicas observacionales como etnografía para toma de requerimientos. Ingenieros de software aprenden acerca de las tareas del

usuario que se sumerge en el ambiente y observando cómo los usuarios realizan sus tareas al interactuar con los demás y con herramientas de software y otros recursos. Estas técnicas son relativamente caras pero también instructivas porque ilustran muchas tareas de usuario y procesos de negocios que son muy sutiles y complejos para que sus actores puedan describir fácilmente.

Historias de usuario. Esta técnica se utiliza comúnmente en metodologías ágiles (vea el tema "Métodos ágiles" en el área de conocimiento de métodos y modelos de ingeniería de Software) y se refiere a las descripciones cortas de alto nivel de funcionalidad requerida expresada en términos de atención al cliente. Una historia de usuario está destinada a contener suficiente información para que los desarrolladores puedan producir una estimación razonable del esfuerzo para implementarlo. El objetivo es evitar algunos de los residuos que suceden a menudo en proyectos donde están reunidos los requisitos detallados anteriormente pero deben ser válidos antes de que comience el trabajo. Antes de implementar una historia de usuario, deberá escribirse un procedimiento apropiado de aceptación por parte del cliente para determinar si se han cumplido los objetivos de la historia de usuario.

Otras técnicas. Existe una variedad de otras técnicas para apoyar la elicitación de requisitos de información y van desde análisis de productos de la competencia a la aplicación de técnicas de minería de datos a utilizar fuentes de bases de dominio, conocimiento o petición de cliente.

4. Análisis de requerimientos.

Este tema tiene que ver con el proceso de analizar los requisitos para:

Detectar y resolver conflictos entre requisitos. Descubre los límites del software y de cómo debe interactuar con su ambiente. Requisitos del sistema elaborado para derivar requerimientos de software.

La visión tradicional del análisis de requerimientos ha sido que se reduzca el Modelado conceptual utilizando uno de un número de métodos de análisis, tales como el método de análisis estructurado. Mientras que el modelado conceptual es importante, se incluye la clasificación de los requisitos para ayudar a informar disyuntivas entre requisitos (clasificación de requisitos) y el proceso de establecer estas disyuntivas (negociación de requisitos).

Debe tenerse cuidado para describir los requisitos precisamente lo suficiente para permitir que los requisitos sean validados para su aplicación, verificando sus costos para ser estimados.

4.1. Clasificación de los Requisitos.

Los requisitos se pueden clasificar en varias dimensiones. Los ejemplos incluyen:

Si el requisito es funcional o no funcional (Ver tema 1.3 requisitos funcionales y no funcionales).

Si el requisito es derivado de uno o más requisitos de alto nivel o de una propiedad emergente (véase tema 1.4 propiedades emergentes) o está imponiendo directamente en el software de un participante o de alguna otra fuente.

Si el requisito es sobre el producto o el proceso (véase 1.2 producto y requisitos de proceso). Los requisitos en el proceso pueden restringir la elección del contratista, el proceso de ingeniería de software para ser adoptado o las normas a seguirse.

La prioridad del requisito. Cuanto mayor sea la prioridad, lo más esencial es el requisito para cumplir los objetivos generales del software. A menudo se clasifican en una escala de punto fijo como obligatorio, altamente deseable, deseable, u opcional, la prioridad a menudo tiene que sopesar el costo de desarrollo e implementación. La priorización de requisitos es necesaria no sólo como un medio para filtrar requisitos importantes, sino también para resolver los conflictos y planes de puesta en escena de las entregas, lo que significa tomar decisiones complejas que requieran dominio detallado de los conocimientos y habilidades de buena estimación. Sin embargo, a menudo es difícil obtener información real que puede actuar como una base para este tipo de decisiones. Además, los requisitos a menudo dependen mutuamente y sus prioridades son relativas. En la práctica, ingenieros de software realizan priorización de requerimientos con frecuencia sin conocer todos los requisitos.

El alcance del requisito. Este ámbito de aplicación se refiere a la medida en que afecta un requisito del software y componentes de software. Algunos requisitos, especialmente los no funcionales, tienen un alcance global en que su satisfacción no puede asignarse a un componente discreto. Por lo tanto, un requisito con ámbito global afecta fuertemente a la arquitectura de software y el diseño de muchos componentes, mientras que uno con un alcance acotado puede ofrecer un número de opciones de diseño y tienen poco impacto en la satisfacción de otras necesidades.

Volatilidad/estabilidad. Algunos requisitos cambiarán durante el ciclo de vida del software e incluso durante el proceso de desarrollo propio. Es útil si se puede hacer una estimación de la probabilidad de que un requisito va a cambiar. Por ejemplo, en una aplicación bancaria, los requisitos de las funciones para calcular el interés de crédito de las cuentas de los clientes serán probablemente más estables que un requisito para apoyar un tipo particular de cuenta libre de impuestos. Los primeros reflejan una característica fundamental del dominio bancario (que cuentas pueden ganar interés), mientras que este último puede ser obsoleta por un cambio en la legislación del gobierno. Al marcar los requisitos potencialmente volátiles puede ayudar al ingeniero de software a establecer un diseño que es más tolerante al cambio.

Otras clasificaciones pueden ser apropiadas, dependiendo de la práctica habitual de la organización y de la propia aplicación.

Hay una fuerte superposición entre la clasificación de los requisitos y atributos de requisitos (véase tema 7.3 requisitos atributos).

4.2. Modelado conceptual.

El desarrollo de modelos de un problema del mundo real es clave para el análisis de requisitos de software. Su propósito es ayudar a comprender el problema, más que todo para iniciar el diseño de la solución. Por lo tanto, los modelos conceptuales constituyen modelos de entidades del problema de dominio configurado para reflejar sus reales relaciones y dependencias. Este tema está estrechamente relacionado al área de conocimiento de métodos y modelos de ingeniería de Software.

Se pueden desarrollar varios tipos de modelos. Estos incluyen diagramas de casos de uso, modelos de flujo de datos, modelos de estado, los modelos basados en la meta, las interacciones del usuario, modelos de objetos, modelos de datos y muchos otros. Muchas de estas notaciones de modelado son parte de la Unified Modeling Language (UML). Diagramas de casos de uso, por ejemplo, se utilizan habitualmente para proporcionar un medio de representar el límite de software, una vista de alto nivel de su comportamiento (los casos de uso) y los actores en el entorno de software.

Los factores que influyen en la elección de la notación de modelado incluyen:

La naturaleza del problema. Algunos tipos de software demandan que algunos aspectos se analicen rigurosamente. Por ejemplo, los estados y modelos paramétricos, que forman parte de SysML [2], son propensos a ser más importante para el software en tiempo real que para los sistemas de información, mientras que normalmente sería lo contrario para los modelos de objeto y actividad.

La experiencia del ingeniero de software. Suele ser más productivo de adoptar la notación de modelado o método con el cual el ingeniero de software tiene experiencia.

Los requisitos del proceso del cliente (Ver tema 1.2 requerimientos de proceso y producto). Los clientes pueden imponer su notación favorecida o método o prohibir que son desconocidos. Este factor puede entrar en conflicto con el factor anterior.

Tenga en cuenta que, en casi todos los casos, es útil comenzar con la construcción de un modelo del contexto de software. El contexto de software proporciona una conexión entre el software previsto y su ambiente externo. Esto es crucial para entender el contexto del software en su entorno operacional y la identificación de sus interfaces con el medio ambiente.

Este tema no pretende "enseñar" un estilo particular de modelado o notación pero proporciona una guía sobre el propósito y la intención de modelado.

4.3. Proyectos arquitectónicos y asignación de requisitos.

En algún momento, la arquitectura de la solución debe ser derivada. El diseño arquitectónico es el punto en que el proceso de requisitos se superpone con el diseño de software o sistemas e ilustra lo imposible que es separar limpiamente las dos tareas. Este tema se relaciona estrechamente con la subzona de Software. En muchos casos, el ingeniero de software actúa como arquitecto de software porque el proceso de analizar y

elaborar los requisitos exige que los componentes que se encargan de satisfacer los requisitos deban ser identificados. Esta es la asignación de requisitos, la asignación a los componentes de la responsabilidad de satisfacer los requisitos.

La asignación es importante para permitir un análisis detallado de los requisitos. Por lo tanto, por ejemplo, una vez que un conjunto de requisitos ha sido asignado a un componente, las necesidades individuales pueden ser más analizadas para descubrir aún más los requisitos de cómo el componente necesita interactuar con otros componentes con el fin de satisfacer los requisitos asignados. En grandes proyectos, la asignación estimula una nueva ronda de análisis para cada subsistema. Por ejemplo, los requisitos para un determinado rendimiento de frenado para un auto (distancia de frenado, condiciones de seguridad en la conducción pobre, suavidad de aplicación, presión en el pedal requerida) pueden asignarse al hardware frenado (Asambleas mecánicas e hidráulicas) y un sistema de frenos antibloqueo (ABS). Sólo cuando se ha identificado un requisito para un sistema de frenado antibloqueo, y los requisitos asignados a él, puede las capacidades del ABS, el frenado hardware y propiedades emergentes (como el peso del coche) utilizarse para identificar los requisitos detallados del software ABS.

El diseño arquitectónico está estrechamente identificado con modelado conceptual (Ver tema 4.2 modelado Conceptual).

4.4. Requisitos de negociación.

Otro término usado comúnmente para este subtema es "resolución de conflictos". Esto concierne en resolver problemas con requisitos donde se producen conflictos entre dos actores que requieren características mutuamente incompatibles, entre recursos y requisitos o entre los requerimientos funcionales y no funcionales, por ejemplo. En la mayoría de los casos, no es prudente para el ingeniero de software tomar una decisión unilateral, y entonces se hace necesario consultar con las partes interesadas para alcanzar un consenso sobre una compensación adecuada. A menudo es importante, por razones contractuales, que tales decisiones sean trazables al cliente. Hemos clasificado esto como un tema de análisis de requisitos de software porque surgen problemas como el resultado del análisis. Sin embargo, también puede hacerse un fuerte caso por considerarlo un tema de validación de requisitos.

4.5. Análisis formal.

Las preocupaciones del análisis formal conciernen no sólo a la sección 4, sino también al inciso 5.3 y 6.3. Este tema también está relacionado con el tema "Métodos formales" en el área de conocimiento de métodos y modelos de ingeniería de Software. El análisis formal ha tenido un impacto en algunos dominios de aplicación, particularmente los de sistemas de alta integridad. La expresión formal de los requisitos requiere un lenguaje con semántica formalmente definida. El uso de un análisis formal para la expresión de requisitos tiene dos ventajas. En primer lugar, permite a los requisitos expresados en el lenguaje especificarse con precisión y sin ambigüedades, por lo tanto (en principio) evitando la posibilidad de una interpretación errónea. En segundo lugar, los requisitos se

pueden razonar, permitiendo propiedades deseadas del software especificado que debe ser probado. El razonamiento formal requiere herramientas de apoyo que sean posible para que no sean sistemas y herramientas triviales que generalmente caen en dos tipos; Teoremas o damas modelo. En ningún caso puede probar ser completamente automatizado, y el nivel de competencia en razonamiento formal necesario para utilizar las herramientas restringe la aplicación más amplia del análisis formal.

El análisis más formal se centra en etapas relativamente tardías de análisis de requerimientos. Es generalmente contraproducente aplicar formalización hasta los objetivos de negocio y las necesidades de los usuarios han entrado bien enfocadas a través de medios como los que se describe en la sección 4. Sin embargo, una vez los requisitos se hayan estabilizado y elaborado para especificar las propiedades concretas del software, puede ser beneficioso formalizar al menos los requisitos críticos. Esto permite la validación estática del software especificado por los requisitos; de hecho tiene las propiedades (por ejemplo, ausencia de bloqueo) que el ingeniero de software, los usuarios y clientes que esperan.

5. Especificación de los requisitos.

Para las profesiones de ingeniería, el término "especificación" se refiere a la asignación de valores numéricos o límites objetivos de diseño de un producto. En la jerga de la ingeniería de software, "especificación de requisitos de software" se refiere normalmente a la producción de un documento que puede ser sistemáticamente revisado, evaluado y aprobado. Para los sistemas complejos, especialmente aquellos que involucran componentes de software no-substanciales, tantos como tres diferentes tipos de documentos se producen: definición de sistema, requisitos del sistema y requisitos de software. Para productos de software simple, sólo la tercera parte de éstos se requiere. Los tres documentos se describen aquí, con el entendimiento de que se puede combinar según corresponda. Puede encontrarse una descripción de los sistemas de ingeniería en las disciplinas relacionadas de Ingeniería de Software.

5.1. Documento de definición del sistema.

Este documento (a veces conocido como el documento de requisitos de usuario o el concepto de operaciones) registra los requisitos del sistema. Define los requisitos de alto nivel del sistema desde la perspectiva de dominio. Sus lectores incluyen representantes de los usuarios/clientes de sistema (marketing puede desempeñar estas funciones de software orientados al mercado), así que su contenido debe ser redactado en términos de dominio. El documento enumera los requisitos del sistema junto con información acerca de los objetivos generales para el sistema, su entorno de destino y una declaración de las limitaciones, supuestos y los requisitos no funcionales. Puede incluir modelos conceptuales diseñados para ilustrar el contexto del sistema, los escenarios de uso y las entidades de dominio principal, así como los flujos de trabajo.

5.2. Sistema de especificación de requisitos.

Los desarrolladores de sistemas con software substancial y componentes de software — un avión moderno, por ejemplo — a menudo separan la descripción de los requisitos del sistema de la descripción de requisitos de software. En este punto de vista, se especifican los requisitos del sistema, los requisitos de software se derivan de los requisitos del sistema, y luego se especifican los requisitos para los componentes de software. Estrictamente hablando, especificación de requisitos de sistema es una actividad de ingeniería de sistemas y cae fuera del alcance de esta guía.

5.3. Software de especificación de requisitos.

El software de especificación de requisitos establece las bases para el acuerdo entre clientes y contratistas o proveedores (en proyectos impulsados por el mercado, estas funciones pueden ser interpretadas por las divisiones de marketing y desarrollo) en lo que es el producto de software a hacer así como lo que no se espera que haga.

El software de especificación de requisitos permite una evaluación rigurosa de los requisitos, antes del diseño se puede comenzar y reducir el rediseño más adelante. Asimismo deberá aportar una base realista para la estimación de los horarios, los riesgos y los costos del producto.

Las organizaciones también pueden utilizar un documento de especificación de requisitos de software para desarrollar sus propios planes de validación y verificación más productivamente.

El software de especificación de requisitos proporciona una base informada para transferir un producto de software a nuevos usuarios o plataformas de software. Por último, puede proporcionar una base para la mejora de software.

Los requisitos de software a menudo están escritos en lenguaje natural, pero en el software de especificación de requisitos, esto podrá completarse con las descripciones formales o semi-formales. La selección de notaciones apropiadas permite requisitos específicos y aspectos de la arquitectura de software que se describirán más precisa y concisamente ese lenguaje natural. La regla general es que se deben utilizar notaciones que permiten la mayor precisión posible de los requisitos para ser descrito. Esto es particularmente crucial para críticos y ciertos otros tipos de software confiable. Sin embargo, la elección de la notación a menudo está limitada por la formación, habilidades y preferencias de los lectores y autores del documento.

Una serie de indicadores de calidad han desarrollado, que puede utilizarse para relacionar la calidad de la especificación de requisitos de software para otras variables del proyecto como costo, aceptación, rendimiento, horario y reproducibilidad. Los indicadores de calidad para las declaraciones de especificación de requisitos software individual son imperativos, directivas, frases débiles, opciones y aplazamientos. Los indicadores para el documento de especificación de requisitos software completo incluyen tamaño, legibilidad, especificación, profundidad y estructura del texto.

6. Validación de requisitos.

Los documentos de los requisitos pueden estar sujetos a procedimientos de validación y verificación. Los requisitos pueden ser validados para asegurarse de que el ingeniero de software ha comprendido los requisitos; también es importante verificar que un documento de requisitos conforme a las normas de la empresa debe ser entendible, coherente y completo. Notaciones formales ofrecen la ventaja de permitir que las dos últimas propiedades deban ser probadas (en un sentido restringido, por lo menos). Diferentes actores, incluyendo a representantes del cliente y desarrollador, deben revisar los documentos. Los documentos de requisitos están sujetos a las mismas prácticas de gestión de configuración de software que las otras entregas de los procesos de ciclo de vida del software.

Es normal programar uno o más puntos en el proceso de requisitos donde se validan los requisitos. El objetivo es recoger cualquier problema antes de que los recursos se hayan comprometido a atender los requerimientos. La validación de requisitos se refiere al proceso de examinar el documento de requisitos para garantizar que se define el software adecuado (es decir, el software que los usuarios esperan).

6.1. Comentarios de los requisitos.

Quizás los medios más comunes de validación son por inspección o revisiones del documento de requisitos. Se asigna un grupo de árbitros para buscar errores, suposiciones erróneas, falta de claridad y la desviación de la práctica estándar. La composición del grupo que realiza la revisión es importante (al menos un representante del cliente debe ser incluido en un proyecto orientado hacia el cliente, por ejemplo), y puede ayudar a proporcionar orientación sobre lo que debe buscar en forma de listas.

Los comentarios podrán estar constituidos al finalizar el documento de definición del sistema, el documento de especificación del sistema, el documento de especificación de requisitos de software, la especificación de línea de base para una nueva versión, o en cualquier otro paso en el proceso.

6.2. Creación de un prototipo.

Los prototipos comúnmente son un medio para la validación de interpretación al ingeniero de software de los requisitos de software, así como para la obtención de nuevos requerimientos. Como con el desencadenamiento, hay una gama de técnicas de creación de prototipos y una serie de puntos en el proceso donde la validación del prototipo puede ser apropiado. La ventaja de los prototipos es que pueden llegar más fácil a interpretar supuestos del ingeniero de software y, donde sea necesario, dar información útil sobre por qué se equivocan. Por ejemplo, se puede entender mejor el comportamiento dinámico de una interfaz de usuario a través de un prototipo animado que a través de la descripción textual o modelos gráficos. También hay desventajas, estos incluyen el peligro de que la atención de los usuarios pueda distraerse del núcleo de la funcionalidad subyacente por cuestiones cosméticas o problemas de calidad con el prototipo. Por esta razón, algunos abogan por prototipos que eviten el software, tales como maquetas basados en el portafolio. Los prototipos pueden ser costosos para desarrollar, sin embargo, si evitan el

despilfarro de recursos causado por intentar satisfacer requisitos erróneos, su costo puede justificarse más fácilmente.

6.3. Modelo de validación.

Es normalmente necesario validar la calidad de los modelos desarrollados durante el análisis. Por ejemplo, en modelos de objetos, es útil a la colección, un análisis estático para verificar que existen vías de comunicación entre objetos que, en el dominio de las partes interesadas, intercambian datos. Si se utilizan las notaciones de análisis formal, es posible utilizar un razonamiento formal para probar las propiedades de la especificación. Este tema está estrechamente relacionado con los métodos y modelos de ingeniería de Software.

6.4. Aceptación de pruebas.

Una característica esencial de un requisito de software es que debe ser posible validar que satisface el producto terminado. Requisitos que no pueden ser validados son realmente "deseos". Una tarea importante es estar planeando cómo comprobar cada requisito. En la mayoría de los casos, diseñar pruebas de aceptación hace esto.

Identificar y diseñar pruebas de aceptación pueden ser difíciles para los requisitos no funcionales (Ver tema 1.3 funcionales y los requisitos no funcionales). Para ser validado, primero deben ser analizados y descompuestos al punto donde ellos pueden expresarse cuantitativamente.

Información adicional puede encontrarse en el KA de pruebas de Software, pruebas de aceptación/calificación/pruebas de conformidad.

7. Consideraciones Prácticas.

El primer nivel de descomposición de la subzona presentado puede parecer describir una secuencia lineal de actividades. Esta es una visión simplificada del proceso.

El proceso de requisitos extiende el ciclo de vida de todo software. La administración de cambios y el mantenimiento de los requisitos de un estado que refleja con precisión el software a construir, o que ha sido construido, es clave para el éxito del proceso de ingeniería del software.

No toda organización tiene una cultura de documentación y gestión de requisitos. Es común en empresas dinámicas, impulsadas por una fuerte "visión de producto" y recursos limitados, ver la documentación de los requisitos como una sobrecarga innecesaria. Más a menudo, sin embargo, a medida que estas empresas aumentan, como su cliente base crece, y cuando su producto comienza a evolucionar, descubren que tienen que recuperar los requisitos que motivaron características del producto con el fin de evaluar el impacto de los cambios propuestos. Por lo tanto, los requisitos documentación y gestión del cambio son clave para el éxito de cualquier proceso de requisitos.

7.1. Naturaleza interactiva del proceso de requisitos.

Hay presión general en la industria del software para que haya ciclos de desarrollo más cortos y esto es particularmente pronunciado en sectores altamente competitivos, impulsado por el mercado. Además, la mayoría de proyectos está limitada de alguna manera por su entorno, y muchos son actualizaciones o revisiones de software existente donde la arquitectura es dada. Por lo tanto, en la práctica casi siempre resulta poco práctico implementar el proceso de requisitos como un proceso lineal y determinista en que el software de requisitos es sacado de las partes interesadas, asignado y entregado al equipo de desarrollo de software. Ciertamente es un mito que los requisitos para grandes proyectos de software son siempre perfectamente entendidos o perfectamente especificados.

En cambio, los requisitos normalmente interactúan hacia un nivel de calidad y detalle suficiente para permitirle a las decisiones de diseño y aprovisionamiento realizarse. En algunos proyectos, esto puede resultar ser una base ante todas sus propiedades que se entienden plenamente en los requisitos. El riesgo es que el trabajo sea costoso si surgen problemas en el proceso de ingeniería de software. Sin embargo, los ingenieros de software están necesariamente limitados por planes de gestión de proyecto y por lo tanto, deben tomar medidas para asegurarse de que la “calidad” de los requisitos sea lo más alta posible dados los recursos disponibles. Deberían, por ejemplo, hacer explícitamente las suposiciones que apuntan los requisitos, así como problemas conocidos.

En casi todos los casos proceden requisitos de comprensión que siguen evolucionando el diseño y desarrollo. Esto a menudo conduce a la revisión de los requisitos en el ciclo de vida. Quizás el punto más crucial en el entendimiento de la ingeniería de requerimientos es que una proporción significativa de los requerimientos va a cambiar. Esto es a veces debido a errores en el análisis, pero con frecuencia es una consecuencia inevitable del cambio en el “ambiente”, por ejemplo, el cliente de funcionamiento, o el ambiente de negocios, o el mercado en que el software debe vender. Cualquiera que sea la causa, es importante reconocer la inevitabilidad del cambio y tomar medidas para mitigar sus efectos. El cambio tiene que gestionarse para asegurar que los cambios propuestos pasen por una revisión definida y un proceso de aprobación y, mediante la aplicación de requisitos cuidadosos como el seguimiento, análisis y gestión de la configuración de software de impacto. Por lo tanto, el proceso de requisitos no es simplemente una tarea de principio a fin en el desarrollo del software sino que se extiende a todo el ciclo de vida de un software. En un proyecto típico, las actividades de los requisitos de software evolucionan con el tiempo de estimulación a la gestión del cambio.

7.2 Gestión del Cambio.

La gestión del cambio es fundamental para la gestión de requisitos. Este tema describe el papel de la gestión del cambio, los procedimientos que deben estar en el lugar y el análisis que debe aplicarse a los cambios propuestos.

7.3 Atributos de los Requisitos.

Los requisitos deben consistir solo de una especificación de lo que se necesita, sino también de información auxiliar, que ayuda a administrar e interpretar los requisitos. Esto debe incluir las diversas dimensiones de la clasificación de los requisitos y el método de verificación o aceptación relevante. También puede incluir información adicional, como una justificación sumaria para cada requisito, la fuente de cada requisito y un historial de cambios. El atributo más importante, es un identificador que permite a los requisitos identificarse única e inequívocamente.

7.4 Requisitos de Rastreo.

Los requisitos de seguimiento se refieren a recuperar la fuente de los requisitos y predecir los efectos de este. Un trazado es fundamental para realizar un análisis de impacto cuando los requerimientos cambian. Un requisito debe ser trazable al revés de los requerimientos y las partes interesadas que lo motivaron. Por el contrario, un requisito debe ser trazable para que remita a las entidades de diseño que satisfacen.

7.5 Requisitos de Medición.

Como una cuestión practica, es típicamente útil tener algún concepto del “volumen” de los requisitos para un producto de software en particular. Este número es útil para evaluar el “tamaño” de un cambio en los requisitos, al estimar el costo de una tarea de mantenimiento o desarrollo, o simplemente para el uso como denominador en otras medidas. La medida del tamaño funcional (MTF) es una técnica para evaluar el tamaño de un cuerpo de requerimientos funcionales.

8. Requisitos de las herramientas del software.

Las herramientas para tratar con requisitos de software en términos generales se dividen en dos categorías: herramientas de modelado y herramientas para la gestión de requisitos.

Las herramientas para la gestión de requisitos suelen apoyar una gama de actividades, incluyendo documentación, seguimiento y gestión del cambio y han tenido un impacto significativo en la práctica. De hecho, gestión de cambio y seguimiento son realmente factibles si son compatibles con una herramienta. Puesto que es fundamental para la práctica de los requisitos una buena gerencia del requisito, muchas organizaciones han invertido en herramientas de gestión de requisitos, aunque muchos más gestionan sus requerimientos y generalmente de maneras menos satisfactorias.