Пытаюсь со студентами использовать EA при разработке видения системы, т.е. выстроить цепочку рассуждений и трассировки от проблем (issue) к потребностям (need) и к возможностям (feature).

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

Можно начать с потребности "Автоматизация расчета зарплаты (выплаты)" - корректно такое название или нет, какое бы вы дали?
В чем вы видите ошибочность возможностей системы (feature), которые реализуют такую потребность: "вход в систем", "доступ к старым данным", "ежедневное обновление данных для расчета"?

Спасибо !

Эдуард, добрый день!

Пока скажу об основной ошибке, которую я вижу в матрице. Need по смыслу больше похожи на Feature. А большинство Feature это скорее Use Case.

Сергей, добрый день!

Пока скажу об основной ошибке, которую я вижу в матрице. Need по смыслу больше похожи на Feature. А большинство Feature это скорее Use Case.

Был бы рад, если бы ты объяснил почему ты так думаешь. И как бы по твоему следовало бы сформулировать?

Начнём с определений:
1. "Stakeholder need - The business or operational problem (opportunity) that must be fulfilled to justify purchase or use of the system." То есть это формулировка некоторой проблемы (потребности), с которой сталкивается кто-то из заинтересованных лиц в ходе своей работы и которую он хотел бы решить (или улучшить что-то в своей деятельности, воспользоваться некоторой возможностью).
2. "Feature - an externally observable service provided by the system that directly fulfills a stakeholder need." Некий сервис системы, который может полностью или частично решить проблему заинтересованного лица и обладает собственной значимостью для ЗЛ с точки зрения бизнеса.

Need (по вертикали):
"Автоматический расчёт зарплаты" - это не бизнес-проблема, а очевидно сервис, предоставляемый системой (Feature). Теперь надо задать вопрос... Какую бизнес-потребность конкретного ЗЛ решает этот сервис? Может быть этот сервис и не нужен совсем? Формулировка Need для главного бухгалтера, которому не нравится что зарплата рассчитывается слишком долго, может выглядеть примерно так: "Снижение времени расчёта зарплаты в 2 раза". У бухгалтера, который непосредственно вручную считает зарплату, формулировка может звучать немного по другому: "Избавление от обязанности по расчёту зарплаты".

Feature (по горизонтали):
"Администрирование данных о служащих" - это не Feature, поскольку не обладает собственной значимостью и не может удовлетворить подразумевающиеся бизнес потребности (Need). А вот в качестве Use Case как раз подойдёт. Трассировка может быть как раз на Feature "Автоматический расчёт зарплаты". То есть пока не заведёшь данные о служащих, не сможешь автоматически рассчитать зарплату.

Сергей, спасибо:)

Эдуард, не за что:) Мне самому интересно чем всё это закончится. Если есть такая возможность, прошу выкладывать новые версии:)

Эдуард, не за что:) Мне самому интересно чем всё это закончится. Если есть такая возможность, прошу выкладывать новые версии:)

Я вообще-то надеялся, что студенты включаться в дискуссию.

Сергей, пока студенты собираются с мыслями, попробуем обсудить формулировки:
проблем (issue) - потребностей (need) - возможноcтей (feature)

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

Попробуем разобрать какие? Не все, а на примере какой-то определенной части?

Сергей, пока студенты собираются с мыслями, попробуем обсудить формулировки:
проблем (issue) - потребностей (need) - возможноcтей (feature)

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

Попробуем разобрать какие? Не все, а на примере какой-то определенной части?

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

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

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

Проанализировав эти источники, можно получить перечень функций (и нефункциональных требований), и их уже трассировать на источники.

Когда я смотрю на матрицу в исходном посте, я вижу и в строках, и в столбцах не возможности и потребности, а разноуровневые функции, которые трассируются друг на друга.
Чем "ведение БД о служащих" отличается от "Администрирования данных о служащих"? И что это за потребность такая - ведение БД?

Эд, а зачем так сразу переходить к трассировке проблем на возможности?

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

Затем сформулируйте цели, критерии успеха.

Потом уже можно переходить к выдвижению возможностей и трассировке.

У нас на курсах каждый 3-й участник, действующий профессионал, называет, например, в качестве проблемы «контроль посещаемости».

Тема непростая, не надо так спешить и комкать, системный метод же не просто так придуман.

Чем "ведение БД о служащих" отличается от "Администрирования данных о служащих"? И что это за потребность такая - ведение БД?

Ничем, это скажем так ошибка, неопытность.

Эд, а зачем так сразу переходить к трассировке проблем на возможности?
Тема непростая, не надо так спешить и комкать, системный метод же не просто так придуман.

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

Эд, а зачем так сразу переходить к трассировке проблем на возможности?

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

Затем сформулируйте цели, критерии успеха.

Потом уже можно переходить к выдвижению возможностей и трассировке.

Согласен с Денисом. Так было бы гораздо интереснее. Но если сузить задачу, то...

Сергей, пока студенты собираются с мыслями, попробуем обсудить формулировки:
проблем (issue) - потребностей (need) - возможноcтей (feature)

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

Попробуем разобрать какие? Не все, а на примере какой-то определенной части?

Давайте попробуем. Начнём в проблем:
1. Трудоемкость регистрации читателя
2. Повторная регистрация
3. Трудоемкость поиска изданий
4. Информация о наличии
5. Трудоемкость заказывания
6. Трудоемкость комплектования заказа

Есть несколько замечаний:
1. Основное: обычно под проблемами понимаются проблемы бизнеса в целом, а не конкретных заинтересованных лиц. "Трудоёмкость регистрации читателя"? Разве владельцу бизнеса должны быть интересны проблемы "негров"? Сотрудникам трудно регистрировать читателей? Да наплевать, если это не приводит к потере прибыли или снижению других важных показателей бизнеса. Надо задать вопрос что плохого в трудоёмкости регистрации читателей? Возможно клиенты уходят к конкурентам? Или из "министерства" грозятся уволить директора за плохие показатели? И как это отражается на достижении целей бизнеса, к чему приводит?
2. "Повторная регистрация", "Информация о наличии"... Это вообще непонятно что. Можно ли себе представить, что существует проблема "Информация о наличии"? Надо переформулировать.

Запросы заинтересованных лиц:
Обычно под этим понимаются самые первые необработанные источники:
1. Электронные письма (дословно).
2. Документы с "требованиями", как это понимает заказчик. Обычно "неструктурированный поток мыслей".
3. Протоколы совещаний.

Возможности:
В документе они больше похожи на варианты использования. Для того чтобы правильно настроиться на правильную формулировку возможностей (Features) я обычно вспоминаю маркетологов МВидео, Эльдорадо, Техносила. Они очень хорошо формулируют на уличных билбордах фичи различной электроники. Что-то типа:
1. Быстрая подготовка к работе.
2. Удобство использования.
3. Высокая производительность.
4. Развлечения и работа.

Системные требования:
Насколько я понимаю предполагается представление требований в виде вариантов использования. Есть следующие замечания:
1. Основная часть ВИ - сценарии основного и альтернативных потоков. В документе я не увидел пошаговых сценариев с описанием команд экторов и ответов системы.
2. "Проверка дублирования" и прочие подобные - это не варианты использования. Правильная формулировка предусматривает получение эктором некоторого сервиса от системы.

Сергей, большое спасибо за анализ.

Согласен с Денисом. Так было бы гораздо интереснее. Но если сузить задачу, то...

Это Ваше право Но я не готов обсуждать это в данном случае, так как цели задачи иные.

Давайте попробуем. Начнём в проблем:
Есть несколько замечаний:
1. Основное: обычно под проблемами понимаются проблемы бизнеса в целом, а не конкретных заинтересованных лиц. "Трудоёмкость регистрации читателя"? Разве владельцу бизнеса должны быть интересны проблемы "негров"? Сотрудникам трудно регистрировать читателей? Да наплевать, если это не приводит к потере прибыли или снижению других важных показателей бизнеса. Надо задать вопрос что плохого в трудоёмкости регистрации читателей? Возможно клиенты уходят к конкурентам? Или из "министерства" грозятся уволить директора за плохие показатели? И как это отражается на достижении целей бизнеса, к чему приводит?

Вполне возможно, но в данном случае мы опускаемся чуть ниже к этим самым неграм. Соглашусь, что трудоемкость - как краткая формулировка мало понятна. Избыточная трудоемкость - лучше?

2. "Повторная регистрация", "Информация о наличии"... Это вообще непонятно что. Можно ли себе представить, что существует проблема "Информация о наличии"? Надо переформулировать.

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

Запросы заинтересованных лиц:
Обычно под этим понимаются самые первые необработанные источники:
1. Электронные письма (дословно).
2. Документы с "требованиями", как это понимает заказчик. Обычно "неструктурированный поток мыслей".
3. Протоколы совещаний.

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

В документе они больше похожи на варианты использования. Для того чтобы правильно настроиться на правильную формулировку возможностей (Features) я обычно вспоминаю маркетологов МВидео, Эльдорадо, Техносила. Они очень хорошо формулируют на уличных билбордах фичи различной электроники. Что-то типа:
1. Быстрая подготовка к работе.
2. Удобство использования.
3. Высокая производительность.
4. Развлечения и работа.

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

Системные требования:
Насколько я понимаю предполагается представление требований в виде вариантов использования. Есть следующие замечания:
1. Основная часть ВИ - сценарии основного и альтернативных потоков. В документе я не увидел пошаговых сценариев с описанием команд экторов и ответов системы.
2. "Проверка дублирования" и прочие подобные - это не варианты использования. Правильная формулировка предусматривает получение эктором некоторого сервиса от системы.

Тут я следую рекомендациям моего эксперта. Это не сами прецеденты, это требования типа прецеденты, которые впоследствии будет развернуты в полноценные сценарии и диаграммы активности типа черный ящик.

Системный требования я оставил для полноты. Давайте, пока оставим их в данном случае вне поля нашего рассмотрения. Хорошо?

Вполне возможно, но в данном случае мы опускаемся чуть ниже к этим самым неграм. Соглашусь, что трудоемкость - как краткая формулировка мало понятна. Избыточная трудоемкость - лучше?

Если вы опускаетесь ближе к "неграм", то тогда это уже не Problem Statement, а Stakeholder Need. В таком случае лучше придерживаться устоявшейся терминологии и назвать эти сущности потребностями (Need). "Избыточная трудоёмкость..." более интересно звучит, но если это всё-таки потребность, то я сформулировал бы примерно так: "Снизить время, необходимое на регистрацию читателя до 5 минут".

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

Если я правильно понял из описания, то:
"Информация о наличии" -> "Необходимо иметь возможность в течение 30 секунд получать информацию о точном местонахождении невыданного экземпляра книги."

В данном случае, поскольку в рамка учебного курса невозможно смоделировать реальные запросы ЗЛ и взаимодействия с ними, то упрощается до формулировки предполагаемых потребностей, устраняющих проблему (concern - озабоченность) ЗЛ

Почему невозможно смоделировать запросы ЗЛ? У вас же есть описание задачи? Это уже запрос ЗЛ. Если разделить его на 2 документа, можно оформить их как протокол совещания, e-mail и т.п.
В предлагаемом Вами варианте предлагаю придерживаться терминологии из стандартов/методологий. Если это не запросы ЗЛ, то не надо использовать такой термин. Иначе можно запутаться.

Я согласен, что свойства к качеству должны быть заявлены, но где функциональные свойства?

"Развлечения и работа" - это функциональность.

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

Если вариантов использования мало, то можно назвать фичи аналогично вариантам использования, но тогда исчезает образовательная ценность такого упражнения. Студентам я бы показал как разделять функционал на высокоуровневые возможности. К примеру для нескольких ВИ, таких как CRUDLS, можно сформулировать фичу как "Управление такими-то сущностями". Тогда хотя бы будет понятно, что отношение фич к ВИ это не 1-к-1, а 1-ко-многим.

Тут я следую рекомендациям моего эксперта. Это не сами прецеденты, это требования типа прецеденты, которые впоследствии будет развернуты в полноценные сценарии и диаграммы активности типа черный ящик.

Зачем тогда называть вариантами использования то, что не является ими? Сами себя запутываете.

Системный требования я оставил для полноты. Давайте, пока оставим их в данном случае вне поля нашего рассмотрения. Хорошо?

ОК.

Если вы опускаетесь ближе к "неграм", то тогда это уже не Problem Statement, а Stakeholder Need. В таком случае лучше придерживаться устоявшейся терминологии и назвать эти сущности потребностями (Need). "Избыточная трудоёмкость..." более интересно звучит, но если это всё-таки потребность, то я сформулировал бы примерно так: "Снизить время, необходимое на регистрацию читателя до 5 минут".

Потребность проистекает из проблемы. Избыточная трудоемкость - это проблема, некоторый недостаток, то что хочется поменять. Не не может формулироваться как потребность в избыточной трудоемкости, но как потребность в ее устранении. Такая связь может объяснить почему возникла такая потребность.

Если я правильно понял из описания, то:
"Информация о наличии" -> "Необходимо иметь возможность в течение 30 секунд получать информацию о точном местонахождении невыданного экземпляра книги."

Если считать потребность, то такая формулировка мне нравится. Но тут нужно помнить - краткое именование потребности и ее расширенное описание.
Например "быстро узнать о наличии книги"?

Почему невозможно смоделировать запросы ЗЛ? У вас же есть описание задачи? Это уже запрос ЗЛ. Если разделить его на 2 документа, можно оформить их как протокол совещания, e-mail и т.п.

Это требует времени, у меня его нет. Исходные описания задачи далеки от предлагаемого Вами

В предлагаемом Вами варианте предлагаю придерживаться терминологии из стандартов/методологий. Если это не запросы ЗЛ, то не надо использовать такой термин. Иначе можно запутаться.

Мы этим и не пользуемся. Это пример консультанта-эксперта.

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

Не очень Вас понимаю, можете дать более развернутое разъяснение.

Студентам я бы показал как разделять функционал на высокоуровневые возможности.

Именно это я и пытаюсь дать используя концепцию feature

К примеру для нескольких ВИ, таких как CRUDLS, можно сформулировать фичу как "Управление такими-то сущностями". Тогда хотя бы будет понятно, что отношение фич к ВИ это не 1-к-1, а 1-ко-многим.

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

Зачем тогда называть вариантами использования то, что не является ими? Сами себя запутываете.
ОК.

У меня двоякое представление об этом, я с вами и согласен и нет. Это предложение эксперта, я в процессе его осмысления