Дальнейший гайд не является точным руководством. Мы постарались собрать в нём лучшие практики в наиболее простой форме. Если вы знаете более удобный для вас метод описания требований, можете воспользоваться им.

Для того, чтобы сформулировать требования к системе необходимо:

  1. Выписать всех стейкхолдеров. Если не понимаете, как учесть всех стейкхолдеров, то посмотрите этот материал

    1. Стейкхолдеры как источник требований (короткое видео)
    2. Жизненный цикл системы (короткое видео)

  2. Выписать их цели. Ответьте для каждого стейкхолдера на вопрос: «Чего он хочет достичь?». Подумайте над тем, как стейкхолдеры достигают этих целей сейчас и что им в этом не нравится.

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

    <aside> 🤓 В первых двух вопросах мы описали, что происходит сейчас. Теперь давайте продумаем, каким должно быть наше решение, чтобы стейкхолдер захотел им пользоваться. Примечание: бывают разные роли пользователей. Разные стейкхолдеры могут занимать одну и ту же пользовательскую роль. С этого момента мы говорим о пользовательской роли. Ещё раз: 1) Стейкхолдер хочет достичь цели → 2) Он встаёт в роль пользователя → 3) Пользователь взаимодействует с продуктом и получает результат работы продукта → 4) Результат приближает стейкхолдера к достижению цели. Почему стейкхолдер не равно пользователь? Стейкхолдер — это тот, кто имеет какой-то интерес в проблемной ситуации, которую мы выявили. Они существуют и как-то действуют вне зависимости от нашей воли. В пользовательскую роль стейкхолдер становится используя наш продукт, чтобы достичь желаемого результата. Пользовательскую роль (и сценарии для неё) мы продумываем сами, а пользователь соглашается ей следовать (или не соглашается).

    </aside>

  4. Перечислите, какие действия совершает пользователь (при участии вашего продукта), чтобы получить результат. Это упражнение похоже на написание User Story Map. Можете использовать её, но не забудьте проверить, всё ли в ней соответствует новой информации.

  5. Перечислите, что должно появиться в вашем решении, чтобы пользователи достигли результата. Для этого ответьте на вопрос: «Что должно быть в моём решении, чтобы пользователь смог выполнить эти действия?»

  6. Обязательно зафиксируйте ответы на вышеперечисленные вопросы. Можете использовать для этого копию этой таблицы (мы сделали шаблон, чтобы вам было легче разобраться — копируйте его), или используйте любой другой удобный вам инструмент (Miro, Google Docs и тд).

  7. Положите артефакт с зафиксированными требованиями на доску в трелло в свой архив (столбец архив).

Полезные материалы:

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