Requirement management (rus)

QDD – Question Driven Development

Question Driven Development (QDD) – подход, при котором создается  всесторонний список вопросов, который позволит разработать модель UML для вашей разрабатываемой системы (с заданным уровнем детализации), либо же детализировать требования к ней. Конечно же, изначально данный список следует сформировать.

Замечу, что использование QDD не зависит от методологии разработки ПО (Waterfall, RUP, MSF, Scrum, etc), так как QDD является более низкоуровневой.

Наиболее интересную статью вы можете прочитать здесь, однако данный список подготовлен разработчиком. Я хорошо помню, что самыми главными вопросами являются: “КТО?“, “ЗАЧЕМ?“,”КАК?“. Тем не менее, я начал искать, нет ли подготовленного списка вопросов, который могли бы использовать аналитики. В итоге я на него наткнулся на сайте коллег из Белоруссии, к сожалению, ссылка на форум для обсуждения на их сайте оказалась битой… Кстати, я произвел полное копирование вопросов, сохранив термин “функционал”, который я раз и навсегда отучился использовать при разговоре о функциональности/функциональных возможностях и т.п. Почему? Потому что функционал – это числовая функция, заданная на векторном пространстве. Есть более пошлый вариант, с которым вы можете ознакомиться здесь.

В итоге я решил утащить этот список к себе, так как мне гораздо удобнее его просматривать при работе (надеюсь, на меня никто не обидится, но, если что, то я его удалю отсюда):

Вопросы «Как?»:

•    Как вы будете использовать данный функционал? •    Является ли данный функционал процессом, и, если да, каковы его шаги? Или же какие вопросы мне следует задать, чтобы эти шаги выяснить? •    Как мы можем удовлетворить данную потребность бизнеса? •    Как можно обдумать данный функционал с альтернативной точки зрения? •    Как мы узнаем, что функционал закончен?

Вопросы «Где?»:

•    Где точка входа в процесс? •    Где будет данный функционал доступен для пользователя? •    Где пользователь будет физически находиться во время использования функционала? •    Где можно будет увидеть результаты?

Вопросы «Когда?»:

•    Когда функционал будет использоваться? •    Когда вам необходимо будет знать о…? •    В каких случаях функционал может «упасть»? •    Когда мы будем готовы приступить к…?

Вопросы «Кто?»:

•    Кто будет использовать функционал? •    Кто будет предоставлять входные данные для функционала? •    Кто будет являться получателем выходных результатов? •    Кому необходимо знать о результатах использования функционала? •    У кого я могу узнать больше об этом?

Вопросы «Что?»:

•    Что я знаю о функционале? •    Или же, какие предположения у меня есть о функционал, ожидающие подтверждения? •    Что функционал должен делать? •    Что является конечным результатом работы функционала? •    Что являются составляющими частями функционала? •    Что должно происходить дальше? •    Что должно произойти до? •    Что, если….? Обдумайте все альтернативные сценарии и задайте вопросы о том, что должно происходить в случае их выполнения. •    Что необходимо отслеживать?

Вопросы «Зачем»?

Вопросы «Зачем?» отлично подходят для подведения итогов, так как помогают убедиться в том, что только что выявленные требования соответствуют потребностям, идентифицированным во время определения объема проекта.

•    Еще раз: зачем нам этот функционал? •    Есть ли другие пути достижения данных результатов? •    Удовлетворяет ли данный функционал потребностям бизнеса и решает ли проблему, которую необходимо решить?

Advertisements
Standard

3 thoughts on “QDD – Question Driven Development

  1. Алексей, привет! Никогда не слышал про QDD 🙂 и странно, что напоминает это какую-то смесь из стандартных практик: критический взгляд + контрольные списки вопросов.

    Хотел поделиться еще одним наблюдением. Описанные тобой вопросы уж очень похоже на те, которые задает г-н Захман в своем известном фреймворке: http://devprom.ru/news/Проектирование-архитектуры-по-модели-Захмана

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s