Об implicit и explicit требованиях: некапитанская очевидность
На практике, работая с той или иной степенью детализации требований заказчика к создаваемому ПО, мы достаточно часто склонны к тому, чтобы слышать, читать и, в конечном счёте, воспринимать их (требования aka "хотелки") так, как нам кажется верным. Разумеется, это восприятие опирается на эмпирику и когнитивистику. Кроме того, нередко достаточно жёсткие временные, экономические и прочие проектные рамки диктуют необходимость повышения экономии человеческого ресурса, в т.ч. выявляющего, формализующего и согласующего требования к ПО на первичных этапах его реализации. Проще говоря: мы стараемся с первых "аккордов" понять заказчика, а сам заказчик - не углубляться в "очевидные" аспекты функционирования его бизнеса, существующего системного ландшафта и т.п.
Сегодня речь о двух вещах, лежащих на поверхности, а именно: о тех пожеланиях и требованиях к реализации ПО, которые кажутся очевидными, и тех из них, которые не являются очевидными, но кем-то из числа "генераторов хотелок" подразумеваются как таковые. Для категориальной согласованности далее введём пару употребляемых в индустрии понятий в контексте Functional и Non-Functional Reqs: "
implicit" - нечто
подразумеваемое, "
explicit" -
явное, чётко и точно определённое.
Не жонглируя гибкими подходами / методологиями разработки ПО и "классикой", можно утверждать, что чем позже мы получаем запрос на изменение того или иного требования к ПО, тем дороже его имплементация по отношению, по крайней мере, к этапу первичного проектирования (одна из типовых визуализаций двух кривых затрат Boehm/Beck приведена на изображении к посту). Теоретические и практические подтверждения тому можно встретить N-раз на просторах интернета, в т.ч. здесь.
{продолжение ниже}
