Небрежное отношение к разработке и управлению требованиями часто приводит к тому, что проекты по разработке программного обеспечения оказываются сложными или проваливаются. Вот десять распространенных ловушек, с которыми можно столкнуться, если не принимать требования всерьез. Я описываю симптомы, которые могут указывать на то, что вы стали жертвой одной из ловушек, а также некоторые возможные решения. Более подробную информацию обо всех этих ловушках можно найти в книге "Требования к программному обеспечению", 3-е издание, авторы Karl Wiegers и Joy Beatty.
Одним из предупреждающих признаков является то, что заинтересованные стороны ссылаются на "требования" без уточняющих прилагательных. У участников проекта могут быть разные ожидания относительно того, насколько подробными должны быть требования. Другой признак — пользователи предоставляют "требования", но разработчики все еще не уверены, что именно нужно создавать. При обсуждении, сосредоточенном исключительно на функциональности, можно упустить из виду другую важную информацию о требованиях.
Решения: Все участники проекта должны понимать основные концепции, терминологию и практику разработки требований. Я мыслю в терминах трех уровней требований (Рисунок 1). Бизнес-требования описывают высокоуровневые бизнес-цели организации или клиента, запрашивающего систему или продукт. Они отвечают на вопрос: Почему мы беремся за этот проект?
Рисунок 1: Три уровня требований к программному обеспечению
На втором уровне рассматриваются требования пользователей: что пользователи смогут делать с продуктом. Они могут быть зафиксированы в виде сценариев использования или пользовательских историй. Однако сами по себе сценарии использования не обеспечивают достаточной детализации, чтобы разработчики знали, что нужно разрабатывать. Поэтому бизнес-аналитик (BA) должен вывести конкретные функциональные требования к программному обеспечению из примеров использования. Разработчики не реализуют напрямую требования бизнеса или пользователей — они реализуют отдельные функциональные требования.
Другие типы знаний о требованиях включают атрибуты качества, бизнес-правила, ограничения проектирования и реализации, а также требования к внешнему интерфейсу. Изучите их все во время разработки, чтобы не упустить что-то важное. Многие из этих типов требований обычно включаются в спецификацию требований к программному обеспечению или SRS.
Одним из ранних признаков недостаточного вовлечения клиентов является то, что требования предоставляют не реальные пользователи, а их заменители — менеджеры, сотрудники отдела маркетинга или даже разработчики. Другим признаком является то, что разработчики вынуждены принимать многие решения по требованиям, не имея достаточной информации. Если ни один из классов пользователей продукта не внес свой вклад, кто-то будет недоволен результатом.
Решения: Стремитесь к сотрудничеству между представителями заказчика, BA и командой разработчиков. Начните с определения различных классов пользователей. Классы пользователей — это группы, которые отличаются по частоте использования продукта, используемым функциям, уровню привилегий или другим признакам. Затем определите индивидуальных чемпионов продукта, которые будут представлять определенные классы пользователей. Представители продукта собирают информацию от других членов своего класса пользователей, предоставляют требования пользователей BA, а также вносят свой вклад в атрибуты качества и приоритеты требований.
Ваши представители пользователей также могут просматривать письменные требования, оценивать прототипы и предоставлять обратную связь по постепенным релизам, как в agile-разработке. Стремитесь к постоянному взаимодействию с пользователями, а не только к проведению семинара или двух семинаров в начале проекта.
Еще один признак нечетких или неполных требований — отсутствие в SRS информации, необходимой разработчикам. Например, если вы не можете придумать тесты для проверки правильности выполнения каждого требования, значит, ваши требования определены нечетко. Конечным симптомом нечетких требований является то, что разработчики вынуждены задавать много вопросов BA или заказчикам, или им приходится догадываться о том, что на самом деле предполагается.
Решения: Избегайте использования субъективных и двусмысленных по своей сути слов при написании требований. Такие термины, как минимизировать, максимизировать, оптимизировать, быстрый, удобный для пользователя, интуитивный, надежный, улучшенный, эффективный и поддержка являются особенно уязвимыми выражениями.
Чтобы устранить двусмысленность, поручите команде, включающей представителей различных точек зрения, тщательно проанализировать требования. В число подходящих специалистов входят:
Прототипы делают требования более осязаемыми. Оценка прототипа — отличный способ прояснить пробелы в ваших знаниях и достичь общего понимания. Визуальные модели анализа, такие как диаграммы потоков данных, диаграммы взаимосвязей сущностей и диаграммы переходов состояний, предоставляют альтернативные представления требований, которые часто выявляют пробелы в знаниях.
Определите исключения, которые должна обрабатывать система, а также то, что пользователи должны делать с системой. Хорошие разработчики тратят много времени на написание кода для обнаружения, предотвращения и восстановления после всех вещей, которые могут пойти не так. Им и пользователям очень помогает, если бизнес-аналитик работает с пользователями, чтобы определить эти условия ошибок и способы их обработки.
Другим симптомом этой ловушки является то, что почти все ваши требования считаются высокоприоритетными. Различные заинтересованные стороны могут по-разному интерпретировать "высокий" приоритет, что приводит к несовпадению ожиданий относительно того, какая функциональность войдет в следующий релиз. Пользователи могут не решаться расставить приоритеты, потому что боятся, что низкоприоритетные элементы никогда не будут реализованы. Но если вы не можете вместить все желания в рамки проекта, не лучше ли знать, какие из них отложить или опустить?
Решения: Относительный приоритет реализации — это важный атрибут каждого варианта использования, пользовательской истории, функции или функционального требования. Высокий приоритет может быть основан на ожидаемой частоте использования, удовлетворении наиболее важных классов пользователей, реализации основных бизнес-процессов или соответствии нормативным требованиям. Распределите каждый элемент в вашем бэклоге на конкретный релиз или итерацию на основе его приоритета.
Приоритет включает в себя как важность, так и сроки. Если вы используете трех- или четырехуровневую шкалу приоритетов, четко определите категории, чтобы способствовать последовательной классификации и общим ожиданиям. Вот мои определения:
Решения: Отслеживайте каждое функциональное требование вплоть до его происхождения, например, конкретного случая использования, системного требования более высокого уровня или бизнес-правила. Создавайте функциональные требования на основе примеров использования, чтобы избежать бесхозных функций. Если вы не знаете, откуда взялось требование, задайтесь вопросом, действительно ли оно вам нужно.
Определите класс пользователей, которым нужна каждая функция или сценарий использования. Написание пользовательских историй в форме "Как <type of user>(<тип пользователя>), я хочу <some goal>(<такую-то цель>), чтобы <some reason> (<такая-то причина>)" позволяет четко определить, какой класс пользователей получит выгоду.
Аналитическое определение приоритетов функциональных требований, вариантов использования или функций также поможет вам избежать этой ловушки. Избегайте реализации требований, которые влекут за собой большие затраты и приносят низкую ценность для бизнеса.
Решения: Ваша реалистичная цель — это не идеальный SRS, а набор четко сформулированных требований, чтобы часть разработки могла продолжаться с приемлемым риском. Выберите такой жизненный цикл разработки, который позволит вам реализовывать части требований по мере их понимания. Инкрементные подходы к разработке, такие как agile, частично развились для того, чтобы избежать аналитического паралича. Обозначьте пробелы в ваших требованиях символом TBD (будет определено позднее) для обозначения дальнейших действий. Моделируйте и создавайте прототипы только сложных, новых или малопонятных частей системы, чтобы уточнить требования.
Расползание рамок происходит наиболее вероятно, когда объем проекта изначально не был четко определен. Если новые требования были предложены, затем отклонены, но всплыли позже — с постоянными спорами о том, есть ли им место в системе, — значит, ваше определение рамок слишком размыто. Новые требования, которые проникают через заднюю дверь, а не через эффективный процесс изменений, могут привести к превышению сроков.
Решения: Во всех проектах следует ожидать некоторого увеличения требований. В ваших планах должны быть предусмотрены буферы для такого хода вещей. Всякий раз, когда кто-то предлагает новую функциональность, спросите: "Входит ли это в рамки?". Чтобы ответить на этот вопрос, задокументируйте видение и рамки проекта и используйте их как основу для принятия решения о том, какие изменения следует включить.
Расползание рамок часто указывает на то, что требования изначально были не учтены, поэтому эффективные методы получения требований очень важны. Установите значимый процесс для определения базового набора требований для следующего релиза или нового этапа разработки. Дополнительные идеи о том, как справиться с этой ловушкой, см. в моей статье "Managing Scope Creep: Why, When, and How".
Другие признаки недостатков процесса изменений: неясно, кто принимает решения о предлагаемых изменениях, решения об изменениях не доводятся до сведения всех, кого они касаются, а статус каждого запроса на изменение не всегда ясен.
Решения: Определите практический процесс управления изменениями для вашего проекта. Вы можете дополнить этот процесс инструментом отслеживания проблем или вопросов для сбора, отслеживания и передачи изменений. Однако инструмент не заменит процесс. Создайте комиссию по управлению изменениями для рассмотрения предлагаемых изменений и принятия обязательных решений о внесении или отклонении изменений. Определите приоритет каждого предложенного изменения требований по отношению к списку требований, которые еще предстоит реализовать.
Следуйте своему процессу управления изменениями для всех изменений, учитывая, что при принятии новых требований может потребоваться пересмотр обязательств.
Решения: Прежде чем сказать: "Конечно, мы можем это сделать", поймите последствия согласия на внесение изменений, определите, какую работу необходимо выполнить, и оцените влияние на трудозатраты и сроки. Каждое изменение потребует ресурсов: изменения никогда не бывают бесплатными. Отслеживайте информацию об изменениях, чтобы определить все уязвимые компоненты системы. Предоставьте оценки затрат и выгод каждого предложения по изменению лицам, принимающим решения, чтобы они могли разумно принять на себя обязательства.
Решения: Прежде чем команда погрузится в разработку дизайна экрана и детальной функциональности, BA должен провести обсуждение для того, чтобы выяснить требования пользователей. Сосредоточьтесь на бизнес-процессах и задачах пользователей, на том, что система должна помочь им выполнить. Из этих пользовательских требований BA может вывести необходимые функциональные требования, которые должны реализовать разработчики.
BA должен прислушиваться к сигналам, указывающим на то, что пользователи представляют решения, а не истинные требования. Когда вы слышите идею решения, задавайте вопросы, чтобы понять, какая реальная потребность стоит за каждым предлагаемым решением. Является ли эта идея решения истинным ограничением, которое должны соблюдать разработчики? Или это просто одно из представлений говорящего о том, как может быть реализована та или иная возможность?
Источник статьи: https://habr.com/ru/company/otus/blog/566600/
Первая ловушка: Непонимание того, что такое требования
Симптомы: Слово "требования" означает разные вещи для разных людей. В представлении руководителя требования могут быть высокоуровневой концепцией продукта или видением бизнеса. Требования разработчика могут выглядеть как дизайн пользовательского интерфейса. Требования, предоставляемые заказчиком, часто на самом деле являются идеями решений (см. ловушку № 10).Одним из предупреждающих признаков является то, что заинтересованные стороны ссылаются на "требования" без уточняющих прилагательных. У участников проекта могут быть разные ожидания относительно того, насколько подробными должны быть требования. Другой признак — пользователи предоставляют "требования", но разработчики все еще не уверены, что именно нужно создавать. При обсуждении, сосредоточенном исключительно на функциональности, можно упустить из виду другую важную информацию о требованиях.
Решения: Все участники проекта должны понимать основные концепции, терминологию и практику разработки требований. Я мыслю в терминах трех уровней требований (Рисунок 1). Бизнес-требования описывают высокоуровневые бизнес-цели организации или клиента, запрашивающего систему или продукт. Они отвечают на вопрос: Почему мы беремся за этот проект?
На втором уровне рассматриваются требования пользователей: что пользователи смогут делать с продуктом. Они могут быть зафиксированы в виде сценариев использования или пользовательских историй. Однако сами по себе сценарии использования не обеспечивают достаточной детализации, чтобы разработчики знали, что нужно разрабатывать. Поэтому бизнес-аналитик (BA) должен вывести конкретные функциональные требования к программному обеспечению из примеров использования. Разработчики не реализуют напрямую требования бизнеса или пользователей — они реализуют отдельные функциональные требования.
Другие типы знаний о требованиях включают атрибуты качества, бизнес-правила, ограничения проектирования и реализации, а также требования к внешнему интерфейсу. Изучите их все во время разработки, чтобы не упустить что-то важное. Многие из этих типов требований обычно включаются в спецификацию требований к программному обеспечению или SRS.
Вторая ловушка: Недостаточное вовлечение клиентов
Симптомы: Однажды я видел, как клиенты отвергли новую информационную систему при первом же знакомстве с ней, то есть на начальном этапе внедрения. Это мощный, но запоздалый и болезненный признак недостаточного вовлечения клиентов. Пользователи иногда считают, что BA по техническому анализу или разработчики должны знать, что им нужно. Некоторые пользователи утверждают, что они слишком заняты, чтобы тратить время на требования.Одним из ранних признаков недостаточного вовлечения клиентов является то, что требования предоставляют не реальные пользователи, а их заменители — менеджеры, сотрудники отдела маркетинга или даже разработчики. Другим признаком является то, что разработчики вынуждены принимать многие решения по требованиям, не имея достаточной информации. Если ни один из классов пользователей продукта не внес свой вклад, кто-то будет недоволен результатом.
Решения: Стремитесь к сотрудничеству между представителями заказчика, BA и командой разработчиков. Начните с определения различных классов пользователей. Классы пользователей — это группы, которые отличаются по частоте использования продукта, используемым функциям, уровню привилегий или другим признакам. Затем определите индивидуальных чемпионов продукта, которые будут представлять определенные классы пользователей. Представители продукта собирают информацию от других членов своего класса пользователей, предоставляют требования пользователей BA, а также вносят свой вклад в атрибуты качества и приоритеты требований.
Ваши представители пользователей также могут просматривать письменные требования, оценивать прототипы и предоставлять обратную связь по постепенным релизам, как в agile-разработке. Стремитесь к постоянному взаимодействию с пользователями, а не только к проведению семинара или двух семинаров в начале проекта.
Третья ловушка: Нечеткие, двусмысленные и неполные требования
Симптомы: Вы сталкиваетесь с двусмысленностью, если формулировка требования может иметь несколько различных значений, и вы не уверены, какое из них правильное. Более коварная форма двусмысленности возникает, когда несколько человек по-разному интерпретируют требование. Каждый приходит к выводу, что его интерпретация верна, и двусмысленность остается незамеченной до тех пор, пока ее не придется устранять.Еще один признак нечетких или неполных требований — отсутствие в SRS информации, необходимой разработчикам. Например, если вы не можете придумать тесты для проверки правильности выполнения каждого требования, значит, ваши требования определены нечетко. Конечным симптомом нечетких требований является то, что разработчики вынуждены задавать много вопросов BA или заказчикам, или им приходится догадываться о том, что на самом деле предполагается.
Решения: Избегайте использования субъективных и двусмысленных по своей сути слов при написании требований. Такие термины, как минимизировать, максимизировать, оптимизировать, быстрый, удобный для пользователя, интуитивный, надежный, улучшенный, эффективный и поддержка являются особенно уязвимыми выражениями.
Чтобы устранить двусмысленность, поручите команде, включающей представителей различных точек зрения, тщательно проанализировать требования. В число подходящих специалистов входят:
- BA, который написал требования, и, возможно, другой опытный BA
- Клиент или представитель отдела маркетинга, который их предоставил
- Разработчик, который должен их реализовать
- Тестировщик, который должен проверить их в продукте
Прототипы делают требования более осязаемыми. Оценка прототипа — отличный способ прояснить пробелы в ваших знаниях и достичь общего понимания. Визуальные модели анализа, такие как диаграммы потоков данных, диаграммы взаимосвязей сущностей и диаграммы переходов состояний, предоставляют альтернативные представления требований, которые часто выявляют пробелы в знаниях.
Определите исключения, которые должна обрабатывать система, а также то, что пользователи должны делать с системой. Хорошие разработчики тратят много времени на написание кода для обнаружения, предотвращения и восстановления после всех вещей, которые могут пойти не так. Им и пользователям очень помогает, если бизнес-аналитик работает с пользователями, чтобы определить эти условия ошибок и способы их обработки.
4 ловушка: Неприоритетные требования
Симптомы: "Нам не нужно расставлять приоритеты в требованиях", — сказал представитель пользователя. "Они все важны, иначе я бы их вам не предоставил". Признание всех требований одинаково важными не помогает менеджеру проекта реагировать на новые требования или на изменения в реальности проекта (персонал, график, цели по качеству). Если неясно, какие функции можно отложить во время слишком распространенной "фазы быстрого анализа" в конце проекта, вы рискуете получить неприоритетные требования.Другим симптомом этой ловушки является то, что почти все ваши требования считаются высокоприоритетными. Различные заинтересованные стороны могут по-разному интерпретировать "высокий" приоритет, что приводит к несовпадению ожиданий относительно того, какая функциональность войдет в следующий релиз. Пользователи могут не решаться расставить приоритеты, потому что боятся, что низкоприоритетные элементы никогда не будут реализованы. Но если вы не можете вместить все желания в рамки проекта, не лучше ли знать, какие из них отложить или опустить?
Решения: Относительный приоритет реализации — это важный атрибут каждого варианта использования, пользовательской истории, функции или функционального требования. Высокий приоритет может быть основан на ожидаемой частоте использования, удовлетворении наиболее важных классов пользователей, реализации основных бизнес-процессов или соответствии нормативным требованиям. Распределите каждый элемент в вашем бэклоге на конкретный релиз или итерацию на основе его приоритета.
Приоритет включает в себя как важность, так и сроки. Если вы используете трех- или четырехуровневую шкалу приоритетов, четко определите категории, чтобы способствовать последовательной классификации и общим ожиданиям. Вот мои определения:
- Высокий: должно быть включено в следующий релиз или итерацию
- Средний: необходимо, но может подождать до следующего релиза
- Низкий: мы можем прожить без этого, если это необходимо
Пятая ловушка: Создание функциональности, которую никто не использует
Симптомы: Иногда я внедрял функции, которые, как клялись пользователи, были им необходимы, но потом никто никогда их не использовал. Это расстраивает. Остерегайтесь клиентов, которые не отличают блестящий "хром" от необходимой "стали", которая должна присутствовать, чтобы программное обеспечение было полезным. Остерегайтесь разработчиков, которые добавляют ненужную функциональность, которая может быть не нужна пользователям. Некоторые предлагаемые функциональные возможности не имеют четкой связи с известными задачами пользователей или достижением ваших бизнес-целей.Решения: Отслеживайте каждое функциональное требование вплоть до его происхождения, например, конкретного случая использования, системного требования более высокого уровня или бизнес-правила. Создавайте функциональные требования на основе примеров использования, чтобы избежать бесхозных функций. Если вы не знаете, откуда взялось требование, задайтесь вопросом, действительно ли оно вам нужно.
Определите класс пользователей, которым нужна каждая функция или сценарий использования. Написание пользовательских историй в форме "Как <type of user>(<тип пользователя>), я хочу <some goal>(<такую-то цель>), чтобы <some reason> (<такая-то причина>)" позволяет четко определить, какой класс пользователей получит выгоду.
Аналитическое определение приоритетов функциональных требований, вариантов использования или функций также поможет вам избежать этой ловушки. Избегайте реализации требований, которые влекут за собой большие затраты и приносят низкую ценность для бизнеса.
Ловушка 6: Аналитический паралич
Симптомы: Если кажется, что разработка требований длится вечно, возможно, вы стали жертвой аналитического паралича. Новые версии SRS могут появляться так часто, что номера версий напоминают IP-адреса. Чрезмерно усердный BA может попытаться смоделировать все требования или создать прототип всей системы, прежде чем объявить требования готовыми к реализации. Возможно, лица, принимающие решения, так и не пришли к согласию относительно базовой линии требований. Аналитический паралич — это большой риск чисто водопадного подхода к разработке программного обеспечения.Решения: Ваша реалистичная цель — это не идеальный SRS, а набор четко сформулированных требований, чтобы часть разработки могла продолжаться с приемлемым риском. Выберите такой жизненный цикл разработки, который позволит вам реализовывать части требований по мере их понимания. Инкрементные подходы к разработке, такие как agile, частично развились для того, чтобы избежать аналитического паралича. Обозначьте пробелы в ваших требованиях символом TBD (будет определено позднее) для обозначения дальнейших действий. Моделируйте и создавайте прототипы только сложных, новых или малопонятных частей системы, чтобы уточнить требования.
Седьмая ловушка: Расползание рамок
Симптомы: Большинство проектов сталкиваются с угрозой расползания рамок проекта, поскольку в процессе разработки постоянно добавляются новые требования. Как правило, сроки проекта не меняются, больше ресурсов не выделяется, и ничего не исключается для размещения новой функциональности.Расползание рамок происходит наиболее вероятно, когда объем проекта изначально не был четко определен. Если новые требования были предложены, затем отклонены, но всплыли позже — с постоянными спорами о том, есть ли им место в системе, — значит, ваше определение рамок слишком размыто. Новые требования, которые проникают через заднюю дверь, а не через эффективный процесс изменений, могут привести к превышению сроков.
Решения: Во всех проектах следует ожидать некоторого увеличения требований. В ваших планах должны быть предусмотрены буферы для такого хода вещей. Всякий раз, когда кто-то предлагает новую функциональность, спросите: "Входит ли это в рамки?". Чтобы ответить на этот вопрос, задокументируйте видение и рамки проекта и используйте их как основу для принятия решения о том, какие изменения следует включить.
Расползание рамок часто указывает на то, что требования изначально были не учтены, поэтому эффективные методы получения требований очень важны. Установите значимый процесс для определения базового набора требований для следующего релиза или нового этапа разработки. Дополнительные идеи о том, как справиться с этой ловушкой, см. в моей статье "Managing Scope Creep: Why, When, and How".
8 ловушка: Несовершенный процесс внесения изменений
Симптомы: Наиболее ярким симптомом является то, что в вашем проекте отсутствует определенный процесс обработки изменяющихся требований. Новая функциональность может стать очевидной только во время тестирования системы. Некоторые люди обходят этот процесс, рассказывая своим приятелям-разработчикам о желаемых изменениях.Другие признаки недостатков процесса изменений: неясно, кто принимает решения о предлагаемых изменениях, решения об изменениях не доводятся до сведения всех, кого они касаются, а статус каждого запроса на изменение не всегда ясен.
Решения: Определите практический процесс управления изменениями для вашего проекта. Вы можете дополнить этот процесс инструментом отслеживания проблем или вопросов для сбора, отслеживания и передачи изменений. Однако инструмент не заменит процесс. Создайте комиссию по управлению изменениями для рассмотрения предлагаемых изменений и принятия обязательных решений о внесении или отклонении изменений. Определите приоритет каждого предложенного изменения требований по отношению к списку требований, которые еще предстоит реализовать.
Следуйте своему процессу управления изменениями для всех изменений, учитывая, что при принятии новых требований может потребоваться пересмотр обязательств.
Девятая ловушка: Неэффективный анализ воздействия изменений
Симптомы: ВА, разработчики или руководители проектов иногда соглашаются внести предложенные изменения, не обдумав их последствия. Изменение может оказаться более сложным, чем предполагалось, занять больше времени, чем было обещано, оказаться технически или экономически невыполнимым или противоречить другим требованиям. Еще одним признаком неэффективного анализа воздействия изменений является то, что разработчики продолжают сталкиваться с более уязвимыми компонентами системы по мере внедрения изменений.Решения: Прежде чем сказать: "Конечно, мы можем это сделать", поймите последствия согласия на внесение изменений, определите, какую работу необходимо выполнить, и оцените влияние на трудозатраты и сроки. Каждое изменение потребует ресурсов: изменения никогда не бывают бесплатными. Отслеживайте информацию об изменениях, чтобы определить все уязвимые компоненты системы. Предоставьте оценки затрат и выгод каждого предложения по изменению лицам, принимающим решения, чтобы они могли разумно принять на себя обязательства.
Десятая ловушка: Решения, представленные в виде требований
Симптомы: Многие из моих клиентов-консультантов говорили мне, что эта ловушка представляет собой их самую большую проблему с требованиями. Пользователи зачастую представляют эскизы экрана как свои требования, а обсуждения в рамках процесса выявления требований сосредоточены на дизайне пользовательского интерфейса, а не на базовых потребностях. Команда может рассчитывать на то, что прототипы заменят письменные спецификации требований. Если вы обнаружите, что обсуждение требований сосредоточено на том, как будет выглядеть продукт и его возможностях, а не на том, что пользователи смогут с ним делать, возможно, вы попали в эту ловушку.Решения: Прежде чем команда погрузится в разработку дизайна экрана и детальной функциональности, BA должен провести обсуждение для того, чтобы выяснить требования пользователей. Сосредоточьтесь на бизнес-процессах и задачах пользователей, на том, что система должна помочь им выполнить. Из этих пользовательских требований BA может вывести необходимые функциональные требования, которые должны реализовать разработчики.
BA должен прислушиваться к сигналам, указывающим на то, что пользователи представляют решения, а не истинные требования. Когда вы слышите идею решения, задавайте вопросы, чтобы понять, какая реальная потребность стоит за каждым предлагаемым решением. Является ли эта идея решения истинным ограничением, которое должны соблюдать разработчики? Или это просто одно из представлений говорящего о том, как может быть реализована та или иная возможность?
Основные составляющие отличных требований
Эти десять ловушек — не единственные, скрывающиеся на минном поле требований, но они одни из самых распространенных и самых серьезных. Чтобы справиться с ними, попробуйте использовать следующие подходы.- Обучайте разработчиков, менеджеров и заказчиков как практическим требованиям, так и области применения.
- Установите партнерские отношения между заказчиком и разработчиком.
- Используйте итеративный и инкрементный подход к разработке требований.
- Используйте стандартные шаблоны для концепции и объема, сценария использования и подробных документов требований.
- Проводите как неформальные, так и формальные обзоры требований.
- Заранее составляйте тесты на соответствие требованиям.
- Вдумчиво расставляйте приоритеты требований, чтобы быстро получить максимальную ценность для бизнеса.
- Прививайте дисциплину для последовательной и эффективной работы с изменяющимися требованиями.
Источник статьи: https://habr.com/ru/company/otus/blog/566600/