Описание FSD или системных требований
Что такое FSD или Functional Specifications Document.
Из гугла - документ, который детально определяет функциональные требования к продукту с фокусировкой на реализации.
На деле - это документ с описанием поведения системы, со всеми альтернативными сценариями и ссылками на передаваемые параметры.
Этим документом в основном пользуются разработчики — при реализации и тестировщики — при тестировании.
Способов написания FSD огромное множество! Вы можете их легко нагуглить. Я буду писать о том, что помогло мне и моей команде, при разработке довольного большого проекта с кучей альтернативных сценариев.
Вначале, FSD писались как статьи. Целая скатерть из слов, цифр и списков. Читать это было сложно, а тестировать по этим статьям еще сложнее.
В следующий раз я начала рисовать диаграмму. В последствии, она очень сильно изменилась, и об этих изменениях, которые, кстати, и привели меня к этой статье, я напишу.
Что нужно учесть при описании FSD с помощью диаграммы:
- Определиться с нотацией
- Описать легенду
- Декомпозировать процессы
- Визуально отделять ветки подпроцессов и альтернативные сценарии
- Упростить просмотр параметров web-сервисов
Начнем с первого.
Определиться с нотацией. Вообще можно придумать свою нотацию. Главное, чтобы она была понятна коллегам, которые будут с ней работать. Для этого:
- Провести небольшой митинг с коллегами и узнать, как они предпочитают видеть спецификацию.
- Выбрать нотацию, которая удобнее всего будет конкретно для вашего описания (например, если много альтернативных сценариев, то подойдет больше диаграмма деятельности)
- Придумать свою диаграмму, но тогда очень важна вторая часть из списка - Легенда
Второе — Легенда.
Описать легенду легко. Тут есть два варианта:
- Описать вначале — сразу определиться с тем, какие будут использованы объекты (состояния, ветвления, сообщения, данные и т.д.)
- Описать в конце - собрать все объекты, которые были использованы хотя бы раз и описать их в легенде.
Третье — декомпозиция процессов
Декомпозиция процессов зависит только от системы, требования к которой должны быть описаны. Но укажу на самые основные:
- Декомпозиция по процессам — например, Процесс Авторизация, Процесс Регистрация, Процесс Выбора товара и т.д.
- Декомпозиция по формам/экранам — например, экран выбора счета, экран данных клиента, экран завершения оформления заказа и т.д.
Четвертое — визуальное оформление
Необходимо, для полного и облегчённого понимания процесса, визуально отделять некоторые элементы схемы.
- Альтернативные сценарии выделять в отдельные блоки (лучше закрашивать определенным цветом)
- Все новые элементы/объекты, на которые вы хотите обратить внимание разработчиков, выделять цветом и описывать в легенде.
- Отдельные части веток, которые соответствуют легаси или имеют единообразную функцию, тоже выделять блоками. Важно описывать кратко название блоков.
- Системы, с которыми интегрируется ваша система, процессы, которые к вашей системе не относятся (чтобы не вводить в заблуждение разработчиков) выделять цветом и описывать это в легенде. Также кратко описывать процессы которые происходят в другой системы — для общего понимания.
Пятое — Упростить просмотр параметров web-сервисов
Параметры web сервисов или описание методов API не поместятся ни в один блок схемы (можно конечно уместить, но получится довольно громоздко). Можно отдельно выписывать, например, в ветвлении, на какой именно параметр смотрим или какой проверяем. Это относится только к единичным атрибутам. Чтобы разработчикам не нужно было лезть и искать атрибут по которому отбираются определенные значения.
Для всех остальных простыней параметров методов, легче использовать ссылки.
- Это могут быть объекты — ссылки для параметров. Лучше вставлять ссылку на передаваемые параметры прямо внутрь объекта. Чтобы разработчики и тестировщики могли по клику переходить на страницу с описанными параметрами
- Оставлять ссылки рядом с объектами, которые подразумевают передачу некоторых параметров (например, «сохранение в БД» рядом ссылка на страницу с параметрами для сохранения в БД)