Требования к внешнему интерфейсу определяют оборудование, программное обеспечение или элементы баз данных, с которыми система или компонент должны взаимодействовать. Информация этого раздела необходима для обеспечения взаимодействия с внешними компонентами. Если у разных частей продукта разные внешние интерфейсы, то следует детализировать требования для каждой такой части.
В сложной системе с множеством подкомпонентов следует использовать раздельные спецификации для интерфейсов или спецификацию системной архитектуры. В документацию по интерфейсу можно включить ссылки на материал из других документов.
Интерфейсы пользователя
Для описания интерфейсов пользователя нужно указать логические характеристики каждого пользовательского интерфейса, который необходим системе, например:
- ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продукта, которые необходимо соблюдать;
- стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления и т.п.;
- конфигурация экрана или ограничения разрешения;
- стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;
- быстрые клавиши;
- стандарты отображения сообщений;
- стандарты конфигурации для упрощения локализации программного обеспечения;
- специальные возможности для пользователей с проблемами со зрением.
Если в спецификации требований к программному обеспечению говорится об улучшении существующей системы, то целесообразно включить в документ изображения экранов в том виде, как они будут реализованы. Для разработчиков уже заданы ограничения существующей системой, поэтому можно заранее представить, как будут выглядеть измененные, а, возможно, новые экраны. На рисунке 1 представлен шаблон спецификации требования к интерфейсу пользователя.
Интерфейсы оборудования
В этом разделе указываются характеристики каждого интерфейса между компонентами программного обеспечения и оборудованием системы. В описание могут входить типы поддерживаемых устройств, протоколы обмена данными между программным обеспечением и оборудованием, а также протоколы взаимодействия, которые будут использоваться. Ниже приведен шаблон спецификации оборудования.
Спецификация интерфейсов программного обеспечения
В спецификации должны быть указаны соединения продукта и других компонентов программного обеспечения (идентифицированные по имени и версии), в том числе базы данных, операционные системы, средства, библиотеки и интегрированные коммерческие компоненты. Необходимо указать назначение элементов сообщений, данных и элементов управления, обмен которыми происходит между компонентами программного обеспечения. Приводятся службы, необходимые внешним компонентам программного обеспечения, и природу взаимодействия между компонентами. Приводится описание данных, к которым будут иметь доступ компоненты программного обеспечения.
Интерфейсы передачи информации
В случае необходимости следует указать требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и электронные формы:
- соответствующие форматы сообщений;
- особенности безопасности взаимодействия или шифрования;
- частота передачи данных;
- механизмов синхронизации и т.п.
Шаблон спецификации приведен на рис. 4.
Матрица требований
Итогом работы по выявлению и спецификации требований является матрица требований. Матрица требований позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.
По мере того, как сбор требований завершается – необходимо выполнить их «балансировку», то есть, выполнить оценку, какие из выявленных требований войдут в проект.
Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта. Процесс балансировки основан на сочетании интуиции и здравого смысла.
Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта.
Матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.
Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, мы снижаем риск «промахнуться мимо ожиданий заказчика».
В следующей статье приводится структура одного из основополагающих документов - Концепции проекта.