#Документация
14 статей
Как выявлять требования
Требования не лежат в одном месте: часть в головах людей, часть в документах, часть в данных и в самой системе. Выявление начинается с вопроса, где искать ответ на каждый вопрос.
Как разобраться в существующей системе или процессе
В старой системе есть три правды: та, что написана, та, что рассказывают люди, и та, что записана в данных и логах. Знакомство с системой - это сверка этих правд.
Use Case и пользовательские сценарии
Use case описывает один путь пользователя к цели вместе с тем, что происходит, когда что-то идёт не так. Он нужен там, где короткой истории уже мало.
Бизнес-правила
Бизнес-правило - это то, что компания решила для себя и чего система обязана придерживаться. Если правило не записано отдельно, оно размазывается по коду, письмам и памяти людей.
Таблицы решений для сложных правил
Таблица решений превращает правило с несколькими условиями в сетку, где каждое сочетание условий видно отдельно. Из неё нельзя прочитать правило двумя способами.
Прототипы и макеты: как согласовывать интерфейс
Макет экрана часто становится первым местом, где требования встречаются с реальностью. Здесь разберём, чем набросок отличается от макета и прототипа, что проверять в макете и как писать замечания, которые дизайнер сможет выполнить без уточнений.
Экранные формы и валидации
Форму описывают не картинкой, а таблицей полей: что вводят, обязательно ли, в каком формате и что показать при ошибке. Здесь разберём, как составить такую таблицу и почему проверка ввода живёт сразу в нескольких местах.
Состояния экрана: загрузка, пусто, ошибка
Экран может быть в шести состояниях, а макет часто показывает одно. Здесь опишем каждое состояние и свяжем его с ответом сервера, чтобы интерфейс не замирал и не молчал.
Неполные и противоречивые требования
Плохое требование редко выглядит плохим: оно читается гладко, пока не начнёшь его реализовывать. Здесь разберём, где в тексте прячутся пробелы и противоречия и как добиться ответа, который можно записать.
Как проверить качество требований: чек-лист
Чек-лист превращает «мне кажется, требование нормально» в порядок вопросов, на которые можно ответить «да» или «нет». Здесь собран список из восьми вопросов с примерами «было и стало» и объяснено, что проверять у одного требования, а что у всего набора.
Изменение требований: Change Request и Impact Analysis
«Тут будет маленькая правка» бывает самой дорогой фразой в разработке. Здесь разберём, как оформлять изменение требований запросом и как оценить, что такое «маленькая правка» затронет на самом деле.
Трассировка требований
Когда требование потерялось между постановкой и проверкой, об этом узнают на приёмке или в проде. Трассировка делает такие потери видимыми заранее: по одной строке видно, зачем требование нужно, кто его делает и чем проверяется.
От требований к тестированию: тест-кейсы и приёмка
Требование, из которого нельзя вывести проверку, остаётся пожеланием. Здесь разберём, из чего состоит тест-кейс, как по требованию получить позитивные, негативные и граничные проверки и как из них складывается приёмка.
Постановка задачи разработке: Definition of Ready, чек-лист
Задача, переданная одной строкой, возвращается семью вопросами по ходу работы. Здесь соберём короткий чек-лист готовности, разберём, как передавать задачу разговором, а не запиской, и как не превратить чек-лист в барьер.