В теме 19 ответов, и 6 участников, последнее обновление сделано пользователем 
Андрей В. 13 г, 5 мес. назад.
-
Сообщения
-
Добрый день!
Меня интересует какие вы вопросы задаете заказчику для того чтобы понять его потребности и получить в итоге требования.
Ссылки на литературу только приветствуются. Желательно на русском языке.
Хотелось бы не просто получить ссылки, но и конкретно примеры от каждого форумчанина и последовательность ваших вопросов.Заранее благодарю.
Привет,Вообще, тема не в том разделе. Я бы попросил модератора перекинуть ее в работу с требованиями.
Теперь по сабжу: http://analyst.by/forum/rabota-s-trebovaniyami/checlist-dlya-raboty-s-trebovaniyami
Это не то?Привет,
Привет
Вообще, тема не в том разделе.
Долго выбирал и решил здесь открыть.
Я бы попросил модератора перекинуть ее в работу с требованиями.
Не возражаю.
Теперь по сабжу: [url]http://analyst.by/forum/rabota-s-trebovaniyami/checlist-dlya-raboty-s-trebovaniyami[/url]
Это не то?В этих темах всё как-то обобщенно. А мне надо конкретные вопросы.
Поскольку даже обобщенные пункты обсуждались очень вяло, то я могу предположить, что конкретные вопросы получить маловероятно
Но всё же очень надеюсь на них! Сейчас придется общаться с людьми ну очень сложными. В первом моём случаи было легче т.к. был человек более смышленый, а самое главное была литературы от куда я мог брать информацию. Сейчас такой литературы нет и люди толком даже не смогли сказать что им надо и поэтому отложили беседу на следующую неделю. Буду в выходные готовиться к этой беседе.В теме С чего начинать извлечение требований?Юрий Веденин » 11 апр 2010, 13:37
1) ознакомиться со всеми имеющимися материалами
2) ознакомиться с тем, кто же ваш заказчик
3) ознакомиться с бизнесом вашего заказчика
4) спланировать дальнейшее "извлечение" требованийСогласен! Сделано. Пункт 4 интересует
Gerych » 17 янв 2010, 20:20
1) у меня лично это authentication and authorization portion (юзера, роли, аутентификация, пермишны),
2) каталог юз кейсов приложения,
3) драфтовые мокапы скринов,
4) интеграция с внешними приложениями и скрытая логика системы.
5) Получив исходные неформализованные требования по всем этим пунктам ваяется скоуп проекта (к примеру в виде юз кейсыкаталог фич -> vision and scope document).
6) После полного согласия между сторонами по скоупу начинается детальное выяснение требований по всем этим пунктам и, соответственно, занесение их в SRS.Вот как ты получаешь эту инфу? Какие вопросы для каждого пункта задаешь?
essence » 12 май 2010, 11:24
1. Выделила бизнес потребности и их владельцев (кому что надо).
2. Выделила high-level процессы, их владельцев и 2-3 активных участников каждого процесса.
3. Выделила аналитика со стороны заказчика. Вот тут ИМХО важно пояснить, что у всех этих людей должно быть выделено время на работу над проектом, иначе они ее будут саботировать. Объяснить их руководству.
4. Вначале самостоятельно изучила процессы (google и т.п.), нарисовала бы себе стандартный процесс (по ISO и т.п.), сформировала скоуп вопросов. Часто заранее можно получить всякие внутренние инструкции, памятки и т.п. — в них горы информации.
5. Сформировала коммуникационный план. Оптимально, я думаю делать его еженедельно на неделю вперед. Запланировала встречи согласно плану.
6. И вперед на баррикады: интервью, анкеты, семинары, наблюдение и т.д. Вот тут я для себя заметила некоторую особенность: есть люди, которым лучше писать, чем говорить. Вот таким я стараюсь задавать вопросы письменно.Я считаю, что обследование процессов "как есть " важно при извлечении требований. Потому что на этом этапе выясняется столько интересной инфы, которая может быть имлементирована в системе (регистрация задним числом, параллельное и одновременное выполнение последовательных процедур процесса, регистрация дополнительной информации и т.д.).
7. Нарисовала процессы "как есть" и подтвердила с участниками процессов, что именно так и есть.
8. Приступила к формированию системных сценариев использования на основании бизнес сценариев.Тоже самое. Как получить эту инфу? Какие вопросы для каждого пункта надо задать?
А в теме Чеклист для работы с требованиями для проектируемой системыGerych » 24 май 2010, 18:16
- Список юз кейсов/фич планируемой системы в объеме, достаточном, чтобы покрыть эстимациями;
- Доменная модель системы aka список всех возможных сущностей и взаимосвязей между ними;
- Четкое понимание жизненного цикла основных сущностей систем и business workflows при работе с системой (с четко заостренными моментами начала и конца работы);
- Аутентификация и авторизация — классы пользователей и, как следствие, роли, ограничения и т.д.№
- Требования к дизайну;
- В случае абсолютной непонятности скоупа гуя по исходному вижну — мокапы/описание отдельных страниц/окон;
- Если есть интеграция с внешними системами, то точный скоуп интеграции + API.
- Ограничения хостинга, железа и софта.Какие конкретно по каждому пункту надо задавать вопросы чтобы получить наиболее правильный ответ? Ведь «Правильно заданный вопрос – половина ответа» :-)
Добрый день, Andre!Чтобы не повторять сказанное коллегами (мои вопросы очень близки к уже прозвучавшим здесь), выскажусь с немного другой позиции.
На мой взгляд, одним из первых шагов при вхождении в новый проект должно быть высокоуровневое понимание бизнеса (на уровне кто? что? зачем?). Достигнув такого понимания, можно говорить о конкретных вопросах типа требований к железу или дизайну. Как правило, заказчик — человек бизнеса, его представление о технических решениях, нужных для бизнеса, может быть очень и очень поверхностным и далеким от правды. Поэтому если сразу начинать вытягивать конкретные требования, можно в дальнейшем столкнуться с тем, что система фактически не будет соответствовать требованиям бизнеса (хоть и спроектирована она согласно видению заказчика).
Конечно же, можно начинать и без этого. Но чем глубже будет ваше понимание бизнеса и его проблем, тем лучше будут предлагаемые вами решения и довольнее заказчик.
Для того, чтобы получить это первоначальное понимание, можно воспользоваться прикрепленным шаблоном — Business Model Canvas. Шаблон разделен по секциям Key Partners, Key Activities, Key Resources, Value Propositions, Customer Relationship, Customer Segments, Channels, Cost Structure, Revenue Streams (в каждой секции содержится пояснение, подробнее также можно почитать по ссылке http://www.businessmodelhub.com/page/business-model-generation). В нем уже есть высокоуровневые вопросы. Удостоверьтесь, что вы знаете ответы на них, если нет — можно начинать с их прояснения (через непосредственное общение с заказчиком, изучение доступной информации о компании и ее деятельности, изучение бизнес-домена и т.п.). Дальнейшие вопросы закономерно будут вытекать из полученных ответов.Когда-то переводил статью ресурса bridging-the-gap: http://analyst.by/articles/whichquestionstoask
Ссылка на оригинал: http://www.bridging-the-gap.com/what-questions-do-i-ask-during-requirements-elicitation/
Мне кажется, что ответ Аси + те вопросы, которые перечислены в упомянутой мною статье, отлично подойдут для начала. По мере же углубления в проект у вас появятся крайне специфические вопросы, точную формулировку которых заранее предсказать невозможно.Привет,
Вообще, тема не в том разделе. Я бы попросил модератора перекинуть ее в работу с требованиями.
Теперь по сабжу: [url]http://analyst.by/forum/rabota-s-trebovaniyami/checlist-dlya-raboty-s-trebovaniyami[/url]
Это не то?Учёл это.
Надеюсь в том разделе создал новую тему Как объяснить заказчику что такое пользовательские сценарии?Добрый день, Andre!
Для того, чтобы получить это первоначальное понимание, можно воспользоваться прикрепленным шаблоном — Business Model Canvas. Шаблон разделен по секциям Key Partners, Key Activities, Key Resources, Value Propositions, Customer Relationship, Customer Segments, Channels, Cost Structure, Revenue Streams (в каждой секции содержится пояснение, подробнее также можно почитать по ссылке [url]http://www.businessmodelhub.com/page/business-model-generation[/url]). В нем уже есть высокоуровневые вопросы.Благодарю за полезные ссылки!
Всё на аглицком. Буду переводить, а может уже есть перевод? На русском сам чёрт ногу сломит, а тут ещё на аглицком :-)Когда-то переводил статью ресурса bridging-the-gap: [url]http://analyst.by/articles/whichquestionstoask[/url]
Ссылка на оригинал: [url]http://www.bridging-the-gap.com/what-questions-do-i-ask-during-requirements-elicitation/[/url]
Мне кажется, что ответ Аси + те вопросы, которые перечислены в упомянутой мною статье, отлично подойдут для начала. По мере же углубления в проект у вас появятся крайне специфические вопросы, точную формулировку которых заранее предсказать невозможно.Благодарю за ссылки.
Может ещё кто-нибудь подкинет интересные вопросы.
Буду оформлять свой вопросник.Благодарю за полезные ссылки!
Всё на аглицком. Буду переводить, а может уже есть перевод? На русском сам чёрт ногу сломит, а тут ещё на аглицком :-)Перевод не попадался, специально не искала. Там текста совсем немного, думаю, разобраться особо труда не составит
Если что-то будет непонятно, пишите, вместе разберемся.Если что-то будет непонятно, пишите, вместе разберемся.
О, отлично! Ни вопрос!
Завтра постараюсь ответить, а то меня на работе задергали уже
Я так понимаю никто не имеет свой вопросник? Я думаю, что лучше перед встречей иметь свой вопросник, но видимо никто не хочет с ним делиться, да?
Вопросник конечно будет зависит от заказчика, но всё же некоторые вопросы будут универсальны. Да и полезно сохранять свои вопросники.
Я так понимаю никто не имеет свой вопросник? Я думаю, что лучше перед встречей иметь свой вопросник, но видимо никто не хочет с ним делиться, да?
Вопросник конечно будет зависит от заказчика, но всё же некоторые вопросы будут универсальны. Да и полезно сохранять свои вопросники.
Вопросы всегда зависят от домена проекта. Шаблоны анкет есть, но задавать вопросы из них все же нужно со знанием, зачем задается тот или иной вопрос. ИМХО чужие шаблоны будут мало полезны. Не бывает серебряной пули — к каждому заказчику и каждому интервью/сессии сбора требований нужно отдельно готовиться (если только у вас не поточное производство однотипных проектов, а такое бывает редко
)Вопросы всегда зависят от домена проекта. Шаблоны анкет есть, но задавать вопросы из них все же нужно со знанием, зачем задается тот или иной вопрос. ИМХО чужие шаблоны будут мало полезны. Не бывает серебряной пули — к каждому заказчику и каждому интервью/сессии сбора требований нужно отдельно готовиться (если только у вас не поточное производство однотипных проектов, а такое бывает редко
)У меня нет никакой информации и я собираюсь в первый раз встретиться с заказчиком. Мне нужно подготовиться к этой встрече. Желательно иметь готовый вопросник. С помощью этого вопросника необходимо получить максимум информации от заказчика. После этой встречи и анализа ответов я уже сам буду формулировать уточняющие вопросы.
Наверняка есть универсальные первые вопросы для любого будущего продукта. По ходу первой беседы я буду выбирать из вопросника наиболее подходящее вопросы.Я думаю, что у хорошего аналитика есть готовый шаблон. Не держать же это все в голове (это не разумно). Если есть информация, то учитывая её можно брать вопросы из этого универсального шаблона вопросника и дополнять его с учётом информации о будущем продукте. В итоге будет готовый вопросник для конкретной встречи.
У меня нет никакой информации и я собираюсь в первый раз встретиться с заказчиком.
При такой встрече я бы большую часть внимания уделила организационным вопросам: определение ролей на проекте (в том числе, к кому обращаться с вопросами, кому отправлять документы на валидацию, кто является decision maker-ом и т.п.), какие артефакты ожидаются на выходе и где они должны храниться, как будет происходить коммуникация (по почте, по телефону, при личном общении и т.п.) и когда (можно, например, договориться о еженедельной встрече с обсуждением текущего статуса), примерные сроки выполнения проекта и любые другие волнующие вас вопросы о процессе работы над требованиями. Также стоит узнать, существуют ли какие-либо документы, которые могут оказаться вам полезными (это могут быть зачатки спецификаций или спецификации старой системы, письма с требованиями, макеты, подготовленные дизайнером и т.д. и т.п., как правило, что-то да найдется).
Потом я бы попросила заказчика рассказать о проекте в общих чертах: заранее вопросы подготовить может быть и проблематично, поэтому всегда можно их задавать по ходу дела.
А вот ко второй встрече, изучив полученные артефакты и переварив первую беседу, можно подготовить список вопросов, специфичный именно для этого домена и проекта.И так-с. Продолжим-с.
Вот такие вопросы я накопал. Что скажите? Может их лучше сгруппировать-классифицировать?
Вопросы:
Зачем вам нужно это ПО?
Кто является пользователем системы?
Кем это будет использоваться?
Кто является заказчиком (экономическим покупателем) системы?
Кто будет оценивать и принимать систему, когда она будет представлена и развернута?
Существую другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?
Кто будет заниматься сопровождением новой системы?
Не забыли ли мы кого-нибудь?
Для чего, для кого и в какие сроки должна быть разработано ПО?
Почему вам это надо делать?
Для чего вы это делаете?
Кто и что должен делать?
Какие задачи должна решать необходимое вам ПО?
Что вы хотите, чтобы вы могли делать?
Что вы хотите достичь?
Что должно делать ПО?
Что делается неэффективно?
Что должно быть улучшено?
Без чего нельзя обойтись?
Что мы подаём на вход?
Откуда вы возьмете эти данные?
Что мы должны получить на выходе?
На кого ещё окажут влияния результаты работы системы?
Что будет, если этого не сделать?Конечно можно дополнять, заменять на более грамотные вопросы и пр. вносить улучшения.
Вопрос по названию ПО тоже надо включить? Хотя бы иметь предварительное название.
Вы должны авторизироваться для ответа в этой теме.
