Четкая и эффективная коммуникация — основополагающий принцип разработки требований — коммуникации от людей, у которых есть потребности, к людям, которые умеют создавать решения, а затем к тем, кто может реализовать и проверить эти решения.
Опытный бизнес-аналитик выберет самый эффективный способ доведения любого типа требований до любой аудитории.
Итог разработки требований — задокументированное соглашение между заинтересованными лицами о создаваемом продукте.
Как уже говорилось в предыдущих главах, в документе об образе и границах проекта содержатся бизнес-требования, а пользовательские требования часто фиксируются в виде вариантов использования продукта и пользовательских историй. Подробные функциональные и нефункциональные требования к продукту записаны в спецификации к требованиям к ПО, которая предоставляется тем, кто должен проектировать, разрабатывать и проверять решение. Фиксация всех требований вместе в виде структурированного и читабельного материала, который могут проверить все заинтересованные лица гарантирует, что они понимают, на что соглашаются.
В этой главе рассматриваются цель, структура и содержание спецификации требований к ПО. Мы опишем спецификацию требований к ПО как документ, но это не обязательно должен быть традиционный документ, созданный в обычном редакторе. Надо сказать, что документы обладают многими недостатками:
В качестве альтернативы можно хранить информацию в электронной таблице (у которой те же ограничения, что и у документа), вики, базе данных или серийном средстве управления требованиями. Их надо рассматривать как разные возможные хранилища или контейнеры информации требований. Но независимо от формы используемого хранилища требований, вам всегда нужны одни и те же типы информации. Описанный в этой главе шаблон спецификации требований к ПО — удобное средство напоминания о том, какую информацию надо собрать и как ее организовать.
Не все считают, что стоит тратить время на документирование требований. А в исследовательских и очень изменчивых проектах, в которых неочевидно, каким будет решение, попытки отслеживать в документации все подробности требований приносит мало пользы. Однако затраты на документирование знаний малы по сравнению со стоимостью получения этих знаний или воссоздания их в какой-то момент в будущем.
Акт спецификации и моделирования помогает участникам проекта обдумывать и точно формулировать важные вещи, которые в устном обсуждении могут остаться невыясненными. Если вы на все сто процентов уверены, что какая-то информация никому из заинтересованных лиц никогда не будет нужна за исключение времени, когда эта информация хранится в их краткосрочной памяти, тогда можете не регистрировать эту информацию. В противном случае сохраните ее там, где храните что-то типа групповой памяти.
Вам никогда не создать идеальных требований. Помните, что требования пишутся для определенной аудитории. Объем подробностей, типы предоставляемой вами информации и способ ее структурирования должны соответствовать потребностям целевой аудитории. Аналитики естественным образом пишут требования со своей точки зрения, но они должны их писать так, чтобы требования были максимально понятными тем, кто их должен понимать и выполнять на их основе свою работу. Вот почему важно, чтобы представители этих аудиторий рецензировали требования, проверяя, соответствуют ли требования их потребностям.
Последовательное уточнение деталей — ключевой принцип эффективной разработки требований.
В большинстве проектов нереально, да и не нужно, на ранних этапах проект собрать все и каждое требование. Наоборот — надо думать в терминах слоев. Нужно узнать о требованиях достаточно, чтобы можно было в первом приближении определить их приоритеты и назначить на конкретные будущие выпуски и итерации. После этого можно уточнять группы требований в режиме «just in time», предоставив разработчикам достаточно информации, чтобы они не выполняли лишних и ненужных переделок.
Не стоит надеяться, что даже самая точная документация по требованиям сможет заменить текущие обсуждения в процессе проекта. Должны быть открыты все каналы коммуникации: между бизнес-аналитиками, командой разработчиков, представителями клиента и другими заинтересованными лицами, чтобы они могли быстро разобраться с мириадами возникающих по ходу проекта вопросов.
Внимание! Не стоит рассчитывать, что телепатия и ясновидение заменят собой надежные приемы разработки спецификаций требований. Они попросту не работают, хотя некоторые упорно пытаются использовать в качестве основы проектов разработки ПО.
Способов представления требований несколько:
Последний метод обеспечивает наивысшую степень точности, однако немногие разработчики — и еще меньше клиентов — знакомы с ним. В большинстве проектов не требуется такого уровня формализма, но я сильно надеюсь, что проектировщики высокорисковых систем, таких как системы управления АЭС, применяют формальные методы спецификации. Структурированный естественный язык, усиленный визуальными моделями и другими приемами представления (такими, как таблицы, рабочие модели, фотографии и математические выражения), остается самым практичным способом документирования требований в большинстве проектов по разработке ПО. Оставшаяся часть главы рассказывает, как можно организовать информацию в спецификации требований к ПО.
| Документирование требований | Спецификация требований к ПО |