![](http://www.galaktika.ru/agro/files/et_temp/sklad51-1569053_958x340.jpg)
Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:
В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!
Давайте будем идти по порядку, как это нам предлагает методология. И начать следует с
Определения (Definitions)
Если нет общего понимания терминологии, то возможно, это признак того, что заинтересованные стороны на самом деле не договорились о других вещах? Это могут быть цели бизнеса, бизнсс-процессы или функции, которые требуются системе. Простая проверка терминологии может выявить серьезные недостатки в самом понимании проекта
Поэтому начинать надо с того, что мы считаем нашим словарем и откуда в нем определения. Это могут быть обыкновенные словари, какие-либо книги, корпоративные стандарты и так далее. Задайте себе вопрос о том, точно ли вы понимаете значения существительных и глаголов? Обязательно запомните откуда вы берете это определение. Обратите внимание, не вызывает ли оно каких-либо противоречий с тем, что вы уже знаете.
И самое главное — попросите вашего заказчика вместе с вами проверить, что все это верно.
Что касается нашего случая, полезным будет узнать:
- что вообще будет храниться на складе?
- есть ли зоны спец-товаров, например, холодильник?
- как происходит процесс отгрузки/приема?
Функционал (Features)
Когда мы говорим о требованиях, надо мыслить фичами и визуализировать именно их, а не абстрактный UML в вакууме. И визуализация позволяет понять это гораздо четче, потому что каждый процесс отображается через свои шаги и каждый шаг и становится фичей. За счет этого прием Story Mapping и дает такой классный результат.
Так вот, когда вы читаете требования, обращайте внимания на следующие вещи, которые являются самостоятельными фичами:
- Именованные фичи — пользователи и аналитики, возможно, уже решили, какие функции они хотели бы видеть в системе. Примерами могут быть «Ввод заказа», «Экран поиска», «Отчет о состоянии дел.
- Фразы вроде: «Система будет {глагол} {объект} '. Типовые глаголы: добавлять, обновлять, удалять, обрабатывать и так далее. Объектом может быть любая сущность или процесс в система, например, клиент, заказ, продукт, человек, счета-фактуры и так далее.
Для нашего случая, явным образом выделяются следующие фичи:
- отгрузка товара со склада
- прием товара на склад
- регистрация товара на складе
Результаты (Outcomes)
Больше, чем что-либо другое, требования должны описывать результаты работы. Результаты это то, чего мы хотим от системы. Обычно в тексте требований результаты легко выделить по следующим паттернам:
- активное проявление — «ситема будет»
- пассивное проявление — «правильный результат работы это...» или «неправильный результат работы это...»
Соответственно, результаты работы систему могут ссылаться на веб-страницы, где отображаются результаты, отчеты и так далее. Так же они могут относиться к поведению системы, которое мы видим как пользователи через интерфейс или в виде медиа выдачи (видео, например).
Часто результат, который не явно не видим, наблюдается сообщением, который информирует пользователя о том, что произошло. Соответственно, результатом работы системы может быть «ничего». Типичным примером здесь будет реакция системы на попытки взлома или подбора пароля.
Возвращаясь к нашим требованиям. Нам было бы полезно видеть:
- процентное наполнение склада
- информацию о том, что место заканчивается
Сценарии (Scenarios)
Мы наконец-то подошли к сценариям (но это еще не конец нашей работы), и теперь можем комбинировать все то, что нарыли на предыдущих этапах. При этом обращаем внимание на следующие вещи:
- в рамках сценария нет ветвления
- все исключительные ситуации — это отдельный сценарий
- сценарий начинается с описания стартовой ситуации
- сценарий содержит только конкретные значения параметров
(Кстати, все это и делает сценарий отличным тест-кейсом).
Например,
Изначально склад пуст и может хранить 100 мешков картошки, когда мы добавляем 1 мешок картошки, мы видим, что процент заполненности склада стал 1%
Идем дальше.
Прогноз (Prediction)
Начинаем проверять наши сценарии на логику. Всегда понятно, почем из мы получаем именно тот результат, который в сценарии описан. Если нет, это чаще всего означает что пропущен тот или иной шаг, или даже описаны не все условия. Это возвращает нас на этап визуализации процесса в целом.
Двусмысленность (Ambiguity)
(Мой любимый этап) Для этого этапа полезно представлять сценарии в виде таблицы, которая потом так же найдет свое применение.
Customer type | Cart contents | Delivery |
---|---|---|
VIP | 1 book | Free |
VIP | 10 books | Free |
VIP | 11 books | Standard |
Regular | 10 books | Standard |
VIP | 5 washing machines | Standard |
VIP | 1 washing machine | 5 books Standard |
И начинаем после этого смотреть на следующие вещи:
- есть ли случаи, когда данные не отличаются или отличаются незначительно, а результат кардинально разный
- если случай, когда разные данные ведут к одному результату
На этом этапе начинают всплывать такие вещи, как:
- разные определения одного функционала
- скрытые шаги
- неоднозначное понимание терминологии
- и так далее
Пробелы (Missing)
На самом деле, этот этап неявно проскальзывал уже несколько раз, но стоит упомянуть его еще раз. Например, еще и по той причине, что после того, как мы получили классные сценарии, мы забли обновить глоссарии, исходные документы и так далее.
На этом этапе так же полезно видеть таблицу сценариев, так он позволяет быстрее ориентироваться в них и находить пробелы.
Что дальше?
Дальше мы берем BDD фреймворк и начинаем писать код! Об этом я расскажу, а точнее покажу как это делается в ближайшем вебинаре. Следите за новостями!
Кстати, а вот и сам вебинар про общую теорию подхода Spec By Example