61

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 16:07:45 »

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

greesha, мне тоже очень нравится "вникать в физическую сущность проблемы", честно,
еле сдерживаюсь, чтобы самому не пОстить свои соображения по моделированию этой сАмой "физической сущности".

у нас уже обзначилось распределение ролей в изучаемом нами процессе управления требованиями по участникам обсуждения:
- Вы, greesha, - законный эксперт по формулировкам и пониманию СУТИ каждого требования,
- я взял себе роль ведущего манагера по требованиям, которому просто губительно вникать в суть требований, и без того вокруг них работы полно,
- Galogen добровольно (и очень добросовестно) взялся за работу моего подчинённого-исполнителя,
но на самом деле - это для него должно быть только в режиме парт-тайма,
его главная роль - ВНЕ самого процесса: учредитель проекта,
в рамках которого нужно:
-  построить и запустить "стендовый" процесс управления требованиями,
-  собрать на результатах методический материал для проведения курса своим студентам.

62

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 15:38:52 »

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

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

63

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 15:33:06 »

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

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

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

64

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 15:14:24 »

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

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

65

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 13:13:16 »

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

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

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

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

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


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

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

66

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 12:39:29 »

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

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

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

67

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 12:21:22 »

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

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

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

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

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

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

68

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 11:46:35 »

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

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

69

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 11:41:07 »

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

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

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

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

70

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 11:14:35 »

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

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

71

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 19:41:01 »

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

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

72

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 19:32:03 »

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

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

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

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

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

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

второе

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

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

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

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

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

73

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 18:56:56 »

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

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

74

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 18:51:03 »

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

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

75

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 18:42:59 »

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

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