Абстрактные формулировки
Абстрактные формулировки
На днях читала требования молодого аналитика и там были такие весёлые формулировки-франкинштейны, которые никак нельзя было допускать в работу. Такие формулировки порой любят наши заказчики, но они приводят разработку и заказчика в ловушку.
Суть проблемных требований:
- можно понять двояко;
- в одном требовании несколько требований;
- требования противоречивы;
- требования размыты.
Поскольку нельзя приводить требования моего молодого аналитика, то буду основываться на примерах из литературы.
Пример: «Для иллюстрации того, как не надо делать, ниже приводятся два «жутких» примера формулирования требований:
1. Система должна обеспечивать максимальный уровень производительности в течение всего времени работы, за исключением аварийных ситуаций, при которых она должна обеспечивать уровень производительности до 125%, но только если аварийная ситуации не длится более чем 15 минут, - в противном случае система должна уменьшить уровень производительности до 105%; но в случае, если удается достигнуть уровня производительности только 95%, система должна активировать режим «исключительно малого уровня» и поддерживать этот уровень в пределах 10% от начального значения в течение, как минимум, 30 минут.
2. Система должна обеспечивать основные функции текстового редактора, удобные для использования не обученным персоналом, и должна работать в условиях «тонкого» Ethernet'а, проложенного по воздушной системе кабельных каналов с интегрированными сетевыми адаптерами, поставляемыми с дополнительными модулями памяти, при необходимости.
Эти примеры иллюстрируют классические негативные ситуации, характерные для разработки требований. [...]
Анализ первого примера показывает, что вместо одного требования, нужно писать 12. Развивая эту мысль, лучше всего выделить 4 отдельных условия эксплуатации -нормальное, аварийное, аварийное более 15 минут, режим «исключительно малого уровня», - и описать требования для каждого из этих условий.
Обратите внимание на имеющуюся лазейку во втором примере. Совершенно непонятен объем требования. Например, это требование можно интерпретировать и так: «Система должна обеспечивать основные функции текстового редактора ... при необходимости». Так требуется ли, в конце концов, текстовый редактор или нет? - старайтесь избегать таких ситуаций.”»
Элизабет Халл, Кен Джексон, Джереми Дик, Разработка и управление требованиями. Практическое руководство пользователя (Второе издание) - Telelogic, 2005г., стр. 99-101
Для того, чтобы избежать грубых ошибок формулирования требований используйте следующий чек-лист:
- На одну функцию системы приходится 1-3 ограничения, если нет, то требования к работе функции надо выделить в отдельный раздел ТЗ\постановки;
- При описании входящих\исходящих данных описаны форматы, предъявлены требования к каждому виду данных;
- Есть ли в ТЗ определения понятий, которые могут толковаться двояко. С внутренним заказчиком введение определений может оказаться излишне, но при этом слово транзакция экономистом и программистом могут быть истолкованы по-разному.
- В требованиях заданы конкретные результаты выполнения операции(критерии приёмки). Например, запрос в БКИ должен выполняться не более чем за 2 минуты или файл с данными загружает только строки, где количество ошибок от 0 до 6;
- В тексте отсутствуют неоднозначные термины. Примеры таких формулировок можно посмотреть ниже, но список не избыточен.
Неоднозначные термины | Способ их улучшения |
| Приемлемый, адекватный | Определите, что понимается под приемлимостью и как система это может оценить |
Практически выполнимо
| Не заставляйте разработчиков определять, что под этим понимается. Поставьте пометку «TBD» и определите дату, к которой эту проблему следует разрешить |
По меньшей мере как минимум, не более чем, не должно превышать | Укажите минимальное и максимальное допустимые |
| Между | Определите, указаны ли конечные точки |
| Зависит от | Определите природу зависимости. Обеспечивает ли другая система ввод данных в вашу систему, надо ли установить другое ПО до запуска вашей системы и зависит ли ваша система от другой при выполнении определенных расчетов или служб?
|
Эффективный
| Определите, насколько эффективно система ресурсы, насколько быстро она выполняет определенные операции и насколько она проста в обращении |
Быстрый, моментальный
| Укажите минимальную приемлимую скорость, при система выполняет определенное действие |
Гибкий
| Опишите способы изменения системы в ответ на изменения условий или бизнес-потребностей |
Улучшенный, лучший, более быстрый, Превосходный
| Определите количественно, насколько лучше или быстрее стали показатели в определенной функциональной области |
Включает: включает в себя, но не ограничен этим; и т.д.; и т.п.; такой как
| Список элементов должен включать все возможности. В противном случае его нельзя использовать при разработке или тестировании
|
Миксимизируйте, минимизируйте, оптимизируйте
| Укажите минимальное и максимальное допустимые значения определенного параметра
|
| Обычно, в идеальном варианте | Также опишите поведение системы при нештатных или неиде- условиях
|
| Необязательно | Укажите кто делает выбор: система,. Пользователь или разработчик |
Разумный, при необходимости, при условиях
| Объясните, как это выполнить |
| Устойчивый к сбоям | Определите, как система должны обрабатывать исключения и реагировать на неожиданные условии работы |
| Цельный, прозрачный, элегантный | Выразите ожидания пользователя, применяя характеристики продукта, которые можно наблюдать |
| Несколько | Укажите сколько или задайте минимальную и максимальную границы диапазона |
| Не следует | Старайтесь формулировать требования в позитивной форме, описывая, что именно система будет делать |
| Реальный | Поясните этот термин |
| Достаточный | Укажите, какая степень чего-либо свидетельствует достаточности |
| Поддерживает, позволяет | Дайте точное определение, какие действия система будет выполнять, поддерживая конкретную возможность |
| Дружественный, простой, легкий | Опишите системные характеристики, которые будут отвечать потребностям пользователей и его ожиданиям, касающимся легкости и простоты применения продукта |
Стр. 194-196
Вигерс К., Разработка требований к программному обеспечению - М.:Издательство- торговый дом «Русская Редакция», 2004