Сбор требований к программному обеспечению является основой всего проекта разработки программного обеспечения. Выявление и сбор требований бизнеса является важным первым шагом для каждого проекта. Чтобы устранить разрыв между бизнес-требованиями и техническими требованиями, бизнес-аналитики должны полностью понимать бизнес-потребности в заданном контексте, согласовывать их с бизнес-целями и должным образом сообщать о них заинтересованным сторонам и команде разработчиков.
Ключевые заинтересованные стороны хотят, чтобы кто-то мог объяснить требования клиента / клиента простым языком. Будет ли это полезным для них от понимания ценности на высоком уровне? Это будет основной областью, так как они попытаются сопоставить документацию с требованиями и тем, как BA может общаться наилучшим образом.
Почему проекты терпят неудачу
Есть много причин, почему проекты терпят неудачу, но некоторые из общих областей включают следующее —
- Сбой рынка и стратегии
- Организационные и плановые сбои
- Сбои качества
- Лидерство и неудачи в управлении
- Навыки, Знания и недостатки компетенции
- Помолвка, работа в команде и сбои связи
Суть проблемы заключается в том, что проекты становятся все более сложными, происходят изменения и общение является сложной задачей.
Почему успешные команды делают управление требованиями
Управление требованиями подразумевает синхронизацию вашей команды и предоставление информации о том, что происходит внутри проекта.
Для успеха ваших проектов крайне важно, чтобы вся ваша команда понимала, что вы строите и почему — именно так мы определяем управление требованиями. «Почему» важно, потому что оно обеспечивает контекст для целей, обратной связи и решений, принимаемых в отношении требований.
Это повышает предсказуемость будущего успеха и потенциальных проблем, позволяя вашей команде быстро исправить любые проблемы и успешно завершить ваш проект в срок и в рамках бюджета. Для начала важно, чтобы все участники имели общее представление о том, что такое требования и как их выполнять.
Начнем с основ
Требование — это условие или способность, необходимые заинтересованному лицу для решения проблемы или достижения цели. Состояние или способность, которой должна соответствовать система или система. Компонент для удовлетворения контракта, стандарта, спецификации или других формально наложенных документов.
Требование может быть выражено с помощью текста, эскизов, подробных макетов или моделей, независимо от того, какая информация лучше всего сообщается инженеру, что строить, и менеджеру по контролю качества, что тестировать. В зависимости от процесса разработки вы можете использовать различные термины для сбора требований.
Требования высокого уровня иногда называют просто потребностями или целями . В практике разработки программного обеспечения требования могут упоминаться как «варианты использования», «функции» или «функциональные требования». Более конкретно, в методологиях гибкой разработки требования часто отражаются в эпосах и историях .
Независимо от того, как их называет ваша команда или каким процессом вы пользуетесь; Требования необходимы для разработки всех продуктов. Без четкого определения требований вы можете получить неполный или бракованный продукт. На протяжении всего процесса может быть много людей, участвующих в определении требований.
Заинтересованная сторона может запросить функцию, которая описывает, как продукт будет обеспечивать ценность при решении проблемы. Разработчик может определить требование на основе того, как конечный продукт должен выглядеть или работать с точки зрения удобства использования или пользовательского интерфейса.
Бизнес-аналитик может создать системное требование, соответствующее конкретным техническим или организационным ограничениям. Для создания современных сложных продуктов и программных приложений часто требуются сотни или тысячи требований, чтобы в достаточной мере определить объем проекта или выпуска. Таким образом, обязательно, чтобы команда имела возможность получать доступ, сотрудничать, обновлять и тестировать каждое требование до его завершения, поскольку требования естественным образом изменяются и развиваются с течением времени в процессе разработки.
Теперь, когда мы определили ценность управления требованиями на высоком уровне, давайте углубимся в четыре основных принципа, которые каждый член команды и заинтересованное лицо может извлечь выгоду из понимания —
- Планирование хороших требований: «Какого черта мы строим?»
- Совместная работа и вступительный взнос: «Просто одобрите спецификацию, уже!»
- Отслеживание и управление изменениями: «Подождите, разработчики знают, что изменилось?»
- Гарантия качества: «Здравствуйте, кто-нибудь проверял эту вещь?»
Все знают, что мы строим и почему? Это ценность управления требованиями.
Сотрудничество и бай-ин от заинтересованных сторон
Все в курсе? Есть ли у нас одобрение требований для продвижения вперед? Эти вопросы возникают во время циклов разработки. Было бы здорово, если бы каждый мог договориться о требованиях, но для крупных проектов со многими заинтересованными сторонами это обычно не происходит. Попытка договориться со всеми может привести к тому, что решения будут отложены или, что еще хуже, вообще не приняты. Добиться консенсуса по каждому решению не всегда легко.
На практике вам не обязательно нужен «консенсус», вы хотите «вступительный взнос» от группы и одобрение со стороны контролирующих, чтобы вы могли продвигать проект вперед. С консенсусом вы пытаетесь заставить всех пойти на компромисс и согласиться с решением. С бай-ином вы пытаетесь заставить людей поддержать лучшее решение, принять разумное решение и сделать все необходимое для продвижения вперед.
Вам не нужно, чтобы все соглашались с тем, что решение является лучшим. Вам нужно, чтобы все поддержали это решение. Совместная работа команды может помочь в получении поддержки при принятии решений и в планировании хороших требований.
Коллективные команды усердно работают, чтобы убедиться, что каждый заинтересован в проектах и обеспечивает обратную связь. Коллективные группы постоянно обмениваются идеями, обычно лучше общаются и, как правило, поддерживают принятые решения, потому что существует общее чувство приверженности и понимания целей проекта.
Именно тогда, когда разработчики, тестировщики или другие заинтересованные стороны чувствуют себя «не в курсе», возникают проблемы с коммуникацией, люди разочаровываются, а проекты задерживаются. После того, как все согласились с объемом работ, необходимо, чтобы требования были четкими и хорошо документированными. Отслеживание всех требований — вот где все становится сложнее.
Представьте себе список дел длиной в милю, который включает в себя сотрудничество с несколькими людьми для завершения. Как бы вы сохранили все эти вещи прямо? Как бы вы отследили, как одно изменение элемента повлияет на остальную часть проекта? Именно здесь прослеживаемость и управление изменениями повышают ценность.