ailev.ru

19 января 2011 · Комментарий

Спасибо за обзор

Очень порадовал качественный и концентрированный обзор стандартов и подходов к представлению требований, таких материалов всегда не хватает. Если же по существу говорить о требованиях в ИТ, то главная проблема этого подхода в том, что требования в виде некоторого набора утверждений - они необозримы. А еще - по ним нельзя или сложно сказать нечто о системе за пределами сформулированных требований. Всегда существует некоторая вариативность процессов, и часто хочется понимать, насколько эта вариативность может быть поддержана. Более того, часто эта вариативность должна быть как-то заложена в требованиях, и не на уровне спектра поддерживаемых процессов, а на уровне вариантов mainstream-путей, поддерживаемых в эргономичном режиме. То есть, заказчик говорит: у нас этот процесс проходит 2 способами, и каждый - надо эффективно поддержать автоматизацией, а еще - мы хотим попробовать способ 3, и вообще бывает - еще штук 5, но их можно поддержать в полуручном режиме, однако хотелось бы представлять трудоемкость - вдруг мы захотим их использовать, а также стоимость реализации - если велика, мы лучше потом доработку закажем. На языке требований это не описывается, тут надо строить модели системы - через разные схемы - и доносить их до заказчика - тогда он сможет представить варианты. А как только модель построена - требования начинают представлять только исторический интерес, при чем только те, которые обосновывают конкретные не очевидные решения. Причем модель надо строить на ранних этапах, потому что заказчик еще заинтересован в деньгах и сроках и готов менять требования и свои процессы, если за счет этого систему можно получить сильно быстрее. Но готов менять, естественно, ограничено. Примерно так.

К записи · К обсуждению