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

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

да и орешек НЕ слабый на самом деле:
давайте нанесём первый удар в плоскости уровней: Бизнес-Юзер-Систем,
без разбору остальной классификации.

З.Ы. я хоть и старался каждое из них писать удобным для однозначной классификации, но возможны и ляпы, так что заранее прошу не пинать ногами :-)
всегда готов исправиться, если увидим чего не так.
тем более, что пример учебный и можно себе позволить некоторый волюнтаризм...
но на то и greesha на форуме, чтоб Gevorg не дремал... :-)

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

пока новых требований придумывать не надо, и без того мороки хватит,
да и новых уровней постараемся не вводить, я когда придумывал требования, ориентировался только на 3: B-U-S

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

полностью согласен про рекурсию с уточнениями ОПИСАНИЯ_СУЩНОСТИ_требований и глоссария, и что в разных проектах её началом может быть как одно, так и другое.
но как быть со случаем в моём примере сценария, когда Требование уже зарегистрировано, а его описания, как такового, пока нет вААще?
это я снова стараюсь обратить внимание на то, что у требования, кроме его описания и смысла, который за ним стоит, - есть ещё целая пачка важных атрибутов.

чтобы далеко не ходить:

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

а по нашей теме: где здесь требования?
если я правильно понял, то:
- Заказчик изменил бизнес-процесс, и не сообщил об этом Разработчику,
- Заказчик использовал имеющийся в системе набор решений для реализации какого-то нового или обновлённого фрагмента в изменённом бизнес-процессе,
   (заметим: снова не сообщил об этом Разработчику)
- как результат - Заказчик получил проблему в области своего бизнеса,
- Заказчик пытается разделить или полностью перенести на Разработчика ответственность за возникновение проблемы и за её решение.

Так где здесь проблемы НЕДопонимания или разночтения сути требования?
Здесь чистой воды ряд убийственных просчётов в области МЕНЕДЖМЕНТА оных.

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

Дак Эдуарду как раз и нужно МНОГО требований,
точнее МНОГО вариантов для набора требований,
достаточно отличающихся между собой, чтобы затруднить списывание и плагиат.

Итак, нам нужен достаточно большой, но без примитивного фанатизма (300шт - занадто и НЕ здраво) набор простых требований,
позволяющий скомбинировать из них 30 мало пересекающихся вариантов набора требований,
 как материала для заданий по курсу управления требованиями.

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

Эдуард, берите в коллекцию!
 возникла задача менеджмента требований:
-  уточнить термин  "регистрация"
- внести необходимые правки в описание требований: 6,8,9, содержащих эти требования, возможно,-
- провести ревизию описаний остальных требований на предмет использования синонимов.

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

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

Эдуард, ещё находка: Появилось новое требование.
По нему задача: зарегистрить в СУТ.


Результатом должно быть что-то в роде:

Требование
№: 15.
Описание: В учёте отслеживать статус карт: "загружена"/"продана"/"активирована"/...
Автор: greesha (роль в проекте: сторонний консультант),
Статус: предложено,
Связь: подтребование(составная часть) от тр1.
Важность для Заказчика: 100%
Ответственность: Galogen (роль в проекте: регистратор изменений в требованиях)

О, меня уже посчитали.

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

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

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

3. Для чего используются скретч-карты (оплата мобильной связи, оплата междугородной связи, доступ в интернет, web-деньги, другое...)
Предполагается обработка карт только одного типа или разных типов?

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

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

Gevorg давайте (а может на ты, проще общаца) не будем торопица.

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

Я уже начал его формировать и сделал структуру: Бизнес-требования, Пользовательские требования, Функциональные требования

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

Пока у меня не все получилось - куда что пораскидать, также возникла проблема с названием каждого требования, пока делаю просто - из каждого описания выделяю ключевую фразу и делаю ее заголовком, а всё предложение помещаю в описание требования. Нужно еще разместить статусы и назначить атрибуты. Пока использую что есть по умолчанию

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

Далее что с нумерацией? придерживаться предложенной Вами? или разрешить автонумерацию?

Потом я включу Ваши указания по требованиям

Да - а что такое срэтч-карта (простите за наивность)

Да - а что такое срэтч-карта (простите за наивность)

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

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

Или это была просто шутка юмора, как комментарий к опечатке?

Gevorg давайте (а может на ты, проще общаца) не будем торопица.

Огромное сорри!
>общаца и торопица
это только в плане стёба над спецификой общения с ТОПами,
и только в пределах одного пОста,
в личном плане - ничего подобного и в мыслях не было,
да и по отношению к себе не люблю.

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

Ага, теперь понятно, было что-то в подсознании из опыта использования интернет-карт

Огромное сорри!
>общаца и торопица
это только в плане стёба над спецификой общения с ТОПами,
и только в пределах одного пОста,
в личном плане - ничего подобного и в мыслях не было,
да и по отношению к себе не люблю.

Это Вы что, типа обиделись?

Еще не все ладно с классификацией,

и у меня не всё ладно, это как раз то, что нам надо:
- с классификацией требований - проблемы,
- общей картины по бизнесу нет, одни осколки,
- СУТЬ, описанная в документе с требованиями, - не выдерживает никакой критики,
- хамовитый ТОП наезжает со своими манерами общения,
и т.д.

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

Это Вы что, типа обиделись?

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