2022-07-21 02:56:47
{начало выше}
К чему все эти прелюдии? Днём ранее нашей командой проводилась очередная итерация выявления требований к создаваемому отраслевому порталу в рамках коммуникации с функциональным заказчиком. Портал, как видится, будет как достаточно развесистым в интеграционном плане, так и декомпозированным на ряд подсистем и модулей с управляемой моделью доступа к их функциям и соответствующим данным. Помимо ряда прочих, уже обсуждённых требований, заказчиком озвучивается следующее: "
На портале должна быть реализована функциональность запроса пользователями доступа к сервисам". Казалось бы, "пользователь", "запрос", "доступ", "сервис". Берём и делаем, ведь это всё про доступ к нашим же "блочкам" портала. И, всё же, "сервис" - это что? Подсистема / модуль / раздел портала, что-то внешнее? Если внешнее, то почему это связано с порталом? "Сервис" в данном случае - это яркий пример
implicit-формулировки требования. Выяснив, что под "сервисом" заказчик привык считать свои существующие информационные системы и ресурсы, а не имеет в виду условный раздел "WIKI" или "Видеоконференции" на создаваемом портале,
implicit-требование преобразуется в довольно конкретное
explicit.
К слову сказать, приведённый выше частный пример требования оказался достаточно критическим для заказчика, ранее не звучал, но вписывается в отведённый проектный бюджет. Пожалуй, довольно удачно, что пользователь сможет только запрашивать доступ на портале, а не запрашивать, после чего портал интегрируется с частными системами / DC / IdM, изменяет полномочия пользователя в целевом "сервисе" по approve-циклу администратора, возвращает пользователю почтовые уведомления со статусом выполнения его заявки и т.п. И если в ряде частных случаев всплывающие неучтённые
implicit-детали могут быть разрешены путём джентельменских договорённостей / выпуском доп. соглашения, то так происходит не всегда. Можно полагать, что с ненулевой вероятностью, в некоторой степени пропорциональной уровню работы проектной команды с требованиями, можно дотянуть до испытаний своё собственное разработческое представление о работе тех или иных функций ПО или системы в целом, а затем отправиться в цикл доработок / реинжиниринга или вовсе с протоколом замечаний и неподписанным актом, когда выяснится, что всё не совсем так, как представлялось.
Таким образом, вместо морали: здоровая форма дотошности при работе с требованиями, приземление категориального аппарата объекта автоматизации и просто рабочие вопросы "А что вы имеете здесь в виду?" - это адекватный минимум достаточно очевидных вопросов, которыми следует задаваться, не полагаясь лишь на собственный N-летний опыт, молниеносное и абсолютно точное схватывание "хотелок".
Implicit Reqs, рвущие бюджеты и cash-flow, не дремлют
#недоэнтимема
19 views23:56
Р
