Обычно мы как аналитики ставим задачи на разработку (программную реализацию) одного из 5 видов требований:
- функционального программного - Function Requirement (FR),
- функционального аппаратно-программного - Equipment Requirement (ER),
- к интерфейсу пользователя - User Interface Requirement (UIR),
- к интеграции с внешними системами или сервисами - Integration Requirement (IR),
- запроса на изменения - Change Request (CR).
Можно расширить и усложнить эту типологию - любая классификация имеет степень условности, но нам для работы вполне достаточно и этой.
Как мы уже говорили, постановка нужна для того, чтобы программисты и другие инженеры службы разработки смогли однозначно понять, какое требование (выбираем тип выше) и каким образом должно быть закодировано так, что входящие данные обрабатываются в исходящие с нужным результатом.
Хорошей практикой является следующая примерная структура постановки как артефакта анализа (разделы можно сокращать или дополнять по целесообразности):
- введение и описание задачи - о чем постановка, что содержит и для какой крупной задачи проекта предназначена;
- реестр версий - кто, когда, какие правки и по чьей инициативе внес;
- реестр ответственности - имена и контакты (возможно, в формате ссылок на аккаунты типа Confluence) аналитика-исполнителя и согласователей, даты и статусы согласования;
- ссылки на соответствующие задачи в таск-менеджере (трекере);
- описание пользовательских ролей и их прав в проектируемом функционале;
- реестр реализуемых требований с подробным описанием соответствующих юзкейсов - или, как минимум, ссылками на них, мокапы UI и объекты модели данных;
- примечания с ограничениями и зависимостями от других требований.
Пример оформления постановки можно посмотреть в разделе
Портфолио.
При всей необходимой подробности, не следует перегружать постановку деталями из компетенций разработчиков - условно говоря, указывать, какие конкретные таблицы и атрибуты физической БД использовать для какого-либо элемента управления в UI, достаточно сослаться на логическую модель данных.