Планирование хороших требований

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

Хороший документ с требованиями может быть частью группы с высокоуровневыми требованиями, разбитыми на подзапросы.
Они также могут включать очень подробные спецификации, которые включают набор функциональных требований, описывающих поведение или компоненты конечного продукта.
Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос: «Что нам нужно?» Вместо того, чтобы «как нам удовлетворить потребность?»
Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неправильно истолкованы, конечный продукт может быть неисправным или неисправным.

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

Сбор и анализ требований

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

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

Требования должны быть:

Documented
Actionable
Measurable
Testable
Traceable

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

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

Выявляющий подход

Чтобы выяснить цели, задайте бизнес-эксперту, менеджеру по развитию и спонсору проекта следующие вопросы:

Какие бизнес-цели компании поможет решить этот проект?
Почему мы сейчас делаем этот проект?
Что будет, если мы сделаем это позже?
Что, если мы вообще этого не сделаем?
Кому будет полезен этот проект?
Считают ли люди, которым это принесет пользу, это самое важное улучшение, которое возможно сделать в настоящее время?
Должны ли мы вместо этого заняться другим проектом?

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

Различные типы требований

Наиболее распространенные типы требований, которые интересуют бизнес-аналитика, следующие:

Бизнес-требования

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

Требования пользователя

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

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

Системные Требования

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

Функциональные требования

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

Нефункциональные требования

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

Нефункциональные требования говорят о том, как должна выглядеть система, или о том, как «система должна быть». Нефункциональные требования называются качествами системы.

Требования к переходу

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

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

Прослеживаемость и управление изменениями

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

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

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

Включите столбцы для каждого из следующих в RTM -

Описание требования
Ссылка на требование в FRD
Метод проверки
Ссылка на требование в плане тестирования

Example- Соединение точек для определения отношений между элементами в вашем проекте. Это соединитель общего нисходящего потока.

Идея Требования Дизайн Тест Бизнес-цели

У вас должна быть возможность проследить каждое из ваших требований до исходной бизнес-цели.

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

Гарантия качества

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

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

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

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

Таким образом, управление требованиями может показаться сложной дисциплиной, но если свести ее к простой концепции - она помогает командам ответить на вопрос: «Все ли понимают, что мы создаем и почему?» От бизнес-аналитиков, менеджеров по продуктам и руководителей проектов до разработчиков, менеджеров по обеспечению качества и тестировщиков, а также заинтересованных сторон и клиентов - так часто основной причиной неудач проекта является непонимание масштабов проекта.

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

Note- Исследования показали, что проектные группы могут устранить 50-80% дефектов проекта, эффективно управляя требованиями. По данным института разработки программного обеспечения Карнеги-Меллона, «60-80 процентов стоимости разработки программного обеспечения приходится на доработку».

Получение подтверждения требований

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

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

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