В любом случае, на момент разработки требований, было известно, что такая роль точно должна существовать, и ее создают специальным (отличным от других ролей) способом. И, известно, что посредством именно этой роли будут раздаваться права на функциональность других ролей. Так что тут противоречий нет :-).

1. Разделить ФТ и НФТ также думал увести низ разделяющей линии вправо, но как-то некрасиво получалось Видимо других вариантов нет, так и сделаю.

сдается мне это тоже не решит проблему. У Вигерса бизнес-требования не зря были чисто функциональными, никто ведь не разрабатывает ИС для того, чтобы в ней была система хранения на 1 ПБ (к примеру)! Мне кажется бизнес-требования носят чисто функциональный характер.

сдается мне это тоже не решит проблему. У Вигерса бизнес-требования не зря были чисто функциональными, никто ведь не разрабатывает ИС для того, чтобы в ней была система хранения на 1 ПБ (к примеру)! Мне кажется бизнес-требования носят чисто функциональный характер.

Не согласен. НФТ на уровне БТр м.б. и законодательные акты и требования на уровне организации, что они рассматривают только такие платформы. Бизнес НФТ - это ограничения на уровне Бизнеса.

НФТ на уровне БТр м.б. и законодательные акты и требования на уровне организации, что они рассматривают только такие платформы.

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

Я чо-та много пропустила в ходе беседы, но кто-нибудь из классификаторов вообще заморачивается таким понятием, как признак, по которому классифицируются требования? В зависимости от этого можно наплодить столько классификаций, сколько надо.
Пример, предложенный Вигерсом, в общем случае тянет на классификацию по типу источника требований (бизнес, пользователи, система).
Никто не запрещает разным видам классификаций существовать и использоваться теми и тогда, кому и когда они удобны/уместны.

Обычный же подход к структурированию информации.

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

Цель должна быть SMART, т.е. в т.ч. и достижимая, а на это как раз и влияют бизнес ограничения.
БПр - это уже конкретное условие. На уровне бизнеса это м.б. ограниченно просто соответствием какому-то закону.

Я чо-та много пропустила в ходе беседы, но кто-нибудь из классификаторов вообще заморачивается таким понятием, как признак, по которому классифицируются требования? В зависимости от этого можно наплодить столько классификаций, сколько надо.
Пример, предложенный Вигерсом, в общем случае тянет на классификацию по типу источника требований (бизнес, пользователи, система).
Никто не запрещает разным видам классификаций существовать и использоваться теми и тогда, кому и когда они удобны/уместны.

Обычный же подход к структурированию информации.

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

У Вигерса удобно то, что все группы требований ложатся в какой-то один раздел ТЗ (если по ГОСТ 34.602). Также они упорядочены по времени сбора данных требований. А предложенную схему/классификацию/модель лично я применить на практике затрудняюсь.

У Вигерса удобно то, что все группы требований ложатся в какой-то один раздел ТЗ (если по ГОСТ 34.602). Также они упорядочены по времени сбора данных требований. А предложенную схему/классификацию/модель лично я применить на практике затрудняюсь.

Хотелось бы подробнее узнать, о том, какие именно группы требований в какие именно разделы ТЗ по ГОСТ 34 ложатся, можете привести схему маппинга?

А в чем именно состоят затруднения применения на практике данной схемы?

Если использовался только один признак - источник требований, как в этом случае должно выглядеть множество значений данного признака (множество источников требований)?

Теперь видимо я чего-то не понимаю.

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

Мы об одном и том же, или о разном? )

Теперь видимо я чего-то не понимаю.

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

Мы об одном и том же, или о разном? )

Собственно вопрос в том, чтобы перечислить эти самые источники требований ("требования от мамы", "требования от папы", ...) только в приложении к схеме Вигерса. 

Хотелось бы подробнее узнать, о том, какие именно группы требований в какие именно разделы ТЗ по ГОСТ 34 ложатся, можете привести схему маппинга?

Как вариант:
Бизнес-требования -> Раздел 2 "НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ (РАЗВИТИЯ) СИСТЕМЫ"
Требования пользователей -> Раздел 4.1.1. "Требования к структуре и функционированию системы"
Бизнес-правила -> Разделы 4.1.4 - 4.1.14 (4.1.4   Требования к надежности, 4.1.5   Требования безопасности, 4.1.6   Требования к эргономике и технической эстетике, 4.1.7   Требования к транспортабельности для подвижных АС, 4.1.8   Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы, 4.1.9   Требования к защите информации от несанкционированного доступа, 4.1.10   Требования по сохранности информации при авариях, 4.1.11   Требования к защите от влияния внешних воздействий, 4.1.12   Требования к патентной чистоте, 4.1.13   Требования по стандартизации и унификации, 4.1.14   Дополнительные требования) в зависимости от содержания требований
Атрибуты качества -> Раздел 4.1.3"Показатели назначения"
Системные требования -> Раздел 4.3"Требования к видам обеспечения"
Функциональные требования -> Раздел 4.2 "Требования к функциям (задачам), выполняемым системой"
Внешний интерфейс -> Разделы 4.3.3   "Требования к лингвистическому обеспечению" и 4.3.4   "Требования к программному обеспечению"
Ограничения -> Раздел 4.1.14"Дополнительные требования"

А в чем именно состоят затруднения применения на практике данной схемы?

На предложенной схеме выделены 3 группы: "Бизнес-требования", "Пользовательские требования" и "Системные требования", при этом граница между функциональными и нефункциональными требованиями очень размыта (непонятно, где она должна проходить). Что дает такая схема? Какие плюсы от ее использования? 

Как вариант:
Бизнес-требования -> Раздел 2 "НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ (РАЗВИТИЯ) СИСТЕМЫ"
Требования пользователей -> Раздел 4.1.1. "Требования к структуре и функционированию системы"
Бизнес-правила -> Разделы 4.1.4 - 4.1.14 (4.1.4   Требования к надежности, 4.1.5   Требования безопасности, 4.1.6   Требования к эргономике и технической эстетике, 4.1.7   Требования к транспортабельности для подвижных АС, 4.1.8   Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы, 4.1.9   Требования к защите информации от несанкционированного доступа, 4.1.10   Требования по сохранности информации при авариях, 4.1.11   Требования к защите от влияния внешних воздействий, 4.1.12   Требования к патентной чистоте, 4.1.13   Требования по стандартизации и унификации, 4.1.14   Дополнительные требования) в зависимости от содержания требований
Атрибуты качества -> Раздел 4.1.3"Показатели назначения"
Системные требования -> Раздел 4.3"Требования к видам обеспечения"
Функциональные требования -> Раздел 4.2 "Требования к функциям (задачам), выполняемым системой"
Внешний интерфейс -> Разделы 4.3.3   "Требования к лингвистическому обеспечению" и 4.3.4   "Требования к программному обеспечению"
Ограничения -> Раздел 4.1.14"Дополнительные требования"
На предложенной схеме выделены 3 группы: "Бизнес-требования", "Пользовательские требования" и "Системные требования", при этом граница между функциональными и нефункциональными требованиями очень размыта (непонятно, где она должна проходить). Что дает такая схема? Какие плюсы от ее использования? 

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

По использованию схемы - граница м/у различными типами требований лежит в их определении и их назначении. Они вполне себе четко идентифицированы и понятно с какой point of view (в архитектурном смысле) они задаются. В ТЗ по ГОСТ, используется несколько другой подход и другая точка зрения (он не лучше и не хуже, т.е. я не даю ему оценку в данном постинге). И, как раз, если смотреть с позиции "вигерсовской схемы" на ТЗ, то как раз ТЗ будет казаться некоторым смешением точек зрения "в одном флаконе". Плюсами от использования схемы Вигерса можно считать ее понятность, для решения бизнес-задач в первую очередь и изоляцию разных точек зрения (включающих в т.ч. источники требований), что дает возможность использовать различные подходы для выявления требований, их анализа и документирования.

Интересно было бы как раз получить подобную схему для ГОСТ 34 ... где бы были классифицированы требования по их типам, т.е. по сути синтезировать по документарному отображению модель требований, лежащей в основе ГОСТ 34.

Пользовательские требования (по их определению) не ложатся на "Требования к структуре и функционированию системы", т.к. они не про систему и ее структуру (суть архитектуру)

По Вигерсу пользовательские требования есть варианты использования системы. Ну а где же их еще прописывать, как не в разделе "Требования к структуре и функционированию системы"? Затрудняюсь найти под эти требования другой раздел ТЗ.

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

Вы правы, не совсем, и только в ряде случаев.

В целом, не вполне корректный IMHO мэппинг

С другой стороны, если написать ТЗ по данной схеме, вряд ли какой Заказчик будет против  Документ получится достаточно последовательным и логичным. А что еще надо для работы?

Интересно было бы как раз получить подобную схему для ГОСТ 34 ... где бы были классифицированы требования по их типам, т.е. по сути синтезировать по документарному отображению модель требований, лежащей в основе ГОСТ 34.

можно попробовать...

По Вигерсу пользовательские требования есть варианты использования системы. Ну а где же их еще прописывать, как не в разделе "Требования к структуре и функционированию системы"? Затрудняюсь найти под эти требования другой раздел ТЗ.Вы правы, не совсем, и только в ряде случаев. С другой стороны, если написать ТЗ по данной схеме, вряд ли какой Заказчик будет против  Документ получится достаточно последовательным и логичным. А что еще надо для работы?можно попробовать...

У ГОСТ 34 нет явно выраженной и выделенной в отдельную точку зрения, что что Крухтен называет в своей модели 4+1  - use case view. Поэтому пользовательские требования и не лезут никуда в ГОСТ 34.602. Можно конечно применить смекалку :-) ... но явно этого там нет. Кроме этого, мне кажется будет несколько диковато смотреться "ТЗ по ГОСТ с юзкейсами" ... хотя, "в природе встречается" - это когда очень хочется писать юзкейсы, а нужно сдавать по ГОСТ 34 :-) ....