REQUISITOS DE SOFTWARE

CIA Confidencialidad, Integridad y disponibilidad

DAG Dirigido acíclicos Gráfico

FSM Tamaño Medida Funcional

INCOSE Consejo Internacional de Sistemas ingeniería

UML lenguaje de modelado unificado

SysML sistemas de lenguaje modelado

INTRODUCCIÓN

El área Requisitos de software del conocimiento (KA) se refiere a la obtención, análisis, especificación, y validación de requisitos de software así como la gestión de requisitos durante todo el ciclo de vida del producto de software.

Es ampliamente reconocido entre los investigadores y profesionales de la industria que los proyectos de software son críticamente vulnerables cuando el requirementsrelated las actividades están mal realizadas.

Requisitos de software expresan las necesidades y

las restricciones impuestas a un producto de software que

contribuir a la solución de algunos-mundo real

problema.

La "ingeniería de requisitos" plazo es ampliamente

utilizado en el campo para indicar la manipulación sistemática

de requisitos. Por razones de coherencia, la

término "ingeniería" no se utilizará en este KA

excepto para la ingeniería del software en sí.

Por la misma razón, "requisitos ingeniero"

un término que aparece en la parte de la literatura,

no se utilizarán tampoco. En cambio, el término "software

ingeniero "o, en algunos casos específicos," Requisitos

especialista "se utilizará, este último donde

el papel en cuestión se realiza generalmente por una

persona que no sea un ingeniero de software. Esta

no implica, sin embargo, que un ingeniero de software

no pudo realizar la función.

Un riesgo inherente en el desglose propuesto es

que un proceso en cascada como se puede inferir. A

guardia contra esto, tema 2, Requisitos de Proceso,

está diseñado para proporcionar una visión general de alto nivel de la

requisitos de proceso por el que se establecen los recursos

y las restricciones bajo las cuales opera el proceso

y que actúan para configurarlo.

Una descomposición alternativo podría utilizar un producto basado-

estructura (requisitos del sistema, el software

requisitos, prototipos, casos de uso, y

así sucesivamente). El desglose basado en procesos refleja

el hecho de que el proceso de los requisitos, si se trata de

tenga éxito, debe ser considerado como un proceso

involucrando actividades complejas, fuertemente acoplados

(Tanto secuencial y concurrente), en lugar de como una

discreta, de una sola vez actividad realizada desde el principio

de un proyecto de desarrollo de software.

La Requisitos de software KA es relacionada

estrechamente al software de diseño, pruebas de software,

Mantenimiento de Software, Software de Configuración

Gestión, Software de Gestión de Ingeniería,

Software Ingeniería de Procesos, Software

Modelos y métodos de ingeniería y software

Kas Calidad.

DESGLOSE DE TEMAS PARA

REQUISITOS DE SOFTWARE

El desglose de los temas para el Software

Requisitos KA se muestra en la Figura 1.1.

1. Requisitos de software Fundamentos

[1 *, c4, c4s1, c10s1, c10s4] [2 *, C1, C6, C12]

1.1. Definición de un requisito de software

En su forma más básica, un requisito de software es un

propiedad que debe ser exhibido por algo en Para resolver algún problema en el mundo real. Eso

puede apuntar para automatizar parte de una tarea para alguien

para apoyar los procesos de negocio de una organización,

para corregir deficiencias de software existente,

o para controlar un dispositivo para nombrar sólo algunos de los

muchos problemas para los que las soluciones de software son

posible. Las formas en que los usuarios, procesos de negocio,

y la función de los dispositivos suelen ser complejos.

Por extensión, por lo tanto, los requisitos en particular,

software suelen ser una combinación compleja

de varias personas en diferentes niveles de una

organización, y que están en una forma u otra

implicados o relacionados con esta función desde el

entorno en el que el software operará.

Una propiedad esencial de todos los requisitos de software

es que sean verificables como un individuo

función como requisito funcional o en la

nivel de sistema como un requisito no funcional. Eso

puede ser difícil o costoso para verificar determinado software

requisitos. Por ejemplo, la verificación

del requisito de rendimiento en un centro de llamadas

puede requerir el desarrollo de la simulación

software. Requisitos de software, pruebas de software,

y personal de calidad debe asegurar que el requisitos pueden ser verificados dentro disponibles

las limitaciones de recursos.

Requisitos tienen otros atributos además

a las propiedades de comportamiento. Los ejemplos más comunes

incluir una clasificación de prioridad para permitir compensaciones en

la cara de recursos finitos y un valor de estado a

permitir a los avances del proyecto a ser monitoreados. típicamente,

requisitos de software se identifican de forma única

de modo que puedan ser sometidos a la configuración del software

gestión durante todo el ciclo de vida

de la función y del software.

1.2. Productos y procesos Requisitos

Un requisito producto es una necesidad o restricción en

el software a ser desarrollado (por ejemplo, "El

software verificará que un estudiante cumple con todos los requisitos previos

antes de que él o ella se registra para un curso ").

Un requisito proceso es esencialmente una restricción

en el desarrollo del software (por

ejemplo, "El software se ha desarrollado utilizando

un proceso RUP ").

Algunos requisitos de software generan implícita

requisitos del proceso. La elección de verificación técnica es un ejemplo. Otro podría ser el

uso de técnicas de análisis particularmente rigurosos

(Tales como los métodos de especificación formales) para reducir

fallos que pueden conducir a la fiabilidad inadecuada. Proceso

requisitos también pueden ser impuestas directamente

por la organización de desarrollo, sus clientes,

o de un tercero, como un regulador de la seguridad.

1.3. Requisitos funcionales y no funcionales

Requisitos funcionales describen las funciones

que el software es ejecutar; por ejemplo, el formato

algún texto o la modulación de una señal. Ellos

a veces son conocidos como las capacidades o características.

Un requisito funcional también se puede describir

como uno de los que un conjunto finito de pasos de prueba puede ser

escrito para validar su comportamiento.

Los requisitos no funcionales son los que

actuar para restringir la solución. No funcional

requisitos son a veces conocidos como restricciones

o requisitos de calidad. Se pueden clasificar además

en función de si son de rendimiento

requisitos, requisitos de mantenimiento,

requisitos de seguridad, requisitos de fiabilidad,

requisitos de seguridad, requisitos de interoperabilidad

o uno de muchos otros tipos de software

requisitos (ver modelos y características de calidad

en el Software KA calidad).

1.4. Propiedades emergentes

Algunos requisitos representan propiedades emergentes

de los requisitos de software, es decir, que no puede

ser abordados por un solo componente, pero que

dependerá de cómo todos los componentes de software

interoperar. El requisito de rendimiento para una

centro de llamadas que, por ejemplo, dependerá de la forma

el sistema telefónico, sistema de información, y

los operadores de todo interactuaban bajo de funcionamiento real

condiciones. Las propiedades emergentes son crucialmente

depende de la arquitectura del sistema.

15. Requisitos cuantificables

Requisitos de software deben expresarse tan claramente

y como sin ambigüedad como sea posible, y, en su

apropiado, cuantitativamente. Es importante

evitar los requisitos vagos y no verificables que dependen para su interpretación sobre subjetiva

juicio ("el software debe ser confiable", "la

software debe ser fácil de usar "). Esto es particularmente

importante para los requisitos no funcionales.

Dos ejemplos de requisitos cuantificados

son los siguientes: el software de un centro de llamadas debe

aumentar el rendimiento del centro en un 20%; y un

sistema deberá tener una probabilidad de generar una

error grave durante cualquier hora del funcionamiento de menos

de 1 * 10-8

. El requisito de rendimiento es en una

y necesitará de muy alto nivel que se utilizará para derivar

una serie de requisitos detallados. La fiabilidad

requisito será fuertemente restringir el sistema de

arquitectura.

16. Requisitos del sistema y software

Requerimientos

En este tema, "sistema":

una combinación de elementos que interactúan

para lograr un objetivo determinado. Estas

incluyen hardware, software, firmware,

personas, información, técnicas, instalaciones,

servicios, y otros elementos de apoyo,

según lo definido por el Consejo Internacional de Software

e Ingeniería de Sistemas (INCOSE) [3].

Requisitos del sistema son los requisitos para

el sistema como un todo. En un sistema que contiene

componentes de software, requisitos de software son

derivado de los requisitos del sistema.

Esta KA define "las necesidades del usuario" en un

forma restringida, ya que los requisitos del sistema de

clientes o usuarios finales. Requisitos del sistema,

por el contrario, abarca los requisitos del usuario,

requisitos de otras partes interesadas (como regulador

autoridades), y los requisitos sin un

fuente humana identificable.

2. Requisitos Proceso

[1 *, c4s4] [2 *, C1-4, c6, c22, c23]

Esta sección presenta los requisitos de software

proceso, orientando los cinco temas restantes y

que muestra cómo encaja el proceso de requisitos

con el proceso global de ingeniería de software.

2.1. Modelos de Proceso

El objetivo de este tema es el de proporcionar una comprensión que el proceso de los requisitos

• No es una actividad frontal discreta del software

ciclo de la vida, sino más bien un proceso iniciado

en el comienzo de un proyecto que sigue

ser refinado a lo largo del ciclo de vida;

• Identifica los requisitos de software como la configuración

artículos y gestiona usando el

gestión de la configuración misma de software

prácticas como otros productos de software

procesos del ciclo de vida;

• necesita ser adaptada a la organización y

contexto del proyecto.

En particular, el tema se refiere a cómo

las actividades de obtención, análisis, especificación,

y validación están configurados para diferentes

tipos de proyectos y limitaciones. El tema también

incluye actividades que proporcionan la entrada en el

requisitos del proceso, tales como la comercialización y la viabilidad

estudios.

2.2. Actores del Proceso

En este tema se presentan los roles de las personas que

participar en el proceso de requisitos. Este proceso

es fundamentalmente interdisciplinario, y la

especialista requisitos tiene que mediar entre

el dominio de la parte interesada y la de software

ingeniería. A menudo hay mucha gente

involucrado además del especialista requisitos, cada

de los cuales tiene una participación en el software. Los grupos de interés

variará entre los proyectos, pero siempre

incluir los usuarios / operadores y clientes (que necesitan

no ser el mismo).

Ejemplos típicos de las partes interesadas de software

incluir (pero no se limitan a) lo siguiente:

• Usuarios: Este grupo comprende a los que se

operar el software. A menudo es un heterogéneo

grupo de la participación de personas con diferentes

funciones y requisitos.

• Clientes: Este grupo comprende a los que

han encargado el software o que representan

El mercado objetivo de software.

• Los analistas de mercado: Un producto de mercado masivo

no tendrá un cliente puesta en marcha, por lo

gente de marketing son a menudo necesarios para establecer

cuáles son las necesidades del mercado y de actuar como

clientes de proxy.

• Reguladores: Muchos dominios de aplicación, tales

como la banca y el transporte público, son regulados.

Software en estos dominios debe cumplir

con los requisitos de la reglamentación

las autoridades.

• Los ingenieros de software: Estos individuos tienen

un interés legítimo en sacar provecho de desarrollo

el por software, por ejemplo, reutilizando

componentes en o de otros productos. Si,

En este escenario, un cliente de un particular,

producto tiene requisitos específicos que

comprometer el potencial para el componente

reutilización, los ingenieros de software deben cuidadosamente

sopesar su propio juego contra los de la

cliente. Los requisitos específicos, en particular

limitaciones, pueden tener un impacto importante en

costo o la entrega del proyecto, ya sea porque

encajar bien o mal con el conjunto de habilidades de la

ingenieros. Compensaciones importantes entre tales

requisitos deben ser identificados.

No será posible satisfacer perfectamente la

requisitos de todas las partes interesadas, y es el

trabajo de ingeniero de software para negociar compensaciones que

son a la vez aceptable para los principales grupos de interés

y dentro del presupuesto, técnicos, regulatorios y

otras restricciones. Un requisito previo para esto es que todos los

identificar las partes interesadas, la naturaleza de su

"Juego" analizada y sus requisitos suscitó.

2.3. Apoyo y Gestión de Procesos

En esta sección se presenta la gestión de proyectos

recursos necesarios y consumidos por los requisitos

proceso. Establece el marco para la

primer tema (Iniciación y Definición del Alcance) de la

Ingeniería del Software de Gestión KA. Su principal

objetivo es hacer que el vínculo entre el proceso

actividades identificadas en 2.1 y las cuestiones de la

costos, 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 de los requisitos

proceso. Su propósito es hacer hincapié en el papel clave

el proceso de requisitos juega en términos de la costo y oportunidad de un producto de software y de

la satisfacción del cliente con él. Esto ayudará a

orientar el proceso de los requisitos de las normas de calidad

y modelos de mejora de procesos de software

y sistemas. La calidad y mejora de procesos

está estrechamente relacionado tanto al Software

KA Calidad e Ingeniería del Software Proceso

KA, que comprende

• Cobertura proceso de requisitos por el proceso

normas y modelos de mejora;

• medidas de proceso y requisitos

evaluación comparativa;

• Planificación e implementación de mejora;

• Seguridad / mejora de la CIA / planificación y

implementación.

3. Requisitos Elicitación

[1 *, c4s5] [2 *, C5, C6, C9]

Requisitos elicitación se refiere a la

orígenes de los requisitos de software y cómo el

ingeniero de software puede recogerlos. Es la primera

etapa en la construcción de una comprensión del problema

el software se requiere para resolver. Es fundamentalmente

una actividad humana y es donde las partes interesadas

se identifican y se establecieron relaciones

entre el equipo de desarrollo y el cliente.

Se denomina diversamente "captura de requisitos,"

"Requisitos descubrimiento", y "requisitos

adquisición ".

Uno de los principios fundamentales de un buen

proceso de obtención requisitos es el de la efectiva

la comunicación entre las distintas partes interesadas.

Esta comunicación continúa a través de

todo el Ciclo de Vida de Desarrollo de Software

Proceso (SDLC) con diferentes partes interesadas en

diferentes puntos en el tiempo. Antes de desarrollo

comienza, especialistas requisitos pueden formar el

conducto para esta comunicación. Deben mediar

entre el dominio de los usuarios de software (y

otros grupos de interés) y el mundo de la técnica de la

ingeniero de software. Un conjunto de coherencia interna

modelos en diferentes niveles de abstracción facilitan

las comunicaciones entre el software los usuarios / grupos de interés

y los ingenieros de software.

Un elemento crítico de la obtención de requisitos es

informar el alcance del proyecto. Esto implica proporcionar

se especifica una descripción del software

y su propósito y dar prioridad a los entregables

para asegurarse de negocios más importante del cliente

necesidades son satisfechas en primer lugar. Esto minimiza el riesgo

de los requisitos de especialistas pasar tiempo provocando

requisitos que son de baja importancia, o

los que resultan ser ya no es relevante cuando

el software se entrega. Por otro lado, la

descripción debe ser escalable y extensible para

aceptar más requisitos no expresados en la

primero las listas oficiales y compatible con el anterior

como se contempla en los métodos recursivos.

3.1. Requisitos Fuentes

Requisitos tienen muchas fuentes en el software típico,

y es esencial que todas las fuentes potenciales

ser identificado y evaluado. Este tema está diseñado

para promover el conocimiento de las diversas fuentes de

requisitos de software y de los marcos de

gestionarlos. Los principales puntos tratados son tan

de la siguiente manera:

• Objetivos. El término "objetivo" (a veces llamada

"Empresa comercial" o "factor crítico de éxito")

se refiere a los objetivos generales, de alto nivel

del software. Objetivos proporcionan la motivación

para el software, pero son a menudo vagamente

formulado. Los ingenieros de software necesitan pagar

especial atención a la evaluación del valor

(En relación con prioridad) y el costo de las metas. Un viabilidad

estudio es una forma relativamente barata de

haciendo esto.

• Conocimiento de Dominio. El ingeniero de software

necesita adquirir o tener conocimiento disponible

sobre el dominio de aplicación. Dominio

conocimiento proporciona el contexto en el

que todo conocimiento requisitos suscitado

debe establecerse con el fin de entenderlo. Es

una buena práctica para emular un ontológica

enfoque en el dominio del conocimiento. Relaciones

entre los conceptos pertinentes dentro de la

dominio de aplicación debe ser identificado.

• Las partes interesadas (véase la sección 2.2, Proceso

Actores). Gran parte del software ha demostrado ser insatisfactoria

porque ha hecho hincapié en los requisitos

de un grupo de partes interesadas en el

costa de los demás. Por lo tanto, el entregado

software es difícil de usar, o subvierte el

estructuras culturales o políticas del cliente

organización. El ingeniero de software

tiene que identificar, representar y administrar los "puntos de vista" de muchos tipos diferentes de

grupos de interés.

• Las reglas de negocio. Estas son las declaraciones que

definir o restringir algunos aspectos de la estructura

o el comportamiento de la propia empresa. "LA

estudiante no puede inscribirse en el próximo semestre de

cursos si no se mantienen algunas clases no remunerado

honorarios "sería un ejemplo de una regla de negocio

eso sería una fuente requisito para una universidad de

software del curso-registro.

• El entorno operativo. Requerimientos

se deriva de la ambiente en el

que se ejecutará el software. Estas

puede ser, por ejemplo, limitaciones de tiempo

en software o de rendimiento restricciones de tiempo real

en un entorno empresarial. Estas

debe ser buscado activamente porque pueden

afectar en gran medida la viabilidad software y el coste como

así como restringir las opciones de diseño.

• El entorno de la organización. Software

a menudo se requiere para apoyar un proceso de negocio,

la selección de los cuales puede estar condicionada

por la estructura, cultura, e interna

la política de la organización. El software

ingeniero tiene que ser sensible a estos, ya que,

en general, el nuevo software no debe forzar

el cambio no planificado en el proceso de negocio.

3.2. Técnicas de obtención

Una vez que los requisitos de las fuentes se han identificado,

el ingeniero de software puede comenzar a provocar

requisitos de información de ellos. Tenga en cuenta que

requisitos rara vez se suscitó ya hecho.

Más bien, el ingeniero de software obtiene información

de la que él o ella formula requisitos.

Este tema se centra en las técnicas para conseguir

actores humanos para articular requirementsrelevant

información. Es una tarea muy difícil y

el ingeniero de software debe ser sensibilizado a la

hecho de que (por ejemplo) los usuarios pueden tener dificultades

la descripción de sus tareas, puede dejar información importante

no declarada, o pueden ser dispuestos o no pueden

cooperar. Es particularmente importante entender

elicitación que no es una actividad pasiva y que,

incluso si las partes interesadas de cooperación y articular son

disponible, el ingeniero de software tiene que trabajar duro

para obtener la información correcta. Muchos negocios o

requisitos técnicos son tácito o en retroalimentación que

aún no se ha obtenido de los usuarios finales. La importancia

de la planificación, verificación y validación en

obtención de requisitos no puede ser exagerada. LA

número de técnicas existen para la obtención de requisitos;

las principales son los siguientes:

• Entrevistas. Entrevistar a los interesados es un

medios "tradicionales" de la obtención de requisitos.

Es importante comprender las ventajas

y las limitaciones de las entrevistas y cómo

debe llevarse a cabo.

• Escenarios. Escenarios proporcionan una valiosa

medios para proporcionar contexto a la elicitación

de las necesidades del usuario. Permiten la

ingeniero de software para proporcionar un marco

para preguntas sobre las tareas del usuario al permitir

"Qué pasaría si" y las preguntas "¿cómo se hace esto"

que se le pregunte. El tipo más común de escenario

es la descripción de casos de uso. Hay un

enlazar aquí al tema 4.2 (Modelado Conceptual)

porque notaciones de escenarios tales como casos de uso

diagramas son comunes en el software de modelado.

• Prototipos. Esta técnica es una herramienta valiosa

para aclarar los requisitos ambiguos. Ellos

puede actuar de una manera similar a escenarios proporcionando

los usuarios con un contexto en el que se

puede comprender mejor qué información

que proporcionar. Hay una amplia gama de

técnicas de prototipado-maquetas de papel

de la pantalla diseña a las versiones beta de prueba de

productos-software y un fuerte solapamiento de

sus usos diferentes para la obtención de requisitos

y para la validación de requisitos (ver

sección 6.2, de prototipos). Prototipos de baja fidelidad

a menudo se prefieren para evitar los grupos de interés

"Anclaje" de las características de menor importancia, incidentales

de un prototipo de mayor calidad que puede

limitar la flexibilidad de diseño de formas no deseadas.

• Facilitado reuniones. El propósito de estos

reuniones es tratar de lograr un sumativa

efecto, mediante el cual un grupo de personas puede traer

más información sobre sus requisitos de software

que trabajando individualmente. Ellos

pueden intercambiar ideas y refinar ideas que pueden ser

difícil de llevar a la superficie mediante entrevistas.

Otra ventaja es que en conflicto

requisitos de superficie desde el principio en una forma que

permite a las partes interesadas reconocen cuando éstos

ocurrir. Cuando funciona bien, esta técnica un conjunto de requisitos que de otro modo podrían

ser alcanzables. Sin embargo, las reuniones tienen que

se maneja con cuidado (de ahí la necesidad de un

facilitador) para evitar una situación en la que

las habilidades críticas del equipo se erosionan

por la lealtad de grupo, o en las que los requisitos

que refleja las preocupaciones de unos pocos pelos en la lengua

(Y tal vez mayores) las personas que se ven favorecidas

en detrimento de los demás.

• Observación. La importancia de software

contexto en el ambiente organizacional

ha conducido a la adaptación de observacional

técnicas como la etnografía de

obtención de requisitos. Los ingenieros de software

aprender sobre las tareas del usuario sumergiéndose

en el medio ambiente y observando cómo

los usuarios realizan sus tareas mediante la interacción con

entre sí y con herramientas de software y otro

recursos. Estas técnicas son relativamente

caro, pero también instructivo porque

ilustrar que muchas de las tareas de los usuarios y las empresas

procesos son demasiado sutil y complejo para

sus actores para describir fácilmente.

• Historias de usuarios. Esta técnica es comúnmente

utilizado en los métodos de adaptación (ver Métodos Ágiles

en los modelos de ingeniería de software

y Métodos KA) y se refiere a una palabra, de alto nivel

descripciones de funcionalidad requerida

expresado en términos de clientes. Un usuario típico

historia tiene la forma: "Como <función>, quiero

<Meta / deseo> de modo que <benefician>. "Un usuario

historia está destinado a contener información suficiente

de modo que los desarrolladores pueden producir un

estimación razonable del esfuerzo para poner en práctica

ello. El objetivo es evitar algunos de los residuos

que sucede a menudo en proyectos donde detallada

requisitos se reunieron temprano, pero se vuelven

no válida antes de que comience el trabajo. Antes de que un usuario

historia se implementa, una aceptación adecuada

procedimiento debe ser escrito por el cliente

para determinar si los objetivos de la

historia de usuario se han cumplido.

• Otras técnicas. Una gama de otras técnicas

para el apoyo a la obtención de los requisitos

existe información y van desde el análisis

productos de la competencia a la aplicación de la minería de datos

técnicas para el uso de fuentes de dominio

conocimiento o solicitud del cliente de bases de datos.

Análisis 4. Requisitos

[1 *, c4s1, c4s5, c10s4, c12s5]

[2 *, c7, c11, c12, c17]

Este tema tiene que ver con el proceso de análisis

requisitos a

• detectar y resolver los conflictos entre

requisitos;

• descubrir los límites del software y cómo

debe interactuar con su organización y

entorno operativo;

• Requisitos del sistema elaborados para derivar software

requisitos.

La visión tradicional de análisis de requerimientos

ha sido que ser reducido a modelado conceptual

usando uno de un número de métodos de análisis,

tales como el método de análisis estructurado. Mientras

modelado conceptual es importante, incluimos el

clasificación de los requisitos para ayudar a informar a las compensaciones

entre los requisitos (clasificación requisitos)

y el proceso de establecimiento de estos

compensaciones (requisitos negociación).

Se debe tener cuidado para describir los requisitos

lo suficientemente precisa para permitir que los requisitos para

ser validados, su aplicación a ser verificada,

y sus costes a estimar.

4.1. Requisitos Clasificación

Requisitos pueden clasificarse en un número de

dimensiones. Algunos ejemplos son los siguientes:

• Si el requisito es funcional o

no funcional (ver sección 1.3, Funcional

y requisitos no funcionales).

• Si el requisito se deriva de uno

o requisitos más alto nivel o un emergente

propiedad (ver sección 1.4, Emergent

Propiedades), o se están imponiendo directamente en

el software por un interesado o algún otro

fuente.

• Si el requisito es sobre el producto

o el proceso (ver sección 1.2, del producto y de

Requisitos de proceso). Requisitos en el

proceso puede limitar la elección del contratista,

el proceso de ingeniería de software para ser adoptadas, o las normas que deben respetarse.

• La prioridad requisito. Cuanto mayor sea la prioridad,

más esencial el requisito es

para cumplir con los objetivos generales del programa.

A menudo clasifican en una escala de coma fija tales

como obligatorio, altamente deseable, deseable,

u opcional, la prioridad a menudo tiene que ser equilibrado

contra el costo de desarrollo y

implementación.

• El alcance de la prescripción. Alcance refiere

en la medida en que un requisito afecta

los componentes de software y software.

Algunos requisitos, particularmente ciertos

los no funcionales, tienen un alcance global en

que su satisfacción no se puede asignar a

un componente discreto. Por lo tanto, un requisito

con alcance global puede afectar fuertemente la

arquitectura de software y el diseño de muchos

componentes, mientras que uno con un estrecho

alcance puede ofrecer una serie de opciones de diseño

y tienen poco impacto en la satisfacción de

otros requerimientos.

• Volatilidad / estabilidad. Algunos requisitos voluntad

cambiar durante el ciclo de vida del software-

e incluso durante el desarrollo

proceso en sí mismo. Es útil si alguna estimación

de la probabilidad de que un requisito

el cambio se puede hacer. Por ejemplo, en una banca

de aplicación, los requisitos para las funciones

para el cálculo y el interés de crédito a los clientes '

cuentas es probable que sean más estable que una

requisito para apoyar un tipo particular de

libre de impuestos cuenta. El primero refleja un derecho fundamental

característica del dominio bancario (que

cuentas pueden ganar intereses), mientras que el segundo

puede ser obsoleto por un cambio de

la legislación del gobierno. Cómo marcar potencialmente

requisitos volátiles pueden ayudar el software

diseñar establecer un diseño que es más tolerante

del cambio.

Otras clasificaciones pueden ser apropiadas,

dependiendo de la práctica normal de la organización

y la propia aplicación.

Hay un fuerte solapamiento entre los requisitos

atributos de clasificación y requisitos (véase

sección 7.3, Requisitos Atributos).

4.2. Modelado Conceptual

El desarrollo de modelos de un mundo real

problema es clave para el análisis de los requisitos de software.

Su propósito es ayudar en la comprensión de la

situación en la que se produce el problema, así como

representa una solución. Por lo tanto, los modelos conceptuales

comprender modelos de entidades del problema

dominio, configurado para reflejar su mundo real

relaciones y dependencias. Este tema es

estrechamente relacionados con los modelos de ingeniería de software

Métodos y KA.

Varios tipos de modelos se pueden desarrollar.

Estos incluyen diagramas de casos de uso, los modelos de flujo de datos,

modelos de estado, los modelos basados en objetivos, las interacciones del usuario,

modelos de objetos, modelos de datos, y muchos

otros. Muchas de estas notaciones de modelado son parte

del Lenguaje Unificado de Modelado (UML). Usar

diagramas de casos, por ejemplo, se utilizan de forma rutinaria

para representar escenarios en los que los separa de frontera

los actores (usuarios o sistemas en el entorno externo)

desde el comportamiento interno donde cada

caso de uso representa una funcionalidad del sistema.

Los factores que influyen en la elección de los modelos

notación incluyen los siguientes:

• La naturaleza del problema. Algunos tipos de

la demanda de software que se analizarán algunos aspectos

particularmente rigurosa. Por ejemplo,

modelos de estado y paramétricos, que son parte

de SysML [4], es probable que sean más importante

para el software en tiempo real de la información

sistemas, al tiempo que normalmente sería el

frente a modelos de objetos y de actividad.

• La experiencia del ingeniero de software. Es

a menudo más productivo para adoptar una modelización

notación o método con el que el software

ingeniero tiene experiencia.

• Los requisitos del proceso del cliente

(Ver sección 1.2, Productos y Procesos

Requisitos). Los clientes pueden imponer su

notación favorecida o método o prohíben cualquier

con los que no están familiarizados. Este factor

puede entrar en conflicto con el factor anterior.

Tenga en cuenta que, en casi todos los casos, es útil comenzar

mediante la construcción de un modelo del contexto software. Los

contexto software proporciona una conexión entre

los programas informáticos destinados y su entorno externo.

Esto es crucial para entender el contexto del software

en su entorno operativo y para identificar

sus interfaces con el medio ambiente.

Este subtema no busca "enseñar" un particular,

estilo de modelado o anotación sino que proporciona

orientación sobre el propósito y la intención de la modelización.

4.3. Diseño y Requisitos de arquitectura

Asignación

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 se superpone con los requisitos

software o sistemas de diseño e ilustra cómo

imposible que es para desacoplar limpiamente las dos tareas.

Este tema está estrechamente relacionado con Estructura del software

y Arquitectura del Software Diseño KA. En

muchos casos, el ingeniero de software actúa como software

arquitecto, porque el proceso de análisis

y la elaboración de los requisitos que exige

los componentes de la arquitectura / diseño que serán

responsable de satisfacer los requisitos de ser

identificado. Esta es la asignación de requisitos-la

asignación a componentes de la arquitectura responsables

para satisfacer los requisitos.

Asignación es importante para permitir un análisis detallado

de requisitos. Por lo tanto, por ejemplo, una vez al

conjunto de requisitos se ha asignado a un componente,

los requisitos individuales pueden estar más lejos

analizados para descubrir nuevos requisitos sobre la forma

el componente necesita interactuar con otros componentes

con el fin de satisfacer los requerimientos asignados.

En grandes proyectos, la asignación estimula una

nueva ronda de análisis para cada subsistema. Como

ejemplo, los requisitos para un frenado particular,

el rendimiento de un coche (la distancia de frenado, la seguridad en

condiciones de conducción pobres, suavidad de aplicación,

presión del pedal es necesario, y así sucesivamente) puede ser

asignado al hardware de frenado (mecánico

y conjuntos hidráulicos) y un antibloqueo

sistema (ABS). Sólo cuando un requisito para una

sistema de frenado antibloqueo ha sido identificado, y

los requisitos que se le asignen, ¿pueden las capacidades

del ABS, el hardware de frenado, y emergente

propiedades (tales como el peso del coche) se utilizarán para

identificar los requisitos detallados de software del ABS.

El diseño arquitectónico está estrechamente identificado con

modelado conceptual (ver sección 4.2, conceptual

Modeling).

4.4. Requisitos Negociación

Otro término comúnmente utilizado para este subtema

es "la resolución de conflictos." Esto se refiere a la resolución de

problemas con los requisitos que los conflictos

ocurrir entre dos actores que requieren mutuamente

características incompatibles, entre los requisitos

y los recursos, o entre funcionales y no funcionales

requisitos, por ejemplo. En la mayoría

casos, no es aconsejable para el ingeniero de software de

tomar una decisión unilateral, por lo que se hace necesario

consultar con la parte interesada (s) para llegar a una

consenso sobre una compensación adecuada. A menudo es

importantes, por razones contractuales, que tales decisiones

Volveremos trazable al cliente. Tenemos

clasificado como un análisis de los requisitos de software

tema porque los problemas surgen como el resultado

de análisis. Sin embargo, un caso fuerte también puede ser

hecho por considerarlo una validación requisitos

tema (véase el tema 6, Requisitos de validación).

Requisitos de prioridades es necesaria, no

sólo como un medio para filtrar los requisitos importantes,

sino también con el fin de resolver los conflictos y planificar

organizado entregas, lo que significa hacer compleja

decisiones que requieren un conocimiento detallado de dominio

y buenas habilidades de estimación. Sin embargo, a menudo es

difícil obtener información real que puede actuar como

una base para tales decisiones. Además, los requisitos

menudo dependen unos de otros, y las prioridades

son relativos. En la práctica, los ingenieros de software

realizar requisitos priorización frecuencia

sin necesidad de conocer todos los requisitos.

Requisitos priorización puede seguir un costvalue

enfoque que implica un análisis de

los actores que definen en una escala de los beneficios

o el valor agregado que la aplicación

del requisito de los trae, frente a la

sanciones de no haber implementado un particular,

requisito. También implica un análisis desde

los ingenieros de software de estimación en una escala del

costo de la implementación de cada requisito, relativo

a otros requisitos. Otra priorización requisitos

enfoque llama la jerarquía analítica

proceso implica la comparación de todos los pares únicos de

requisitos para determinar cuál de los dos es de

mayor prioridad, y en qué medida.

4.5. Análisis Formal

Preocupaciones de análisis formales no sólo el tema 4, pero

también las secciones 5.3 y 6.3. Este tema también es relacionado

a los métodos formales en la Ingeniería de Software

Modelos y Métodos Área de Conocimiento.

Análisis formal ha hecho un impacto en algunos

dominios de aplicación, en particular los de highintegrity

sistemas. La expresión formal de

requisitos requiere un lenguaje con formalmente

semántica definida. El uso de un análisis formal

para los requisitos de expresión tiene dos beneficios.

En primer lugar, permite a los requisitos expresados en el

idioma que se especifica con precisión y sin ambigüedades,

por lo tanto (en principio) evitando el potencial

a interpretaciones erróneas. En segundo lugar, los requisitos pueden

razonar sobre, permitiendo propiedades deseadas

del software especificado por demostrar. Formal

razonamiento requiere soporte de herramientas para ser viable

para que no sean triviales sistemas y herramientas de nada

generalmente se dividen en dos tipos: demostradores de teoremas o

damas modelo. En ninguno de los casos puede ser una prueba totalmente

automatizado, y el nivel de competencia en la educación formal

razonamiento necesario para utilizar las herramientas restringe

la aplicación más amplia de análisis formal.

La mayor análisis formal se concentra en relativamente

las últimas etapas de análisis de requisitos. Es generalmente

contraproducente para aplicar formalización

hasta que los objetivos de negocio y necesidades de los usuarios

han entrado en un enfoque nítido a través de medios tales

como los descritos en otras partes de la sección 4. Sin embargo,

una vez que los requisitos se han estabilizado y

se han elaborado para especificar las propiedades del concreto

del software, puede ser beneficioso para formalizar

al menos los requisitos críticos. Esto permite

validación estática que el software especificado

por los requisitos en efecto tienen las propiedades

(Por ejemplo, ausencia de punto muerto) que la

clientes, usuarios, y el ingeniero de software esperan

tener.

5. Requisitos Especificación

[1 *, c4s2, c4s3, c12s2-5] [2 *, c10]

Para la mayoría de las carreras de ingeniería, el término "especificación"

se refiere a la asignación de numérica

valores o límites a los objetivos de diseño de un producto. En

ingeniería de software, "los requisitos de software

especificación "típicamente se refiere a la producción de

un documento que puede ser revisado de forma sistemática,

evaluado y aprobado. Para sistemas complejos,

particularmente aquellos que involucran nonsoftware sustancial

componentes, hasta tres diferentes

se producen tipos de documentos: definición del sistema,

requisitos del sistema y los requisitos de software.

Para productos de software simples, sólo el

tercio de éstos se requiere. Los tres documentos son

descrito aquí, con el entendimiento de que

se pueden combinar según sea apropiado. Una descripción de

la ingeniería de sistemas puede encontrarse en la relacionados

Disciplinas de Ingeniería de Software capítulo de

esta Guía.

5.1. Definición Sistema Documento

Este documento (a veces conocido como el usuario

requisitos documento o concepto de las operaciones

documento) registra los requisitos del sistema. Eso

define los requisitos del sistema de alto nivel de

la perspectiva de dominio. Su número de lectores incluye

representantes del sistema de los usuarios / clientes

(Marketing puede desempeñar estos roles para marketdriven

software), por lo que su contenido debe ser redactada

en términos de dominio. El documento enumera el

requisitos del sistema, junto con el fondo

información sobre los objetivos generales para la

sistema, su entorno de destino, y una declaración de

la limitaciones, supuestos, y no funcionales

requisitos. Puede incluir modelos conceptuales

diseñado para ilustrar el contexto del sistema, el uso

escenarios y las principales entidades de dominio, como

así como flujos de trabajo.

5.2. Requisitos del sistema Especificaciones

Los desarrolladores de sistemas con software sustancial

y los componentes, un nonsoftware avión moderno,

por ejemplo, a menudo separar la descripción

de los requisitos del sistema de la descripción

de los requisitos de software. En este punto de vista, el sistema

requisitos se especifican los requisitos de software

se derivan de los requisitos del sistema,

y luego los requisitos para los componentes de software

se especifican. Estrictamente hablando, el sistema de

especificación de requisitos es una ingeniería de sistemas

actividad y cae fuera del alcance de este

Guía.

5.3. Requisitos de software Especificación

Requisitos de software de especificación establece

la base para un acuerdo entre los clientes y

contratistas o proveedores (en los proyectos impulsados por el mercado,

estos roles pueden ser reproducidos por la comercialización

y divisiones de desarrollo) en lo que el software

producto se va a hacer, así como lo que no se espera

hacer.

Requisitos de software de especificación permisos

una evaluación rigurosa de los requisitos antes

diseño puede comenzar y reduce rediseño más tarde. Eso

También debe proporcionar una base realista para estimar

los costos del producto, riesgos y horarios.

Las organizaciones también pueden utilizar un requisitos de software

documento de especificación como base para

el desarrollo de la verificación y validación efectiva

planes.

Requisitos de software proporciona la especificación

una base informada para la transferencia de un producto de software

a los nuevos usuarios o plataformas de software. Por último, se

puede proporcionar una base para la mejora de software.

Requisitos de software se escriben a menudo en

lenguaje natural, pero, en los requisitos de software

especificación, esto puede ser complementado por formales

o descripciones semiformales. Selección de

notaciones apropiadas permite requisitos particulares

y aspectos de la arquitectura de software a

se describirá con más precisión y concisión de

Lenguaje natural. La regla general es que las anotaciones

se debe utilizar que permiten los requisitos

que se describirá tan precisamente como sea posible. Esto es

particularmente crucial para la seguridad crítica, regulatorio,

y ciertos otros tipos de software fiable.

Sin embargo, la elección de la notación es a menudo limitada

por la formación, habilidades y preferencias de los

autores y lectores del documento.

Una serie de indicadores de calidad han sido

desarrollados que puede ser utilizado para relacionar la calidad

de especificación de requisitos de software a otra

variables del proyecto, tales como el costo, la aceptación, el rendimiento,

horario, y reproducibilidad. Calidad

indicadores para las necesidades individuales de software

declaraciones de especificaciones incluyen imperativos,

directivas, frases débiles, opciones y aplazamientos.

Indicadores para la totalidad de los requisitos de software

documento de especificación incluye el tamaño, facilidad de lectura,

especificación, la profundidad y la estructura del texto.

6. Requisitos de validación

[1 *, c4s6] [2 *, c13, c15]

Los documentos de requerimientos pueden estar sujetos a validación

y procedimientos de verificación. Los requisitos

puede ser validado para asegurarse de que el software

ingeniero ha entendido los requisitos; es

También es importante verificar que un documento de requisitos

se ajusta a las normas de la empresa y que

es comprensible, coherente y completa. En

casos en los estándares de la compañía documentados o

son incompatibles con la terminología ampliamente aceptada

normas, una correspondencia entre los dos deben ser

acordado y anexa al documento.

Notaciones formales ofrecen la ventaja importante

de permitir que los últimos dos propiedades por demostrar

(En un sentido restringido, por lo menos). Los diferentes grupos de interés,

incluyendo representantes del cliente

y desarrollador, debe revisar el documento (s).

Requisitos documentos están sujetos a la misma

las prácticas de gestión de configuración como la otra

entregables de los procesos del ciclo de vida del software.

Cuando sea práctico, los requisitos individuales son

también sujeto a la configuración de gestión, por lo general

utilizando una herramienta de gestión de requisitos (ver

tema 8, Requisitos de software Herramientas).

Es normal para programar explícitamente uno o más

puntos en el proceso de requisitos donde el

requisitos se validan. El objetivo es recoger

cualquier problema antes de los recursos se han comprometido a

abordar los requisitos. Requisitos de validación

tiene que ver con el proceso de examinar

el documento de requisitos para asegurarse de que

define el software adecuado (es decir, el software

que los usuarios esperan).

6.1. Requisitos Comentarios

Tal vez los medios más comunes de la validación

es por inspección o revisión de los requisitos

documento (s). Se asigna un grupo de revisores

una breve buscar errores, suposiciones erróneas,

falta de claridad, y la desviación de la práctica estándar.

La composición del grupo que lleva a cabo

la crítica es importante (al menos un representante

del cliente deben ser incluidos para un

impulsado por los clientes del proyecto, por ejemplo), y se puede

ayudar a proporcionar orientación sobre lo que debe buscar en

la forma de listas de comprobación.

Los comentarios pueden ser constituidas al término de

el documento de definición del sistema, la especificación del sistema

documentos, los requisitos de software

documento de especificaciones, la especificación de la línea de base

para un nuevo lanzamiento, o en cualquier otro paso en la

proceso.

6.2. Prototipos

Prototipos es comúnmente un medio para validar

la interpretación que el ingeniero de software del software

requisitos, así como para la obtención de nuevo

requisitos. Al igual que con la elicitación, hay una gama

de prototipos técnicas y una serie de puntos

en el proceso de validación donde prototipo puede

ser apropiado. La ventaja de prototipos es

que pueden hacer que sea más fácil de interpretar el software

supuestos de ingeniero y, cuando sea necesario,

dar información útil sobre por qué están equivocados. Por

ejemplo, el comportamiento dinámico de una interfaz de usuario

se puede entender mejor a través de una animada

prototipo que a través de la descripción textual

o modelos gráficos. La volatilidad de un requisito

que se define después de la creación de prototipos ha sido

hecho es extremadamente bajo porque no hay acuerdo

entre los grupos de interés y la ingeniería de software

Por lo tanto, para la seguridad crítico y crucial

características de prototipos sería de gran ayuda. Hay

también desventajas, sin embargo. Estos incluyen el

peligro de atención de los usuarios que se distrajo de

el núcleo subyacente funcionalidad cosmética

cuestiones o problemas de calidad con el prototipo. Por

esta razón, algunos prototipos abogado que eviten

software, tales como maquetas basadas rotafolio. Prototipos

puede ser costoso para desarrollar. Sin embargo, si

evitan el derroche de recursos que supone

tratando de satisfacer los requisitos erróneos, su

coste se puede justificar más fácilmente. Los primeros prototipos

puede contener aspectos de la solución final.

Los prototipos pueden ser evolutiva en lugar de

tirar.

6.3. Validación del Modelo

Es típicamente necesario para validar la calidad de

los modelos desarrollados durante el análisis. Por ejemplo,

en modelos de objetos, es útil para realizar una

el análisis estático para verificar que las rutas de comunicación

existir entre los objetos que, en los grupos de interés '

dominio, el intercambio de datos. Si notaciones de análisis formales

se utilizan, es posible utilizar el razonamiento formal

para demostrar las propiedades de especificación. Este tema es

estrechamente relacionados con los modelos de ingeniería de software

Métodos y KA.

6.4. Pruebas de Aceptación

Una propiedad esencial de un requisito de software

es que debería ser posible para validar que el

producto terminado satisface. Requisitos que

no pueden ser validados son en realidad "deseos". Un

por lo tanto, importante tarea está planeando cómo verificar

cada requisito. En la mayoría de los casos, el diseño

pruebas de aceptación hace por cómo los usuarios finales normalmente

realizar negocios utilizando el sistema.

La identificación y el diseño de las pruebas de aceptación

puede ser difícil para los requisitos no funcionales

(Ver sección 1.3, funcionales y no funcionales

Requisitos). Para ser validado, deben primero

ser analizado y descompuesto hasta el punto donde

puedan expresarse cuantitativamente.

Información adicional se puede encontrar en la aceptación /

Calificación / Pruebas de conformidad en el

Software Testing KA.

7. Consideraciones prácticas

[1 *, c4s1, c4s4, c4s6, c4s7]

[2 *, c3, c12, c14, c16, c18-21]

El primer nivel de descomposición tema presentado

en este KA puede parecer para describir un lineal

secuencia de actividades. Esta es una vista simplificada

del proceso.

El proceso de requisitos se extiende por la totalidad

ciclo de vida del software. La gestión del cambio y de la

el mantenimiento de los requisitos de un Estado que

espejos con precisión el software a construir, o que

se ha construido, son clave para el éxito del software

proceso de ingeniería.

No todas las organizaciones tienen una cultura de la documentación

y la gestión de requisitos. Es común

en empresas de nueva creación dinámica, impulsada por un

fuerte "visión del producto" y los recursos limitados, a

requisitos de documentación de vista como innecesaria

overhead. Muy a menudo, sin embargo, ya que estas empresas

ampliar, ya que su base de clientes crece, y

como su producto comienza a evolucionar, descubren

que necesitan para recuperar los requisitos que impacto de los cambios propuestos. Por lo tanto, los requisitos

documentación y gestión del cambio son la clave

para el éxito de cualquier proceso de requisitos.

7.1. Naturaleza iterativa de los Requisitos

Proceso

Hay una presión general en la industria del software

para los ciclos de desarrollo cada vez más cortos, y esto

es particularmente pronunciado en altamente competitivo,

sectores impulsados por el mercado. Por otra parte, la mayoría de los proyectos

están limitados de alguna manera por su entorno,

y muchos son mejoras para, o las revisiones, existentes

software donde la arquitectura es un hecho. En

la práctica, por lo tanto, es casi siempre poco práctico

para implementar el proceso de requisitos como lineal,

proceso determinista en que los requisitos de software

se suscitó a partir de los grupos de interés, línea base,

asignado y entregado al software

Equipo de desarrollo. Sin duda, es un mito que la

requisitos para los grandes proyectos de software son cada vez

perfectamente entendida o perfectamente especificado.

En lugar de ello, los requisitos típicamente iterar hacia

un nivel de calidad y el detalle que sea suficiente para

permitir que las decisiones de diseño y de adquisiciones para ser

hecho. En algunos proyectos, esto puede resultar en la

requisitos que se baseline antes toda su

propiedades se entienden completamente. Se corre el riesgo caros

reelaborar si los problemas surgen a finales del software

proceso de ingeniería. Sin embargo, el software

ingenieros están necesariamente limitados por proyecto

planes de gestión y, por tanto, debe tomar medidas

para asegurar que la "calidad" de los requisitos es

lo más alto posible dados los recursos disponibles.

Deben, por ejemplo, hacer explícita cualquier

supuestos que sustentan los requisitos que

así como los problemas conocidos.

Para los productos de software que se desarrollan de forma iterativa,

un equipo de proyecto puede basal sólo aquellos

requisitos necesarios para la iteración actual. Los

especialista requisitos puede continuar desarrollando

requisitos para futuras iteraciones, mientras que los desarrolladores

proceder con el diseño y construcción de la

iteración actual. Este enfoque proporciona a los clientes

con valor de negocio de forma rápida, minimizando

el costo de la reanudación.

En casi todos los casos, los requisitos de comprensión

continúa evolucionando como el diseño y desarrollo

procede. Esto a menudo conduce a la revisión de

requisitos finales en el ciclo de la vida. Tal vez la

el punto más crucial en la comprensión de software

requisitos es que una proporción significativa de

los requisitos cambiarán. Esto es a veces

debido a errores en el análisis, pero es con frecuencia una

consecuencia inevitable de cambio en el "medio ambiente" -

por ejemplo, de funcionamiento del cliente

o ambiente de negocios, procesos de regulación

impuesta por las autoridades, ni el mercado en

qué 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 será gestionado por asegurar que los cambios propuestos

pasar por un proceso de revisión y aprobación definido

y mediante la aplicación de los requisitos cuidadosos trazado,

análisis de impacto, y la configuración del software

gestión (ver la configuración del software

Gestión KA). Por lo tanto, el proceso de los requisitos

no es más que una tarea de front-end en el software

el desarrollo, pero se extiende por toda la vida del software

ciclo. En un proyecto típico, los requisitos de software

actividades evolucionan con el tiempo de obtención

para la gestión del cambio. Una combinación de arriba abajo

análisis y diseño de métodos y bottomup

métodos de aplicación y de refactorización que

reunirse en el centro podría ofrecer lo mejor de ambos

mundos. Sin embargo, esto es difícil de lograr en

practicar, ya que depende en gran medida de la madurez

y la experiencia de los ingenieros de software.

7.2. Gestión del cambio

La gestión del cambio es fundamental para la gestión

de requisitos. En este tema se describe el papel de

gestión del cambio, los procedimientos que deben

estar en su lugar, y el análisis que se debe aplicar

a los cambios propuestos. Tiene fuertes vínculos con el Software

Configuración KA Gestión.

7.3. Requisitos Atributos

Los requisitos deben consistir no sólo de una especificación

de lo que se requiere, sino también de auxiliares

información, que ayuda a administrar e interpretar

los requisitos. Requisitos atributos deben

definir, grabada y actualizada del software

bajo desarrollo o mantenimiento evoluciona.

Esto debe incluir los distintos clasificación Requisitos Clasificación) y la verificación

método o sección del plan de prueba de aceptación correspondiente.

También puede incluir información adicional, tal

como justificación de resumen para cada requisito, el

fuente de cada requisito, y un historial de cambios.

Atribuyen Los requisitos más importantes, sin embargo,

es un identificador que permite a los requisitos

para ser identificado de forma única e inequívoca.

7.4. Requisitos Trazando

Requisitos de rastreo tiene que ver con la recuperación

la fuente de los requisitos y la predicción de la

efectos de los requisitos. El rastreo es fundamental

a la realización de análisis de impacto cuando los requisitos

cambio. Un requisito debe ser trazable hacia atrás

a los requisitos y las partes interesadas que

motivado que (de un requisito de software de nuevo

al requisito (s) del sistema que ayuda a satisfacer,

por ejemplo). Por el contrario, un requisito debe

ser trazable hacia adelante en los requisitos y

entidades de diseño que satisfacen ella (por ejemplo, a partir de

un requisito del sistema en los requisitos de software

que se han elaborado a partir de él, y en

en los módulos de código que lo implementan, o la

casos de prueba relacionados con ese código y hasta un hecho

sección en el manual de usuario que describe el

real funcionalidad) y en el caso de prueba que

verifica.

Los requisitos de rastreo para un proyecto típico

formarán un gráfico acíclico dirigido complejo

(DAG) (ver gráficos en las Fundaciones Informática

KA) de requisitos. El mantenimiento de un up-todate

gráfico o matriz de trazabilidad es una actividad que

deben ser considerados durante todo el ciclo de vida

de un producto. Si la información de trazabilidad no es

actualizado como cambios en los requisitos continúan

a suceder, la información de trazabilidad se convierte en

poco fiable para el análisis de impacto.

7.5. Requisitos de medición

Como una cuestión práctica, es típicamente útil tener

algún concepto del "volumen" de los requisitos

para un producto de software en particular. Esta

número es útil para evaluar el "tamaño" de un

cambio en los requisitos, en la estimación del costo de

una tarea desarrollo o mantenimiento, o simplemente para

utilizar como denominador en otras mediciones.

Medición de tamaño funcional (FSM) es una técnica

para evaluar el tamaño de un cuerpo de funcional

requisitos.

Información adicional sobre la medida del tamaño

y las normas se pueden encontrar en la Ingeniería de Software

Proceso KA.

8. Requisitos de software Herramientas

Herramientas para hacer frente a los requisitos de software caen

a grandes rasgos en dos categorías: herramientas para el modelado

y herramientas para la gestión de requisitos.

Herramientas de gestión de requisitos normalmente apoyan

una serie de actividades, incluyendo la documentación,

trazado, y el cambio de gestión y tiene

tenido un impacto significativo en la práctica. De hecho, la localización

y la gestión del cambio son en realidad sólo posible

si es compatible con una herramienta. Dado que los requisitos

gestión es fundamental para buenas requisitos

la práctica, muchas organizaciones han invertido

en herramientas de gestión de requisitos, aunque

muchos más gestionar sus requisitos en más

ad hoc y en general formas menos satisfactorias (por ejemplo,

utilizando hojas de cálculo).