Spec By Example на примере одного требования

Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:

В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.

В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!

Давайте будем идти по порядку, как это нам предлагает методология. И начать следует с

Определения (Definitions)

Если нет общего понимания терминологии, то возможно, это признак того, что заинтересованные стороны на самом деле не договорились о других вещах? Это могут быть цели бизнеса, бизнсс-процессы или функции, которые требуются системе. Простая проверка терминологии может выявить серьезные недостатки в самом понимании проекта

Поэтому начинать надо с того, что мы считаем нашим словарем и откуда в нем определения. Это могут быть обыкновенные словари, какие-либо книги, корпоративные стандарты и так далее. Задайте себе вопрос о том, точно ли вы понимаете значения существительных и глаголов? Обязательно запомните откуда вы берете это определение. Обратите внимание, не вызывает ли оно каких-либо противоречий с тем, что вы уже знаете.
И самое главное — попросите вашего заказчика вместе с вами проверить, что все это верно.

Что касается нашего случая, полезным будет узнать:

• что вообще будет храниться на складе?
• есть ли зоны спец-товаров, например, холодильник?
• как происходит процесс отгрузки/приема?

Функционал (Features)

Когда мы говорим о требованиях, надо мыслить фичами и визуализировать именно их, а не абстрактный UML в вакууме. И визуализация позволяет понять это гораздо четче, потому что каждый процесс отображается через свои шаги и каждый шаг и становится фичей. За счет этого прием Story Mapping и дает такой классный результат.
Так вот, когда вы читаете требования, обращайте внимания на следующие вещи, которые являются самостоятельными фичами:

• Именованные фичи — пользователи и аналитики, возможно, уже решили, какие функции они хотели бы видеть в системе. Примерами могут быть «Ввод заказа», «Экран поиска», «Отчет о состоянии дел.
• Фразы вроде: «Система будет {глагол} {объект} '. Типовые глаголы: добавлять, обновлять, удалять, обрабатывать и так далее. Объектом может быть любая сущность или процесс в система, например, клиент, заказ, продукт, человек, счета-фактуры и так далее.

Для нашего случая, явным образом выделяются следующие фичи:

• отгрузка товара со склада
• прием товара на склад
• регистрация товара на складе

Результаты (Outcomes)

Больше, чем что-либо другое, требования должны описывать результаты работы. Результаты это то, чего мы хотим от системы. Обычно в тексте требований результаты легко выделить по следующим паттернам:

• активное проявление — «ситема будет»
• пассивное проявление — «правильный результат работы это...» или «неправильный результат работы это...»

Соответственно, результаты работы систему могут ссылаться на веб-страницы, где отображаются результаты, отчеты и так далее. Так же они могут относиться к поведению системы, которое мы видим как пользователи через интерфейс или в виде медиа выдачи (видео, например).
Часто результат, который не явно не видим, наблюдается сообщением, который информирует пользователя о том, что произошло. Соответственно, результатом работы системы может быть «ничего». Типичным примером здесь будет реакция системы на попытки взлома или подбора пароля.
Возвращаясь к нашим требованиям. Нам было бы полезно видеть:

• процентное наполнение склада
• информацию о том, что место заканчивается

Сценарии (Scenarios)

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

• в рамках сценария нет ветвления
• все исключительные ситуации — это отдельный сценарий
• сценарий начинается с описания стартовой ситуации
• сценарий содержит только конкретные значения параметров

(Кстати, все это и делает сценарий отличным тест-кейсом).
Например,
Изначально склад пуст и может хранить 100 мешков картошки, когда мы добавляем 1 мешок картошки, мы видим, что процент заполненности склада стал 1%
Идем дальше.

Прогноз (Prediction)

Начинаем проверять наши сценарии на логику. Всегда понятно, почем из мы получаем именно тот результат, который в сценарии описан. Если нет, это чаще всего означает что пропущен тот или иной шаг, или даже описаны не все условия. Это возвращает нас на этап визуализации процесса в целом.

Двусмысленность (Ambiguity)

(Мой любимый этап) Для этого этапа полезно представлять сценарии в виде таблицы, которая потом так же найдет свое применение.

И начинаем после этого смотреть на следующие вещи:

• есть ли случаи, когда данные не отличаются или отличаются незначительно, а результат кардинально разный
• если случай, когда разные данные ведут к одному результату

На этом этапе начинают всплывать такие вещи, как:

• разные определения одного функционала
• скрытые шаги
• неоднозначное понимание терминологии
• и так далее

Пробелы (Missing)

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

Что дальше?

Дальше мы берем BDD фреймворк и начинаем писать код! Об этом я расскажу, а точнее покажу как это делается в ближайшем вебинаре. Следите за новостями!

Кстати, а вот и сам вебинар про общую теорию подхода Spec By Example

Автор: mythmaker

Источник