Юлий Минькин, директор по развитию проектного офиса
Сбор и формирование требований пользователей к автоматизированной системе — это фундаментальный этап в разработке любой автоматизированной системы. Этот процесс определяет, какие функциональные и нефункциональные характеристики должна иметь система для удовлетворения потребностей пользователей и достижения бизнес-целей.
Рассмотрим ключевые аспекты этого процесса.
Классификация требований пользователей
Требования пользователей в контексте информационных систем обычно классифицируются на несколько основных типов:
- Функциональные требования. Определяют, что система должна делать. Включают в себя описание задач, операций, которые система должна выполнять, и условий, при которых эти операции должны происходить. Это может включать конкретные функции, вычисления, технические детали, обработку данных и другие функциональные характеристики.
- Нефункциональные требования. Эти требования определяют критерии, по которым система выполняет функции, включая производительность, безопасность, надежность, совместимость, пользовательский интерфейс и взаимодействие. Они могут также касаться ограничений, таких как стандарты разработки или внутренние политики организации.
- Требования к данным. Определяют, какие данные должны быть введены в систему, как они должны храниться, обрабатываться и представляться. Это включает структуры баз данных, обновление данных, частоту бэкапов, интеграцию с другими данными и системами.
- Требования к интерфейсу. Описывают, как система будет взаимодействовать с другими системами, оборудованием, пользовательскими интерфейсами и коммуникационными протоколами. Это может включать в себя внешний вид и ощущение от пользовательского интерфейса, стандарты взаимодействия и API.
- Требования к процессам. Определяют, какие бизнес-процессы система должна поддерживать, какие рабочие процедуры будут изменены или введены в действие.
- Регуляторные требования: Включают в себя соответствие законодательству, стандартам, лицензированию и политике конфиденциальности. Эти требования обеспечивают, что система будет соответствовать всем применимым законам и регуляциям.
- Требования к качеству. Описывают стандарты качества, которым должна соответствовать система, включая тестирование, документацию, требования к порядку приемки и контроля системы и стандарты обслуживания.
- Ограничения. Описывают любые ограничения на доступные ресурсы, такие как время, бюджет и технические ограничения, которые могут повлиять на проектирование и разработку системы.
Классификацию требований по К. Вигерсу и ГОСТ читайте в нашей статье.
Методы сбора требований
Эффективные методы сбора требований обеспечивают то, что проектные решения будут соответствовать бизнес-целям организации, удовлетворять потребности пользователей, способствовать проекту оставаться в рамках бюджета и сроков. Давайте рассмотрим основные методы сбора требований и их вклад в успешное выполнение проектов.
Анкетирование и опросы
Опросы и анкетирование позволяют быстро собирать данные от большого количества пользователей. Практика показывает, что с помощью стандартизированных вопросов сбор требований будет более полным. Однако, существуют недостатки этого метода: респонденты часто неспособны, либо слабо мотивированы, чтобы информативно заполнить анкету; велика вероятность получить неполную или ложную информацию; такой подход не всегда подходит для выявления сложных или глубинных требований, так как варианты ответов ограничены и не предоставляют полного контекста. Анкетирование и опросы применяются в дополнение к другим методам сбора требований.
Интервью
Интервью с заинтересованными сторонами является классическим методом сбора требований. Этот метод позволяет не только узнать, чего желают пользователи, но и понять их невысказанные потребности.
До проведения интервью может быть полезно распространить анкеты среди потенциальных пользователей. Анкеты могут содержать вопросы о текущих рабочих процессах, болевых точках и ожиданиях от новой системы. Это позволяет интервьюеру подготовиться и сфокусироваться на ключевых темах во время беседы.
Для успешного проведения интервью необходимы навыки глубокого слушания и способность задавать правильные вопросы. Кроме того, необходимо протоколировать ответы и обеспечить, чтобы информация была точно зафиксирована.
Фокус-группы
Фокус-группы собирают представителей целевой аудитории для обсуждения их потребностей и предпочтений пользователей. Этот метод полезен для выявления неявных требований и получения более широкого спектра мнений по вопросам, объединяющим несколько групп пользователей. Недостатком является возможное доминирование более громких участников над остальными, что может привести к искажению результатов.
Мозговой штурм
Метод мозгового штурма подразумевает групповую творческую работу, направленную на генерацию новых идей. В контексте сбора требований он помогает стимулировать инновационное мышление и выявлять нестандартные решения. Важно, чтобы процесс был организован так, чтобы каждый участник имел возможность высказаться. Без надлежащего управления такие мероприятия переходят в "базар" и выяснение отношений между его участниками.
Наблюдение и погружение
Метод наблюдения включает в себя изучение пользователей в их естественной рабочей среде. Это позволяет аналитикам уловить детали и нюансы использования текущих систем, которые могут быть упущены в документации к этим системам или в ходе интервью с пользователями.
Документ-анализ
Анализ существующих документов, таких как политики, процедуры, инструкции, отчеты, проектная документация и пр., может выявить требования, которые уже были формализованы, но нуждаются в пересмотре или обновлении.
Прототипирование
Прототипирование предполагает создание упрощенной версии системы для сбора обратной связи от пользователей. Этот метод эффективен для проверки и уточнения требований в интерактивном режиме.
Анализ исторических систем
Анализ существующих систем может помочь понять, какие функции программы или элементы управления ценят пользователи, а какие вызывают трудности. Что было доработано и для чего. Понять последовательность выполнения учетных процессов, включая заполнения документов и их реквизитов, выполнение регламентных задач и пр.
Каждый из этих методов имеет свои преимущества и недостатки, и на практике часто используется их комбинация для достижения наилучших результатов. Выбор методов сбора требований должен опираться на конкретные цели проекта, доступные ресурсы и характеристики пользовательской аудитории.
Формы списков требований
Списки требований могут принимать различные формы, в зависимости от целей проекта, методологии разработки и предпочтений команды. Ниже приведены наиболее распространенные формы списков требований:
User Stories (Пользовательские Истории)
В гибких методологиях, например таких как ТБР или Scrum, требования часто представлены в форме пользовательских историй. Это короткие описания функционала с точки зрения конечного пользователя.
Backlog product (Журнал требований)
Журнал требований к системе — упорядоченный и приоритезированный список требований, пользовательских историй и улучшений, которые необходимо выполнить для получение конечного продукта.
Feature List (Список функций)
Это перечень всех запланированных функций продукта. Обычно более общий и менее детализированный, чем традиционная спецификация требований.
Use Cases (Сценарий использования)
Описывают, как пользователи будут взаимодействовать с системой для выполнения конкретных задач. Это помогает разработчикам и заинтересованным сторонам понять контекст использования системы.
Checklists (Чек-листы)
Простой и лаконичный список требований, который может использоваться для быстрой проверки и удостоверения, что все необходимые аспекты были учтены.
Другие формы списков требований
Matrix of Requirements (Матрица Требований): Таблица или матрица, которая отображает отношения между требованиями и другими элементами проекта, такими как компоненты системы, тестовые случаи или документы.
Mind Maps (Карты памяти): Визуальное представление требований, которое помогает лучше понять связи между различными аспектами и функциями системы.
Acceptance Criteria (Критерии принятия): Список условий, которые система или функция должна выполнить, чтобы быть принятой пользователями или заинтересованными сторонами.
Wireframes or Mock-ups (Макеты или Прототипы): Визуальные представления пользовательского интерфейса, которые могут служить для демонстрации и согласования требований к внешнему виду и взаимодействию пользователя с системой.
Выбор формы списка требований зависит от многих факторов, включая сложность проекта, требования к документации, предпочтения команды и заинтересованных сторон, а также от выбранной методологии управления проектом.
Формальные документы описывающие требования
Формальные документы, описывающие требования, являются важной частью планирования и реализации любого проекта, особенно в области информационных технологий.
Они предоставляют четкое и подробное описание функциональных и нефункциональных требований к продукту или системе, а также определяют критерии, по которым эти требования будут проверяться и приниматься.
Описание основных видов таких документов читайте в нашей статье.
Эти документы играют критическую роль в успешном управлении проектом, обеспечивая, что все члены команды и заинтересованные стороны имеют единое понимание целей и требований к проекту. Кроме того, они помогают минимизировать риски, связанные с недопониманием или изменением требований в ходе проекта.
Анализ качества процесса сбора и формирования требований
Анализ качества процесса сбора и формирования требований является важным аспектом управления проектами, особенно в области разработки программного обеспечения и систем.
Качественный процесс сбора требований увеличивает шансы на успешное выполнение проекта, снижает риски и помогает в достижении удовлетворенности клиентов.
Для анализа качества этого процесса можно рассмотреть несколько ключевых аспектов:
- Полнота и точность собранных требований. Оценить, насколько полно и точно собранные требования отражают потребности и ожидания заинтересованных сторон. Неполные или неточные требования могут привести к недопониманию и проблемам в дальнейшем.
- Процесс вовлечения заинтересованных сторон. Оценить, насколько эффективно в процесс были вовлечены все ключевые заинтересованные стороны, и были ли учтены их мнения и предложения.
- Методы сбора требований. Провести анализ используемых методов сбора требований (например, интервью, опросы, фокус-группы, анализ документации), чтобы определить их эффективность и при необходимости внести корректировки.
- Документирование требований. Оценить качество документации требований, включая ясность, структуру и доступность документов для всех участников проекта.
- Гибкость и управление изменениями. Оценить, насколько гибко процесс может адаптироваться к изменениям требований и как эффективно управляются эти изменения.
- Уровень удовлетворенности пользователей. Сбор обратной связи от конечных пользователей может дать ценную информацию о качестве процесса сбора требований.
- Анализ рисков. Оценить, были ли идентифицированы и управляемы потенциальные риски, связанные с требованиями.
- Повторяемость и стандартизация. Оценить, насколько процесс сбора требований может быть стандартизирован и повторяем для будущих проектов.
Анализ качества процесса сбора и формирования требований помогает выявить области для улучшения, повышает эффективность работы команды, и в конечном итоге способствует созданию качественного продукта, соответствующего потребностям пользователей и бизнеса.
Верификация требований
Верификация требований — это процесс подтверждения того, что сформулированные требования к системе или продукту корректны, полны, точны и исполнимы.
Этот процесс является критически важной частью разработки программного обеспечения и систем, поскольку он помогает обеспечить, что конечный продукт будет соответствовать ожиданиям и потребностям пользователей и заинтересованных сторон.
Критерии верификации требований
Рассмотрим ключевые критерии верификации требований.
- Проверка на полноту. Следует убедиться, что все необходимые требования были определены и задокументированы. Все возможные сценарии использования и условия должны быть учтены.
- Оценка непротиворечивости. Проверить, что нет конфликтующих требований в документации. Требования не должны противоречить друг другу или существующим стандартам и спецификациям.
- Анализ осуществимости. Определить, можно ли реализовать каждое требование с учетом текущих технических возможностей, времени, ресурсов и бюджета.
- Проверка на однозначность. Следует убедиться, что требования формулированы ясно и однозначно, так чтобы каждый член команды мог их одинаково понять и интерпретировать.
- Проверка на тестируемость. Каждое требование должно быть проверяемо, то есть должен существовать метод для подтверждения его реализации, например, через тестирование или демонстрацию.
- Подтверждение соответствия нормам и стандартам. Следует удостовериться, что все требования соответствуют применимым законодательным и отраслевым стандартам и нормам.
Методы и средства проверки требований
Верификация требований – это процесс проверки того, что сформулированные требования для системы или продукта являются правильными, полными, однозначными и выполнимыми.
Для верификации требований используются различные методы и средства, вот некоторые из них:
- Ревизии и инспекции: Организация формальных встреч, на которых команда проекта, заинтересованные стороны или внешние эксперты тщательно пересматривают документацию требований. Это помогает выявить любые ошибки, пропуски, несоответствия или двусмысленности.
- Прототипирование. Разработка прототипов или макетов для визуализации требований и их дальнейшее тестирование среди пользователей. Прототипирование позволяет получить раннюю обратную связь и убедиться, что требования правильно поняты.
- Анализ трассируемости. Установление связей между требованиями и другими артефактами проекта, такими как тестовые случаи, проектное решение и исходный код. Это помогает гарантировать, что каждое требование будет реализовано и протестировано.
- Моделирование. Создание моделей (например, UML-диаграмм), которые помогают визуализировать требования и анализировать их взаимодействия, а также потенциальные проблемы или конфликты.
- Тестирование требований. Разработка тестовых случаев и сценариев, которые напрямую связаны с требованиями. Это проверяет, что требования могут быть реализованы и верифицированы через тестирование.
- Опросы и интервью с заинтересованными сторонами. Проведение обсуждений с пользователями и заинтересованными сторонами для уточнения и подтверждения требований.
- Анализ воздействия. Оценка потенциального влияния каждого требования на существующие системы, процессы и бизнес-цели, чтобы гарантировать их реализуемость и соответствие.
- Групповые сессии. Использование креативных и групповых техник для генерации и обсуждения требований, что может помочь в выявлении недостатков и улучшении понимания требований.
- Формальное утверждение требований. Получение подтверждения от всех ключевых заинтересованных сторон, что они согласны с документированными требованиями.
Эффективная верификация требований требует сочетания различных методов и инструментов, а также активного участия всех заинтересованных сторон проекта.
Участники процесса верификации
Верификация требований в проектах, особенно в области разработки программного обеспечения и систем, может вовлекать различных специалистов в зависимости от сложности проекта, его масштаба и используемой методологии.
Чем отличается верификация и валидация, читайте в нашей статье.
Вот кто обычно участвует в процессе верификации требований:,
- Заинтересованные стороны. Включение заинтересованных сторон в процесс верификации для обеспечения того, что их потребности и ожидания были правильно поняты и учтены.
- Бизнес-аналитики. Они часто являются основными лицами, ответственными за сбор, анализ и верификацию требований. Бизнес-аналитики уделяют внимание тому, чтобы требования были полными, точными и соответствовали бизнес-целям.
- Системные аналитики. Они сосредоточены на том, как требования будут реализованы в рамках технических возможностей системы. Системные аналитики помогают гарантировать, что требования технически осуществимы и не противоречат другим системным ограничениям.
- Разработчики. Разработчики ПО также участвуют в верификации требований, чтобы убедиться, что они понимают требования и могут их реализовать. Они могут предоставлять обратную связь по вопросам реализации и технической сложности.
- Тестировщики. Эти специалисты проверяют, что требования являются тестируемыми. Они обеспечивают, что для каждого требования существует методика тестирования, чтобы подтвердить его реализацию.
- Проектные менеджеры. Они могут участвовать в верификации для обеспечения соответствия требований целям и границам проекта, включая бюджетные и временные рамки.
- Заказчики и пользователи. Вовлечение конечных пользователей и заказчиков критически важно для верификации требований с точки зрения соответствия их ожиданиям и потребностям. Они могут подтвердить, что требования действительно отражают то, что им нужно от системы.
Верификация требований помогает уменьшить риски связанные с неправильным пониманием, недоразумениями или неполными требованиями, что в конечном итоге приводит к более высокому качеству конечного продукта и удовлетворенности клиентов. Поэтому важно, чтобы все результаты верификации должны быть тщательно задокументированы, включая обнаруженные проблемы и предложенные изменения.
Важно помнить, что верификация требований — это не разовое действие, а непрерывный процесс, который может повторяться в течение всего цикла разработки проекта.
Управление изменениями
Управление изменениями требований является критическим компонентом успешного управления проектами, особенно в динамичной среде разработки программного обеспечения. Это процесс, который помогает систематически учитывать, оценивать и внедрять изменения в требования проекта в течение всего его жизненного цикла.
Вот ключевые аспекты управления изменениями требований:
Формальный процесс управления изменениями. Создание четко определенного процесса для обработки запросов на изменение, включая их документирование, оценку и утверждение. Это помогает в поддержании порядка и предотвращает хаотичные изменения.
Логирование и документирование запросов на изменения. Каждый запрос на изменение должен быть задокументирован с указанием его источника, описания, причины и ожидаемого воздействия на проект.
Оценка воздействия изменений. Перед принятием изменения необходимо оценить его влияние на проект, включая сроки, бюджет, ресурсы и другие требования. Это помогает принимать взвешенные решения.
Приоритизация запросов на изменения. Не все изменения имеют одинаковый приоритет. Важно определить, какие из них критически важны, а какие могут быть отложены или отклонены.
Утверждение или отклонение ЗНИ. Процесс должен включать механизмы для утверждения или отклонения изменений, обычно с участием проектных менеджеров, бизнес-аналитиков и других ключевых заинтересованных сторон.
Коммуникация с заинтересованными сторонами. Важно обеспечить, чтобы все заинтересованные стороны были информированы об изменениях, их влиянии и обновленных планах.
Интеграция изменений в план проекта. После утверждения изменений необходимо интегрировать их в текущий план проекта, включая изменение документации требований, планов разработки, тестирования и внедрения.
Аудит и отслеживание. Регулярно проводить аудит процесса управления изменениями для убеждения в его эффективности и внесения необходимых корректировок.
Гибкость и адаптивность. В гибкой (Agile) методологии управления проектами процесс управления изменениями требований должен быть достаточно адаптивным, чтобы учитывать постоянно меняющуюся динамику проекта.
Инструменты для управления изменениями. Использование специализированных инструментов для управления требованиями и изменениями может помочь автоматизировать и упрощать процесс.
Эффективное управление изменениями требований обеспечивает баланс между необходимостью адаптации к изменяющимся условиям и поддержанием стабильности и направленности проекта.
Заключение
Анализ собранных данных требует тщательной работы. Важно не только собрать требования, но и корректно их документировать, классифицировать и приоритизировать. Ключевым моментом является обратная связь с пользователями для верификации собранных данных.
Сбор требований — это не одноразовый процесс, это циклическая деятельность, требующая постоянного пересмотра и адаптации в свете новых информаций и изменений в проекте. Умение грамотно собирать и анализировать требования прямо влияет на качество и успех конечного продукта, делая этот процесс краеугольным камнем в разработке автоматизированных систем.
Если статья была полезна, ставьте палец вверх и подписывайтесь на канал. Свои вопросы и комментарии по теме пишите под статьей или отправляйте нам напрямую. Контакты для связи с нами:
Telegram
Проектный офис erp.lab@1cbit.ru
