Хочу поделиться статьей о заблуждениях в работе аналитика. Добавила немного и от себя (со значком 🔎).
Статья Common Misconceptions About Requirements Engineering о том, что, некоторые знания из инженерии требований могут теряться, если аналитик руководствуется только BABOK.
📖 Бывает, что объединяются или подменяются типы требований, которые в инженерии требований (IREB) находятся на двух разных уровнях абстракции. Речь о терминах “требования пользователей” и “системные требования”. “Системные требования” описывают как система работает и находятся в области решений, в отличие от “требований пользователей”, которые относятся к области бизнеса и отражают потребности группы заинтересованных сторон, которая будет использовать приложение.
🔎 Я никогда не относилась слишком серьезно к формальной классификации требований. Тем не менее, когда оказываешься перед потоком информации, нужен ориентир, который поможет этот поток направить в нужное русло. Например, менеджер проекта по запуску нового кредитного продукта рассказал вам на встрече как должна быть сверстана страница заполнения клиентских данных и какой сервис должен быть вызван нажатием на кнопку “Сохранить”. Вы вернулись на рабочее место и думаете, в какой раздел документа записать такую “хотелку”. Вопрос-то больше в том, чтобы понять нужно ли ее вообще куда-либо записывать. Можно ли это считать системным требованием, про вызов сервиса же говорили? или это потребность менеджера как заинтересованной стороны? или требование к решению? или требование пользователя? Классификация требований и знания о заинтересованных сторонах подсказывают, что перед нами просто точка зрения на фронт и бэк решения от одного из участников проекта, который не является ни экспертом-разработчиком, ни пользователем будущего продукта. Запишем “хотелку” в протокол встречи для истории, там она и должна оставаться.
В чем здесь разногласие с BABOK? В BABOK уровни требований не предусмотрены, а типизация требований такая: бизнес-требования, требования заинтересованных сторон, требования к решению, переходные требования. Не предложено классификации по уровням. В примере с менеджером действительно можно ошибиться и отнести “хотелку” либо к требованиям к решению, либо к требованиям заинтересованных сторон.
📖 Существует еще одно общее заблуждение, что заинтересованные стороны - единственный источник требований. На самом деле источников гораздо больше - контекст разработки и использования системы, документация, аналогичные системы на рынке, текущие решения в организации, бизнес-процессы, регламенты…
🔎 От себя грустно добавлю, приходится наблюдать такое заблуждение, что для выявления требований достаточно “пойти и спросить заказчика”. На конференциях и тренингах нас учат “проводить discovery”, а при постановке задачи аналитику чаще всего слышим “нужно провести интервью с заказчиком и записать все его требования” и “как им надо, так и сделаем”. Об этом тоже нашлась неплохая статья, расскажу о ней позже…
