- •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). Примеры.
- •Тут выше что-то было, пусть будет
8. Способы документирования требований. Привести пример требования, задокументированного по каждому из способов.
Инженерия требований сосредоточена на задачах обнаружения, выявления, разработки, анализа, надежной верификации требований, а также на валидации, выражении, документировании требований и управлении требованиями и является одним из ключевых элементов системной инженерии.
При составлении документа, содержащего требования, следует тщательно соблюдать баланс между двумя аспектами:
1) документ с требованиями должен быть удобным для чтения;
2) набор требований должен быть технологичным, то есть удобным для работы с требованиями.
Первый из этих аспектов относится к структуре документа, к организации его содержимого, к тому, насколько эта структура помогает читателю вписать отдельное требование в контекст всего документа. В центре внимания второго аспекта находятся качество формулировки отдельных требований, язык изложения, обеспечивающий ясность и точность, деление текста на отдельные хорошо прослеживаемые разделы и подразделы.
Документация, относящаяся к требованиям, может быть весьма объёмной. В таких ситуациях важным фактором управления сложностью становится понятная и чётко определённая структура документов, содержащих описание полного набора требований.
Организация требований в правильную структуру может помочь: минимизации количества требований; лучшему пониманию больших объёмов информации; быстрому нахождению наборов требований по заданным критериям; выявлению пропусков и дублирований; устранению конфликтов между требованиями; управлению итерациями (например, для отложенных требований); исключению ненужных требований; оценке требований; повторному использованию требований в нескольких проектах. Обычно документы имеют иерархическую структуру с разделами и подразделами нескольких уровней. Иерархии представляют собой структуры, удобные для классификации, и одним из способов структурирования документа является использование системы заголовков разделов для категоризации пунктов требований. При таком подходе положение пункта требований в документе соответствует основной или первичной классификации.
Если требования выводятся из моделей, где используется иерархия, то одну из иерархий, полученных в результате моделирования, можно использовать в качестве структуры заголовков для документа, содержащего требования. В дополнение к описаниям требований документы могут включать разнообразные технические и нетехнические тексты, способствующие лучшему пониманию требований, например: вспомогательная информация, которая позиционирует требования с учетом контекста; внешний контекст, описывающий объемлющую систему, часто называемый «предметной областью»; определение области применения требований (что «внутри» и что «снаружи»); определения терминов, используемых в формулировках требований; описания, связывающие различные разделы документа; описания заинтересованных сторон; краткие обзоры моделей, применяемых для определения происхождения требований; ссылки на другие документы.
Простой текстовой формы не вполне достаточно для определения требования, каждое требование должно также включать иную информацию о его классификации и статусе. Чтобы упорядочить текст, содержащий требование, следует предусмотреть дополнительные информационные «атрибуты», привязанные к требованию. Подобные атрибуты позволяют структурировать информацию, касающуюся каждого отдельного требования, что дает возможность упростить ее обработку, фильтрацию, сортировку и т. п.
Использование ясного, логически непротиворечивого языка заметно упрощает определение различных типов требований. Самый простой пример – использование слова «должен» как ключевого слова для обозначения в тексте приоритета требования.
Обычно требование конкретной возможности имеет следующую форму:
Если некоторые аспекты той или иной характеристики или ограничения связаны исключительно с описываемым требованием, то их также можно включить в текст, например, в такой форме:
Например, следующее требование возможности включает в себя характеристику и ограничение: Дежурный оператор должен быть способен: запустить ракету в течение 3 секунд после обнаружения цели радаром в условиях волнения моря до 7 баллов.
Как правило, требования к ограничениям записываются в следующей форме:
Пример: Водитель машины скорой помощи не должен попадать в ситуацию, вынуждающую нарушать национальные правила дорожного движения.
Вот пример описания функции с показателем функционирования:
Пример: Система связи должна поддерживать телефонные соединения не менее чем 10 абонентов при отсутствии внешнего электропитания.
В другом примере описывается ограничение на периодичность действия:
Пример: Кофеварка должна готовить горячий напиток каждые 10 секунд. Обсуждение этой темы будет продолжено в следующем разделе.
Требование может ссылаться на общий для всего документа экземпляр шаблона, а данные, помещаемые в поля шаблона, могут быть собраны как атрибуты конкретного требования.
