Начните со случая, в котором возникла проблема
Сотрудник предлагает добавить кнопку бронирования возле каждой книги. Возможная причина запроса: читатель видит свободный экземпляр, приезжает позже и обнаруживает, что его уже выдали. Чтобы уточнить потребность, полезно описать последовательность: просмотр каталога, решение приехать, дорога, обращение к библиотекарю. Затем определить желаемое изменение: человек должен заранее понимать, будет ли конкретный экземпляр ждать его и до какого момента. Это ещё не окончательный интерфейс. Возможно, понадобятся сведения о сроке хранения, подтверждение заявки и правила отказа. Если обсуждать только цвет и расположение кнопки, главная неопределённость останется внутри процесса.
У разных участников разные вопросы
Читателю важно получить понятное подтверждение. Библиотекарю нужно знать, какой экземпляр отложить и когда вернуть его в доступный фонд. Администратору важно согласовать правила на случай нескольких заявок. Эти потребности связаны, но не совпадают. Для учебного примера можно предложить правило: подтверждённая бронь удерживает один свободный экземпляр до конца следующего рабочего дня. Это вымышленное условие, которое в реальном проекте пришлось бы согласовать. Сразу возникают уточнения: что считается рабочим днём, можно ли отменить бронь, что происходит при ошибке каталога? Полезный результат анализа иногда представляет собой список открытых вопросов, а не преждевременно завершённое описание функции.
Проверка должна показывать поведение системы
Фраза бронирование должно быть удобным допускает множество толкований. Более проверяемое условие описывает исходную ситуацию, действие и наблюдаемый результат. Например: есть один доступный экземпляр; читатель отправляет заявку; система подтверждает резервирование и показывает срок хранения. Нужен и противоположный случай: свободных экземпляров нет, поэтому подтверждение успешной брони не появляется. Отдельно проверяется отмена, если она входит в согласованный объём. Такой набор примеров помогает обсуждать границы решения. Он не доказывает, что библиотека достигла общей цели: после внедрения ещё потребуется узнать, стало ли меньше бесполезных поездок. Соответствие описанному поведению и польза изменения требуют разных свидетельств.
Попробуйте на практике
Подготовьте короткую карточку требования для вымышленной библиотеки, не рисуя интерфейс.
- Запишите участника, конкретную трудность и желаемое изменение. Используйте ситуацию с поездкой за уже выданной книгой, а не общее пожелание улучшить сервис.
- Назовите двух других участников процесса и по одному вопросу, который им необходимо решить. Не подменяйте их потребности собственными догадками.
- Составьте успешный и неуспешный сценарии. В каждом укажите наличие экземпляра, действие читателя и видимый ответ системы.
- Отметьте одно несогласованное правило и один способ проверить пользу после запуска. Например, отдельно учитывать обращения о книгах, которые ожидались свободными.
Как проверить результат. В карточке прослеживается связь между проблемой, правилом и проверкой. Понятно, что уже предложено для обсуждения, что согласовано лишь внутри учебного примера и какие сведения ещё нужно получить.
Частые вопросы
Макет экрана считается требованием?
Макет может помогать уточнять решение и связанные ожидания. Но изображение само по себе часто не описывает правила, исключения и причину изменения. Эти сведения полезно сохранять рядом и связывать между собой.
Нужно ли заранее перечислить все возможные ошибки?
Для первого обсуждения достаточно существенных сценариев и явно обозначенных пробелов. Детализацию выбирают по сложности и риску задачи. Неизвестные условия лучше записывать открыто, чем молча принимать за согласованные.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.