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