Форум Сообщества Аналитиков

×


Требования = Решения(Прочитано 20024 раз)
Требования = Решения : 23 Июня 2007, 00:54:40
Вот тут возникла идея статьи для Requirements Network.

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

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

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

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

Пример:

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

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

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

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

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

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

Что думаете, дерзко? )
« Последнее редактирование: 23 Июня 2007, 00:58:09 от Денис "Майевтик" »



Re: Требования = Решения Ответ #1 : 23 Июня 2007, 12:47:01
Решение на мой взгляд - это готовый продукт. А будут ли требования совпадать с решением еще не факт.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Требования = Решения Ответ #2 : 23 Июня 2007, 18:52:04
bas, "Решение" как взаимоувязанный программно(-аппаратный) комплекс, предназначеный для автоматизации конкретного вида деятельности, БП или их набора - это одно из возможных пониманий термина, причём навязанное консалтерами и интеграторами. Понятия "управленческое решение", "проектное решение" и "техническое решение" - гораздо более зрелые термины.

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

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



Re: Требования = Решения Ответ #3 : 23 Июня 2007, 18:55:16
Решение на мой взгляд - это готовый продукт. А будут ли требования совпадать с решением еще не факт.
Если решение - это по твоему продукт, а требования, как ты надеюсь согласишься, "условие или возможность", то даже рассуждать о возможности "совпадения" продукта и условий - бессмысленно.



Re: Требования = Решения Ответ #4 : 25 Июня 2007, 15:19:00
Ну ладно уговорили, только решение = набор требований.

Только какой в этом практический смысл??
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Требования = Решения Ответ #5 : 26 Июня 2007, 01:25:07
Ну ладно уговорили, только решение = набор требований.
Саша, когда Архитектор принимает решение, в частности, что такая-то задача будет решаться с применением шаблона Transaction Script, то это ровно 1 (одно) решение, и ровно 1 (одно) требование для программиста.

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

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



Re: Требования = Решения Ответ #6 : 26 Июня 2007, 09:35:38
Денис,

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



Re: Требования = Решения Ответ #7 : 26 Июня 2007, 11:39:43
Очень хорошее предложение - артикулированно отображать в документе с описанием требований (ТЗ) указание на уровень и особенно - на роль (лицо), которое это требование выдвинуло. Представляется важным избегать безличных требований, выдвинутых "именем закона природы" или даже "именем рынка". Практически всегда составитель документа "Требования" получает информацию о таких глобальных требованиях от конкретного лица, т.е. как конкретное понимание требований рынка данным конкретным лицом.
Уровни, как они представлены в таблице классификации требований Дениса, фактически и задаются конкретными ролями ("Ответственные").
Привязка требований к конкретным ролям (лицам) проекта также является хорошим ключом к решению проблем (если такие возникают) отнесения тех или иных требований к конкретному уровню (через решение воспроса, кто именно за них будет отвечать).



Re: Требования = Решения Ответ #8 : 26 Июня 2007, 14:31:59
Все как-то смешалось - "требование - это решение", а "решение - это требование". С одной стороны, с этим нельзя не согласиться. Но, с другой стороны, какая от этого польза? Такая вот игра слов может быть применима только к некоему документу, который возникает в результате выполнения очередного этапа создания системы. На входе этапа всегда требование, а на выходе решение. Если представить, что процесс создания системы это набор этапов, на входе которых требования, а на выходе - решения, то на входе процесса создания системы находится тоже требование, а на выходе  -  решение, то бишь сама система.
Успех - не окончателен, поражение - не фатально, мужество продолжать - вот, что имеет значение.



Re: Требования = Решения Ответ #9 : 26 Июня 2007, 23:35:57
что в ТЗ будем включать все. Это как??
Где я это сказал?



Re: Требования = Решения Ответ #10 : 26 Июня 2007, 23:52:35
Все как-то смешалось - "требование - это решение", а "решение - это требование". С одной стороны, с этим нельзя не согласиться. Но, с другой стороны, какая от этого польза?
Вы знаете, я получаю удовольствие от проникновения в суть вещей, и отделения истинного от традиционного. За инсайтом не всегда следует немедленное понимание практической пользы.

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



Re: Требования = Решения Ответ #11 : 27 Июня 2007, 01:09:57
1. Эпиграф: "Эк вас на фисолофию потянуло" ...
2. ОК, ну и так известно, что граница между требованиями и дизайном достаточно размыта. И только вопрос в договоренностях о том, что считаем требованием, а что дизайном в каком конкретном случае. От того что проектные решения будут называться "требованиями для программиста", они станут качественнее? Вопрос в большей степени в том, где нужно остановиться при детализации требований. И еще ... использование паттерна transaction script является потребительским свойством системы? Скорее всего нет, но другой вопрос, что это может повлиять на ряд этих свойств.
3. Кроме этого следует упомянуть еще и про то, что существуют т.н. ОГРАНИЧЕНИЯ ПРОЕКТИРОВАНИЯ ... которые по сути -- дизайн, а по форме -- требования (или наоборот :-)?)
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Требования = Решения Ответ #12 : 27 Июня 2007, 01:23:49
ОК, ну и так известно, что граница между требованиями и дизайном достаточно размыта. И только вопрос в договоренностях о том, что считаем требованием, а что дизайном в каком конкретном случае.
О, даже Юра вляпался ) Какая граница? Я говорю о том, что требования ОДНОВРЕМЕННО являются решениями и наоборот, если смотреть на процесс и систему вцелом, не замыкаясь в какой-то одной роли (БА, СА).

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

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

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



Re: Требования = Решения Ответ #13 : 27 Июня 2007, 10:39:43
Это не игра слов, это Роль, которую играет Утверждение о свойстве системы в отношении Участника процесса её создания. Про "применимость только к документу" обоснуйте.

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



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

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

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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19