7.1.1 Цели процесса определения требований к ПО
Цели данного процесса состоят в том, чтобы:
а) разработать требования верхнего уровня;
б) оценить производные требования верхнего уровня с точки зрения безопасности системы.
7.1.2 Состав работ, выполняемых в процессе определения требований к ПО
Входными данными для процесса определения требований к ПО являются системные требования, описания аппаратного интерфейса и архитектуры системы (если они не включены в системные требования), определяемые процессами жизненного цикла системы, План разработки ПО и стандарты на разработку требований к ПО, определяемые процессом планирования. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, входные данные используют для разработки требований верхнего уровня к ПО. Требования верхнего уровня включают в себя функциональные требования, требования к эффективности, требования к интерфейсу и требования, связанные с безопасностью. Результатами данного процесса являются документы «Спецификация требований к ПО» (12.13) и «Спецификация требований к интерфейсу» (12.14). Процесс определения требований к ПО считают завершенным, когда достигнуты его цели и цели связанных с ним интегральных процессов. Процесс определения требований к ПО должен обеспечить следующее:
— анализ функциональных системных требований и требований к интерфейсам, которые предназначены для программной реализации, на отсутствие противоречий, несоответствий и неопределенностей;
— регистрацию для последующего уточнения или исправления и передачи в качестве входной информации обратной связи к исходным процессам тех входных данных процесса определения требований к ПО, которые оказались неадекватными или некорректными;
— спецификацию в документе требований верхнего уровня каждого системного требования, которое предназначено для программной реализации;
— определение всех требований верхнего уровня, соответствующих системным требованиям, которые связаны с предотвращением риска;
— верифицируемость, непротиворечивость и соответствие требований верхнего уровня стандартам на разработку требований к ПО;
— установление требований верхнего уровня в количественных показателях с погрешностями в тех случаях, когда это необходимо;
— требования верхнего уровня не должны описывать детали проектирования или верификации, исключая определения и обоснования ограничений проектирования;
— трассируемость каждого системного требования, которое предназначено для программной реализации, к одному или нескольким требованиям верхнего уровня для ПО;
— трассируемость каждого требования верхнего уровня, кроме производных требований к одному или нескольким системным требованиям;
— оценку производных требований верхнего уровня с точки зрения безопасности системы.
7.2 Процесс проектирования ПО
Требования верхнего уровня к ПО уточняют далее в процессе проектирования ПО одной или несколькими итерациями, чтобы разработать архитектуру ПО и требования нижнего уровня, которые могут быть непосредственно использованы для получения исходного кода.
7.2.1 Цели процесса проектирования ПО
Цели данного процесса состоят в том, чтобы:
а) разработать архитектуру ПО и требования нижнего уровня на основе требований верхнего уровня;
б) оценить с точки зрения безопасности системы производные требования нижнего уровня.
7.2.2 Состав работ, выполняемых в процессе проектирования ПО
Входными данными процесса проектирования ПО являются требования к ПО, План разработки ПО и стандарты на процесс проектирования ПО. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, эти входные данные используются в процессе проектирования для разработки архитектуры ПО и требований нижнего уровня. Требования нижнего уровня могут включать в себя одно или несколько требований более низких уровней. Основным выходным результатом процесса является документ «Описание проекта ПО» (12.16), который содержит описание архитектуры ПО и требования нижнего уровня. Если это предусмотрено условиями контракта, часть проекта, имеющая отношение к интерфейсам, может быть включена в документ «Описание проекта интерфейса» (12.17), а часть проекта, имеющая отношение к базам данных, может быть включена в документ «Описание проекта базы данных» (12.18). Процесс проектирования ПО считают завершенным, когда удовлетворены его цели и цели связанных с ним интегральных процессов. Процесс проектирования ПО должен обеспечивать следующее:
— архитектура ПО и требования нижнего уровня, разработанные в процессе проектирования ПО, должны соответствовать стандартам на процесс проектирования ПО и быть прослеживаемыми, верифицируемыми и непротиворечивыми;
— производные требования должны быть определены и проанализированы для гарантии того, что они не противоречат требованиям верхнего уровня;
— работы процесса проектирования ПО могут привести к появлению возможных отказов в ПО или, наоборот, предотвратить их. Использование метода разбиения или других архитектурных методов при проектировании ПО может изменить установленный уровень критичности ПО для некоторых компонентов ПО. В таких случаях должна быть определена информация о производных требованиях, позволяющая обеспечить процесс оценки безопасности системы;
— необходимо контролировать поток управления и поток данных, когда это связано с требованиями безопасности;
— реакция на отказные ситуации должна быть согласована с требованиями безопасности;
— при обнаружении в процессе проектирования ПО неадекватных или некорректных входных данных следует осуществлять обратную связь с процессами жизненного цикла системы, с процессами определения требований к ПО или с процессом планирования ПО для исследования проблемы или исправления входных данных.
Примечание — На современном уровне развития технологии разработки ПО не применяют количественную корреляцию между сложностью и достигаемой безопасностью. Тем не менее, в процессе проектирования ПО необходимо избегать сложных конструкций, поскольку с увеличением сложности ПО становятся более трудными верификация и доказательство того, что удовлетворены цели безопасности.
7.2.3 Проектирование модифицируемого пользователем ПО
Для разработки ПО, которое предназначено для модификации пользователями, необходимы дополнительные требования. Модифицируемый компонент — часть ПО, которая предназначена для изменения пользователем, а немодифицируемый компонент не допускает изменения пользователем. Модифицируемое пользователем ПО может широко варьироваться по сложности. ПО любого уровня может включать в себя модифицируемые компоненты. Требования для проектирования модифицируемого пользователем ПО следующие:
— немодифицируемый компонент должен быть защищен от модифицируемого компонента, чтобы предотвратить влияние на безопасность функционирования немодифицируемого компонента.
Эта защита может быть обеспечена аппаратными, программными, инструментальными средствами, используемыми для реализации изменений, или их комбинацией;
— нужно показать, что специально предназначенные для реализации изменений средства являются единственно допустимыми для модификации.
7.2.4 Проектные решения уровня ЭКПО