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

Вашими бы устами да мёд пить.

Легко придумывались штук 300 требований? Да еще однозначно понимались? Да еще однозначно трассировались? и были не интересны? - может сразу все сделать и выдать готовый результат? :-)

Если честно я не очень понимаю в чем проблема связи требований?

Мне кажется есть проблема извлечения, формулировки требований.

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

Я конечно понимаю Ваш тезис. Главное не в навороченности системы, красивости и удобстве ее. Главное в умение и понимании, а оно безусловно достигается не использованием инструментов, хотя и помогает этому.

Изучая UML(в графическом его смысле), совершенно нельзя научиться объектному проектированию.

Значит справедливо и утверждение - использование систем управления требованиями - по сути не научит делать требования и управлять ими.

Gevorg, Вы это greesha  в пику или в одобрение казали?

дак он про грабли, да про то, что болит у каждого своё, а мне соль на раны...
решил поделиться, мол, и у меня такое было :-)

а по сути вопроса, так однозначно - одобрение,
очень стОящее свойство требования, хорошо, что greesha напомнил

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

Почему добыча требования - это его дизайн?

процессов по оценке качества, упаковке, маркировке, транспортировке, хранению (менеджмент требований)

Т.е. производством мы не управляем?

для дизайна - выходным продуктом.

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

- акцент на систематизированность подхода,

Так куда же пбез систематизированости, только мне кажется Вы тут попутали системный подход с систематизированностью

- набор деятельностей, не включающий какого-либо производства требования, одна логистика.

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

 

причём - на полном серъёзе: в рамках работы над ТЗ пришлось
 продумывать и предлагать бизнес-процессы для только зарождающейся деятельности Заказчика,

Ну это возможно и это никак не противоречит намшей дискуссии

а поскольку управление требованиями идёт в контексте комплексного управления ВСЕМИ объектами процесса управления разработкой ПО,

Да вообщем, тут и обсуждать нечего - совершенного естественно. Тем более, что в рамках итеративного подхода требования определятся практически на всем протяжении проекта.

- производственного процесса, для которого требование является
-- артефактом (в моём примитивном понимании - продуктом), и

требования являются, по-моему, заданием - производственным заданием. И на разных уровнях оно разное. Токарю - выдаете чертеж и технологическую карту, чертежнику-конструктору - более общие задания.

Помещу, вот ссылочку чтобы не забыть: http://www.pmexpert.ru/services/training/moscow/detail.php?ID=107.

Ключевое слово для будущего поиска: рюшечка

Легко придумывались штук 300 требований? ...
- может сразу все сделать и выдать готовый результат? :-)

Именно это я и предлагаю: "выдать готовый результат", в смысле - сАми требования.
И дальше - показать студенту, что даже когда требования УЖЕ классно описаны и связи между ними - определены
-- Всё равно остаётся куча проблем в работе с ними.
Их решение - и будет предметом курсовой работы именно по УПРАВЛЕНИЮ требованиями.

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

так мы о теории говорим или о практическом опыте?
Проблема, ещё какая проблема! И не одна.
Только не научные эти проблемы, а инженерные и манагерские.
Согласования терминов и сути в наборе из различных, но тесно связанных технологий,
Интеграция средств автоматизации,
Регламентирование и документирование самого процесса,
Саботаж персонала.

Если честно я не очень понимаю в чем проблема связи требований?

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

Значит справедливо и утверждение - использование систем управления требованиями - по сути не научит делать требования и управлять ими.

ЫМХО, справедливы след.2  утверждения:

использование _ПО_ для управления требованиями - по сути не научит делать требования и управлять ими.

использование _КОНЦЕПТУАЛЬНОЙ СИСТЕМЫ_  как раз-то и научит делать требования и управлять ими как по-сути, так и по-форме.

Gevorg? давай уж эти свои 10 требований и начнем их обсуждать. Я буду с использованием раквеста чур...

Т.е. производством мы не управляем?

да управляем,или по крайней мере, - должны управлять,
только в рамках управления требованиями - намеренно абстрагируемся, считаем, что на производстве уже всё так, как нам надо

А я полагал, что для дизайна выходной продукт - решение.
Да, конечно, между требованием и решением много общего.

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

здесь я для себя провожу аналогию с понятиями производство - логистика.
...получается, что
для менеджмента  - требование является объектом управления, а
для дизайна - выходным продуктом.

ИМХО, чтобы более нагладно представить суть обсуждаемого предмета  попытался представить ваше утверждение в IDEF0, но возникают некоторые трудности: IDEF не предполагает управление артефакатами (требваниями), а только управление функциями. Поэтому воспроизвести Ваше утверждение на приаттаченной схеме буквально (вариант 1) - не получилось. Вы имели в виду вариант 2 или вариант 3?

(наивно) А направление движения справа налево - это очередное новведение UML?

2 greesha: sorry, поправил (IDEF3 попутал .

Gevorg? давай уж эти свои 10 требований и начнем их обсуждать. Я буду с использованием раквеста чур...

Вот, на вскидку:

1. Система должна обеспечивать учёт скрэтч-карт.
2. Система должна поддерживать интеграцию с Клиент-Банком.
3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
12. Необходима интеграция с внешними системами считывания бар-кодов.
13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Нужно бы ещё придумать для них авторов, других заинтересованных лиц и их интересы, степень важности.

Набросок списка первых заданий студенту:
- классифицировать требования по 3-м уровням.
- Определить наличие и тип простейших зависимостей между требованиями одного уровня (детализация\агрегирование).
- Определить наличие связей проблема-решение между требованиями различных уровней.

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

да управляем,или по крайней мере, - должны управлять,
только в рамках управления требованиями - намеренно абстрагируемся, считаем, что на производстве уже всё так, как нам надо

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

Здесь должен помочь Джереми Дик - один из соавторов известной книжки от Телелоджика (преревод Ильи Корнипаева),

Книгу знаю, читаю. Нахожу много интересного.

Отсюда и терминологическая путаница в терминах дизайн-решение.

Давайте определятся с терминологией. Насколько я знаю создание глоссарие и единое понимание терминов - важнейшая часть любого проекта.

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

Нужно бы ещё придумать для них авторов, других заинтересованных лиц и их интересы, степень важности.

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

Набросок списка первых заданий студенту:
- классифицировать требования по 3-м уровням.

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

- Определить наличие и тип простейших зависимостей между требованиями одного уровня (детализация\агрегирование).

а если одно требование реализует несколько требований более высокого уровня, т.е. нет строгой иерархии

- Определить наличие связей проблема-решение между требованиями различных уровней.

А это что за связь?

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

Несовсем понял, что вы имеете в виду? И кто такой дизайнер требований?

Дело менеджера оных должно свестись к простой регистрации в определённом формате.
В нашем случае - заведению в РаКвесте.

Менеджера чего? Т.е. лица отвественного за требования, тот кто их формирует и утверждает?

Вот, на вскидку:

1. Система должна обеспечивать учёт скрэтч-карт.

Вах, какая сладкая тема!

Вопрос: что такое "регистрация"?

Ещё вопрос: что такое "учёт"? Предполагается ли учёт статуса карт - "загружена"/"продана"/"активирована"/...

Самый Главный Вопрос: "За что ему деньги плОтят?" Как связан cash flow со статусами карт? (Всю последнюю неделю стоим на ушах, из-за того что заказчик поменял схему расчётов с провайдером, применив способ, изначально никем не предусмотренный, огрёб из-за этого серьёзные финансовые претензии и попытался свалить их на нас).

Клиент-Банк - это вообще отдельная тема со своими требованиями, которые по сложности могут превысить основной функционал.


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

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

Появление новых требований в этой схеме тоже возможно.
Вот приблизительный возможный сценарий:

Для начала роли персон андер дискашшинз:
- Менджер требований (RM): центральная фигура, в фокусе нашего внимания,
- Дизайнер требований (RD): некий Умный и Всезнающий Дядя (УВД), способный закрыть любую дыру в проблемах с требованиями. Как работает - неизвестно, Что делает - не понятно, но проблему решает любую.
- Представитель Заказчика (CR): некая совсем уж обобщённая роль для любых действий, предполагаемых от Заказчика.

1. (CR): Звонит на фирму, просит выслушать его очередную хотелку.
2. (RM):
- Принимает звонок,
- регистрирует новое требование во внутренней системе управления Требованиями (СУТ).
- Признаётся, что ничего не понимает в словах (CR)-а,
- договаривается с ним и
- регистрирует в СУТ задачу для (RD): провести интервью и извлечь требование:
    "Поди туда, ЗНАЮ, куда, - возьми то, НЕ_ЗНАЮ, что.
3. (RD):
- Проводит интервью,
- уж неизвестно как изощряется, но
- приносит формулировку нового требования,
- его классификацию и связи с другими.
4. (RM):
- регистрирует выполнение задачи (RD)-мом,
- Регистрирует принесённые результаты в СУТ,
- обнаруживает, что (RD) забыл определить список заинтересованных лиц,
- ПЫТАЕТ оного по данному вопросу.
5. (RD):
- отделывается выбором заинтересованных лиц из списка уже имеющихся в СУТ,
- отбивается, чтобы не решать задачу формулировки их интересов по данному требованию.
6. (RM):
- регистрирует заинтересованных лиц, фиксирует напоминалку, что список заинтересованных лиц не проверен на полноту,
- регистрирует напоминалку, что список интересов по требованию не определён,