Sacado de la Guia SWEBOK

1. Capitulo 1
Requerimientos de Software
SIGLAS
GDA: Gráfico Dirigido Acíclico
MTF: Medida de Tamaño Funcional.
COINSIS: Consejo internacional sobre Ingeniería de sistemas.
LUM: Lengua Unificada de Modelaje.
SML: Sistemas que Modelan el Lenguaje.
INTRODUCCION
El Área de Conocimiento de Exigencias de Software el (AC) está preocupado por el
análisis, la especificación, y la validación de exigencias de software. Extensamente es
reconocido dentro de la industria que el software que traza proyectos es críticamente
vulnerable cuando estas actividades son realizadas mal.
Las exigencias de software expresan las necesidades y coacciones colocadas sobre un
producto de software que contribuye a la solución de algún problema mundial verdadero.
El término " exigencias de la ingeniería" es extensamente usado en el campo para
denotar el manejo sistemático de exigencias. Por motivos de consistencia, el término
"ingeniería" no será usado en la Guía sino para otra cosa que el software que trama en sí.
Por la misma razón, "las exigencias del ingeniero," un término que aparece en un poco de
la literatura, no será usado tampoco. En cambio, el término "el ingeniero de software" o,
en algunos casos específicos, " el especialista de exigencias " será usado, éste el donde
el papel en cuestión por lo general es realizado por un individuo otro que un ingeniero de
software. Esto no implica, sin embargo, que un ingeniero de software no pueda realizar la
función.
Un riesgo inherente en la interrupción propuesta consiste en que un proceso parecido a
una cascada puede ser deducido. Para protegerse contra esto, el subárea 2 Proceso de
Exigencias, es diseñado para proporcionar una descripción de alto nivel del proceso de
exigencias disponiendo de los recursos y coacciones bajo las cuales el proceso funciona y
que actúan para configurarlo.
Una descomposición alterna podría usar una estructura a base de producto (exigencias
de sistema, exigencias de software, prototipos, casos de empleo, etcétera). La
interrupción a base del proceso refleja el hecho que el proceso de exigencias, si debe ser
acertado, debe ser considerado como un proceso que implica el complejo, actividades

2. Requerimientos del
Software
Requerimientos del
software
fundamentales
Proceso de
Requerimientos
Elicitación de
Requerimientos
Análisis de
Requerimientos
Especificación de
Requerimientos
Validación de
Requerimientos
Definicion de
Requerimientos del
Software
Modelo de Procesos
Fuentes de
Requerimientos
Clasificacion de
Requerimientos
Documento de
Definicion de Sistema
Revisiones de
Requerimientos
Requerimientos del
producto y los
procesos.
Actores de Procesos
Tecnicas de Elicitacion
Modelado Conceptual
Especificacion de los
Requerimientos del
Sistema
Creacion de Prototipos
Requerimientos
funcionales y no
funcionales
Apoyo y Gestion de
Procesos
Diseño Arquitectónico
y Asignación de
Requerimientos
Especificacion de los
Requerimientos del
Software
Propiedades
Emergentes
Proceso de Calidad y
Mejora.
Negociacion de
Requerimientos
Requerimientos
cuantificables
Consideración Practica
Naturaleza Interactiva
del proceso de
requerimientos
Gestion del Cambio
Validacion del Modelo
Atributos de los
Requerimientos
Pruebas de Aceptacion
Rastreo de los
Requerimientos
Analisis Formal
Requerimientos de
Software y
Requerimientos de
sistemas
Figura 1: Interrupción de Asuntos para las Exigencias de Software
Medicion de los
Requerimientos
Herramientas de los
Requerimientos del
Software

3. Fuerte acopladas (tanto secuencial como simultáneo), más bien como una actividad
discreta, única realizada a comienzos de un proyecto de desarrollo de software.
Las Exigencias de Software son relacionadas estrechamente con el Diseño de Software,
Pruebas de Software, el Mantenimiento de Software, la Dirección de Configuración de
Software, Ingeniería del mantenimiento de software, el Proceso de Ingeniería de Software,
Ingeniería de los Modelos y Métodos de Software, y la Calidad de Software.
1. Requerimientos del Software fundamentales
1.1. Definición de un Software de requisito.
En su forma más básica, un requisito de software es una propiedad que debe ser exhibida
para solucionar algún problema en el mundo real. La guía se refiere a los requisitos en
"software" porque se refiere a los problemas a ser abordados por el software. Por lo tanto,
un requisito de software es una propiedad que debe ser exhibida por el software
desarrollado o adaptado para resolver un problema particular. Dicho software puede
apuntar para automatizar parte de una tarea de quien usará el software, para apoyar los
procesos de negocio de las organización que ha encargado el software, las deficiencias
correcta del software existente, o para controlar un dispositivo — por nombrar solo
algunos de los muchos problemas para que el software soluciones son posibles. Las
formas en que los usuarios, los procesos de negocio y dispositivosfunción son típicamente
complejos. Por extensión, por lo tanto, los requisitos de software en particular son
típicamente una combinación compleja de los requisitos de diferentes personas en
diferentes niveles de organización y del ambiente en el que el software funcionará.
Una característica esencial de todos los requisitos de software es que sean
comprobables. Puede ser difícil o costoso para verificar ciertos requisitos de software. Por
ejemplo, verificación de los requisitos de rendimiento en un centro de llamadas puede
requerir el desarrollo de software de simulación. Tanto los requisitos de software y calidad
personal debe asegurarse de que los requisitos pueden verificarse dentro de las
limitaciones de recursos disponibles.
Los Requisitos tienen otros atributos además de las propiedades del comportamiento que
expresan. Los ejemplos más comunes incluyen un grado de prioridad apermitir
compensaciones ante recursos finitos y un valor de estado para permitir el avance del
proyecto a ser monitoreados. Por lo general, requisitos de software únicamente son
identificados para que ellos puedan ser sometidos a control de la configuración del
software y gestionados por el software todo el ciclo de vida.
1.2. Requerimientos de proceso y producto
Se puede distinguir entre parámetros de producto y proceso. Parámetros del producto son
requisitos de software a desarrollarse (por ejemplo, "el software verificará que un
estudiante cumple con todos los requisitos antes de que él o ella se registra para un
curso").

4. Un parámetro de proceso es esencialmente una restricción en el desarrollo del software
(por ejemplo, "el software deberá estar escrito en Java"). Estos son a veces conocidos
como requisitos del proceso.
Algunos requisitos de software generan requisitos de proceso implícito. La elección de la
técnica de verificación es un ejemplo. Otro podría ser el uso de técnicas de análisis
particularmente riguroso (como los métodos de especificación formal) para reducir fallas
que pueden conducir a la insuficiente fiabilidad. También podrán imponer requisitos de
proceso directamente por la organización de desarrollo, sus clientes, o terceros como un
regulador de seguridad.
1.3. Funcionales y los requisitos no funcionales
Los requisitos funcionales describen las funciones que el software se va a ejecutar; por
ejemplo, formato de texto o una señal de modulación. Se conocen a veces como
capacidades. Los requisitos no funcionales son los que actúan para restringir la solución.
Los requisitos no funcionales son a veces conocidos como restricciones o requisitos de
calidad. Se pueden clasificar más lejos según sean los requisitos de rendimiento,
requisitos de mantenimiento, los requisitos de seguridad, requisitos de fiabilidad o uno de
muchos otros tipos de requisitos de software(véase también "Características de los
modelos y calidad" en el Software de calidad KA)
1.4. Propiedades emergentes
Algunos requisitos representan propiedades emergentes de software — es decir,
requisitos que no puede ser tratado por un solo componente, pero que dependen para su
satisfacción sobre cómo interoperan todos los componentes de software. El requisito de
rendimiento para un centro de llamadas, por ejemplo, depende cómo el sistema
telefónico, el sistema de información y los operadores interactuaban bajo condiciones de
funcionamiento reales. Propiedades emergentes dependen crucialmente de la
arquitectura del sistema.
.5. Requisitos Cuantificables
Los requisitos de Software, deberían indicarse claramente y sin ambigüedad posible y,
cuando proceda, cuantitativamente. Es importante evitar los requerimientos de vagos y no
se puede comprobar que dependen para su interpretación en juicio subjetivo ("el software
será confiable"; "el software es fácil de usar"). Esto es particularmente importante para los
requisitos no funcionales. Dos ejemplos de requisitos cuantificados son los siguientes:
software de un centro de llamadas debe aumentar el rendimiento del centro en un 20%; y
un sistema tendrá una probabilidad de generar un error fatal durante cualquier hora
deoperación de menos de 1 * 10−188 8. El requisito de rendimiento es a un nivel muy alto
y es necesario utilizar para derivar una serie de requisitos detallados. El requisito de
confiabilidad limitará fuertemente la arquitectura del sistema.

5. 1.6. Requisitos del sistema y los requisitos de Software
En este tema, "sistema" significa "una interacción combinación de elementos para lograr
un objetivo definido. Estos incluyen hardware, software, firmware, gente, información,
técnicas, instalaciones, servicios y otros elementos de apoyo”.
Requisitos del sistema son los requisitos para el sistema como un todo. En un sistema
que contiene componentes de software, requisitos de software se derivan de los requisitos
del sistema. La literatura sobre los requisitos a veces llama requisitos del sistema
"requisitos de usuario". La guía define "necesidades de los usuarios" de manera
restringida como los requisitos de los clientes o usuarios finales del sistema. Requisitos
del sistema, por el contrario, abarcan los requerimientos del usuario, requisitos de otras
partes interesadas (por ejemplo, las autoridades reguladoras) y requisitos sin un origen
humano identificable.
2. Proceso de Requisitos
Esta sección presenta el proceso de los requisitos del software, orientando las restantes
cinco subareas y mostrando cómo los requisitos concuerdan con el proceso general de
ingeniería de software.
2.1 Modelos de procesos.
El objetivo de este tema es proporcionar un entendimiento de que los requisitos del
proceso:
 No son una actividad de principio a fin discreta, del ciclo de vida del software, sino
más bien un proceso iniciado al principio de un proyecto que sigue siendo refinado
durante todo el ciclo de vida.
 Identifica los requerimientos de software como elementos de configuración y los
administra utilizando las mismas prácticas de gestión de configuración del software
como otro producto de los procesos de ciclo de vida del software.
 Debe ser adaptada al contexto y organización del proyecto.
En particular, el tema se refiere a cómo se configuran las actividades de obtención,
análisis, especificación y validación para los diferentes tipos de proyectos y limitaciones.
El tema también incluye actividades que proporcionan insumos en el proceso de
requisitos, tales como los estudios de Marketing y viabilidad.
2.2 Actores del Proceso
Este tema presenta los roles de las personas que participan en el proceso de requisitos.
Este proceso es fundamentalmente interdisciplinario, y el especialista en requisitos
necesita mediar entre el dominio de la parte interesada y la ingeniería de software. A
menudo hay muchas personas involucradas además del especialista de requerimientos,
cada uno de los cuales tiene una participación en el software. Las partes interesadas

6. variarán a través de proyectos pero siempre incluirá los usuarios y operadores y clientes
(que no tiene que ser el mismo).
Los ejemplos típicos de los actores de software incluyen (pero no están limitados a):
 Usuarios: Este grupo comprende aquellos que operarán el software. A menudo es
un grupo heterogéneo formado por personas con diferentes funciones y requisitos.
 Clientes: este grupo está conformado por aquellos que han encargado el software
o que representan el mercado objetivo del software.
 Los analistas del mercado: un producto de Mercado masivo no tendrá una puesta
en servicio al cliente, así que a menudo se necesitan personas de marketing para
establecer lo que necesita el mercado y para actuar como clientes.
 Reguladores: muchos dominios de aplicación, como lo bancario y el transporte
público, se encuentran regulados. El software en estos dominios debe cumplir con
los requisitos de las autoridades reguladoras.
 Ingenieros de Software: estos individuos tienen un interés legítimo en el beneficio
de desarrollar un software, por ejemplo, reutilizando los componentes en otros
productos. Si en este escenario, un cliente de un producto en particular tiene
necesidades específicas que comprometen las posibilidades de reutilización de
componentes, los ingenieros de software deben pensar cuidadosamente su propio
juego contra ésos del cliente.
No será posible satisfacer perfectamente las necesidades de todos los interesados, y
es trabajo del ingeniero software negociar las compensaciones que sean aceptables a
las principales partes interesadas y dentro del presupuesto, técnicas regulatorias y
otras restricciones. Un requisito previo para esto es que todas las partes interesadas
sean identificadas, la naturaleza de su "inversión" analizadas y sus requerimientos
sacados.
2.3. Apoyo y Gestión de Procesos.
Este tema presenta los recursos de gestión de proyectos requeridos y consumidos por el
proceso de requisitos. Establece el contexto para la primera subárea (definición de
iniciación y alcance) de la Gestión de Ingeniería de Software. Su propósito principal es
hacer el vínculo entre las actividades de proceso identificadas en el punto 2.1 y las
cuestiones de costo, recursos humanos, capacitación y herramientas.
2.4. Proceso de calidad y mejora.
Este tema se refiere a la evaluación de la calidad y la mejora del proceso de requisitos. Su
propósito es hacer hincapié en el papel clave que juega el proceso de requisitos en
términos de costo y puntualidad de un producto de software y de la satisfacción del cliente
con él. Ayudará a orientar el proceso de requisitos con estándares de calidad y modelos
de mejora de procesos de software y sistemas. Calidad del proceso y mejora se relaciona
estrechamente tanto el Software calidad KA y KA proceso de ingeniería del Software. Este
tema se trata:

7.  Requisitos de proceso, cobertura por estándares de mejora de procesos y
modelos;
 Requisitos de proceso de medidas y benchmarking (proceso sistemático y
continuo para evaluar los productos, servicios y procesos de trabajo de las
organizaciones);
 Planificación de la mejora e implementación.
3. Elicitacion de Requerimientos
La elicitación de requisitos se refiere a la procedencia de requisitos de software y cómo el
ingeniero de software puede juntarlos. Es la primera etapa en la construcción de una
comprensión del problema del software que es necesaria para resolver. Es
fundamentalmente una actividad humana y es donde se identifican los actores y las
relaciones establecidas entre el equipo de desarrollo y el cliente. Varios la denominan
"captura de requisitos", "descubrimiento de requisitos" y "adquisición de requisitos".
Uno de los principios fundamentales de la buena Ingeniería de software es que hay buena
comunicación entre los actores del software e ingenieros de software. Antes de que
comience el desarrollo, especialistas en requisitos pueden formar el conducto para la
comunicación. Deben mediar entre el dominio de los usuarios del software (y otras partes
interesadas) y el mundo técnico del ingeniero de software.
Un elemento crítico de la elicitación de requisitos es informar el alcance del proyecto. Se
trata de proporcionar una descripción del software a ser especificado y su propósito,
priorizando las entregas para garantizar que se satisfacen las necesidades del cliente más
importantes del negocio, primero. Esto reduce el riesgo de que los especialistas de
requisitos demoren más tiempo elicitando requisitos que son de poca importancia o
aquellos que resultan ya no ser relevantes cuando el software se es entregado.
3.1. Fuentes de Requisitos.
Los requisitos tienen muchas fuentes en el software típico, y es esencial que todas las
fuentes potenciales sean identificadas y evaluadas. Este tema está diseñado para
promover el conocimiento de las distintas fuentes de requisitos de software y de los
marcos para gestionarlos. Son los puntos principales cubiertos:
 Objetivos. El término "objetivo" (a veces llamado "la preocupación de negocio" o
"factor crítico de éxito") se refiere a los objetivos generales de alto nivel del
software. Los objetivos proporcionan la motivación para el software pero son a
menudo vagamente formulados. Los Ingenieros de software necesitan prestar
especial atención a la evaluación del valor (en relación con prioridad) y costo de
las metas. Un estudio de viabilidad es una forma relativamente barata de hacer
esto.
 Conocimiento de dominio. El ingeniero de software necesita adquirir o disponer,
conocimiento sobre el dominio de aplicación. El conocimiento del dominio
proporciona el fondo contra el cual deben establecerse requisitos sacando todos
los conocimientos para entenderlo.

8.  Partes interesadas (véase tema 2.2 actores del proceso). Muchos software han
demostrado ser satisfactorios porque lo han subrayado las necesidades de un
grupo de partes interesadas a expensas de los demás. Por lo tanto, el software
suministrado es difícil de usar o subvierte las estructuras culturales o políticas de
la organización del cliente. El ingeniero de software debe identificar, representar y
administrar los "miradores" de muchos tipos diferentes de las partes interesadas.
 Reglas del negocio. Estas son declaraciones que definen o limitan algunos
aspectos de la estructura o el comportamiento del negocio propio. "Un estudiante
no puede registrarse en cursos del próximo semestre si quedan algunos sin pagar
la matrícula" sería un ejemplo de una regla de negocio que sería una fuente de
requisito para el software de registro de curso de una universidad.
 El entorno operativo. Los requisitos se derivarán del ambiente en el cual se
ejecutará el software. Estos pueden ser, por ejemplo, restricciones de
sincronización en tiempo real del software o interoperabilidad restricciones en un
ambiente de negocios. Estos deben ser activamente buscados porque pueden en
grandes proporciones afectar la factibilidad y costo del software así como restringir
las opciones de diseño.
 El clima organizacional. Un software es a menudo necesario para apoyar un
proceso de negocio, la selección de los cuales puede estar condicionada por la
estructura, la cultura y la política interna de la organización. Las necesidades del
ingeniero de software deben ser sensibles a estos ya que, en general, un nuevo
software no debería obligar a un cambio imprevisto en los procesos de negocio.
3.2. Técnicas de Elicitación.
Una vez que se han identificado las fuentes de requisitos, el ingeniero de software puede
empezar a obtener la información de requisitos de ellos. Tenga en cuenta que los
requisitos son rara vez sacados o confeccionados. Por el contrario, el ingeniero de
software provoca que se formulen los requerimientos de información. Este tema se centra
en las técnicas para conseguir actores humanos para articular la información relacionada
con los requisitos. Es una tarea muy difícil y el ingeniero de software debe sensibilizarse
al hecho de que los usuarios (por ejemplo) pueden tener dificultades para describir sus
tareas, pueden dejar importante información que no se expresa o pueden ser incapaces
de cooperar. Es particularmente importante entender que la elicitación no es una actividad
pasiva y que, incluso si actores cooperativos y articulados están disponibles, el ingeniero
de software tiene que trabajar duro para obtener la información correcta. Gran parte de los
negocios o los requerimientos técnicos es tácito o en comentarios que aún debe
obtenerse de los usuarios finales. No puede exagerarse la importancia de la planificación,
verificación y validación en toma de requerimientos. Existe un número de técnicas para la
toma de requerimientos, siendo los principales:
 Entrevistas. un medio "tradicional" de obtención de requisitos. Es importante
comprender las ventajas y limitaciones de las entrevistas y cómo debe realizarse.
 Escenarios, significa un valioso contexto para proporcionar la elicitación de
requisitos de usuario. Permiten al ingeniero de software proporcionar un marco

9. 



para preguntas acerca de las tareas del usuario permitiendo que "si" y "Cómo se
hace esto" sean preguntas que formular. El tipo más común de escenario es la
descripción de casos de uso. Hay un enlace a topic4.2 (modelado Conceptual)
porque las notaciones de escenario como diagramas de casos de uso son
comunes en software de modelado.
Prototipos, una valiosa herramienta para clarificar los requisitos claros. Pueden
actuar de una manera similar a escenarios ofreciendo a los usuarios un contexto
dentro del cual puedan entender mejor qué información necesitan proporcionar.
Hay una amplia gama de técnicas de prototipos de maquetas de papel, de diseños
de pantalla a las versiones beta-test de productos de software y un fuerte
compromiso de su propio uso por separado para la toma de requerimientos y
validación de requisitos (Ver tema 6.2 Prototipos).
Facilitación de reuniones. El propósito de estos encuentros es tratar de lograr un
efecto sumatorio, por el que un grupo de personas puede aportar una visión más
clara en sus requerimientos de software que al trabajar individualmente. Pueden
pensar y refinar ideas que pueden ser difíciles de llevar a la superficie mediante
entrevistas. Otra ventaja es que los requisitos de superficie pueden ser
contradictorios desde el principio de una manera que permite a las partes
interesadas reconocer donde hay conflicto. Cuando funciona bien, esta técnica
puede resultar en una serie de requisitos más rica y más consistente de lo
contrario podría ser factible. Sin embargo, las reuniones deben ser manipuladas
con cuidado (por lo tanto, la necesidad de un facilitador) para prevenir una
situación en la cual las capacidades críticas del equipo están erosionadas por
lealtad de grupo o en los requisitos que refleja las preocupaciones de algunas
personas abiertamente (y quizás último) son favorecidas en detrimento de otros.
Observación. La importancia del contexto de software en el entorno organizacional
ha llevado a la adaptación de las técnicas observacionales como etnografía para
toma de requerimientos. Ingenieros de software aprenden acerca de las tareas del
usuario que se sumerge en el ambiente y observando cómo los usuarios realizan
sus tareas al interactuar con los demás y con herramientas de software y otros
recursos. Estas técnicas son relativamente caras pero también instructivas porque
ilustran muchas tareas de usuario y procesos de negocios que son muy sutiles y
complejos para que sus actores puedan describir fácilmente.
Historias de usuario. Esta técnica se utiliza comúnmente en metodologías ágiles
(vea el tema "Métodos ágiles" en el área de conocimiento de métodos y modelos
de ingeniería de Software) y se refiere a las descripciones cortas de alto nivel de
funcionalidad requerida expresada en términos de atención al cliente. Una historia
de usuario está destinada a contener suficiente información para que los
desarrolladores puedan producir una estimación razonable del esfuerzo para
implementarlo. El objetivo es evitar algunos de los residuos que suceden a
menudo en proyectos donde están reunidos los requisitos detallados
anteriormente pero deben ser válidos antes de que comience el trabajo. Antes de
implementar una historia de usuario, deberá escribirse un procedimiento apropiado

10. de aceptación por parte del cliente para determinar si se han cumplido los
objetivos de la historia de usuario.
 Otras técnicas. Existe una variedad de otras técnicas para apoyar la elicitación de
requisitos de información y van desde análisis de productos de la competencia a la
aplicación de técnicas de minería de datos a utilizar fuentes de bases de dominio,
conocimiento o petición de cliente.
4. Análisis de requerimientos.
Este tema tiene que ver con el proceso de analizar los requisitos para:
 Detectar y resolver conflictos entre requisitos.
 Descubre los límites del software y de cómo debe interactuar con su ambiente.
 Requisitos del sistema elaborado para derivar requerimientos de software.
La visión tradicional del análisis de requerimientos ha sido que se reduzca el Modelado
conceptual utilizando uno de un número de métodos de análisis, tales como el método de
análisis estructurado. Mientras que el modelado conceptual es importante, se incluye la
clasificación de los requisitos para ayudar a informar disyuntivas entre requisitos
(clasificación de requisitos) y el proceso de establecer estas disyuntivas (negociación de
requisitos).
Debe tenerse cuidado para describir los requisitos precisamente lo suficiente para permitir
que los requisitos sean validadospara su aplicación, verificando sus costos para ser
estimados.
4.1. Clasificación de los Requisitos.
Los requisitos se pueden clasificar en varias dimensiones. Los ejemplos incluyen:
 Si el requisito es funcional o no funcional (Ver tema 1.3 requisitos funcionales y no
funcionales).
 Si el requisito es derivado de uno o más requisitos de alto nivel o de una propiedad
emergente (véase tema 1.4 propiedades emergentes) o está imponiendo
directamente en el software de un participante o de alguna otra fuente.
 Si el requisito es sobre el producto o el proceso (véase 1.2 producto y requisitos
de proceso). Los requisitos en el proceso pueden restringir la elección del
contratista, el proceso de ingeniería de software para ser adoptado o las normas a
seguirse.
 La prioridad del requisito. Cuanto mayor sea la prioridad, lo más esencial es el
requisito para cumplir los objetivos generales del software. A menudo se clasifican
en una escala de punto fijo como obligatorio, altamente deseable, deseable, u
opcional, la prioridad a menudo tiene que sopesar el costo de desarrollo e
implementación. La priorización de requisitos es necesaria no sólo como un medio
para filtrar requisitos importantes, sino también para resolver los conflictos y
planes de puesta en escena de las entregas, lo que significa tomar decisiones
complejas que requieran dominio detallado de los conocimientos y habilidades de

11. buena estimación. Sin embargo, a menudo es difícil obtener información real que
puede actuar como una base para este tipo de decisiones. Además, los requisitos
a menudo dependen mutuamente y sus prioridades son relativas. En la práctica,
ingenieros de software realizan priorización de requerimientos con frecuencia sin
conocer todos los requisitos.
 El alcance del requisito. Este ámbito de aplicación se refiere a la medida en que
afecta un requisito del software y componentes de software. Algunos requisitos,
especialmente los no funcionales, tienen un alcance global en que su satisfacción
no puede asignarse a un componente discreto. Por lo tanto, un requisito con
ámbito global afecta fuertemente a la arquitectura de software y el diseño de
muchos componentes, mientras que uno con un alcance acotado puede ofrecer un
número de opciones de diseño y tienen poco impacto en la satisfacción de otras
necesidades.
 Volatilidad/estabilidad. Algunos requisitos cambiarán durante el ciclo de vida del
software e incluso durante el proceso de desarrollo propio. Es útil si se puede
hacer una estimación de la probabilidad de que un requisito va a cambiar. Por
ejemplo, en una aplicación bancaria, los requisitos de las funciones para calcular
el interés de crédito delas cuentas de los clientes serán probablemente más
estables que un requisito para apoyar un tipo particular de cuenta libre de
impuestos. Los primeros reflejan una característica fundamental del dominio
bancario (que cuentas pueden ganar interés), mientras que este último puede ser
obsoleta por un cambio en la legislación del gobierno. Al marcar los requisitos
potencialmente volátiles puede ayudar al ingeniero de software a establecer un
diseño que es más tolerante al cambio.
Otras clasificaciones pueden ser apropiadas, dependiendo de la práctica habitual de la
organización y de la propia aplicación.
Hay una fuerte superposición entre la clasificación de los requisitos y atributos de
requisitos (véase tema 7.3 requisitos atributos).
4.2. Modelado conceptual.
El desarrollo de modelos de un problema del mundo real es clave para el análisis de
requisitos de software. Su propósito es ayudar a comprender el problema, más que todo
para iniciar el diseño de la solución. Por lo tanto, los modelos conceptuales constituyen
modelos de entidades del problema de dominio configurado para reflejar sus reales
relaciones y dependencias. Este tema está estrechamente relacionado al área de
conocimiento de métodos y modelos de ingeniería de Software.
Se pueden desarrollar varios tipos de modelos. Estos incluyen diagramas de casos de
uso, modelos de flujo de datos, modelos de estado, los modelos basados en la meta, las
interacciones del usuario, modelos de objetos, modelos de datos y muchos otros. Muchas
de estas notaciones de modelado son parte de la Unified Modeling Language (UML).
Diagramas de casos de uso, por ejemplo, se utilizan habitualmente para proporcionar un

12. medio de representar el límite de software, una vista de alto nivel de su comportamiento
(los casos de uso) y los actores en el entorno de software.
Los factores que influyen en la elección de la notación de modelado incluyen:
 La naturaleza del problema. Algunos tipos de software demandan que algunos
aspectos se analicen rigurosamente. Por ejemplo, los estados y modelos
paramétricos, que forman parte de SysML [2], son propensos a ser más importante
para el software en tiempo real que para los sistemas de información, mientras
que normalmente sería lo contrario para los modelos de objeto y actividad.
 La experiencia del ingeniero de software. Suele ser más productivo de adoptar la
notación de modelado o método con el cual el ingeniero de software tiene
experiencia.
 Los requisitos del proceso del cliente (Ver tema 1.2 requerimientos de proceso y
producto). Los clientes pueden imponer su notación favorecida o método o prohibir
que son desconocidos. Este factor puede entrar en conflicto con el factor anterior.
Tenga en cuenta que, en casi todos los casos, es útil comenzar con la construcción de un
modelo del contexto de software. El contexto de software proporciona una conexión entre
el software previsto y su ambiente externo. Esto es crucial para entender el contexto del
software en su entorno operacional y la identificación de sus interfaces con el medio
ambiente.
Este tema no pretende "enseñar" un estilo particular de modelado o notación pero
proporciona una guía sobre el propósito y la intención de modelado.
4.3. Proyectos arquitectónicos y asignación de requisitos.
En algún momento, la arquitectura de la solución debe ser derivada. El diseño
arquitectónico es el punto en que el proceso de requisitos se superpone con el diseño de
software o sistemas e ilustra lo imposible que es separar limpiamente las dos tareas. Este
tema se relaciona estrechamente con la subzona de Software. En muchos casos, el
ingeniero de software actúa como arquitecto de software porque el proceso de analizar y
elaborar los requisitos exige que los componentes que se encargan de satisfacer los
requisitos deban ser identificados. Esta es la asignación de requisitos, la asignación a los
componentes de la responsabilidad de satisfacer los requisitos.
La asignación es importante para permitir un análisis detallado de los requisitos. Por lo
tanto, por ejemplo, una vez que un conjunto de requisitos ha sido asignado a un
componente, las necesidades individuales pueden ser más analizadas para descubrir aún
más los requisitos de cómo el componente necesita interactuar con otros componentes
con el fin de satisfacer los requisitos asignados. En grandes proyectos, la asignación
estimula una nueva ronda de análisis para cada subsistema. Por ejemplo, los requisitos
para un determinado rendimiento de frenado para un auto (distancia de frenado,
condiciones de seguridad en la conducción pobre, suavidad de aplicación, presión en el
pedal requerida) pueden asignarse al hardware frenado (Asambleas mecánicas e
hidráulicas) y un sistema de frenos antibloqueo (ABS). Sólo cuando se ha identificado un

13. requisito para un sistema de frenado antibloqueo, y los requisitos asignados a él, puede
las capacidades del ABS, el frenado hardware y propiedades emergentes (como el peso
del coche) utilizarse para identificar los requisitos detallados del software ABS.
El diseño arquitectónico está estrechamente identificado con modelado conceptual (Ver
tema 4.2 modelado Conceptual).
4.4. Requisitos de negociación.
Otro término usado comúnmente para este subtema es "resolución de conflictos". Esto
concierne en resolver problemas con requisitos donde se producen conflictos entre dos
actores que requieren características mutuamente incompatibles, entre recursos y
requisitos o entre los requerimientos funcionales y no funcionales, por ejemplo. En la
mayoría de los casos, no es prudente para el ingeniero de software tomar una decisión
unilateral, y entonces se hace necesario consultar con las partes interesadas para
alcanzar un consenso sobre una compensación adecuada. A menudo es importante, por
razones contractuales, que tales decisiones sean trazables al cliente. Hemos clasificado
esto como un tema de análisis de requisitos de software porque surgen problemas como
el resultado del análisis. Sin embargo, también puede hacerse un fuerte caso por
considerarlo un tema de validación de requisitos.
4.5. Análisis formal.
Las preocupaciones del análisis formal conciernen no sólo a la sección 4, sino también al
inciso 5.3 y 6.3. Este tema también está relacionado con el tema "Métodos formales" en el
área de conocimiento de métodos y modelos de ingeniería de Software. El análisis formal
ha tenido un impacto en algunos dominios de aplicación, particularmente los de sistemas
de alta integridad. La expresión formal de los requisitos requiere un lenguaje con
semántica formalmente definida. El uso de un análisis formal para la expresión de
requisitos tiene dos ventajas. En primer lugar, permite a los requisitos expresados en el
lenguaje especificarse con precisión y sin ambigüedades, por lo tanto (en principio)
evitando la posibilidad de una interpretación errónea. En segundo lugar, los requisitos se
pueden razonar, permitiendo propiedades deseadas del software especificado que debe
ser probado. El razonamiento formal requiere herramientas de apoyo que sean posible
para que no sean sistemas y herramientas triviales que generalmente caen en dos tipos;
Teoremas o damas modelo. En ningún caso puede probar
ser completamente
automatizado, y el nivel de competencia en razonamiento formal necesario para utilizar
las herramientas restringe la aplicación más amplia del análisis formal.
El análisis más formal se centra en etapas relativamente tardías de análisis de
requerimientos. Es generalmente contraproducente aplicar formalización hasta los
objetivos de negocio y las necesidades de los usuarios han entrado bien enfocadas a
través de medios como los que se describe en la sección 4. Sin embargo, una vez los
requisitos se hayan estabilizado y elaborado para especificar las propiedades concretas
del software, puede ser beneficioso formalizar al menos los requisitos críticos. Esto
permite la validación estática del software especificado por los requisitos; de hecho tiene

14. las propiedades (por ejemplo, ausencia de bloqueo) que el ingeniero de software, los
usuarios y clientes que esperan.
5. Especificación de los requisitos.
Para las profesiones de ingeniería, el término "especificación" se refiere a la asignación
de valores numéricos o límites objetivos de diseño de un producto. En la jerga de la
ingeniería de software, "especificación de requisitos de software" se refiere normalmente
a la producción de un documento que puede ser sistemáticamente revisado, evaluado y
aprobado. Para los sistemas complejos, especialmente aquellos que involucran
componentes de software no-substanciales, tantos como tres diferentes tipos de
documentos se producen: definición de sistema, requisitos del sistema y requisitos de
software. Para productos de software simple, sólo la tercera parte de éstos se requiere.
Los tres documentos se describen aquí, con el entendimiento de que se puede combinar
según corresponda. Puede encontrarse una descripción de los sistemas de ingeniería en
las disciplinas relacionadas de Ingeniería de Software.
5.1. Documento de definición del sistema.
Este documento (a veces conocido como el documento de requisitos de usuario o el
concepto de operaciones) registra los requisitos del sistema. Define los requisitos de alto
nivel del sistema desde la perspectiva de dominio. Sus lectores incluyen representantes
de los usuarios/clientes de sistema (marketing puede desempeñar estas funciones de
software orientados al mercado), así que su contenido debe ser redactado en términos de
dominio. El documento enumera los requisitos del sistema junto con información acerca
de los objetivos generales para el sistema, su entorno de destino y una declaración de las
limitaciones, supuestos y los requisitos no funcionales. Puede incluir modelos
conceptuales diseñados para ilustrar el contexto del sistema, los escenarios de uso y las
entidades de dominio principal, así como los flujos de trabajo.
5.2. Sistema de especificación de requisitos.
Los desarrolladores de sistemas con software substancial y componentes de software —
un avión moderno, por ejemplo — a menudo separan la descripción de los requisitos del
sistema de la descripción de requisitos de software. En este punto de vista, se especifican
los requisitos del sistema, los requisitos de software se derivan de los requisitos del
sistema, y luego se especifican los requisitos para los componentes de software.
Estrictamente hablando, especificación de requisitos de sistema es una actividad de
ingeniería de sistemas y cae fuera del alcance de esta guía.
5.3. Software de especificación de requisitos.
El software de especificación de requisitosestablece las bases para el acuerdo entre
clientes y contratistas o proveedores (en proyectos impulsados por el mercado, estas
funciones pueden ser interpretadas por las divisiones de marketing y desarrollo) en lo que
es el producto de software a hacer así como lo que no se espera que haga.

15. El software de especificación de requisitos permite una evaluación rigurosa de los
requisitos, antes del diseño se puede comenzar y reducir el rediseño más adelante.
Asimismo deberá aportar una base realista para la estimación de los horarios, los riesgos
y los costos del producto.
Las organizaciones también pueden utilizar un documento de especificación de requisitos
de software para desarrollar sus propios planes de validación y verificación más
productivamente.
El software de especificación de requisitos proporciona una base informada para transferir
un producto de software a nuevos usuarios o plataformas de software. Por último, puede
proporcionar una base para la mejora de software.
Los requisitos de software a menudo están escritos en lenguaje natural, pero en el
software de especificación de requisitos, esto podrá completarse con las descripciones
formales o semi-formales. La selección de notaciones apropiadas permite requisitos
específicos y aspectos de la arquitectura de software que se describirán más precisa y
concisamente ese lenguaje natural. La regla general es que se deben utilizar notaciones
que permiten la mayor precisión posible de los requisitos para ser descrito. Esto es
particularmente crucial para críticos y ciertos otros tipos de software confiable. Sin
embargo, la elección de la notación a menudo está limitada por la formación, habilidades
y preferencias de los lectores y autores del documento.
Una serie de indicadores de calidad han desarrollado, que puede utilizarse para relacionar
la calidad de la especificación de requisitos de software para otras variables del proyecto
como costo, aceptación, rendimiento, horario y reproducibilidad. Los indicadores de
calidad para las declaraciones de especificación de requisitos software individual son
imperativos, directivas, frases débiles, opciones y aplazamientos. Los indicadores para el
documento de especificación de requisitos software completo incluyen tamaño, legibilidad,
especificación, profundidad y estructura del texto.
6. Validación de requisitos.
Los documentos de los requisitos pueden estar sujetos a procedimientos de validación y
verificación. Los requisitos pueden ser validados para asegurarse de que el ingeniero de
software ha comprendido los requisitos; también es importante verificar que un documento
de requisitos conforme a las normas de la empresa debe ser entendible, coherente y
completo. Notaciones formales ofrecen la ventaja de permitir que las dos últimas
propiedades deban ser probadas (en un sentido restringido, por lo menos). Diferentes
actores, incluyendo a representantes del cliente y desarrollador, deben revisar los
documentos. Los documentos de requisitos están sujetos a las mismas prácticas de
gestión de configuración de software que las otras entregas de los procesos de ciclo de
vida del software.
Es normal programar uno o más puntos en el proceso de requisitos donde se validan los
requisitos. El objetivo es recoger cualquier problema antes de que los recursos se hayan
comprometido a atender los requerimientos. La validación de requisitos se refiere al

16. proceso de examinar el documento de requisitos para garantizar que se define el software
adecuado (es decir, el software que los usuarios esperan).
6.1. Comentarios de los requisitos.
Quizás los medios más comunes de validación son por inspección o revisiones del
documento de requisitos. Se asigna un grupo de árbitros para buscar errores,
suposiciones erróneas, falta de claridad y la desviación de la práctica estándar. La
composición del grupo que realiza la revisión es importante (al menos un representante
del cliente debe ser incluido en un proyecto orientado hacia el cliente, por ejemplo), y
puede ayudar a proporcionar orientación sobre lo que debe buscar en forma de listas.
Los comentarios podrán estar constituidos al finalizar el documento de definición del
sistema, el documento de especificación del sistema, el documento de especificación de
requisitos de software, la especificación de línea de base para una nueva versión, o en
cualquier otro paso en el proceso.
6.2. Creación de un prototipo.
Los prototipos comúnmente son un medio para la validación de interpretación al ingeniero
de software de los requisitos de software, así como para la obtención de nuevos
requerimientos. Como con el desencadenamiento, hay una gama de técnicas de creación
de prototipos y una serie de puntos en el proceso donde la validación del prototipo puede
ser apropiado. La ventaja de los prototipos es que pueden llegar más fácil a interpretar
supuestos del ingeniero de software y, donde sea necesario, dar información útil sobre por
qué se equivocan. Por ejemplo, se puede entender mejor el comportamiento dinámico de
una interfaz de usuario a través de un prototipo animado que a través de la descripción
textual o modelos gráficos. También hay desventajas, estos incluyen el peligro de que la
atención de los usuarios pueda distraerse del núcleo de la funcionalidad subyacente por
cuestiones cosméticas o problemas de calidad con el prototipo. Por esta razón, algunos
abogan por prototipos que eviten el software, tales como maquetas basados en el
portafolio. Los prototipos pueden ser costosos para desarrollar, sin embargo, si evitan el
despilfarro de recursos causado por intentar satisfacer requisitos erróneos, su costo
puede justificarse más fácilmente.
6.3. Modelo de validación.
Es normalmente necesario validar la calidad de los modelos desarrollados durante el
análisis. Por ejemplo, en modelos de objetos, es útil a la colección, un análisis estático
para verificar que existen vías de comunicación entre objetos que, en el dominio de las
partes interesadas, intercambian datos. Si se utilizan las notaciones de análisis formal, es
posible utilizar un razonamiento formal para probar las propiedades de la especificación.
Este tema está estrechamente relacionado con los métodos y modelos de ingeniería de
Software.
6.4. Aceptación de pruebas.

17. Una característica esencial de un requisito de software es que debe ser posible validar
que satisface el producto terminado. Requisitos que no pueden ser validados son
realmente "deseos". Una tarea importante es estar planeando cómo comprobar cada
requisito. En la mayoría de los casos, diseñar pruebas de aceptación hace esto.
Identificar y diseñar pruebas de aceptación pueden ser difíciles para los requisitos no
funcionales (Ver tema 1.3 funcionales y los requisitos no funcionales). Para ser validado,
primero deben ser analizados y descompuestos al punto donde ellos pueden expresarse
cuantitativamente.
Información adicional puede encontrarse en el KA de pruebas de Software, pruebas de
aceptación/calificación/pruebas de conformidad.
7. Consideraciones Prácticas.
El primer nivel de descomposición de la subzona presentado puede parecer describir una
secuencia lineal de actividades. Esta es una visión simplificada del proceso.
El proceso de requisitos extiende el ciclo de vida de todo software. La administración de
cambios y el mantenimiento de los requisitos de un estado que refleja con precisión el
software a construir, o que ha sido construido, es clave para el éxito del proceso de
ingeniería del software.
No toda organización tiene una cultura de documentación y gestión de requisitos. Es
común en empresas dinámicas, impulsadas por una fuerte "visión de producto" y recursos
limitados, ver la documentación de los requisitos como una sobrecarga innecesaria. Más a
menudo, sin embargo, a medida que estas empresas aumentan, como su cliente base
crece, y cuando su producto comienza a evolucionar, descubren que tienen que recuperar
los requisitos que motivaron características del producto con el fin de evaluar el impacto
de los cambios propuestos. Por lo tanto, los requisitos documentación y gestión del
cambio son clave para el éxito de cualquier proceso de requisitos.
7.1. Naturaleza interactiva del proceso de requisitos.
Hay presión general en la industria del software para que haya ciclos de desarrollo más
cortos y esto es particularmente pronunciado en sectores altamente competitivos,
impulsado por el mercado. Además, la mayoría de proyectos está limitada de alguna
manera por su entorno, y muchos son actualizaciones o revisiones de software existente
donde la arquitectura es dada. Por lo tanto,en la prácticacasi siempre resulta poco
práctico implementar el proceso de requisitos como un proceso lineal y determinista en
que el software de requisitos es sacado de las partes interesadas, asignado y entregado
al equipo de desarrollo de software. Ciertamente es un mito que los requisitos para
grandes proyectos de software son siempre perfectamente entendidos o perfectamente
especificados.

18. En cambio, los requisitos normalmente interactúan hacia un nivel de calidad y detalle
suficiente para permitirle a las decisiones de diseño y aprovisionamiento realizarse. En
algunos proyectos, esto puede resultar ser una base ante todas sus propiedades que se
entienden plenamente en los requisitos. El riesgo es que el trabajo sea costoso si surgen
problemas en el proceso de ingeniería de software. Sin embargo, los ingenieros de
software están necesariamente limitados por planes de gestión de proyecto y por lo tanto,
deben tomar medidas para asegurarse de que la “calidad” de los requisitos sea lo más
alta posible dados los recursos disponibles. Deberían, por ejemplo, hacer explícitamente
las suposiciones que apuntan los requisitos, así como problemas conocidos.
En casi todos los casos proceden requisitos de comprensión que siguen evolucionando el
diseño y desarrollo. Esto a menudo conduce a la revisión de los requisitos en el ciclo de
vida. Quizás el punto más crucial en el entendimiento de la ingeniería de requerimientos
es que una proporción significativa de los requerimientos va a cambiar. Esto es a veces
debido a errores en el análisis, pero con frecuencia es una consecuencia inevitable del
cambio en el “ambiente”, por ejemplo, el cliente de funcionamiento, o el ambiente de
negocios, o el mercado en que el software debe vender. Cualquiera que sea la causa, es
importante reconocer la inevitabilidad del cambio y tomar medidas para mitigar sus
efectos. El cambio tiene que gestionarse para asegurar que los cambios propuestos
pasen por una revisión definida y un proceso de aprobación y, mediante la aplicación de
requisitos cuidadosos como el seguimiento, análisis y gestión de la configuración de
software de impacto. Por lo tanto, el proceso de requisitos no es simplemente una tarea
de principio a fin en el desarrollo del software sino que se extiende a todo el ciclo de vida
de un software. En un proyecto típico, las actividades de los requisitos de software
evolucionan con el tiempo de estimulación a la gestión del cambio.
7.2 Gestión del Cambio.
La gestión del cambio es fundamental para la gestión de requisitos. Este tema describe el
papel de la gestión del cambio, los procedimientos que deben estar en el lugar y el
análisis que debe aplicarse a los cambios propuestos.
7.3 Atributos de los Requisitos.
Los requisitos deben consistir solo de una especificación de lo que se necesita, sino
también de información auxiliar, que ayuda a administrar e interpretar los requisitos. Esto
debe incluir las diversas dimensiones de la clasificación de los requisitos y el método de
verificación o aceptación relevante. También puede incluir información adicional, como
una justificación sumaria para cada requisito, la fuente de cada requisito y un historial de
cambios. El atributo más importante, es un identificador que permite a los requisitos
identificarse única e inequívocamente.
7.4 Requisitos de Rastreo.
Los requisitos de seguimiento se refieren a recuperar la fuente de los requisitos y predecir
los efectos de este. Un trazado es fundamental para realizar un análisis de impacto
cuando los requerimientos cambian. Un requisito debe ser trazable al revés de los

19. requerimientos y las partes interesadas que lo motivaron. Por el contrario, un requisito
debe ser trazable para que remita a las entidades de diseño que satisfacen.
7.5 Requisitos de Medición.
Como una cuestión practica, es típicamente útil tener algún concepto del “volumen” de los
requisitos para un producto de software en particular. Este número es útil para evaluar el
“tamaño” de un cambio en los requisitos, al estimar el costo de una tarea de
mantenimiento o desarrollo, o simplemente para el uso como denominador en otras
medidas. La medida del tamaño funcional (MTF) es una técnica para evaluar el tamaño de
un cuerpo de requerimientos funcionales.
8. Requisitos de las herramientas del software.
Las herramientas para tratar con requisitos de software en términos generales se dividen
en dos categorías: herramientas de modelado y herramientas para la gestión de
requisitos.
Las herramientas para la gestión de requisitos suelen apoyar una gama de actividades,
incluyendo documentación, seguimiento y gestión del cambio y han tenido un impacto
significativo en la práctica. De hecho, gestión de cambio y seguimiento son realmente
factibles si son compatibles con una herramienta. Puesto que es fundamental para la
práctica de los requisitos una buena gerencia del requisito, muchas organizaciones han
invertido en herramientas de gestión de requisitos, aunque muchos más gestionan sus
requerimientos y generalmente de maneras menos satisfactorias.