- •1. Работа с требованиями при создании систем по стандарту гост 34.601, 602.
- •Более подробно про каждый этап
- •Более подробно про каждый подраздел
- •2. Работа с требованиями при создании систем по стандарту iso/iec/ieee 29148.
- •3. Преобразование потребностей в требования согласно Райану (Ryan, 2013).
- •4. Диаграмма «сущность-связь», описывающая концептуальную схему требований (Ryan and Wheatcraft, 2016).
- •5. Работа с требованиями в V-образной модели жизненного цикла системы.
- •6. Свойства, правила и атрибуты для формулировок требований согласно Руководству по написанию требований incose.
- •7. Свойства, правила и атрибуты для формулировок требований согласно iso/iec/ieee 29148. [Условие] [Субъект] [Действие] [Объект] [Ограничение]
- •[Условие] [Действие или Ограничение] [Значение]
- •[Субъект] [Действие] [Значение]
- •8. Способы документирования требований. Привести пример требования, задокументированного по каждому из способов.
- •9. Взаимосвязь между пользовательскими историями (User Stories), вариантами и сценариями использования (uCs) и спецификацией требований.
- •10. Методы выявления и ранжирования заинтересованных сторон. Выявление потребностей (нужд) заинтересованных сторон. Виды потребностей. Выявление требований заинтересованных сторон. Виды требований.
- •11. Типовой процесс для инженерии требований. Разработка систем. Контекст типового процесса и его информационная модель. Типовой процесс инженерии требований
- •Основные положения типовых процессов разработки требований
- •Разработка системы
- •Процесс разработки системы
- •Информационная модель тпрт
- •12. Входящие и производные требования. Разработка требований в контексте изменений.
- •Определение исходных и производных требований в контексте изменения в типовом процессе
- •Разработка требований в контексте изменений
- •13. Методы моделирования для разработки требований. Диаграммы потоков данных. Диаграммы «сущность-связь». Диаграммы состояний.
- •14. Объектно-ориентированные подходы к управлению требованиями.
- •Диаграммы классов
- •Варианты использования (use cases)
- •15. Описание и проверка требований. Ключевые требования. Использование атрибутов. Обеспечение непротиворечивости требований.
- •16. Структурирование документов, содержащих требования. Критерии для написания текста требований. Связанность и согласованность требований.
- •17. Определение области проблем. Согласование требований с заинтересованными сторонами.
- •18. Определение заинтересованных сторон. Разработка сценариев использования. Определение границ системы. Сбор требований.
- •19. Определение стратегии проверки соответствия. Определение критериев приемки и проверки.
- •20. Инженерия требований в области решений. Получение системных требований из пользовательских. Область решений
- •Получение системных требований из пользовательских
- •21. Разработка архитектурной модели системы.
- •22. Прослеживаемость требований. Простая прослеживаемость. Доказательство выполнения требований. Привязка требований.
- •23. Трассировка требований. Проектная документация. Элементарные связи. Анализ расширенных связей. Параметры анализа связей. Трассировка требований.
- •24. Управленческие аспекты инженерии требований.
- •Контроль за ходом выполнения работ
- •Изменения
- •25. Проблемы управления процессом разработки требований. Планирование. Контроль за ходом выполнения работ. Изменения.
- •26. Что такое верификация и валидация? Основные методы верификации и валидации.
- •27. Понятие системы через способности (capabilities), эмерджентность, процессы управления (Command and Control, c2), показатели результативности, операционную среду.
- •28. Понятия миссии, цели, способности (capability), функции системы.
- •29. Понятия efficacy, efficiency, effectiveness. С примерами количественных оценок.
- •30. Многослойное мышление (Why? What? How? Надсистема, система, подсистемы). Примеры с разными наблюдателями.
- •31. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Графическое изображение циклов управления.
- •32. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Производственный цикл интересующей системы.
- •33. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Архитектурное представление.
- •34. Система целевого назначения/производственная система/проект (Mission System, Producer) и система обеспечения (Enabling System, Supplier). Принцип двойной роли. Примеры.
- •35. Иерархия показателей результативности moe, mop, mos. Что такое эффективность, результативность (Performance), пригодность (Sutability). Примеры.
- •Тут выше что-то было, пусть будет
Тут выше что-то было, пусть будет
Принцип Mission Statement
Выражение миссии (mission statement) должно задавать один и только один выходной результат, который необходимо достигнуть и который определятся одним или несколькими показателями выполнения (performance-based objectives).
Принцип Mission Objectives
Каждая миссия должна быть ограничена и определена одним или несколькими показателями выполнения (performance-based objectives).
Термины (!!ОНИ НЕ ТОЛЬКО К ЭТОМУ ПРИНЦИПУ!!): (Про них подробнее в вопросе 35 есть)
- MET – Mission Event Timeline
- MOE – Measures of Effectiveness – показатели
эффективности/результативности (валидация)
- MOP – Measure of Performance – показатель производительности/показатель выполнения задачи (верификация)
- MOS – Measures of Suitability – показатели пригодности
- SOI – System of Interest
- UC – Use Case
Принцип Mission Operating Constraints
Каждая целенаправленная деятельность должна быть ограничена посредством operating constraints которые лимитируют ее приемлемое использование—безопасность, диапазон применения, доступность, условия окружающей среды.
На протяжении выполнения целенаправленной деятельности интересующей системы — система целевого назначения (Mission System) или система обеспечения (Enabling System) — взаимодействуют с внешними системами в среде штатной эксплуатации/среде применения (Operating Environment).
Эти внешние системы могут включать в себя дружественные, благоприятные, враждебные, вредные, угрозы, столкновения, взаимодействия, условия окружающей среды, которые могут варьироваться от благоприятных до агрессивных.
Принцип Mission Reliability
Каждая миссия должна быть ограничена показателем mission reliability (вероятность безотказного достижения цели), который необходимо достигнуть.
- Нужно ответить на вопрос: При заданных ограничениях на ресурс, какой минимальный уровень успеха вы хотите достигнуть для обеспечения установленного Return on Investment (ROI)? С точки зрения системной инженерии, мы рассматриваем уровень успеха как mission reliability (вероятность безотказного достижения цели).
- На вероятность безотказного достижения цели влияют провалы внутреннего оборудования (Equipment) или в стандартных условиях исполнение человека-оператора (его решения, ошибки, усталость) и взаимодействие с сущностями среды применения (Operating Environment).
- Вероятность безотказного достижения цели определяется как условная вероятность, что система с заданными условиями применения успешно завершит миссию заданной протяженности в описанной среде применения (Operating Environment) без провалов. В зависимости от применения системы, 100% mission reliability может чрезмерно дорого стоить, но 95% mission reliability может быть допустимо.
Требования целенаправленной деятельности иногда относятся к операционным требованиям (operational requirements). В общем случае, операционные требования выражают точку зрения пользователя на то, как он намеревается:
- Интегрироватьпредлагаемуюсистему,продукт или услугу как актив в свою Enterprise System для выполнения целенаправленной деятельности;
- Разворачивать, применять, сопровождать, поддерживать, уничтожать систему, продукт или услугу для заданных видов целенаправленной деятельности (mission applications).
Принцип User Mission Profile
Целенаправленная деятельность начинается с начальной точки (point of origination) и заканчивается в точке назначения (point of destination). Учитывая ограничения на всех стадиях, вопрос состоит в том, как нам перейти от point of origination (Point A), к point of destination (Point B)?
В контексте системных вариантов и сценариев использования (User Cases, UC) профиль миссии является графической иллюстрацией системного UC воздушного судна, выполняющего миссию.
UC характеризуется основным успешным сценарием, когда всё выполняется, как было запланировано – взлет, набор высоты, крейсерский полет, снижение, приземление.
Принцип Mission Phases of Operation
Системы, созданные человеком — Enterprise and Engineered Systems — имеют, по крайней мере, три основных фазы применения: Подготовительная (Pre-Mission), Исполнение (Mission), Завершающая (Post-Mission). Для некоторые систем требуется назначить дополнительные промежуточные фазы, например, Storage.
Анализ сценариев использования (Mission UC Analysis)
Во время фаз Pre-Mission, Mission, Post-Mission должны исполняться назначенные реализации целенаправленной деятельности варианты и сценарии использования (UC и UCS), а также относящиеся к ним операции по применению и задачи. Все они должны способствовать достижению показателей целенаправленной деятельности на определенной фазе.
