|
Интервью с заказчиком
Формальные или неформальные беседы с заинтересованными сторонами системы являются частью многих инженерных процессов. В ходе этих интервью группа инженеров по связям задает заинтересованным сторонам вопросы о системе, которую они используют в настоящее время, и о разрабатываемой системе. Требования вытекают из ответов на эти вопросы. Собеседование может быть двух видов:
Закрытые интервью, в которых заинтересованная сторона отвечает на заранее определенные вопросы.
Открытые разговоры без заранее определенной повестки дня. Команда инженеров по запросу изучит ряд вопросов с заинтересованными сторонами системы и, таким образом, лучше поймет их потребности.
На практике беседы с заинтересованными сторонами обычно представляют собой смесь того и другого. Возможно, вам придется ответить на конкретные вопросы, но это обычно приводит к другим проблемам, которые обсуждаются менее структурировано. Полностью открытые обсуждения редко работают хорошо. Обычно вам нужно задать несколько вопросов, чтобы начать разговор и сосредоточить разговор на разрабатываемой системе.
Интервью хороши для получения общего представления о том, что могут сделать заинтересованные стороны, как они будут взаимодействовать с новой системой и с какими проблемами они столкнутся при работе с текущими системами. Люди любят говорить о своей работе, и поэтому они обычно с удовольствием участвуют в интервью. Однако если у вас нет прототипа системы для установки, не стоит ожидать, что заинтересованные стороны предложат четкие и подробные требования . Кому-то трудно представить, на что может быть похожа эта система. Вам необходимо проанализировать собранные данные и разработать на их основе требования.
Получение знаний в предметной области через собеседование может быть затруднено по двум причинам:
Специалисты во всех приложениях используют жаргон, характерный для их сферы деятельности. Они не могут обсуждать требования домена, не используя эту терминологию . Обычно они четко и тонко используют слова, которые могут быть неправильно поняты инженерами.
Некоторые знания в предметной области настолько знакомы заинтересованным сторонам, что их может быть трудно им объяснить, или они считают их настолько важными, что нет необходимости упоминать об этом . Например, для библиотекаря само собой разумеется, что все запросы AC были каталогизированы перед добавлением в библиотеку. Однако это может быть неясно интервьюируемому и поэтому не учитывается в требованиях.
Интервьюирование — неэффективный способ узнать о требованиях и ограничениях организации, потому что между разными людьми в организации существуют тонкие отношения власти. Опубликованные организационные структуры редко соответствуют реальности принятия решений в организации, но интервьюируемые могут не захотеть раскрывать незнакомцу реальную структуру, а не теоретическую структуру. В целом многие неохотно обсуждают политические и организационные вопросы, которые могут повлиять на требования.
Чтобы быть эффективным собеседником, вам нужно помнить о двух вещах:
Вы должны быть непредубежденными, избегать предвзятых мнений о требованиях и быть готовыми слушать заинтересованные стороны. Если заинтересованная сторона выдвигает неожиданные требования, вы должны быть готовы изменить свое мнение о системе.
вы должны предложить вопрос и ответ или запросить предложение или обсуждение, работая вместе над прототипом системы . Говоря людям «скажи мне, чего ты хочешь», вряд ли можно получить полезную информацию. Им легче говорить в конкретном контексте, чем в общем смысле.
Используются данные интервью, наряду с другой информацией о системе, документами, описывающими бизнес-процессы или существующие системы, наблюдениями пользователей, опытом разработчиков . Иногда, кроме информации в системных документах, информация из интервью может быть единственным источником информации о системных требованиях. Однако собеседование само по себе может упустить важную информацию, поэтому его следует использовать в сочетании с другими методами определения требований.
требований — это процесс, когда группа людей, являющихся заказчиком системы и разработчиком системы , подробно читает документ с требованиями и проверяет наличие ошибок, аномалий и несоответствий. После того, как они были идентифицированы и зарегистрированы, клиент и разработчик должны обсудить, как решить выявленные проблемы.
Do'stlaringiz bilan baham: |
