сбор требований

Смотрите обязательный комикс ниже...

В общем, я пытаюсь почувствовать бизнес-модель, которую мой клиент/клиент пытается эмулировать с помощью приложения, которое они хотят построить. Создаем ли мы прославленный процессор форм? Получаем ли мы данные из нескольких источников в одном приложении, чтобы сэкономить время? Мы осуществляем какую-то интеграцию?

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

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

Один вопрос, который я всегда обязательно задаю в той или иной форме: "что самое сложное/самое раздражающее, что вы должны делать, когда делаете X. Как правило, ответ на этот вопрос раскрывает самое сумасшедшее правило бизнеса/данных, которое вам придется реализовать.

Надеюсь, это поможет!

Вы почти наверняка что-то упускаете. Наверное, очень многое. Не волнуйся, все в порядке. Даже если вы все запомнили и охватили все основания, заинтересованные стороны не смогут дать вам очень хорошие, четкие требования без какой-либо точки отсчета. Лучший способ сделать это-получить от них то, что вы можете сейчас, а затем взять это и дать им что-то, на что они могут реагировать. Это может быть бумажный прототип, макет, версия 0.1 программного обеспечения, что угодно. Тогда они могут начать говорить вам, чего они действительно хотят.

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

Сбор требований невероятно сложен из-за того, как работает коммуникация. Это четырехэтапный процесс, который теряется на каждом этапе.

• У меня есть идея в голове
• Я превращаю это в слова и картинки
• Вы интерпретируете картинки и слова
• Вы рисуете в своем воображении образ того, какой была моя первоначальная идея

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

Agile делает все правильно, поощряя итеративное развитие. Получение ранних версий для клиента важно в определении того, какие функции являются наиболее важными (что поставляется в 0.1 - 0.5 ish), помогает держать вас обоих на правильном пути с точки зрения того, как приложение будет работать и быстро выявляет скрытые функции, которые вы пропустите.

Два основных сценария проблем - это два конца шкалы:

• Не имея ни малейшего понятия о том, что вы делаете - получите несколько экспертов по доменам
• Имея слишком много требований -особенность ямы. - Вопрос, отбраковка (приоритизация ;) ) функций и использование итеративной разработки

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

Особенность ямы - это другая сторона, в основном полная неудачных правительственных проектов IT. Слишком много, слишком рано, недостаточно продумано или применено реализма (но что вы ожидаете, что у них есть только около четырех лет, чтобы почувствовать себя важными?). Цель здесь состоит в том, чтобы выяснить, чего на самом деле хочет клиент. До тех пор, пока вы работаете над правильностью основных компонентов, эффективные и безошибочные клиенты обычно остаются терпимыми к отсутствующим функциям, которые прибывают в более поздние поставки, пока они в конечном итоге прибывают. Именно здесь итеративная разработка действительно помогает.

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

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

Ого, с чего начать?

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

Во-вторых, существуют различные виды требований.

• Цели: Чего хочет достичь пользователь?
• Функционал: что нужно сделать пользователю, чтобы достичь своей цели? (подумайте шаги, чтобы достичь objective/s)
• Нефункциональный: каковы ограничения, необходимые для выполнения вашей программы? (подумайте о 10 против 10 тысяч одновременных пользователей, росте, резервном копировании и т. д.)
• Бизнес-правила: какие динамические ограничения вы должны соблюдать? (подумайте о расчетах, определениях, юридических проблемах и т. д.)

В-третьих, способ наиболее эффективно собрать требования, а затем получить обратную связь по ним (что вы и будете делать, верно?) заключается в использовании моделей. Пользовательские кейсы и истории пользователей-это модель того, что должен делать пользователь. Модели процессов - это еще одна версия того, что должно произойти. Системные диаграммы - это всего лишь еще одна модель взаимодействия различных частей программы(программ). Хорошее моделирование данных определит бизнес-концепции и покажет вам входы, выходы и изменения, которые происходят в вашей программе. Модели (а их больше, чем я перечислил) действительно являются ключом к тому, что вы перечисляете. Несколько хороших моделей будут отражать потребности, и из моделей вы можете определить свои требования.

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

Как бы я ни ценил требования и модели, которые ими управляют, пользователи обычно не понимают последствий всех своих запросов. Постоянное общение с шансами на обзор и обратную связь даст пользователям лучшее понимание того, что вы предоставляете. Далее, они будут совершенствовать свое понимание, основанное на том, что они видят. Если вы не работаете на правительство, итерации и / или прототипы полезны.

Прежде всего соберите требования, прежде чем начать кодирование. Вы можете начать проектирование в то время как вы собираете их в зависимости от вашего жизненного цикла проекта, но вы никогда не должны начинать кодирование без них.

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

Требования должны быть проверяемыми. Если требование не может быть проверено, то это не требование. Это означает что-то вроде: "система "

Требования должны быть конкретными. Это означает, что утверждение "The system user interface shall be easy to use" не является правильным требованием.

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

Проводите встречи с клиентом во время разработки требований. Опишите их клиенту своими словами и убедитесь, что вы и клиент имеете одинаковую концепцию в требованиях.

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

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

Вы никогда не можете задавать слишком много или "stupid" вопросов. Чем больше вопросов вы задаете, тем больше ответов получаете.

По мнению Стива Йегге, это неправильный вопрос . Если вы собираете требования, то уже слишком поздно, ваш проект обречен.

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

2. Прослушайте один абзац описания системы, выбейте его

3. Макет UI

4. Формализовать известные требования

5. Теперь повторите между 3 и 4 с более функциональными прототипами и более подробными спецификациями. Пишите тесты по ходу дела. Делайте это до тех пор, пока у вас не будет функционального программного обеспечения и полной, объективной, тестируемой спецификации требований.

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

Сбор Бизнес-Требований-Это Чушь Собачья - Стив Егге

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

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

Потому что мы все люди, и нам не свойственно помнить каждую мучительную деталь. Вы повышаете вероятность обнаружения пропущенных требований по мере общения с большим количеством людей и перекрестной проверки.

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

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

• прочитайте манифест agile-рабочее программное обеспечение-это единственное измерение успеха программного проекта
• познакомьтесь с agile программными практиками-изучите Scrum , бережливое Программирование, xp и т. д.-Это сэкономит вам огромное количество времени не только на сбор требований, но и на весь жизненный цикл разработки программного обеспечения
• ведите регулярные дискуссии с клиентами и особенно с будущими пользователями и ключевыми пользователями
• убедитесь, что вы говорите с людьми, понимающими предметную область проблемы, например : специалисты в данной области
• Делайте небольшие заметки во время переговоров
• После каждого CONVERSATION напишите официальный список требований и представьте его на утверждение. Впоследствии будет трудно оспорить все согласованные документы
• убедитесь, что ваши клиенты приблизительно знают, каковы приблизительные затраты времени и денег на реализацию требований "nice to have"
• убедитесь, что вы обозначили требования как "must have", "should have" и "nice to have" с самого начала, убедитесь, что клиенты также понимают различия между этими типами
• интегрируйте все документы в последний и окончательный анализ требований (или текущий для итерации или любого другого цикла программирования agile, который вы используете ... )
• помните, что требования меняются в течение жизненного цикла программного обеспечения , поэтому сбор данных-это одно, а управление и реализация-другое
• KISS-держите его как можно более простым
• изучите также среду , в которой будет находиться будущая система - там все больше и больше технологических ограничений от унаследованных или окружающих систем, поскольку компании не предпочитают выбрасывать на помойку деньги, которые они инвестировали десятилетиями, даже если в нашем современном сознании 20-летний код является мусором ...

Как и большинство этапов процесса разработки программного обеспечения, его итерация работает лучше всего.

Сначала выясните, кто ваши пользователи -- отдел XYZ,

Затем выясните, как они вписываются в организацию-часть отдела Z,

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

Затем в определенных терминах-соберите наличные из касс и проверьте на мошенничество в кассах.

Тогда вы можете начать говорить с ними.

Спросите, Какую проблему они хотят, чтобы вы решили - вы получите ответ, Как написать систему надувательства, используя OCR с shark technoligies.

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

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

Затем подробно договоритесь, как они будут измерять успех проекта.

Тогда и только тогда предложите и согласуйте детальный набор требований.

Я бы посоветовал вам прочитать " Программная инженерия Роджера-Прессмана : подход практикующего специалиста".

Прежде чем вы пойдете разговаривать с stakeholders/users/anyone, убедитесь, что вы сможете записать собранную информацию полезным и долговечным способом.

• Используйте звукозаписывающее устройство, если это OK с другим человеком, и информация является громоздкой.
• Если вы услышали что-то важное и вам нужно некоторое разумное время, чтобы записать это, у вас есть два варианта: попросить другого человека подождать секунду или попрощаться с этой драгоценной информацией. Вы не запомните его правильно, спросите любого нейробиолога.
• Если вы обнаружите, что какой-то пункт нуждается в более глубоком рассмотрении или что вам нужен какой-то документ, о котором вы только что слышали, убедитесь, что вы договорились с другим человеком отправить этот документ или запланировать другую встречу с более конкретной целью. Никогда не говорите "I'll remember to ask for that xls file", потому что в большинстве случаев вы этого не сделаете.
• Чтобы не задерживаться долго после встречи, суммируйте все свои заметки, записи и свежие мысли. Просто суммировать его право. Создавайте эффективные напоминания о принятых обязательствах.
• Опять же, сразу после собрания, это идеальное время, чтобы понять, почему собрание, которое вы только что сделали, было не таким правильным, как вы думали в конце собрания. Именно тогда вы сможете задать много значимых вопросов для следующей встречи.

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

Я использую ментальное отображение (например, структуру разбивки работы), чтобы помочь собрать требования и определить неизвестные (убийца проекта #1). Начните с высокого уровня и пройдите свой путь вниз. Вам нужно работать со спонсорами, пользователями и командой разработчиков, чтобы убедиться, что вы получите все углы и ничего не пропустите. Нельзя ожидать, что вы будете знать весь объем того, что они хотят, без их involvement...you - как менеджера проекта/BA - необходимости вовлечь их (самая важная часть работы).

Я предпочитаю, чтобы мой процесс сбора требований был максимально простым, прямым и тщательным. Вы можете скачать образец документа, который я использую в качестве шаблона для своих проектов, на этой странице блога: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html

Недавно я начал использовать концепции, стандарты и шаблоны, определенные организацией International Institute of Business Analysis organization ( IIBA ).

У них есть довольно хорошая BOK (Книга знаний), которую можно скачать с их сайта. У них тоже есть сертификат.

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

http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html

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

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

• LM

Проектирование требований-это своего рода искусство, существует множество различных способов его реализации, вы действительно должны адаптировать его к своему проекту и вовлеченным в него заинтересованным сторонам. Хорошее место для начала - это разработка требований Карлом Вигерсом:

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?т. е.=UTF8&s=books&qid=1234910330&sr=8-2

а также процесс разработки требований, который может состоять из нескольких этапов, например::

• Выявление-за основу для обсуждения с бизнесом
• Анализ и описание-техническое описание для целей разработчиков
• Разработка, уточнение, проверка и согласование-дальнейшее уточнение требований

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

Я вообще считаю, что написание набора вариантов использования и включение прототипов каркасов хорошо работает для определения начального набора требований. С этого момента это непрерывный процесс работы с техническими специалистами и деловыми людьми для дальнейшего уточнения и уточнения требований. Отслеживание того, что было первоначально согласовано, и отслеживание дополнительных требований имеют важное значение для предотвращения ползучести охвата. Переговоры играют здесь также небольшую роль между различными сторонами в соответствии с ломаным железным треугольником (http://www.ambysoft.com/essays/brokenTriangle.html).

ИМО самый важный первый шаг - это создание словаря доменных слов. Когда ваш клиент говорит "order", что он имеет в виду? Что - то он получает от своих клиентов или что-то посылает своим поставщикам? Или может обе?

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