mcureenabКормить семью, достать денег, это пакеты требований. Требования - учиться, работать, покупать еду, то есть именно этим и будет заниматься система, для того чтобы кормить семью. Очевидно, что мы забыли про покупку посуды и дров для приготовления пищи, таким образом наша система не сможет накормить семью (разве что сырым мясом), но это не наша проблема, а проблема заказчика, если он подписал такое ТЗ. Возможно заказчик сыроед.

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

Дальнейшая декомпозиция требований может происходить на стадии технического проектирования, п. 5.3 Разработка ТЗ на разработку изделий для комплектования АС. Но это уже будут требования исполнителя к подрядчикам в рамках проектного решения принятого исполнителем.
Ну хорошо, Вы объяснили, на каких этапах какие требования будут появляться и что дальше? Консенсус достигнут?

mcureenab Boatman
ПРИМЕР
....
ЧТО1: Кормить семь.
-Достать денег (см ЧТО2)
-Купить еду (см ЧТО3)

ЧТО2: Достать денег
-Учиться (см ЧТО21)
-Работать (см ЧТО22)
...



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

mcureenab BoatmanНу хорошо, Вы объяснили, на каких этапах какие требования будут появляться и что дальше? Консенсус достигнут?

Вроде достигнут.
В раздел назначение системы выносим названия UC, в требования содержание UC.

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

mcureenab
Сценарий это последовательность действий. Если мы её раздербаним по разделам ТЗ будет проблематично восстаносить её обратно.

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

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

byur
Не уверен, что данное высказывание корректно, особенно если опираться на понятийный механизм системного анализа (и в частности на определение модели). Т.к. ТЗ это собственно не модель, это описание требований -- т.е формулировка того, что из себя должна предствалять модель системы. Более реально можно назвать моделью уже ДИЗАЙН (и архитектуру) системы -- т.е. фактически описание того как устроена система. Тут можно говорить и о детализации такой модели.
А что это, если не модель?
"Моде́ль — описание объекта (предмета, процесса или явления) на каком-либо формализованном языке, составленное с целью изучения его свойств. Такое описание особенно полезно в случаях, когда исследование самого объекта затруднено или физически невозможно." - это одно из определений. ТЗ описывает разрабатываемую систему или нет?
И кроме детализации есть еще плоскость взгляда. У любой системы может быть множество моделей разной детализации с роазных точек зрения.

byur
Еще раз хотельсь бы подчеркнуть, что UC не есть функция, это суть разные вещи. Я не зря приводил ссылки на соответствующие статьи. И кстати функциями чего являются юзкейсы - функциями системы или функциями пользователя системы ???

Никто не утверждает, что UC=функция. речь идет о связи. А связь такая (к вопросу, чья функция): UC - функция человеко-машинной (или машино-машинной) системы, то есть, что человек совместно с этой системой может выполнить. Как следствие UC с достаточной уверенностью можно назвать функцией надсистемы по отношению к разрабатываемой.

byur mcureenab BoatmanНу хорошо, Вы объяснили, на каких этапах какие требования будут появляться и что дальше? Консенсус достигнут?

Вроде достигнут.
В раздел назначение системы выносим названия UC, в требования содержание UC.


И что получаем -- ровным счетом только плевки в сторону техники юзкейсов и устойчивое мнение, что юзкейсы -- полная ерунда :-). И вот почему: в качестве требования к системе имеем фразу шага юзкейса "пользователь подтверждает идентичность паспортных данных в документе и в Профиле Клиента". Это требование к системе????
Не вижу в данном конкретном выделенном Вами тексте плевки. "Юзкейсы - ерунда" в этой ветке Вы сказали первым. Я, не могу в этом с Вами согласиться.
В ответ на вопрос, требование или нет. требование может звучать так: система должна поддерживать следующие варианты использования ....
Но это одно и то же, что и смущающая Вас "автоматизация деятельности". Так как UC - та же самая совместная деятельность актера и системы. И еще раз: функция будет атомарным кирпичиком из которого строится UC, если только не требуется жесткий надзор системы над соблюдением сценария, тогда соблюдение прописанного UC само будет функциональным требованием.

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

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

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

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

byur
Кстати, часто именно так и делают -- по сценарию юзкейса делают визард. А насчет "только что пришедшей в голову идеи" :-) ... так это общепринята практика от UC к тест-кейсам и пользовательской документации :-). Кстати, в этом одно из преимуществ use-case driven разработки -- максимальное использование уже наработанного.

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