Вот тут возникла идея статьи для Requirements Network.

Главный тезис такой - Requirements ARE Design Solutions.

Вот есть такое определение требования, что это-де "это условие или возможность, которой должна соответствовать система". Давайте посмотрим, а что такое, с другой стороны, "проектное решение"? На мой взгляд, проектное решение - это тоже некоторое утверждение о свойствах системы, которому она должна соответствовать.

Как же так, скажете вы, нас всю жизнь учили - "не путайте требования с решениями"?

А дело, на мой взгляд, вот в чём - объективно нет никаких Требований и Решений - есть только Утверждения. И эти Утверждения могут играть Роль Требования или Решения, в зависимости от его отношения к вам. Оно либо приходит к вам (Input, Requirement Statement) и вы его перерабатываете во что-то другое, либо исходит от вас, и тогда для вас оно Решение (Output, Design Statement).

Пример:

Рынок давит на Заказчика, вынуждает его повышать качество продукции и объёмы производства и снижать цены. Это Утверждения, которые порождает Рынок, в каком-то смысле его Решения.

Заказчик воспринимает эти Утверждения как Требования рынка, думает и говорит - хочу, чтобы система производства обрабатывала в 10 раз больше заявок, чем сейчас. Это его Бизнес-Решение.

Если вы Аналитик, то вы воспринимаете его Бизнес-решение как Бизнес-требование и выстраивая концептуальную модель системы преобразуете его в набор Общесистемных Решений относительно того, какими свойствами должна обладать система для выполнения этого бизнес-требования. Эти Общесистемные Решения являются результатом вашего труда.

Эти утверждения относительно системы передаются Архитектору, который воспринимает их как Общесистемные Требования. Прорабатывая их, он создаёт Решения относительно внутреннего устройства системы, а именно - технической архитектуры, набора подсистем и их интерфейсов - Внутрисистемные Решения.

Эти утверждения передаются как Требования к подсистеме Проектировщику подсистемы и т.д.

Далее см. мою таблицу типов требований (а на самом деле - категорий утверждений о свойствах системы).

Что думаете, дерзко? )

Решение на мой взгляд - это готовый продукт. А будут ли требования совпадать с решением еще не факт.

bas, "Решение" как взаимоувязанный программно(-аппаратный) комплекс, предназначеный для автоматизации конкретного вида деятельности, БП или их набора - это одно из возможных пониманий термина, причём навязанное консалтерами и интеграторами. Понятия "управленческое решение", "проектное решение" и "техническое решение" - гораздо более зрелые термины.

Давай я скажу не Design Solutions, а Design Decision. Ведь тебе как аналитику приходится принимать решения? И архитектору и программисту приходится и бизнесу само собой.

Кстати, понятие Концепция также многозначно - под этим может пониматься и документ в целом и "определённый способ понимания (трактовки) какого-либо предмета, явления или процесса; основная точка зрения на предмет; руководящая идея для их систематического освещения".

Решение на мой взгляд - это готовый продукт. А будут ли требования совпадать с решением еще не факт.

Если решение - это по твоему продукт, а требования, как ты надеюсь согласишься, "условие или возможность", то даже рассуждать о возможности "совпадения" продукта и условий - бессмысленно.

Ну ладно уговорили, только решение = набор требований.

Только какой в этом практический смысл??

Ну ладно уговорили, только решение = набор требований.

Саша, когда Архитектор принимает решение, в частности, что такая-то задача будет решаться с применением шаблона Transaction Script, то это ровно 1 (одно) решение, и ровно 1 (одно) требование для программиста.

Только какой в этом практический смысл??

А смысл такой, что Требования не замыкаются только на аналитика, практически каждый участник команды их формулирует в рамках своей зоны ответственности и выполняет внешние для себя требования. Практический смысл такой, что под фразой "Требования к системе" на само деле скрывается громадный спектр возможных требований, в зависимости от того, какие именно категории включает в понятие говорящий. Чтобы преодолеть разночтения, я предлагаю распространить понятие требования на весь спектр решений, и при оперировании понятием требования всегда указывать, к какому уровню оно относится. Грубо говоря, в проекте "всё есть требование", только какие-то требования (цели и задачи проекта) формулируются и за их выполнение отвечает ПМ, за какие-то БА (модель предметной области, БПроц, БПрав, б-требования),  за какие-то - Инженер по качеству, за какие-то - программист. Причём различные категории требований имеют различные механизмы задания. Например, цвета, шрифты, относительные размеры блоков в интерфейсе вполне могут задаваться в графическом макете графдизайнером. Эти требования выполняет верстальщик.

Кроме того, это снимает внутреннюю психологическую напряжённость от необходимости включать в ТЗ то, что традиционно считается относящимся к области решений, а не требований.

Денис,

Тебя не поймешь, то ты сначала говоришь об разграничении уровней требований, а потом заканчиваешь, что в ТЗ будем включать все. Это как??

Очень хорошее предложение - артикулированно отображать в документе с описанием требований (ТЗ) указание на уровень и особенно - на роль (лицо), которое это требование выдвинуло. Представляется важным избегать безличных требований, выдвинутых "именем закона природы" или даже "именем рынка". Практически всегда составитель документа "Требования" получает информацию о таких глобальных требованиях от конкретного лица, т.е. как конкретное понимание требований рынка данным конкретным лицом.
Уровни, как они представлены в таблице классификации требований Дениса, фактически и задаются конкретными ролями ("Ответственные").
Привязка требований к конкретным ролям (лицам) проекта также является хорошим ключом к решению проблем (если такие возникают) отнесения тех или иных требований к конкретному уровню (через решение воспроса, кто именно за них будет отвечать).

Все как-то смешалось - "требование - это решение", а "решение - это требование". С одной стороны, с этим нельзя не согласиться. Но, с другой стороны, какая от этого польза? Такая вот игра слов может быть применима только к некоему документу, который возникает в результате выполнения очередного этапа создания системы. На входе этапа всегда требование, а на выходе решение. Если представить, что процесс создания системы это набор этапов, на входе которых требования, а на выходе - решения, то на входе процесса создания системы находится тоже требование, а на выходе  -  решение, то бишь сама система.

что в ТЗ будем включать все. Это как??

Где я это сказал?

Все как-то смешалось - "требование - это решение", а "решение - это требование". С одной стороны, с этим нельзя не согласиться. Но, с другой стороны, какая от этого польза?

Вы знаете, я получаю удовольствие от проникновения в суть вещей, и отделения истинного от традиционного. За инсайтом не всегда следует немедленное понимание практической пользы.

Такая вот игра слов может быть применима только к некоему документу, который возникает в результате выполнения очередного этапа создания системы. На входе этапа всегда требование, а на выходе решение. Если представить, что процесс создания системы это набор этапов, на входе которых требования, а на выходе - решения, то на входе процесса создания системы находится тоже требование, а на выходе  -  решение, то бишь сама система.

Это не игра слов, это Роль, которую играет Утверждение о свойстве системы в отношении Участника процесса её создания. Про "применимость только к документу" обоснуйте.

1. Эпиграф: "Эк вас на фисолофию потянуло" ...
2. ОК, ну и так известно, что граница между требованиями и дизайном достаточно размыта. И только вопрос в договоренностях о том, что считаем требованием, а что дизайном в каком конкретном случае. От того что проектные решения будут называться "требованиями для программиста", они станут качественнее? Вопрос в большей степени в том, где нужно остановиться при детализации требований. И еще ... использование паттерна transaction script является потребительским свойством системы? Скорее всего нет, но другой вопрос, что это может повлиять на ряд этих свойств.
3. Кроме этого следует упомянуть еще и про то, что существуют т.н. ОГРАНИЧЕНИЯ ПРОЕКТИРОВАНИЯ ... которые по сути -- дизайн, а по форме -- требования (или наоборот :-)?)

ОК, ну и так известно, что граница между требованиями и дизайном достаточно размыта. И только вопрос в договоренностях о том, что считаем требованием, а что дизайном в каком конкретном случае.

О, даже Юра вляпался ) Какая граница? Я говорю о том, что требования ОДНОВРЕМЕННО являются решениями и наоборот, если смотреть на процесс и систему вцелом, не замыкаясь в какой-то одной роли (БА, СА).

От того что проектные решения будут называться "требованиями для программиста", они станут качественнее?

"Ты перестал пить коньяк по утрам?"

Вопрос в большей степени в том, где нужно остановиться при детализации требований.

Смотря что мы обсуждаем. Я пытался обсуждать очистку совести (избавления от шизофрении) при засовывании макетов интерфейса в ТЗ

3. Кроме этого следует упомянуть еще и про то, что существуют т.н. ОГРАНИЧЕНИЯ ПРОЕКТИРОВАНИЯ ... которые по сути -- дизайн, а по форме -- требования (или наоборот :-)?)

Если ты про таблицу - то да, она давно просит обновления.

Это не игра слов, это Роль, которую играет Утверждение о свойстве системы в отношении Участника процесса её создания. Про "применимость только к документу" обоснуйте.

Употребляя слово "документ", я имела в виду, что каждое утверждение, высказанное любым из участников процесса, будь то заказчик или исполнитель, должно быть задокументировано. Имея некий документ, можно решать, для кого он требование, а для кого решение. А если утверждение осталось висеть в воздухе, то через пару дней обязательно возникнут трения по поводу кто что должен делать. ...Заказчики вобще умудряются отказываться от своих собственных слов, которые записаны на диктофон.

<...>А дело, на мой взгляд, вот в чём - объективно нет никаких Требований и Решений - есть только Утверждения. И эти Утверждения могут играть Роль Требования или Решения, в зависимости от его отношения к вам. Оно либо приходит к вам (Input, Requirement Statement) и вы его перерабатываете во что-то другое, либо исходит от вас, и тогда для вас оно Решение (Output, Design Statement).
<...>
Что думаете, дерзко? )

Дерзко. Взять отмести мнение большинства гуру.

Действительно, всё, что утверждено заказчиком - требование. Сроки - требование. Функциональность - требование. Графический дизайн - требование. И даже unit-тесты - требование, если их ухитирились утвердить.
А с другой стороны - сроки не на пустом месте возникли, это - решение относительно трудоёмкости и рисков. И функциональность не просто так предлагают, а уж UC/US разработать - ничуть не проще, чем, к примеру, структуру БД. "Сбора" требований нет, они нигде не лежат готовыми, их нужно "вылавливать", "тралить", а лучше - "предлагать".

Лично я склонен подразделять артефакты "до кода" не на "требования" и "решения", а на "требования" и "архитектуру". И оставлять за разработчиками как можно больше архитектуры, которая по определению не требует утверждения у заказчиков. Иначе не будет пространства для манёвра. Запишешь, например, самостоятельно разработанную структуру БД или навигации GUI в требования, утвердят её (задав множество глупых вопросов и потребовав множества глупых, ухудшающих исправлений), а потом перед каждым изменением - снова согласовывать.

Мне кажется, что гуру имели в виду именно такое разделение, не с точки зрения процесса создания, а с точки зрения процесса утверждения и жёсткости фиксации.