Отвечу немножко не по порядку.
byur
Т.е. процесс -- первичен, стандарт по которому мы генерируем документы требований -- может быть при это любой.
На мой взгляд первична цель, которая включает требуемый результат и вид его представления. Если ГОСТ требуется заказчиком - это не подлежит обсуждению. Если не требуется, все равно составление ТЗ по ГОСТ ЦЕЛЕСООБРАЗНО, так как оно отвечает на вопросы
1. Что будет делать система
2. При каких ограничениях и допущениях.
3. Что должен обеспечить заказчик
4. Что будет делать исполнитель
5. Как это будет контроллироваться и проверяться
В RUP ТЗ соответствуют сразу несколько документов, от этого вопросы, на которые следует ответить не изменяюются.

byur
Мой вывод -- имея поставленный процесс работы с требованиями можно выдавать документы по любому из стандартов, в т.ч. и по ГОСТ.
Не спорю, можно, если это целесообразно и возможно. Однако, следует отметить, что ТЗ по ГОСТ освещает почти все вопросы, которые должны быть сняты, на определенном этапе - в этой полноте для меня его ценность.

byur
ГОСТ это стандарты, и эти стандарты никак не определяют процессов работы с требованиями. И это является как источником проблем, так и возможность "выкрутиться".
Абсолютно согласен ни одна из ГОСТовских систем (ЕСКД, ЕСПД, СПДС) не диктует процесс, а только требуемый результат, оставляя все возможности построения процесса исполнителям. И, просто, "Вы ищете там, где не прятали" (с): в ГОСТ нет процеса.

byur
Финальные требования -- это какие? Весь вопрос в целях создания требований к ПО.
Здесь у нас, похоже, нет разногласий.
byur
Любой документ в котором содержатся грамотно описанные требования к ПО (а это может и не быть ГОСТ, не так ли?) может служить источником для приемки системы.
Я бы усилил высказывание и сказал, что документ содержащий требования необходим для приемки ПО. Это с точки зрения заказчика. Для исполнителя - это руководство к действию, но любое руководство к действитю обязательно должно быть УТВЕРЖДЕНО ЗАКАЗЧИКОМ, так что, на мой взгляд, первая цель ТЗ - представление требований для заказчика, остальные цели могут выполняться и внутренними аналитическими документами, вытекающими из ТЗ (или аналогичного документа). И термин "финальные" был употреблен вместо "утверждаемые".

byur
Руководствуясь ГОСТом в качестве источника знаний по процессу работы с требованиями например, такая мысль (о возможности трассировки и проведения на ее основе анализа влияния) можно и не подозревать.
Да - это так.
Не вижу смысла искать в ГОСТ знания об управлении требований, такой цели перед ГОСТ не ставилось. И ГОСТ не заменяет RUP или XP, а только дополняет их в области общения с заказчиком и представления ЖЦ софта для заказчика.
При этом задолго до ГОСТ сложивщейся инженерной практикой были перекрестные ссылки между частями документов, частным случаем которой является трассировка. Трассировка сама по себе является (одним из многих) способом отслежиывания изменений. А кроме трассировки между частями документа могут существовать связи многих других видов. Таким образом, нет смысла их описывать в ГОСТ.

byur
ГОСТ не определяет необходимость атомарности требований, в отличие от того же IEEE 830.
В этом и заключается сила ГОСТ: вы можете поместить в ТЗ Use Case, а можете User Story, а можете и то и другое. А атомарность требований - очень относительное понятие и в большинстве случаев атомарное требование может быть разделено путем увеличения детализации. Детализация всегда будет расти по мере развития проекта. По этому, требование атомарности на момент утверждения ТЗ может уже быть нарушено на момент внесения в него изменений.

В какчестве вывода.
ГОСТ, как стандарт общения с заказчиком должен быть принят обеими сторонами, если заказчик работает по другим стандартам, применять ГОСТ нецелесообразно. Так же следует избегать заблуждения, что в ГОСТ предлагается технология управления требованиями, разработки или другая технология. ГОСТ - это описание взаимодействия между заказчиком и имсполнителем в виде описания требований к документам и в виде представления ЖЦ, которое тербуется заказчику для контроля хода проекта.
ГОСТ может быть взят, как основа для технологии, в части описания результата, но не в части описания процесса.

byur
...это может быть как ГОСТ, так и нечто другое....

Консенсус достигнут.

byur
Насчет вопросов -- неплохо бы ответить еще вопросы:
1. ПОЧЕМУ будет делаться эта система -- какую бизнес-проблему она будет решать (заранее предвижу ваш ответ, интересно угадаю я его или нет ;-))?
2. Каковы цели пользователя по отношению к системе?

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

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

чтобы было понятно: консенсус достигнут. Мы вместе считаем, что в ГОСТ процесса нет.

byur
И я, с позволения, усилю -- и этот документ НЕ ОБЯЗАТЕЛЬНО ТЗ по ГОСТ!

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

byur
Смысла там искать эти знания -- нет ... но практика показывает, что ИХ ТАМ ИЩУТ :-) ибо других отечественных источников знаний -- нет. А западные методологии не всегда "ложаться" на отечественных же аналитиков (или постановщиков задач -- кстати кто такие ПОСТАНОВЩИКИ задач? в чем состоит их работа? До сих пор не получил ни одного внятного ответа от специалистов связанных с ГОСТ)

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

byur
Вот видимо в этом и вопрос -- связи между частями документов или между АТОМАРНЫМИ требованиями? Это к вопросу документоцентричного похода и атомарности требований.

Продолжаю настаивать, что атомарность вещь относительная. Следовательно всерьез оперировать этим понятием можно только подразумевая контекст. Я думаю, более прагматичным подходом будет нечто подобное концепции сцепления: сколько частей документа-следствий будет затронуто при модификации части доукумента-причины при каскадном распространении изменений. Целесообразно минимизировать глубину и ширину дерева изменений, отсюда попытка требовать атомарность части документа.

byur
Поместить то конечно можем ... только юзкейсы, как я упомянул ранее будут отвечать на другие вопросы -- которые ТЗ не призвано задавать. И это уже и есть то самое "выкручивание из ситуации".

Use Case - это функциональное требование, выраженное сценарием ( источник ). Следовательно, место UC в разделе "функциональные требования" ТЗ по ГОСТ 34. User Story - это может быть тоже UC, но более крупный (неатомарный?) и место ему там же, а может быть и требование другого вида.

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

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

byur
Кроме этого -- довольно сложно в реальной жизни следовать диктуемой ГОСТ модели ЖЦ (практически это водопад) при этом удовлетворив потребности заказчика. Документы могут быть подписаны, хорошо сормулированы, но это может оказаться не то ЧТО НУЖНО ЗАКАЧИКУ НА МОМЕНТ сдачи системы :-).
Не соглашусь. Нигде в ГОСТ не сказано (или я не заметил), что стадии ЖЦ не могут пересекаться или делиться на этапы. В ГОСТ явно декларируются версии ТЗ и дополнения к ТЗ, как самостоятельные документы. Так что можно сделать, хоть инкрементный цикл, хоть эволюционный, надо только не лениться выпускать версии документов. Затруднения могут вызвать переутверждения целикового ТЗ, как громоздкого документа, проходящего множество инстанций. Но никто не мешает резать проект на этапы и писать отдельное ТЗ на этап. Так же можно резать на подсистемы и писать ТЗ на подсистему. Добавку пары функций можно провести дополнением к ТЗ с выпуском следующей версии ТЗ при накоплении серьезных изменений.

byurЯ угадал ваш ответ :-). На практике в документах ТЗ часто можно в качестве цели создания системы увидеть "автоматизацию деятельности" :-).

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

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

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

byurДолжен ли постановщик задач плнировать работу по созданию ПО и отвечать за результат ;-)?

Я думаю, что развитие этого направления выведет нас за рамки темы. Но мое мнение, что вышеописанные дела относятся к управлению проектами, а какие роли кто и где совмещает - это совсем другой вопрос. И даже не спрашивайте меня, как правильней...

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

Не согласен, что "высокоуровневые требования могут быть детализированы", так как высокоуровневые требования в моем представлении - это требования другого уровня абстракции, а значит, они могут быть реализованы множеством способов на нижних уровнях абстракции. Детализация связана с составом системы требований, выделение уровней абстракции, скорее ближе к ее иерархии.
Согласен, что требования могут быть и вне документа и в нескольких. Дальше осмелюсь сказать, что если расширить термин до "потенциальные части документа", будет лучше, по тому, что частью документа может быть не только требование, но и любая другая информация, которой мы хотим управлять. Для меня трассировки, версионность документов и подобные вещи лежат не в плоскости управления требованиями, а в плоскости управления инженерной документацией в целом. К требованиям относятся конкретные процедуры их выявления и анализа, которые ортогональны по отношению к процедурам управления документами. Хотя - это опять будет спор об идеальной классификации.

byur
Э нет, тут я имею желание возразить. Юзкейсы ни в коем случае не ЕСТЬ функциональные требования. Это пользовательские требования. Даже википедия (не самый авторитетный источнк на самом деле), использует термин capturing связывая юзкейсы и функциональные требования. В качестве ссылки статья Top Ten Use Case Mistakes, by Doug Rosenberg and Kendall Scott (цитата):
"The Top 10 Use Case Modeling Errors
Contrary to the principles we just discussed are a number of common errors that we have seen students make when they're doing use case modeling on their projects for the first time. Our "top 10" list follows.

10. Don't write functional requirements instead of usage scenario text. Requirements are generally stated in terms of what the system shall do, while usage scenarios describe actions that the users take and the responses that the system generates. Eventually, our use case text will be used as a run-time behavioral specification for the scenario we'll describe, and this text will sit on the left margin of a sequence diagram. We want to be able to easily see how the system (shown with objects and messages) implements the desired behavior, as described in the use case text. So, we need to clearly distinguish between usage descriptions (behavior) and system requirements. ..."

Тут мне придется возразить в свою очередь. В цитате выделен текст, определяющий UC, как спецификацию поведения. Поведение - это ЧТО и КАК делает система. Функциональное требование определяет, ЧТО делает система. Следовательно, UC - функциональное тербование "ЧТО", дополненное спецификацией "КАК", ибо нельзя указать способ действий, не сказав явно или неявно, что будет делаться. Значит, UC - уточненное функциональное тербование или, если точнее - спецификация функции.
В ГОСТ явно не написано, что при описании функции следует ее специфицировать, то есть ГОСТ разрешает не детализировать функциональные требования, но и не запрещает. Кроме этого
ГОСТ 34.602-89
...
1.4. Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.
...
...
В ТЗ на АС могут включаться приложения.

2.2. В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ.
...

Можно видеть, что "выкручиваться" не надо, по тому, что ГОСТ явно диктует пользоваться прогрессивной методикой и достаточно гибко (но обоснованно) обращаться с содержимым разделов.

byur
Есть еще ссылки на Коберна и Вигерса, которые рассуждают на эту тему в своих книгах. А вообще, это давняя дискуссия (на тему use cases vs functional reqs), которая закончиласть позиционированием юзкейсов как пользовательских требований :-).

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

byur
Интересный критерий, но не уверен что он верный. Связи (трейсы) в пределе будут ослеживаться на уровне бизнес-требования->пользователькие требования->функциональные требования. По вкусу можно доавбить бизнес-правила и атрибуты качества. Для каждого их приведенных уровней требований будут существовать собственные "атомарные требования", и их атомарность не зависит от количества трейсов и наоборот?

Не понял про связь атомарности с количеством трассировок.
Приведу пример, когда мы получаем письмо (или фиксируем User Story) от пользователя в котором три абзаца с неатомарными пользовательскими требованиями. Письмо писал эксперт пользователя и требовать от него атомарность нецелесообразно - анализ требований не его работа. Мы помещаем письмо в базу данных, а абзацы выделяются, получают тип, напрмер, "элемент запроса на изменение" и трассируются от письма. Затем аналитик садится разбирать эти абзацы, расщепляет их на кусочки, моделирует, выявляет и устраняет неточности, ведет диалог с экспертоми, наконец, помещает в БД некоторое количество "атомарных" (в Вашей терминологии) требований с теми типами, которые диктует классификация, принятая в методологии проекта. Количество типов тербований, забитых в инструмент управления требованиями может быть больше количества, принятого в методологии, из за добавления "технологических" типов, связанных со стадиями анализа и не нужными в документах. Можно хранить вообще не требования, а другую информацию, если хочется. Пример относился к сбору требований путем опроса пользователей от концепции к спецификации требований (User needs->Features->Software requironments по RUP).
Если ведется сбор требования через моделирование бизнес-процессов (пресловутая автоматизация деятельности), то трассировки будут идти от элементов процессов AS IS к элементам процессов TO BE, от них к функциональным и дополнительным требованиям точно так же, возможно, через промежуточные "технологические" типы требований.
При других принятых методах сбора требований будет своя цепочка преобразования от собираемой информации до утверждаемых требований.
В результате я хочу сказать, что не вижу необходимости накладывать условия обязательной атомарности на все требования в базе данных (к стати, не удобно управлять тряссировками от многих требований ко многим), кроме этого могу привести примеры, когда неатомарность требований, попадающих в базу данных невозможно обойти.
И продолжаю настаивать, что целесообразная необходимость минимизации сцепления требований в финальных (утверждаемых) документах вызвана стремлением к уменьшению объема изменений (в количестве абзацев) в утверждаемом документе при изменениях на входе в процесс сбора требований.


byur
...утверждение о пересечении этапов -- довольно вольная трактовка положений ГОСТ.
Смотрим ГОСТ
ГОСТ ГОСТ 34.601-90
1.1. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.

Работа - минимальная учитываемая единица. Стадии и этапы - это множества работ.
ГОСТ ГОСТ 34.601-90
1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

Достаточно туманная фраза, но она не запрещает стадиям и этапам пересекаться.
ГОСТ ГОСТ 34.601-90
2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

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

ГОСТ ГОСТ 34.601-90
2.2. Стадии этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.

Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.

Явное указание, что этапы следующих стадий могут начинаться до завершения предшествующих стадий (а значит, и этапов этих стадий). Явное указание на возможность параллельного запуска нескольких этапов. Явное указание на добавление видов работ и этапов, не предусмотренных в ГОСТ. Наложенные ограничения в виде выделенных слов указывают, что более поздние (по таблице) стадии обязаны закончиться позже, чем более ранние. То есть, например, ВЕСЬ сбор требований надо закончить раньше, ВСЮ разработку, а всю разработку раньше, чем все сопровождение, что очень трудно было бы нарушить при любой технологии разработки.
Добавлю, что так же не запрещено, а даже поощряется разбиение на подсистемы и запуск тех же стадий от формирования требований до сопровождения на каждую подсистему отдельно.

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

basА это уже совсем другой документ ...
Не понял этот тезис...

basНа самом деле, не понятна цель вашего спора?
Для меня - это не спор, а диалог, в котором уточняются и укрепляются одни позиции, а другие пересматриваются.
Нигде не написано в моих постах, что ГОСТ = ЛУЧШИЙ стандарт в определенной области. В системных проблемах ОПТИМУМ недостижим по объективным причинам, и его заменяют целесообразностью.

bas- Нет методологии сбора и управления требований
Не считаю это минусом - это причина, по которой ГОСТ может пережить многие стандарты. Никто не мешает дополнить ГОСТ любой понравившейся методологией, при этом ГОСТ не изменится, а из методологии придется выкинуть лишнее.

bas- Вольная трактовка пунктов ТЗ => возможно написать полное дерьмо
Ни один стандарт не определен на формальном уровне. Даже IDEF0 позволяет
трактовку. Выше были приведены цитаты из ГОСТ, которые явно требуют доопределить его на уровне ОСТ и СТП. А полное дерьмо можно написать даже на языке программирования, который гораздо более формально описан.

bas- Довольно старый => не соответсвует новым/изменившимся тенденциям
Выше я как раз и стремился показать, что в ГОСТ пока что ложатся любые современные тенденции, что только добавляет ему ценности.
Если вы намерены отстаивать это свое утверждение, приведите технологии, методики и тенденции, которые не ложатся в ГОСТ. Кроме тенденции мигом свавять модные яйца в профиль и освоить дикий бюджет на выкорчевывании старого и внедрении нового.

mcureenab
ТЗ на этот вопрос не даёт ответа. Для этого служит тактико-техническое задание, где в частности отражается эффект (экономический, социальный и т.д.) ожидаемый от системы. Хорошее ТЗ в технических терминах определяет АС, которая должна удовлетворить (экономические, социальные и т.д.) ожидания пользователей. Как определить, что именно такая система принесёт ожидаемый эффект в ГОСТ 34 к сожалению не написано, это вопрос методологии.

Согласен, не дает и не должно.
Добавлю, что подсчет эффекта - танцы с бубном сравнимые с выявлением требований, а то и похлеще. Не каждый заказчик готов платить за предельно четкое обоснование стратегических решений (своих или предложенных консультантами). А если он оплатит обоснование, то он получает десять вариантов, оцененных по десяти параметрам и ему говорят, что оптимум будет зависеть от выбора оптимизирующей функции, подходов к выбору которой еще 20. И ему остается бросать гадальные кости, чтобы выбрать вариант. По этому, зачастую, принимается решение автоматизировать деятельность и формулируются дополнительные цели и ограничения.
Хочу отметить, что мы живем в мире неидеальных вещей. И цель "автоматизация деятельности" еще не значит, что проект уже провальный, просто, аналитикам придется поднапрячься, чтобы доопределить постановку.

byurОтвет в самом ГОСТ 34.602:
"2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других пока-зателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы "

Вот Вы сами и ответили на вопрос постом раньше. Можно видеть, что "автоматизация деятельности" как единственная цель без указания критериев достижения (если Вы именно это часто наблюдаете) противоречит требованиям ГОСТ. Выше я указывал, что выявление показателей - часто работа аналитиков. На этом считаю, что консенсус достигнут. Если вас смущает именно термин "значения", то можно формулировать и качественные критерии, оценивая их по введенным шкалам: зачет-незачет или от 2 до 5 или и т.д., и требовать зачетного поведения или какого-то другого. Так можно загнать любые цели в формализованные рамки.

byur
не в качестве спора а комментария для, скажу -- что если пользовательское требование в ТЗ по ГОСТ некуда впихнуть, а юзкейс например сам по себе (на этом уровне) атомарен -- то значит классификация ГОСТ неполная?

Спорить прекращаем, отмечу, только, что НЕДЕЛИМЫМ юзкейс быть не может.
Любой абзац раскладывается на множество истинных высказываний в различных формах. Из этого набора можно формировать разные эквивалентные множества абзацев по правилам логики. Способ формирования абзаца (требования к содержимому) и будет типом требования. По этому любые требования из одной полной классификации можно переформулиовать в требования в другой полной классификации. Любая классификация требований не формальна, а только формализована, по этому границы и критерии полноты являются нечеткими.

byur
Сорри, что значит "они могут быть реализованы множеством способов на нижних уровнях абстракции"? Мы говорим о детализации требований или уже о дизайне -- как реализации требований?

На мой взгляд - детализация - это операция над составом, когда элкмент системы превращается в компонент. Нельзя сказать, что User Need состоит из нескольких Feature. Можно сказать, что
Feature следует из User Need или User Need реализован с помощью Feature - это или отношение иерархии или связь структуры другого типа.
А множеством способов, то и значит, что пока сформулирован только User Need, мы можем предложить несколько наборов Feature. Чтобы выбрать один набор, задачу следует доопределить (собрать еще требований).

byur
Интересно, но мне показалось что это несколько противоречит постулатам программной инженерии, изложенным в SWEBOK, и в частности области знаний Пограммные требования (http://www.almportal.ru/public/so/book/3-1-software_engineering_requirements.pdf). И второй момент -- IMHO управлять требованиями проще и эффективнее, чем документами.

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

byur
Я позволю себе тоже возразить на возражение :-). Все-таки юзкейсы отображают ВЗАИМОДЕЙСТВИЕ пользователя и системы, а не только действия системы -- в частности, система делает <что-то> в ответ на действие пользователя. Второй момент -- поведение можно описать и в терминах только "ЧТО" (что делает система в ответ на действия пользователя), и не обязательно говорить про то КАК или КАКИМ образом она это делает -- на этот вопрос отвечает ДИЗАЙН. Третий момент -- юзкейсы ЭТО НЕ ЕСТЬ ФУНКЦИИ СИСТЕМЫ! В частности можно об этом посмотреть тут http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/WhyUseCasesAreNotFunctionsDec00.pdf (уважаемый bas не даст соврать :-))

Согласен, что UC явно требует большей детализации, чем функциональное требование по ГОСТ, но он не может уйти от функции, так как описывает поведение. Возвращаясь к вопросу, куда класть UC в ТЗ по ГОСТ, продолжаю настаивать, что в функциональные требования. Спецификации UC можно вынести в приложение, если это удобно.
Чтобы больше не путаться со ЧТО и КАК, предлагаю посмотреть с такой стороны: ЧТО - это инвариант (цель), условия, предпочтения и ограничения; КАК - это структура системы (средства), которая удовлетворяет ЧТО. Естественно, на каждом этапе каждый элемент КАК порождает новое ЧТО (в этом задача аналитика, а потом и разработчика) и дальше по новому кругу. Вы видите функцию в виде описания цели, а UC в виде описания средств достижения цели, но они подразумевают присутствие цели. Естественно, функции и UC - это не одно и то же, но они покрывают (в сумме логически эквивалентны) одно и то же множество более мелких фактов, отвечающих за поведение системы.

byur
Интерпретировать ГОСТ тут можно однозначно -- мы не должны говорить в требованиях, что например бакап БД нужно производить на дискеты, т.к. современный уровень технологий позволяет для этого использовать более емкие и быстрые носители по доступной цене. И в частности потому, что так сделано в системе NNN, которая широко известна.
И далее, что требования не должны (если это не является явным ограничением) диктовать метод решения -- например использовать метод Хука-Дживса или Генетический алгоритм для решения задачи линейного программирования.

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

byur
ОК, не будем хоронить (long live rock'n'roll ! :-)). Осмелюсь предположить что в данном случае под пользовательскими требованиями вы понимаете "требования которые высказал в том или ином виде заказчик/пользователь"? Я в данном случае использую терминологию К.Вигерса -- пользовательские требования -- это требования определяющие цели пользователя по отношению к системе, например -- оператору комплексной станции ПВО нужно иметь возможность идентифицировать класс "скоросной низколетящей цели" -- это его задача (цель пользователя по отношению к системе) -- для этого радар(ы) должны иметь определенные возможности, как то генерировать импульсы в определенных частотных диапазонах с определенными волновыми характеристиками. Оптико-локационные станции должны при этом тоже иметь определенные возможности -- как то сопровождение цели в течении определенного времени на определенной дистанции и т.п. (характеристики ОЛС). Это (возможности и характеристики радара и ОЛС) есть функциональные требования к комплексу, а пользовательское требование -- ни что иное как "идентифицировать класс "скоросной низколетящей цели"" -- в этом ему помагают конкретные дивайсы.

Договорились. Технологии и методологии приходят и уходят. Пока достаточно устойчиво работает только системный анализ и некоторые разделы математики. Вигерс достоен уважения, но в реальном проекте все зависит от... Мне ближе мнение, что для каждого типа своих проектов уместно создавать собственную классификацию требований на основе известных классификаций или на другой основе, даже если станет ясно, что следует позаимствовать готовую, считаю целесообразным такой анализ не пропускать.

byur
Вообще, возможно следует использовать другой термин вместо "атомарные" -- все-таки "атомарный" ассоциируется с "неделимый". Возможно стоит говорить о ДИСКРТЕТНОСТИ требований и их однозначной идентификации. И о том, что в одном требовании должно содержаться одно утверждение. Я надеюсь это внесет больше ясности. Будем говорить о ДИСКРЕТНОМ требовании -- тогда, дискретное требование может существовать и без трассировок, в то же время, трассировка не существует без дискретного требования.

Не вижу, как требование (например) уровня UC может висеть в воздухе (без трассировки) не вытекая из Feature или Change Request. Одно требование - одно утверждение - это хорошо, но что, если три утверждения можно переформулировать в пять других? Еще раз подчеркиваю, что нет критерия, однозначно указывающего расщеплять требование или нет - вовремя остановиться - задача человека не всегда есть четкие критерии.

byur
В пределе "минимизации сцепления требований" приведет к тому, что требования в ТЗ будут очень неконкретными и высокоуровневыми -- ведь именно так можно достичь нулевого количества трейсов? IMHO Не хватает ограничений на условие минимизации ... как бы вы их сформулировали? Думаю что размышления на эту тему приведут к классическим схемам трассировки (BR->UR->FR) :-)

Не надо путать, неконкретные и высокоуровневые и помещение нескольких высказываний в один учитываемый абзац.
Допустим, из двух Feature (назовем их А1 и А2), вытекает функция Б, она содержит подфункции Б1, Б2, Б3, каждая подфункция трассируется в два класса Б1 в К11 и К12, Б2 в К21 и К22, Б3 в К31 и К32. Есть два варианта: в первом записать функцию Б в требования, во втором вместо Б записать Б1, Б2, Б3.
По трассировкам в первом случае 2+3*2=8, во втором 2*3+3*2=12.
Пришел запрос на изменение, которое коснется А1, Б в части Б1 и К11.
В первом случае потревожим А1, получим 1 подозрительную связь, потревожим Б, получим 6 подозрительных связей, потревожим К11. Итого 3 абзаца изменились, просмотрено 7 связей.
Во втором случае потревожим А1, получим 3 подозрительных связи, потревожим Б1, поолучим 2 подозрительных связи, потревожим К11. Итого 3 абзаца изменились, просмотрено 5 связей.
Можно видеть, что иногда расщепление требований уменьшает работу при внесении изменений. Я думаю, есть и другие причины и критери расщепления, но сцепление - это то, что можно пощупать и рассчитать его численные параметры.

byur
IMHO это интерпретация (т.е. толкование или все та же "выкручивание из ситуации"). Более логичен на тему ЖЦ ГОСТ Р 12207 (он же ISO 12207).
Я вижу ГОСТ, как набор равноправных утверждений, накладывающих ограничения на разработку. В тексте не встречается явное указание предпочтительности водопада перед инкрементом или эволюцией. Как можно видеть, интерпретация происходит всегда и у всех по разному, но нет доказательств, что чья-то правильней. То есть водопадная интерпретация ГОСТа диктуется информацией вне ГОСТа: мифами маркетологов, и стереотипами специалистов старой закалки.

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

Как правило UC не достаточно для спецификации системы. Для выявления требований приходится рассматривать не только поведенчиские, но и структурные аспекты задачи, например строить модели данных, описывать ограничения (constraint) операций выполняемых в рамках UC, затем трассировать их в требования ТЗ.
Формулировка тредования может быть краткой и ссылаться на подробную спецификацию в другом документе, где в удобной форме раскрывается содержание операции, или другого элемента системы, который требуется реализовать.

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

mcureenab
UC требованием быть не может. UC это модель поведения системы, требование, это соглашение исполнителя и заказчика о том, что система должна в определённой мере соответствовать этой модели.

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

mcureenab
Как я уже говорил, анализ UC порождает множество разнообразных требований часть которых включается в ТЗ на версию системы. Например, мы можем смоделировать самый идеальный UC, но в силу проектных ограничений реализовать только часть требований связанных с ним.

Как я уже говаорил выше, одно и то же множество истинных утверждений о системе может быть объединено в разные подмножества. Способ объединения и будет соответствовать типам требований по разным классификациям.
А если мы не можем реализовать смоделированный UC, не стоит ли его измернить?

mcureenab
Т.е. есть модель системы, она помогает выявлять и формулировать требования, есть ТЗ с требованиями, которые должны быть реализованы на данном этапе ЖЦ системы (ведь речь может идти не только о создании новой системы с нуля, но и о создании новой версии существующей системы, а в этом случае ТЗ включает только новые требования которые мы хотим реализовать), есть сама система, которая должна отвечать реализованным требованиям. В такой классификации UC относится к модели системы.
Абсолютно верно подмечено, что "в такой классификации". На мой взгляд - классификация не догма, а метод работы, принятый здесь и сейчас.
Кроме этого, никто не отрицает многоэтапный анализ требований, в акотором крутятся те же сущности, что и в финальном утверждаемом наборе требований.
Если вернуться к вопросу, с которого все началось: "куда в ТЗ класть UC", то пока никто не против, что перечислить их можно в функциональных требованиях. Если религия запрещает туда же положить и спецификации UC, то выносим их в приложение или добавляем раздел. На этом спор UC vs Functionsl Requironment считаю зашедшим в тупик. Так как, большинство утверждений за придание UC статуса священного артефакта, требующего специального обращения, приходят к установлению лучшей из классификаций, что для меня неприемлемо.