REQUISITOS DE SOFTWARE

CIA

Confidencialidad, Integridad y disponibilidad

DAG

Dirigido acclicos Grfico

FSM

Tamao Medida Funcional

INCOSE

Consejo Internacional de Sistemas ingeniera

UML

lenguaje de modelado unificado

SysML

sistemas de lenguaje modelado

INTRODUCCIN
El rea Requisitos de software del conocimiento (KA) se refiere a la obtencin,
anlisis, especificacin, y validacin de requisitos de software as como la gestin
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 crticamente vulnerables cuando el
requirementsrelated las actividades estn mal realizadas.
Requisitos de software expresan las necesidades y
las restricciones impuestas a un producto de software que
contribuir a la solucin de algunos-mundo real
problema.
La "ingeniera de requisitos" plazo es ampliamente
utilizado en el campo para indicar la manipulacin sistemtica
de requisitos. Por razones de coherencia, la
trmino "ingeniera" no se utilizar en este KA
excepto para la ingeniera del software en s.
Por la misma razn, "requisitos ingeniero"
un trmino que aparece en la parte de la literatura,
no se utilizarn tampoco. En cambio, el trmino "software
ingeniero "o, en algunos casos especficos," Requisitos
especialista "se utilizar, este ltimo donde
el papel en cuestin 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 funcin.

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 diseado para proporcionar una visin 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 actan para configurarlo.
Una descomposicin alternativo podra utilizar un producto basadoestructura (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 diseo, pruebas de software,
Mantenimiento de Software, Software de Configuracin
Gestin, Software de Gestin de Ingeniera,
Software Ingeniera de Procesos, Software
Modelos y mtodos de ingeniera 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. Definicin de un requisito de software

En su forma ms bsica, un requisito de software es un
propiedad que debe ser exhibido por algo en Para resolver algn problema en el
mundo real. Eso
puede apuntar para automatizar parte de una tarea para alguien
para apoyar los procesos de negocio de una organizacin,
para corregir deficiencias de software existente,
o para controlar un dispositivo para nombrar slo 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 funcin de los dispositivos suelen ser complejos.
Por extensin, por lo tanto, los requisitos en particular,
software suelen ser una combinacin compleja
de varias personas en diferentes niveles de una
organizacin, y que estn en una forma u otra
implicados o relacionados con esta funcin 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
funcin como requisito funcional o en la
nivel de sistema como un requisito no funcional. Eso
puede ser difcil o costoso para verificar determinado software
requisitos. Por ejemplo, la verificacin
del requisito de rendimiento en un centro de llamadas
puede requerir el desarrollo de la simulacin
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 adems
a las propiedades de comportamiento. Los ejemplos ms comunes
incluir una clasificacin 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. tpicamente,
requisitos de software se identifican de forma nica
de modo que puedan ser sometidos a la configuracin del software
gestin durante todo el ciclo de vida
de la funcin y del software.

1.2. Productos y procesos Requisitos

Un requisito producto es una necesidad o restriccin 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 restriccin
en el desarrollo del software (por
ejemplo, "El software se ha desarrollado utilizando
un proceso RUP ").
Algunos requisitos de software generan implcita
requisitos del proceso. La eleccin de verificacin tcnica es un ejemplo. Otro podra
ser el
uso de tcnicas de anlisis particularmente rigurosos
(Tales como los mtodos de especificacin formales) para reducir
fallos que pueden conducir a la fiabilidad inadecuada. Proceso
requisitos tambin pueden ser impuestas directamente
por la organizacin 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
algn texto o la modulacin de una seal. Ellos
a veces son conocidos como las capacidades o caractersticas.
Un requisito funcional tambin 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 solucin. No funcional
requisitos son a veces conocidos como restricciones
o requisitos de calidad. Se pueden clasificar adems
en funcin 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 caractersticas 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 cmo todos los componentes de software
interoperar. El requisito de rendimiento para una
centro de llamadas que, por ejemplo, depender de la forma
el sistema telefnico, sistema de informacin, 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 ambigedad como sea posible, y, en su
apropiado, cuantitativamente. Es importante
evitar los requisitos vagos y no verificables que dependen para su interpretacin
sobre subjetiva
juicio ("el software debe ser confiable", "la
software debe ser fcil 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 combinacin de elementos que interactan
para lograr un objetivo determinado. Estas
incluyen hardware, software, firmware,
personas, informacin, tcnicas, instalaciones,
servicios, y otros elementos de apoyo,
segn lo definido por el Consejo Internacional de Software
e Ingeniera 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 seccin presenta los requisitos de software
proceso, orientando los cinco temas restantes y
que muestra cmo encaja el proceso de requisitos
con el proceso global de ingeniera de software.
2.1. Modelos de Proceso
El objetivo de este tema es el de proporcionar una comprensin que el proceso de
los requisitos
No es una actividad frontal discreta del software
ciclo de la vida, sino ms 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 configuracin
artculos y gestiona usando el
gestin de la configuracin misma de software
prcticas como otros productos de software
procesos del ciclo de vida;
necesita ser adaptada a la organizacin y
contexto del proyecto.

En particular, el tema se refiere a cmo

las actividades de obtencin, anlisis, especificacin,
y validacin estn configurados para diferentes
tipos de proyectos y limitaciones. El tema tambin
incluye actividades que proporcionan la entrada en el
requisitos del proceso, tales como la comercializacin 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
ingeniera. A menudo hay mucha gente
involucrado adems del especialista requisitos, cada
de los cuales tiene una participacin en el software. Los grupos de inters
variar entre los proyectos, pero siempre
incluir los usuarios / operadores y clientes (que necesitan
no ser el mismo).
Ejemplos tpicos 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 heterogneo
grupo de la participacin 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

cules son las necesidades del mercado y de actuar como
clientes de proxy.
Reguladores: Muchos dominios de aplicacin, tales
como la banca y el transporte pblico, son regulados.
Software en estos dominios debe cumplir
con los requisitos de la reglamentacin
las autoridades.
Los ingenieros de software: Estos individuos tienen
un inters legtimo 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 especficos que
comprometer el potencial para el componente
reutilizacin, los ingenieros de software deben cuidadosamente
sopesar su propio juego contra los de la
cliente. Los requisitos especficos, 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 inters
y dentro del presupuesto, tcnicos, 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 Gestin de Procesos
En esta seccin se presenta la gestin de proyectos
recursos necesarios y consumidos por los requisitos
proceso. Establece el marco para la
primer tema (Iniciacin y Definicin del Alcance) de la
Ingeniera del Software de Gestin KA. Su principal
objetivo es hacer que el vnculo entre el proceso
actividades identificadas en 2.1 y las cuestiones de la
costos, recursos humanos, capacitacin y herramientas.
2.4. Proceso de Calidad y Mejora
Este tema se refiere a la evaluacin de
la calidad y la mejora de los requisitos
proceso. Su propsito es hacer hincapi en el papel clave
el proceso de requisitos juega en trminos de la costo y oportunidad de un producto
de software y de
la satisfaccin 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 Ingeniera del Software Proceso
KA, que comprende
Cobertura proceso de requisitos por el proceso
normas y modelos de mejora;
medidas de proceso y requisitos
evaluacin comparativa;
Planificacin e implementacin de mejora;
Seguridad / mejora de la CIA / planificacin y
implementacin.

3. Requisitos Elicitacin
[1 *, c4s5] [2 *, C5, C6, C9]
Requisitos elicitacin se refiere a la
orgenes de los requisitos de software y cmo el
ingeniero de software puede recogerlos. Es la primera
etapa en la construccin de una comprensin 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
adquisicin ".
Uno de los principios fundamentales de un buen
proceso de obtencin requisitos es el de la efectiva
la comunicacin entre las distintas partes interesadas.
Esta comunicacin contina a travs 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 comunicacin. Deben mediar
entre el dominio de los usuarios de software (y
otros grupos de inters) y el mundo de la tcnica de la
ingeniero de software. Un conjunto de coherencia interna
modelos en diferentes niveles de abstraccin facilitan
las comunicaciones entre el software los usuarios / grupos de inters
y los ingenieros de software.
Un elemento crtico de la obtencin de requisitos es
informar el alcance del proyecto. Esto implica proporcionar

se especifica una descripcin del software

y su propsito y dar prioridad a los entregables
para asegurarse de negocios ms 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
descripcin debe ser escalable y extensible para
aceptar ms requisitos no expresados en la
primero las listas oficiales y compatible con el anterior
como se contempla en los mtodos recursivos.
3.1. Requisitos Fuentes
Requisitos tienen muchas fuentes en el software tpico,
y es esencial que todas las fuentes potenciales
ser identificado y evaluado. Este tema est diseado
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 trmino "objetivo" (a veces llamada
"Empresa comercial" o "factor crtico de xito")
se refiere a los objetivos generales, de alto nivel
del software. Objetivos proporcionan la motivacin
para el software, pero son a menudo vagamente
formulado. Los ingenieros de software necesitan pagar
especial atencin a la evaluacin del valor
(En relacin 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 aplicacin. Dominio
conocimiento proporciona el contexto en el
que todo conocimiento requisitos suscitado
debe establecerse con el fin de entenderlo. Es
una buena prctica para emular un ontolgica
enfoque en el dominio del conocimiento. Relaciones
entre los conceptos pertinentes dentro de la
dominio de aplicacin debe ser identificado.
Las partes interesadas (vase la seccin 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 dems. Por lo tanto, el entregado
software es difcil de usar, o subvierte el
estructuras culturales o polticas del cliente
organizacin. El ingeniero de software
tiene que identificar, representar y administrar los "puntos de vista" de muchos
tipos diferentes de
grupos de inters.
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 prximo semestre de
cursos si no se mantienen algunas clases no remunerado
honorarios "sera un ejemplo de una regla de negocio
eso sera 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 diseo.
El entorno de la organizacin. Software
a menudo se requiere para apoyar un proceso de negocio,
la seleccin de los cuales puede estar condicionada
por la estructura, cultura, e interna
la poltica de la organizacin. 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. Tcnicas de obtencin
Una vez que los requisitos de las fuentes se han identificado,
el ingeniero de software puede comenzar a provocar
requisitos de informacin de ellos. Tenga en cuenta que
requisitos rara vez se suscit ya hecho.
Ms bien, el ingeniero de software obtiene informacin
de la que l o ella formula requisitos.
Este tema se centra en las tcnicas para conseguir
actores humanos para articular requirementsrelevant
informacin. Es una tarea muy difcil y
el ingeniero de software debe ser sensibilizado a la
hecho de que (por ejemplo) los usuarios pueden tener dificultades
la descripcin de sus tareas, puede dejar informacin importante
no declarada, o pueden ser dispuestos o no pueden

cooperar. Es particularmente importante entender

elicitacin que no es una actividad pasiva y que,
incluso si las partes interesadas de cooperacin y articular son
disponible, el ingeniero de software tiene que trabajar duro
para obtener la informacin correcta. Muchos negocios o
requisitos tcnicos son tcito o en retroalimentacin que
an no se ha obtenido de los usuarios finales. La importancia
de la planificacin, verificacin y validacin en
obtencin de requisitos no puede ser exagerada. LA
nmero de tcnicas existen para la obtencin de requisitos;
las principales son los siguientes:
Entrevistas. Entrevistar a los interesados es un
medios "tradicionales" de la obtencin de requisitos.
Es importante comprender las ventajas
y las limitaciones de las entrevistas y cmo
debe llevarse a cabo.
Escenarios. Escenarios proporcionan una valiosa
medios para proporcionar contexto a la elicitacin
de las necesidades del usuario. Permiten la
ingeniero de software para proporcionar un marco
para preguntas sobre las tareas del usuario al permitir
"Qu pasara si" y las preguntas "cmo se hace esto"
que se le pregunte. El tipo ms comn de escenario
es la descripcin 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 tcnica 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 informacin
que proporcionar. Hay una amplia gama de
tcnicas de prototipado-maquetas de papel
de la pantalla disea a las versiones beta de prueba de
productos-software y un fuerte solapamiento de
sus usos diferentes para la obtencin de requisitos
y para la validacin de requisitos (ver
seccin 6.2, de prototipos). Prototipos de baja fidelidad
a menudo se prefieren para evitar los grupos de inters
"Anclaje" de las caractersticas de menor importancia, incidentales
de un prototipo de mayor calidad que puede
limitar la flexibilidad de diseo de formas no deseadas.
Facilitado reuniones. El propsito de estos
reuniones es tratar de lograr un sumativa
efecto, mediante el cual un grupo de personas puede traer
ms informacin sobre sus requisitos de software
que trabajando individualmente. Ellos
pueden intercambiar ideas y refinar ideas que pueden ser
difcil 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 tcnica un conjunto de requisitos que de otro
modo podran
ser alcanzables. Sin embargo, las reuniones tienen que
se maneja con cuidado (de ah la necesidad de un
facilitador) para evitar una situacin en la que
las habilidades crticas 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 dems.
Observacin. La importancia de software
contexto en el ambiente organizacional
ha conducido a la adaptacin de observacional
tcnicas como la etnografa de
obtencin de requisitos. Los ingenieros de software
aprender sobre las tareas del usuario sumergindose
en el medio ambiente y observando cmo
los usuarios realizan sus tareas mediante la interaccin con
entre s y con herramientas de software y otro
recursos. Estas tcnicas son relativamente
caro, pero tambin 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 fcilmente.
Historias de usuarios. Esta tcnica es comnmente
utilizado en los mtodos de adaptacin (ver Mtodos giles
en los modelos de ingeniera de software
y Mtodos KA) y se refiere a una palabra, de alto nivel
descripciones de funcionalidad requerida
expresado en trminos de clientes. Un usuario tpico
historia tiene la forma: "Como <funcin>, quiero
<Meta / deseo> de modo que <benefician>. "Un usuario
historia est destinado a contener informacin suficiente
de modo que los desarrolladores pueden producir un
estimacin razonable del esfuerzo para poner en prctica
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 vlida antes de que comience el trabajo. Antes de que un usuario
historia se implementa, una aceptacin adecuada
procedimiento debe ser escrito por el cliente
para determinar si los objetivos de la
historia de usuario se han cumplido.
Otras tcnicas. Una gama de otras tcnicas
para el apoyo a la obtencin de los requisitos
existe informacin y van desde el anlisis
productos de la competencia a la aplicacin de la minera de datos
tcnicas para el uso de fuentes de dominio
conocimiento o solicitud del cliente de bases de datos.
Anlisis 4. Requisitos
[1 *, c4s1, c4s5, c10s4, c12s5]
[2 *, c7, c11, c12, c17]
Este tema tiene que ver con el proceso de anlisis
requisitos a
detectar y resolver los conflictos entre
requisitos;
descubrir los lmites del software y cmo
debe interactuar con su organizacin y
entorno operativo;
Requisitos del sistema elaborados para derivar software
requisitos.
La visin tradicional de anlisis de requerimientos
ha sido que ser reducido a modelado conceptual
usando uno de un nmero de mtodos de anlisis,
tales como el mtodo de anlisis estructurado. Mientras
modelado conceptual es importante, incluimos el
clasificacin de los requisitos para ayudar a informar a las compensaciones

entre los requisitos (clasificacin requisitos)

y el proceso de establecimiento de estos
compensaciones (requisitos negociacin).
Se debe tener cuidado para describir los requisitos
lo suficientemente precisa para permitir que los requisitos para
ser validados, su aplicacin a ser verificada,
y sus costes a estimar.
4.1. Requisitos Clasificacin
Requisitos pueden clasificarse en un nmero de
dimensiones. Algunos ejemplos son los siguientes:
Si el requisito es funcional o
no funcional (ver seccin 1.3, Funcional
y requisitos no funcionales).
Si el requisito se deriva de uno
o requisitos ms alto nivel o un emergente
propiedad (ver seccin 1.4, Emergent
Propiedades), o se estn imponiendo directamente en
el software por un interesado o algn otro
fuente.
Si el requisito es sobre el producto
o el proceso (ver seccin 1.2, del producto y de
Requisitos de proceso). Requisitos en el
proceso puede limitar la eleccin del contratista,
el proceso de ingeniera de software para ser adoptadas, o las normas que deben
respetarse.
La prioridad requisito. Cuanto mayor sea la prioridad,
ms 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
implementacin.
El alcance de la prescripcin. 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 satisfaccin 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 diseo de muchos
componentes, mientras que uno con un estrecho
alcance puede ofrecer una serie de opciones de diseo
y tienen poco impacto en la satisfaccin de
otros requerimientos.
Volatilidad / estabilidad. Algunos requisitos voluntad
cambiar durante el ciclo de vida del softwaree incluso durante el desarrollo
proceso en s mismo. Es til si alguna estimacin
de la probabilidad de que un requisito
el cambio se puede hacer. Por ejemplo, en una banca
de aplicacin, los requisitos para las funciones
para el clculo y el inters de crdito a los clientes '
cuentas es probable que sean ms estable que una
requisito para apoyar un tipo particular de
libre de impuestos cuenta. El primero refleja un derecho fundamental
caracterstica del dominio bancario (que
cuentas pueden ganar intereses), mientras que el segundo
puede ser obsoleto por un cambio de

la legislacin del gobierno. Cmo marcar potencialmente

requisitos voltiles pueden ayudar el software
disear establecer un diseo que es ms tolerante
del cambio.
Otras clasificaciones pueden ser apropiadas,
dependiendo de la prctica normal de la organizacin
y la propia aplicacin.
Hay un fuerte solapamiento entre los requisitos
atributos de clasificacin y requisitos (vase
seccin 7.3, Requisitos Atributos).
4.2. Modelado Conceptual
El desarrollo de modelos de un mundo real
problema es clave para el anlisis de los requisitos de software.
Su propsito es ayudar en la comprensin de la
situacin en la que se produce el problema, as como
representa una solucin. 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 ingeniera de software
Mtodos 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 eleccin de los modelos
notacin incluyen los siguientes:
La naturaleza del problema. Algunos tipos de
la demanda de software que se analizarn algunos aspectos
particularmente rigurosa. Por ejemplo,
modelos de estado y paramtricos, que son parte
de SysML [4], es probable que sean ms importante
para el software en tiempo real de la informacin
sistemas, al tiempo que normalmente sera el
frente a modelos de objetos y de actividad.
La experiencia del ingeniero de software. Es
a menudo ms productivo para adoptar una modelizacin
notacin o mtodo con el que el software
ingeniero tiene experiencia.
Los requisitos del proceso del cliente
(Ver seccin 1.2, Productos y Procesos
Requisitos). Los clientes pueden imponer su
notacin favorecida o mtodo o prohben cualquier
con los que no estn 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 construccin de un modelo del contexto software. Los
contexto software proporciona una conexin entre
los programas informticos 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 "ensear" un particular,

estilo de modelado o anotacin sino que proporciona

orientacin sobre el propsito y la intencin de la modelizacin.
4.3. Diseo y Requisitos de arquitectura
Asignacin
En algn momento, la arquitectura de la solucin debe
ser derivada. El diseo arquitectnico es el punto en
que el proceso se superpone con los requisitos
software o sistemas de diseo e ilustra cmo
imposible que es para desacoplar limpiamente las dos tareas.
Este tema est estrechamente relacionado con Estructura del software
y Arquitectura del Software Diseo KA. En
muchos casos, el ingeniero de software acta como software
arquitecto, porque el proceso de anlisis
y la elaboracin de los requisitos que exige
los componentes de la arquitectura / diseo que sern
responsable de satisfacer los requisitos de ser
identificado. Esta es la asignacin de requisitos-la
asignacin a componentes de la arquitectura responsables
para satisfacer los requisitos.
Asignacin es importante para permitir un anlisis 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 ms 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 asignacin estimula una
nueva ronda de anlisis 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 conduccin pobres, suavidad de aplicacin,

presin del pedal es necesario, y as sucesivamente) puede ser
asignado al hardware de frenado (mecnico
y conjuntos hidrulicos) y un antibloqueo
sistema (ABS). Slo 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 utilizarn para
identificar los requisitos detallados de software del ABS.
El diseo arquitectnico est estrechamente identificado con
modelado conceptual (ver seccin 4.2, conceptual
Modeling).
4.4. Requisitos Negociacin
Otro trmino comnmente utilizado para este subtema
es "la resolucin de conflictos." Esto se refiere a la resolucin de
problemas con los requisitos que los conflictos
ocurrir entre dos actores que requieren mutuamente
caractersticas incompatibles, entre los requisitos
y los recursos, o entre funcionales y no funcionales
requisitos, por ejemplo. En la mayora
casos, no es aconsejable para el ingeniero de software de
tomar una decisin unilateral, por lo que se hace necesario
consultar con la parte interesada (s) para llegar a una
consenso sobre una compensacin adecuada. A menudo es
importantes, por razones contractuales, que tales decisiones
Volveremos trazable al cliente. Tenemos
clasificado como un anlisis de los requisitos de software
tema porque los problemas surgen como el resultado
de anlisis. Sin embargo, un caso fuerte tambin puede ser

hecho por considerarlo una validacin requisitos

tema (vase el tema 6, Requisitos de validacin).
Requisitos de prioridades es necesaria, no
slo como un medio para filtrar los requisitos importantes,
sino tambin 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 estimacin. Sin embargo, a menudo es
difcil obtener informacin real que puede actuar como
una base para tales decisiones. Adems, los requisitos
menudo dependen unos de otros, y las prioridades
son relativos. En la prctica, los ingenieros de software
realizar requisitos priorizacin frecuencia
sin necesidad de conocer todos los requisitos.
Requisitos priorizacin puede seguir un costvalue
enfoque que implica un anlisis de
los actores que definen en una escala de los beneficios
o el valor agregado que la aplicacin
del requisito de los trae, frente a la
sanciones de no haber implementado un particular,
requisito. Tambin implica un anlisis desde
los ingenieros de software de estimacin en una escala del
costo de la implementacin de cada requisito, relativo
a otros requisitos. Otra priorizacin requisitos
enfoque llama la jerarqua analtica
proceso implica la comparacin de todos los pares nicos de
requisitos para determinar cul de los dos es de
mayor prioridad, y en qu medida.
4.5. Anlisis Formal
Preocupaciones de anlisis formales no slo el tema 4, pero

tambin las secciones 5.3 y 6.3. Este tema tambin es relacionado

a los mtodos formales en la Ingeniera de Software
Modelos y Mtodos rea de Conocimiento.
Anlisis formal ha hecho un impacto en algunos
dominios de aplicacin, en particular los de highintegrity
sistemas. La expresin formal de
requisitos requiere un lenguaje con formalmente
semntica definida. El uso de un anlisis formal
para los requisitos de expresin tiene dos beneficios.
En primer lugar, permite a los requisitos expresados en el
idioma que se especifica con precisin y sin ambigedades,
por lo tanto (en principio) evitando el potencial
a interpretaciones errneas. 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 educacin formal
razonamiento necesario para utilizar las herramientas restringe
la aplicacin ms amplia de anlisis formal.
La mayor anlisis formal se concentra en relativamente
las ltimas etapas de anlisis de requisitos. Es generalmente
contraproducente para aplicar formalizacin
hasta que los objetivos de negocio y necesidades de los usuarios
han entrado en un enfoque ntido a travs de medios tales
como los descritos en otras partes de la seccin 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 crticos. Esto permite
validacin esttica 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 Especificacin
[1 *, c4s2, c4s3, c12s2-5] [2 *, c10]
Para la mayora de las carreras de ingeniera, el trmino "especificacin"
se refiere a la asignacin de numrica
valores o lmites a los objetivos de diseo de un producto. En
ingeniera de software, "los requisitos de software
especificacin "tpicamente se refiere a la produccin de
un documento que puede ser revisado de forma sistemtica,
evaluado y aprobado. Para sistemas complejos,
particularmente aquellos que involucran nonsoftware sustancial
componentes, hasta tres diferentes
se producen tipos de documentos: definicin del sistema,
requisitos del sistema y los requisitos de software.
Para productos de software simples, slo el
tercio de stos se requiere. Los tres documentos son
descrito aqu, con el entendimiento de que
se pueden combinar segn sea apropiado. Una descripcin de
la ingeniera de sistemas puede encontrarse en la relacionados
Disciplinas de Ingeniera de Software captulo de
esta Gua.
5.1. Definicin 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 nmero de lectores incluye
representantes del sistema de los usuarios / clientes
(Marketing puede desempear estos roles para marketdriven
software), por lo que su contenido debe ser redactada
en trminos de dominio. El documento enumera el
requisitos del sistema, junto con el fondo
informacin sobre los objetivos generales para la
sistema, su entorno de destino, y una declaracin de
la limitaciones, supuestos, y no funcionales
requisitos. Puede incluir modelos conceptuales
diseado 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 avin moderno,
por ejemplo, a menudo separar la descripcin
de los requisitos del sistema de la descripcin
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
especificacin de requisitos es una ingeniera de sistemas
actividad y cae fuera del alcance de este
Gua.
5.3. Requisitos de software Especificacin
Requisitos de software de especificacin 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 comercializacin
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 especificacin permisos
una evaluacin rigurosa de los requisitos antes
diseo puede comenzar y reduce rediseo ms tarde. Eso
Tambin debe proporcionar una base realista para estimar
los costos del producto, riesgos y horarios.
Las organizaciones tambin pueden utilizar un requisitos de software
documento de especificacin como base para
el desarrollo de la verificacin y validacin efectiva
planes.
Requisitos de software proporciona la especificacin
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
especificacin, esto puede ser complementado por formales
o descripciones semiformales. Seleccin de
notaciones apropiadas permite requisitos particulares
y aspectos de la arquitectura de software a
se describir con ms precisin y concisin 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 crtica, regulatorio,

y ciertos otros tipos de software fiable.

Sin embargo, la eleccin de la notacin es a menudo limitada
por la formacin, 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 especificacin de requisitos de software a otra
variables del proyecto, tales como el costo, la aceptacin, el rendimiento,
horario, y reproducibilidad. Calidad
indicadores para las necesidades individuales de software
declaraciones de especificaciones incluyen imperativos,
directivas, frases dbiles, opciones y aplazamientos.
Indicadores para la totalidad de los requisitos de software
documento de especificacin incluye el tamao, facilidad de lectura,
especificacin, la profundidad y la estructura del texto.
6. Requisitos de validacin
[1 *, c4s6] [2 *, c13, c15]
Los documentos de requerimientos pueden estar sujetos a validacin
y procedimientos de verificacin. Los requisitos
puede ser validado para asegurarse de que el software
ingeniero ha entendido los requisitos; es
Tambin 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 estndares de la compaa documentados o
son incompatibles con la terminologa 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 inters,

incluyendo representantes del cliente
y desarrollador, debe revisar el documento (s).
Requisitos documentos estn sujetos a la misma
las prcticas de gestin de configuracin como la otra
entregables de los procesos del ciclo de vida del software.
Cuando sea prctico, los requisitos individuales son
tambin sujeto a la configuracin de gestin, por lo general
utilizando una herramienta de gestin de requisitos (ver
tema 8, Requisitos de software Herramientas).
Es normal para programar explcitamente uno o ms
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 validacin
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 ms comunes de la validacin
es por inspeccin o revisin de los requisitos
documento (s). Se asigna un grupo de revisores
una breve buscar errores, suposiciones errneas,
falta de claridad, y la desviacin de la prctica estndar.
La composicin del grupo que lleva a cabo
la crtica 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 orientacin sobre lo que debe buscar en

la forma de listas de comprobacin.

Los comentarios pueden ser constituidas al trmino de
el documento de definicin del sistema, la especificacin del sistema
documentos, los requisitos de software
documento de especificaciones, la especificacin de la lnea de base
para un nuevo lanzamiento, o en cualquier otro paso en la
proceso.
6.2. Prototipos
Prototipos es comnmente un medio para validar
la interpretacin que el ingeniero de software del software
requisitos, as como para la obtencin de nuevo
requisitos. Al igual que con la elicitacin, hay una gama
de prototipos tcnicas y una serie de puntos
en el proceso de validacin donde prototipo puede
ser apropiado. La ventaja de prototipos es
que pueden hacer que sea ms fcil de interpretar el software
supuestos de ingeniero y, cuando sea necesario,
dar informacin til sobre por qu estn equivocados. Por
ejemplo, el comportamiento dinmico de una interfaz de usuario
se puede entender mejor a travs de una animada
prototipo que a travs de la descripcin textual
o modelos grficos. La volatilidad de un requisito
que se define despus de la creacin de prototipos ha sido
hecho es extremadamente bajo porque no hay acuerdo
entre los grupos de inters y la ingeniera de software
Por lo tanto, para la seguridad crtico y crucial
caractersticas de prototipos sera de gran ayuda. Hay
tambin desventajas, sin embargo. Estos incluyen el
peligro de atencin de los usuarios que se distrajo de
el ncleo subyacente funcionalidad cosmtica

cuestiones o problemas de calidad con el prototipo. Por

esta razn, 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 errneos, su
coste se puede justificar ms fcilmente. Los primeros prototipos
puede contener aspectos de la solucin final.
Los prototipos pueden ser evolutiva en lugar de
tirar.
6.3. Validacin del Modelo
Es tpicamente necesario para validar la calidad de
los modelos desarrollados durante el anlisis. Por ejemplo,
en modelos de objetos, es til para realizar una
el anlisis esttico para verificar que las rutas de comunicacin
existir entre los objetos que, en los grupos de inters '
dominio, el intercambio de datos. Si notaciones de anlisis formales
se utilizan, es posible utilizar el razonamiento formal
para demostrar las propiedades de especificacin. Este tema es
estrechamente relacionados con los modelos de ingeniera de software
Mtodos y KA.
6.4. Pruebas de Aceptacin
Una propiedad esencial de un requisito de software
es que debera 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 cmo verificar
cada requisito. En la mayora de los casos, el diseo
pruebas de aceptacin hace por cmo los usuarios finales normalmente
realizar negocios utilizando el sistema.

La identificacin y el diseo de las pruebas de aceptacin

puede ser difcil para los requisitos no funcionales
(Ver seccin 1.3, funcionales y no funcionales
Requisitos). Para ser validado, deben primero
ser analizado y descompuesto hasta el punto donde
puedan expresarse cuantitativamente.
Informacin adicional se puede encontrar en la aceptacin /
Calificacin / Pruebas de conformidad en el
Software Testing KA.
7. Consideraciones prcticas
[1 *, c4s1, c4s4, c4s6, c4s7]
[2 *, c3, c12, c14, c16, c18-21]
El primer nivel de descomposicin 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 gestin del cambio y de la
el mantenimiento de los requisitos de un Estado que
espejos con precisin el software a construir, o que
se ha construido, son clave para el xito del software
proceso de ingeniera.
No todas las organizaciones tienen una cultura de la documentacin
y la gestin de requisitos. Es comn
en empresas de nueva creacin dinmica, impulsada por un
fuerte "visin del producto" y los recursos limitados, a
requisitos de documentacin 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
documentacin y gestin del cambio son la clave
para el xito de cualquier proceso de requisitos.
7.1. Naturaleza iterativa de los Requisitos
Proceso
Hay una presin general en la industria del software
para los ciclos de desarrollo cada vez ms cortos, y esto
es particularmente pronunciado en altamente competitivo,
sectores impulsados por el mercado. Por otra parte, la mayora de los proyectos
estn 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 prctica, por lo tanto, es casi siempre poco prctico
para implementar el proceso de requisitos como lineal,
proceso determinista en que los requisitos de software
se suscit a partir de los grupos de inters, lnea 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 tpicamente iterar hacia
un nivel de calidad y el detalle que sea suficiente para
permitir que las decisiones de diseo 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 ingeniera. Sin embargo, el software
ingenieros estn necesariamente limitados por proyecto

planes de gestin y, por tanto, debe tomar medidas

para asegurar que la "calidad" de los requisitos es
lo ms alto posible dados los recursos disponibles.
Deben, por ejemplo, hacer explcita 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 slo aquellos
requisitos necesarios para la iteracin actual. Los
especialista requisitos puede continuar desarrollando
requisitos para futuras iteraciones, mientras que los desarrolladores
proceder con el diseo y construccin de la
iteracin actual. Este enfoque proporciona a los clientes
con valor de negocio de forma rpida, minimizando
el costo de la reanudacin.
En casi todos los casos, los requisitos de comprensin
contina evolucionando como el diseo y desarrollo
procede. Esto a menudo conduce a la revisin de
requisitos finales en el ciclo de la vida. Tal vez la
el punto ms crucial en la comprensin de software
requisitos es que una proporcin significativa de
los requisitos cambiarn. Esto es a veces
debido a errores en el anlisis, 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 regulacin
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 revisin y aprobacin definido
y mediante la aplicacin de los requisitos cuidadosos trazado,
anlisis de impacto, y la configuracin del software
gestin (ver la configuracin del software
Gestin KA). Por lo tanto, el proceso de los requisitos
no es ms que una tarea de front-end en el software
el desarrollo, pero se extiende por toda la vida del software
ciclo. En un proyecto tpico, los requisitos de software
actividades evolucionan con el tiempo de obtencin
para la gestin del cambio. Una combinacin de arriba abajo
anlisis y diseo de mtodos y bottomup
mtodos de aplicacin y de refactorizacin que
reunirse en el centro podra ofrecer lo mejor de ambos
mundos. Sin embargo, esto es difcil de lograr en
practicar, ya que depende en gran medida de la madurez
y la experiencia de los ingenieros de software.
7.2. Gestin del cambio
La gestin del cambio es fundamental para la gestin
de requisitos. En este tema se describe el papel de
gestin del cambio, los procedimientos que deben
estar en su lugar, y el anlisis que se debe aplicar
a los cambios propuestos. Tiene fuertes vnculos con el Software
Configuracin KA Gestin.
7.3. Requisitos Atributos
Los requisitos deben consistir no slo de una especificacin
de lo que se requiere, sino tambin de auxiliares
informacin, 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 clasificacin Requisitos Clasificacin) y la verificacin
mtodo o seccin del plan de prueba de aceptacin correspondiente.
Tambin puede incluir informacin adicional, tal
como justificacin de resumen para cada requisito, el
fuente de cada requisito, y un historial de cambios.
Atribuyen Los requisitos ms importantes, sin embargo,
es un identificador que permite a los requisitos
para ser identificado de forma nica e inequvoca.
7.4. Requisitos Trazando
Requisitos de rastreo tiene que ver con la recuperacin
la fuente de los requisitos y la prediccin de la
efectos de los requisitos. El rastreo es fundamental
a la realizacin de anlisis de impacto cuando los requisitos
cambio. Un requisito debe ser trazable hacia atrs
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 diseo 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 mdulos de cdigo que lo implementan, o la
casos de prueba relacionados con ese cdigo y hasta un hecho
seccin 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 tpico
formarn un grfico acclico dirigido complejo

(DAG) (ver grficos en las Fundaciones Informtica

KA) de requisitos. El mantenimiento de un up-todate
grfico o matriz de trazabilidad es una actividad que
deben ser considerados durante todo el ciclo de vida
de un producto. Si la informacin de trazabilidad no es
actualizado como cambios en los requisitos continan
a suceder, la informacin de trazabilidad se convierte en
poco fiable para el anlisis de impacto.
7.5. Requisitos de medicin
Como una cuestin prctica, es tpicamente til tener
algn concepto del "volumen" de los requisitos
para un producto de software en particular. Esta
nmero es til para evaluar el "tamao" de un
cambio en los requisitos, en la estimacin del costo de
una tarea desarrollo o mantenimiento, o simplemente para
utilizar como denominador en otras mediciones.
Medicin de tamao funcional (FSM) es una tcnica
para evaluar el tamao de un cuerpo de funcional
requisitos.
Informacin adicional sobre la medida del tamao
y las normas se pueden encontrar en la Ingeniera de Software
Proceso KA.
8. Requisitos de software Herramientas
Herramientas para hacer frente a los requisitos de software caen
a grandes rasgos en dos categoras: herramientas para el modelado
y herramientas para la gestin de requisitos.
Herramientas de gestin de requisitos normalmente apoyan
una serie de actividades, incluyendo la documentacin,
trazado, y el cambio de gestin y tiene
tenido un impacto significativo en la prctica. De hecho, la localizacin

y la gestin del cambio son en realidad slo posible

si es compatible con una herramienta. Dado que los requisitos
gestin es fundamental para buenas requisitos
la prctica, muchas organizaciones han invertido
en herramientas de gestin de requisitos, aunque
muchos ms gestionar sus requisitos en ms
ad hoc y en general formas menos satisfactorias (por ejemplo,
utilizando hojas de clculo).