документация — Антон Григорьев

Функциональная спецификация интерфейса: что это, зачем нужна, как её писать

Функциональная спецификация вместе с прототипом рассказывает, из каких элементов состоит и как работает интерфейс системы. Она описывает то, что трудозатратно, невозможно или бессмысленно показывать в прототипе.

С её помощью можно улучшить предлагаемые решения, ответить на вопросы разработчиков и других участников проекта, зафиксировать договорённости на бумаге.

В этой статье я рассказал, как она помогает сделать продукт лучше, что можно включить в спецификацию, как её структурировать, что писать об отдельных элементах интерфейса и что уже выходит за рамки подобного документа.

Надеюсь, это поможет вам в написании спецификаций для своих интерфейсов.

Как заставить читать документацию

Проектирование — это формирование образа продукта в головах исполнителей и заказчиков. При этом стороны активно создают документы и обмениваются ими.

Илья Бирман, арт-директор бюро Артёма Горбунова, говорит, что не читает присылаемые технические задания. Проекты всегда нужно обсуждать. Один и тот же документ разные люди поймут по-разному.

По этой причине дизайнеры Бюро не пишут спецификаций для разработчиков. Разработчики сами разбираются в проекте, задают дизайнерам вопросы и спецификациями показывают, как поняли сказанное.

Результат проектирования

Проектная документация

В процессе проектирования мы решаем, как должен работать будущий продукт, и документируем решения. Чем детальнее наши документы, тем лучше:

Заказчик видит, что получит через несколько месяцев разработки, и может оценить, правильно ли его понял исполнитель;
Исполнитель точнее оценивает объём работ;
Документы становятся частью договора. Отклонение от изначальных проектных решений со стороны заказчика или исполнителя приведёт к изменению стоимости и сроков проекта;
У заказчика появляется возможность ещё раз задуматься о будущем продукте и скорректировать своё видение.

Всё это повышает шансы проекта на реализацию.

Карл Вигерс, автор книги «Разработка требований к программному обеспечению», подсчитал, что на американском рынке разработки 40% бюджета проекта уходит на переделки из-за того, что заказчик и исполнитель плохо сформулировали требования к продукту и вообще не поняли друг друга.