Простое определение термина "требование" - что должно быть доставлено для обеспечения ценности (value)

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

Основной причиной "ползучести (creep) требований" является принципиальное различие между бизнес и системными требованиями

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

Продукт может работать именно так, как написано в системных требованиях. Но при этом он может не доставлять бизнесу value, так как не соответствует бизнес-требованиям

Бизнес и пользователи хорошо разбираются в своей предметной области. Но этого не достаточно для выявления адекватных требований. Так как им не хватает скиллов по, собственно, выявлению требований.

Концептуально на языке бизнеса описывают какие бизнес-результаты должны быть доставлены для обеспечения value

Описывают высокоуровневый дизайн продукта, который представляет собой один из возможных вариантов доставки бизнес-требований

Бизнес-требования	Системные требования
Бизнес/пользовательский взгляд/язык	Взгляд/язык продукта
Концептуальные	Конкретные, высоко-уровневый дизайн продукта
Какие бизнес-результаты должны быть доставлены для обеспечения value	Как продукт должен функционировать (с внешней точки зрения) чтобы работать в соответствии с дизайном и предположительно доставлять ожидаемый бизнес-результат
Уже существует внутри бизнеса	Определяется кем-то
Много разных путей для достижения	Один возможный путь для удовлетворения бизнес-требований

Как правило проверяет не сами требования (что user знает и что ему необходимо), а то - насколько верно аналитик написал эти требования "под диктову" со слов user'a

3. Supervisory review

Тестирование должно включать: выполнение теста; получение реального результата; сравнение полученного результата с ожидаемым.

Если мы просто выполняем тест и получаем результат, но не сравниваем с желаемым - это не тестирование

Во время ревью требований люди не выполняют сравнение с ожидаемым результатом. Они просто просматривают реальный результат. Найти дефекты при таком подходе не возможно.

Для нахождения дефектов мы должны корректно определить ожидаемый результат без влияния реального результата.

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

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

Основывается на перечне руководящих принципов (giudeline)/ тем (topic), которые должны быть проверены

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

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

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

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

Проектные переменные (бюджет, расписание и т.п.) не являются бизнес-требованиями (если не обеспечивают value). Они являются ограничениями проекта и должны собираться вместе с требованиями.

9. Clarity (ясность, четкость)

10. Deliverable whats

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

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

15. Ambiguity (двусмысленность)

Richard Bender разработал специальную методику для анализа имеющейся информации на предмет наличия в ней двусмысленности - Ambiguity Review methodology. Его метод включает чек-лист из 30 техник, посвященных поиску и устранению двусмысленности.

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

Пользователь - тот, кто непосредственно физически использует систему (в широком смысле слова, система - не только ПО)

Заказчик - тот, кто использует результаты работы системы или зависит от работы системы. Может быть внешним или внутренним

Убедиться, что требуемые функции, возможности, требования к производительности для всех ЗЛ определены, при этом определены полно, точно и адекватно.

Убедиться, что продукт используется в соответствии со стандартами и соглашениями; работники имеют необходимые скилы и используют соответствующие технологии и инструменты;

Эту технику можно применять к нескольким требованиям из одной темы. И если в результате мы понимаем, что эти несколько требований нам не нужны, то может быть можно не анализировать и всю тему - вдруг она вся не нужна. Таким образом мы можем сэкономить время, не тратя его на остальные требования темы.

При разработке требований необходимо помнить про "нефункциональные требования" - показатели качества.

Большинство аналитиков в процессе выявления требований акцентируют свое внимание непосредственно на операционной деятельности пользователей.

Технические бизнес-требования описывают: среду (environment), операционную систему, сеть, СУБД и т.п.

При выборе конкретного варианта необходимо учитывать всю совокупность факторов, как то стоимость, сроки, риски и т.п.

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

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

Мы думаем образами, а общаемся словами. При переводе образов в слова и обратно обязательно происходит искажение.

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

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

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

Мы часто отбрасываем реальные требования, потому что нам кажется, что то, что сказал пользователь, не является требованием.

Block 2 - Measure now - значения критериев, на основе которых было принято решение о том, что проблема действительно имеет место

Block 5 - What "Should be" (requirements) - описание реального to be процесса, который приводит к решению проблемы. Этот блок по сути содержит бизнес-требования.

Block 6 - How (design) - содержит высокоуровневое описание дизайна, то есть того, как требования должны быть реализованы. Этот блок по сути содержит системные требования.

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

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

Очень эффективно, но не надо забывать, что оно акцентирует внимание на том, КАК работа выполняется

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

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

Люди обычно говорят о том, что для них важно. Поэтому думайте, почему человек сказал именно это, а не другое. И если не понимаете - спросите.

Для каждого человека существует наиболее удобный способ коммуникации.

1. Спускаясь сверху-вниз описать бизнес-языком конечные результаты/выходы бизнес-модели TO BE, опираясь на комплексный подход

Эффективность деятельности и предполагаемый workflow (operational effectiveness and workflow preference)

В дополнение к описанию техник я даю пояснение КАК и ПОЧЕМУ они работают. Я считаю, что понимание концепций, лежащих в основе техник - является ключом для адаптации этих техник под вашу конкретную ситуацию.

Требования - они идут от бизнеса. Поэтому они должны отражать то, что БИЗНЕС думает, а не то, что думаем МЫ по поводу потребностей бизнеса.