Мне кажется, требования по Виггерсу пришли по аналогии из технических систем. Потому что в том же ТРИЗ-е постулируется, что противоречия в технических характеристиках (требуемых) проектируемых систем возникают из-за разных сценариев использования. И в технических системах это удобно, потому что характеристика, как правило, привязан к какому то конструктивному элементу. Но, только до определенного уровня.
Вот, например, нужно спроектировать мяч, для футбола, баскетбола, волейбола. Все мы знаем, что они разные, а еще у них разные размер, материал оболочки, нормативное/нормальное давление, что то еще. И если я пишу требования к шару, это все вполне легко описывается, но если я хочу написать их же к чему то более сложному, то начинаются сложности.
Я проектирую какой то околоспорткар, БМВ М-серии. Он должен ехать быстро, рулиться классно, как то там шустро разгоняться и тормозить, давать возможность “выпендриться перед девчулями”. И вот чтобы он классно рулился (сузим) на каком то серпантине (уже сценарий использования), он должен иметь скажем рычаги подвески определенной толщины и формы, потому что большие рычаги увеличивают инерцию и на каждой кочке колесо будет подпрыгивать высоко и медленно возвращаться на дорогу. И вот мы приходим к требованию веса рычага. Но рычаг не один (у спортивных авто), он часть системы “подвеска колеса”, а еше у него есть точка крепления через резинку/сайлентблок, это часть его как системы. И эта резинка должна выдерживать определенные нагрузки/давление/нагрев, это все те характеристики резинки, которые важны в сценарии “быстро ехать по серпантину”.
И эти характеристики опять же взяты как “эта штука должна быть такой, чтобы был возможен сценарий использования езда по серпантину”. Есть явная цепочка от сценария до конкретной циферки конкретного конструктивного элемента создаваемой системы. Но здесь же и зарыты ограничения, рычаг как конструктивный элемент уже есть в момент проектирования из культуры/опыта/практики/шаблонов/стандартных шаблонных конструкций (вахаводы поймут)(и империум вечен). Циферка его веса нужна проектировщикам для проектирования, производителям для производства.
Но если я проектирую не БМВ, а самобеглую коляску (нет опыта/культуры проектирования машин, все ездят на телегах), то чтобы прийти от сценария до циферки веса конкретного рычага (на самом деле функционального и конструктивного элемента), при котором коляска таки весело поедет по серпантину, вам нужно пройти путь. И этот путь будет состоять из множества цепочек гипотеза-моделирование-(прототип)-подтверждение гипотезу-балансировка характеристик. И лишь шагом на пути будет гипотеза “давайте сделаем рычаг вместо моста/ресссоры для передачи усилия на упругий элемент”. Другими словами, в процессе проектирования системы сценарий использования константа, а вес рычага переменная. К тому же вес рычага зависим: от веса машины, от примененного упругого элемента, еще много от чего.
Где то здесь я пытаюсь найти связь со своим опытом описания функциональных требований условно по Виггерсу (формализованных) в IT. Почему мне так и не удалось создать шаблон их описания? Сейчас мне кажется, что поэтому же, чтобы однозначно прописать эти требования, ты должен максимально детально нарезать систему на составляющие (простые приложения, где весь бэк можно назвать системой я не беру) и прописать такие требования к ним. Тогда любое взаимодействие с составляющей можно упихнуть в пару стимул-реакция, или событие-ответ на событие (ведь в этом в сущности все эти “система должна дать такой то ответ” при таком то событии от пользователя в роли). Но, здесь же и очевидная сложность и трение: это же тебе нужно сначала декомпозировать систему (будущую, проектируемую, по сути воображаемую сейчас), потом описать ее как какую структуру/композицию, принять некую версию описания за “так и будет”, и из этой точки описать функц-е требования к ее части (ака рычагу подвески передних колес).
Возможно ли это? Конечно да. Дорого ли это? Очень. Потому что тебе нужна качественная декомпозиция, очень много труда в формализованное описание (которое у меня нередко доходило до псевдокода). А какие еще издержки? Тут явно много согласований для утряски требований, это явно дорого менять после того, как все согласовано. Но самые главные издержки проявляются, как только такой подход накладывается на процесс разработки и условия “неполной неопределенности”. Первое более чем актуально для всяких информационных систем, где хотелки меняются очень быстро, второе для организационных, где ты сталкиваешься с “а что там думает человек вообще”. И для обоих, если положить их в контекст бесконечного развития.
Сценарий больше подходит для описания всей системы, а требования для описания функциональной части, явной, выделенной, в идеале уже существующей в культуре/практике.