2. Эксплуатационные требования. Они определяют значения
измеряемых переменных, характеризующих работу программного изделия. Эксплуа
тационные требования могут быть представлены либо в виде отдельных требова
ний, либо в виде количественных атрибутов функциональных требований.
Количественные требования не должны фиксироваться в виде качественных характеристик типа "быстрый ответ", а должны быть записаны, например, в виде "время ответа должно быть не более X сек", или вместо "в большинстве случаев" должно быть указано "для У% случаев среднее время ответа должно быть менее 2 сек" и т. п.
Атрибуты эксплуатационных характеристик могут быть также представлены в виде диапазона значений.
3. Требования к интерфейсам. Эти требования описывают эле
менты технических средств, программного обеспечения, баз данных, с которыми
должен взаимодействовать программный продукт. Требования к интерфейсам с тех
ническими средствами могут определять необходимую их конфигурацию. Требова
ния к программному обеспечению могут включать требования к типу и версии опе
рационной системы, прикладным пакетам, типу СУБД. Требования к внешним ин
терфейсам могут потребовать, например, использования конкретного сетевого про
токола передачи информации, определенного языка описания документов и т.п.
Требования к интерфейсам могут быть проиллюстрированы с помощью специальных структурных схем, описывающих взаимодействие программного изделия с окружающей обстановкой.
4. Операционные требования. Они определяют, как система бу
дет работать и как она будет связываться с операторами или пользователями про
граммного изделия. Операционные требования должны включать все интерфейсы
пользователя и требования к человеко-машинному взаимодействию. Примерами
таких требований являются форматы экранов, содержание сообщений об ошибках,
справочная информация, выдаваемая в качестве подсказок пользователю и т.п.
5. Требования к ресурсам. Они обычно устанавливают верхние
пределы для характеристики технических средств, таких как скорость процессора,
емкость внешней и оперативной памяти и т.д.
6. Требования на верификацию программного изделия и на
приемное тестирование. Они определяют, как проверяется корректность
принимаемых решений на каждом этапе ЖЦПИ и могут включать требования к мо
делированию окружающей обстановки и интерфейсов программного изделия. Тре
бования к приемному тестированию определяют условия проведения аттестации
разработанного программного изделия.
7. Требования к защите информации. Они включают требо
вания к обеспечению конфиденциальности и целостности информации. Примерами
таких требований могут служить команды блокировки, системы паролей и защиты
от вирусов, ограничение доступа к данным и запрещение отдельных операций с
данными для разных категорий пользователей.
8. Требования к качеству. Они определяют специфические атрибу
ты программного изделия, которые гарантируют, что функционирование изделия
будет соответствовать поставленным целям. Везде, где это возможно, показатели
качества должны быть выражены в количественных величинах.
16
Такие показатели качества, как надежность программного изделия, пригодность его к сопровождению, безопасность описываются отдельно.
9. Требования к надежности. Они определяются либо значением
допустимого среднего времени между отказами, либо значением минимального
времени между отказами.
10. Требования на пригодность к сопровождению. Они могут
быть представлены требованиями простоты исправления ошибок (при отказах) лег
кости адаптации к конкретным операционным условиям и простоты модернизации
программного изделия при изменении требований пользователя и при совершенст
вовании программного изделия в процессе его эксплуатации.
Эти требования должны быть по возможности представлены количественными показателями, такими, как время исправления отказа или коэффициент готовности. Они могут также включать ряд ограничений, отражающих возможности организации, занятой сопровождением.
11. Требования к безопасности. Они могут определять ряд до
полнительных требований к программному изделию, которые обусловлены опасно
стью отказов программного изделия. При этом могут быть указаны отдельные функ
ции, отказы, при выполнении которых могут привести к серьезным последствиям
(для людей, имущества и т.п.).
12. Требования к документации. Они обычно дополняют требо
вания, содержащиеся в стандартах на документацию.
1.4.4. Атрибуты требований к программному изделию
Каждое требование к программному изделию после всестороннего изучения и согласования должно быть документировано. При этом описание каждого требования должно включать следующие атрибуты:
1) идентификатор, обеспечивающий возможность контроля реализа
ции этого требования в течение всех фаз ЖЦПИ;
2) уровень важности, указывающий, насколько существенным явля
ется это требование, может ли оно в дальнейшем обсуждаться и изменяться или же
оно является категорическим;
3) приоритет, указывающий некоторый порядок очередности в выполне
нии этого требования при планировании работ и при проектировании изделия;
4) стабильность, отражающая степень постоянства требования. Долж
ны быть отмечены все те требования, которые могут быть изменены на протяжении
ЖЦПИ в результате получения дополнительной информации об изделии;
5) пригодность к верификации, означающая возможность про
верки присутствия данного требования на каждой фазе разработки, демонстрации
того, что требование реализовано в проекте с помощью либо тестовых прогонов,
либо в результате сквозных просмотров.
При описании требований особое внимание должно быть уделено ясным и четким формулировкам, обеспечивающим однозначную интерпретацию каждого требования.
В перечне требований к программному изделию должны быть учтены все требования пользователя и для каждого возможного набора входных данных должны быть точно описаны действия, выполняемые программным изделием.
Наконец, совокупность требований должна содержать непротиворечивые требования. Несогласованность требований может возникать при использовании разных терминов для описания одинаковых сущностей и, наоборот, один и тот же термин - для описания разных предметов. Другим источником несогласованности могут быть случаи, когда одновременно должны выполняться несовместимые действия или выполняться в недопустимой последовательности. Противоречивость требова-
17
ний может проявиться и в случае дублирования требований, особенно, когда одно требование перекрывает другое.
1.4.5. Документ «Требования к программному изделию»
Выходным материалом рассматриваемой фазы исследований должен быть документ «Требования к программному изделию». Главным показателем качества этого документа является полнота охвата требований пользователя. Для контроля и доказательства полноты в документ целесообразно поместить таблицу (матрицу), показывающую, как требования пользователя соотносятся с требованиями к программному обеспечению. Таблица позволяет организовать трассировку требований как вручную, так и с использованием автоматизированных средств.
Непротиворечивость описания требований должна проверяться и при проведении критического обзора документа.
Основными в документе являются функциональные требования, которые структурируются по нисходящему принципу с последовательной детализацией требований предыдущего, более высокого уровня.
Нефункциональные требования должны быть подключены к функциональным, поэтому они могут появиться на всех уровнях иерархии функциональной декомпозиции.
Документ не должен включать описания деталей реализации программного изделия, т.е. функциональные требования должны отражать лишь то, что должен выполнять программный продукт. Многие из функциональных требований вытекают из схем потоков данных, которые являются результатом структурного системного анализа проектируемого продукта. При этом схема потоков данных верхнего уровня дает общий обзор функций будущего изделия.
В документе каждое требование, снабженное идентификатором и атрибутами степени важности и приоритета, должны иметь ссылку на документ «Требования пользователя для облегчения обратной трассировки».
Документ «Требования к программному изделию» должен быть написан на естественном языке. В рассмотрении и критическом обзоре этого документа, кроме разработчиков, принимают участие пользователи, операционный персонал и менеджеры, поэтому стиль и форма изложения требований должна быть понятна всем участникам этой фазы.
Вместе с тем при описании ряда специфических требований может потребоваться использовать формальные языки описания спецификаций, которые позволяют описать требования более строго без нежелательных неточностей и многозначности естественного языка. В этом случае формальное описание (например, в виде таблиц или деревьев решений и т.п.) должно быть дополнено пояснениями на естественном языке.
Все установленные требования к программному изделию включаются в соответствующий раздел технического задания.
1.5. Архитектурное проектирование программного изделия
1.5.1. Общее содержание работ фазы
Фаза архитектурного проектирования может быть названа фазой "принятия решения". Цель этой фазы - определить совокупность компонент программного изделия и их интерфейсы, чтобы дать каркас для последующей разработки программного изделия. Архитектурный проект должен охватывать все требования, сформулированные на предыдущей фазе.