Лабораторная работа №1
От исходного задания к описанию поведения системы
Контекст
Перед вами адаптированное реальное тестовое задание на вакансию Senior PHP-разработчика.
Из исходного задания намеренно удалены технические детали реализации: язык программирования, фреймворк, база данных, архитектура, API, способ хранения файлов и другие подобные решения.
Сегодня нас интересует не вопрос «как это запрограммировать?», а вопрос:
Что именно должна делать система?
Во время лабораторной преподаватель играет роль заказчика и доменного эксперта.
Если в задании не хватает информации, её не нужно додумывать молча — нужно сформулировать вопрос заказчику.
Исходное задание
Необходимо создать систему для работы с каталогом книг.
Книги
Для книги известны:
- название;
- год выпуска;
- описание;
- ISBN;
- изображение обложки.
У одной книги может быть несколько авторов.
Авторы
Для автора известно ФИО.
Работа с системой
Гость может:
- просматривать каталог;
- подписываться на новые книги автора.
Пользователь может:
- просматривать каталог;
- добавлять книги и авторов;
- изменять книги и авторов;
- удалять книги и авторов.
Отчёт
Система должна показывать ТОП-10 авторов, выпустивших больше всего книг за выбранный год.
Отчёт доступен всем.
Уведомления
При появлении новой книги автора, на которого подписался гость, гостю должно приходить SMS-уведомление.
Правило лабораторной
Сегодня не обсуждаем техническую реализацию.
Не нужно выбирать:
- язык программирования;
- фреймворк;
- базу данных;
- архитектуру;
- API;
- таблицы;
- классы;
- очереди;
- способ хранения изображений;
- конкретные библиотеки и сервисы.
Нас интересует только поведение системы:
кто → что делает → при каких условиях → что должно произойти
Как работать
Работа выполняется командами по 3–4 человека.
Сначала прочитайте исходное задание целиком.
После этого разберите его на отдельные части и для каждой существенной части ответьте на вопросы ниже.
1. Что уже известно?
Запишите факты, которые прямо следуют из исходного задания или из ответов заказчика.
Не смешивайте факты со своими предположениями.
2. Что непонятно?
Найдите места, которые допускают несколько разных трактовок.
Если из исходного задания нельзя однозначно понять, как должна вести себя система, это не ошибка команды.
Это означает, что нужно уточнение.
3. Какой вопрос нужно задать заказчику?
Сформулируйте вопрос так, чтобы ответ действительно мог изменить поведение системы.
Для каждого вопроса напишите:
- сам вопрос;
- почему ответ важен;
- что может измениться в зависимости от ответа.
Пример структуры:
| Вопрос | Почему это важно | Что может измениться |
|---|---|---|
| Что считается «новой книгой»? | От этого зависит момент отправки уведомления | Когда система должна отправлять SMS |
4. Зафиксируйте ответ заказчика
Когда преподаватель отвечает на вопрос, запишите ответ как правило системы.
Если ответа пока нет, явно напишите:
Не определено. Нужно решение заказчика.
Не заменяйте неизвестность своим молчаливым предположением.
5. Придумайте проверяемые сценарии
Для существенных правил придумайте конкретные ситуации.
Можно использовать простой формат:
Сценарий
Дано:
что уже произошло или существует в системе.
Когда:
какое действие или событие происходит.
Тогда:
что система должна сделать.
Пример:
Дано:
Иван подписан на автора Петрова.
Когда:
в каталоге появляется новая книга Петрова.
Тогда:
Иван должен получить SMS-уведомление.
Ищите пограничные случаи
Попробуйте найти ситуации, в которых обычное правило может оказаться недостаточно точным.
Например, можно подумать о случаях:
- у книги несколько авторов;
- человек подписан на нескольких авторов;
- книга связана сразу с двумя авторами, на которых подписан один человек;
- одну и ту же информацию пытаются добавить повторно;
- ранее добавленные данные изменяются;
- объект удаляется;
- несколько участников системы имеют разные права;
- два разных случая выглядят одинаково, но система должна реагировать на них по-разному.
Это не готовый список правильных вопросов.
Не нужно механически проходить его целиком.
Цель — научиться замечать места, где от уточнения действительно зависит решение.
Что должно быть в итоговом документе команды
1. Участники
Укажите:
- учебную группу;
- номер или название команды;
- ФИО всех участников.
2. Краткое понимание задачи
Своими словами опишите, какую проблему решает система и что она должна позволять делать.
Не пересказывайте исходный текст дословно.
3. Факты
Зафиксируйте то, что уже известно.
4. Вопросы заказчику
Для каждого существенного вопроса укажите:
- вопрос;
- почему он важен;
- что изменит ответ.
5. Решения заказчика
Запишите полученные ответы как правила системы.
6. Оставшиеся неопределённости
Если какие-то вопросы остались без ответа, перечислите их отдельно.
7. Проверяемые сценарии
Опишите несколько конкретных сценариев поведения системы.
Среди них должны быть не только обычные случаи, но и пограничные.
Критерии завершения работы
Работа считается завершённой, если:
- указаны все участники команды;
- задача описана без ухода в техническую реализацию;
- факты отделены от предположений и неизвестного;
- найдены существенные неоднозначности;
- сформулированы вопросы заказчику;
- для вопросов понятно, почему ответы важны;
- ответы заказчика зафиксированы как правила;
- неизвестные правила не выдуманы молча;
- приведены конкретные проверяемые сценарии;
- есть хотя бы несколько пограничных случаев;
- по итоговому документу другая команда может понять ожидаемое поведение системы без дополнительных устных объяснений авторов.
Важный принцип
Если два человека прочитали одно требование и получили две разные разумные трактовки, это не обязательно означает, что один из них неправ.
Возможно, требование пока недостаточно определено.
Задача команды сегодня — не угадать мысли заказчика, а обнаружить такие места и сделать поведение системы достаточно ясным для дальнейшей работы.