Здорово.

Но...

Примерил это на RaQuest, и (его возможности пока знаю плохо, т.к. совершенно нет возможности проверить работу на коллективность - но зато есть стимул), думается мне, это там не возможно. Разве только в опции обсуждения.

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

Примерил это на RaQuest, и (его возможности пока знаю плохо, т.к. совершенно нет возможности проверить работу на коллективность - но зато есть стимул), думается мне, это там не возможно. Разве только в опции обсуждения.

система статусов и групповая работа, в т.ч. и обсуждения имхо спасут и тебя, и отца русской демократии.

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

В EA это есть, правда не юзала.

система статусов и групповая работа, в т.ч. и обсуждения имхо спасут и тебя, и отца русской демократии.

Стоп стоп стоп. Ты хочешь сказать, что в RaQueste есть нечто под понятием раздача задач и поручений? Или это просто смена статуса ПМ?

EA и RQ близнецы братья, кто больше матери истории ценен... (покорябанный c)
Если есть в EA, то я могу набить требование в RQ, открыть EA и прицепить к нему что-нибудь еще, таск или баг.
Смена статуса возможна для требований, и режим обсуждений есть прям для требований - и вот это все есть в RQ

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

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

Вопрос: что такое "регистрация"?
Ещё вопрос: что такое "учёт"? Предполагается ли учёт статуса карт - "загружена"/"продана"/"активирована"/...
Клиент-Банк - это вообще отдельная тема со своими требованиями, которые по сложности могут превысить основной функционал.

Узнаю хватку и максимализм аналитика:
Пока требование не прояснено до конца - оно не имеет право на жизнь!!!
(а аналитик на спокойный сон) :-)

Но...
Примерил это на RaQuest, и (его возможности пока знаю плохо,

так ото-ж :-)
или мы укладываем в голове, ЧТО нужно делать с требованиями
или мучимся применить для этого любимое средство

Узнаю хватку и максимализм аналитика:
Пока требование не прояснено до конца - оно не имеет право на жизнь!!!
(а аналитик на спокойный сон) :-)

Я не аналитик, я только учусь. Пока преимущественно на своих ошибках.

Пока не определена терминология, а над проектом работает больше одного человека, требование может (и обязательно будет) истолковано неправильно.

Будет побольше времени - добавлю пару свежих примеров в ветку "Просчёты аналитиков".

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

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

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

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

О! вот это уже точно по нашей теме!
Начало - в моём наброске сценария приёма требования.
И если мы хотим что-то толковое родить в наших дискуссиях - то в этом должна обязательно присутствовать тщательно проработанная часть:
роли в процессе управления требованиями и их классификация

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

второе

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

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

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

это и есть упоминаемая Вами связь между требованиями различных уровней

и модель со связью: много_проблем - ко - многим_решениям, где Требование является классом-связью, реализующим эту связь многие-ко многим,
Гуры сознательно или подсознательно упрощают до: ОДНА_проблема- ко -многим_решениям, где требование строится путём добавления нужных атрибутов Проблеме.
Отсюда и двойственность в толковании терминов проблема и требование.
В последней модели: требование - это то же самое, что и проблема, только ещё с дополнительными атрибутами и прицепленным набором решения проблемы.

Пока не определена терминология, а над проектом работает больше одного человека, требование может (и обязательно будет) истолковано неправильно.

а никто и не спорит,
но прежде, чем требование будет истолковано неправильно (или будет создан глоссарий для его  однозначной ПЕРЕФОРМУЛИРОВКИ) - оно должно родиться и прожить какое-то время.
так что, пусть бомжует весь этот период?
или вообще займёмся "планированием семьи" требований, пока глоссарий и описание бизнес-процессов не подготовим? :-)

а никто и не спорит,
но прежде, чем требование будет истолковано неправильно (или будет создан глоссарий для его  однозначной ПЕРЕФОРМУЛИРОВКИ) - оно должно родиться и прожить какое-то время.
так что, пусть бомжует весь этот период?
или вообще займёмся "планированием семьи" требований, пока глоссарий и описание бизнес-процессов не подготовим? :-)

Это вопрос курицы и яйца.

Глоссарий формируется по мере формулирования требований, стандартными запросами "Переведи!" и "Шо конкретно вы имели в виду?"
Некоторые авторитеты рекомендуют, чтобы документ с требованиями (если такой имеется) оформлял один человек, но при этом он обязательно должен советоваться со всеми, кто этот документ собирается использовать.

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

То есть аналитик пишет, например: "данные операции должны учитываться при сверке итогов по тем же правилам, что и продажи". Разногласия возникли при интерпретации слова "данные".

7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.

Неясное требование. Что же должна делать система? Отлавливать карты с разрешенным диапазоном кодов, но какие-то бракованные?

Что-то туго у меня с классификацией.

Потому пока вот такой расклад. Я не учитель, я ученик в требованиях

1.   Работа со скрэтч-картами
   a.   Система должна обеспечивать учёт скрэтч-карт.
   b.   Система должна поддерживать интеграцию с Клиент-Банком.
   c.   Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
       i.   Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
       ii.   Необходимо использование БАР-кодов для номеров скретч-карт.
       iii.   Необходимо использование БАР-кодов для секретных кодов скретч-карт.
       iv.   Необходима интеграция с внешними системами считывания бар-кодов.
       v.   Необходима интеграция с переносной системой считывания бар-кодов компании Х.
   d.   Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
       i.   Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.

2.   Приход средств
   a.   Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
   b.   Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

3.   Отчетность по счету
   a.   Система должна обеспечивать отчётность о текущем состоянии счёта компании.
   b.   Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
   c.   Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Несовсем понял из задания. Нужно ли самому придумать, если нет, но подразумеваются: бизнес требования, требования пользователей? Или нужно действовать в жестких рамках предложеного списка, не добавляя и не убавляя

Вот так всегда. Начинаешься кучу книг, кажется, все знаешь. Но стоит столкнуться с реальной задачей и пасуешь.

Однако на ум приходит фраза из детства. Был такой журнал. Что-то типа:
"Орешек знаний тверд. Но расколоть его поможет киножурнал 'Хочу все знать'"

Так что попытка №2. Классификация

Скажем так нужды
3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
12. Необходима интеграция с внешними системами считывания бар-кодов.
13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.


Системные требования
1. Система должна обеспечивать учёт скрэтч-карт.
2. Система должна поддерживать интеграцию с Клиент-Банком.
6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Продолжим издевательства над требованиями:

3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
    11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в
         компании оборудование поддерживает только этот стандарт.
{хотя неочень четко понимаю разницу - и это как-то ближе к бизнес-правилу, по карйней мере что касается требования 5}

12. Необходима интеграция с внешними системами считывания бар-кодов.
      13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.



1. Система должна обеспечивать учёт скрэтч-карт.
    6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
    7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.


8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
    2. Система должна поддерживать интеграцию с Клиент-Банком.

9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Неясное требование. Что же должна делать система? Отлавливать карты с разрешенным диапазоном кодов, но какие-то бракованные?

:-) ОК, я, типа, ТОП от Заказчика, Вы - обескураженный Аналитик:
ну чё непАнатнАга? :
сидит девка, заносит в систему приход новой пачки карт:
клац штрих-сканнером спереди- номер первой карточки,
клац сззади - номер последней,
пАсьмАтрела - на пачке написана бракованная карточка, которую выкинули,
вбила её номер пальцами.
Всё: все карточки из пачки шоб в системе были, а бракованной - шоб не было.