Требования к именованию

У каждого требования должен быть уникальный и неизменный идентификатор.

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

Номер восемь, с кружочком

Как-то в одном длинном полете на самолете я разговорился с соседом по имени Дейв, который, как оказалось, тоже имеет отношение к разработке ПО. Я упомянул, что меня интересуют требования. Дейв вытащил из портфеля спецификацию требований к ПО — я уж не знаю, носил ли он ее на всякий случай или она оказалась при нем случайно. Я увидел, что требования в этом документе организованы в виде иерархии, но все списки был маркированными. В некоторых местах глубина иерархии достигала восьми уровней. В списках разных уровней использовались разные маркеры — ○, ■, ♦, и тп, — но у них не было никаких более содержательных меток кроме этих маркеров. Было невозможно сослаться на элемент маркированного списка или отследить его соответствие в дизайне, сегменте кода или тесте.

Нумерация по порядку

Самый простой способ — присвоить каждому требованию уникальный порядковый номер, например UR-9 или FR-26. Серийные средства управления требованиями присваивают такой идентификатор, когда пользователь добавляет новое требование в базу данных. Префикс обозначает тип требования, например FR означает «functional requirement» (то есть «функциональное требование»). При удалении требования номер повторно не используется, поэтому читателю не придется путаться между исходным требованием FR-26 или новым требованием FR-26. Такой простой поход нумерации не обеспечивает логического или иерархического группирования связанных требований, число не подразумевает никакого упорядочения, а названия не раскрывают содержания требования. Вместе с тем это позволяет сохранять уникальные идентификаторы при перемещении требований внутри документа.

Иерархическая нумерация

Это наиболее распространенный способ. Если функциональные требования приводятся в разделе 3.2 спецификации, то все их номера будут начинаться с 3.2. Чем больше цифр, тем больше уровень детализации требования, так что сразу понятно, что 3.2.4.3 является потомком по отношению к 3.2.4. Это способ отличается простотой, компактностью и очевидностью. Ваш текстовый редактор скорее всего сможет назначать номера автоматически. Средства управления требованиями обычно также поддерживают иерархическую нумерацию.

Однако с иерархической нумерацией тоже не все безоблачно. Даже в спецификации среднего размера нумерация может быть весьма длинной. Вдобавок названия, состоящие только из цифр, ничего не говорят о назначении требований. При использовании текстового редактора этот метод не обеспечивает неизменность номеров. Если вы вставите новое положение, то номера всех последующих фрагментов увеличатся. А после удаления или перемещения требования — уменьшатся. Удаление, вставка, слияние или перемещение целых разделов приводит к изменению многих фрагментов. При этом нарушаются все ссылки на эти фрагменты.

Внимание! Однажды один бизнес-аналитик заметил: «Мы не разрешаем людям вставлять требования — сбивается нумерация». Не позволяйте применять неэффективные приемы, которые могут препятствовать эффективной и разумной работе.

Можно усовершенствовать этот способ, пронумеровав важнейшие разделы требований иерархически, а затем выделив отдельные функциональные требования в каждом разделе с помощью короткого текстового кода, после которого следует порядковый номер. Например, если в спецификации требований к ПО есть «Раздел 3.5 — Функции редактора», то требования в нем будут названы ФР-1, ФР-2 и т. д. При этом соблюдается определенная иерархия и структурированность документа, названия достаточно короткие, осмысленные и менее зависят от местоположения в документе. Но это не решает полностью проблему нумерации.

Иерархические текстовые теги

Консультант Том Гилб (Gilb, 1988) предложил текстовую схему иерархических тегов именования требований. Рассмотрим такое требование: «Система должна запрашивать у пользователя подтверждение запроса, когда тот хочет печатать более 10 копий». Этому требованию можно присвоить тег Print.ConfirmCopies, который означает, что это требование является частью функции печати и связано с количеством печатаемых копий. Иерархические текстовые тэги структурированы, их названия осмысленны и не меняются при добавлении, удалении или перемещении остальных требований. Пример спецификации требований к ПО в Приложении В иллюстрирует эту схему, как другие примеры в тексте книги. Этот метод также подходит для нумерации бизнес-правил, если они управляются вручную, а не с помощью специализированного инструмента или хранилища бизнес-правил.

Использование таких текстовых тегов помогает решить еще одну проблему. При иерархической организации между требованиями возникают отношения «родитель–потомок». Если родитель описан, как функциональное требование, отношение между потомком и родителем может быть непонятным. Правильное соглашение предусматривает, что родительское требование должно выглядеть как заголовок или название функции, а не как самостоятельное функциональное требование. Потомки родительского требования в совокупности должны покрывать все его возможности. Вот пример, содержащий заголовок и четыре функциональных требования.

Продукт:	Заказ товаров в интернет-магазине
.Cart	В интернет-магазине должна быть корзина, в которой размещаются все выбранные клиентом товары
.Discount	В корзине должно присутствовать поле для кода скидки. Код скидки принимает вид определенного процента на все содержимое корзины или фиксированную долларовую скидку на конкретные товары в корзине
.Error	При вводе клиентом неверного кода скидки интернет-магазин должен отображать сообщение об ошибке
.Shipping	Корзина должна прибавлять к заказам клиентов стоимость доставки, если клиент заказывает физические товары, которые нужно доставлять

Полный уникальный идентификатор каждого требования создается путем присоединения метки требования к строке, состоящей из меток вышестоящих родителей. Утверждение Product выглядит как заголовок, а не как конкретное требование. Первое функциональное требование обозначено как Product.Cart. Полный идентификатор третьего требования — Product.

Discount.Error. Такая иерархическая схема избавляет от проблем с обслуживанием иерархического нумерования, но теги длинные и им нужно назначать значащие имена, обычно на основе имени соответствующей функции. Может быть сложным обеспечить уникальность, особенно если над набором требований трудится несколько человек. В небольших наборах требований можно упростить схему, совместив иерархическую нумерацию с суффиксом порядкового номера: Product.Cart.01, Product.Cart.02 и т. д. В общем, существует много рабочих схем.