Как писать требования

Категории: Практики Инструменты

Рекомендация, как писать требования (не важно какие - функциональные или нефункциональные)

  • Избегайте обобщающих фраз - Все, Всегда, Никогда, Иногда, Возможно, В редких случаях, Может быть и т.д. Суть требований - прояснять требований и давать однозначный ответ, а не оставлять требование неясным. Если вы видите в требовании такую фразу или вам хочется добавить такое слово - значит требование неясно, оно требует вашего внимания. Используйте в таких случаях: Каждый из (список, перечисленный), указанные в требовании №11 (здесь ссылка на конкретное требование)
  • Максимально сухо и без эмоций и описаний: красивый, интересный, большой, долгий. Эти прилагательные не описывают требования, потому что они субъективны. Для меня понятие “Долгий” - это 1 час. Для вас - 1 минута. Каждый понял по-своему, но однозначности не прибавилось
  • У каждой операции есть как минимум 2 исхода: Успешное завершение или Неуспешное. Можно добавить еще состояние “В процессе“. Например, если вы нажали кнопку Сохранить, то есть положительный сценарий (его нужно описать) - данные успешно сохранены, отрицательный (возникла ошибка) - нужно описать, что делать пользователю в случае неуспеха. Промежуточное состояние (в процессе) - как правило, оно должно быть конечно. Обращайте внимание да длительность этого состояния (1 минута, 10 секунд, 1 час и т.д.). Такое уточнение тоже проясняет требование
  • Если вы используете термины в требованиях - должна быть расшифровка этих терминов. Персональные данные, Секрет, Серверные данные - эти термины требуют уточнения, описания. Указать что является Персональными данными (согласно Федерального закона или согласно вашего приложения)? Что такое секрет (пароль, токен, дата рождения, код в смс)? Для расшифровки можно использовать отдельный пункт требований или глоссарий
  • Используйте UserFlow, чтобы понять в каком месте у пользователя “нет выхода“. Например, в мобильном приложении возникла ошибка при Сохранении, появилось сообщение на весь экран с текстом ошибки, но нет возможности закрыть это окно. Пользователю нужно полностью закрыть приложение и вернуться к самому началу этого сценария. Не ЮзерФрендли
  • Если в ходе написания требований у вас возникает список подходящих условий (расширения экрана для МП) - крайне рекомендую перечислить те, которые вы поддерживаете. Или собираетесь поддерживать. Перечислить можно как в Приложении, так и в тексте. При этом, здесь очень важно соблюсти баланс - все, что вы перечислите - вам нужно будет протестировать. Если вы указали 100 расширений экранов - вам нужно сделать тесты на каждый экран и проверить, что работает

Все посты написаны мной. Если вам интересно узнать больше, подписывайтесь на мою рассылку о менеджменте. Один-два раза в месяц я пишу статьи о разных аспектах проектного управления или менеджмента в целом. Или вы можете просто написать мне :)