Захотелось оформить давно накипевшие мысли в серию блог-постов. Как обычно, не претендую на большую истину. Что-то у меня получается, что-то нет, поэтому перечислю получившееся ( неполучившееся тоже перечислю с ответом почему не получилось ). 

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

Требования — это НЕ единожды написанный монолит. Требования рождаются и развиваются, требуют внимания и контроля, а также подхода к ним.

Что я часто наблюдаю: человек выполняющий роль аналитика/продакт-овнера пишет требования. Он или она старается: проводит много времени в изучении целей бизнеса и пользователей, проводит интервью, пишет юзер-стори, приоритезирует, 

(погодите, еще немного перечислений дел этого человека :) )

назначает встречу с командой для обсуждения задач на спринт

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

Тут мне вспоминается услышанная где-то шутка, что жил-был тестировщик и считал аналитика странным: ну а что он странно и непонятно пишет? Потом тестировщик сам стал аналитиком и теперь уже жаловался:  команда какая-то странная, читать не умеет, ну понятно же все написано!

В чем проблема? Аджайл не требует детальной и монолитной документации, но документация все равно нужна. 

Какие виды требований могли бы быть:

• Бизнес-требования, 

• их перерабатывают в системные (пользовательские требования)

• их перерабатывают в функциональные требования (ТЗ, которое можно отдавать в работу и получить годный результат)

А что есть на деле: 

• список юзер-стори, то есть пользовательские требования, добавить щепотку бизнес-требований.

• команда, которой нужно это все осознать и через пару недель выдать готовый результат.

Что делать? Начинать то, что назовем, реинжинирингом требований.

Шаги:

1. Восстановить вкратце бизнес-требования, если это не видно по описанию. Какая бизнес-цель? Зачем и для кого?

2. Воссоздать или вытащить список действий для достижения цели из описания. 

• все ли нужны?

• ничего не пропустили?

Обычно на этом этапе звучит фраза "ничего непонятно!" (хотя  положа руку на сердце, понятно гораздо больше половины). 

3. Отлично, с непонятного и надо начинать.

Мне нравятся несколько способов для размышления над непонятным:

1. Если непонятно как должно выглядеть, но понятно как делать ---> Сделать "прототип".

2. Если при чтении складывается конструкция IF ELSE с кучей IF ELSE ---> Таблицы решений Decision Table

3. Если при чтении угадывается объект, его состояния и переходы между ними --> Диаграмма состояний-переходов State Transition Diagram

 Странная формулировка про "понятно" и "непонятно", поэтому поясню. 

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

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

Еще упростим, пусть отчет представляет собой таблицу с колонкой А - дата (день/месяц/год) и колонкой B - название отдела, C - количество жалоб на этот отдел.

Большинство таких непонятностей решается просьбой: 

Так что не стоит играть в аналитика зря ;)

В чем плюс: команда не играет в угадайку

В чем минус: вам все равно могут прислать плохо проработанные требования и примеры

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

В чем плюс: относительно низкие затраты времени/ресурсов, возможность обсудить сначала с разработчиком

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

Пример

Пока готовила данные для примера в блог, обнаружила подсказку о подсчете номера недели в году. Не все так просто.

 The first week of the year is considered to be the week containing the first Thursday of the year, which is numbered as week 1. System 2 is the approach specified in ISO 8601, also known as the European system for numbering weeks.

Уточнение/возможный запрос на улучшение: достаточно ли просуммировать количество жалоб без информации о количестве записей за период? В примере без колонки c количеством записей, на первой неделе на Z пожаловались 4 раза, а на X всего 3 раза. С колонкой - видно, что на Z есть 4 жалобы за 3 дня, а на Х есть всего одна запись, то есть все 3 жалобы получены в один день.