¿Qué es la Ingeniería de Sistemas y es

relevante para mí?

La Ingeniería de Sistemas es un campo de la ingeniería que se encarga del diseño, la
programación, la implantación y el mantenimiento de sistemas. Utiliza un enfoque
interdisciplinario que permite estudiar y comprender la realidad, con el propósito de
implementar u optimizar sistemas complejos. La Ingeniería de Sistemas no construye
productos tangibles, sino sistemas abstractos mediante el uso de metodologías de la
Ciencia de Sistemas. Algunas herramientas utilizadas por la Ingeniería de Sistemas son
Modelación y Simulación, Optimización, Sistemas Dinámicos, Análisis de Confiabilidad y
Análisis de Decisiones.

En el Instituto de Ingeniería se realiza investigación en las siguientes ramas de la

Ingeniería de Sistemas:

 Ingeniería de Transporte
 Investigación de Operaciones
 Planeación
 Ingeniería Industrial

La ingeniería de sistemas, en esencia, es un enfoque interdisciplinario para el diseño, la

implementación y la evaluación que tiene la clave para el desarrollo exitoso de sistemas humanos
complejos. Es una disciplina muy amplia, por lo que apuntamos a destilar cómo los conceptos y
procedimientos podrían aplicarse a proyectos individuales.

Antes de introducirnos en la ingeniería de sistemas, es decir la ingeniería de un sistema,

necesitamos dar una breve mirada a de qué hablamos cuando decimos que algo es un sistema.
Ahora esto es particularmente importante porque la palabra sistema es, quizás, una de las
palabras más excesivamente utilizadas. Y ésto es porque la palabra sistema tiene muchos
contextos, existen sistemas físicos como el sistema solar, sistemas de ríos, sistemas de vías,
sistemas de satélites, de comunicaciones, de información, sistemas de poleas, sistema nervioso,
sólo por nombrar algunos. Y también hay sistemas conceptuales como sistemas filosóficos,
sociales, religiosos, de juegos, sistemas bancarios, de gobierno, y muchísimos mas.

0:42

La palabra, incluso es usada en ejemplos mas esotéricos como la consideración del

comportamiento individual y social como un sistema de eventos con un propósito.

0:52
Ahora, en todos estos contextos, el aspecto en común es el uso de la palabra sistema, proviene de
su significado originario de su raíz griega. Un sistema se refiere a una totalidad o un conjunto que
surge cuando un número de cosas han sido agrupadas de un modo en particular y por una razón
determinada. Qué es el set, cómo está agrupado y por qué razón es contexto dependiente.
Entonces antes de continuar debemos considerar brevemente qué entendemos por sistema en un
contexto particular de la ingeniería de sistemas.

1:24

En ingeniería de sistemas un sistemas se puede definir como un conjunto o set de elementos que
interactúan para alcanzar un propósito determinado.

1:33

Esta definición implica que un sistema comprende elementos interconectados o que hay
interacción entre esos elementos. Y por el sólo hecho de identificar el sistema que nos interesa, un
sistema externo lindero también está implicado.

1:49

Cuando dibujamos los límites alrededor de los elementos seleccionados de un sistema, estamos
definiendo el sistema de interés. Este sistema de interés comprende a los elementos del sistema y
todas las interconecciones que existen dentro nuestro límite definido.

2:05

Al propósito del sistema se lo llama misión, La cual debe estar claramente expresada por la
gerencia del negocio y los accionistas.

2:12

La misión representa el punto de partida para proceso de diseño, así como provee las bases para
el examen final de la aptitud del sistema para su propósito una vez que ha sido instalado.

2:22

En un sentido amplio entonces, la misión de un sistema es la de proveer una solución a un

problema del negocio.

2:30

Esta delimitación en el uso general de la palabra sistema es muy importante porque tiene dos
implicaciones principales.

2:37
Primero, cuando nos referimos al sistema como un conjunto de elementos que están
interconectados con la finalidad de cumplir un propósito, estamos diciendo que la totalidad de
estos aspectos principales resultan de una decisión consciente. Esto es, nos referimos a un sistema
que ha sido deliberadamente diseñado o construido, de ahí nuestro interés en ingeniería de
sistemas.

2:58

Un sistema que ha sido diseñado para cumplir con una misión específica debe poder realizar esa
misión con relativa autonomía. Así pues, debe ser directiva y operativamente independiente, y
también podría haber sido obtenido independientemente.

3:12

Volveremos a este tema brevemente cuando discutamos las diferencias entre sistemas y sub-
sistemas y, entre sistemas y sistemas de sistemas.

3:23

Existen numerosas formas de clasificar sistemas. Aquí identificaremos los cuatro tipos principales,
con la finalidad de ser claros respecto a cual tipo de sistema nos referimos en ingeniería de
sistemas y por lo tanto en el resto de este curso. Hay sistemas abiertos o cerrados. Tenemos los
que son naturales, hechos por el hombre, o modificados por el hombre. Existen sistemas que son
físicos o conceptuales. Hay sistemas con precedentes y sin precedentes. Demos un vistazo a cada
uno de éstos, un poco más detenidamente. Uno abierto, interactúa con su entorno operativo. Es
decir, el abierto acepta entradas desde su entorno atravesando sus límites, y retorna su producto
a través de los mismos límites a su ambiente exterior. Un sistema cerrado, por otro lado, está
aislado de su entorno.

4:09

Estamos interesados en sistemas útiles, los cuales deberán ser abiertos.

4:15

Los sistemas naturales contienen elementos naturales y son el resultado de procesos naturales.
Los sistemas hechos por el hombre llegan a existir gracias a los esfuerzos humanos y pueden
contener algunos elementos de manufactura humana, o algunos elementos naturales adaptados a
propósitos designados por el hombre. Los sistemas naturales que han sido modificados para
propósitos humanos, se llaman sistemas modificados por el hombre.

4:35

La ingeniería de sistemas para sistemas naturales, ciertamente no ha sido dirigida por humanos.
Por lo tanto, solamente nos interesan los sistemas hechos por humanos o modificados por ellos.
4:46

Los sistemas físicos existen en forma física y, los conceptuales, no ellos son conceptuales. Ya que
nuestro foco de ingeniería de sistemas está en sistemas´de ingeniería, cosas que en realidad
podemos producir, estamos interesados en sistemas físicos.

5:01

En un sistema con precedentes, sistemas similares o al menos la mayoría de los elementos del
sistema han sido producidos anteriormente.

5:08

Un sistema sin precedentes es uno que no ha sido producido previamente.

5:13

Sistemas que se componen en su mayoría de elementos sin precedentes son el resultado de

investigación y desarrollo. Aquí nos enfocamos en sistemas que utilizan elementos largamente pre
utilizados. Es decir, aquellos que han sido diseñados previamente y por lo tanto, aquellos cuya
ingeniería de sistema es la más apropiada.

5:32

Ahora, basados en esas cuatro clases de sistemas, existe una amplia variedad de combinaciones
que pueden desencadenar en un gran número de tipos de sistemas, teniendo cada uno
propiedades marcadamente diferentes. Pero, es importante reconocer que en este curso y, en
ingeniería de sistemas, estamos hablando de sistemas abiertos, físicos, que han sido hechos o
modificados por el hombre y con elementos ampliamente pre utilizados.

5:55

Ahora, volviendo a nuestro simple diagrama de un sistema.

5:58

Ya que estamos interesados en la ingeniería de sistemas físicos que están abiertos, nuestro
sistema de interés debe admitir interfaces externas. es decir, entradas y salidas a través de los
límites del sistema. Entonces, conectado a elementos externos que existen en un ambiente
operativo exterior, o quizás un sistema recargado. Para ir más lejos, a veces necesitamos estar
conscientes de un mayor contexto, inclusive. Por lo que un SOI puede ser considerado parte de un
SOI mayor, un WSOI los cuales existen en un ambiente operativo.

6:28

Y ese ambiente operativo puede ser concebido incluso como parte de un ambiente mayor.
6:34

En un sentido físico, el término sistema, a veces es considerado como sinónimo de producto. Así
que decimos que el proyecto nos entrega un sistema,o nos entrega un producto. Un sistema, sin
embargo, normalmente se considera que contiene un número de productos. ANSI/EIA-632 ve un
sistema como conjunto de productos operativos o productos finales, y permite productos tales
como de evaluación, entrenamiento, y de desecho.

Un sistema puede describirse de dos formas, en términos lógicos, y en términos físicos.

0:13

Una descripción lógica, e históricamente frecuentemente llamada descripción funcional, expresa

lo que el sistema hará, cuán bien lo hará, cómo será probado, bajo qué condiciones funcionará, y
qué otros sistemas serán involucrados con su funcionamiento.

0:29

Una descripción física cuenta los elementos propios del sistema. explica qué son esos elementos,
cómo se ven, cómo serán hechos, cómo serán integrados y probados. Por lo tanto, una descripción
lógica es respecto a qué y una física se refiere a cómo.

0:45

Pero ambas descripciones son muy importantes, por supuesto, y ambas existen juntas. Y ambas
requieren lo que nombraremos después, una serie de enunciados llamados requerimientos.

0:58

Ahora, ambas descripciones del sistema son válidas e independientes. Y es muy importante que el
sistema sea descrito de ambas formas, lógica y la físicamente. Pero, por supuesto, primero
debemos enfocarnos en la descripción lógica.

1:10

Bien, en un sentido realmente médico, se desarrolla la descripción lógica primero, con el objetivo
de determinar si un sistema físico particular es apropiado. Es así, cómo lo vamos a hacer útil para
nosotros. Debemos primero comprender, obviamente, qué es lo que vamos a hacer. ¿Cual es el
propósito que queremos para el sistema?

1:28

Por eso necesitamos enfocarnos en la descripción lógica, el qué, antes de examinar una serie de
descripciones físicas candidatas, el cómo, de qué manera desarrollaríamos el sistema. Una de ellas
es ir eligiendo la solución física según nuestra preferencia. La segunda razón es que no debemos
permitir la manera en la cual frecuentemente implementamos sistemas corrientes, para colorear
innecesariamente la forma en la cual describiremos sistemas futuros. Si nos enfocamos en la
descripción lógica, podemos entonces, enfocarnos en, quizás, soluciones novedosas para nuevos o
inclusive viejos problemas. Si nos enfocamos en la solución física primero, nosotros terminaríamos
siempre resolviendo nuevos problemas con los viejos bloques físicos construidos. Tercero, si
vamos a sacrificar cosas, si vamos a sacrificar algún valor por dinero, por ejemplo, entonces,
necesitamos hacerlo a un nivel lógico antes de decidir la implementación física. Si no, podríamos
desperdiciar un significativo equipamiento seleccionando soluciones físicas que cumplen funciones
innecesarias, o que no cumplen con las que realmente son críticas. Continuando, una descripción
lógica es idealmente la adecuada, para la interfase entre la ingeniería de sistemas y el caso de
negocios. Mientras que frecuentemente es posible para el caso del negocio obtener directamente
una solución física obvia, probablemente sea mejor para el manejo del negocio hacer una
transición desde su caso de negocio hacia una descripción lógica más detallada, antes de decidirse
por cómo resolver ese problema en un sentido físico. La definición de la descripción lógica antes
de desarrollar un sistema físico, por lo tanto avanza desde el caso de negocio hacia la solución
final, en un modo más controlado, más verificable. Y la razón final es que esa descripción lógica
cambia mucho más lentamente. La descripción física cambia muy rápido, especialmente en estos
días con los cambios en la tecnología.

3:13

Es discutible por ejemplo, la necesidad de una descripción de nivel superior, de un motor de

combustión interna, que no ha cambiado mucho en los últimos doscientos años. Su propósito es
proveer movimiento de avance para el automóvil. Pero la implementación física para un motor ha
cambiado dramáticamente. Así es, el propósito del sistema como parte del auto, no ha cambiado,
pero lo que hacemos, lo hace en la medida que reconocemos las nuevas tecnologías

3:41

en el desarrollo de un sistema, por lo tanto, existen dos vistas arquitectónicas. Una arquitectura
de sistema lógico y una arquitectura del sistema físico.

3:50

Por supuesto, esas dos descripciones son del mismo sistema, es decir deben estar relacionadas.
Luego veremos cómo la arquitectura lógica, siendo la guía de los requerimientos para el desglose
de la estructura, es aplicada en la arquitectura física, representada en lo que llamamos el trabajo
de desarmar la estructura.
CICLO DE VIDA DE UN SISTEMA
Las unidades de las que vamos a hablar en este curso se relacionan predominantemente con la fase de
adquisición del ciclo de vida del sistema y, en menor medida, con la fase de utilización. Para estas dos fases
principales, utilizaremos las actividades del ciclo de vida, las actividades más comúnmente utilizadas,
particularmente en los sectores de defensa y aeroespacial. Ahora los nombres de estas actividades comenzaron
con los estándares militares y con los primeros trabajos de Blanchard y Fabrycky, y la mayoría de los
estándares modernos de ingeniería de sistemas y gestión de proyectos hacen uso de estos términos.
0:35
En la fase de adquisición, las actividades se denominan diseño conceptual, diseño preliminar, diseño y
desarrollo detallados, y construcción y producción.
0:46
En la fase de utilización, las actividades son uso operacional y soporte del sistema. Y estas dos actividades se
llevan a cabo en paralelo. La fase de adquisición comprende las cuatro actividades principales de diseño
conceptual, diseño preliminar, diseño detallado y desarrollo, y construcción y producción. Y es en esta fase de
adquisición en la que nos centraremos durante todo el curso. Veamos cada una de estas actividades con más
detalle en las próximas semanas.
1:13
Primero, el diseño conceptual, que representa la transición formal del mundo de los negocios al mundo de los
proyectos, por lo que es una fase muy importante.
1:22
Es importante, porque la declaración de la misión debe ser capaz de proporcionar una descripción lógica
completa del sistema de interés, para que podamos adquirirlo de una manera que sea útil para el negocio. Es
esencial que la actividad finalice con una comprensión completa y completa de los requisitos del sistema, de
modo que podamos garantizar el compromiso apropiado entre los gerentes comerciales y las partes
interesadas de alto nivel. Ahora, esta transición tiene tres pasos amplios desde la declaración de la misión
hasta un conjunto de requisitos del sistema. Primero, desarrollamos necesidades y requisitos comerciales. Son
articulados y confirmados por la administración comercial, y luego son elaborados por las partes interesadas
en el nivel de operaciones comerciales, en un conjunto de necesidades y requisitos de las partes interesadas o
SNR. Luego, los ingenieros de requisitos los elaboran en un conjunto de requisitos del sistema, comúnmente
llamado especificación de requisitos del sistema o el SYRS. Puede haber más de una especificación de
requisitos del sistema para todo el sistema de capacidades. Pero es más probable que haya un SYRS para
todos los elementos constitutivos de la capacidad, es decir, uno para cada uno de los principales sistemas de
materiales, uno para el personal, uno para soporte, uno para instalaciones de entrenamiento, y así
sucesivamente.
Como se señaló anteriormente, cada uno de estos elementos constitutivos de capacidad se puede desarrollar
independientemente y se puede desarrollar a través de contratos separados.
2:47
La especificación de requisitos del sistema es un elemento clave de lo que se llama la línea de base funcional.
La línea de base funcional representa la arquitectura lógica a nivel de sistema que describe las características
y los por qué del sistema que cumple con las necesidades y requisitos del negocio y las partes interesadas.
Entonces el diseño conceptual termina con lo que se llama la revisión del diseño del sistema. Y la revisión del
diseño del sistema, entre muchas otras cosas, finaliza la línea de base funcional inicial. Por lo tanto,
proporciona una verificación formalizada del diseño lógico. Comunica ese diseño a los principales
interesados. Confirma la interfaz externa y los problemas de interoperabilidad. Confirma las necesidades y los
requisitos del negocio, las necesidades y requisitos de las partes interesadas, y los requisitos del sistema, y
proporciona un registro formal de las decisiones de diseño y la aceptación del diseño, antes de que nos
embarquemos en la siguiente actividad.
3:41
El objetivo del diseño preliminar es convertir la línea de base funcional en una descripción física de nivel
superior del sistema.
3:47
Es entonces cuando van a continuar y describir el cómo del sistema. El diseño preliminar es por lo tanto el
escenario, donde el diseño lógico se traduce en el diseño físico. Y así el enfoque cambia del dominio del
problema al dominio de la solución y muy probablemente de un cliente al contratista.
4:05
El diseño implementado resultante es un diseño de subsistema conocido como línea de base asignada. Se
llama asignado porque hemos agrupado lógicamente las funciones en la línea de base funcional. En grupos
físicos de nivel de subsistema, que llamamos elementos de configuración. La suma de todos los elementos de
configuración es el diseño físico del nivel superior del sistema.
4:30
En el centro de la línea de base asignada hay una serie de especificaciones de desarrollo, que contienen los
requisitos de nivel de subsistema agrupados por elemento de configuración.
4:40
La actividad finaliza con la revisión preliminar del diseño, el PDR. El PDR y otra vez entre muchas otras
cosas, formaliza la línea de base asignada.
4:51
Ahora asegura que el esfuerzo de diseño que le precedió fue apropiado, que se centró en el nivel apropiado de
diseño físico y garantiza la adecuación técnica de la solución propuesta. También se centra en el riesgo
técnico y se asegura de que la solución propuesta en el ABL coincida con la línea de base funcional.
El diseño preliminar también investiga las interfaces entre los elementos de configuración y la compatibilidad
de cada uno de esos elementos de configuración.
5:24
Ahora el otro tipo de línea de base que desarrollamos en el diseño preliminar es el punto de partida para el
diseño detallado y el desarrollo. Que es donde se lleva a cabo la ingeniería tradicional. Proporcionar un
desarrollo completo de los subsistemas individuales, los ensamblajes y los componentes que conforman el
sistema. En este nivel hacemos prototipos de ingeniería y confirmamos el diseño del sistema probando la
evaluación.
5:47
El resultado de los datos de nuestro proceso de desarrollo de diseño es el establecimiento de lo que se llama,
la línea de base del producto. Y la línea base del producto, como su nombre lo indica, se trata de productos.
Es qué subsistemas, ensamblajes y componentes, necesitamos continuar y construir para formar el sistema
total. Además, por supuesto, debemos tener en cuenta los materiales, los procesos y las personas que
necesitamos para la fabricación y la construcción.
6:12
La definición del sistema en esta etapa debe ser suficientemente detallada para apoyar el comienzo de las
actividades de producción de la construcción.
6:20
La revisión al final de esta actividad se llama revisión crítica del diseño. La crítica revisión del diseño no es
crítica por accidente, es la última vez que el diseño está en papel. Es la revisión final del diseño, que da como
resultado la aceptación oficial del diseño y el posterior inicio de la construcción y producción.
6:37
CDR evalúa el diseño detallado, determina la preparación para la producción y la construcción. Asegura que
el diseño sea compatible e incluye una comprensión detallada de todas las interfaces externas e internas.
6:53
La actividad final dentro de la fase de adquisición, entonces, es la construcción y la producción. Los
componentes se producen de acuerdo con las especificaciones de diseño de detalle, tal como se presentan en
la línea de base del producto. Y a la vez que han desarrollado, el sistema finalmente se construye al final de la
actividad en su forma final.
7:10
Luego hacemos actividades formales de prueba y evaluación, lo llamamos pruebas de aceptación que se
llevarán a cabo para garantizar que la configuración inicial del sistema cumpla con los requisitos de la
especificación de requisitos del sistema.
7:22
La construcción y / o producción en la fase de adquisición, luego termina con lo que se llama una revisión de
calificación formal, a menudo también llamada prueba de aceptación, que proporciona la base sobre la cual el
cliente acepta el sistema del contratista. El FQR está informado por los resultados de lo que se llama AT y E,
aceptación, prueba y evaluación, de lo cual hablaremos más adelante.
En la aceptación del proveedor, el cliente mueve el sistema a la utilización, presentándolo al servicio. Las
principales actividades durante esta fase son, el uso operacional, por supuesto, es el propósito para el que se
diseñó el sistema y el soporte del sistema.
8:03
Las actividades de ingeniería del sistema pueden continuar durante la fase de utilización, principalmente para
respaldar cualquier actividad de modificación que pueda ser necesaria. Y, por supuesto, como vimos
anteriormente, esas modificaciones pueden ser necesarias para rectificar los déficits de rendimiento, para
cumplir con entornos ambientales cambiantes, por ejemplo, o quizás para abordar algún problema de soporte
continuo para mantener el sistema. El sistema permanece en servicio con suerte por un período mucho más
largo de lo que tardó en adquirirlo realmente. Pero debe terminar en algún momento y, por lo tanto, el ciclo de
vida del sistema finaliza con la jubilación del sistema, que bien puede superponerse, como vimos
anteriormente con la introducción al servicio de un sistema de reemplazo.
8:44
A medida que nos acercamos a la introducción al ciclo de vida del sistema, debemos tener en cuenta que el
ciclo de vida genérico del sistema que hemos discutido aquí no pretende representar ningún modelo particular
de desarrollo o adquisición.
8:55
Hemos presentado las actividades del ciclo de vida como si se llevaran a cabo de forma secuencial, porque la
mejor manera de explicar las actividades y los efectos extraños de la ingeniería de sistemas es especial para
quienes son nuevos. Sin embargo, al hacerlo, hemos asumido lo que generalmente se conoce como el modelo
de cascada del desarrollo del sistema.
9:12
Tenemos que señalar temprano que hay, sin embargo, una serie de otros enfoques de desarrollo para
implementar las actividades del ciclo de vida del sistema. Estos se llaman modelos de adquisición progresiva,
espiral o evolutiva. Ahora cada uno de ellos tiene diferentes fortalezas y debilidades, dependiendo del tipo de
sistema, y luego la organización total durante el desarrollo. La selección de un enfoque de desarrollo
adecuado es, por lo tanto, una actividad crítica al principio del ciclo de vida del sistema. Pero para nuestros
propósitos aquí, por simplicidad, particularmente en esta primera parte del curso, asumimos el enfoque de
cascada. Porque proporciona un buen flujo secuencial lógico de actividades y entregables que lo hace fácil de
explicar.
Además, debe tenerse en cuenta que, en general, se considera que el enfoque en cascada es el componente
básico de cualquier enfoque alternativo, como incremental, evolutivo y espiral. Y sigue siendo un enfoque de
desarrollo muy comúnmente aplicado.
10:06
Por alguna razón, entonces, una sólida comprensión del desarrollo de cataratas es, por lo tanto, muy útil.
Ahora discutiremos estos temas con mucho más detalle al final del curso, cuando consideramos la ingeniería
de sistemas como parte de los diversos enfoques de adquisición y desarrollo.
10:22
Bueno, eso completa nuestra breve introducción a los sistemas y el ciclo de vida del sistema y completa el
módulo uno. En la siguiente presentación, proporcionamos una descripción general de la disciplina de la
ingeniería de sistemas antes de profundizar en cada una de las principales actividades.
El enfoque de arriba hacia abajo. Como mencioné anteriormente, los
métodos de diseño de ingeniería tradicionales se basan en enfoques ascendentes, en los cuales los
componentes conocidos que son conocidos y de confianza para los ingenieros se diseñan y
construyen, y luego se combinan en ensamblajes, y luego en subsistemas y de los cuales el sistema
está construido.
El sistema luego se prueba para sus propiedades deseadas, y el diseño se puede modificar de manera
iterativa hasta que el sistema cumpla con los criterios de diseño. Y este enfoque es válido, de hecho
es extremadamente válido y confiable en ingeniería. Y esto es muy, muy útil para problemas
relativamente sencillos que están bien definidos, como problemas técnicos de bajo nivel, o al menos
con problemas que hemos tenido muchas veces antes, y eso es lo que llamamos ingeniería.
Desafortunadamente, los problemas complicados que tienden a tener una cara bastante novedosa no
se pueden resolver con un enfoque ascendente.
2:18
En la ingeniería de sistemas, por lo tanto, comenzamos abordando el sistema como un todo, lo que
facilita la comprensión del sistema, su entorno y sus interfaces antes de especificar qué es
exactamente lo que hay dentro de los sistemas.
2:32
Comenzamos, por lo tanto, con requisitos de nivel de sistema. Una vez que los entendemos, el
sistema se divide en subsistemas, los subsistemas se dividen aún más en ensamblajes, y luego en
componentes, hasta que se logra una comprensión completa del sistema de arriba a abajo.
2:48
Este enfoque descendente es muy importante para gestionar el desarrollo de sistemas complicados.
Al ver el sistema como un todo inicialmente y luego irrumpiendo progresivamente en los elementos
cada vez más pequeños, la integración de esos componentes puede entenderse más a fondo, lo que
ayuda a identificarlos y diseñarlos como interfaces de usuario de los diversos elementos, sus
interfaces internas, y por supuesto, las interfaces entre el sistema y su entorno, las interfaces
externas. Ahora, quizás el mejor ejemplo de este enfoque descendente proviene de ANSI / EIA-632,
el estándar que brinda una perspectiva del producto.
3:26
Y este es un proceso de arriba hacia abajo desde 632. Tenga en cuenta que el sistema se
descompone en productos finales y productos habilitadores, todo lo que se necesita hacer para
producir los productos finales, y ya lo vimos antes.

Sin embargo, se puede considerar que el producto final comprende varios subsistemas, cada uno de
los cuales puede considerarse que comprende un producto final y un producto facilitador, y luego se
puede considerar que cada producto final comprende productos finales y productos habilitantes. Y
los precios pueden continuar hasta que se hayan desarrollado todas las hojas del árbol, con las hojas
del árbol están los paquetes de trabajo que se deben hacer para permitir que se construya el sistema.
Los paquetes de trabajo se asignan a equipos individuales o personas para que realmente lo hagan.
Por supuesto, la otra cara del diseño de arriba hacia abajo es la integración de abajo hacia arriba.
Podemos ver aquí otra representación de diseño de arriba hacia abajo en el lado izquierdo del
diagrama, el sistema se descompone de un sistema en subsistemas. Los subsistemas se
descomponen en ensamblajes, los ensamblajes se descomponen en componentes, y esto es
desarrollo. Sin embargo, en el lado derecho del diagrama, tenemos la otra cara del diseño de arriba
hacia abajo, que es la integración de abajo hacia arriba. Los componentes se construyen, prueban y
luego se integran en ensamblajes. Los conjuntos se prueban e integran en subsistemas, que luego se
prueban e integran en el sistema final. El sistema finalmente se prueba para las propiedades
deseadas del sistema, y así completó ese ciclo de desarrollo descendente e integración ascendente.
Ahora el desarrollo de una definición completa y precisa de los requisitos del sistema es
fundamental para el éxito del proyecto. Y es un enfoque principal de los primeros esfuerzos de
ingeniería de sistemas. Reconociendo, por supuesto, que una descripción completa no siempre es
posible y se requiere cierta iteración. El ciclo de vida que vimos comenzó con las necesidades del
negocio, que luego se tradujeron en un mayor número de declaraciones de requisitos que formaron
la base del diseño lógico, y posteriormente se han elaborado para formar el diseño físico. Ahora
estas transiciones de las necesidades y los requisitos del negocio, a las necesidades y requisitos de
los interesados, a los requisitos del sistema se gestionan a través de precios muy formales llamados
ingeniería de requisitos. Y este objetivo es garantizar que se hayan incluido todos los requisitos, lo
que significa que se excluyen los requisitos irrelevantes. También se enfoca en el hecho de que no
podemos arreglar los requisitos deficientes mediante un buen diseño. Por lo tanto, invariablemente
se deduce que los requisitos rigurosos de desarrollo son absolutamente esenciales para que la
adquisición sea exitosa. Una vez que se han recopilado los requisitos, el proceso de ingeniería de
sistemas se centra en derivar y descomponer estos requisitos, hasta el siguiente nivel. En un proceso
que veremos más adelante se llama, flujo de requisitos. Este proceso requiere elucidación, es decir,
identificar los requisitos. Análisis de esos requisitos. Definición, validación y luego gestión de los
requisitos. La ingeniería de requisitos garantiza que se adopte un enfoque riguroso, por lo tanto,
para la recopilación de un conjunto completo de requisitos inequívocos de los interesados para que
el desarrollo del sistema pueda comenzar.
1:38
Como parte de la ingeniería de requisitos, veremos que la rastreabilidad posterior de los requisitos
es esencial. Tenemos dos tipos de trazabilidad. Y ambas trazabilidades nos permiten rastrear las
decisiones de diseño desde cualquier nivel hasta cualquier otro nivel.
1:52
Las decisiones de diseño que se rastrean desde el nivel del sistema hasta la decisión de diseño
detallada, solicitamos la rastreabilidad. Y de manera similar, cualquier decisión de diseño individual
debe poder justificarse al estar asociada con al menos un requisito de nivel superior. Llamamos
trazabilidad hacia atrás. Ahora esta trazabilidad es importante, ya que el cliente debe estar seguro de
que todos sus requisitos se pueden rastrear en el diseño. Y además, cualquier parte del diseño que
no pueda rastrearse hasta un requisito de alto nivel, probablemente sea un trabajo innecesario. Algo
por lo que el cliente no está dispuesto a pagar.

La rastreabilidad también es compatible con el control de configuración. Si necesitamos cambiar un

requerimiento por cualquier motivo, podemos ver de dónde proviene ese requisito y cuál es el
impacto del cambio. El soporte para la rastreabilidad de requisitos es una característica del enfoque
descendente, y proporciona un mecanismo que puede garantizarse que los requisitos se puedan
satisfacer en cualquier etapa. Un enfoque ascendente no puede proporcionar la misma garantía.
2:52
La ingeniería del sistema mantiene un enfoque de ciclo de vida. Se enfoca en todo el ciclo de vida
del sistema, y toma todas estas consideraciones en cuenta durante cualquier proceso de toma de
decisiones. En el pasado, ha sido demasiado común considerar opciones de diseño solo en interés de
los problemas asociados con su adquisición. Y prestar poca atención a través de soporte en vivo.
3:14
Es correcto que los gerentes de proyecto y sus equipos se centren en la adquisición, ese es su rol. Y
queremos asegurarnos de cumplir con los requisitos de las partes interesadas, minimizando los
costos y el cronograma. Sin embargo, la falta de consideración de problemas de la vida entera a
menudo puede generar costos mayores a los esperados durante la utilización, que se satisfacen con
presupuestos que generalmente son inapropiados e insuficientes para mantener el sistema en
servicio.
3:37
Un enfoque de ciclo de vida requiere que nos centremos entonces en toda la capacidad a lo largo de
todo su ciclo de vida, no solo en el producto durante la adquisición.
3:47
El resultado es un enfoque en lo que se llama costos del ciclo de vida o costos totales de vida, y a
veces denominado costo de propiedad.
3:55
Como ejemplo muy simple, es una falsa economía comprar un automóvil más barato que tenga
costos de funcionamiento muy altos, particularmente si se puede adquirir un automóvil un poco más
caro con costos de funcionamiento mucho más bajos. Y, por lo tanto, los costos mucho más bajos
del ciclo de vida o un costo total de propiedad mucho más bajo.

También mencionamos que el enfoque de la ingeniería de sistemas es la optimización y el equilibrio

del sistema. Como discutimos en un módulo más liviano, no es necesario seguir la combinación de
subsistemas optimizados para un sistema optimizado. Por lo tanto, no es útil permitir que los
diseñadores de subsistemas optimicen su parte del sistema independientemente de las
consideraciones de nivel del sistema. Considere, por ejemplo, el impacto de incorporar un motor de
F1 en un automóvil familiar pequeño. El motor puede ser un gran motor y optimizado para el
rendimiento, pero destruirá el resto del tren de transmisión que se diseñó para un motor mucho
menos potente. Además, el motor F1 es capaz de propulsar el automóvil mucho más rápido de lo
que es seguro dada su suspensión y frenos actuales. Y es mucho más rápido, por supuesto, de lo que
permiten los límites de velocidad legales. Por lo tanto, se deduce que varios subsistemas pueden
necesitar localmente ser subóptimos, o al menos restringidos de alguna manera, para permitir que su
combinación, es decir, el sistema, sea óptima.
5:13
La ingeniería del sistema también reconoce que el sistema debe diseñarse teniendo en cuenta el
equilibrio. Por ejemplo, debemos equilibrar el rendimiento del sistema con otros factores, como los
efectos sociales, éticos, culturales y psicológicos, entre muchos otros.
5:26
De nuevo, la optimización y el equilibrio del sistema es un subproducto del enfoque descendente.
No pueden ser garantizados por métodos de abajo arriba.
5:36
La ingeniería de sistemas tiene como objetivo gestionar e integrar los
esfuerzos de una multitud de disciplinas técnicas y especialidades. Entonces,
el enfoque principal está en esa integración. Rara vez es posible, en estos días, que un sistema
complicado sea diseñado por una sola disciplina, considere nuestra aeronave. Tenemos ingenieros
aeronáuticos, que bien pueden tener un papel importante en el diseño del avión. Y, y participe en su
desarrollo y producción. Pero se requieren muchas otras disciplinas de ingeniería en electrónica,
electricidad, software, producción de seguridad, metalúrgica, control de la erosión y muchas otras.

Por supuesto, en términos de sistemas, se requieren otras disciplinas de ingeniería para las pruebas y
para el apoyo logístico y de mantenimiento, así como para el diseño y construcción de instalaciones
como pistas, hangares, instalaciones de reabastecimiento de combustible, instalaciones de embarque
y desembarque, etc.
6:28
Otras disciplinas no relacionadas con la ingeniería están involucradas, como marketing, finanzas,
contabilidad, legales y ambientales. En resumen, podría haber cientos, incluso miles de ingenieros y
miembros de otras disciplinas, involucrados en la entrega de un solo sistema de avión.
6:44
El objetivo de la ingeniería de sistemas es definir las tareas que
pueden completar estas disciplinas y especialidades dispares, y
luego proporcionar a la administración la integración de sus
esfuerzos para producir el sistema que satisfaga las necesidades
del usuario. En los desarrollos modernos del sistema, esta
función es aún más importante debido a la complejidad de los
proyectos, su tamaño, sus mecanismos de contratación y la
dispersión geográfica de los contratistas y el personal
subcontratista en todo el país y, de hecho, en todo el mundo.
7:12
Y finalmente, gestión. La ingeniería del sistema claramente tiene un papel técnico muy importante y
proporciona las metodologías esenciales para el desarrollo del sistema. Pero no se limita solo a
problemas técnicos. Y no se trata de un proceso de ingeniería de sistemas simplemente otro. La
ingeniería del sistema tiene una función administrativa y técnica. Ahora la administración de
proyectos es responsable de garantizar que los sistemas se entreguen a tiempo, y dentro del
presupuesto, satisfaciendo las expectativas del cliente. Las compensaciones y los compromisos
implícitos en esas funciones están informados por la ingeniería de sistemas.
7:44
Además, el alcance del proyecto está definido por la estructura de desglose del trabajo, que es
predominantemente el resultado de ingeniería de sistemas e ingeniería de requisitos. De modo que
la ingeniería de sistemas, la ingeniería de requisitos y la gestión de proyectos están
inextricablemente vinculadas.

Relevancia y beneficios de la Ingeniería de

Sistemas:
Los principios y procesos de ingeniería del sistema son aplicables, aunque, en diversos
grados, a una amplia gama de proyectos. Por ejemplo, ANSI / EIA-632. Establece que la
norma en sí misma es aplicable a la ingeniería o la reingeniería de sistemas comerciales o
no comerciales o parte de los mismos. Cualquier sistema pequeño, grande, simple,
complejo, intensivo en software, precedente, sin precedentes. Sistemas que comprenden
hardware, software, firmware, instalaciones de personal, etc. Nuevos sistemas y sistemas
heredados. En realidad es bastante difícil imaginar el sistema que no encaja en ese tipo de
descripción. En otras palabras, la ingeniería de sistemas se aplica a todos los sistemas.
0:55
Sin embargo, la ingeniería de sistemas de pozo puede aplicarse a todos los sistemas.
Tenemos que ser muy cuidadosos sobre cómo se aplica. Seguramente no podemos hacer
exactamente las mismas cosas en proyectos grandes y complicados, como lo haríamos en
proyectos muy simples y pequeños. De lo contrario, llevaríamos demasiado tiempo y
gastaríamos demasiado, además de asumir muchos riesgos innecesarios haciendo cosas que
simplemente no son necesarias. Entonces, claramente, se aplican diferentes niveles de
ingeniería de sistemas a cada uno de estos tipos de proyectos. Y los problemas y las
actividades que consideramos deben adaptarse a cada proyecto individual.
1:28
Por lo tanto, es fundamental que entendamos los méritos de la ingeniería de sistemas y los
apliquemos de forma personalizada, conscientes del tamaño relativo, la complejidad y el
riesgo asociados con el desarrollo del sistema. Y volveremos más tarde y hablaremos más
sobre la sastrería en ingeniería de sistemas.
Ahora primero debemos observar la ingeniería del sistema como relevante para todas las
partes, así como para todos los sistemas, y es particularmente relevante tanto para el cliente
como para el proveedor.
1:54
El cliente utiliza la ingeniería del sistema para definir los requisitos empresariales, de las
partes interesadas y del sistema, así como para supervisar el progreso y el riesgo del
contratista. Los contratistas utilizan la ingeniería de sistemas para desarrollar procesos
efectivos para el diseño, desarrollo y prueba de sistemas. Por lo tanto, ambas partes buscan
producir sistemas de calidad, al tiempo que minimizan su exposición al riesgo. Y esto es
con lo que la ingeniería de sistemas puede ayudarlos.
2:20
Para ser específico, hay una serie de beneficios que provienen de aplicar procesos correctos
de ingeniería de sistemas. Primero, hay un ahorro en costos de ciclo grandes y vimos
aquellos antes. Hay una reducción en el horario general. Hay una reducción en el riesgo y
produce un sistema de mayor calidad.
2:40
Veamos cada uno de ellos con más detalle. El primer y más obvio beneficio es lograr un
ahorro de dinero durante todas las fases del ciclo de vida del sistema. Y llamamos a esos
ahorros de costos del ciclo de vida. Mientras que algunos pueden argumentar que los
recursos adicionales y los requisitos impuestos por la ingeniería del sistema pueden
aumentar el costo, estos aumentos son comparativamente pequeños. Y generalmente se
sienten en las primeras fases de diseño. Si se aplica de manera adecuada, la ingeniería del
sistema puede garantizar que los ahorros logrados superen con creces el costo de
implementar cualquier cantidad pequeña de procedimientos y metodologías adicionales. La
experiencia indica que un énfasis inicial en la ingeniería de sistemas puede resultar en un
ahorro de costos significativo más adelante en las fases de construcción y producción, en el
uso operativo en el soporte del sistema e incluso en la eliminación del sistema.
Ahora la figura aquí proporciona una ilustración simplista del impacto de la ingeniería de
sistemas en el ciclo de vida del sistema. Esta curva muestra que la ingeniería de sistemas
tiene su mayor impacto, a través de las aplicaciones rigurosas de procesos y metodologías
durante las primeras etapas de un proyecto. Donde es fácil cambiar y es barato modificarlo.
3:46
De hecho, la curva en la figura ha sido etiquetada como la facilidad con la que se pueden
hacer cambios a lo largo del ciclo de vida del sistema. Ahora, en la segunda curva de la
figura, se puede ver que el mayor impacto de la ingeniería de requisitos se produce al
momento, cuando el costo de implementar los cambios es más bajo. Es decir, cuanto antes
detectemos y corrijamos errores, más fácil será corregirlos.
4:07
En consecuencia, la ingeniería de sistemas brinda la oportunidad ideal para tener el mayor
impacto en un proyecto, en un momento en que los cambios son más fáciles y menos
costosos de realizar.
4:20
Por lo tanto, tiene sentido que la ingeniería del sistema conduzca a la reducción de los
riesgos técnicos asociados con el sistema.
4:25
Los riesgos se identifican tempranamente y se monitorean durante todo el ciclo de vida.
4:29
Incluso al principio del proceso, se centran en el análisis de viabilidad, que elige el riesgo
para el proyecto.
4:35
A través de la ingeniería de sistemas, las decisiones de diseño se remontan a los requisitos
del usuario original, y los requisitos conflictivos del usuario se pueden identificar y aclarar
antes. Reduce significativamente el riesgo de falla, más adelante en el proyecto.
4:48
El riesgo técnico es monitoreado y evaluado continuamente, a través de medidas de
desempeño técnico y diseño y revisiones y auditorías, a lo largo del desarrollo del sistema.
Finalmente, y probablemente, lo más importante. El enfoque disciplinado de la ingeniería de
sistemas conduce a un producto que hace que el propósito original previsto sea más completo. Aquí
usamos la palabra calidad, para referirnos a la idoneidad para el propósito o a la capacidad del
sistema para servir a su propósito previsto o su misión prevista. En otras palabras, este rendimiento
mejorado, conduce a un sistema de calidad donde la calidad se mide por la capacidad del sistema
para cumplir con las necesidades y requisitos documentados.

Las discusiones sobre ingeniería de sistemas se vuelven muy complicadas debido al

mandato muy amplio de la disciplina. La amplia gama de tipos de sistemas involucrados, la
complejidad y la interrelación de muchas actividades de ingeniería y las relaciones con
otras disciplinas a lo largo de todo el ciclo de vida del sistema, sin mencionar la experiencia
y los antecedentes de las personas que están discutiendo.
0:21
La capacidad de comprender un tema complejo como la ingeniería de sistemas se ve
reforzada en gran medida por un marco sólido dentro del cual se pueden considerar los
conceptos. Hay una serie de excelentes sistemas de estándares de ingeniería disponibles en
la actualidad, que contribuyen a los elementos de un marco adecuado. Pero cada estándar
contiene complejidad, terminología y detalles que requieren interpretación.
El nivel de entrada para muchos estudiantes para ingenieros subalternos y para gerentes de
proyectos, por lo tanto, no permite el uso de tales estándares como marcos efectivos para
examinar la ingeniería de sistemas. Para el resto de este curso utilizamos el marco simple
que muestra tres elementos principales de la ingeniería de sistemas, los procesos que son el
elemento de hacer, la gestión del elemento de control y las herramientas que soportan tanto
la administración como los procesos.
1:09
Estos elementos se colocan dentro del contexto de un cuarto elemento llamado disciplinas
relacionadas.
1:16
Los procesos y tareas de ingeniería del sistema se dividen en las etapas del ciclo de vida
dentro de las cuales ocurren típicamente. En este curso no intentamos detallar,
exhaustivamente, todos los procesos de ingeniería del sistema, sino que nos concentramos
en la intención y el objetivo principal de cada fase, dentro del ciclo de vida del sistema, y
examinamos algunas de las técnicas probables que pueden usarse para llegar a ese objetivo
Ponemos especial énfasis en la fase de adquisición del ciclo de vida, ya que es la fase
durante la cual, la ingeniería del sistema tiene la capacidad de tener el mayor impacto en el
sistema.
1:49
La administración de ingeniería de sistemas es una actividad global, responsable de dirigir
el esfuerzo de ingeniería de sistemas, monitorear e informar ese esfuerzo a las áreas
apropiadas, y revisar y auditar el esfuerzo en las etapas críticas de todo el proceso. Más
adelante en el curso, abordaremos brevemente los principales elementos de ingeniería de
sistemas de revisiones técnicas y auditorías, prueba y evaluación del sistema, gestión de
riesgos técnicos y configuración, el uso de especificaciones y estándares, gestión de
integración y gestión y planificación de ingeniería de sistemas. La posición preeminente de
la administración de ingeniería de sistemas en nuestro marco ilustra que es la clave de todo
el esfuerzo de ingeniería del sistema. X
Ahora existen muchas herramientas para ayudar a los sistemas durante los procesos y la administración. Estas
herramientas van desde técnicas y métodos hasta estándares de ingeniería de sistemas. Aquí
describimos las herramientas y estándares más populares sin repetir la información que
podría estar contenida en otra parte.
2:43
A lo largo del curso presentamos herramientas de proceso genéricas, como la estructura de
desglose de requisitos, el RBS, diagramas de bloques de flujo funcional, FFBD, estructuras
de desglose del trabajo, WBS, análisis de compromiso y creación de prototipos y
simulación, como ejemplos de herramientas que se pueden aplicar al esfuerzo de ingeniería
del sistema para procesos. También describimos las herramientas de administración de
ingeniería de sistemas de estándares y modelos de madurez de capacidades.
3:11
Ahora hay muchas disciplinas, tanto técnicas como no técnicas, relacionadas con la
ingeniería de sistemas. Tales como, gestión de proyectos, gestión logística, garantía de
calidad, ingeniería de requisitos, ingeniería de hardware, ingeniería de software, etc.
3:25
La relación entre las disciplinas relacionadas y las otras facetas de la ingeniería de sistemas
depende en gran medida de la disciplina en cuestión. Algunos, como la gestión de
proyectos, supervisan toda la disciplina de ingeniería del sistema. Mientras que otros, como
la ingeniería de hardware y software, se sientan entre la administración de ingeniería de
sistemas y los procesos. Y otros, como la garantía de calidad, se sientan al lado del esfuerzo
de ingeniería del sistema.
3:49
Discutimos estas disciplinas y su relación con la ingeniería de sistemas al final del curso.
3:56
Todas las normas y prácticas de ingeniería de sistemas de extensión instalan procesos que
se construyeron en torno a una aplicación iterativa de análisis, síntesis y evaluación. La
naturaleza iterativa de la aplicación es crítica para los procesos de ingeniería de sistemas.
Inicialmente, el ciclo de evaluación de la síntesis del análisis se aplica a nivel del sistema y
luego se vuelve a aplicar al nivel del subsistema, luego al nivel de ensamblaje y así
sucesivamente hasta que se completa el proceso completo.
4:21
Durante las primeras etapas, el cliente está muy involucrado, hacia el final, el contratista es
el principal responsable, supervisado por el cliente.
Antes del detalle y de las actividades individuales dentro de los procesos de ingeniería
del sistema, vale la pena considerar por un breve momento las bases básicas que
proporciona el ciclo de evaluación de síntesis del análisis. El concepto no es complejo,
es simplemente un buen enfoque de solución de problemas aplicable en cualquier
dominio, pero particularmente fundamental para la ingeniería de sistemas.
4:50
Durante el diseño conceptual, el análisis investiga las necesidades del negocio y las
partes interesadas, e identifica los requisitos esenciales del sistema, a fin de satisfacer
esas necesidades. El análisis a nivel del sistema tiene como objetivo responder a las
preguntas sobre qué, qué bien y por qué, que están relacionadas con el diseño del
sistema.
5:07
Las actividades de análisis continúan a lo largo del ciclo de vida subsiguiente, para
ayudar a definir los requisitos de bajo nivel asociados con los aspectos físicos, los
cómos del sistema.
5:17
Ahora, dependiendo de la fase de diseño particular, estos requisitos se pueden agrupar de
acuerdo con algunos criterios lógicos que los hacen más fáciles de administrar. Y luego se
asigna a un componente físico particular, es decir, el componente se vuelve responsable de
satisfacer las funciones que le han sido asignadas. La asignación de requisitos forma una
descripción de los elementos del sistema y, por lo tanto, ayuda en el proceso de síntesis o
diseño, es decir, respondiendo las preguntas sobre cómo.
5:46
Entonces, una vez que la actividad de análisis resuelve lo que se requiere, así como también
qué tan bien y por qué, la síntesis o el diseño determinan cómo. La síntesis es el proceso
donde la creatividad y la tecnología se combinan para reducir el diseño que mejor se ajusta
al estado y los requisitos del sistema. El término síntesis es más apropiado que el diseño en
el contexto de la ingeniería del sistema, ya que insinúa la naturaleza evolutiva del diseño y
desarrollo.
6:11
Entonces el análisis nos ha dicho qué hará el sistema y qué tan bien lo hará. Síntesis
propone cómo lograr esto. Y la síntesis, por supuesto, es probablemente el rol más
ampliamente reconocido de un ingeniero profesional.
En el proceso inicial de ingeniería del sistema, la síntesis se limita a definir el diseño lógico
del sistema y luego considerar todos los enfoques técnicos. A partir de esta consideración,
se selecciona el mejor enfoque, y el proceso pasa luego al siguiente nivel de detalle. Más
adelante en los procesos de ingeniería del sistema, el concepto de diseño seleccionado se
sintetiza aún más, hasta que finaliza un diseño completo. Entonces, después de completar el
análisis y luego la síntesis, tenemos algunos diseños de candidatos.
6:52
La evaluación es el proceso de investigar las compensaciones entre esos diseños. En el
primer momento es la evaluación entre los requisitos y el diseño, las alternativas de diseño
y tomar las decisiones necesarias. Pero ese proceso continúa en todas las etapas del
esfuerzo de ingeniería de sistemas, en última instancia, determina si el sistema satisface los
requisitos originales. Entonces, el análisis de intercambio es una de las herramientas
disponibles para el diseñador del sistema, al realizar la evaluación de requisitos o diseños
en competencia. Discutimos el análisis de trade off con más detalle más adelante.
7:24
El resultado de la evaluación es una selección o confirmación del enfoque deseado para el
diseño. Las discrepancias también se identifican si son aplicables y pueden dar como
resultado un análisis y una síntesis adicionales a medida que se cierra el ciclo de análisis-
síntesis-evaluación.
7:40
Entonces, seguramente, el ciclo análisis-síntesis-evaluación se puede aplicar a todas las
actividades del ciclo de vida. Esta figura resume eso mostrándote de una manera visual,
cómo se puede aplicar iterativamente a cada una de esas actividades.

NECESIDADES Y REQUISITOS DE INGENIERIA DE SISTEMAS:

En los dos últimos módulos, presentamos los sistemas, el ciclo de vida del sistema y la
ingeniería de sistemas. Mirando en particular, la relevancia y los beneficios de la ingeniería
de sistemas.
0:11
Antes de continuar con las diversas actividades involucradas, en próximos módulos, en este
módulo analizaremos las necesidades y los requisitos. También consideraremos cómo
desarrollamos el conjunto de requisitos. Y llamamos a ese proceso, ingeniería de requisitos.
0:26
Al describir el sistema, debemos hacer la distinción entre necesidades y requisitos. Las
necesidades generalmente son capacidades, expresadas en el lenguaje de la administración
comercial o partes interesadas en los niveles de operaciones comerciales. Requisitos de
declaraciones formales que están estructuradas y pueden validarse. Puede haber más de un
requisito, que se puede definir a través de cualquier necesidad.
0:47
Los requisitos se generan a partir de las necesidades, a través de un proceso de análisis de
requisitos que también se denomina análisis de negocios o análisis de misiones en los
niveles superiores.
0:56
Las necesidades y los requisitos existen, en varios niveles. En primer lugar, existe una
visión empresarial, en la cual el liderazgo de la empresa establece las estrategias y los
conceptos de operaciones de la empresa. Luego hay una vista de administración de
negocios, en la cual la administración de negocios deriva las necesidades y limitaciones del
negocio, y formaliza sus requisitos. Hay una vista de operaciones comerciales, en la que los
interesados definen sus necesidades y requisitos, y luego una vista del sistema, en la que el
sistema se define en términos lógicos y físicos. Posteriormente, por supuesto, hay vistas en
el nivel inferior del subsistema y otros elementos del sistema. Pero nos enfocaremos en los
niveles superiores.
Como se ilustra aquí, las vistas de empresa, administración comercial y operación
comercial están en el dominio del problema. El sistema y el subsistema y las vistas
inferiores están en el dominio de la solución.
1:44
Como vimos en módulos anteriores, generalmente se considera que el dominio del
problema es responsabilidad de quienes tienen la propiedad del problema que se va a
resolver. Por lo tanto, las descripciones del sistema se basan principalmente en el lenguaje
de la administración comercial y las operaciones comerciales del cliente. Centrándose en lo
que el sistema debe poder hacer, qué tan bien debe hacerse y por qué. Y vimos que
llamamos a estas descripciones, las descripciones lógicas o funcionales.
2:09
Ahora, por otro lado, el dominio de solución, a menudo
se considera responsabilidad de quienes implementan el
sistema. Entonces, las descripciones de los sistemas en ese dominio, son
principalmente en ingeniería y en términos físicos, centrándose en cómo se debe resolver el
problema. Es decir, cómo se verá, una vez que se haya implementado. Y entonces estas
descripciones laterales, llamamos descripciones físicas.
2:30
Al más alto nivel, la empresa tiene una serie de estrategias que guiarán el futuro de la
empresa. Desde nuestra perspectiva, nuestro sistema tiene su génesis en lo que se
llama el concepto de operaciones o las operaciones. Que comunica las intenciones de
los líderes, con respecto al funcionamiento de la organización, en términos de cómo va
a utilizar los sistemas existentes y los sistemas que se desarrollarán, uno de los cuales
será el nuestro.
2:54
Las necesidades y requisitos del negocio. El proceso de definición de B & R comienza con
la visión, las metas y los objetivos de la organización comunicados por ConOps. La
administración comercial luego usa esta guía para definir las necesidades del negocio. Y en
gran medida esas necesidades comerciales son capturadas, en una serie de documentos
llamados documentos conceptuales preliminares del ciclo de vida, o el PLCD, y capturan
las primeras versiones del concepto de adquisición, el concepto operacional, llamado
OpsCon, el concepto de implementación, el soporte concepto, y el concepto de jubilación.
Primero, sin embargo, las necesidades comerciales que están contenidas en estos
documentos preliminares se elaboran y formalizan en requisitos comerciales. Y están
documentados entonces, en la especificación de requisitos comerciales, el BRS. Lo que a
veces se denomina documento de requisitos comerciales o BRD.
5:10
El proceso mediante el cual las necesidades del negocio se transforman, desde las
necesidades hasta los requerimientos del negocio, se denomina análisis de misión o análisis
comercial. Una vez que la administración comercial está convencida de que sus
necesidades y requisitos están razonablemente completos, los transfiere al nivel de
operaciones comerciales. Aquí, las necesidades y requisitos de las partes interesadas, el
proceso de definición de SNR, usa el ConOps y otro PLCD como orientación. Los
ingenieros de requisitos lideran a las partes interesadas desde el nivel de operaciones
comerciales, a través de un proceso estructurado para obtener las necesidades de las partes
interesadas, y normalmente se trata de versiones refinadas de OpsCon y de los demás
documentos conceptuales del ciclo de vida. Las necesidades de las partes interesadas se
transforman una vez más formalmente, en un conjunto de requisitos llamados requisitos de
las partes interesadas. Y están documentados, en la especificación de requisitos de las
partes interesadas, los STRS. Y esa transformación, es el proceso formal de análisis de
requisitos.
6:03
A nivel del sistema, en el proceso de definición de requisitos del sistema, los requisitos en
el STRS son transformados por los ingenieros de requisitos, en los requisitos del sistema,
que luego se documentan, en la especificación de requisitos del sistema DSYRS. También
tiene otros nombres, a menudo se lo denomina documento de especificación de requisitos
de solución o, lo más común, probablemente, simplemente la especificación del sistema o
la especificación del sistema. Tenga en cuenta que la figura aquí ilustra que un número de
SYRS puede derivarse de STRS. Y luego, cómo esperar una descripción antes de eso,
puede haber varios sistemas desarrollados como parte de un sistema de mayor capacidad.
También tenga en cuenta que algunas organizaciones pueden preparar documentos
individuales del ciclo de vida, para cada uno de una serie de sistemas, que se desarrollan
para satisfacer las necesidades del negocio.
6:50
El proceso continúa, desde el sistema hasta los elementos del sistema. Como vimos
anteriormente, los requisitos ahora son requisitos físicos, ya que se relacionan con los
elementos del sistema, más que con el sistema en sí.

Por lo tanto, hemos hablado sobre los nombres en los requisitos y sobre cómo utilizamos el
análisis de negocios y el análisis de requisitos para traducir esas necesidades y requisitos en
varios niveles. Ahora, veamos el proceso que se relaciona con esa traducción con un poco
más de detalle. Pero primero, comenzaremos con algunas definiciones que nos ayudarán.
0:20
Lo primero que tenemos que reconocer es que el término como sistema y elemento del
sistema realmente es específico del nivel. Entonces, necesitamos un término que pueda
aplicarse a cualquier nivel o a cualquier cosa en cualquiera de esos niveles. Entonces,
primero definimos una entidad como una sola cosa a la que se refiere una necesidad o un
requisito. Y eso podría ser una empresa, una unidad de negocio, un sistema o un elemento
del sistema y podría ser un producto, un proceso, un humano o una organización.
0:49
Esa entidad tiene una necesidad. Y entonces hablamos de una necesidad como resultado de
una transformación formal de uno o más de los conceptos de los que hablamos para una
entidad en alguna forma de expectativa acordada para que la entidad realice alguna función
o posea alguna cualidad. Y, por supuesto, eso siempre está dentro de algunas limitaciones
especificadas.
1:13
Entonces, ¿qué es un requisito? Mientras que un requisito es el resultado de una
transformación formal de una o más necesidades en una obligación acordada para que una
entidad realice alguna función o posea alguna calidad y nuevamente, dentro de algunas
limitaciones especificadas.
1:30
Ahora es común en la ingeniería de sistemas referirse a dos categorías principales de
requisitos. El primero es un requisito funcional, y como su nombre lo indica, significa
una función, algo que el sistema debería hacer, o algo que debería proporcionar. Los
tipos restantes de requisitos generalmente se llaman requisitos no funcionales. Y son
amplios y variados, pero se refieren a las propiedades, cualidades o atributos que el sistema
debe poseer, por lo que algunos de color, por ejemplo, o alguna forma. También podría
referirse a alguna condición que el sistema debe cumplir, o alguna restricción bajo la cual
debe operar o de hecho desarrollarse.

Un tipo de requisito que comúnmente se incluye como un requisito no funcional se

denomina restricción. Y algunas personas incluso separan las restricciones, por lo que dicen
que hay restricciones finales funcionales no funcionales. Pero es común aquí, lo
incluiremos como uno de los requisitos no funcionales. De cualquier manera, una
restricción es alguna restricción o algún límite. Algo bajo lo cual el sistema debería operar
o algo que restringe la forma en que se desarrollará el sistema. Como dije, las restricciones
se enumeran más comúnmente en la categoría de requisitos no funcionales, pero algunas
personas y algunas empresas las enumeran por separado.
2:44
Cada declaración de requisito no se escribe de forma aislada, sino que debe ser respaldada
por otras declaraciones. En primer lugar, existen declaraciones de rendimiento,
declaraciones de verificación y declaraciones de justificación que respaldan cada uno de los
requisitos. Y veremos cada uno de ellos con un poco más de detalle en breve. También
debemos incluir definiciones de otros sistemas con los que el sistema debe integrarse o con
los que debe interactuar. Y esto es lo que llamamos más tarde en las interfaces externas.
También podríamos proporcionar información sobre el dominio de la aplicación dentro del
cual el sistema debe operar, o incluso sobre el propio sistema, ya que opera dentro de ese
dominio. Ahora los requisitos en la especificación de requisitos de negocio y la
especificación de requisitos de partes interesadas no son tan formales como los de la
especificación de requisitos del sistema, pero sí tienen la misma estructura y siguen las
mismas reglas.
3:34
Por lo tanto, veamos con más detalle los requisitos de rendimiento, los requisitos de
verificación y las declaraciones de justificación. Primero, requisitos de rendimiento.
Después de haber decidido qué debe hacer el sistema, el diseñador ahora debe determinar
qué tan bien debe cumplir cada uno de esos requisitos funcionales. Es una buena disciplina
garantizar que cada vez que redactemos un requisito funcional, se realice al menos una
declaración de rendimiento correspondiente. Ahora, la mayoría de las funciones operativas
tendrán un parámetro de rendimiento obvio asociado a ellas. Por ejemplo, velocidad,
precisión, resistencia, aceleración, etc.

Aunque hemos agregado un requisito de rendimiento a nuestro requisito de función, la

definición aún no está completa hasta que hayamos agregado el requisito de verificación.
Por lo tanto, cada vez que articulemos con una declaración de rendimiento apropiada, es
una buena práctica agregar una declaración de verificación correspondiente. Es decir, cómo
es que sabremos que el sistema cumple con la función y cumple con el rendimiento.
4:34
Ahora, a menudo es difícil escribir declaraciones de verificación para las funciones de nivel
del sistema, pero la disciplina de hacerlo es muy importante, ya que no tiene sentido
continuar estableciendo una función sin entender cómo vamos a probarla.
4:48
Un beneficio adicional al escribir estas afirmaciones en este nivel es que nuestros planes de
prueba se vuelven mucho más fáciles de escribir más tarde porque a medida que escribimos
cada función, comenzamos a considerar la prueba que podría estar asociada a ella en
cualquiera de los niveles. Y eso significa que nuestro régimen de prueba donde los planos y
procedimientos de prueba comienzan a desarrollarse a medida que desarrollamos el
rendimiento funcional y la verificación de la arquitectura a medida que avanzamos en el
árbol de requisitos.
5:17
La tercera declaración para agregar a una declaración de requisitos en el conjunto de lo que
llamamos la expresión de requisitos, es la razón fundamental. Ahora, la razón es muy
importante porque articula la razón por la cual existe el requisito. El razonamiento podría
registrar la decisión de diseño que conduce al requisito. Podría registrar las suposiciones
detrás del requisito o algo tan simple como la lógica de por qué se eligió ese número o por
qué, por ejemplo, se eligió un número con dos decimales o por qué se redondeó para ser un
número entero. Cualquier cosa que realmente proporcione alguna orientación a los
diseñadores de nivel inferior es una razón de ser muy útil, por lo que entienden por qué se
solicita el requisito en primer lugar. Un requisito no debería aceptarse realmente hasta que
se comprenda bien el razonamiento, en gran parte porque si no podemos explicar la razón,
probablemente no deberíamos incluir el requisito.

Ahora, además de que las categorías generales son funcionales y no funcionales, hay
muchos otros adjetivos utilizados para describir la naturaleza de un requisito. Por lo tanto, a
menudo escuchará referencias a cosas como requisitos operativos, requisitos de partes
interesadas, requisitos ambientales, requisitos de interfaz, requisitos del sistema, requisitos
normativos, requisitos de seguridad, requisitos de diseño y muchas más categorías. En gran
parte, sin embargo, estas son simplemente formas en que podemos agruparlos para que
podamos hacer un uso razonable de ellos.
6:37
En general, es cierto particularmente en el nivel del sistema, ese requisito debe ser una
declaración de lo que no, es decir, debería decir lo que el sistema debería hacer. En lugar de
cómo debería hacerlo y forzar cualquier diseño en particular en un diseñador de nivel
inferior.
6:50
Sin embargo, esto a menudo es demasiado simplista en la práctica porque puede ser
esencial que el sistema haga algo particular de una manera particular, para que sea
interoperable, por ejemplo, con otro sistema o para cumplir con algún estándar particular.
7:04
Además, una afirmación particular se confunde mucho menos fácilmente que una
afirmación abstracta. Entonces, si es lo que quieren los diseñadores de nivel superior,
deberían decirlo y eliminar cualquier ambigüedad.

Eso también es cierto porque los especificadores del sistema suelen ser los expertos en el
dominio. Por lo tanto, es probable que estén en mejor posición para indicar cómo debe
desarrollarse el sistema y cómo debería funcionar, en lugar de dejarlo en manos de los
diseñadores más jóvenes. Entonces, hemos hablado sobre las necesidades y los requisitos.
Bueno, ¿por qué los necesitamos realmente? Bueno, debería ser obvio por ahora, pero hay
varias razones muy importantes. Primero, necesitamos que puedan definir el alcance del
proyecto. Si no los tenemos, ¿de qué otro modo podríamos saber qué haría el sistema?
Entonces, debemos asegurarnos de que todos los involucrados hayan tenido su opinión y
que todos los puntos de vista se hayan reconciliado. La única forma de hacerlo es agrupar
todos los requisitos en un conjunto equilibrado de requisitos. También necesitamos poder
justificar cualquier gasto de fondos o cualquier esfuerzo de la organización para satisfacer
la necesidad en términos de poder cumplir con ese conjunto endosado de requisitos. Y
luego, por supuesto, mientras hacemos nuestro trabajo, debemos poder informar nuestro
progreso. ¿Cómo sabemos qué tan lejos estamos del proyecto? Necesitamos informarnos
sobre el centro de los requisitos, y finalmente, por supuesto, queremos saber si hemos
terminado hasta que podamos eliminar cada uno de los requisitos. Entonces, en general,
necesitamos requisitos para poder describir el proyecto, pero también para ayudarnos a
administrar el proyecto.
8:26
Veamos ahora algunas definiciones principales. Ya usamos algunos de estos términos en un
sentido general, pero antes de hacerlo, vamos a definirlos un poco más precisamente.
8:35
Un usuario es alguien que está involucrado en el uso del sistema una vez que ha sido
desarrollado. Estrictamente hablando, los usuarios son parte del sistema. Son, son parte de
los otros elementos del sistema, como materiales, instalaciones, datos, software, hardware,
etc. Y debido a que son parte del sistema, a los usuarios a veces se les llama actores. Es
decir, juegan un papel como parte del desarrollo de la funcionalidad del sistema. Entonces
los usuarios incluirán operadores, mantenedores, etc.
9:02
Ahora, los usuarios trabajan para el cliente. El cliente es la organización que está pagando
por el desarrollo del sistema. Dentro del cliente, hay un adquirente, que es la entidad que
está adquiriendo el sistema. Debido a que los usuarios normalmente están demasiado
ocupados con sus tareas operativas, no tienen el tiempo, o necesariamente tienen la
experiencia para adquirir nuevos sistemas. Las grandes organizaciones de clientes, por lo
tanto, muy probablemente tengan una organización de adquisición separada que esté
separada de la organización usuaria.

Y como dijimos antes, es probable que el cliente no sea lo suficientemente grande como
para poder desarrollar el sistema por sí mismo, por lo que se relacionará con el
desarrollador. Ese desarrollador es la persona responsable de desarrollar los productos que
componen el sistema. Ese desarrollador podría ser interno, pero lo más probable es que
actualmente el desarrollador forme parte de una organización de contratistas. Y el
contratista es la organización dentro del cual se desarrolla el desarrollo y como dijimos
antes normalmente, por lo tanto, bajo contrato con el cliente para hacer el desarrollo.
9:59
También mencionamos la parte interesada y una parte interesada es cualquiera que tenga el
derecho de influir en los requisitos. A veces se llama genéricamente a cualquiera que se ve
afectado por el sistema.
10:09
Los usuarios son invariablemente partes interesadas, pero otras partes interesadas pueden
incluir la gestión, los clientes, el público, etc.
10:17
Entonces, hemos discutido las necesidades y los requisitos. Pasemos ahora a la idea de
ingeniería de requisitos. Si bien hemos hablado sobre las necesidades y los requisitos y los
distintos niveles a los que se exponen, de paso, podríamos hacer referencia al análisis de
requisitos, que es realmente parte de una imagen más amplia llamada ingeniería de
requisitos. Como se ilustra aquí, la ingeniería de requisitos es el proceso formal a través
del cual pasamos de las estrategias empresariales a los requisitos del sistema. En
primer lugar, traduciendo formalmente las necesidades comerciales en requisitos
comerciales a las necesidades y requisitos de las partes interesadas y luego, en los
requisitos del sistema.
10:53
También vimos antes por qué necesitamos requisitos. Bueno, ¿por qué necesitamos
ingeniería de requisitos? Obviamente, si tenemos que ser capaces de movernos a sabiendas
entre los conjuntos de requisitos, necesitamos un proceso formal para poder hacerlo.
Necesitamos poder garantizar que tenemos un conjunto completo de requisitos que no es
ambiguo, que es completo, que no es conflictivo, y así sucesivamente.
Necesitamos poder cambiar la funcionalidad por el costo, lo que implica que entendemos
todas las cosas que debemos hacer, más sus prioridades más sus costos, etc. Y finalmente,
las cosas cambiarán. Por lo tanto, a través de la ingeniería de requisitos, debemos ser
capaces de gestionar los cambios en los requisitos por una amplia variedad de razones.

Antes de dejar los requisitos, es común considerar dos aspectos adicionales de los requisitos
y la ingeniería de requisitos. En primer lugar, hay ciertas características que deseamos a
partir de un requisito bien formado, un buen requisito que decimos. Y segundo, a menudo
volcamos a la declaración de requisitos uno o más atributos. Y el propósito de hacer eso es
usar esos atributos para ayudarnos a administrar la declaración de requisitos en sí misma, y
el conjunto de esas declaraciones de requisitos. Pero primero veamos las características de
un requisito bien formado antes de volver a considerar sus atributos.

Deseablemente, para ser útil, cada declaración de requisito debe exhibir todas las
características siguientes. Y el primero es, ser necesario. Ahora, por supuesto, parece ser
una afirmación bastante obvia que el requisito debe ser necesario; de lo contrario, no lo
habríamos incluido. Pero es una buena prueba para nosotros decir, bueno, ¿este requisito es
realmente necesario? Debe ser necesario si el sistema tiene que funcionar de la manera
deseada. De esto se desprende que el requisito que no es necesario no puede remontarse a
un requisito de nivel superior o, de hecho, puede remontarse a una necesidad más alta.
Entonces, simplemente agrego que la pequeña prueba simple es necesaria para este
requisito, nos permite entender si el requisito realmente debería estar allí o no. Y eso nos
ayuda con respecto a los instintos como el equipo de alcance. La siguiente característica es
Singular. Un requisito no puede ser una combinación de dos o más requisitos. Recuerde que
dijimos que un requisito es una obligación acordada, y para que una obligación sea justa,
tiene que ser singular. Tenemos que decir una cosa. También nos ayuda cuando lo estamos
probando, etcétera, para asegurarnos de que estamos hablando de una sola cosa. Por lo
tanto, es muy importante asegurarse de que los requisitos sean únicos. Simplemente se
aplican a una sola función, no a una combinación de funciones, y eso significa que el
requisito es conciso y está claro. Se sigue que el requisito también debería ser correcto. De
nuevo, que es correcto, como axiomático, tenemos que saberlo, pero esta es una pequeña
prueba. Decimos, ¿es este requisito correcto? ¿Estamos seguros de que es correcto?
¿Estamos todos seguros de que es correcto? Para asegurarnos de no mantener requisitos que
no son requisitos o requisitos reales que en realidad son engañosos. Y eso nos lleva a la
siguiente característica, los requisitos deben ser inequívocos. Es decir, todos los que lo lean
deberían entender lo mismo que han leído ese requisito. Ahora, eso es particularmente
difícil en idiomas como el inglés, donde una declaración puede tener un gran número de
significados y cada palabra tiene un número considerable de sinónimos. Por lo tanto, es
muy importante asegurarse de que cada lector futuro de este requisito comprenda
correctamente lo que se comunica el requisito. La siguiente característica es factible. Y
nuevamente, eso suena obvio.

Pero una pequeña prueba antes de continuar es si decimos eso, y queremos que el sistema
realice esa función, ¿es realmente factible? Es decir, ¿podemos hacerlo con las tecnologías
existentes? ¿Podemos hacerlo con los conjuntos de habilidades existentes? ¿Podemos
hacerlo con las capacidades de fabricación existentes? Y así. Y nuevamente, es solo que esa
pequeña prueba asegura que no vamos a escribir requisitos que al final no podrán ser
completados, fabricados o producidos. Además de esos, otras características incluyen, en
primer lugar, apropiadas para nivelar. Es decir, que el requisito puede ser incluso todas las
características anteriores, pero dicho en el nivel equivocado. Entonces realmente no
deberíamos estar hablando de funciones secundarias del sistema a nivel del sistema, por
ejemplo, porque es una declaración de nivel de sistema y estamos hablando del exterior. El
sistema como una caja negra, no el interior del sistema. Entonces, debemos ser muy
cuidadosos al decir solo aquellas cosas que son apropiadas para el nivel cuando estamos
hablando de una entidad en ese nivel.
3:33
La siguiente característica está completa. El requisito en sí, ahora este no es el conjunto de
requisitos, este es el requisito individual, debe completarse. Decimos en inglés que no
debería plantearse la cuestión de que no debería haber cosas que se planteen al leerlo.
Debería poder leer el requisito y saber exactamente lo que significa. Y es decir, no debería
necesitar ninguna otra explicación. Entonces el requisito debe ser conforme. Eso significa
que cada requisito debe ajustarse a una estructura formal estándar, probablemente según lo
descrito por la organización o quizás por algún estándar externo. Y eso significa que
cuando lo leemos, porque lo leemos siempre de la misma manera, en el mismo formato
estándar, significa, por supuesto, que los requisitos son por lo tanto menos ambiguos como
resultado.

Y por último, como dijimos, no hace mucho tiempo, los requisitos deben ser verificables.
Es decir, hemos escrito una declaración de verificación. Necesitamos saber cómo es que
proponemos probar que el sistema cumple o posee esto, esta propiedad que requiere este
requisito. La verificación podría ser de uno o varios medios. Pero vale la pena un tiempo
aquí antes de continuar. Es como ser factible. Si el requisito es factible, ¿cuál es el método
de verificación factible que lo acompaña, porque tenemos que pagar por la función?
También tenemos que pagar por el método de verificación, por lo que la persona que está
escribiendo la especificación del sistema debe saber cuáles son esas dos cosas. Qué es lo
que queremos y cómo es que proponemos saber que tenemos lo que queremos en el otro
extremo.

Además de las características de los requisitos, utilizamos atributos para respaldar el

análisis y la administración. Y así, un requisito podría ser asignado una serie de atributos.
De hecho, podría haber muchos de tales atributos, hasta un requerimiento a veces, hasta
unos 300. Aquí solo identificamos un pequeño número que serían los principales atributos.
Pero tiene la idea del tipo de cosas que una organización podría desear asociar a un
requisito para permitir que esa organización gestione ese requisito mejor durante la vida del
sistema. El primero, por supuesto, es el identificador único. Las palabras que son listas
generales y largas de palabras se vuelven difíciles de manejar. Por lo tanto, cada requisito
debe tener un número único aparte para identificar la declaración única. Y, por supuesto, ya
sabes, la base de datos de requisitos generalmente suele venir de forma gratuita, ya que se
le asigna una clave para la base de datos. Pero el punto es que, de cualquier forma que los
administremos, necesitamos un identificador único. Esa cantidad, por supuesto, tampoco es
terriblemente útil. Por lo tanto, es útil agregar al título un título corto. Y ese título corto
entonces, en tres palabras, cuatro palabras, simplemente resume el requisito. No es tan útil
como el requisito, obviamente, pero es útil referirse al requisito por su título corto en lugar
de leer un número que no parece tener sentido o leer la oración larga cada vez. Cada
requisito también debe tener una prioridad. Y eso es importante porque más adelante
hablaremos de la idea de espacio de diseño. Es decir que los diseñadores pueden cambiar el
peso por el rango, la velocidad de combustión, el espacio para las piernas, etc., en una
plataforma como una aeronave. Si no entendemos cuál es más importante para el cliente,
entonces es muy difícil usar ese espacio de diseño para diseñar el sistema. Entonces, la
prioridad es una forma que el creador del requerimiento comunica a los diseñadores, y cuán
importante es cada uno de esos aspectos para ellos. Ahora, no es obligatorio, pero también
es muy útil al escribir el requisito de adjuntar al requisito alguna indicación de riesgo.
Podría ser un nivel de riesgo o, en realidad, podría ser una declaración de riesgo en algunos
sistemas. Ahí es cuando el escritor del requisito lo articula, también tienen que pensar un
momento sobre qué riesgo se asocia a eso, y eso se remonta a lo que estábamos hablando
antes sobre la viabilidad del requisito, y, también, la capacidad para verificar.

Si necesitamos discutir el requisito en el futuro, es posible que tengamos que volver a la

fuente. Ahora podría ser un estándar, podría ser un reglamento. Pero también es
comúnmente, por supuesto, un individuo o una organización, o un comité, o un taller.
También proceso de molicitación que nos dio el requerimiento. Por lo tanto, necesitamos
saber de dónde vino en caso de que tengamos que volver para analizar si, por ejemplo, dos
requisitos entran en conflicto. Es posible que tengamos que volver a conciliar eso con las
fuentes originales. Otro atributo útil, como vimos antes, es un razonamiento. Algunas
personas escribirían una declaración racional. Otros pueden incluir una justificación en los
atributos. Dudo que realmente importe de ninguna manera, pero nuevamente es importante,
como dijimos antes, que registremos el motivo de la existencia del requisito. También es
posible que desee registrar algo de historia. Ahora, nuevamente, por supuesto, en una base
de datos relacional, la base de datos rastrea el historial generalmente, de modo que viene de
manera gratuita. Pero queremos saber, ¿cuándo se planteó este requisito? ¿Con qué
frecuencia ha sido cambiado? ¿Lo hemos eliminado? Entonces, ¿dónde están los viejos
requisitos que hemos eliminado? Entonces, la historia es realmente útil para ayudarnos a
entender cómo ha cambiado en el futuro. También nos gustaría saber, como vimos antes, y
hablaremos más tarde sobre la trazabilidad. ¿Cómo se relaciona este requisito con otros
requisitos? Y entonces esas relaciones deberían ser rastreadas también. De nuevo, podría
estar en los atributos o podría ser parte de la base de datos relacional en el sistema de
gestión de requisitos moderno.
Y, por supuesto, como dije antes, puede haber hasta 300 requisitos adjuntos, por lo que
podría incluirse mucha otra información como atributo de un requisito. Podemos indicar la
fecha de elevación, el estado, y actualmente se están revisando, se ha aceptado, se ha
rechazado, cualquier comentario que sea útil para los diseñadores posteriores es muy útil
para incluir. Y, por último, a menudo es útil agregar un atributo de tipo, por lo que los
requisitos pueden asentarse en varias agrupaciones lógicas que son útiles en su gestión. El
tipo puede ser de cualquier tipo realmente. Algunas organizaciones insisten en tener una
serie estructurada de tipos, de etiquetas que puedan adjuntarse. Otros permiten que el
campo tipo esté abierto para permitir que las personas agreguen cualquier cantidad de tipos.
Pero el valor del campo de tipo es poder registrar qué tipo de requisito es esto. Por lo tanto,
podría ser un requisito de seguridad, un requisito de seguridad, un requisito de capacitación,
etc. La idea es que recibimos pedidos mucho en bases de datos de requisitos. Entonces, si
alguien nos dice, entonces, ¿dónde están todos sus requisitos de seguridad? O bien, ¿dónde
se relacionan todos tus requisitos con el estándar xyz? Es muy útil poder usar el campo de
tipo en una base de datos, por decir, bueno, déjenme imprimir todos los requisitos de
seguridad. Y, por lo tanto, busque e imprima según el tipo de campo de seguridad, en lugar
de tener que examinar y ver qué requisitos se relacionan con la seguridad, por ejemplo. Y
entonces hay varios tipos y cada organización usaría un sistema ligeramente diferente. Pero
sea lo que sea que utilicen, el tipo es un atributo muy útil para adjuntar a una declaración de
requisito como parte de una expresión de requisito.
10:07
Finalmente, en este módulo, hacemos una breve referencia a lo que llamamos las
propiedades emergentes de un sistema.
Es decir, debemos reconocer que cuando desarrollamos un sistema, tendrá ciertas
propiedades que son las que posee el sistema como un todo. Y que esas propiedades pueden
no haber sido obvias en ninguno de los elementos, o las interconexiones a medida que
construimos el sistema desde el componente, hasta el nivel del subsistema. Y esas
propiedades, por lo tanto, solo surgen una vez que todos los elementos individuales del
sistema se han integrado, y por eso los llamamos propiedades emergentes. Esas propiedades
no son obvias al observar los elementos o los subsistemas. Solo son posibles cuando
observa el sistema como un todo, y quizás solo sea posible cuando mira al sistema como un
todo cuando interactúa con su entorno. Eso es como está operando. Hay muchos ejemplos
de propiedades emergentes, y realmente no tenemos tiempo para tratarlas adecuadamente
aquí. Simplemente los señalamos porque, en primer lugar, hay muchos, de, hay
mantenimiento, fiabilidad, facilidad de uso, seguridad, seguridad, etc. Todas estas cosas son
solo obvias cuando todo el sistema se vuelve a unir. Y en segundo lugar, es posible que
surja una propiedad que es inesperada, y eso es algo que debemos tener en cuenta. Muchas
de estas propiedades queremos y esperamos y diseñamos para. Por supuesto, es posible que
haya una propiedad emergente, que no es deseada. Si quieres tener un ejemplo en mente a
lo largo del camino, tal vez el mejor ejemplo de la bicicleta, porque si miramos una
bicicleta y miramos todos los subsistemas, veríamos ruedas, marcos, manillares y pronto.
Pero si lo pusiéramos de pie, se caería. De hecho, incluso si pones al piloto sobre él, se cae.
No es hasta que el piloto está en él, y está pedaleando, avanzando, que toda la
funcionalidad del sistema es obvia. Y entonces esa propiedad del sistema, que es realmente
lo que llamaríamos una bicicleta, es una propiedad emergente. No existe hasta que todos los
elementos del sistema estén juntos, incluido el operador, y todos esos sistemas estén
interactuando con su entorno con la gravedad, y así sucesivamente, y el viento, hasta que
podamos ver las propiedades reales. del sistema.

Nos interesan las propiedades emergentes porque deben definirse de arriba hacia abajo. No
se pueden obtener especificando requisitos para elementos individuales y luego esperando
que esas propiedades surjan cuando combinemos esos elementos. Entonces, por ejemplo, si
decimos que el sistema debe ser seguro, le corresponde al diseñador decidir cómo los
elementos contribuyen a esa seguridad. De modo que cuando todos los elementos están
juntos, todo el sistema está a salvo. Pero podría ser cierto que ninguno de los elementos
individuales en sí mismos es seguro, pero la combinación sí lo es. Y para que las
propiedades emergentes sean algo muy importante, debe especificarse de arriba hacia
abajo, y debe ser controlado por el diseñador a medida que el diseño del sistema continúa.
Por supuesto, como dije antes, también debemos considerar la posibilidad de que el sistema
completo muestre alguna propiedad emergente que no se haya considerado como parte del
diseño original. Y en algunos casos puede ser indeseable, en el producto terminado. Es
decir, tenemos que entender que cuando estamos poniendo subsistemas o elem, elementos
del sistema juntos para interactuar, es posible que algunas de esas interacciones sean
imprevistas.
13:20
En este módulo, hemos discutido los requisitos, los niveles en los que existen y la relación
entre ellos en cada uno de esos niveles. Examinamos varias definiciones y luego
terminamos con una introducción a la ingeniería de requisitos. En el siguiente módulo,
veremos con más detalle cómo crear y cómo validar un conjunto de requisitos.
 Requisitos de ingeniería y Trazabilidad:
Entonces ahora tenemos una comprensión de las necesidades y requisitos y del proceso de
ingeniería de requisitos. Veámoslos más de cerca, en el proceso de desarrollar un buen
conjunto de requisitos. Vimos anteriormente que las necesidades y los requisitos se pueden
capturar en jerarquías lógicas o funcionales. Al final de este módulo, veremos brevemente
dos, llamados la estructura de desglose de requisitos, o el RBS, que ayudará a desarrollar
estas jerarquías. En primer lugar, sin embargo, veamos el proceso mediante el cual las
necesidades y los requisitos se relacionan entre sí en los distintos niveles de jerarquía.
0:29
Una jerarquía funcional se produce a través de dos procesos principales, elicitación y
elaboración. Los elementos elicitados se pueden atribuir directamente a la fuente y
normalmente se recopilan por entrevista o taller. Un elemento elicitado también podría
extraerse directamente de otras restricciones, como una regulación, por ejemplo. Eso
significa que los elementos que se obtienen son explícitos, es decir, en gran parte nos los da
directamente el negocio o los interesados, o se toman directamente de alguna restricción.
0:58
Por otro lado, la elaboración implica el análisis, que concluiría que algún elemento es
necesario como resultado de las intenciones del negocio o los interesados. Este análisis es
la descomposición o derivación.
1:11
La descomposición implica dividir la función de nivel superior en aquellas funciones de
nivel inferior que requiere explícitamente.
Por otro lado, las derivaciones implican requisitos de los ingenieros para extraer alguna
inferencia. Es decir, la dirección comercial o las partes interesadas no establecen la función
directamente, pero la función derivada es una parte necesaria del diseño del sistema, si se
cumplen una o más de las funciones declaradas directamente.
1:37
Las tareas de obtención y elaboración no son para principiantes, eso es particularmente
cierto para la elaboración. Para llevarlo a cabo correctamente, los ingenieros de requisitos o
analistas comerciales deben comprender el negocio, el dominio de la aplicación, el
problema específico, las necesidades y limitaciones de los interesados, conocidos por
comprender la gestión de adquisiciones y proyectos, la ingeniería de requisitos, la
ingeniería de sistemas, las tecnologías y la ingeniería involucrada. Entonces, puede ver en
esta lista que tales habilidades rara vez ocurren por accidente y deben ser desarrolladas
deliberadamente.
2:09
Pero tenemos un ejemplo simple, considere una declaración de nivel superior de la misión
de un centro médico. Por lo tanto, podemos decir que el centro médico debe proporcionar
una gama seleccionada de servicios médicos en un entorno seguro y cómodo, con el fin de
obtener una ganancia nominada. Y si esa es la declaración de la misión de este sistema, los
ingenieros de requisitos podrían descomponerse y derivar funciones de esa declaración. Las
siguientes funciones están descompuestas, es decir, son explícitas en la declaración y las
resaltamos aquí en negrita roja. Las funciones descompuestas son más claras, debemos
proporcionar una gama seleccionada de servicios médicos. Necesitamos proporcionar un
ambiente seguro. Un ambiente confortable. Entretener un cierto nivel de ganancia.
2:51
Pero eso no es todo lo que tenemos que hacer. Los ingenieros de requerimientos derivarían
las funciones como funciones necesarias pero no indicadas directamente por las partes
interesadas para poder proporcionar la infraestructura, poder administrar el centro y
administrar sus servicios, y por supuesto para respaldar los servicios.
Las necesidades y los requisitos se pueden identificar de varias maneras diferentes y esta diapositiva enumera
bastantes. Probablemente los más útiles sean los talleres estructurados, sin duda son la
forma más rápida y eficiente. Los talleres deben comenzar con artefactos de hombre de paja
que se afinan y aumentan a lo largo del período asignado. Los talleres deben ser facilitados
para asegurarse de que funcionen sin problemas. Donde el problema es una lluvia de ideas
más abierta y las sesiones de resolución de problemas pueden considerarse talleres
estructurados no estructurados. Y, por lo tanto, realmente solo son útiles al principio del
proceso para ayudar con el desarrollo de los artefactos iniciales, que probablemente
emprendamos luego en talleres estructurados.
3:46
Las entrevistas deben considerarse como talleres uno a uno. Es decir, deberían
estructurarse, comenzar con algunos artefactos principales y tener una agenda si se quiere
alcanzar el máximo valor.
3:55
Las encuestas y los cuestionarios no tienen una gran tasa de devolución, en algún lugar
cercano al 10-20% en cualquier contexto. Por lo tanto, no son formas muy buenas de
garantizar que todos los puntos de vista de las partes interesadas estén representados. Pero
son una buena forma de garantizar que la cantidad máxima de personas haya tenido al
menos la oportunidad de contribuir. Probablemente otra forma útil, particularmente en un
bajo nivel de comprensión de cómo funcionarán la mayoría de los sistemas, usaré los casos
como escenarios operacionales. Los humanos somos contadores de historias naturales, por
lo que es una forma muy útil de pedirles a los interesados que describan la forma en que
van a interactuar con este sistema, pidiéndoles que cuenten una historia al respecto.
4:30
Del mismo modo, estábamos en un nivel suficientemente bajo en el diseño, las
simulaciones, los modelos y los prototipos son formas útiles de comprender los requisitos
de la legión, así como de realizar diversos estudios de comercio y análisis.
diseño, en cuyo caso podríamos usar cosas como observaciones de estudios de obras.
Podríamos participar en actividades laborales para tener una idea de cómo se llevan a cabo.
Podemos hacer observaciones del entorno, podemos hacer revisiones de documentación,
análisis de mercado, análisis de sistemas competitivos, ingeniería inversa y marcado de
banco
5:11
Todo el proceso tiene como objetivo producir un sistema que se verifique con los
documentos que produjeron el sistema, y se valida con las necesidades originales que
iniciaron el desarrollo en primer lugar.
5:23
Entonces, hay dos actos principales. Verificación, que asegura que el sistema, en cualquier
etapa, coincida con las especificaciones que hemos desarrollado para él. Es decir, hemos
construido el sistema correcto. Y luego está la validación, que asegura que el sistema
cumpla con las necesidades y requisitos comerciales originales. Es decir, ¿hemos
construido el sistema correcto? A menudo, estos dos objetivos asociados se combinan en el
término genérico, verificación y validación, o V y V.
5:52
Regrese a un diagrama que muestra cómo la ingeniería de requisitos ayuda en el desarrollo
de requisitos, ahora podemos trabajar hacia atrás. Antes de que el cliente acepte el sistema
del contratista, se verifica el sistema entregado. Y se verifica contra la especificación del
sistema. Es decir, estamos comprobando que el contratista haya entregado un sistema que
haga que lo que les hemos contratado haga, es decir, que cumpla con las especificaciones
del sistema.
Sin embargo, antes de que el sistema entre en servicio, y esto es particularmente cierto para
los sistemas de capacidades, debemos validar el sistema contra las necesidades y requisitos
originales. Entonces, validamos las necesidades y los requisitos de las partes interesadas, y
luego las necesidades y requisitos del negocio, para garantizar que se cumplan tanto ese
nivel de necesidades como los requisitos.
6:36
La verificación y validación se basa en un enfoque bien administrado de lo que llamamos T
y E, prueba y evaluación. Que tiene como objetivo respaldar la entrega de un sistema que
sea verificado y validado. Entonces hay tres categorías principales de T y E, que se aplican
para que coincidan con las actividades, la fase de adquisición, la transición entre la fase de
adquisición y utilización y la fase de retiro.
7:00
Prueba de desarrollo y evaluación, DT y E se refiere a las actividades de T y E realizadas
durante la fase de adquisición para apoyar el diseño y el esfuerzo de desarrollo. Las
actividades DT & E también pueden ocurrir durante la utilización para apoyar actividades
tales como el desarrollo de modificaciones. La prueba y evaluación de aceptación, o AT &
E, representa la prueba formal realizada para permitir al cliente verificar el sistema. Y por
lo tanto, para poder permitir que lo acepten del desarrollador. Por lo tanto, AT & E forma
efectivamente el límite o la transición entre la fase de adquisición y la fase de utilización. Y
como tal, es un colaborador muy importante para una revisión de calificación formal.
7:40
La siguiente actividad es prueba operacional y evaluación. Una vez que el desarrollador ha
aceptado el sistema, OT & E puede llevarse a cabo en condiciones operacionales realistas,
mientras que el personal operacional, para validar el sistema de capacidades. El OT & E se
realiza normalmente durante un período de tiempo, una vez que el cliente ha aceptado el
sistema por parte del contratista. Eso es después de AT & E y antes de la introducción
completa en servicio.
Sigamos considerando la función importante de la gestión de requisitos, es decir, el proceso
en el que nos aseguramos de que estamos gestionando los requisitos.
2:04
Esa es una breve descripción de las herramientas de gestión de requisitos. Permite
[INAUDIBLE] ver brevemente las herramientas que admiten ingeniería de requisitos. Eso
es herramientas de ingeniería de requisitos. Ahora hay una gran cantidad de herramientas
de este tipo, que pueden ayudar en la ingeniería de requisitos dependiendo del dominio
particular en el que se realice. Hay diagramas de contenido. Diagramas de bloques de flujo
funcional. Los requisitos desglosan la estructura, en dos diagramas más otras herramientas
que incluyen análisis estructural, diagramas de flujo de datos, diagramas de flujo de control,
diagramas IDEF, diagramas de comportamiento y muchos, muchos más diagramas de ese
tipo. Cada uno de los cuales tiende a ser una herramienta particular, utilizada en un dominio
particular. Aquí nos enfocamos principalmente en la simplicidad y el tiempo en las dos
herramientas probablemente más importantes, la estructura de desglose de requisitos, el
RBS. Y los diagramas de bloques de flujo funcional, los FFBD.
2:56
Aquí llamamos el marco de requisitos, la estructura de desglose de requisitos. Ahora que
hemos dicho antes, eso también se llama jerarquía funcional, pero lo llamaremos RBS.
Ahora las palabras se eligen con mucho cuidado para diferenciar esta estructura, del
conocido documento de gestión de proyectos llamado estructura de desglose del trabajo o el
WBS. Lo obvio se agrupa lógicamente. El WBS está estructurado físicamente en un grupo
de paquetes de trabajo físico para los elementos de configuración que deben desarrollarse.
Al final del diseño prelineativo, las agrupaciones lógicas de lo obvio, por lo tanto, se
mapean o asignan, en las agrupaciones físicas en el WBS.
El principal beneficio de la jerarquía funcional es que proporciona un marco muy útil,
dentro del cual podemos desarrollar los requisitos y luego rastrearlos. Y ese proceso a
menudo se denomina flujo de requisitos.
3:47
Los requisitos se capturan en una jerarquía funcional. Una jerarquía es un árbol, en
matemáticas lo llamamos el gráfico de directivas. Y en ese árbol, las ramas fluyen desde la
declaración de la misión, en la parte superior, hasta el nivel más bajo de necesidades y
requisitos, que son las hojas del árbol en la parte inferior. En cada nivel, permanecemos en
el nivel de obstrucción, eso permanece dentro de nuestra intuición. Como solo podemos
mantener en nuestra memoria de trabajo, media docena de conceptos, esto nos alienta a
comenzar con la declaración de la misión, dentro de la cual hay de cinco a siete conceptos
clave. Cada uno de esos conceptos se vacía, como una declaración en el siguiente nivel que
conduce a cinco a siete declaraciones de objetivos. Cada uno de ellos contiene de cinco a
siete conceptos. Ahora, cada una de esas declaraciones de objetivos se puede eliminar
nuevamente en el siguiente nivel, en declaraciones objetivas. Cada uno de los cuales tiene
de cinco a siete conceptos, etc. Y el proceso continúa, hasta que alcanzamos las hojas del
árbol.
4:40
Si observas este árbol más completamente entonces, podemos ver la adición de un sistema
de numeración, permite que cada nivel se asocie con el nivel superior e inferior.
4:50
Hay algunas reglas generales para desarrollar el RBS. Primero, el RBS es un gráfico
jerárquico. Por lo tanto, el nivel que se está ilustrando debe ser tal que la porción mostrada
sea visible en una sola hoja de papel A4, con una fuente de 10 puntos como mínimo.
5:05
La denominación de los elementos debe ser coherente, de modo que las frases clave estén
basadas en verbos. La longitud de las frases clave también debe ser consistente,
normalmente tres o cuatro palabras son suficientes.

Cada frase de palabra clave debe ser única, ya que necesitamos desarrollarla para que sea
un requisito único. Y, por último, los elementos deben estar numerados, con un sistema de
numeración jerárquica, para que podamos rastrear desde padres a hijos y viceversa.
5:30
Aquí hay un ejemplo de RBS, en este caso para una alarma de seguridad doméstica, como
parte de nuestra casa. Has ingresado a través de los cinco elementos en el primer nivel.
Puede ver las principales funciones de la alarma, para disuadir, detectar, clasificar, informar
y brindar una alarma líder en el mercado.
5:48
Si mira al siguiente nivel, el RBS muestra las funciones que se combinan para formar cada
función principal, en el nivel anterior.
5:54
Como puede ver en este diagrama, el RBS es una poderosa herramienta para ilustrar la
funcionalidad que proporcionará el sistema.
6:03
La representación jerárquica de los requisitos en el RBS también puede ser respaldada por
otra herramienta llamada FFBD, el Diagrama de Flowbot Funcional. El valor de la
FFBD es que también muestra los flujos entre las funciones, no solo la descripción
jerárquica de las funciones. El diagrama de bloques de flujo funcional también debe
mostrarse jerárquicamente. Es decir, deberían poder descomponer cada uno de los
niveles al siguiente nivel inferior.
6:28
Un FFBD de un solo nivel tiene que ser ilustrado de nuevo, en una sola hoja de papel A4,
en una fuente de 10 puntos como mínimo. Las funciones en el FFBD también deben estar
numeradas y nombradas, de modo que sean consistentes con el RBS.
Aquí hay una porción de ejemplo de un primer borrador de un FFBD, nuevamente para un
ejemplo de alarma doméstica. El diagrama muestra un borrador inicial, ya que podría
haberse preparado, por ejemplo, en un taller con partes interesadas. Tenga en cuenta que las
funciones aún no se han escrito formalmente y el sistema de numeración aún no se ha
aplicado. A menudo es mejor capturar las funciones de manera informal y luego
formalizarlas. Luego, trata de capturarlos a todos en una plantilla formal. Tenga en cuenta
que hay muy buenas formas de capturar los escenarios operativos, a partir de los cuales se
desarrollarán las necesidades y los requisitos. Y simplemente mirando este diagrama,
debería poder ver qué es lo que los usuarios quieren hacer con el sistema a medida que lo
describen. No voy a la RBS que solo muestra relaciones lógicas. El siempre pd proporciona
el ingeniero de requisitos, con información sobre la secuencia de funciones. Por ejemplo, el
residente evacua después de configurar alarmas. Puedes ver en las primeras dos funciones.
Alternativamente, si puede ver en el medio del diagrama, todas las formas de entrada son
igualmente posibles. Entonces las primeras dos funciones, configurar la alarma y evacuar,
están en serie. Las funciones de entrada, se muestran en paralelo. Eso hace una gran ayuda
en el ingeniero de requisitos, para poder identificar las interfaces.
7:51
Vimos anteriormente que los requisitos no se pueden gestionar eficazmente sin una buena
trazabilidad de los requisitos. La rastreabilidad garantiza que sepamos de dónde viene el
requisito, qué requisitos están relacionados con él y qué requisitos se derivaron de él. Una
buena trazabilidad, por lo tanto, nos permite identificar todos los requisitos afectados por
un cambio, por ejemplo.

Ahora, en términos generales, existen dos tipos de rastreabilidad que mencionamos

anteriormente, la rastreabilidad hacia adelante y la rastreabilidad hacia atrás. Ahora con
nuestro RVS, podemos ver cómo estas traceabilidades se aplican a la jerarquía de
requisitos. La rastreabilidad hacia adelante nos da la confianza de que cada requisito se ha
abordado en el diseño. La trazabilidad hacia atrás, nos permite rastrear desde cada requisito
hasta al menos un requisito de período.
8:34
A través de la rastreabilidad hacia adelante, las decisiones de diseño se pueden rastrear
desde cualquier requisito de nivel de sistema, requisito aparente, hasta una decisión de
diseño detallada, un requisito de niño. Para cada requisito, debemos ser capaces de
encontrar al menos un niño en los documentos de diseño subordinados. Si hay más de un
niño, debemos ser capaces de identificarlos a todos.
8:54
La trazabilidad hacia atrás garantiza que los requisitos adicionales, que no han sido
formalmente respaldados por el cliente, no se hayan infiltrado. Llamamos a ese guión de
requisitos. Cualquier aspecto del sistema que, por lo tanto, no puede remontarse a un
requisito de alto nivel, probablemente represente un trabajo innecesario para el cual los
clientes probablemente paguen una prima, pero no lo hayan autorizado. Llamamos a esos
requisitos, requisitos huérfanos. Ahora un requisito de huérfano, está fuera del alcance.
9:20
Bueno, ha sido un trabajo duro, pero ahora hemos cubierto todos los elementos básicos que
necesitamos para poder ver las fases del ciclo de vida con más detalle. En el siguiente
módulo, Ian comenzará la discusión de la fase de adquisición, examinando el diseño
conceptual