1.3 Трассировка (Связь) между Требованиями
Трассировка – это способ представления отношений между требованиями различного уровня в системе. Она помогает определить источник любого требования. Рисунок 1.1. показывает, как требования переходят от самого верхнего уровня к нижнему. Каждая потребность обычно соответствует нескольким функциональным особенностям. Обычно это отношение «многие-ко-многим», т.к. одна потребность может трассироваться ко многим функциональным особенностям, но из нескольких потребностей может быть получена одна функциональная особенность. Одна потребность, соответствующая одной функциональной особенности – это также общий случай. Функциональные особенности соответствуют сценариям использования в отношении «многие-ко-многим». Функциональные особенности также соответствуют дополнительным требованиям в отношении «многие-ко-многим».
Каждый сценарий использования соответствует одному или более сценарию (алгоритму), таким образом, их тип отношений – «один-ко-многим». Сценарии (алгоритмы) соответствуют тестовым сценариям в отношении «один-ко-многим».
Трассировка играет несколько важных ролей:
Подтверждение, что реализация удовлетворяет всем требованиям: Все, что требовал заказчик, было реализовано.
Подтверждение, что приложение делает только то, что было заказано: Не реализовывать то, что заказчик никогда не просил.
Анализ воздействия: Какие элементы будут затронуты при добавлении новых требований или изменении текущих?
Помощь в управлении изменениями: Когда некоторые требования изменяются, мы хотим знать, какие тестовые сценарии должны быть изменены, чтобы протестировать данное изменение.
Элемент трассировки – это элемент проекта, который должен быть получен (трассирован) из другого элемента. В терминах RequisitePro под ним понимается все, что принадлежит какому-либо типу требований. Примеры типов требований в RequisitePro: потребности заинтересованных лиц, функциональные особенности, сценарии использования, действующие лица и термины справочника. В RequisitePro есть очень удобный способ отображения трассировки (связи) с помощью специальных представлений (views).
1.4 Характеристики Хорошего Требования
Требование должно удовлетворять нескольким критериям для того, чтобы считаться «хорошим требованием» [HUL05][LEF03][LUD05][YOU01]. Хорошее требование должно иметь следующие характеристики:
|
|
|
|
|
|
|
|
Помимо этих критериев для отдельных требований, для набора требований применяются три критерия. Требования должны быть:
Постоянными.
Немногословными.
Завершенными.
В данной книге используется пример проекта он-лайн агентства путешествий, как показано на Рисунке 1.2. Возможно, Вы знакомы с приложением этого типа, т.к. различные его вариации встречаются на нескольких сайтах. Проект достаточно сложный, чтобы показать возможные отношения между различными типами требований, но в то же время, достаточно мал, чтобы его можно было легко понять. Большинство примеров в данной главе (и в других главах) относятся к этому проекту.
Рисунок 1.2. Домашняя страница он-лайн агентства путешествий.
Рассмотрим каждый из критериев хорошего требования и приведем несколько примеров.
Недвусмысленность
Должен существовать только один путь интерпретации требования. Иногда двусмысленность проявляется в виде неопределенных акронимов.
Треб.1: Система должна быть реализована с использованием ASP.
Что значит ASP – Active Server Pages или Application Service Provider? Для разрешения этой ситуации, мы можем указать полное наименование и предоставить акроним в скобках:
Треб.1: Система должна быть реализована с использованием Active Server Pages (ASP).
Другой пример:
Треб.1: Система не должна принимать пароли более 15-ти символов.
Не совсем ясно, что система должна делать:
Система не должна позволять пользователю вводить более чем 15 символов.
Система должна отсекать введенную строку до 15-ти символов.
Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.
Исправленное требование содержит пояснение:
Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.
Иногда двусмысленность может проявляться местоположением определенного слова:
Треб.1: На экране «Stored Flight» пользователь может только просмотреть одну запись.
Значит ли это, что пользователь может «только просмотреть», не удалять и не изменять, или же что пользователь может просмотреть «только одну» запись – не одну, не две и не три?
Один из способов решения проблемы – это переписать требование с точки зрения системы:
Треб.1: На экране «Stored Flight» система должна отображать только один рейс.
Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование реализовано корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы быть пригодным для тестирования, требование должно быть ясным, точным и недвусмысленным. Использование некоторых слов может сделать требование невозможным для тестирования [LUD05]:
Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.
Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Такие требования могут выглядеть примерно следующим образом:
Треб.1: Функция поиска должна позволять пользователю искать заказ на основе Фамилии, Имени, Даты, и т.д.
В этом требовании все критерии поиска должны быть детально перечислены. Дизайнер и разработчик не могут догадаться, что пользователь имел в виду под сокращением «и т.д.».
Другие проблемы могут возникнуть при использовании двусмысленных слов или фраз:
Изменение фраз: соответственно, как требовалось, если необходимо, должен быть рассмотрен.
Неопределенные слова: обслуживать, обрабатывать.
Пассивный залог: предмет предложения получает действие глагола, а не выполняет его.
Треб.1: Код аэропорта должен быть введен пользователем.
Треб.2: Код аэропорта должен быть введен.
Первый пример показывает классический случай пассивного залога. В активном залоге это предложение бы звучало так: «Пользователь должен ввести код аэропорта». Второй пример показывает другой результат использования пассивного залога – когда пропускается агент, исполняющий действие. Кто должен вводить этот код - система или пользователь?
Неопределенные местоимения: немного, много, больше всего, несколько, сколько-нибудь, кто-то, что-то, и т.д.
Треб.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: Для пользователей Франции дата должна отображаться в формате дд/мм/гггг.
В итоге это приведет к следующему требованию:
Треб.3: Даты должны отображаться в формате, принятом в веб-браузере пользователя.
Другой пример прямого конфликта может быть рассмотрен на следующих двух требованиях:
Треб.1: Должна быть доступна оплата через PayPal.
Треб.2: Должна приниматься оплата только через кредитные карты.
В этом случае конфликт не может быть разрешен путем добавления условий, поэтому одно из требований должно быть изменено или удалено.
Косвенный конфликт возникает, когда требования описывают разную функциональность, но выполнить оба этих требования одновременно невозможно:
Треб.1: Система должна иметь интерфейс на естественном языке.
Треб.2: Система должна быть разработана в течение трех месяцев.
Некоторые требования не конфликтуют сами по себе, а используют несовместимую терминологию:
Треб.1: Пользователь должен иметь возможность сравнить цены на рейсы вылета и прибытия по отношению с другими близлежащими аэропортами.
Треб.2: Рейсы вылета и возвращения должны быть отсортированы по наименьшему количеству остановок.
Немногословность
Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием:
Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.
Первое требование (относящееся только к дате рейса) является частью второго требования (относящееся к любой дате, вводимой пользователем).
Завершенность
Требование должно быть описано для всех возможных условий:
Треб.1: Страна назначения не должна отображаться для рейсов в пределах США.
Треб.2: Для рейсов через море система должна отображать страну назначения.
А как же насчет рейсов в Мексику и Канаду? Они не входят в состав США, но и не отделены морями от США.
Все необходимые требования должны быть приведены. Это условие является наиболее сложным для выполнения. Действительно, невозможно быть уверенным, что были собраны все требования, и за неделю до выпуска продукта одно из заинтересованных лиц не скажет: «Я забыл упомянуть, что мне нужна еще одна функциональная особенность в приложении».
Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев:
Изменяемый: Если требование элементарное и немногословное, то оно обычно изменяемое.
Трассируемое: Если оно краткое и имеет уникальный идентификатор (ID), то оно обычно трассируемое (способное к отслеживанию связи).