Бизнес-анализ от а до я: гид для начинающих

Формат нумерации я уже упоминал ранее и обсудил полезность этого уникального номера требования, который впоследствии может использоваться при обсуждении с членами команды или клиентом. При просмотре требований он позволяет сделать удобные ссылки на конкретное требование, без необходимости цитировать его полностью. Например, требование имеет номер ФР-СИМ-СИД-02. Клиент при проверке требований может сделать замечание: «Требование ФР-СИМ-СИД-02 не понятно, следует добавить детали». В плане формата требований я старался следовать простому правилу – стараться уместить требование в одно предложение, написать его в максимально простой форме.

У меня было черновое требование, которое звучало как: «Должна быть возможность создавать адрес для клиента, заполнять необходимые поля и редактировать их при необходимости». Я разбил этот черновик на следующие требования:

– «Система должна предоставлять возможность создать адрес для клиента»

– «Система должна предоставлять возможность редактировать адрес для клиента»

– «Система должна содержать следующие данные в адресе: тип адреса, страна, штат, город, улица, номер здания, номер офиса, индекс.

»

Атомарность требований позволяет затем значительно упростить решение любых вопросов, например, с клиентом, когда появляются запросы или пожелания к дополнению или изменению требований. Приведу простой пример, с которым я сталкивался: клиент может просмотреть и согласиться с требованиями №2 и №3, но пояснить, что для №1 он хотел бы уточнить, из каких частей приложения можно будет инициировать создание адреса.

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

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