- •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). Примеры.
- •Тут выше что-то было, пусть будет
22. Прослеживаемость требований. Простая прослеживаемость. Доказательство выполнения требований. Привязка требований.
Вся информация из книги элизабет халл, если хотите узнать ещё больше обратитесь к главе 7
Прослеживаемость требований — это процесс отслеживания требований на протяжении всего цикла разработки.
Простая прослеживаемость
Существует много способов представления связей типа «многие ко многим». Многие инженеры хотели бы, чтобы свидетельства прослеживаемости были представлены в матричной форме в виде приложения к соответствующим документам. Если использовать два измерения, то требования пользователя можно, например, отложить по одной оси, а требования к системе – по другой с пометками в тех ячейках, где существует взаимосвязь.
Этот подход имеет ряд недостатков:
если по обеим осям отложить большое количество пунктов требований, то для отображения необходимого объёма информации места на листе или экране может не хватить;
взаимосвязи, определяющие прослеживаемость, размещаются, как правило, с низкой плотностью, поэтому большинство ячеек матрицы останется пустым, таким образом, пространство используется нерационально;
достаточно трудно работать в случае, когда имеет место многоуровневая прослеживаемость, отображенная несколькими отдельными матрицами;
информация о прослеживаемости отделена от подробностей самих требований.
Другая методика заключается в использовании документов с гиперссылками, где отдельные пункты могут быть выделены (подсвечены) и связаны с другими пунктами, при наличии достаточного навыка можно переходить по этим ссылкам в любом необходимом направлении. В этом случае информация о прослеживаемости содержится в тексте пункта требований, но и здесь возникают проблемы:
при выполнении анализа физическая связь для перехода по ссылке может быть установлена раньше, чем будет представлен целевой фрагмент текста;
удаление элемента текста на другом конце гиперссылки может остаться незамеченным, при этом ссылка становится некорректной, «висящей», затрудняя обеспечение прослеживаемости.
Какой бы подход не использовался, отсутствие необходимых инструментов превращает управление прослеживаемостью в очень трудную задачу. В простейшей форме прослеживаемость достигается посредством установления взаимосвязей между пунктами документов с помощью некоторых типов баз данных. Полезно, чтобы информация о связях хранилась отдельно от самих документов. Здесь крайне важна недвусмысленная и независимая идентификация каждого пункта документа.
Как показывает анализ, наиболее важными возможностями, необходимыми для достижения прослеживаемости, являются:
возможность создавать ссылки между пунктами документа, формируя тем самым допустимые связи;
возможность удалять ссылки между пунктами, сохраняя при этом управление связями и полный контроль над ними;
возможность одновременно просматривать текст (или другие атрибуты) пунктов требований, расположенных на обоих концах выбранной связи;
возможность выполнять анализ покрытия для выявления всех пунктов, охваченных или не охваченных выбранной связью; возможность выполнять одноуровневый или многоуровневый анализ влияния с целью указания на совокупность пунктов документа, подверженных данному воздействию;
возможность выполнять одноуровневый или многоуровневый анализ происхождения с целью указания на совокупность исходных пунктов;
Возможность выполнять восходящий или нисходящий анализ покрытия для выявления всех пунктов, охваченных или не охваченных несколькими выбранными связями. На рис. 7.1 показан пример простой прослеживаемости. Требование пользователя прослеживается до трех соответствующих требований к системе в целом. Здесь текст требования пользователя можно видеть вместе с полным набором требований к системе, которые ему соответствуют. Наличие такой объединенной информации позволяет без затруднений контролировать прослеживаемость. На рис. 7.2 показан второй пример.
Доказательство выполнения требований
Смысл примера на рис. 7.1 заключается в том, что показанные три требования к системе в той или иной степени достаточны для выполнения требования пользователя. Но тому, кто не является специалистом в данной области, трудно оценить правильность этого утверждения.
Причина в том, что здесь не представлено его обоснование. Для улучшения ситуации полезно представить доказательство выполнения для каждого требования пользователя. Простая прослеживаемость, демонстрируемая на рис. 7.1, даёт информацию только о том, что три требования к системе играют какую-то роль при доказательстве выполнения требований, но не содержит никаких сведений о том, в чем состоит это доказательство.
Расширенная прослеживаемость представляет собой способ получения доказательства выполнения требования. Обоснование выглядит как отдельный пункт, размещённый между требованием пользователя и соответствующими требованиями к системе, как показано на рис. 7.3.
Доказательство выполнения требования приводится не только в текстовом виде, существует также система специальных обозначений, определяющая способ взаимосвязи требований к системе и обоснования с использованием логических операторов:
конъюнкция (&) означает, что все перечисленные требования к системе обязательно должны участвовать в доказательстве выполнения требования пользователя;
дизъюнкция (or) означает, что любое требование к системе (одно из перечисленных) обязательно должно участвовать в доказательстве выполнения требования пользователя.
Теперь представлено намного больше информации о том, как должны выполняться требования пользователя. Даже тот, кто не является специалистом в данной предметной области, получает возможность более или менее верной оценки важных аспектов обоснования требований. Текст позволяет оценить валидность и полноту логической составляющей обоснования. Оператор делает структуру обоснования более точной.
Привязка требований
Часто доказательство выполнения требования является простым только в привязке к одной или нескольким подсистемам или элементам. В этом случае иногда говорят о «привязке» требований или о «нисходящем потоке» требований. При использовании такого нисходящего потока требований процесс внесения изменений можно упростить. Изменения в требованиях верхнего уровня могут автоматически «спускаться» на более низкие уровни. Простое развитие расширенной прослеживаемости позволяет охватить и подобные случаи. К операторам «and» и «or», используемым для характеристики обоснований, добавляется ещё один, обозначающий идентичность. На рис. 7.8 показан пример использования всех трёх операторов. Символ «=» обозначает идентичность.
