Итак, что делает хорошее требование? Хорошее требование должно быть ценным и действенным; это должно определить потребность, а также обеспечить путь к решению. Все в команде должны понимать, что это значит. Требования различаются по сложности.
-
Хороший документ с требованиями может быть частью группы с требованиями высокого уровня, разбитыми на подусловия.
-
Они могут также включать очень подробные спецификации, которые включают набор функциональных требований, описывающих поведение или компоненты конечного продукта.
-
Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос «что нам нужно?», А не «как мы удовлетворяем потребность?»
-
Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неверно истолкованы, конечный продукт может быть неисправен или неисправен.
Хороший документ с требованиями может быть частью группы с требованиями высокого уровня, разбитыми на подусловия.
Они могут также включать очень подробные спецификации, которые включают набор функциональных требований, описывающих поведение или компоненты конечного продукта.
Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос «что нам нужно?», А не «как мы удовлетворяем потребность?»
Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неверно истолкованы, конечный продукт может быть неисправен или неисправен.
Предотвращению сбоев или неправильного толкования требований может помочь постоянное получение обратной связи от группы в течение всего процесса по мере развития требований. Непрерывное сотрудничество и участие со всеми — ключ к успеху.
Сбор и анализ требований
Требование — это условие или способность, необходимые заинтересованному лицу для решения проблемы или достижения организационной цели; состояние или способность, которой должна соответствовать система.
Анализ требований в разработке программного обеспечения охватывает те задачи, которые входят в определение потребностей или условий для нового или измененного продукта с учетом возможных противоречивых требований различных заинтересованных сторон, анализа, документирования, проверки и управления требованиями к программному обеспечению или системе.
Требования должны быть —
- документированный
- Осуществимое
- измеримый
- Тестируемые
- прослеживаемый
Требования должны быть связаны с определенными бизнес-потребностями или возможностями и определены с уровнем детализации, достаточным для проектирования системы.
Бизнес-аналитик собирает информацию, наблюдая за существующими системами, изучая существующие процедуры, обсуждая с клиентами и конечными пользователями. Аналитик также должен обладать творческими и творческими навыками в отсутствие работающей Системы. Анализ собранных требований для поиска недостающих ссылок — это анализ требований.
Выявление Подхода
Чтобы определить цели, задайте бизнес-эксперту, менеджеру по развитию и спонсору проекта следующие вопросы:
-
Каких бизнес-целей компании поможет этот проект?
-
Почему мы делаем этот проект сейчас?
-
Что будет, если мы сделаем это позже?
-
Что делать, если мы не делаем это вообще?
-
Кто выиграет от этого проекта?
-
Считают ли люди, которые извлекут из этого пользу, самым важным улучшением, которое может быть сделано в это время?
-
Должны ли мы делать другой проект вместо этого?
Каких бизнес-целей компании поможет этот проект?
Почему мы делаем этот проект сейчас?
Что будет, если мы сделаем это позже?
Что делать, если мы не делаем это вообще?
Кто выиграет от этого проекта?
Считают ли люди, которые извлекут из этого пользу, самым важным улучшением, которое может быть сделано в это время?
Должны ли мы делать другой проект вместо этого?
Возможными целями могут быть сокращение затрат, улучшение обслуживания клиентов, упрощение рабочего процесса, замена устаревшей технологии, пилотирование новой технологии и многие другие. Также убедитесь, что вы точно понимаете, как предлагаемый проект поможет достичь поставленной цели.
Различные типы требований
Наиболее распространенные типы требований, которые интересуют бизнес-аналитика, следующие:
Бизнес-требования
Бизнес-требования — это критически важные действия предприятия, которые должны выполняться для достижения целей организации, оставаясь при этом независимым от решения. Документ бизнес-требований (BRD) детализирует бизнес-решение для проекта, включая документацию о потребностях и ожиданиях клиента.
Требования к пользователю
Пользовательские требования должны указывать конкретные требования, которые пользователь ожидает / хочет от программного обеспечения, которое будет создано из программного проекта. Требование пользователя должно быть Проверяемым, Четким и кратким, Полным, Последовательным, Прослеживаемым, Жизнеспособным.
Документ с требованиями пользователя (URD) или спецификация требований пользователя — это документ, обычно используемый в разработке программного обеспечения, в котором указывается, что пользователь ожидает от программного обеспечения.
Системные Требования
Системные требования касаются определения требований к программным ресурсам и предварительных условий, которые необходимо установить на компьютер для обеспечения оптимального функционирования приложения.
Функциональные требования
Функциональные требования фиксируют и определяют конкретное предполагаемое поведение разрабатываемой системы. Они определяют такие вещи, как системные вычисления, манипулирование и обработка данных, пользовательский интерфейс и взаимодействие с приложением, а также другие специфические функции, которые показывают, как удовлетворяются пользовательские требования. Присвойте уникальный идентификационный номер каждому требованию.
Нефункциональные требования
Нефункциональное требование — это то, которое определяет критерии, которые могут использоваться для оценки работы системы, а не для конкретного поведения. Архитектура системы говорит о плане реализации нефункциональных требований.
Нефункциональные требования говорят о том, как должна выглядеть система, или ее можно назвать «система должна быть». Нефункциональные требования называются качествами системы.
Требования к переходу
Требования перехода описывают возможности, которые решение должно выполнять, чтобы облегчить переход от текущего состояния предприятия к желаемому будущему состоянию, но это не потребуется после завершения этого перехода.
Они отличаются от других типов требований, поскольку они всегда носят временный характер и не могут быть разработаны до тех пор, пока не будет определено как существующее, так и новое решение. Как правило, они охватывают преобразование данных из существующих систем, пробелы в навыках, которые необходимо устранить, и другие связанные изменения, чтобы достичь желаемого будущего состояния. Они разрабатываются и определяются путем оценки и подтверждения решения.
Отслеживание и управление изменениями
Отслеживание требований — это способ организации, документирования и отслеживания всех ваших требований от начальной генерации идеи до фазы тестирования.
Матрица возможностей трассировки требований (RTM) предоставляет метод для отслеживания функциональных требований и их реализации в процессе разработки. Каждое требование включено в матрицу вместе с соответствующим номером раздела.
По мере выполнения проекта RIM обновляется, чтобы отражать статус каждого требования. Когда продукт готов к тестированию системы, в матрице перечисляются все требования, какой компонент продукта отвечает на них, и какой тест проверяет, правильно ли он реализован.
Включить столбцы для каждого из следующих в RTM —
- Описание требования
- Требование ссылки в FRD
- Метод проверки
- Ссылка на требование в плане испытаний
Пример — подключение точек для определения взаимосвязей между элементами в вашем проекте. Это соединитель общего нисходящего потока.
Идея Требования Дизайн Тест Бизнес Цели
Вы должны быть в состоянии проследить каждое из ваших требований до их первоначальной бизнес-цели.
Отслеживая требования, вы можете определить, какие изменения имели волновой эффект, посмотреть, выполнено ли требование и проходит ли оно надлежащее тестирование. Отслеживание и управление изменениями обеспечивают менеджерам душевное спокойствие и видимость, необходимые для прогнозирования проблем и обеспечения постоянного качества.
Гарантия качества
Правильное выполнение требований с первого раза может означать лучшее качество, более быстрые циклы разработки и более высокое удовлетворение потребителя продуктом. Управление требованиями не только помогает вам сделать все правильно, но и помогает вашей команде сэкономить деньги и избавиться от множества головных болей на протяжении всего процесса разработки.
Вкратце, конкретные требования могут помочь вам обнаружить и исправить проблемы раньше, а не позже, когда их решение намного дороже. Кроме того, исправление дефекта в процессе разработки после его кодирования может стоить в 100 раз дороже, чем исправление на раннем этапе, когда это требуется.
Интегрируя управление требованиями в свой процесс обеспечения качества, вы можете помочь своей команде повысить эффективность и устранить доработки. Кроме того, на переделках возникает большинство проблем с расходами.
Другими словами, команды разработчиков тратят большую часть своего бюджета на усилия, которые не выполняются правильно с первого раза. Например, разработчик кодирует функцию, основанную на старом документе спецификации, только чтобы потом узнать, что требования к этой функции изменились. Таких проблем можно избежать с помощью эффективных методов управления требованиями.
Таким образом, управление требованиями может показаться сложной дисциплиной, но когда вы сводите его к простой концепции — речь идет о том, чтобы помочь командам ответить на вопрос: «Все ли понимают, что мы строим и почему?» От бизнес-аналитиков, продукта менеджеры и руководители проектов разработчикам, менеджерам по обеспечению качества и тестировщикам, а также заинтересованным сторонам и заказчикам — поэтому зачастую причиной провала проекта является неправильное понимание масштабов проекта.
Когда все сотрудничают и имеют полный контекст и видимость для обсуждений, решений и изменений, связанных с требованиями на протяжении всего жизненного цикла проекта, то есть когда успех происходит последовательно и вы сохраняете постоянное качество. Кроме того, процесс более плавный, с меньшим количеством трений и разочарований по пути для всех участников.
Примечание. Исследования показали, что проектные группы могут устранить 50-80% дефектов проекта, эффективно управляя требованиями. По данным Института разработки программного обеспечения Карнеги-Меллона, «60–80 процентов затрат на разработку программного обеспечения находятся в процессе доработки».
Получение требований Signoff
Подписание требований формализует согласие заинтересованных сторон проекта, что содержание и представление требований, как они задокументированы, являются точными и полными. Официальное соглашение снижает риск того, что в ходе или после реализации заинтересованная сторона введет новое (ранее не встречавшееся) требование.
Получение требований к подписке обычно включает в себя итоговый обзор требований, как это задокументировано, с каждым участником проекта. В конце каждой проверки заинтересованному лицу предлагается официально утвердить пересмотренный документ с требованиями. Это одобрение может быть зарегистрировано либо физически, либо электронно.
Получение подписи требований, как правило, является конечной задачей в рамках взаимодействия требований. Бизнес-аналитику потребуются результаты анализа (-ов) формальных требований, включая размещение любых комментариев или возражений, которые были высказаны в процессе проверки.