Necesidades de los interesados ​y Requisitos 95

ha sido adjudicada. Puede ver la adjudicación de las observaciones presentadas antes de la Sebök v. 1.0 en Sebök Revisión y Adjudicación. los
comentarios posteriores se abordan y los cambios se resumen en la Carta del Editor y Reconocimientos e Historia de lanzamiento.

Si desea proporcionar ediciones en este artículo, recomendar nuevos contenidos, o hacer comentarios sobre el Sebok en su conjunto, por favor ver el Sebök

recinto de seguridad [ 1].

ENCODED_CONTENT
OTg0OTMPGRpdiBpZD0iZGlzcXVzX3RocmVhZCI + + PC9kaXY CjxzYW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoJ2hlYWQnKVswXSB8fCBkb2N1bW

Definición del sistema

actividades de definición del sistema se llevan a cabo para crear y describir en detalle un sistema de intereses (SOI) para satisfacer una necesidad identificada. Las

actividades se agrupan y se describen como procesos genéricos. que consisten de los requisitos del sistema definición, la arquitectura del sistema definición,

definición diseño del sistema y análisis del sistema. La definición de la arquitectura del sistema puede incluir el desarrollo de modelos de la arquitectura lógica

relacionados y modelos de arquitectura física. Durante y / o al final de cualquier iteración, se realiza análisis de la brecha para asegurar que todos los requisitos del

sistema han sido asignadas a la arquitectura y diseño.

actividades de definición del sistema se basan en los artefactos y las decisiones de la definición del concepto, sobre todo la articulación de la misión de la (SOI), las

necesidades y requerimientos de los interesados, y conceptos operativos preliminares. Ver los procesos de ciclo de vida y la necesidad de la empresa para obtener más

detalles sobre la transformación de las necesidades y requerimientos de la empresa o los niveles de la empresa y las partes interesadas de la abstracción tratados en la

definición del concepto de nivel de elemento del sistema y el sistema de abstracción abordado en la definición del sistema.

Los productos de las actividades de definición del sistema (requisitos del sistema, arquitectura y diseño) son entradas para la realización del sistema.

Las actividades específicas y la secuencia de actividades de definición del sistema y su implicación con las actividades del ciclo de vida de cualquier sistema, y ​en

particular, la estrecha integración con las actividades concepto definición y realización del sistema, dependen del tipo de modelo de ciclo de vida que se utilizan.

Consulte Aplicación de los procesos de ciclo de vida para una mayor discusión sobre la naturaleza concurrente, iterativa y recursiva de estas relaciones.

temas
Cada parte de la Sebok se divide en áreas de conocimiento (KAS), que son agrupaciones de información con un tema relacionado. La KAS a su vez

se dividen en temas. Esta KA contiene los siguientes temas:

• Requisitos del sistema

• Arquitectura del sistema

• Desarrollo del Modelo de arquitectura lógica

• Modelo de desarrollo de la arquitectura física

• Diseño de sistemas

• Análisis del sistema

Vea la matriz del artículo de ejemplos de implementación de un mapeo de los estudios de casos y viñetas incluidas en la Parte 7 a temas tratados en la parte 3.
Definición del sistema 96

Vistas del sistema y elementos de sistema

Una solución de sistema de ingeniería (glosario) a un concepto definido incluye un conjunto de elementos de ingeniería, las características y propiedades.

Estos elementos se agrupan en dos formas:

• Necesidades y requisitos vistas

• vistas de arquitectura y diseño

vistas Arquitectura incluyen la identificación de los límites y las interfaces de un sistema de intereses (SOI), que puede entonces ser refinado como una

colección de elementos de sistema y sus relaciones.

Necesidades y requerimientos Vistas

Requisitos proporcionan una visión global de la finalidad y la misión que el sistema en su conjunto está destinado a satisfacer, así como una visión

independiente de la tecnología de que las soluciones (s) del sistema deben hacer. Se organizan de forma convencional en dos tipos:

• Comerciales o misión requisitos y necesidades de los interesados ​se definen y analizan en el Concepto Definición KA.

• Los requisitos del sistema, que describen las funciones que debe cumplir el sistema como un todo con el fin de satisfacer las necesidades de los interesados ​y

se expresan en un conjunto apropiado de puntos de vista, y los requisitos no funcionales que expresan los niveles de seguridad, la seguridad, la fiabilidad, etc.,

que se pide. Estos forman colectivamente la base para la verificación posterior del ciclo de vida.

requisitos del sistema y requisitos de los interesados ​están estrechamente relacionados. Ni se puede considerar completa hasta que se ha alcanzado la

consistencia entre los dos, como se demuestra por la trazabilidad, para los que puede ser necesario un número de iteraciones.

Las actividades de los procesos que se utilizan para identificar, ingeniero y gestionar los requisitos del sistema se describen con más detalle en el artículo sobre los requisitos del

sistema en el KA.

Arquitectura y Diseño Vistas

Un sistema de ingeniería dado es una solución que pudiera dirección / responder a un problema o una oportunidad (representado a través
de vistas requisitos); la solución puede ser más o menos complejo. Una solución de complejo no puede ser comprendido con una única
vista o modelo, debido a las características o propiedades del problema / solución (ver la complejidad del sistema). Las características
están estructurados como tipos o entidades; tipos están relacionados entre sí. Una instanciación del conjunto de tipos puede ser entendido
como la arquitectura del sistema. La mayoría de las interpretaciones de la arquitectura del sistema se basa en la noción bastante intangible
de la estructura. Por lo tanto, la arquitectura y el diseño del sistema se representa formalmente con conjuntos de tipos o entidades tales
como funciones, interfaces, objetos de flujo de recursos, elementos de información, elementos físicos, nodos, enlaces, etc.

Puntos de vista y puntos de vista a veces se especifican en los marcos de arquitectura. Vistas normalmente se generan a partir de modelos. Muchas de las prácticas de

ingeniería de sistemas de uso de vistas lógicas y físicas para el modelado de la arquitectura y el diseño del sistema.

• Los vista lógica de la arquitectura apoya la operación lógica del sistema a lo largo de todo su ciclo de vida, y puede incluir visitas / modelos funcionales,
conductuales y temporales. escenarios operacionales refinar la misión en una colección de funciones y estructuras dinámicas que describen cómo se
lleva a cabo la misión (comportamiento).

• Los vista física de la arquitectura es un conjunto de elementos del sistema que realizan las funciones del sistema. Aquellos elementos del sistema pueden ser o
bien material o inmaterial (por ejemplo, equipo hecha de hardware, software y / o humana
Definición del sistema 97

papeles).

El límite de la arquitectura del sistema depende de lo que los ingenieros incluyen dentro del alcance del IOA y fuera de ella. Esta decisión
marca la transición de la caracterización del contexto del problema a los inicios de definición solución.

Frente al número potencial de los elementos del sistema que constituyen la arquitectura física, conjuntos de elementos del sistema pueden ser agrupadas para formar

sistemas. La descomposición de SOI (nivel más alto) puede incluir la descomposición de varias capas de los sistemas (niveles intermedios de sistemas) hasta que los

elementos del sistema tecnológico (nivel más bajo) se definen. Cualquier capa de la descomposición pueden incluir sistemas y elementos de sistema tecnológico no

descomponibles. La relación entre cada capa es recursivo; como un elemento del sistema es también un sistema de ingeniería que se puede caracterizar a su vez el

uso de los puntos de vista anteriores en su propio contexto.

Las representaciones lógicas y físicas de la arquitectura del sistema se asignan una sobre otra. Las interacciones entre los elementos del sistema se

definen por las interfaces cuya complejidad depende en gran medida de la forma en la arquitectura del sistema y el diseño se define. Las relaciones entre

las salidas de la definición del concepto y la solución del sistema, así como la gama de otros puntos de vista de un sistema que están disponibles para

describir un conjunto más completo de características entre los elementos del sistema se discuten en la lógica de desarrollo de arquitectura del modelo y

de Física Arquitectura secciones de Desarrollo del Modelo de definición del sistema.

Síntesis del sistema y de descomposición

Definición del sistema se gestiona a través de síntesis metódica de SOI en los sistemas y elementos del sistema. La síntesis en solución puede ser de arriba hacia abajo o

de abajo hacia arriba, como se discutió en la síntesis de las posibles soluciones. Sin embargo se hace, a medida que avanza definición de la arquitectura del sistema, una

descomposición de los sistemas y elementos del sistema surge, esta forma una estructura de división del sistema (SBS). A efectos de gestión de proyectos, cada sistema

de la SBS se puede incluir en una

bloque de construcción, una noción introducida en (ANSI / EIA 1998), también llamado bloques del sistema.

existen requisitos de los interesados ​y requisitos del sistema en todas las capas de la SBS. En ISO / IEC / IEEE 29148 Sistemas e ingeniería de

software - Ingeniería de Requisitos ( ISO 2011), estas capas se conocen como niveles de abstracción. Junto con la introducción sistemática capas de

los sistemas, el proceso de la arquitectura y diseño gestiona la transformación de los requisitos del sistema a través de niveles de abstracción. La

Figura 1 ilustra este enfoque.

Definición del sistema 98

Figura 1. De arriba hacia abajo Desarrollo de Arquitectura y Diseño y Requisitos (Faisandier 2012). Permiso otorgado por

Sinergy'Com. Todos los otros derechos están reservados por el propietario de los derechos de autor.

Como se muestra en la Figura 1

• Los óvalos blancos representan los requisitos en la disminución de niveles de abstracción, y las flechas representan la transformación de los requisitos a

través de los niveles utilizando el proceso de arquitectura y diseño. expresiones de las partes interesadas de las necesidades, expectativas y limitaciones se

transforman en necesidades de los interesados.

• La siguiente transformación cruza el límite entre las áreas de problemas y soluciones mediante la conversión de requisitos de los interesados ​en los

requisitos del sistema, lo que refleja el espacio solución acotada.

• A nivel SOI la arquitectura del sistema es desarrollado que sirve para identificar sistemas y elementos del sistema y establece la forma en que

operan juntos para abordar los requisitos de SOI.

Este enfoque se aplica de forma recursiva para cada nivel de abstracción / descomposición reconociendo que los mismos procesos genéricos se aplican en múltiples

niveles de abstracción. En cualquier nivel de esta descomposición uno o más opciones de solución se pueden presentar como arquitecturas de sistemas. El proceso por

el cual se selecciona y se justificó la solución que mejor se ajuste a los requisitos del sistema, necesidades de los interesados ​y asociados preocupaciones más amplias

del ciclo de vida se discute en el proceso de análisis del sistema.

Figura 2 a continuación describe la ingeniería que se produce en cada bloque de sistema. Según sea necesario, los elementos del sistema se definen a través de conjuntos de requisitos

de elementos del sistema, que se convierten en entradas a otros bloques del sistema ( el nivel n + 1). El enfoque se aplicó entonces de forma recursiva utilizando los procesos de

definición del sistema.

Definición del sistema 99

Figura 2. Recursive instanciación de Procesos Definición (Faisandier 2012). La autorización concedida por Sinergy'Com. Todos los demás derechos están reservados por

el propietario del copyright.

En el n + 1 nivel, los sistemas o elementos del sistema también pueden recoger otros requisitos de los interesados ​que son directamente pertinentes a este nivel de

arquitectura y diseño. Procesos dentro de cada sistema son genéricas, pero único en el propósito locales, el alcance y el contexto.

Consulte Aplicación de los procesos de ciclo de vida para una discusión de la aplicación iterativa y recursiva de los requisitos del sistema y los procesos de la arquitectura y los

procesos de ciclo de vida y la necesidad de la empresa para obtener más detalles sobre la transformación de las necesidades y requisitos de los sistemas y de los elementos del

sistema de abstracción.

Los diferentes aspectos de cómo el pensamiento sistémico es aplicable a la definición del sistema se discuten en la Parte Sebök 2. En particular, véase el análisis

de la naturaleza recursiva de los sistemas y contextos de sistemas de ingeniería en el contexto del sistema de ingeniería; el contraste entre el arriba-abajo y de

abajo hacia arriba en la síntesis de los enfoques posibles soluciones y el papel de la solución opciones de arquitectura y selección en Análisis y selección entre las

posibles soluciones.

referencias

Trabajos citados

ANSI / EIA. 1998. Procesos para la ingeniería de un sistema. Filadelfia, PA, EE.UU.: American National Standards Institute (ANSI) /

Asociación de Industrias Electrónicas (EIA), ANSI / EIA-632-1998. Faisandier, A. 2012. Sistemas de Arquitectura y Diseño. Belberaud,

Francia: Sinergy'Com. ISO / IEC / IEEE. 2011. Sistemas y software de ingeniería - Ingeniería de Requisitos. Ginebra, Suiza: Organización

Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional / Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), (IEC),

ISO / IEC / IEEE 29148. ISO / IEC / IEEE. 2011. Sistemas e ingeniería de software - Descripción arquitectura. Ginebra, Suiza: Organización

Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional (IEC) / Instituto de Ingenieros Eléctricos y Electrónicos (IEEE),

ISO / IEC / IEEE 42010.

Definición del sistema 100

Las referencias primarias

ANSI / EIA. 1998. Procesos para la ingeniería de un sistema. Filadelfia, PA, EE.UU.: American National Standards Institute (ANSI) / Asociación de

Industrias Electrónicas (EIA), ANSI / EIA 632 hasta 1.998. Blanchard, BS, y WJ Fabrycky. 2005. Ingeniería de Sistemas y Análisis. 4ª ed. Serie

Internacional de Prentice-Hall en Ingeniería Industrial y de Sistemas. Englewood Cliffs, NJ, EE.UU.: Prentice-Hall. INCOSE. 2015. 'Manual de sistemas

de ingeniería: Una guía para los procesos y actividades del ciclo de vida del sistema', versión

4.0. Hoboken, NJ, EE.UU.: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0 ISO / IEC. 2007. Ingeniería de Sistemas - Aplicación y

gestión del proceso de Ingeniería de Sistemas. Ginebra, Suiza: Organización Internacional de Normalización (ISO) / Comisión Electrotécnica

Internacional (IEC), ISO / IEC 26702: 2007. ISO / IEC / IEEE. 2015. Sistemas y de Ingeniería de Software - Procesos del ciclo de vida del

sistema. Ginebra, Suiza: Organización Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional (IEC) / Instituto de

Ingenieros Eléctricos y Electrónicos. ISO / IEC / IEEE 15288: 2015. ISO / IEC / IEEE. 2011. Sistemas e Ingeniería de Software - Ingeniería de

Requisitos. Ginebra, Suiza: Organización Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional / Instituto de

Ingenieros Eléctricos y Electrónicos (IEEE), (IEC), ISO / IEC / IEEE 29148. ISO / IEC / IEEE. 2011. Sistemas e Ingeniería de Software -

Arquitectura descripción. Ginebra, Suiza: Organización Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional (IEC) /

Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), ISO / IEC / IEEE 42010. Martin, JN 1997. Ingeniería de Sistemas Guía: Un proceso

para el desarrollo de sistemas y productos, 1st ed. Boca Raton, FL, EE.UU.: CRC Press. La NASA. 2007. Manual de sistemas de ingeniería. Washington,

DC: National Aeronautics and Space Administration (NASA), la NASA / SP-2007-6105.

Referencias adicionales

Baldwin, CY y KB Clark. 2000. Reglas de diseño. Cambridge, Massachusetts: MIT Press. Buede, DM 2009. El diseño de Ingeniería de Sistemas: Modelos y

Métodos. 2ª ed. Hoboken, Nueva Jersey, EE.UU.: John Wiley & Sons Inc. Faisandier, A. 2012. Sistemas de Arquitectura y Diseño. Belberaud, Francia:

Sinergy'Com. Hatley, DJ, y la IA Pirbhai. 1987. Estrategias para Real-Time System especificación. Nueva York, Nueva York: Dorset House Pub.

MOD. 2010. MOD Marco de Arquitectura, Versión 1.2.004. Ministerio de Defensa británico. Disponible en: http: / / www. mod. Reino Unido/ DefenceInternet / AboutDefence

/ WhatWeDo / Gestión de la información / MODAF / .

<Artículo anterior | Padres artículo | Siguiente artículo>

Sebok v. 1.8 lanzado 27 de de marzo de 2017

Discusión Sebök
Por favor envíe sus comentarios y retroalimentación sobre el Sebök a continuación. Usted tendrá que entrar a Disqus usando una cuenta existente (por

ejemplo, Yahoo, Google, Facebook, Twitter, etc.) o crear una cuenta Disqus. Simplemente escriba su comentario en el campo de texto de abajo y Disqus

le guiará a través de los pasos de inicio de sesión o de registro. La reacción será archivada y se utiliza para futuras actualizaciones de la Sebok. Si

proporcionó un comentario que ya no está en la lista, que ha sido adjudicada. Puede ver la adjudicación de las observaciones presentadas antes de la

Sebök v. 1.0 en Sebök Revisión y Adjudicación. los comentarios posteriores se abordan y los cambios se resumen en la Carta del Editor y
Definición del sistema 101

Reconocimientos e Historia de lanzamiento.

Si desea proporcionar ediciones en este artículo, recomendar nuevos contenidos, o hacer comentarios sobre el Sebok en su conjunto, por favor ver el Sebök

recinto de seguridad [ 1].

ENCODED_CONTENT
NjA1ODEPGRpdiBpZD0iZGlzcXVzX3RocmVhZCI + + PC9kaXY CjxzYzBdIHx8IGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCdib2R5JylbMF0pLmF

Requisitos del sistema

Los requisitos del sistema son todos los requisitos en el Nivel del sistema que describen las funciones que el sistema en su conjunto debe cumplir para

satisfacer las necesidades y requisitos de los interesados, y se expresa en una combinación apropiada de declaraciones textuales, vistas y requisitos no

funcionales; este último que expresa los niveles de seguridad, la seguridad, la fiabilidad, etc., que serán necesarios.

Requisitos del sistema juegan un papel importante en la ingeniería de sistemas, ya que:

• Formar la base de la arquitectura del sistema y las actividades de diseño.

• Formar la base de la integración de sistemas (glosario) y las actividades de verificación.

• Actuar como referencia para la validación y aceptación de los interesados.

• Proporcionar un medio de comunicación entre los diferentes técnicos que interactúan a lo largo del proyecto. Elicitación de requisitos de los interesados

​se inicia en la definición del concepto, y se desarrolló inicialmente aunque entrevista y análisis de misión. Los requisitos del sistema se consideran en detalle

durante definición del sistema. Ni se puede considerar completa hasta que se ha alcanzado la consistencia entre los dos, como se demuestra por la

trazabilidad, para los que puede ser necesario un número de iteraciones.

Definición y finalidad de los requisitos

Un requisito es una declaración que identifica a un producto o procesos, o característica de diseño funcional operacional o de restricción, que no es

ambigua, comprobable, o medible y necesario para el producto o la aceptabilidad proceso (ISO

2007).

Para evitar la confusión en la multitud de términos relativos a requisitos, considerar las siguientes clasificaciones:

• Rol proceso o Estado: El papel del requisito desempeña en el proceso de definición; por ejemplo, su posición en el bloque de sistema (por ejemplo, traducida,

derivado, satisfecho) o su estado de acuerdo (por ejemplo propuesto, aprobado, cancelado).

• Nivel de abstracción: El nivel en el proceso de definición, la condición se encuentra; por ejemplo, el requisito de los interesados,

requisito del sistema, requisito elemento del sistema.

• Tipo de Requisito: La naturaleza del requisito de sí mismo; por ejemplo, funcionales, de rendimiento, restricción, etc. Cualquier requisito único

puede ser al mismo tiempo en un estado particular, en un nivel de abstracción en particular, y de un tipo particular. Para explicaciones adicionales

sobre las diferencias entre los tipos de requisitos, consulte (Martin

1997, capítulo 2).