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