Пропуск каких-либо серьёзных данных — самый популярный недочёт требований (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 — это надежный метод для обнаружения недостающих требований.