Если не приживется убьем!

Для начала хочу задать несколько вопросов по организации группировок требований и связей.

Итак, ЕА позволяет нам группировать требования разным способом:
1. Пакеты - пакеты классические элементы группировки и ограничения поля внимания.

Вопрос такое: в каком случае целесообразно использовать именно пакеты? Или, что лучше выбрать за элемент классификации. Пакеты это иерархическая, строгая, но не гибкая классификация.

2. Вложенность - т.е. требование можно вложить в другое требование. В ЕА это связь владения, она никак графически не отображается, но проявляется в виде иерархии.

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

3. Агрегация - одно требование агрегирует другие. Что есть агрегация понятно, но в чем отличие в данном контексте от владения? То что владение задает жесткую иерархию, а агрегация позволяет показатьсвязи требований из разных иерархий? Но будет ли это верно?

4. Группировка по типу требований - это сквозная группировка и тут, кажется, все понятно.

5. Зависимости - наверное просто показывает влияние одних от других и к группировке не относится.

6. Группировка по тегированным значениям - позволяет группировать требования по различным условиям (дата, проект, что-то еще)

7. Еще можно выделить ассоциации - можно ли считать это тоже своего рода группировками? Когда работают ассоциации?

8. Могут ли требования находится в отношении реализации? И может ли это являться также группировкой?

А что никто не ответит? Глупость сморозил, удалить? Эй модераторы!!!

А что никто не ответит? Глупость сморозил, удалить? Эй модераторы!!!

Я тебе один умный вещь скажу, только ты не обижайся.

Ты сам - модератор!

Эд, тебе для развития или для работы?
Если для работы, то может стоит сначала задать вопрос "а для чего все это нужно"?
Скажу по себе
1. Пакеты использую для группировки по предметным областям или типам. В зависимости от ситуации
2. Вложенность использую для упорядочения в дереве, чтобы не было большого списка (считай иерархия)
3. Связь реализации появляется при привязывании требований к вариантам использования через свойства последних
4. Все возможные выборки и по типам и по другим признакам настраиваются во View в виде фильтров. Их удобно использовать для различных группировок и управления требованиями

Может кто-то дополнит. Вообще каждый для себя сам определяет как уобней, чтобы не делать лишней работы и экономить время и силы. Как говорит Саша Юняев (ака bustor)

я придерживаюсь принципа KISS

Я тебе один умный вещь скажу, только ты не обижайся.
Ты сам - модератор!

Вай дарагой, а не модератор, понимаешь, я это администрация:) А модераторы тут bas, да Irr:)

Эд, тебе для развития или для работы?

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

И для работы - говорил же, у нас приняли предварительно решение использовать ЕА в качестве инструмента фиксации требований. Не уверен, что именно им все будем управлять, о есть такая к этому тенденция. ПМ активно формирует модель - нашей системы (нашего видения задачи) и модель нашего очччень важного клиента. Продвинулся далеко. Меня приглашал для рецензирования. Именно я высказал ему мысль, что использования пакетов для группировки целесообразней вложения одних требований в другие. ПМ досадовал, что при переносе иерархически связанных требований на диаграмму не появляются связи агрегации. Я высказал идею, что и не должно, т.к. все-таки агрегация не подразумевает обязательной иерархии, а иерархии агрегацию. Хотя тут вопрос спорный, типично иметь has-a Иерархию и is-a ирерахию. Но имеет ли место быть тут именно это?

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

Ответил?

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

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

2. Вложенность использую для упорядочения в дереве, чтобы не было большого списка (считай иерархия)

И какая семантика иерархии - простая организация? От общего к деталям? Можешь примерчик дать?

3. Связь реализации появляется при привязывании требований к вариантам использования через свойства последних

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

4. Все возможные выборки и по типам и по другим признакам настраиваются во View в виде фильтров. Их удобно использовать для различных группировок и управления требованиями

Эти вещи понятны, я их привел для общности картины, если что

Может кто-то дополнит. Вообще каждый для себя сам определяет как уобней, чтобы не делать лишней работы и экономить время и силы. Как говорит Саша Юняев (ака bustor)

Удобство для себя не означает удобство для других. Я не однократно сталкивался с этим, и тут трудно что-то поделать, приходится либо смирится либо доказать, что твоя классификация лучше.

Все таки меня волновала связь владения owns и связь агрегации (composed of , part of), Правда присмотревшись внимательно обнаружил, что обе эти связи обозначаются совершенно одинаково. Т.е. можно утверждать, что это одно и тоже. Жаль что в ЕА не автоматизирована визуализация связей таких вложенностей явно, хотя может и правильно...

В общем я предлагаю в этой теме дискутировать по поводу применимости ЕА для управления требованиями, как? Если нет - убью тему...

Ответил?

да

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

По типам,например, модель требования (читай SUP) разделяю в отдельные пакеты функциональные требования, требования по производительности, ограничения и тп,
По предметным областям для требований и вариантов использования это, например, безопасность, сервисы для клиента, сервисы оператора, CRM, Отчетность и тп.
Для акторов это 2 пакета обычно по типам - Пользователи и Системы, но их тоже можно поделить по областям, если акторов много

И какая семантика иерархии - простая организация? От общего к деталям? Можешь примерчик дать?

1. Формат регистрационный данных
  1.1 Формат логина
  1.2 Формат пароля
  1.3 Формат ФИО
  1.4 Формат паспортных данных
  ...

Да согласен, а как ты назовешь связи между бизнес-целями и детализирующими их требованиями? Зависимости?

Трассировка
Назвать можно как хочется, главное чтобы все тебя понимали и это помогало решать ВАШУ проблему (задачу)
В книге Вигерса "More about software requirements" есть хорошая картинка показывающая не просто связи требований друг с другом, а их семантику

По типам,например, модель требования (читай SUP) разделяю в отдельные пакеты функциональные требования, требования по производительности, ограничения и тп,
По предметным областям для требований и вариантов использования это, например, безопасность, сервисы для клиента, сервисы оператора, CRM, Отчетность и тп.
Для акторов это 2 пакета обычно по типам - Пользователи и Системы, но их тоже можно поделить по областям, если акторов много

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

1. Формат регистрационный данных
  1.1 Формат логина
  1.2 Формат пароля
  1.3 Формат ФИО
  1.4 Формат паспортных данных

Как я понимаю это именование (алиасы) требований. Вот требование 1 ка у тебя сформулируется? Ч учетом, что оно должно быть проверяемым поскольку это требование?

Назвать можно как хочется, главное чтобы все тебя понимали и это помогало решать ВАШУ проблему (задачу)
В книге Вигерса "More about software requirements" есть хорошая картинка показывающая не просто связи требований друг с другом, а их семантику

у меня нет книги, у тебя есть?

Книгу нашел. Где смотреть

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

Не понимаю. Объясни плиз, в какое время и почему она будет меняться? Отчеты можно делать разные, опять же все зависит от того как организованна работа. Требования к отчетности навряд ли могут стать требованиями к администированию  

Как я понимаю это именование (алиасы) требований. Вот требование 1 ка у тебя сформулируется? Ч учетом, что оно должно быть проверяемым поскольку это требование?

В системе должны быть предусмотрены такие-то регистрационные данные

Книгу нашел. Где смотреть

Эд, в книге есть список иллюстраций. Их просмотр занимает 2 минуты
Figure 23-1

Не понимаю. Объясни плиз, в какое время и почему она будет меняться? Отчеты можно делать разные, опять же все зависит от того как организованна работа. Требования к отчетности навряд ли могут стать требованиями к администированию 

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

В системе должны быть предусмотрены такие-то регистрационные данные

но требование то по формату. Ты пишешь Формат рег данных: система должна поддерживать установленный формат данных для таких-то рег данных? и дальше раскрывать конкретно? Конкретные моменты мы проверим, но как проверить само группирующее требование? или проверять его следует как агрегат и только как агрегат?

Эд, в книге есть список иллюстраций. Их просмотр занимает 2 минуты
Figure 23-1

Злой ты, Виталик, вижу я рисунки - поди догадайся какой ты имел в виду. И кстати мы не используем Use Cases

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

Хм... походу беседа клонится к обсуждению таксономии требований и EA тут не при чем получается. Я согласна с Виталием - делать надо, как удобнее, хотя бы самому себе для начала. А то окажешься в положении сороконожки, которая задумалась, с какой ноги идти. Классификация очень сильно может зависеть от поставленной перед тобой задачи...
Да и требования на практике не обязаны выстраиваться в строгую иерархию по какому-либо одному или нескольким атрибутам. В случае EA мы имеем дело с реляционной БД, в которой требования - записи с некоторым набором атрибутов (можем назвать их аналитическими признаками или даже классификаторами). EA позволяет делать выборки-отчеты, фильтруя записи по атрибутам.
Если этого недостаточно, можно рассмотреть возможность прикрутить к БД EA какое-нибудь средство построения отчетов или того больше - OLAP...

М.б. ЕА и не причем, но нужно учитывать, что ЕА позволяет производить многие действия только на основе пакетов, например, посмотреть трассировку требований можно посмотреть только сравнивая 2 пакета.

Хм... походу беседа клонится к обсуждению таксономии требований и EA тут не при чем получается.

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

Сейчас несколько ситуация поменялась. Тем не менее меня интересовало в первую очередь вкладывание одних требований в другие. Но, кажется, я для себя прояснил ситуацию. Потому можно двигаться дальше.

М.б. ЕА и не причем, но нужно учитывать, что ЕА позволяет производить многие действия только на основе пакетов, например, посмотреть трассировку требований можно посмотреть только сравнивая 2 пакета.

Да ты прав Саша, это следует иметь в виду обязательно