Сбор требований
Как вы проходите этап сбора требований? У кого-нибудь есть хороший набор рекомендаций или советов для подражания? Какие хорошие вопросы нужно задать заинтересованным лицам?
В настоящее время я работаю над новым проектом, и там много неизвестных. Я нахожусь в процессе составления списка вопросов, которые могут быть заданы заинтересованным сторонам. Однако я не могу помочь, но чувствую, что что-то упустил или забыл задать критический вопрос.
20 ответов
Вы почти наверняка что-то упустили. Многое, наверное. Не волнуйся, все в порядке. Даже если вы запомнили все и охватили все основы, заинтересованные стороны не смогут дать вам очень хорошие, четкие требования без каких-либо указаний. Лучший способ сделать это - получить то, что вы можете от них сейчас, затем взять это и дать им что-то, на что можно реагировать. Это может быть бумажный прототип, макет, версия 0.1 программного обеспечения, что угодно. Тогда они могут начать говорить вам, чего они действительно хотят.
Смотрите обязательный комикс ниже...
В общем, я пытаюсь понять бизнес-модель, которую мой клиент / клиент пытается эмулировать с приложением, которое они хотят построить. Создаем ли мы прославленный процессор форм? Получаем ли мы данные из нескольких источников в одном приложении, чтобы сэкономить время? Мы выполняем какую-то интеграцию?
Как только общая бизнес-модель установлена, я перехожу к "must" и "must nots", чтобы приложение диктовало, какие данные я могу получить, кто может выполнять какие функции и т. Д.
Обычно, если вы можете заставить клиента объяснить свою модель или рабочий процесс, вы можете перейти оттуда и найти дополнительные ключевые вопросы.
Единственный вопрос, который я всегда задаю в той или иной форме: "Какова самая хитрая / самая раздражающая вещь, которую вы должны делать при выполнении X. Как правило, ответ на этот вопрос раскрывает самое сумасшедшее правило для бизнеса / данных, которое вы должны реализовать,
Надеюсь это поможет!
Стив Йегге говорит весело, но есть деньги, чтобы выяснить, каковы требования других людей, поэтому я взял бы его статью с щепоткой соли.
Сбор требований невероятно сложен из-за того, как работает коммуникация. Это четырехступенчатый процесс с потерями на каждом этапе.
- У меня в голове идея
- Я превращаю это в слова и картинки
- Вы интерпретируете картинки и слова
- Вы рисуете в своем воображении образ моей первоначальной идеи
И люди терпят неудачу в этом с тревожной частотой из-за своих прелестных недостатков.
Agile правильно продвигает итеративную разработку. Передача ранних версий клиенту важна для определения того, какие функции наиболее важны (какие поставляются в диапазоне от 0,1 до 0,5), помогает держать вас на правильном пути с точки зрения работы приложения и быстро выявлять скрытые функции, ты будешь скучать
Два основных сценария проблемы - это два конца шкал:
- Не имея ни малейшего понятия о том, что ты делаешь - найди экспертов по предметной области
- Слишком много требований - особенность ямы. - Вопрос, отбор (приоритеты;)) функций и использование итеративной разработки
Yegge преуспевает в том, что указывает, что эксперты в предметной области необходимы для выработки хороших требований, потому что они знают бизнес и работают в нем. Они могут помочь определить основное желание клиента и объяснить, как их сотрудники будут использовать систему и что важно для персонала. Альтернативы и дополнения включают в себя попытку выполнить работу самостоятельно, чтобы прийти в сознание, или время от времени иметь сотрудника клиента на месте, хотя последнее вряд ли произойдет.
Функциональная яма - другая сторона, в основном полная провальных правительственных ИТ-проектов. Слишком много, слишком рано, недостаточно мысли или применения реализма (но что вы ожидаете, что у них есть только около четырех лет, чтобы почувствовать себя важными?). Целью здесь является выяснить, что клиент действительно хочет. Пока вы работаете над созданием правильных основных компонентов, эффективные и безошибочные клиенты обычно остаются терпимыми к отсутствующим функциям, которые поступают в более поздних поставках, пока они в конечном итоге поступают. Вот где итеративная разработка действительно помогает.
Не забудьте отделить представления клиента о том, на что будет похожа программа и чего он хочет достичь. Некоторые клиенты могут создавать путаницу, сообщая свои требования в форме функций приложения, которые могут быть плохо продуманными или излишними из-за гораздо более простой функциональности, чем они думают, что они требуют. Хотя я не призываю называть клиента идиотом или не слушать его, я чувствую, что стоит навсегда спросить, почему они хотят, чтобы конкретная функция достигла своей основной цели.
Помните, что в любом из сценариев крайне важно найти самый быстрый путь для удовлетворения основных потребностей клиентов и поставить вас в сценарий, в котором вы оба получаете выгоду от отношений.
Вау, с чего начать?
Во-первых, есть набор знаний, которые кто-то должен будет сделать для анализа некоторых проектов, но это действительно зависит от того, для кого вы строите. Другими словами, это имеет большое значение, если вы изменяете корпоративное приложение для корпорации Fortune 100, создаете приложение для iPhone или добавляете функциональность на личную веб-страницу.
Во-вторых, существуют различные виды требований.
- Цели: чего хочет достичь пользователь?
- Функциональный: Что нужно сделать пользователю, чтобы достичь своей цели? (подумайте шаги для достижения цели / с)
- Не работает: какие ограничения должна выполнять ваша программа? (например, 10 против 10 тыс. одновременных пользователей, рост, резервное копирование и т. д.)
- Бизнес-правила: с какими динамическими ограничениями вы должны встретиться? (подумайте, расчеты, определения, юридические проблемы и т. д.)
В-третьих, наиболее эффективным способом сбора требований и получения отзывов о них (что вы будете делать, верно?) Является использование моделей. Пользовательские случаи и пользовательские истории - это модель того, что пользователь должен делать. Модели процессов - это еще одна версия того, что должно произойти. Системные диаграммы - это просто еще одна модель взаимодействия различных частей программы. Хорошее моделирование данных определит бизнес-концепции и покажет вам входы, результаты и изменения, которые происходят в вашей программе. Модели (а их больше, чем я перечислил) действительно являются ключом к вашей заботе. Несколько хороших моделей будут отражать потребности, а по моделям вы сможете определить свои требования.
В-четвертых, получите обратную связь. Я знаю, что уже упоминал об этом, но с первого раза у вас все не получится, так что получайте ответы на то, что хочет ваш клиент.
Как бы я ни ценил требования и модели, которые ими управляют, пользователи обычно не понимают последствий всех своих запросов. Постоянное общение с возможностью просмотра и обратной связи даст пользователям лучшее понимание того, что вы предлагаете. Кроме того, они будут улучшать свое понимание на основе того, что они видят. Если вы не работаете на правительство, полезны итерации и / или прототипы.
Прежде всего соберите требования, прежде чем начать кодирование. Вы можете начать проектирование, собирая их в зависимости от жизненного цикла вашего проекта, но вам никогда не следует начинать кодировать без них.
Требования - это набор хорошо написанных документов, которые защищают как клиента, так и вас самих. Никогда этого не забывай. Если требования отсутствуют, то за них не было оплачено (и, следовательно, требуется официальный запрос на изменение), если они есть, то они должны быть реализованы и работать правильно.
Требования должны быть проверяемыми. Если требование не может быть проверено, то это не требование. Это означает что-то вроде "Система"
Требования должны быть конкретными. Это означает, что указание "Системный пользовательский интерфейс должен быть прост в использовании" не является правильным требованием.
Чтобы на самом деле "собрать" требования, вам необходимо сначала убедиться, что вы понимаете модель бизнеса. Клиент скажет вам, чего он хочет своими словами, это ваша работа, чтобы понять это и интерпретировать это в правильном контексте.
Проводите встречи с клиентом, пока вы разрабатываете требования. Опишите их клиенту своими словами и убедитесь, что у вас и клиента одинаковая концепция в требованиях.
Требования требуют краткого, проверяемого примера, но следите за всем, что встречается на собраниях, диаграммах, сомнениях и старайтесь вести записи каждого собрания.
Если вы можете использовать инкрементальный жизненный цикл, это даст вам возможность улучшить некоторые плохо собранные требования.
Вы никогда не можете задавать слишком много или "глупых" вопросов. Чем больше вопросов вы задаете, тем больше ответов получаете.
По словам Стива Йегге, это неправильный вопрос. Если вы собираете требование, уже слишком поздно, ваш проект обречен.
Обсуждения на высоком уровне о цели, сфере применения, ограничениях операционной среды, размере и т. Д.
Прослушайте единый параграф описания системы, выбейте его
Макет пользовательского интерфейса
Формализовать известные требования
Теперь итерируйте от 3 до 4, получая все больше функциональных прототипов и больше спецификаций с большим количеством деталей. Пишите тесты, как вы идете. Делайте это, пока у вас не будет функционального программного обеспечения и полной, объективной, проверяемой спецификации требований.
Это мечта. Реальность обычно заключается в том, что после пары итераций все идут наперекосяк и кодируют, пока не останется месяц для тестирования.
- Прочитайте проворный манифест - работающее программное обеспечение является единственным измерением успеха программного проекта
- познакомьтесь с практиками гибкого программного обеспечения - изучите Scrum, бережливое программирование, xp и т. д. - это сэкономит вам огромное количество времени не только для сбора требований, но и для всего жизненного цикла разработки программного обеспечения.
- ведите регулярные обсуждения с Заказчиками и особенно с будущими пользователями и ключевыми пользователями
- Обязательно поговорите с людьми, понимающими проблемную область - например, со специалистами в этой области.
- Делайте небольшие заметки во время переговоров
- После каждой беседы напишите официальный список требований и представьте его на утверждение. В дальнейшем будет сложно поспорить против всех согласованных документов.
- Удостоверьтесь, что ваши клиенты приблизительно знают, каковы приблизительные затраты времени и денег на выполнение требований "приятно иметь"
- Убедитесь, что вы помечаете требования как "должны иметь", "должны иметь" и "приятно иметь" с самого начала, убедитесь, что клиенты также понимают различия между этими типами
- интегрировать все документы в последний и окончательный анализ требований (или текущий для итерации или любого цикла гибкого программирования, который вы используете...)
- Помните, что требования меняются в течение жизненного цикла программного обеспечения, поэтому сбор - это одно, а управление и реализация - другое.
- ПОЦЕЛУЙ - делай как можно проще
- изучите также среду, в которой будет находиться будущая система - все больше и больше технологических ограничений от устаревших или окружающих систем, поскольку компании не предпочитают выбрасывать в мусор деньги, которые они вложили десятилетиями, даже если в нашем современном сознании 20 лет старый код мусор...
Как и большинство этапов процесса разработки программного обеспечения, его итерация работает лучше всего.
Сначала выясните, кто ваши пользователи - отдел XYZ,
Затем выясните, где они вписываются в организацию - часть подразделения Z,
Тогда узнайте, что они делают в общих чертах - управляйте наличными
Затем в определенные сроки - собирать наличные с кассы и проверять на наличие мошенничества.
Тогда вы можете начать говорить с ними.
Спросите, какую проблему они хотят, чтобы вы хотели решить, - вы получите ответ, например, напишите ошеломляющую систему, используя OCR с технологиями акул.
Игнорируйте этот ответ и задайте еще несколько вопросов, чтобы выяснить, в чем заключается настоящая проблема - они не могут прочитать квитанции, чтобы примирить деньги.
Согласуйте реальное решение с пользователями - найдите лучшего поставщика красящей ленты - или подключите электронные счета к сети и загрузите журналы на центральный сервер.
Затем детально договоритесь, как они будут измерять успех проекта.
Тогда и только тогда предложите и согласуйте подробный набор требований.
Я бы посоветовал вам прочитать " Разработка программного обеспечения Роджера-Прессмана : подход практикующего"
Здесь уже есть отличные идеи. Вот некоторые принципы сбора требований, которые я всегда хотел бы иметь в виду:
Знайте разницу между пользователем и клиентом. Владельцы бизнеса, которые одобряют блестящий проект, обычно являются клиентами. Однако разрушительной ошибкой является тенденция запутать их как пользователя. Заказчиком обычно является человек, который осознает потребность в вашем продукте, но пользователь - это человек, который фактически будет использовать решение (и, скорее всего, позже будет жаловаться на требование, которое ваш продукт не выполнил). Перейти к более чем одному человеку
Потому что мы все люди, и мы склонны не помнить каждую мучительную деталь. Вы повышаете вероятность обнаружения пропущенных требований, когда общаетесь с большим количеством людей и перепроверяете.
Избегайте специальных предложений Когда пользователь просит что-то очень конкретное, будьте осторожны. Всегда сомневайтесь в предвзятости и посмотрите, действительно ли это улучшит ваш продукт.
Прототип Не ждите до запуска, чтобы показать, что у вас есть для пользователя. Делайте частые прототипы (вы можете даже назвать их бета-версиями) и получайте постоянную обратную связь на протяжении всего процесса разработки. Вы, вероятно, найдете больше требований, как вы делаете это.
Я использовал сопоставление разума (например, структуру разбивки работ), чтобы помочь собрать требования и определить неизвестных (убийца проекта № 1). Начните с высокого уровня и продолжайте свой путь вниз. Вам нужно поработать со спонсорами, пользователями и командой разработчиков, чтобы убедиться, что вы получаете все ракурсы и ничего не пропускаете. Нельзя ожидать, что вы будете знать весь объем того, что они хотят, без их участия... вы - как руководитель проекта /BA - должны вовлекать их (самая важная часть работы).
Прежде чем вы поговорите с заинтересованными сторонами / пользователями / кем-либо, убедитесь, что вы сможете записать собранную информацию полезным и длительным образом.
- Используйте диктофон, если с другим человеком все в порядке, а информация громоздка.
- Если вы услышали что-то важное и вам нужно некоторое разумное время, чтобы записать это, у вас есть два варианта: попросить другого подождать секунду или попрощаться с этой драгоценной информацией. Вы не помните это правильно, спросите любого нейро-ученого.
- Если вы обнаружите, что какой-то вопрос требует более глубокого изучения или вам нужен какой-то документ, о котором вы только что услышали, убедитесь, что вы обязуетесь вместе с другим человеком отправить этот документ или запланировать другое собрание с более конкретной целью. Никогда не говорите "я не забуду попросить этот файл xls", потому что в большинстве случаев вы этого не сделаете.
- Вскоре после встречи, подведите итог всем вашим заметкам, записям и свежим мыслям. Просто подведите итог. Создание эффективных напоминаний для обязательств.
- Опять же, сразу после собрания, это идеальное время, чтобы понять, почему собрание, которое вы только что провели, было не таким правильным, как вы думали в конце собрания. Вот тогда вы сможете поставить много значимых вопросов для другой встречи.
Я знаю, что вопрос был в перспективе предварительного собрания, но, пожалуйста, имейте в виду, что вы можете поработать над этим вопросом до собрания и в итоге получить очень полезное, полное и качественное собрание.
Я предпочитаю сделать процесс сбора требований максимально простым, прямым и тщательным. You can download a sample document that I use as a template for my projects at this blog posting: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html
Разработка требований - это немного искусство, есть много разных способов сделать это, вам действительно нужно адаптировать его к вашему проекту и заинтересованным сторонам. Хорошее место для начала - разработка требований Карлом Вигерсом:
и процесс разработки требований, который может состоять из нескольких этапов, например:
- Выявление - за основу для обсуждения с бизнесом
- Анализ и описание - техническое описание для целей разработчиков
- Разработка, уточнение, проверка и согласование - дальнейшее уточнение требований
Кроме того, существует ряд способов документирования требований (варианты использования, прототипы, спецификации, языки моделирования). У каждого есть свои преимущества и недостатки. Например, прототипы очень хороши для извлечения идей из бизнеса и обсуждения идей.
Я обычно нахожу, что написание набора вариантов использования и включение каркасных прототипов хорошо работает для определения начального набора требований. С этого момента это постоянный процесс работы с техническими и деловыми людьми для дальнейшего уточнения и уточнения требований. Отслеживание того, что было первоначально согласовано, и отслеживание дополнительных требований очень важны, чтобы избежать ползучести. Переговоры здесь играют небольшую роль и между различными сторонами в соответствии с "Сломанным железным треугольником" ( http://www.ambysoft.com/essays/brokenTriangle.html).
Недавно я начал использовать концепции, стандарты и шаблоны, определенные организацией Международного института бизнес-аналитиков ( IIBA).
У них есть довольно хорошая BOK (Книга Знаний), которую можно скачать с их сайта. У них также есть сертификат.
ИМО самый важный первый шаг - создать словарь доменных слов. Когда ваш клиент говорит "заказ", что он имеет в виду? Что-то, что он получает от своих клиентов или что-то, что он посылает своим поставщикам? Или может оба?
Найдите ключевые слова в бизнесе заинтересованных сторон и дайте им объяснить эти слова, пока вы не поймете их значение в процессе. Без этого вам будет трудно понять требования.
Я написал статью в блоге о подходе, который я использую:
http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html
в основном: вопросы, которые следует задавать вашему клиенту перед созданием их сайта.
Я должен добавить, что этот вопросник предназначен только для базовых сборок веб-сайтов - например, для веб-сайтов для бизнеса. совершенно другая история, если вы говорите о веб-программном обеспечении. хотя некоторые из них все еще актуальны (например, вопросы, касающиеся внешнего вида).
- LM