Требования к адаптации места использования
Этот подраздел должен:
а) Определять требования к любым данным или последовательностям инициализации, которые являются специфическими для данного места, задачи, или режима работы (например, значения сетки, пределы безопасности и т.д.);
б) Определять характеристики места или характеристики, связанные с задачей, которые следует изменить, чтобы адаптировать программное обеспечение к конкретной установке.
Функции изделия (Подраздел 2.2Спецификации)
Этот подраздел спецификации должен представлять сводку основных функций, которые будет выполнять программное обеспечение. Например, спецификация для программы бухгалтерского учета может использовать эту часть, чтобы выделить такие функции, как сопровождение счетов клиента, создание отчётов о движении средств клиента и подготовка счетов без упоминания большого количества деталей, которые требуются каждой из этих функций.
Иногда сводка функций, которая необходима для этой части, может быть взята непосредственно из раздела спецификации более высокого уровня (если он существует), который назначает отдельные функции программному изделию. Заметьте, что в целях обеспечения ясности:
а) Функции должны быть организованы таким способом, который делает перечень функций понятным заказчику или любому человеку, читающему документ впервые.
б) Могут быть использованы текстовые или графические методы, чтобы показать различные функции и их связи. Такая схема не предназначается для того, чтобы показать структуру изделия, а просто показывает логические связи между переменными.
Характеристики пользователя (Подраздел 2.3Спецификации)
Этот подраздел спецификации должен описывать общие характеристики пользователей изделия, включающие образовательный уровень, опыт и специальные технические знания. Он не должен использоваться для формулировки конкретных требований, а должен представлять основания, по которым некоторые специфические требования далее определяются в разделе 3 спецификации.
Ограничения (Подраздел 2.4Спецификации)
Этот подраздел спецификации должен обеспечить общее описание любых других позиций, которые будут ограничивать опции разработчика. Они включают:
а) Регулирующие политики;
б) Аппаратные ограничения (например, требования к синхронизации сигналов);
в) Интерфейсы с другими приложениями;
г) Параллельные операции;
д) Функции контроля;
е) Функции управления;
ж) Требования к языку более высокого порядка;
з) Протоколы квитирования сигналов
(например, XON-XOFF, ACK-NACK);
и) Требования к надежности;
к) Критичность применения изделия;
л) Критерии безопасности и защиты.
Допущения и зависимости (Подраздел 2.5Спецификации)
В этом подразделе спецификации должны быть перечислены все факторы, которые влияют на требования, сформулированные в спецификации. Эти факторы не являются архитектурными ограничениями программного обеспечения, это, скорее, любые их изменения, которые могут воздействовать на требования в спецификации.
Например, может быть сделано допущение, что определенная операционная система будет присутствовать на аппаратных средствах, предназначенных для программного изделия. Если в действительности операционная система отсутствует, тогда спецификация должна быть изменена соответствующим образом.
Распределение требований (Подраздел 2.6Спецификации)
Этот подраздел спецификации должен идентифицировать требования, которые могут быть отложены до появления будущих версий системы.
Специфические требования (Раздел 3Спецификации)
Этот раздел спецификации должен содержать все требования к программному обеспечению на уровне детализации, достаточной, чтобы дать проектировщикам возможность разработать систему, удовлетворяющую этим требованиям, а испытателям — убедиться, что система удовлетворяет этим требованиям. В этом разделе каждое сформулированное требование должно восприниматься пользователями, операторами или другими внешними системами. Эти требования должны включать как минимум описание каждого входного воздействия (стимула) на систему, каждого выходного сигнала (отклика) системы и всех функций, выполняемых системой в ответ на входное воздействие или для поддержания выходного сигнала.
Поскольку часто эта часть является самой большой и наиболее важной частью спецификации, применяются следующие принципы:
а) Специфические требования должны быть сформулированы в соответствии со всеми характеристиками, описанными ранее.
б) Специфические требования должны иметь перекрёстные ссылки к более ранним документам, к которым они имеют отношение.
в) Все требования должны быть однозначно идентифицируемы.
г) Необходимо уделить особое внимание оформлению требований, чтобы максимизировать их удобочитаемость.
Перед исследованием специфических способов организации требований полезно осмыслить различные элементы, в которые входят требования, как описано ранее.
Внешние интерфейсы
Этот раздел должен представлять детализированное описание всех входных и выходных данных системы программного обеспечения. Он должен дополнять описания интерфейса, и не должен повторять эту информацию.
Он должен включать содержание и формат следующим образом:
а) Наименование позиции;
б) Описание назначения;
в) Источник входных данных или адресат выходных данных;
г) Допустимый диапазон, точность и/или допуск;
д) Единицы измерения;
е) Синхронизация;
ж) Связи с другими входами/выходами;
з) Форматы/организация экрана;
и) Форматы/организация окна;
к) Форматы данных;
л) Форматы команд;
м) Сообщения о конце.
Функции
Функциональные требования должны определять фундаментальные операции, которые должны выполняться программным обеспечением при принятии и обработке входных данных и обработке и генерации выходных данных. Они обычно перечисляются как формулировки типа «должно», начинающиеся с «Система должна ....,».
Они включают:
а) Проверку достоверности по входам;
б) Точную последовательность операций;
в) Отклики на ненормальные ситуации, включая:
1) Переполнение
2) Средства связи
3) Обработка и устранение ошибок;
г) Влияние параметров;
д) Связь выходов с входами, включая:
1) Последовательности ввода/вывода
2) Формулы для преобразования ввода-вывода.
Может оказаться удобным разбить разделы функциональных требований на подфункции или подпроцессы. Это не означает, что структура программного обеспечения будет организована таким же образом.