4. Если же мы все таки говорим о + и - ДВИ, то давайте о них и говорить. Или мы говорим о ВИ и ДВИ?!

Плюсы и минусы в сравнении с чем? Моё предложение — контекстная диаграмма (для выявления Агентов), проход по бизнес-сценарию Агента и список (для выявления Задач).

2. Как правильно сказал Сергей, многие западные коллеги используют ВИ именно как технику выявления Требований

Не понял, откуда ты взял про западных коллег.

Не понял, откуда ты взял про западных коллег.

Сибирь - это к востоку от Москвы.

Не понял, откуда ты взял про западных коллег.

Погугли requirement elicitation techniques

Плюсы и минусы в сравнении с чем? Моё предложение — контекстная диаграмма (для выявления Агентов), проход по бизнес-сценарию Агента и список (для выявления Задач).

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

От погугли слышу %)

Саша, ещё раз — где СЕРГЕЙ сказал про ЗАПАДНЫХ коллег?

Денис,

Ля ля ля .... надо читать так:
Правильно сказал Сергей, например, многие западные коллеги используют ВИ именно как технику выявления Требований

Денис,

Ля ля ля .... надо читать так:
Правильно сказал Сергей, например, многие западные коллеги используют ВИ именно как технику выявления Требований

С таким отношением к языку и логике высказываний мы далеко не уедем

Денис,

Спасибо за уточнение 

Кто не понял, что я написал? Задайте конкретные вопросы.
В качестве примера - ЛЮБАЯ ГРАМОТНО составленная ДИ.

Денис ты написал все очень корректно. Но на мой взгляд ты говоришь примерно так: Очем тут разговор - ДИ полезна - это аксиома, доказательства не требует. Тем неменее ты приводишь, где будет полезна ДИ. Это хорошо. Но хотелось бы наглядных примеров в пользу твоей точки зрения.

ДВИ полезны для выявления назначения системы в диалоге с Заказчиком/Пользователем.
Как понятно из его рассказа, это целиком и полностью зависит от умения аналитика вести эту работу в качестве Коммуникатора.
Рисует он там овальнички или прямоугольнички — Заказчику всё равно. Рисует он там мужиков с яйцами или мордочки-смайлики — всё равно.
Аналогичным образом я могу составить рассказ о том, как в взаимодействии с Заказчиком получить на доске Список ролей (например, с помощью Контекстной диаграммы), а потом пройдясь по каждой роли, получить Список задач, которые будут решать эти роли с помощью системы (Проходом по сценарию деятельности этой Роли вообще, в бизнесе, а не в системе).

Вот точка зрения Дениса. Полезна не сама ДИ, а процесс получения некой диаграммы в ходе взаимодействия З/П. При этом неважно будет ли это ДИ, или нечто иное.

UML дает нам в качестве КОНТЕКСТНОЙ именно ДИ и будет полезна

ЛЮБАЯ ГРАМОТНО составленная ДИ.

Что значает тогда грамотная?

многочисленные примеры в форуме показывают, что ДИ рисуется в отрыве от З/П, и когда последний получает готовый результат, он не понимает её пользу.

Принимаем ли мы факт, что ДИ полезна только ходе взаимодействия З/П? А сама по себе даже с комментариями лишняя?

Добавлю, что наверное ДИ полезна в рамках UML инструмента, как содержание и средство навигации. Согласны ли вы с этим?

+ ДВИ:
* Охватить одним взглядом функционал Системы, Пользовательские Требования
* Хорош при выявлении Требований
* Служит каркасом для дальнейшей детализации Требований и Архитектуры
* Служит для формирования первоначального набора Тестов, Ролей и Пользовательской Документации

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

- ДВИ:
* Сложность выявления ВИ и рисования ДВИ
* Сложность понимания
* Не применимость для ряда задач - Интеграционные решения, Один Пользователь и т.д.
* Много взглядов (вариантов) на одну и ту же ДВИ

* нет ли противоречия этого пункта с * Хорош при выявлении Требований
* а разве наглядность диаграммы не служит для облегчения понимания? Если диаграмма сложна для понимания зачем она вообще нужна?
* чем плохо множество взглядов. Может как раз эта позиция и сильна. Диаграммы IDEF0, DFD строго определяют одну и только одну точку зрения, так может множественность токи зрения как раз хороша, поскольку снимает ограничение

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

* П.ч. нельзя\сложно показать иерархию ролей, участие одной роли в нескольких задачах, и ВИ, как мы помним, - это цель Пользователя и не совсем задача или функция Системы.
* Тебе сценарий написал Сергей
* Например, мы формируем сценарий из 5-9 шагов, а потом каждый Системный шаг детализируем уже с помощью ФТ
* Да можно, все можно. Можно сюда заместо одной идеологии ВИ вкрутить и Таблицы и Списки и Ментальные Карты и Контекстные Диаграммы и CRC и т.д. просто ВИ - это комплексный продуманный подход по выявлению, анализу и документированию ПТ.

* нет ли противоречия этого пункта с * Хорош при выявлении Требований
* а разве наглядность диаграммы не служит для облегчения понимания? Если диаграмма сложна для понимания зачем она вообще нужна?
* чем плохо множество взглядов. Может как раз эта позиция и сильна. Диаграммы IDEF0, DFD строго определяют одну и только одну точку зрения, так может множественность токи зрения как раз хороша, поскольку снимает ограничение

* Выделение ВИ и выявление Требований немного разные вещи
* Если нормально нарисовать и объяснить, то сложностей мало, если этого не делать, то ДВИ бесполезна
* Если грамотно использовать, то это +, если нет, то это -

* П.ч. нельзя\сложно показать иерархию ролей, участие одной роли в нескольких задачах, и ВИ, как мы помним, - это цель Пользователя и не совсем задача или функция Системы.

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

* Тебе сценарий написал Сергей

Написал, однако участие ДВИ здесь может быть минимальным.

* Например, мы формируем сценарий из 5-9 шагов, а потом каждый Системный шаг детализируем уже с помощью ФТ

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

* Да можно, все можно. Можно сюда заместо одной идеологии ВИ вкрутить и Таблицы и Списки и Ментальные Карты и Контекстные Диаграммы и CRC и т.д. просто ВИ - это комплексный продуманный подход по выявлению, анализу и документированию ПТ.

смотри выше. ВИ может и подход, но причем тут диаграмма?

* Выделение ВИ и выявление Требований немного разные вещи

ВИ - это функциональные ТРЕБОВАНИЯ. Нельзя говорить противопоставлять одно другому. Форма записи не означает различия смысла!

* Если нормально нарисовать и объяснить, то сложностей мало, если этого не делать, то ДВИ бесполезна

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

Диаграмма вариантов использования может быть полезна в рамках организации процесса разработки специалистам компании разработчика, как часть их прфессиональных знаний в:
1. принятии проектных решений
2. в ходе разработке тестов
3. в ходе разработки пользовательской документации
4. как средство навигации по моделям проекта при использовании соотвествующих инструментов

* Если грамотно использовать, то это +, если нет, то это -

Что такое грамотно использовать. Приведи примеры грамотного использования.

Я хочу высказаться в пользу ДВИ в противоречии со занятой в данной теме позиции.

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

С чем бы он столкнулся:
1. повторением одних и тех же ВИ у разных ролей пользователей
2. сложно было бы передать обобщение одиних пользователей другими. Вернее не так сложно, как мало наглядно
3. скорее всего мы бы все равно заставили его что-то нам нарисовать.
4. скорее всего мы бы хуже поняли ход мысли студентам в тексте, чем в диаграмме

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

Далее может вы заметили, что между диаграммами DFD и диаграммами ВИ есть определенное сходство:
1. там и там есть понятие внешней сущности
2. там и там есть сущность, инициирующая процесс, и сущность вспомогательная - поставщик данных
3. в DFD нельзя изобразить обощение одних внешних сущностей через другие, на ДВИ можно
4. как на ДВИ, так и на диаграмме DFD не следует изображать внешние сущности, не взаимодействующие непосредственно с системой
5. контекстная диаграмма DFD почти тоже что и диаграмма ДВИ, если разрешить изображать на DFD внутренние процессы или подсистемы
6. Обе диаграммы ориентированы на отображение взаимодействия внешних сущностей с системой
7. ДВИ специфицируется через описания ВИ, DFD через миниспецификации процессов. Хотя в последнем случае упор на функциональное деление.

Кстати Скотт Амблер в книге Гибкое моделирование тоже об этом говорит. Однако мне кажется, ДВИ выразительнее диаграммы DFD.

Какие трудности я вижу при создании ДВИ, что потом влечет за собой и трудности в описании ВИ.
1. Понятие цели пользователя - что же считать целью пользователя, можно ли использовать текстовый шаблон, какой он будет, какие критерии позволяют сказать - это цель, а вот это не цель. Что же понимают англичание под словом цель: purpose, aim, objective, target, goal, intent, intention...
возможные ответы:
  - то, что может считаться элементарным бизнес-процессом, определенной обязанностью сотрудника
  - то, что одобряется руководством как исполнения полезной работы
  - нечто краткое, сеансовое, законченное - транзакция
2. Наименование варианта использования - с какой стороны стоять при именовании ВИ (это к тому регистрация покупки или регистрация продажи). Если имя ВИ - цель, должное ли оно отржать SMARTER конфигурацию, обязательно выраждаться в ответ ДА-НЕТ.
3. структурирование диаграммы -не понимание связей обобщение, зависимостей include и extend. Не следует ли на этапе анализа заменить их, следуя, Розенбергу на invoke и precede. Первое как либо include или extend (конкретная реализации смысла будет потом на стадии проектирования), а второе без аналогов, просто демонстрирует некое предшествование, то что должно быть выполнено в начале, но имеет и самостоятельно значение? А то и вовсе запретить структурирование ВИ, разрешив только структурирование акторов, как наиболее понятное и очевидное?
4. выделение акторов

Между DFD и ДИ есть серьезное различие - на ДИ нет времени (ни в каком виде) и потоков данных, нет алгоритмов и, как следствие, меньше шансов сделать ошибку!

Эд,

Под идеологии ВИ я имел в виду - выделение Актеров, понятие ВИ как цели, спецификацию ВИ и ДВИ. ИМХО из идеологии что-то выдергивать можно, но это мало эффективно. Если мы правильно выделили ВИ и написали их спецификации, то почему бы нам не нарисовать ДВИ, чтобы было еще понятнее?!

Под выделением ВИ я имел в виду, что мы правильно определили ВИ как цели, а не просто как Системные Требования.

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

ДВИ полезна и при дальнейшей работы с требованиями, если все участники понимают ее смысл, т.е. она должна быть объяснена ЗЛ.

6. Обе диаграммы ориентированы на отображение взаимодействия внешних сущностей с системой

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

7. ДВИ специфицируется через описания ВИ, DFD через миниспецификации процессов. Хотя в последнем случае упор на функциональное деление.

ИМХО содержание ВИ, указанных на ДВИ,  можно детализировать диаграммами деятельности. Особенно на этапе анализа, выявления логики бизнеса Заказчика, безотносительно к возможным программно-аппаратным решениям по его автоматизации. Можно конечно привлекать и диаграммы последовательности, состояний но они сразу тянут за собой диаграмму классов, а это ИМХО  затрагивает компетенцию архитектора и эти диаграммы хорошо бы рисовать минимум вдвоем - бизнес-аналитик и архитектор.

Какие трудности я вижу при создании ДВИ, что потом влечет за собой и трудности в описании ВИ.
1. Понятие цели пользователя - что же считать целью пользователя, можно ли использовать текстовый шаблон, какой он будет, какие критерии позволяют сказать - это цель, а вот это не цель. Что же понимают англичание под словом цель: purpose, aim, objective, target, goal, intent, intention...
возможные ответы:
  - то, что может считаться элементарным бизнес-процессом, определенной обязанностью сотрудника
  - то, что одобряется руководством как исполнения полезной работы
  - нечто краткое, сеансовое, законченное - транзакция

2. Наименование варианта использования - с какой стороны стоять при именовании ВИ (это к тому регистрация покупки или регистрация продажи). Если имя ВИ - цель, должное ли оно отржать SMARTER конфигурацию, обязательно выраждаться в ответ ДА-НЕТ.

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

3. структурирование диаграммы -не понимание связей обобщение, зависимостей include и extend. Не следует ли на этапе анализа заменить их, следуя, Розенбергу на invoke и precede. Первое как либо include или extend (конкретная реализации смысла будет потом на стадии проектирования), а второе без аналогов, просто демонстрирует некое предшествование, то что должно быть выполнено в начале, но имеет и самостоятельно значение? А то и вовсе запретить структурирование ВИ, разрешив только структурирование акторов, как наиболее понятное и очевидное?
4. выделение акторов

ИМХО некорректно пытаться отразить на ДВИ последовательность осуществления ВИ, что неизбежно возникает при попытке отразить на ДВИ отношения invoke и precede. Как отразить условия осуществления, ветвления последовательности осуществления ВИ при выполнении invoke и precede?  Не лучше ли тогда просто нарисовать диаграмму(ы) деятельности?