ГОСТ Р ИСО/МЭК12207—2010
h)требования к программным средствам воплощаются в виде базовыхлиний идоводятся до сведе
ния заинтересованных сторон.
7.1.2.3 Виды деятельности и задачи
При реализации проекта необходимо выполнять следующие виды деятельности изадачи в соответ
ствии с принятыми ворганизации политиками и процедурами вотношении процесса анализа требований к
программным средствам.
7.1.2.3.1 Анализ требований к программным средствам
Для каждого программного элемента (или элемента конфигурации, если он определен) данный вид
деятельности состоит из решения следующих задач:
7.1.2.3.1.1 Исполнитель должен установить идокументально оформить следующие требования к про
граммным средствам (включая спецификации характеристик качества):
a) спецификации функциональныххарактеристик и возможностей, включая эксплуатационные, физи
ческие характеристики и условия окружающей среды, при которых будет применяться программная со
ставная часть;
b
) внешние интерфейсы к программной составной части;
c) квалификационные требования;
d) спецификации по безопасности, включая те спецификации, которые относятся к методам функцио
нирования и сопровождения, влиянию окружающей среды и ущербу для персонала;
e) спецификации по защите, включая спецификации, связанные с угрозами для чувствительной ин
формации;
f) спецификации эргономических факторов, включая спецификации, связанные с ручными операция
ми, взаимодействием человека с оборудованием, ограничениями по персоналу и областям, требующим
концентрации внимания ичувствительным к ошибкам человека и уровню его обученности;
д) описание данных и требования к базам данных;
h) инсталляция итребования к приемке поставляемого программного продукта в местах функциониро
вания и сопровождения;
i) требования к документации пользователя;
j) операции пользователя и требования к их выполнению;
k) пользовательские требования к сопровождению.
П р и м е ч а н и е 1 — [8] может быть руководством по спецификации характеристик качества.
П р и м е ч а н и е 2 — Следует определить приоритет выполнения требований к программным средствам.
П р и м е ч а н и е 3 — Рекомендации для получения желаемого уровня удобства применения можно найти
в [25], если приспособленность к применению является важным требованием. Вид процесса, который сосредото
чивается на вопросах приспособленности к применению, приведен в приложении Е.
7.1.2.3.1.2 Исполнитель должен оценить требования к программным средствам, учитывая критерии,
перечисленные ниже. Результаты оценокдолжны быть документально оформлены.
a) прослеживаемость к системным требованиям и к системному проекту;
b
) внешняя согласованность с системными требованиями;
c) внутренняя согласованность;
d) тестируемость;
е) осуществимость программного проекта;
f) осуществимость функционирования и сопровождения.
7.1.2.3.1.3 Исполнитель должен проводить ревизии в соответствии с 7.2.6.
П р и м е ч а н и е — Вслед за успешными оценкой и ревизией следует принимать требования к программ
ным средствам, закреплять их в базовой линии и сообщать об этом всем заинтересованным сторонам. Последу
ющие изменения в базовой линии требований к программным средствам следует оценивать по стоимости, гра
фикам исполнения и воздействиям технических решений.
7.1.3Процесс проектирования архитектуры программных средств
П р и м е ч а н и е — Процесс проектирования архитектуры программных средств в настоящем стандарте
является процессом более низкого уровня, чем процесс реализации программных средств. Пользователи [18]
могут решить, что данный процесс предусматривается процессом проектирования архитектуры в [18] при его
рекурсивном применении.
7.1.3.1 Цель
Цель процесса проектирования архитектуры программных средств заключается вобеспечении про
екта для программных средств, которые реализуются и могут быть верифицированы относительно требо
ваний.
49