Назначение программы: как сформулировать без путаницы с функциями

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

В ГОСТ 19 и ГОСТ 34 назначение связывает требования, архитектуру, испытания и эксплуатацию. Если назначение сформулировано размыто, дальше сложнее выбрать функции, проверить результат и объяснить, почему часть требований находится вне границ программы.

• когда нужно отделить цель программы от перечня функций;
• при подготовке описания программы по ГОСТ 19.402;
• в техническом проекте по ГОСТ 34, где назначение связывает систему с процессами и пользователями;
• при подготовке ПМИ, чтобы проверять не только отдельные функции, но и достижение ожидаемого результата;
• в пояснительной записке, архитектурном описании или ISO/IEC/IEEE 42010-ориентированном комплекте, где нужно показать роль программы в системе;
• когда проект передается другой команде и важно сохранить смысл продукта, а не только список экранов или API.

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

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

Удобная формула: “Программа предназначена для [пользователь или система] с целью [основная задача] путем [ключевые действия] с использованием [данные или интеграции] в границах [условия и ограничения]”.

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

Слишком широко: “Программа предназначена для автоматизации документооборота”.

Лучше: “Программа предназначена для регистрации входящих документов, маршрутизации задач ответственным сотрудникам, контроля сроков согласования и передачи статусов в учетную систему организации”.

Слишком функционально: “Программа отправляет уведомления, строит отчеты и хранит карточки”.

Лучше: “Программа предназначена для поддержки процесса обработки клиентских заявок: сохраняет карточки обращений, уведомляет ответственных сотрудников и формирует отчетность по срокам реакции”.

Назначение описывает смысл и границы программы. Функции описывают действия, которые программа выполняет для достижения этого назначения. Если в назначении перечислены десятки операций, его трудно использовать при проектировании и приемке. Если назначение состоит только из “повышения эффективности”, оно не помогает проверить результат.

• писать пустую формулу вроде «программа предназначена для автоматизации деятельности» без предмета и результата;
• смешивать назначение с функциями, интерфейсами или внутренней структурой;
• использовать слишком технический язык там, где нужно объяснить роль программы в процессе;
• не указать место программы в экосистеме: с какими системами, пользователями и данными она связана;
• оставить назначение без проверяемого результата, из-за чего его нельзя связать с архитектурой, испытаниями и внедрением.

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