Пропуск каких-либо важных данных — самый распространенный недостаток требований (Jones, 1997). Обнаружить их в процессе повторного просмотра требований очень трудно, поскольку они просто невидимы! Предлагаемые далее приемы позволяют выявить упущенные требования.
| Ловушка Остерегайте паралича аналитического процесса: не тратьте слишком много времени на выявление требований, пытаясь не упустить ни одно из них. Вы никогда не выявите их все сразу! |
· Раскладывайте требования высокого уровня на простейшие составляющие — это позволит понять, чего же именно просят пользователи. Из-за неясности требований высокого уровня, предоставляющих клиентам свободу интерпретации, возможно несовпадение представлений клиента о продукте и тем, что создает разработчик. Вот некоторые неточные и расплывчатые термины, которых следует избегать: обеспечивать поддержку, предоставлять возможность, разрешать, обрабатывать и управлять.
· Убедитесь, что все классы пользователей предоставили вам информацию и для каждого варианта использования определена по крайней мере одна роль.
· Трассируйте требования к системе, варианты использования, списки откликов на события и бизнес-правила в детализирующие их функциональные требования. Это позволит вам быть уверенным, что аналитик описал всю необходимую функциональность.
· Для выявления недостающих требований проверяйте пограничные значения. Предположим, в одном требовании указано: «Если стоимость заказа меньше $100, стоимость доставки будет равна $5,95", а в другом — «Если стоимость заказа превышает $100, стоимость доставки составляет 5% от общей стоимости заказа». А как быть, если стоимость заказа составляет ровно $100? Это не оговорено, значит, отсутствует соответствующее требование.
|
|
· Используйте разнообразные формы представления информации о требованиях. Трудно прочитать большой объем текста и заметить, что чего-то не хватает. Модели анализа визуально представляют требования высокого уровня абстракции — лес, а не отдельные деревья. Рассматривая модель, вы можете заметить, что от одною блока к другому должна идти стрелка; это тоже недостающее требование. Подобного рода ошибку легче заметить на рисунке, чем в длинном списке требований, который сливается перед глазами. Подробнее о моделях анализа — в главе 11.
Один из точных способов поиска недостающих требований — создать матрицу CRUD (Create, Read, Update, Delete — создание, чтение, обновление, удаление). Она позволяет соотнести действия системы с элементами данных (отдельными или их совокупностями), в результате вы получаете представление о том, где и как каждый элемент денных создается, считывается, обновляется и удаляется. Некоторые добавляют к названию матрицы букву L указывая, что элемент данных является списком (List) (Ferdinandi, 2002). В зависимости от способов анализа требований, которые вы используете, удается исследовать различные типы соответствий, в том числе:
· элементы данных и системные события (Robertson и Robertson,1999);
· элементы данных и задачи пользователей или варианты использования (Lauesen, 2002);
· классы объектов и системные события (Ferdinandi, 2002);
· классы объектов и варианты использования (Armour и Miller, 2001).
Наборы требований со сложной булевой логикой (несколько операторов «И», «ИЛИ» и «НЕ») часто оказываются неполными, Если для комбинации логических условий не определено соответствующее функциональное требование, разработчику приходится догадываться, как же должна действовать система, или искать ответ на этот вопрос. Чтобы убедиться, что вы рассмотрели все возможные ситуации, представляйте сложную логику с помощью таблиц и деревьев решений (подробнее — в главе 11).
|
|
| Элемент данных Вариант использования | Заказ | Химикат | Сотрудник, разместивший заказ на химикат | Каталог поставщика |
| Местоположение заказа | С | Ч | Ч | Ч, Ук |
| Изменение заказа | О,Уд | Ч | Ч, Ук | |
| Управление описью химикатов | С, О, Уд | |||
| Сообщение о заказе | Ч | Ч, Ук | Ч, Ук | |
| Редактировать данные колонки «Сотрудник, разместивший заказ на химикат» | С, О, Ук |
На рис. 7-2 показана матрица CRUDL для элементов данных и вариантов использования определенной области Chemical Tracking System. Каждая ячейка указывает, как вариант использования, определенный в крайнем левом столбце, взаимодействует с каждым элементом данных. Вариант использования может Создать - (С) (Create), Читать – (Ч) (Read), Обновить – (О) (Update), Удалить – (Уд) (Delete) или Указать в виде списка – (Ук) (List) элемент данных. После создания матрицы посмотрите, не появилась ли одна из этих букв в какой-либо ячейке столбца. Если коммерческий объект обновлен, но до этого его не создали, откуда он взялся? Обратите внимание, что ни одна ячейка в колонке с именем «Сотрудник, разместивший заказ на химикат» не содержит «Уд». То есть, ни в одном из случаев использования на рис. 7-2 нельзя удалить сотрудника из списка людей, заказывавших химикаты. Интерпретировать это можно тремя способами:
|
|
Рис. 7-2. Пример матрицы CRUDI-для Chemical Tracking System
· удаление сотрудника, разместившего заказ на химикат, не является ожидаемой функцией Chemical Tracking System;
· мы пропустили вариант использования, который удаляет сотрудника, разместившего заказ на химикат;
· вариант использования «Редактировать данные колонки «Сотрудник, разместивший заказ на химикат»» некорректный. Предполагается, что пользователь может удалить из списка сотрудника, разместившего заказ на химикат, но в настоящее время эта функциональность не указана в вариантах использования. Мы не знаем, какая интерпретация правильна, но CRUDL — это надежный способ для обнаружения недостающих требований.