Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
1126
3. Необходимо использование БАР-кодов для номеров скретч-карт.
Больше похоже на бизнес-правило.

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

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
Бизнес-правило однозначно.

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

Насколько мне известно, все более-менее массовые сканеры штрих-кодов поддерживают стандарт EAN.

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


1127
кажется, я начинаю понимать сущность наших разногласий с greesha:

ситуация с отсутствием вижина - явно неправильная для проекта по разработке ПО,
а для нашего с Galogen-ом - так законный пример, который нужно далее развить:

Может, причина наших разногласий в том, что мы по-разному поняли Концепцию проекта "Практикум по управлению требованиями"? ;)

Тогда обращаемся к первоисточнику:
http://www.uml2.ru/forum/index.php?topic=487.msg5535#msg5535
и пытаемся уточнить потребности Заказчика (в роли которого в данном случае выступает Galogen).

1128
Да не утонем. Надо сначала парой абзацев описать назначение разрабатываемой системы (к вопросу о целеполагании), а потом уже приводить примеры требований. Иначе студенты попытаются заполнить пробелы в понимании самостоятельно (те, кто пытается думать, конечно) и насинтезируют заказчику таких потребностей...

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

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

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


Задача стоит, конечно, учебная, и мои вопросы вполне могуть быть лишними. Но посмотрите внимательно на начальные "зарегистрированные" десять требований и варианты ответа на мой первый вопрос "Чем занимается Заказчик?"

Разные ответы на этот вопрос ведут к созданию разных систем. Отвечающих одим и тем же требованиям. Это означает, конечно, что требования неполны.


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

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

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

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

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

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

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

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

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

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

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

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

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

1133
Положительная оценка в 270 градусов... Такой градус, пожалуй, далеко не всякий аналитик осилит. :)

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


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

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

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

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

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

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

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

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

1136
Цитата1.
Требования клиента могут быть выражены в его собственных терминах и представлять собой нетехнические описания. Требования к продукту являются представлением требований клиента с помощью технической терминологии и могут быть использованы для проектных решений.

Вопрос 1.
Что значит выражены "с помощью технической терминологии"?

Там выше сказано:

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

Но по-моему, не стоит уделять этому слишком много внимания.


Цитата 2.
Разработка концепций и сценариев использования системы является первым шагом процесса анализа и утверждения требований

Вопрос 2.
Правильно ли я понимаю, что разработка концепции и ВИ есть суть анализа и осуществляется после сбора " требований клиента, требований к продукту и его компонентам, требований к компонентам продукта, требований к интерфейсам". Просто я как-то наивно полагал, что концепция делается до начала массового сбора требований?

...
Вопрос 3
Как совершенно не въезжаю в то, что тут написано. То, что не понятно, подчеркнул.

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

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

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

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

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

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

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

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


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

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

1139
Странный движок всё-таки. Ввёл пост, нажал "отправить". Он говорит: "пока вы писали ответ, в теме появились новые сообщения".
Исправил свой пост, нажал "отправить". Так движок зачем-то перед отправкой отменил все мои изменения. Зачем тогда спрашивал, интересно?

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

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

Добавляю исключительно по поговорке "у кого что болит, тот о том и говорит". :)

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »