2.1.1.2Характеристики программных требований

Перечислим основные характеристики программных требований:

Недвусмысленность

Должен существовать только один путь интерпретации требования. Иногда двусмысленность проявляется в виде неопределенных акронимов.

Пример:

Треб.1: Система не должна принимать пароли более 15-ти символов.

Не совсем ясно, что система должна делать:

• Система не должна позволять пользователю вводить более чем 15 символов.

• Система должна отсекать введенную строку до 15-ти символов.

• Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.

Исправленное требование содержит пояснение:

Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.

Тестируемость (Возможность Проверки)

Тестеры должны иметь возможность проверить, было ли требование реализовано корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы быть пригодным для тестирования, требование должно быть ясным, точным и недвусмысленным. Использование некоторых слов может сделать требование невозможным для тестирования:

• Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.

• Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.

• Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).

Треб.1: Система должна препятствовать одновременному доступу большого числа пользователей.

Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000?

Ясность (Краткость, Сжатость, Простота, Точность)

Требования не должны содержать ненужных выражений или информации. Они должны быть изложены кратко и просто:

Треб.1: Иногда пользователь будет вводить Airport Code (Код Аэропорта), который система будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города.

Это предложение может быть заменено на более простое:

Треб.1: Система должна идентифицировать аэропорт на основании Airport Code (Кода Аэропорта) или City Name (Названия Города).

Корректность

Если требование содержит факты, эти факты должны быть достоверны:

Треб.1: Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%)

Налог зависит от штата, так что представленная цифра в 6 % - некорректна.

Понятность

Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может».

Реалистичность (Правдоподобность, Выполнимость)

Требование должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы.

Треб.1: Система должна иметь интерфейс на естественном языке, который будет понимать команды на английском языке.

Это требование может быть нереальным из-за короткого периода времени разработки.

Независимость

Чтобы понять требование, не нужно знать какое-либо другое требование.

Треб.1: Список доступных рейсов должен включать номер рейса, время отправления и время прибытия для каждого отрезка пути.

Треб.2: Он должен быть отсортирован по ценам.

Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно.

Элементарность

Требование должно содержать отдельный трассируемый элемент (для которого возможно отслеживание связи):

Треб.1: Система должна предоставлять возможность бронировать рейс, покупать билет, бронировать номер в гостинице, бронировать машину, а также предоставлять информацию о развлечениях.

Это требование содержит пять элементарных требований, которые затрудняют трассировку. Предложения, включающие предлоги «и» или «но» должны быть пересмотрены на предмет разделениях их на элементарные требования.

Необходимость

В требовании нет необходимости, если:

• ни одному заинтересованному лицу требование не нужно;

• удаление требования не повлияет на систему.

Пример требования, которое может быть удалено, т.к. оно не предоставляет никакой новой информации:

Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы.

Независимость от Реализации (Абстрактность)

Требования не должны содержать ненужной информации о дизайне и реализации системы:

Треб.1: Информация должна храниться в текстовом файле.

Решение того, каким образом информация будет храниться, и затем передаваться пользователю, должно приниматься дизайнерами или архитекторами системы.

Постоянство

Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные.

Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации:

Треб.1: Дата должна отображаться в формате мм/дд/гггг.

Треб.1: Дата должна отображаться в формате дд/мм/гггг.

Иногда возможно разрешить конфликт путем анализа условий, которые явились источником данных требований. Например, если Треб.1 поступило от американского пользователя, а Треб.2 от французского, то предыдущие требования могут быть переписаны следующим образом:

Треб.1: Для пользователей США дата должна отображаться в формате мм/дд/гггг.

Треб.2: Для пользователей Франции дата должна отображаться в формате дд/мм/гггг.

Немногословность

Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием:

Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь.

Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.

Первое требование (относящееся только к дате рейса) является частью второго требования (относящееся к любой дате, вводимой пользователем).

Завершенность

Требование должно быть описано для всех возможных условий.

Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев.