1 CAPITULO 2

2 REQUERIMIENTOS DE SOFTWARE
3
4
5 ACRÓNIMOS 51 recursos y los apremios bajo los cuales el proceso
6 52 funciona y los cuales actúan para configurarlo.
DAG Grafo Acíclico Dirigido 53
complejo 54 Una descomposición alternativa podía utilizar una
FSM Medida Funcional del Tamaño 55 estructura basada en producto (requisitos del sistema,
INCOSE Consejo Internacional sobre la 56 requisitos del software, prototipos, casos de uso, y
Ingeniería de Sistemas 57 así sucesivamente). Las interrupciones basadas en
SADT Análisis Estructurados y Técnicas 58 procesos reflejan el hecho de que el proceso de los
de Diseño 59 requisitos, si es acertado, se debe considerar como
7 60 proceso que implica actividades complejas,
8 61 firmemente unidas (ambas secuencial y
9 INTRODUCCIÓN 62 concurrentemente), más que una única actividad
10 63 discreta realizada al principio de un proyecto de
11 El área del conocimiento de los requisitos del 64 desarrollo de software.
12 software (KA) se refiere al análisis, a la 65
13 especificación, y a la validación de los requisitos del 66 El KA de los requisitos del software se relaciona de
14 software. Está extensamente reconocido dentro de la 67 cerca con el Diseño del software, pruebas,
15 industria del software que los proyectos de la 68 mantenimiento del software, gerencia de la
16 ingeniería de software son críticamente vulnerables 69 configuración del software, tecnología de dotación
17 cuando estas actividades se realizan mal. 70 lógica, proceso de la tecnología de dotación lógica, y
18 71 KAs de Calidad de software.
19 Los requisitos del software expresan las necesidades 72
20 y los apremios colocados en un producto de software 73
21 que contribuye a la solución de un cierto problema 74 INTERRUPCIÓN DE LOS ASUNTOS PARA LOS
22 del mundo real. [Kot00] El término “ingeniería de 75 REQUISITOS DEL SOFTWARE
23 requisitos” es ampliamente utilizado en el campo 76
24 para denotar la dirección sistemática de requisitos. 77 1. Fundamentos de los requisitos del software
25 Aunque por razones de consistencia, este término no 78
26 será utilizado en la guía, pues se ha decidido que el 79 1.1. Definición de un requisito del software
27 uso del término “ingeniería” para las actividades con 80
28 excepción de la tecnología de dotación lógica debe 81 Básicamente, un requisito del software es una
29 ser evitado en esta edición de la guía. 82 característica que se debe exhibir para solucionar un
30 83 cierto problema en el del mundo real. La guía se
31 Por la misma razón, tampoco se utilizará “ingeniero 84 refiere a requisitos de “software” porque se refiere a
32 de los requisitos,” un término que aparece en algo de 85 los problemas que se tratarán por el software. Por lo
33 la literatura. En su lugar se utilizará el término 86 tanto, un requisito del software es una característica
34 “Ingeniero de Software” o, en algunos casos 87 que se debe exhibir por el software desarrollado o
35 específicos, “especialista de los requisitos”, el último 88 adaptado para solucionar un problema particular. El
36 donde el papel en la pregunta es realizado 89 problema puede ser automatizar la parte de una tarea
37 generalmente por un individuo con excepción de una 90 de alguien que utilizará el software, para apoyar los
38 Ingeniería de Software. Esto no implica, sin embargo, 91 procesos del negocio de la organización que ha
39 que una Ingeniería de Software no podría realizar la 92 comisionado el software, a corregir los defectos del
40 función. 93 software existente, al control de dispositivos, y
41 94 muchos más. El funcionamiento de los usuarios, los
42 La interrupción de KA es ampliamente compatible 95 procesos del negocio, y los dispositivos es
43 con secciones de IEEE 12207 que se refieren a 96 típicamente complejo. Por extensión, por lo tanto, los
44 actividades de requisitos. (IEEE12207.1-96) 97 requisitos de software son típicamente una
45 98 combinación compleja de requisitos de diversa gente
46 Un riesgo inherente en la interrupción propuesta es 99 en diversos niveles de una organización y del
47 que un proceso en cascada puede ser deducido. Para 100 ambiente en el cual el software funcionará.
48 evitar esto, los procesos de requisitos de la subzona 2, 101
49 se diseñan para proporcionar una descripción de alto 102 Una característica esencial de todos los requisitos del
50 nivel del proceso de los requisitos precisando los 103 software es que sean comprobables. Puede ser difícil
104 o costoso verificar ciertos requisitos del software. Por
 1 ejemplo, la verificación del requisito del rendimiento 23 parámetros del producto son requisitos en software
2 de procesamiento en el centro de la llamada puede 24 para ser convertido (por ejemplo, “El software
3 hacer necesario el desarrollo del software de la 25 verificará que un estudiante resuelva todos los
4 simulación. Los requisitos del software y el personal 26 requisitos previos antes de que él o ella se coloque
5 de la calidad del software deben asegurarse de que 27 para un curso.”).
6 los requisitos se puedan verificar dentro de los 28 Un parámetro de proceso es esencialmente un
7 apremios disponibles del recurso. 29 constreñimiento en el desarrollo del software (por
8 30 ejemplo, “el software será escrito en el Ada.”). Éstos
9 Los requisitos tienen otras cualidades además de las 31 se conocen a veces como requisitos de proceso.
10 características del comportamiento que expresan. 32
11 Ejemplos comunes incluyen una tasa de prioridad 33 Algunos requisitos del software generan requisitos de
12 para permitir compensaciones frente a recursos 34 proceso implícitos. La opción de la técnica de la
13 finitos y un valor del estado para permitir que el 35 verificación es un ejemplo. Otro puede ser el uso de
14 progreso del proyecto sea supervisado. Típicamente, 36 técnicas rigurosas de análisis (tales como métodos
15 los requisitos de software se identifican únicamente 37 formales de la especificación) para reducir las averías
16 de modo que puedan estar sujetos al control de 38 que pueden conducir a una inadecuada confiabilidad.
17 configuración del software y manejados sobre el 39 Los requisitos de proceso pueden también ser
18 ciclo vital entero del software. [Kot00; Pfl01; Som05; 40 impuestos directamente por la organización del
19 Tha97] 41 desarrollo, su cliente, o terceros tales como un
20 1.2. Producto y requisitos del proceso 42 regulador de seguridad [Kot00; Som97].
21 Se puede dibujar una distinción entre los parámetros
22 del producto y los parámetros del proceso. Los
43

44
45 Figura 1: Descomposición de materias para la KA Requisitos del Software
46
47
48 1.3. Requisitos funcionales y no funcionales 51 un formato de texto o modular una señal. Se conocen
49 Los requisitos funcionales describen las funciones 52 también como capacidades.
50 que el software va a ejecutar; por ejemplo, ajustarse a 53
 1 Los requisitos no funcionales son los que actúan para
2 obligar la solución. Los requisitos no funcionales se
3 conocen a veces como apremios o requisitos de
4 calidad. Pueden ser clasificados más a fondo según si
5 son requisitos de funcionamiento, requisitos de
6 capacidad de mantenimiento, requisitos de seguridad,
7 requisitos de confiabilidad, o uno de muchos otros
8 tipos de requisitos del software. Estos asuntos
9 también se discuten en KA de la calidad del software.
10 [Kot00; Som97]
 1 1.4. Características inesperadas 61
2 Algunos requisitos representan características 62 2. Proceso de los requisitos
3 inesperadas del software- esto es, los requisitos que 63 Esta sección introduce el proceso de los requisitos del
4 no pueden ser tratados por un solo componente, pero 64 software, orientando las cinco subzonas restantes y
5 que su satisfacción va a depender de cómo todos los 65 demostrando cómo el proceso de los requisitos encaja
6 componentes de software ínter operan. El requisito 66 con el proceso de ingeniería del software. [Dav93;
7 del rendimiento de procesamiento para un centro de 67 Som05]
8 llamadas, por ejemplo, dependería de cómo el 68 2.1. Modelos de proceso
9 sistema de teléfono, el sistema de información, y los 69 El objetivo de este asunto es proporcionar una
10 operadores obraron recíprocamente bajo condiciones 70 comprensión de que el proceso de los requisitos
11 de funcionamiento reales. Las características 71
12 inesperadas son crucialmente dependientes en la 72 ♦ No es una actividad anticipada discreta del ciclo
13 arquitectura del sistema. [Som05] 73 vital del software, sino un proceso iniciado en
14 74 principio de un proyecto y a continuación
15 1.5. Requisitos cuantificables 75 refinado a través del ciclo vital
16 Los requisitos del software se deben indicar tan clara 76
17 e inequívocamente como sea posible, y 77 ♦ Identifica los requisitos del software como
18 cuantitativamente. Es importante evitar requisitos 78 elementos de configuración, y los maneja usando
19 vagos e inverificables que dependen para su 79 las mismas prácticas de gerencia de la
20 interpretación del juicio subjetivo (“el software será 80 configuración del software como otros
21 confiable”; “el software será de uso fácil”). Esto es 81 productos de los procesos del ciclo vital del
22 particularmente importante para los requisitos no 82 software
23 funcionales. Dos ejemplos de requisitos 83
24 cuantificados son los siguientes: el software para un 84 ♦ Necesita ser adaptado a la organización y al
25 centro de llamadas debe aumentar el rendimiento del 85 contexto del proyecto
26 procesamiento del centro un 20%; y un sistema 86
27 tendrá una probabilidad de generar un error fatal 87 Particularmente, el asunto se refiere a cómo las
28 durante cualquier hora de operación menos de 1 * 88 actividades de análisis, especificación, y la
29 10−8. El requisito de rendimiento de procesamiento 89 validación se configuran para diversos tipos de
30 está a un alto nivel y necesitará ser derivado en un 90 proyectos y apremios. El asunto también incluye las
31 número de requisitos detallados. El requisito de la 91 actividades que proporcionan la entrada en el proceso
32 confiabilidad determinará firmemente la arquitectura 92 de los requisitos, por ejemplo estudios de la
33 del sistema. [Dav93; Som05] 93 comercialización y de viabilidad. [Kot00; Rob99;
34 94 Som97; Som05]
35 1.6. Requisitos del sistema y requisitos del 95
36 software 96 2.2. Agentes de proceso
37 En este asunto, el sistema significa “una combinación 97 Este asunto introduce los papeles de la gente que
38 recíproca de los elementos para lograr un objetivo 98 participa en el proceso de los requisitos. Este proceso
39 definido. Éstos incluyen el hardware, software, 99 es fundamental interdisciplinario, y el especialista de
40 soporte lógico inalterable, gente, información, 100 los requisitos necesita mediar entre el dominio del
41 técnicas, instalaciones, servicios, y otros elementos 101 tenedor de apuestas y el de la tecnología de dotación
42 de apoyo,” según lo definido por el consejo 102 lógica. Hay mucha gente implicada además del
43 internacional sobre la ingeniería de sistemas 103 especialista de los requisitos, cada uno de ellos tiene
44 (INCOSE00). 104 una función en el software. Los tenedores de apuestas
45 105 variarán según los proyectos, pero incluyen siempre
46 Los requisitos del sistema son los requisitos para el 106 usuarios/operadores y clientes (quiénes no necesitan
47 sistema en su totalidad. En un sistema que contiene 107 ser iguales). [Gog93]
48 componentes de software, los requisitos del software 108
49 se derivan de los requisitos del sistema. 109 Los ejemplos típicos de los tenedores de apuestas del
50 110 software incluyen (pero no restringen)
51 La literatura sobre requisitos llama a veces a los 111
52 requisitos del sistema “exigencias del consumidor.” 112 ♦ Usuarios: Este grupo abarca a los que
53 La guía define “exigencias del consumidor” de una 113 utilizan el software. Es a menudo un grupo
54 manera restricta como requisitos de los clientes o de 114 heterogéneo que abarca a gente con diversos
55 los usuarios finales del sistema. Los requisitos del 115 papeles y requisitos.
56 sistema, por el contrario, abarcan los requisitos del 116 ♦ Clientes: Este grupo abarca a los que han
57 usuario, requisitos de otros tenedores de apuestas (por 117 comisionado el software o quién representa
58 ejemplo autoridades reguladoras), y requisitos sin un 118 el blanco de mercado del software.
59 origen identificable. 119 ♦ Analistas de mercado: Un producto del
60 120 mass-market no tendrá un cliente que
 1 comisiona, de modo que la gente de 61 ♦ Cobertura de proceso de los requisitos
2 comercialización a menudo necesita 62 mediante estándares y modelos de la mejora
3 establecer lo que el mercado necesita y 63 ♦ Medidas de proceso de los requisitos y
4 actuar como clientes. 64 benchmarking
5 ♦ Reguladores: Muchos dominios de 65 ♦ Plan de mejora y puesta en práctica [Kot00
6 aplicación como por ejemplo el transporte 66 de la mejora del ; Som97; You01]
7 público o la banca son regulados. El 67
8 software en estos dominios debe 68 3. Captura de los requisitos
9 conformarse con los requisitos de las 69 [Dav93; Gog93; Lou95; Pfl01]
10 autoridades reguladoras. 70
11 ♦ Ingenieros de software: Estos individuos 71 La captura de los requisitos se refiere a de donde
12 tienen un interés legítimo en beneficiarse del 72 vienen los requisitos del software y cómo el ingeniero
13 desarrollo del software, por ejemplo, 73 de software puede recogerlos. Es la primera etapa en
14 reutilizando componentes en otros 74 la construcción de una comprensión del problema que
15 productos. Si, en este escenario, un cliente 75 el software requiere solucionar. Es fundamental una
16 de un producto particular tiene requisitos 76 actividad humana, y es donde identifican a los
17 específicos que comprometen el potencial 77 stakeholders y las relaciones se establecen entre el
18 para la reutilización de componentes, los 78 equipo del desarrollo y el cliente. También se conoce
19 ingenieros de software deben pesar 79 como “descubrimiento de los requisitos,” y
20 cuidadosamente sus propios intereses contra 80 “adquisición de los requisitos.”
21 los del cliente. 81
22 82 Uno de los aspectos fundamentales de la buena
23 No será posible satisfacer perfectamente los 83 ingeniería de software es que haya buena
24 requisitos de cada stakeholder, y es el trabajo de los 84 comunicación entre los usuarios del software y los
25 ingenieros de software negociar las compensaciones 85 ingenieros. Antes de que comience el desarrollo, los
26 que son aceptables a los stakeholder principales y 86 especialistas de requisitos pueden formar el conducto
27 dentro de presupuestario, técnico, regulador, y otros 87 para esta comunicación. Deben mediar entre el
28 apremios. Un requisito previo para esto es que 88 dominio de los usuarios del software (y otros
29 identifiquen a todos los stakeholder, la naturaleza de 89 stakeholders) y el mundo técnico del ingeniero de
30 su “interés” analizada, y sus requisitos sacados. 90 software.
31 [Dav93; Kot00; Rob99; Som97; You01]
32
33 2.3. Ayuda y gerencia de proceso
34 Este asunto introduce los recursos de la gerencia de
35 proyecto requeridos y consumidos por el proceso de
36 los requisitos. Él establece el contexto para la
37 primera subzona (definición de la iniciación y del
38 alcance) de la tecnología de dotación lógica KA de la
39 gerencia. Su propósito principal es hacer el
40 acoplamiento entre las actividades de proceso
41 identificadas en 2.1 y los temas de coste, recursos
42 humanos, entrenamiento, y herramientas. [Rob99;
43 Som97; You01]
44
45 2.4. Calidad y mejora de proceso
46 Este asunto se refiere al gravamen de la calidad y de
47 la mejora del proceso de los requisitos. Su propósito
48 es acentuar el papel dominante que los requisitos
49 procesan en términos de coste y puntualidad de un
50 producto de software, y de la satisfacción del cliente
51 con ello [Som97]. Ayudará a orientar el proceso de
52 los requisitos con estándares de calidad y modelos de
53 mejora de proceso para el software y los sistemas. El
54 proceso de calidad y la mejora se relacionan de cerca
55 con la calidad del software y la tecnología de
56 dotación lógica KA. De interés particular están las
57 aplicaciones de calidad del software, sus cualidades y
58 medida, y la definición de proceso de software. Este
59 punto abarca
60
 1 61 ingenieros de software necesitan ser
2 3.1. Fuentes de los requisitos 62 sensibles a éstos, puesto que, el nuevo
3 [Dav93; Gog93; Pfl01] 63 software no debe forzar generalmente
4 64 cambios imprevistos en el proceso del
5 Los requisitos tienen muchas fuentes en software 65 negocio.
6 típico, y es esencial que todas las fuentes potenciales 66 3.2. Técnicas de Captura de requisitos
7 estén identificadas y evaluadas para su impacto en él. 67 [Dav93; Kot00; Lou95; Pfl01]
8 Este asunto se diseña para promover el conocimiento 68
9 de las varias fuentes de los requisitos del software y 69 Una vez que se hayan identificado las fuentes de los
10 de los armazones para manejarlos. Los puntos 70 requisitos, ingenieros de software pueden comenzar a
11 principales cubiertos son 71 sacar requisitos de ellos. Este asunto se concentra en
12 72 las técnicas para conseguir que los stakeholders
13 ♦ Metas: El término meta (a veces llamada 73 articulen sus requisitos. Es un área muy difícil y
14 “preocupación de negocio” o “factor crítico 74 ingenieros de software necesitan sensibilizarse al
15 del éxito”) se refiere a los objetivos totales, 75 hecho que (por ejemplo) los usuarios pueden tener
16 de alto nivel del software. Las metas 76 dificultad para describir sus tareas, puede dejar la
17 proporcionan la motivación para el software, 77 información importante sin especificar, o pueden
18 pero a menudo son formuladas vagamente. 78 estar poco dispuestos o cooperar. Es particularmente
19 Es necesidad que los ingenieros de software 79 importante entender que la captura no es una
20 presten atención particular a determinar el 80 actividad pasiva, y que, ingenieros de software tienen
21 valor (concerniente a prioridad) y coste de 81 que trabajar difícilmente para sacar la información
22 metas. Un estudio de viabilidad es una 82 adecuada. Existe un número de técnicas para hacer
23 manera relativamente barata de hacer esto. 83 esto, las principales son [Gog93]
24 [Lou95]. 84
25 ♦ Conocimiento del dominio: Los ingenieros 85 ♦ Entrevistas, medios “tradicionales” de sacar
26 de software necesitan adquirir, o tener 86 requisitos. Es importante entender las
27 disponible, conocimiento sobre el uso del 87 ventajas y limitaciones de las entrevistas y
28 dominio. Esto permite deducir el 88 cómo deben ser conducidas.
29 conocimiento que los stakeholders no 89 ♦ Escenarios, valiosos medios para
30 articulan, determinar las compensaciones 90 proporcionar contexto a las exigencias del
31 que serán necesarias en requisitos que están 91 consumidor. Proporcionan un marco para
32 en conflicto, y, a veces, para actuar como 92 preguntas sobre tareas del usuario
33 campeón del “usuario”. 93 permitiendo preguntas “y si” y “cómo se
34 ♦ Stakeholders (véase a agentes de proceso del 94 hace esto”. El tipo más común de escenario
35 asunto 2.2). Mucho software se ha probado 95 es el caso del uso.
36 insatisfactorio porque había tensionado los 96 ♦ Prototipos, una herramienta valiosa para
37 requisitos de un grupo de stakeholders a 97 clarificar requisitos confusos. Pueden actuar
38 expensas de los de otros. Por lo tanto, se 98 de una manera similar a los escenarios,
39 entrega el software que es difícil de utilizar 99 proveyendo a los usuarios un contexto
40 o que derriba las estructuras culturales o 100 dentro del cuál pueden entender mejor qué
41 políticas de la organización del cliente. Los 101 información necesitan proporcionar. Hay
42 ingenieros de software necesitan identificar, 102 una amplia gama de técnicas de
43 representar, y manejar “puntos de vista” de 103 prototipado, maquetas de versiones de
44 muchos diversos tipos de tenedores de 104 pruebas beta de los diseños de la pantalla del
45 apuestas. [Kot00] 105 software , y un traslado fuerte de su uso para
46 ♦ El entorno operacional. Los requisitos serán 106 captura de los requisitos y el uso de
47 derivados del ambiente en el cual el 107 prototipos para la validación de los
48 software será ejecutado. Éstos pueden ser, 108 requisitos (véase el asunto 6.2 Prototipado).
49 por ejemplo, el medir el tiempo en tiempo 109 ♦ Reuniones. El propósito de éstas es intentar
50 real del software o de la interoperabilidad en 110 alcanzar un efecto aditivo por el que un
51 un ambiente de la oficina. Éstos deben ser 111 grupo de gente puede obtener más
52 buscados activamente, porque pueden 112 penetración en los requisitos del software
53 afectar grandemente a la viabilidad y el 113 que trabajando individualmente. Ellos
54 coste del software, y restringen las opciones 114 pueden inspirarse y refinar las ideas que
55 de diseño. [Tha97] 115 pueden ser difíciles de traer a la superficie
56 ♦ El entorno de la organización. El software se 116 usando entrevistas. Otra ventaja es que
57 requiere a menudo para apoyar un proceso 117 dejan a los stakeholders reconocer donde
58 del negocio, la selección del cual se puede 118 hay requisitos en conflicto. Cuando se aplica
59 condicionar por la estructura, cultura, y 119 bien, esta técnica puede resultar en un rico y
60 política interna de la organización. Los 120 constante sistema de requisitos que
 1 difícilmente sería realizable de otro modo. 61 ♦ Si el requisito es funcional o no funcional (véase
2 Sin embargo, las reuniones necesitan ser 62 el asunto 1.3 funcional y requisitos no
3 dirigidas cuidadosamente (por lo tanto es 63 funcionales).
4 necesario un facilitador) para evitar que una 64 ♦ Si el requisito está derivado de uno o más
5 situación ocurra donde las capacidades 65 requisitos de alto nivel o una propiedad
6 críticas del equipo son erosionadas por 66 emergente (véase las características inesperadas
7 lealtad del grupo, o los requisitos que 67 del asunto 1.4) o está impuesto directamente ante
8 reflejan las preocupaciones de algunos 68 el software por un tenedor de apuestas u otra
9 favorecen la gente abierta (y quizás mayor) 69 fuente.
10 en detrimento de otros. 70 ♦ Si el requisito está en el producto o proceso. Los
11 ♦ Observación. La importancia del contexto 71 requisitos en el proceso pueden obligarnos a la
12 del software dentro del ambiente de 72 opción del contratista, a adaptar el proceso de la
13 organización ha conducido a la adaptación 73 ingeniería del software o los estándares que se
14 de las técnicas de observación para captura 74 adherirán.
15 de los requisitos. Los ingenieros de software 75 ♦ La prioridad del requisito. Generalmente cuanta
16 aprenden sobre las tareas del usuario 76 más alta es la prioridad, más esencial es el
17 sumergiéndose en la observación de cómo 77 requisito para satisfacer las metas finales del
18 los usuarios obran recíprocamente con su 78 software. A menudo clasificado en una escala de
19 software. Estas técnicas son relativamente 79 punto fijo tal como obligatorio, altamente
20 costosas, pero son instructivas porque 80 deseable, deseable u opcional, la prioridad a
21 ilustran que muchas tareas del usuario y 81 menudo tiene que ser equilibrada con el coste de
22 procesos del negocio son demasiado sutiles 82 desarrollo e implementación.
23 y complejos para que sus agentes los 83 ♦ El alcance del requisito. El alcance se refiere al
24 describan fácilmente. 84 grado al cual un requisito afecta el software y
25 85 componentes software. Algunos requisitos,
26 4. Análisis de requisitos 86 particularmente los no funcionales, tienen un
27 [Som05] 87 alcance global que no puede ser asignado a un
28 88 componente discreto. Por lo tanto, el requisito
29 Este asunto se refiere al proceso de analizar requisitos 89 con alcance global puede afectar fuertemente a la
30 para 90 arquitectura del software y el diseño de muchos
31 91 componentes, mientras que uno puede con un
32 ♦ Detectar y resolver los conflictos entre los 92 alcance estrecho ofrecer un número de opciones
33 requisitos 93 del diseño y no afectar demasiado a la
34 ♦ Descubrir los límites del software y cómo debe 94 satisfacción de otros requisitos.
35 obrar recíprocamente con su ambiente 95 ♦ Volatilidad/estabilidad. Algunos requisitos
36 ♦ Elaborar los requisitos del sistema para derivar 96 cambiarán durante el ciclo de vida del software,
37 requisitos software 97 y se igualarán durante el proceso de desarrollo.
38 98 Es útil hacer estimaciones de la probabilidad de
39 La vista tradicional del análisis de requisitos ha sido 99 que se puedan hacer cambios. Por ejemplo, en
40 que esté reducida a modelado conceptual utilizando 100 actividades bancarias, los requisitos para las
41 uno de varios métodos de análisis tales como Análisis 101 funciones para calcular y para acreditar los
42 Estructurados y Técnicas de Diseño (SADT). 102 intereses en las cuentas son probablemente más
43 Mientras que el modelado conceptual es importante, 103 estables que un requisito para mantener un tipo
44 nosotros incluimos la clasificación de requisitos para 104 particular de cuenta exenta de impuestos. Lo
45 ayudar a informar a compensaciones entre los 105 anterior refleja una característica fundamental
46 requisitos (clasificación de los requisitos) y el 106 del dominio de las actividades bancarias (esas
47 proceso de establecer estas compensaciones 107 cuentas pueden ganar intereses), mientras que el
48 (negociación de los requisitos). [Dav93] 108 último se puede dejar obsoleto por un cambio de
49 109 gobierno. Señalar requisitos potencialmente
50 El cuidado se debe tomar para describir requisitos 110 volátiles puede ayudar al ingeniero del software
51 con exactitud, suficientemente como para permitir 111 a establecer un diseño que sea más tolerante al
52 que los requisitos sean validados, su implementación 112 cambio.
53 sea verificada, y sus costes estimados. 113
54 114 Otras clasificaciones pueden ser apropiadas,
55 4.1 Clasificación de los requisitos 115 dependiendo de la práctica normal y del uso que se le
56 [Dav93; Kot00; Som05] 116 dé.
57 117
58 Los requisitos se pueden clasificar en un número de 118 Hay un desfase fuerte entre la clasificación de los
59 dimensiones. Los ejemplos incluyen: 119 requisitos y las cualidades de los requisitos (véase las
60 120 cualidades de los requisitos del punto 7.3).
 1 61 conocimiento. Ésta es actualmente la situación con el
2 4.2. El modelo conceptual 62 UML (Lenguaje de Modelado Unificado). (UML04)
3 [Dav93; Kot00; Som05] 63
4 64 El modelado formal usando notaciones basadas en
5 El desarrollo de modelos de un problema del mundo 65 matemática discreta, y que son detectables al
6 real es clave para el análisis de requisitos del 66 razonamiento lógico, han tenido impacto en algunos
7 software. Su propósito es ayudar a entender el 67 dominios especializados. Éstos puede ser impuesto
8 problema, más que iniciar el diseño de la solución. 68 por los clientes o los estándares y puede ofrecer
9 Por lo tanto, modelos conceptuales abarcan modelos 69 ventajas que obligan al análisis de ciertas funciones o
10 de entidades del dominio del problema, configurados 70 componentes críticos.
11 para reflejar sus relaciones y dependencias con el 71
12 mundo real. 72 Este asunto no busca “enseñar” un estilo o una
13 73 notación de modelado particular sino proporcionar
14 Varias clases de modelos pueden ser desarrollados. 74 algo a la dirección con el propósito de modelar.
15 Éstos incluyen datos y controlan flujos, modelos de 75
16 estado, rastros de evento, interacciones de usuario, 76 Dos estándares proporcionan las notaciones que
17 modelos de objeto, modelos de datos y muchos otros. 77 pueden ser útiles en desarrollo conceptual realizando
18 Los factores que influencian la opción del modelo 78 modelado-IEEE conceptual Std 1320.1, IDEF0 para
19 incluyen 79 modelado funcional; e IEEE Std 1320.2, IDEF1X97
20 80 (IDEFObject) para modelado de la información.
21 ♦ La naturaleza del problema. Algunos tipos de 81
22 software exigen que ciertos aspectos estén 82 4.3. Asignación arquitectónica del diseño y de
23 analizados rigurosamente. Por ejemplo, controlar 83 los requisitos
24 el flujo y los modelos de estado son 84 [Dav93; Som05]
25 probablemente más importantes para el software 85
26 en tiempo real que para el software de gerencia 86 En un cierto punto, la arquitectura de la solución debe
27 de información, mientras que es generalmente lo 87 ser derivada. El diseño arquitectónico es el punto en
28 contrario para los modelos de datos. 88 el cual el proceso de los requisitos se junta con
29 ♦ La maestría del ingeniero del software. Es a 89 software o diseño de sistemas e ilustra cómo de
30 menudo más productivo adoptar una notación 90 imposible es desemparejar ambas tareas. [Som01]
31 que modele o método con el cual el ingeniero del 91 Este asunto está de cerca relacionado con el capítulo
32 software tiene una experiencia. 92 de la estructura y de la arquitectura del software en
33 ♦ Los requisitos de proceso del cliente. Los 93 KA del diseño del software. En muchos casos, el
34 clientes pueden imponer su notación o método 94 ingeniero del software actúa como arquitecto del
35 favorecido, o prohibir cualquiera que le sea 95 software porque el proceso de analizar y de elaborar
36 desconocido. Este factor puede estar en conflicto 96 los requisitos exige que los componentes que serán
37 con el factor anterior. 97 responsables de satisfacer los requisitos estén
38 ♦ La disponibilidad de métodos y de herramientas. 98 identificados. Esto es localización de requisitos-la
39 Notaciones o métodos que son mal apoyados por 99 asignación, a los componentes, de la responsabilidad
40 el entrenamiento y las herramientas pueden no 100 de satisfacer requisitos.
41 alcanzar la aceptación esperada aunque se 101
42 satisfagan tipos particulares de problemas. 102 La asignación es importante para permitir análisis
43 103 detallado de requisitos. Por lo tanto, por ejemplo,
44 Observar que, en casi todos los casos, es útil 104 una vez un sistema de requisitos se han asignado a un
45 comenzar construyendo un modelo del contexto del 105 componente, los requisitos individuales se pueden
46 software. El contexto del software proporciona una 106 analizar más a fondo para descubrir otros requisitos
47 conexión entre el software previsto y su ambiente 107 de cómo el componente necesita obrar
48 externo. Esto es crucial para entender el contexto del 108 recíprocamente con otros componentes para
49 software en su ambiente operacional e identificar sus 109 satisfacer los requisitos asignados. En proyectos
50 interfaces con el ambiente. 110 grandes, la asignación estimula un nuevo análisis
51 111 para cada subsistema. Como ejemplo, requisitos para
52 La aplicación de modelar se junta firmemente con la 112 el funcionamiento de los frenos de un coche
53 de los métodos. Para los propósitos prácticos, un 113 (distancia que frena, seguridad en condiciones que
54 método es una notación (o sistema de notaciones) 114 conducen, suavidad del uso, la presión del pedal
55 apoyado por un proceso que dirige el uso de las 115 requerida, y así sucesivamente) se puede asignar un
56 notaciones. Hay escasa evidencia empírica para 116 hardware que frena (montajes mecánicos e
57 apoyar las demandas de superioridad de una notación 117 hidráulicos) y un sistema de frenos antibloqueo
58 sobre otra. Sin embargo, la extensa aceptación de un 118 (ABS). Solamente cuando un requisito para un
59 método o de una notación particular puede conducir a 119 sistema de frenos antibloqueo ha sido identificado, y
60 nivel industrial al beneficio de habilidades y de 120 los requisitos asignados a él, pueden usarse las
 1 capacidades del ABS, el hardware de frenado 61 que implican componentes no-software, se elaboran
2 identificado, y las características indefinidas (tales 62 tres tipos de documentos: definición de sistema,
3 como el peso del coche) para identificar los requisitos 63 sistema requisitos, y requisitos del software. Para
4 detallados del software del ABS. 64 sistemas simples, solamente el tercero de éstos es
5 65 requerido. Los tres documentos se describen aquí,
6 El diseño arquitectónico se identifica de cerca con el 66 entendiendo que combinados pueden ser apropiados.
7 modelado conceptual. El mapeado de las entidades 67 Una descripción de la ingeniería de sistemas se puede
8 del dominio del mundo real para componentes de 68 encontrar en el Capítulo 12, disciplinas relacionadas
9 software no siempre tiene un diseño obvio, así que 69 de la tecnología de dotación lógica.
10 arquitectónicamente se identifica como a asunto 70
11 separado. Los requisitos de notaciones y los métodos 71 5.1. El documento de la definición de sistema
12 son ampliamente iguales para modelado conceptual y 72 Este documento (conocido a veces como documento
13 diseño arquitectónico. 73 de exigencias del o concepto de operaciones) registra
14 74 el sistema requisitos. Define los requisitos del
15 IEEE Std 1471-2000, práctica recomendada para la 75 sistema de alto nivel desde la perspectiva del
16 descripción arquitectónica de sistemas orientados al 76 dominio. Su número total de lectores incluye los
17 software, sugiere un acercamiento del múltiple punto 77 representantes de los usuarios del sistema/de los
18 de vista para describir la arquitectura de sistemas y de 78 clientes (la comercialización puede desempeñar estos
19 sus artículos del software. 79 papeles del mercado software), así que su contenido
20 (IEEE1471-00) 80 debe estar en términos de dominio. El documento
21 81 enumera los requisitos del sistema junto con
22 4.4. Negociación de los requisitos 82 información de fondo sobre los objetivos totales para
23 Otro término comúnmente utilizado para este tema es 83 el sistema, su ambiente de misión y una declaración
24 “resolución del conflicto.” Esto se refiere a 84 de apremios, asunciones, y requisitos no funcionales.
25 problemas de resolución de los requisitos donde los 85 Puede incluir los modelos conceptuales diseñados
26 conflictos ocurren entre dos stakeholders que 86 para ilustrar el contexto del sistema, panoramas del
27 requieren características mutuamente incompatibles, 87 uso y las entidades principales del dominio, así como
28 entre los requisitos y los recursos, o en entre 88 datos, la información, y workflows. IEEE Std 1362,
29 requisitos funcionales y no funcionales, por ejemplo. 89 concepto del documento de las operaciones,
30 90 proporciona consejo sobre la preparación y
31 [Kot00, Som97] en la mayoría de los casos, es 91 contenido de tal documento.
32 imprudente para el ingeniero del software tomar una 92 (IEEE1362-98)
33 decisión unilateral, y hace necesario consultar con los 93
34 stakeholders para alcanzar un consenso en una 94 5.2. Especificación de requisitos del sistema
35 compensación apropiada. Es a menudo importante 95 [Dav93; Kot00; Rob99; Tha97]
36 por esas razones contractuales que tales decisiones 96 Desarrolladores de sistemas con los componentes
37 sean detectables de nuevo al cliente. Hemos 97 software y nonsoftware, un avión de pasajeros
38 clasificado esto como asunto del análisis de requisitos 98 moderno, por ejemplo, separa a menudo la
39 del software porque los problemas emergen como 99 descripción de los requisitos del sistema de la
40 resultado el análisis. Sin embargo, un caso fuerte se 100 descripción de los requisitos del software. En esto se
41 puede también hacer para considerar los requisitos 101 especifica la visión, requisitos del sistema, los
42 como asunto de la validación. 102 requisitos software se derivan de los requisitos del
43 103 sistema, y entonces los requisitos para los
44 5. Especificación de requisitos 104 componentes de software se especifican. En sentido
45 105 estricto, la especificación de requisitos del sistema es
46 Para la mayoría de las profesiones de la ingeniería, el 106 una actividad de la ingeniería de sistemas y esta fuera
47 término “especificación” se refiere a la asignación de 107 del alcance de esta guía. IEEE Std 1233 es una guía
48 valores o límites numéricos para metas del diseño del 108 para los requisitos del sistema que se convierten.
49 producto. (Vin90) Los sistemas físicos típicos tienen 109 (IEEE1233-98)
50 un número relativamente pequeño de tales valores. 110
51 Típicamente el software tiene una gran cantidad de 111 5.3. Especificación de requisitos del software
52 requisitos, y el énfasis se comparte entre la ejecución 112 [Kot00; Rob99]
53 de la cuantificación numérica y el manejo de la 113
54 complejidad de la interacción entre el gran número de 114 La especificación de requisitos del software establece
55 requisitos. Así pues, en software el término, 115 la base para el acuerdo entre los clientes y los
56 “especificación de requisitos del software”se refiere 116 contratistas o los proveedores (en proyectos del
57 típicamente a la producción de un documento, o a su 117 mercado, estos papeles se pueden desempeñar por las
58 equivalente electrónico, que puede estar 118 divisiones de comercialización y desarrollo) en los
59 sistemáticamente repasado, evaluado, y aprobado. 119 que hay que hacer el producto de software, así como
60 Para los sistemas complejos, particularmente ésos 120 lo que no se espera que haga. Para los lectores no
 1 técnicos, el documento de la especificación de los 61 6. Validación de los requisitos
2 requisitos es acompañado a menudo por un 62 [Dav93]
3 documento de la definición de los requisitos del 63
4 software. 64 Los documentos de los requisitos pueden estar
5 65 conformes a la validación y procedimientos de
6 La especificación de requisitos del software permite 66 verificación. Los requisitos pueden ser validados para
7 un riguroso gravamen de requisitos antes de que el 67 asegurarse de que el ingeniero del software entiende
8 diseño pueda comenzar y reducir un reajuste final. 68 los requisitos, y es también importante para verificar
9 Debe también proporcionar una base realista para 69 que un documento de requisitos se conforma con la
10 estimar costes, riesgos, y horario del producto. 70 compañía de los estándares, y éste es comprensible,
11 71 constante, y finito. Las notaciones formales ofrecen
12 Las organizaciones pueden también utilizar un 72 la ventaja importante de permitir que las dos
13 documento de especificación de requisitos software 73 características pasadas sean probadas (en un sentido
14 para desarrollar su propia validación y que la 74 estricto, por lo menos). Diversos stakeholders,
15 verificación sea más productiva. 75 incluyendo los representantes del cliente y del
16 76 revelador, deben también repasar los documentos.
17 La especificación de requisitos software proporciona 77 Los documentos de los requisitos son conformes a
18 una base informada para transferir un producto de 78 las mismas prácticas de gerencia de la configuración
19 software a los nuevos usuarios o a las máquinas 79 del software como los otros puntos relevantes de los
20 nuevas. Finalmente, puede proporcionar una base 80 procesos del ciclo de vida del software. (Bry94,
21 para el realce de software. 81 Ros98)
22 82
23 Los requisitos del software se escriben a menudo en 83 Es normal programar explícitamente unos o más
24 lenguaje natural, pero, en la especificación de 84 puntos en el proceso de los requisitos donde están los
25 requisitos del software, ésta se puede suplir por 85 requisitos validados. La puntería es tomar cualquier
26 formal o semi-formal. La selección de notaciones 86 problema antes de que los recursos se destinen a
27 apropiadas permite requisitos y los aspectos 87 tratar los requisitos. La validación de los requisitos se
28 particulares de la arquitectura del software que se 88 refiere al proceso de examinar el documento de los
29 describirá más ajustadamente que en lengua natural. 89 requisitos para asegurarse de que este define el
30 La regla general es que las notaciones deben ser 90 software correctamente (es decir, el software que los
31 utilizadas para que permitan a los requisitos ser 91 usuarios esperan). [Kot00]
32 descritos tan exactamente como sea posible. Esto es 92
33 particularmente crucial para otros tipos seguridad- 93 6.1 Revisiones de los requisitos
34 crítica y casos de software confiable. Sin embargo, la 94 [Kot00; Som05; Tha97]
35 opción de la notación es obligada a menudo por el 95
36 entrenamiento, las habilidades y las preferencias de 96 Quizás los medios más comunes de la validación
37 los autores y de los lectores del documento. 97 están cerca de inspección o revisiones de los
38 98 documentos de los requisitos. Asignan un grupo de
39 Se han desarrollado un número de indicadores de la 99 revisores en un escrito para buscar errores,
40 calidad para relacionar la calidad de la especificación 100 asunciones confundidas, la carencia de la claridad, y
41 de requisitos del software a otras variables del 101 la desviación de la costumbre. La composición del
42 proyecto por ejemplo coste, aceptación, 102 grupo que conduce la revisión es importante (por lo
43 funcionamiento, horario, reproducibilidad, 103 menos un representante del cliente debe ser incluido
44 indicadores de la calidad etc. para el individuo las 104 para un proyecto cliente-conducido, por ejemplo), y
45 declaraciones de la especificación de requisitos del 105 puede ayudar a proporcionar la dirección en qué
46 software incluyen imperativos, directorios, frases 106 buscar bajo listas de comprobación.
47 débiles, opciones, y continuaciones. Indicadores para 107
48 el documento de especificación de requisitos software 108 Las revisiones se pueden constituir en el final del
49 incluye tamaño, legibilidad, especificación, 109 documento de definición del sistema, el documento
50 profundidad, y estructura del texto. 110 de la especificación de sistema, el documento de la
51 [Dav93; Tha97] (Ros98) 111 especificación de requisitos del software,
52 112 especificación de la línea de fondo para un nuevo
53 IEEE tiene un estándar, IEEE Std 830 [IEEE830-98], 113 lanzamiento, o en cualquier otro paso en el proceso.
54 para producción y contenido de la especificación de 114 IEEE Std 1028 proporciona la dirección para
55 los requisitos del software. También, IEEE 1465 115 conducir tales revisiones. (IEEE1028-97) Las
56 (similar a ISO/IEC 12119) es un estándar que trata 116 revisiones son también cubiertas en KA de la calidad
57 requisitos de calidad en paquetes de software. 117 del software, punto 2.3 Revisiones e intervenciones.
58 (IEEE1465-98) 118
59 119 6.2. Prototipado
60 120 [Dav93; Kot00; Som05; Tha97]
 1 61 7. Consideraciones prácticas
2 Prototipar es comúnmente el medio para validar la 62 El primer nivel de la descomposición de los puntos
3 interpretación del ingeniero del software de los 63 presentados en este KA puede parecer que describe
4 requisitos del software, así como para sacar nuevos 64 una secuencia lineal de actividades. Ésta es una vista
5 requisitos. Como con el elicitation, hay una gama de 65 simplificada del proceso.
6 técnicas de prototipado y un número de puntos en el 66 [Dav93]
7 proceso donde la validación del prototipo puede ser 67
8 apropiada. La ventaja de usar prototipos es que 68 Los requisitos procesan palmos de todo el ciclo de
9 pueden hacer más fácil la interpretación de las 69 vida del software. Cambiar la gerencia y el
10 asunciones del ingeniero del software y, donde lo 70 mantenimiento de los requisitos en un estado que
11 necesite, dan la explicación útil de porqué son 71 refleja exactamente el software que se construirá, o se
12 incorrectas. Por ejemplo, el comportamiento 72 ha construido, es clave para el éxito del proceso
13 dinámico de un interfaz utilizador se puede entender 73 ingeniería del software
14 mejor a través de un prototipo animado que a través 74 [Kot00; Lou95]
15 de la descripción textual o de modelos gráficos. Hay 75
16 también desventajas, sin embargo. Éstos incluyen el 76 No toda organización tiene una cultura de
17 peligro de la atención de los usuarios que es distraída 77 documentación y manejo de requisitos. Es frecuente
18 de la base de la funcionalidad subyacente por las 78 en las compañías de start-up dinámicas, conducidas
19 ediciones o los problemas cosméticos de la calidad 79 por una “visión fuerte del producto” y recursos
20 con el prototipo. Por esta razón, algunas personas 80 limitados, para ver la documentación de los requisitos
21 dicen que los prototipos que evitan. Los prototipos 81 como gastos indirectos innecesarios. Más a menudo,
22 pueden ser costosos. Sin embargo, si evitan el 82 sin embargo, según estas compañías crecen, mientras
23 despilfarro de los recursos causados intentando 83 que su base de cliente crece, y como su producto
24 satisfacer requisitos erróneos, su coste puede ser más 84 comienza a desarrollarse, estas descubren que
25 fácilmente justificado. 85 necesitan recuperar los requisitos que las
26 86 características de producto motivadas para determinar
27 6.3. Validación modelo 87 el impacto de cambios propuestos. Por lo tanto, la
28 [Dav93; Kot00; Tha97] 88 documentación de los requisitos y la gerencia del
29 89 cambio son llave al éxito de cualquier proceso de los
30 Es típicamente necesario validar la calidad de los 90 requisitos.
31 modelos desarrollados durante el análisis. Por 91
32 ejemplo, en modelos de objeto, es útil para realizar 92 7.1. Naturaleza iterativa del proceso de los
33 un análisis estático para verificar que las trayectorias 93 requisitos
34 de comunicación existen entre los objetos que, en 94 [Kot00; You01]
35 dominio de los stakeholders, intercambian datos. Si 95
36 las notaciones de especificación formal se utilizan, es 96 Hay presión general en la industria del software para
37 posible utilizar el razonamiento formal para probar 97 ciclos de desarrollo más cortos, y esto está
38 características de la especificación. 98 particularmente pronunciado en sectores del mercado
39 99 altamente competitivos. Por otra parte, la mayoría de
40 6.4. Pruebas de aceptación 100 los proyectos son obligados de cierta manera por su
41 [Dav93] 101 ambiente, y muchas son mejoras, o revisiones, del
42 102 software existente donde está la arquitectura dada. En
43 Una característica esencial de un requisito del 103 la práctica, por lo tanto, es casi siempre impráctico
44 software es que debe ser posible validar que el 104 poner el proceso de los requisitos en ejecución como
45 producto final lo satisface. Los requisitos que no 105 proceso lineal, determinista en el cual los requisitos
46 pueden ser validados son “deseos realmente justos.” 106 del software se saquen de los stakeholders, asignado,
47 Una tarea importante es por lo tanto planear cómo 107 y entregado al equipo de desarrollo del software. Es
48 verificar cada requisito. En la mayoría de los casos, el 108 ciertamente un mito que los requisitos para los
49 diseño de pruebas de aceptación hace esto. 109 proyectos grandes del software siempre están
50 Identificar y diseñar pruebas de aceptación pueden 110 entendidos perfectamente o especificados
51 ser difícil para los requisitos no funcionales (véase el 111 perfectamente. [Som97]
52 asunto los requisitos funcionales y no funcionales de 112
53 1.3). Para ser validados, deben primero ser 113 En su lugar, los requisitos iteran típicamente hacia un
54 analizados al punto donde pueden ser expresados 114 nivel de calidad y detallan que es suficiente permitir
55 cuantitativamente. 115 las decisiones del diseño y de la consecución que se
56 La información adicional se puede encontrar en el 116 harán. En algunos proyectos, esto puede dar lugar a
57 software KA de prueba, conformidad de la prueba en 117 requisitos antes de que todas sus características se
58 el punto 2.2.4. 118 entiendan completamente. Esto arriesga a una
59 119 reanudación costosa si los problemas emergen tarde
60 120 en el proceso de la ingeniería del software. Sin
 1 embargo, los ingenieros del software son obligados 60 atribuyen, sin embargo, un identificador que permite
2 necesariamente por planes de la gerencia de proyecto 61 requisitos identificados inequívocamente.
3 y deben por lo tanto tomar medidas para asegurarse 62
4 de que la “calidad” de los requisitos es tan alta como 63 7.4 El remontar de los requisitos
5 sea posible dado los recursos disponibles. Deben, por 64 [Kot00]
6 ejemplo, hacer explícita cualquier asunción que 65
7 sostengan los requisitos, así como cualesquiera 66 El remontar de los requisitos se refiere a la fuente
8 problemas sabidos. 67 recuperación de requisitos y de predecir los efectos
9 68 de esos requisitos. El trazado es fundamental para el
10 En casi todos los casos, el entendimiento de los 69 análisis de la ejecución del impacto cuando los
11 requisitos continúa desarrollándose mientras que 70 requisitos cambian. Un requisito debe ser detectable
12 procede el diseño y el desarrollo. Esto conduce a 71 al revés a requisitos y los stakeholders que lo
13 menudo a la revisión de requisitos tarde en el ciclo de 72 motivaron (de un requisito del software de nuevo a
14 vida. Quizás el punto más crucial de entender la 73 los requisitos del sistema que ayudan a satisfacer, por
15 ingeniería de requisitos es que una proporción 74 ejemplo). Inversamente, un requisito debe ser
16 significativa de los requisitos cambiará. Esto es a 75 detectable entidades del diseño que lo satisfacen (por
17 veces debido a los errores en el análisis, pero es con 76 ejemplo, de un requisito del sistema en el software
18 frecuencia una consecuencia inevitable del cambio en 77 requisitos que se han elaborado a partir de él, y
19 el “ambiente”: por ejemplo, la funcionalidad del 78 encendido en los módulos del código que lo ponen en
20 cliente o el ambiente del negocio, o el mercado en el 79 ejecución).
21 cual software se va a vender. Cualquiera que sea la 80
22 causa, es importante reconocer la inevitabilidad del 81 Los requisitos que remontan para un proyecto típico
23 cambio para atenuar sus efectos. El cambio tiene que 82 formarán un gráfico acíclico dirigido complejo
24 ser manejado asegurando esos cambios propuestos 83 (DAG) de requisitos.
25 mediante una revisión definida y un análisis del 84
26 proceso de aprobación, y, aplicando los requisitos 85 7.5 Requisitos que miden
27 cuidadosos que remontan, del impacto, y la 86 Como cuestión práctica, es típicamente útil tener
28 configuración del software (véase la configuración 87 cierto concepto del “volumen” de los requisitos para
29 del software KA de la gerencia). Por lo tanto, el 88 un producto de software particular. Este punto es útil
30 proceso de los requisitos no es simplemente una tarea 89 evaluando el “tamaño” de un cambio en requisitos, en
31 anticipada en el desarrollo del software, pero 90 estimar el coste de una tarea del desarrollo o del
32 atraviesa por completo el ciclo de vida del software. 91 mantenimiento, o simplemente para el uso como el
33 En un proyecto típico, las actividades de los 92 denominador en otra medida. La medida funcional
34 requisitos del software se desarrollan en un cierto. 93 del tamaño (FSM) es una técnica para evaluar el
35 94 tamaño de un cuerpo de requisitos funcionales. IEEE
36 7.2. Cambiar a gestión 95 Std 14143.1 define el concepto de FSM.
37 [Kot00] 96 [IEEE14143.1-00] Estándares de ISO/IEC y otras
38 97 fuentes describen métodos particulares del FSM.
39 La gestión del cambio es central en el análisis de 98
40 requisitos. Este asunto describe el papel de la gestión 99 Información adicional sobre la medida del tamaño y
41 del cambio, los procedimientos que necesitan estar 100 los estandares se encuentran en el proceso de la
42 preparados, y el análisis que se debe aplicar a los 101 ingenieria del software.
43 cambios propuestos. Tiene acoplamientos fuertes a la
44 configuración del software KA de la gestión.
45
46 7.3. Cualidades de los requisitos
47 [Kot00]
48
49 Los requisitos deben consistir no sólo una
50 especificación de qué se requiere, sino también de la
51 información ancilar que las ayudas manejan e
52 interpretan los requisitos. Esto debe incluir varias
53 dimensiones de la clasificación del requisito (véase
54 la clasificación de los requisitos del asunto 4.1) y el
55 método de la verificación o el plan de prueba de
56 aceptación. Puede también incluir la información
57 adicional tal como un resumen-análisis razonado para
58 cada requisito, la fuente de cada requisito, y una
59 historia del cambio. Los requisitos más importantes
 1 REFERENCIAS RECOMENDADAS PARA REQUSITOS SW
2
3 [Dav93] A.M. Davis, Software Requirements: Objects,
4 Functions and States, Prentice Hall, 1993.
5 [Gog93] J. Goguen and C. Linde, “Techniques for
6 Requirements Elicitation,” presented at International
7 Symposium on Requirements Engineering, 1993.
8 [IEEE830-98] IEEE Std 830-1998, IEEE Recommended
9 Practice for Software Requirements Specifications,
10 IEEE, 1998.
11 (IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/
12 IEC14143-1:1998, Information Technology—Software
13 Measurement—Functional Size Measurement—Part 1:
14 Definitions of Concepts, IEEE, 2000.
15 [Kot00] G. Kotonya and I. Sommerville, Requirements
16 Engineering: Processes and Techniques, John Wiley &
17 Sons, 2000.
18 [Lou95] P. Loucopulos and V. Karakostas, Systems
19 Requirements Engineering, McGraw-Hill, 1995. [Pfl01]
20 S.L. Pfleeger, “Software Engineering: Theory and
21 Practice,” second ed., Prentice Hall, 2001, Chap. 4.
22 [Rob99] S. Robertson and J. Robertson, Mastering the
23 Requirements Process, Addison-Wesley, 1999.
24 [Som97] I. Sommerville and P. Sawyer, Requirements
25 Engineering: A Good Practice Guide, John Wiley &
26 Sons, 1997, Chap. 1-2.
27 [Som05] I. Sommerville, Software Engineering,
28 seventhed., Addison-Wesley, 2005.
29 [Tha97] R.H. Thayer and M. Dorfman, eds., Software
30 Requirements Engineering, IEEE Computer Society
31 Press, 1997, pp. 176-205, 389-404.
32 [You01] R.R. You, Effective Requirements Practices,
33 Addison-Wesley, 2001.
 1 64 (Dav94) A. Davis and P. Hsia, “Giving Voice to
2 APÉNDICE A. LISTA DE LECTURAS 65 Requirements Engineering: Guest Editors’
3 COMPLEMENTARIAS 66 Introduction,” IEEE Software, vol. 11, iss. 2, March
4 67 1994, pp. 12-16.
5 (Ale02) I. Alexander and R. Stevens, Writing Better 68 (Def94) J. DeFoe, “Requirements Engineering
6 Requirements, Addison-Wesley, 2002. 69 Technology in Industrial Education,” presented at IEEE
7 (Ard97) M. Ardis, “Formal Methods for 70 International Conference on Requirements
8 Telecommunication System Requirements: A Survey of 71 Engineering,1994.
9 Standardized Languages,” Annals of Software 72 (Dem97) E. Demirors, “A Blackboard Framework for
10 Engineering, vol. 3, 1997. 73 Supporting Teams in Software Development,” presented
11 (Ber97) V. Berzins et al., “A Requirements Evolution 74 at Ninth IEEE International Conference on Software
12 Model for Computer Aided Prototyping,” presented at 75 Engineering and Knowledge Engineering, Knowledge
13 Ninth IEEE International Conference on Software 76 Systems Institute, 1997.
14 Engineering and Knowledge Engineering, Knowledge 77 (Die95) M. Diepstraten, “Command and Control System
15 Systems Institute, 1997. 78 Requirements Analysis and System Requirements
16 (Bey95) H. Beyer and K. Holtzblatt, “Apprenticing with 79 Specification for a Tactical System,” presented at First
17 the Customer,” Communications of the ACM, vol. 38, 80 IEEE International Conference on Engineering of
18 iss. 5, May 1995, pp. 45-52. 81 complex Computer Systems, 1995.
19 (Bru95) G. Bruno and R. Agarwal, “Validating Software 82 (Dob94) J. Dobson and R. Strens, “Organizational
20 Requirements Using Operational Models,” presented at 83 Requirements Definition for Information Technology,”
21 Second Symposium on Software Quality Techniques 84 presented at IEEE International Conference on
22 and Acquisition Criteria, 1995. 85 Requirements Engineering, 1994.
23 (Bry94) E. Bryne, “IEEE Standard 830: Recommended 86 (Duf95) D. Duffy et al., “A Framework for
24 Practice for Software Requirements Specification,” 87 Requirements Analysis Using Automated Reasoning,”
25 presented at IEEE International Conference on 88 presented at Seventh International Conference on
26 Requirements Engineering, 1994. 89 Advanced Information Systems Engineering, 1995.
27 (Buc94) G. Bucci et al., “An Object-Oriented Dual 90 (Eas95) S. Easterbrook and B. Nuseibeh, “Managing
28 Language for Specifying Reactive Systems,” presented 91 Inconsistencies in an Evolving Specification,” presented
29 at IEEE International Conference on Requirements 92 at Second International Symposium on Requirements
30 Engineering, 1994. 93 Engineering, 1995.
31 (Bus95) D. Bustard and P. Lundy, “Enhancing Soft 94 (Edw95) M. Edwards et al., “RECAP: A Requirements
32 Systems Analysis with Formal Modeling,” presented at 95 Elicitation, Capture, and Analysis Process Prototype
33 Second International Symposium on Requirements 96 Tool for Large Complex Systems,” presented at First
34 Engineering, 1995. 97 IEEE International Conference on Engineering of
35 (Che94) M. Chechik and J. Gannon, “Automated 98 Complex Computer Systems, 1995.
36 Verification of Requirements Implementation,” 99 (ElE95) K. El-Emam and N. Madhavji, “Requirements
37 presented at Proceedings of the International 100 Engineering Practices in Information Systems
38 Symposium on Software Testing and Analysis, special 101 Development: A Multiple Case Study,” presented at
39 issue, 1994. 102 Second International Symposium on Requirements
40 (Chu95) L. Chung and B. Nixon, “Dealing with Non- 103 Engineering, 1995.
41 Functional Requirements: Three Experimental Studies 104 (Fai97) R. Fairley and R. Thayer, “The Concept of
42 of a Process-Oriented Approach,” presented at 105 Operations: The Bridge from Operational Requirements
43 Seventeenth IEEE International Conference on Software 106 to Technical Specifications,” Annals of Software
44 Engineering, 1995. 107 Engineering, vol. 3, 1997.
45 (Cia97) P. Ciancarini et al., “Engineering Formal 108 (Fic95) S. Fickas and M. Feather, “Requirements
46 Requirements: An Analysis and Testing Method for Z 109 Monitoring in Dynamic Environments,” presented at
47 Documents,” Annals of Software Engineering, vol. 3, 110 Second International Symposium on Requirements
48 1997. 111 Engineering, 1995.
49 (Cre94) R. Crespo, “We Need to Identify the 112 (Fie95) R. Fields et al., “A Task-Centered Approach to
50 Requirements of the Statements of Non-Functional 113 Analyzing Human Error Tolerance Requirements,”
51 Requirements,” presented at International Workshop on 114 resented at Second International Symposium on
52 Requirements Engineering: Foundations of Software 115 Requirements Engineering, 1995.
53 Quality, 1994. 116 (Gha94) J. Ghajar-Dowlatshahi and A. Varnekar,
54 (Cur94) P. Curran et al., “BORIS-R Specification of the 117 “Rapid Prototyping in Requirements Specification Phase
55 Requirements of a Large-Scale Software Intensive 118 of Software Systems,” presented at Fourth International
56 System,” presented at Requirements Elicitation for 119 Symposium on Systems Engineering, National Council
57 Software-Based Systems, 1994. 120 on Systems Engineering, 1994.
58 (Dar97) R. Darimont and J. Souquieres, “Reusing 121 (Gib95) M. Gibson, “Domain Knowledge Reuse During
59 Operational Requirements: A Process-Oriented 122
60 Approach,” presented at IEEE International Symposium 123
61 on Requirements Engineering, 1997. 124
62 125 Requirements Engineering,” presented at Seventh
63 126 International Conference on Advanced Information
127 Systems Engineering (CAiSE ’95), 1995.
 1 (Gol94) L. Goldin and D. Berry, “AbstFinder: A 65 Conference on Advanced Information Systems
2 Prototype Abstraction Finder for Natural Language Text 66 Engineering (CAiSE ’95), 1995.
3 for Use in Requirements Elicitation: Design, 67 (Lal95) V. Lalioti and B. Theodoulidis, “Visual
4 Methodology and Evaluation,” presented at IEEE 68 Scenarios for Validation of Requirements
5 International Conference on Requirements Engineering, 69 Specification,” presented at Seventh International
6 1994. 70 Conference on Software Engineering and Knowledge
7 (Got97) O. Gotel and A. Finkelstein, “Extending 71 Engineering, Knowledge Systems Institute, 1995.
8 Requirements Traceability: Lessons Learned from an 72 (Lam95) A. v. Lamsweerde et al., “Goal-Directed
9 Industrial Case Study,” presented at IEEE International 73 Elaboration of Requirements for a Meeting Scheduler:
10 Symposium on Requirements Engineering, 1997. 74 Problems and Lessons Learnt,” presented at Second
11 (Hei96) M. Heimdahl, “Errors Introduced during the 75 International Symposium on Requirements Engineering,
12 TACS II Requirements Specification Effort: A 76 1995.
13 Retrospective Case Study,” presented at Eighteenth 77 (Lei97) J. Leite et al., “Enhancing a Requirements
14 IEEE International Conference on Software 78 Baseline with Scenarios,” presented at IEEE
15 Engineering, 1996. 79 International Symposium on Requirements Engineering,
16 (Hei96a) C. Heitmeyer et al., “Automated Consistency 80 1997.
17 Checking Requirements Specifications,” ACM 81 (Ler97) F. Lerch et al.., “Using Simulation-Based
18 Transactions on Software Engineering and 82 Experiments for Software Requirements Engineering,”
19 Methodology, vol. 5, iss. 3, July 1996, pp. 231-261. 83 Annals of Software Engineering, vol. 3, 1997.
20 (Hol95) K. Holtzblatt and H. Beyer, “Requirements 84 (Lev94) N. Leveson et al., “Requirements Specification
21 Gathering: The Human Factor,” Communications of the 85 or Process-Control Systems,” IEEE Transactions on
22 ACM, vol. 38, iss. 5, May 1995, pp. 31-32. 86 Software Engineering, vol. 20, iss. 9, September 1994,
23 (Hud96) E. Hudlicka, “Requirements Elicitation with 87 pp. 684-707.
24 Indirect Knowledge Elicitation Techniques: Comparison 88 (Lut96a) R. Lutz and R. Woodhouse, “Contributions of
25 of Three Methods,” presented at Second IEEE 89 SFMEA to Requirements Analysis,” presented at
26 International Conference on Requirements Engineering, 90 Second IEEE International Conference on Requirements
27 1996. 91 Engineering, 1996.
28 (Hug94) K. Hughes et al., “A Taxonomy for 92 (Lut97) R. Lutz and R. Woodhouse, “Requirements
29 Requirements Analysis Techniques,” presented at IEEE 93 Analysis Using Forward and Backward Search,” Annals
30 International Conference on Requirements Engineering, 94 of Software Engineering, vol. 3, 1997.
31 1994. 95 (Mac96) L. Macaulay, Requirements Engineering,
32 (Hug95) J. Hughes et al., “Presenting Ethnography in 96 Springer-Verlag, 1996.
33 the Requirements Process,” presented at Second IEEE 97 (Mai95) N. Maiden et al., “Computational Mechanisms
34 International Symposium on Requirements Engineering, 98 for Distributed Requirements Engineering,” presented at
35 1995. 99 Seventh International Conference on Software
36 (Hut94) A.T.F. Hutt, ed., Object Analysis and Design - 100 Engineering and Knowledge Engineering, Knowledge
37 Comparison of Methods. Object Analysis and Design - 101 Systems Institute, 1995.
38 Description of Methods, John Wiley & Sons, 102 (Mar94) B. Mar, “Requirements for Development of
39 1994.(INCOSE00) INCOSE, How To: Guide for all 103 Software Requirements,” presented at Fourth
40 Engineers, Version 2, International Council on Systems 104 International Symposium on Systems Engineering,
41 Engineering, 2000. 105 1994.
42 (Jac95) M. Jackson, Software Requirements and 106 (Mas97) P. Massonet and A. v. Lamsweerde,
43 Specifications, Addison-Wesley, 1995. 107 “Analogical Reuse of Requirements Frameworks,”
44 (Jac97) M. Jackson, “The Meaning of Requirements,” 108 presented at IEEE International Symposium on
45 Annals of Software Engineering, vol. 3, 1997. 109 Requirements Engineering, 1997.
46 (Jon96) S. Jones and C. Britton, “Early Elicitation and 110 (McF95) I. McFarland and I. Reilly, “Requirements
47 Definition of Requirements for an Interactive 111 Traceability in an Integrated Development
48 Multimedia Information System,” presented at Second 112 Environment,” presented at Second International
49 IEEE International Conference on Requirements 113 Symposium on Requirements Engineering, 1995.
50 Engineering, 1996. 114 (Mea94) N. Mead, “The Role of Software Architecture
51 (Kir96) T. Kirner and A. Davis, “Nonfunctional 115 in Requirements Engineering,” presented at IEEE
52 Requirements for Real-Time Systems,” Advances in 116 International Conference on Requirements Engineering,
53 Computers, 1996. 117 1994.
54 (Kle97) M. Klein, “Handling Exceptions in 118 (Mos95) D. Mostert and S. v. Solms, “A Technique to
55 Collaborative Requirements Acquisition,” presented at 119 Include Computer Security, Safety, and Resilience
56 IEEE International Symposium on Requirements 120 Requirements as Part of the Requirements
57 Engineering, 121 Specification,” Journal of Systems and Software, vol.
58 1997. 122 31, iss. 1, October 1995, pp. 45-53.
59 (Kos97) R. Kosman, “A Two-Step Methodology to 123 (Myl95) J. Mylopoulos et al., “Multiple Viewpoints
60 Reduce Requirements Defects,” Annals of Software 124 Analysis of Software Specification Process,” IEEE
61 Engineering, vol. 3, 1997. 125 Transactions on Software Engineering, 1995.
62 (Kro95) J. Krogstie et al., “Towards a Deeper 126 (Nis92) K. Nishimura and S. Honiden, “Representing
63 Understanding of Quality in Requirements 127 and Using Non-Functional Requirements: A Process-
64 Engineering,” presented at Seventh International
 1 Oriented Approach,” IEEE Transactions on Software 64 (Ros98) L. Rosenberg, T.F. Hammer, and L.L.
2 Engineering, December 1992. 65 Huffman, “Requirements, testing and metrics,”
3 (Nis97) H. Nissen et al., “View-Directed Requirements 66 presented at 15th Annual Pacific Northwest Software
4 Engineering: A Framework and Metamodel,” presented 67 Quality Conference, 1998.
5 at Ninth IEEE International Conference on Software 68 (Sch94) W. Schoening, “The Next Big Step in Systems
6 Engineering and Knowledge Engineering, Knowledge 69 Engineering Tools: Integrating Automated
7 Systems Institute, 1997. 70 Requirements Tools with Computer Simulated Synthesis
8 (OBr96) L. O’Brien, “From Use Case to Database: 71 and Test,” presented at Fourth International Symposium
9 Implementing a Requirements Tracking System,” 72 on Systems Engineering, 1994.
10 Software Development, vol. 4, iss. 2, February 1996, pp. 73 (She94) M. Shekaran, “The Role of Software
11 43-47. 74 Architecture in Requirements Engineering,” presented at
12 (UML04) Object Management Group, Unified Modeling 75 IEEE International Conference on Requirements
13 Language, www.uml.org, 2004. (Opd94) A. Opdahl, 76 Engineering, 1994.
14 “Requirements Engineering for Software Performance,” 77 (Sid97) J. Siddiqi et al., “Towards Quality Requirements
15 presented at International Workshop on Requirements 78 Via Animated Formal Specifications,” Annals of
16 Engineering: Foundations of Software Quality, 1994. 79 Software Engineering, vol. 3, 1997.
17 (Pin96) F. Pinheiro and J. Goguen, “An Object-Oriented 80 (Span97) G. Spanoudakis and A. Finkelstein,
18 Tool for Tracing Requirements,” IEEE Software, vol. 81 “Reconciling Requirements: A Method for Managing
19 13, iss. 2, March 1996, pp. 52-64. 82 Interference, Inconsistency, and Conflict,” Annals of
20 (Pla96) G. Playle and C. Schroeder, “Software 83 Software Engineering, vol. 3, 1997.
21 Requirements Elicitation: Problems, Tools, and 84 (Ste94) R. Stevens, “Structured Requirements,”
22 Techniques,” Crosstalk: The Journal of Defense 85 presented at Fourth International Symposium on
23 Software Engineering, vol. 9, iss. 12, December 1996, 86 Systems Engineering, 1994.
24 pp. 19-24. 87 (Vin90) W.G. Vincenti, What Engineers Know and How
25 (Poh94) K. Pohl et al., “Applying AI Techniques to 88 They Know It - Analytical Studies form Aeronautical
26 Requirements Engineering: The NATURE Prototype,” 89 History, John Hopkins University Press, 1990.
27 presented at IEEE Workshop on Research Issues in the 90 (Wei03) K. Weigers, Software Requirements, second
28 Intersection Between Software Engineering and 91 ed., Microsoft Press, 2003.
29 Artificial Intelligence, 1994. 92 (Whi95) S. White and M. Edwards, “A Requirements
30 (Por95) A. Porter et al., “Comparing Detection Methods 93 Taxonomy for Specifying Complex Systems,” presented
31 for Software Requirements Inspections: A Replicated 94 at First IEEE International Conference on Engineering
32 Experiment,” IEEE Transactions on Software 95 of Complex Computer Systems, 1995.
33 Engineering, vol. 21, iss. 6, June 1995, pp. 563-575. 96 (Wil99) B. Wiley, Essential System Requirements: A
34 (Pot95) C. Potts et al., “An Evaluation of Inquiry-Based 97 Practical Guide to Event-Driven Methods, Addison-
35 Requirements Analysis for an Internet Server,” 98 Wesley, 1999.
36 presented at Second International Symposium on 99 (Wyd96) T. Wyder, “Capturing Requirements With Use
37 Requirements Engineering, 1995. 100 Cases,” Software Development, vol. 4, iss. 2, February
38 (Pot97) C. Potts and I. Hsi, “Abstraction and Context in 101 1996, pp. 36-40.
39 Requirements Engineering: Toward a Synthesis,” 102 (Yen97) J. Yen and W. Tiao, “A Systematic Tradeoff
40 Annals of Software Engineering, vol. 3, 1997. 103 Analysis for Conflicting Imprecise Requirements,”
41 (Pot97a) C. Potts and W. Newstetter, “Naturalistic 104 presented at IEEE International Symposium on
42 Inquiry and Requirements Engineering: Reconciling 105 Requirements Engineering, 1997.
43 Their Theoretical Foundations,” presented at IEEE 106 (Yu97) E. Yu, “Towards Modeling and Reasoning
44 International Symposium on Requirements Engineering, 107 Support for Early-Phase Requirements Engineering,”
45 1997. 108 presented at IEEE International Symposium on
46 (Ram95) B. Ramesh et al., “Implementing Requirements 109 Requirements Engineering, 1997.
47 Traceability: A Case Study,” presented at Second 110 (Zav96) P. Zave and M. Jackson, “Where Do Operations
48 International Symposium on Requirements Engineering, 111 Come From? A Multiparadigm Specification
49 1995. 112 Technique,” IEEE Transactions on Software
50 (Reg95) B. Regnell et al., “Improving the Use Case 113 Engineering,, vol. 22, iss. 7, July 1996, pp. 508-528.
51 Driven Approach to Requirements Engineering,”
52 presented at Second IEEE International Symposium on
53 Requirements Engineering, 1995.
54 (Reu94) H. Reubenstein, “The Role of Software
55 Architecture in Software Requirements Engineering,”
56 presented at IEEE International Conference on
57 Requirements Engineering, 1994.
58 (Rob94) J. Robertson and S. Robertson, Complete
59 Systems Analysis, Vol. 1 and 2, Prentice Hall, 1994.
60 (Rob94a) W. Robinson and S. Fickas, “Supporting
61 Multi- Perspective Requirements Engineering,”
62 presented at IEEE International Conference on
63 Requirements Engineering, 1994.
 1 APÉNDICE B. LISTA DE ESTANDARS
2
3 (IEEE830-98) IEEE Std 830-1998, IEEE Recommended
4 Practice for Software Requirements Specifications,
5 IEEE, 1998.
6 (IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE
7 Standard for Software Reviews, IEEE, 1997.
8 (IEEE1233-98) IEEE Std 1233-1998, IEEE Guide for
9 Developing System Requirements Specifications, 1998.
10 (IEEE1320.1-98) IEEE Std 1320.1-1998, IEEE
11 Standard for Functional Modeling Language-Syntax
12 and Semantics for IDEF0, IEEE, 1998.
13 (IEEE1320.2-98) IEEE Std 1320.2-1998, IEEE
14 Standard for Conceptual Modeling Language-Syntax
15 and Semantics for IDEFIX97 (IDEFObjetct), IEEE,
16 1998.
17 (IEEE1362-98) IEEE Std 1362-1998, IEEE Guide for
18 Information Technology-System Definition-Concept of
19 Operations (ConOps) Document, IEEE, 1998.
20
21
22 (IEEE1465-98) IEEE Std 1465-1998//ISO/
23 IEC12119:1994, IEEE Standard Adoption of
24 International Standard ISO/IEC12119:1994(E),
25 Information Technology-Software Packages-Quality
26 requirements and testing, IEEE, 1998.
27 (IEEEP1471-00) IEEE Std 1471-2000, IEEE
28 Recommended Practice for Architectural Descriptionos
29 Software Intensive Systems, Architecture Working
30 Group of the Software Engineering Standards
31 Committee, 2000.
32 (IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/
33 IEC12207:1995, Industry Implementation of Int. Std.
34 ISO/IEC 12207:95, Standard for Information
35 Technology- Software Life Cycle Processes, IEEE,
36 1996.
37 (IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/
38 IEC14143-1:1998, Information Technology-Software
39 Measurement-Functional Size Measurement-Part 1:
40 Definitions of Concepts, IEEE, 2000.