Требования утверждены. И что дальше?

Оригинальная статья: "Requirements Are Approved – So What?" by Karl O'Brien

Мы все стремимся писать идеальные требования. Многим из нас приходилось иметь дело с весьма неясными, неструктурированными и сложно воспринимаемыми записями, небрежно набросанными за короткую встречу с заинтересованными лицами или с экспертами в предметной области. Заинтересованные лица или эксперты в предметной области рассказывают нам о новой, гениальной, блестящей и способной изменить мир системе, которая вскоре будет внедрена…(будем надеяться), и мы выжимаем все возможное из наших каракуль, чтобы написать требования для воплощения системы в жизнь.

Хорошо, возможно, все не так уж плохо, но мы тратим дни для создания из полученных требований исчерпывающего документа с функциональными, нефункциональными и бизнес-требованиями. Все это сопровождается большим количеством вспомогательных графиков, вариантами использования и диаграммами, которые мы впоследствии предоставляем заинтересованным лицам для просмотра и получения пресловутого “Утверждения”. Честно говоря, нам ВСЕМ зачастую свойственно лишь пробегать глазами по тексту, вместо того, чтобы уделять этому немного больше времени и добиваться успеха.

Уверен, многие из вас в свое время, устанавливая программные продукты, быстро пропускали “Пользовательское соглашение”, а затем были раздражены, увидев в пятый раз появившуюся строку меню Google в Internet Explorer. Да, в соответствии с требованиями прав доступа, которые вы подтвердили, так и должно было произойти, и также, если вы не еще заметили, ваша домашняя страница изменится тоже. Итак, мы все сделали, прочитали все требования, предоставленные в “Утверждении”, лишь для того, чтобы разочароваться в конечном результате. В нашем случае мы можем легко удалить полученные дополнительные услуги, но в реальном мире создания программных продуктов это будет нам дорого стоить.

Я не пытаюсь рассказать что-то новое. Что же самое важное я хочу сказать? Проекты разрабатывались таким способом долгое время. По статистике уровень доработки проектов составляет 40%. Причина этого лишь в том, что кто-то просто невнимательно прочитал информацию, находящуюся у него перед носом. В большинстве организаций не возникает серьезных последствий за «непрочтение» функциональных требований, и их продолжают утверждать, хотя это просто иллюзия утверждения. Если позже кто-то и выскажет свое недовольство, я уверен, что в документе найдется много неясностей и неопределенностей, но почему мы их пропускаем, а затем исправляем в версии 1.1 или Фазe 2 или после некоторых запросов о внесении изменений?

На мой взгляд, выходом из этой ситуации является применение гибких подходов к любому проекту. Гибкий подход — это и состояние ума, и методология. Поэтому этот подход может быть применен во многих жизненных ситуациях. Я полностью за отмену “Процесса утверждения”, общепринятой передачи документов от человека к человеку, от группы к группе и ожидания, когда все это будет утверждено. Вместо этого, я предпочитаю применять интерактивный подход к процессу созданий требований: подключать заинтересованных лиц на повторяющихся этапах процесса и проводить их через меньшие, менее затратные решения за период времени.

Гибкий подход содействует получению более ранней обратной связи и личному общению. Начните получать выгоду уже на стадии организационных собраний с заинтересованными лицами. Во время таких собраний задавайте следующие вопросы:

Каким людям необходим продукт, который мы собираемся создать?
Почему они нуждаются в его использовании?

Фокусируйтесь на проблемах, которые вы собираетесь решать, и на том, «КАК» решить эти проблемы. Иногда вам придется потратить определенное время на поиск методов решения, особенно если используется новая архитектура. Эта архитектура должна развиваться вместе с требованиями, и в этом случае, придется прилагать двойные усилия.

Конечно, здорово сразу же начинать писать объемные документы требований с информацией о масштабе проекта, заинтересованных лицах, описанием состояния системы «As IS» и «To BE», но я призываю вас как можно быстрее обратиться к вариантам использования. Используйте информацию, которую вы собрали на первой встрече для создания высокоуровневой диаграммы вариантов использования, включив основные субъекты. И не бойтесь обратиться к заинтересованным лицам и получить их согласие, перед тем как двигаться дальше. Очень легко пропустить субъект или вариант использования на начальных этапах создания такой диаграммы.

Суть варианта использования — его главный сценарий успеха — от 6 до 10 шагов, которые описывают то, как субъект выполняет определенные действия. Если вариант использования написан верно, он предоставляет четкое описание того, как система должна себя вести. Если он написан плохо, он превращается в нудную неразбериху, в которую вынужден пялиться читатель. Умение ёмко и информативно описывать шаги является одной из самых важных способностей в написании вариантов использования. Это также самая трудно-приобретаемая способность, так как шаги варианта использования отличаются от традиционного способа вербализации требований.

Каждый шаг должен описывать действие, выполняемое системой или субъектом. Все действия обычно подразделяются на несколько следующих категорий (если выделить категорию сложно, то это указывает на то, что вы, возможно, неправильно описываете шаг).

Вид шага	Пример
1. Система предоставляет информацию субъекту	1. Система отображает результаты поиска
2. Система побуждает субъект	2. Система отправляет запрос субъекту о принятии приглашения
3. Cистема действует от имени субъекта	3. Система посылает запрос платежной программе
4. Субъект делает выбор	4. Участник принимает приглашение
5. Субъект предоставляет информацию системе	5. Клиент вводит информацию о платеже

Старайтесь описывать полученную информацию и пройденную работу живо. Для того чтобы сценарий было легко читать и использовать, опускайте следующие детали:

Пользовательский интерфейс
Формат передаваемых данных
Формулы и бизнес-правила
Требования к производительности (и другие не-функциональные требования)

Эти детали могут быть определены в специальных полях. Не засоряйте сам вариант использования.

Теперь когда у вас есть краткий и легкий для понимания вариант использования, снова согласуйте его с заинтересованными лицами. Пройдите с ними весь процесс и убедитесь, что они согласны с формулировкой, частями и содержанием, определенными вами. В процессе согласования вы можете еще больше расширить вариант использования. Представьте, что это Рождественская ель, и теперь вы можете повесить на неё все виды украшений, которые вы определили:

Ссылки на требования
Макеты
Сопутствующая информация и бизнес-правила
Внешние ссылки

И наконец, НЕ создавайте огромный документ и не просите незнакомых людей проверить и утвердить ваши требования. Соберите их вместе во время работы; по возможности моделируйте требования. Проведите их через требования «небольшими порциями» и зафиксируйте их обратную связь. Вновь и вновь повторяйте этот процесс, чтобы улучшать требования и устранять неточности.

Если встреча проходит в тишине со слабой обратной связью, это может значить только 2 вещи: