ГОСТ Р ИСО/МЭК 15026-4—2016
7.9.1 Соответствующие действия и задачи
Действия постандарту1528В
Действия постандарту 12207
6.4.1.3 с) Анализируйте и поддерживайте тре
бования заинтересованной стороны.
1) Проанализируйте полный набор выявляе
мых требований.
6) Обеспечьте целостность и прослеживае
мость системных требований к требованиям
заинтересованной стороны
6.4.1.3.3 Оценка требований. Эта деятельность состоит из ре
шения следующих задач:
6.4.1.3.3.1 В проекте необходимо анализировать полную сово
купность выявленных требований.
6.4.1.3.4 Согласование требований. Этадеятельность состоит
из решения следующих задач:
6.4.1.3.4.2 В проекте должна предусматриваться обратная
связь от проанализированных требований ксоответствующим
правообладателям для гарантии того, что их потребности и
ожидания были правильно зафиксированы и выражены.
6.4.1.3.4.3 В проекте необходимосовместно с правообладате
лями определить корректность выражения их требований
7.9.2 Указания и рекомендации по гарантии
Подмножество критических свойств должно определяться путем анализа полного набора требо
ваний. представленных заинтересованными сторонами. При том что заинтересованные стороны опре
деляют свои собственные требования, некоторые из них будут отмечены как требующие высокой уве
ренности в их достижении из-за их связи с важными влияющими на свойства системы последствиями,
рисками, регулирующими положениями или другими требованиями (например, защита от взлома, за
щищенность). Требования, для которых необходима высокая уверенность, могут быть использованы
для определения критических свойств системного или программного продукта. Проект должен помочь в
таком выборе с технической точки зрения, посредством, например, определения дополнительных
рисков, последствий, связанных с ними неопределенностей и требований соответствия.
В рамках отбора критических свойств проект должен определить предварительные требования
к демонстрации достижения этих свойств, акцентируя особое внимание на компромиссах, связанных
с допущением рисков заинтересованной стороной. Заинтересованные стороны должны определить
допустимость отказа, ухудшения, нарушений безопасности или потерь, например, деградированных
режимов функционирования. Кроме того, в проекте должны быть идентифицированы все культурные,
социальные и организационные аспекты системы, которые могут повлиять на достижение или демон
страцию достижения определенного свойства. В этих действиях могут быть полезны накопленный опыт
и записи о предыдущих версиях или аналогичных системах и рабочих средах, а также известные на
мерения или прогнозы использования системы в соответствующей среде.
Для отбора наиболее важных, критических для обеспечения гарантийных требований свойств
проект должен установить приоритеты. Выбранные критические свойства вместе с объяснениями и
обоснованием их выбора должны быть документированы, стать частью системы контроля конкретной
потребности заинтересованной стороны и храниться для использования по мере необходимости в воз
можных расследованиях. Подобная документация и сопровождение обоснования являются составной
частью поддержки отслеживания зависимости требований заинтересованной стороны от потребностей
заинтересованной стороны. Отобранные критические свойства используются для определения гаран
тийных требований верхнего уровня.
При анализе требований заинтересованной стороны необходимо учитывать, что у каждой заинте
ресованной стороны — свои особенности и система ценностей.
Примечание — Для определения целесообразности требований на протяжении жизненного цикла про
ект должен реализовываться сучетом ряда обоснованных технологий заинтересованных сторон. Для определения
целесообразности требований и предотвращения модификаций, вызывающих нежелательные изменения затрат,
графика и/или производительности в жизненном цикле (когда о системе становится известно больше технических
подробностей), необходимо рассматривать весь жизненный цикл.
При реализации проекта нужно обязательно стремиться устранить неопределенности в наборе
выявленных требований заинтересованной стороны. Необходимо рассмотреть и определить как функ
циональные. так и нефункциональные требования, в которых должна быть отражена информация о
пиковых объемах работы, сроках ежемесячных отчетов и практическом опыте разработки и функцио
нирования. Подобный подход должен свести к минимуму технически ориентированные риски, обеспе-
14