Четко определенные требования являются важными признаками на пути к успешному проекту. Они устанавливают официальное соглашение между клиентами и поставщиками о том, что они оба работают над достижением одной и той же цели. Качественные и подробные требования также помогают снизить финансовые риски и обеспечить соблюдение графика проекта. В этой статье мы обсудим требования к разрабатываемым продуктам на примере разрабтки ПО и дадим рекомендации по их использованию.
- Типы требований
- Бизнес-требования
- Требования пользователя (заинтересованных сторон)
- Требования к решению
- Требования перехода
- Функциональные и нефункциональные требования
- Что такое функциональные требования?
- Примеры функциональных требований
- Что такое нефункциональные требования?
- Примеры нефункциональных требований
- Типы функциональных требований
- Типы нефункциональных требований
- Удобство использования
- Безопасность
- Надежность
- Производительность
- Доступность
- Масштабируемость
- Сбор и управление требованиями
- Документы с функциональными и нефункциональными требованиями
- Документ спецификации требований к программному обеспечению
- Функциональная декомпозиция и структуры иерархии работ (WBS)
- Форматы требований: варианты использования и пользовательские истории
- Случаи использования
- Истории пользователей
- Рекомендации по документированию требований
- Прототипы: понимание и требования к тестированию
Типы требований
Согласно определению, содержащемуся в Своде знаний по бизнес-анализу (BABOK), требования — это полезное представление потребности. BABOK, признанный набор отраслевых стандартов бизнес-анализа, предлагает следующую классификацию требований.
Бизнес-требования
К ним относятся заявления высокого уровня о целях, задачах и потребностях. Бизнес-требования не имеют каких-либо подробностей или особенностей. Они просто формулируют проблему и бизнес-цель, которую необходимо достичь, например:
- увеличение дохода/пропускной способности/охвата клиентов,
- сокращение расходов/ошибок,
- улучшение обслуживания клиентов и т. д.
Требования пользователя (заинтересованных сторон)
Эта группа требований отражает потребности отдельных групп заинтересованных сторон (менеджеров высшего уровня, неуправленческого персонала, клиентов и т. д.) и определяет, чего они ожидают от конкретного решения. Они служат мостом между обобщенными бизнес-требованиями и конкретными требованиями к решению. Они изложены в Спецификации требований пользователя и могут включать, например, возможность создания различных отчетов, просмотра истории и статуса заказов , управления базами данных клиентов и т. д.
Требования к решению
Требования к решению описывают конкретные характеристики, которыми должен обладать продукт, чтобы удовлетворить потребности заинтересованных сторон и самого бизнеса. Они делятся на две большие группы.
- Функциональные требования определяют, что должен делать продукт, каковы его особенности и функции.
- Нефункциональные требования описывают общие свойства системы. Они также известны как атрибуты качества.
Требования перехода
Дополнительная группа требований определяет, что необходимо организации для успешного перехода от текущего состояния к желаемому состоянию с новым продуктом. Они необходимы лишь на короткое время, пока происходит переход. Примеры:
- «пользователи должны пройти обучение для работы с системой» или
- «предыдущие данные должны быть перенесены в облачное хранилище».
В этой статье исследуются функциональные и нефункциональные типы требований. Итак, давайте сравним их.
Функциональные и нефункциональные требования
Функциональные и нефункциональные требования — две фундаментальные категории требований при разработке программного обеспечения. Каждый тип играет жизненно важную роль в определении характеристик и работы решения.
Функциональные требования | Нефункциональные требования | |
Цель | Опишите, что делает продукт | Опишите, как работает продукт |
Конечный результат | Определите особенности продукта | Определить свойства продукта |
Фокус | Сосредоточьтесь на требованиях пользователей | Ориентируйтесь на ожидания пользователей |
Обязательность | Они обязательны | Они не обязательны, но желательны |
Тип происхождения | Обычно определяется пользователем | Обычно определяется разработчиками или другими техническими экспертами. |
Тестирование | Тестирование компонентов, API, Ul и т. д.Протестировано перед нефункциональным тестированием. | Тестирование производительности, удобства использования, безопасности и т. д. Проверено после функционального тестирования. |
Типы | Аутентификация, уровни авторизации, обработка данных, отчетность и т. д. | Удобство использования, надежность, масштабируемость, производительность и т. д. |
Что такое функциональные требования?
Функциональные требования — это особенности или функции продукта, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи. Поэтому очень важно сделать их понятными как для команды разработчиков, так и для заинтересованных сторон. Как правило, функциональные требования описывают поведение системы в конкретных условиях.
Примеры функциональных требований
Функциональные требования будут различаться для разных типов программного обеспечения. Например, функциональные требования к веб-сайту или мобильному приложению должны определять потоки пользователей и различные сценарии взаимодействия.
- Система отправляет электронное письмо с подтверждением при создании новой учетной записи пользователя.
- Система отправляет запрос на одобрение после того, как пользователь вводит личную информацию.
- Функция поиска позволяет пользователям искать контент/элементы, вводя запрос в строку поиска.
- Пользователь может просмотреть товары в корзине, изменить их количество или удалить их перед оформлением заказа.
- Приложение должно позволять пользователям создавать учетные записи и входить в систему, используя учетные данные, такие как адрес электронной почты и пароль, или посредством интеграции с социальными сетями.
- Приложение может отправлять пользователям уведомления об обновлениях, напоминаниях или рекламном контенте.
- Пользователи должны иметь возможность оставлять отзывы или оценивать услуги/продукты в приложении.
Это некоторые общие функциональные требования. Более специализированные программные системы будут иметь более конкретные требования. Например, система управления гостиничным имуществом будет включать такие требования, как «пользователь должен иметь возможность просматривать и обновлять статус номера» или «система должна объединять счета со всех точек обслуживания».
Что такое нефункциональные требования?
Нефункциональные требования не связаны с функциональностью системы, а скорее определяют, как система должна работать. Они имеют решающее значение для обеспечения удобства использования, надежности и эффективности системы, часто влияя на общее впечатление пользователя. Далее мы подробно опишем основные категории нефункциональных требований.
Примеры нефункциональных требований
Некоторые примеры нефункциональных требований:
- Страницы сайта должны загружаться за 3 секунды при общем количестве одновременных пользователей <5 тысяч.
- Система должна быть способна обслуживать 20 миллионов пользователей без ухудшения производительности.
- Шлюз обработки платежей должен соответствовать стандарту PCI DSS.
- Программа, работающая в Windows 10, должна иметь возможность работать в Windows 11 без каких-либо изменений в ее поведении и производительности.
Типы функциональных требований
Функциональные требования различаются в зависимости от функций, которые они описывают. Согласно этому классификационному подходу можно выделить следующие виды функциональных требований.
- Аутентификация. Эта группа занимается проверкой личности пользователя перед предоставлением доступа к системе, включая ввод имен пользователей и паролей, биометрическую проверку или многофакторную аутентификацию.
- Уровни авторизации. Эти требования направлены на определение и контроль уровней доступа различных пользователей в системе. Например, администратор может иметь полный доступ к системе, а обычный пользователь имеет ограниченный доступ к определенным функциям.
- Обработка данных. Эти требования могут включать ввод данных, проверку, хранение и извлечение.
- Пользовательский интерфейс и пользовательский опыт (UI/UX). Это требования, связанные с дизайном и взаимодействием элементов системы. Их цель — обеспечить удобство использования и удовлетворение потребностей пользователей.
- Составление отчетов. Эти требования определяют создание отчетов, например, источники данных, форматы и т. д.
- Системная интеграция. Эти требования описывают, как система взаимодействует и интегрируется с другими системами или сторонними сервисами.
- Обработка транзакций. Эта группа содержит требования к обработке транзакций. Они особенно важны в системах, которые имеют дело с финансовыми процессами или требуют ведения учета транзакций.
- Обработка и протоколирование ошибок. Эти требования определяют, как система должна обрабатывать ошибки и регистрировать их, например, определять сообщения об ошибках, шаги по устранению неполадок и вести журналы системных действий.
- Резервное копирование и восстановление. Это требования к процессам резервного копирования данных и восстановления системы, обеспечивающие целостность данных и доступность системы в случае сбоя.
Типы нефункциональных требований
Как мы уже упоминали, нефункциональные требования описывают, как должна вести себя система, и устанавливают ограничения на ее функциональность. Этот тип требований также известен как атрибуты качества системы.
Здесь мы лишь кратко опишем наиболее типичные нефункциональные требования.
Удобство использования
Удобство использования определяет, насколько сложно пользователю будет изучить систему и работать с ней. Мы можем оценить удобство использования с разных точек зрения:
- Эффективность использования: среднее время, необходимое для достижения целей пользователя, сколько задач пользователь может выполнить без посторонней помощи, количество транзакций, завершенных без ошибок и т. д.
- Интуитивность: насколько это просто. Заключается в понимании интерфейса, кнопок, заголовков и т. д.
- Низкая воспринимаемая рабочая нагрузка: сколько попыток пользователю необходимо для выполнения определенной задачи.
Примеры:
- Требования к удобству использования могут учитывать языковые барьеры и задачи локализации: люди, не понимающие русского языка, должны иметь возможность использовать продукт.
- Или вы можете установить требования к доступности: пользователи клавиатуры, которые перемещаются по веб-сайту с помощью, должны иметь возможность добраться до кнопки «Добавить в корзину» на странице продукта за 15 кликов.
Безопасность
Требования безопасности обеспечивают защиту от несанкционированного доступа к системе и хранящимся в ней данным. Он учитывает разные уровни авторизации и аутентификации для разных ролей пользователей. Например, конфиденциальность данных — это характеристика безопасности, которая описывает, кто может создавать, просматривать, копировать, изменять или удалять информацию. Безопасность также включает защиту от вирусов и атак вредоносных программ.
Пример: Только администратор данных системы может изменять права доступа к определенной системной информации. Изменения могут быть сделаны только администратором данных системы.
Надежность
Надежность определяет, насколько вероятно, что программное обеспечение будет работать без сбоев в течение заданного времени. Надежность снижается из-за ошибок в коде, аппаратных сбоев или проблем с другими компонентами системы.
Пример: процесс обновления базы данных должен откатить все связанные обновления, если какое-либо обновление не удалось.
Производительность
Производительность — это атрибут качества, который описывает реакцию системы на различные взаимодействия с пользователем. Низкая производительность приводит к негативному пользовательскому опыту. Это также ставит под угрозу безопасность системы, когда она перегружена.
Пример. Время загрузки главной страницы не должно превышать 2 секунд для пользователей, которые заходят на веб-сайт с помощью мобильного соединения LTE.
Доступность
Доступность отражает время, в течение которого функциональные возможности и услуги системы доступны для использования во всех операциях. Таким образом, периоды планового технического обслуживания напрямую влияют на этот параметр. И важно определить, как можно свести к минимуму влияние технического обслуживания. При написании требований к доступности команда должна определить наиболее важные компоненты системы, которые должны быть доступны в любое время. Также следует подготовить уведомления пользователей на случай, если система или одна из ее частей станет недоступной.
Пример. Развертывание нового модуля не должно влиять на доступность главной страницы, страниц продукта и страницы оформления заказа и не должно занимать больше одного часа. На остальных страницах, на которых могут возникнуть проблемы, должно отображаться уведомление с таймером, показывающим, когда система снова заработает.
Масштабируемость
Требования к масштабируемости описывают, как система должна расти, не оказывая негативного влияния на ее производительность. Это означает обслуживание большего количества пользователей, обработку большего количества данных и выполнение большего количества транзакций. Масштабируемость имеет как аппаратное, так и программное обеспечение. Например, вы можете повысить масштабируемость, добавив память, серверы или дисковое пространство. С другой стороны, вы можете сжимать данные, использовать алгоритмы оптимизации и т. д.
Пример: лимит посещаемости веб-сайта должен быть достаточно масштабируемым, чтобы поддерживать 200 000 пользователей одновременно.
Теперь, когда мы обсудили, что такое функциональные и нефункциональные требования, давайте поговорим о том, как их собирать, документировать и управлять ими на протяжении всего проекта.
Сбор и управление требованиями
Сбор требований и управление требованиями — два важнейших этапа любого проекта.
Сбор требований (или выявление требований) включает в себя определение конкретных потребностей и ожиданий заинтересованных сторон в отношении новой системы, программного приложения или любого другого проекта. По сути, речь идет о понимании того, что нужно делать.
Вкратце, процесс сбора требований состоит из трех основных частей.
- Определите заинтересованные стороны – определите, на кого будет влиять проект и кто должен внести свой вклад.
- Собирайте информацию – используйте интервью, опросы, семинары и другие методы для сбора информации о потребностях и ожиданиях заинтересованных сторон.
- Требования к документам – запишите собранную информацию в форматах документации, описанных выше.
Обычно за сбор требований отвечают бизнес-аналитики, хотя иногда к ним также привлекаются владельцы продуктов или менеджеры продуктов.
Управление требованиями направлено на обеспечение того, чтобы все требования выполнялись в процессе разработки, а любые изменения тщательно контролировались и документировались.
Ключевыми компонентами управления требованиями являются
- расстановка приоритетов – определение того, какие требования являются наиболее важными и должны быть реализованы в первую очередь;
- управление изменениями – обработка изменений требований контролируемым образом, чтобы предотвратить расползание объема;
- прослеживаемость – отслеживание всех требований и обеспечение их выполнения на протяжении всего жизненного цикла проекта ; и
- верификация и валидация – обеспечение того, что разработанная система соответствует всем выявленным требованиям и что эти требования выполняют свое прямое назначение.
Следующий важный вопрос, который необходимо изучить, — какие документы и форматы можно использовать для фиксации требований.
Документы с функциональными и нефункциональными требованиями
Требования обычно записываются в виде текста, особенно для проектов, основанных на Agile. Однако они также могут быть визуальными. Наиболее распространенным документом, описывающим систему и перечисляющим требования, является SRS — спецификации требований к ПО.
Документ спецификации требований к программному обеспечению
Мы можем формализовать функциональные и нефункциональные требования в документе спецификации требований к программному обеспечению (SRS), который содержит описания функций и возможностей, которые должен предоставлять продукт. Он также определяет ограничения и предположения.
Мы не рекомендуем составлять SRS для всего решения до начала разработки, но вам следует документировать требования для каждой функции перед ее созданием. Как только вы получите первоначальный отзыв пользователя, вы сможете обновить документ.
Документация должна включать следующие разделы:
- Цель. Определения, обзор системы и предыстория.
- Общее описание. Предположения, ограничения, бизнес-правила и видение продукта.
- Особые требования. Системные атрибуты, функциональные требования и требования к базе данных.
Очень важно сделать документ ясными и понятными для всех заинтересованных сторон. Используйте шаблоны с визуальными эффектами, которые помогут структурировать информацию и сделать ее более понятной. Если у вас есть требования, хранящиеся в других форматах документов, предоставьте ссылку на них, чтобы читатели могли найти необходимую информацию.
Пример оглавления документа требований. Он включает в себя все упомянутые выше пункты, а также варианты использования для иллюстрации частей продукта.
ШАБЛОН SRS
- Введение
1.1. Цель
1.2. Соглашения о документе
1.3. Объем проекта
1.4. Ссылки - Общее описание
2.1. Перспектива продукта
2.2. Классы пользователей и характеристики
2.3. Операционная среда
2.4. Ограничения проектирования и реализации
2.5. Предположения и зависимости - Возможности системы
3.x Системная функция X
3.х.1 Описание
3.x.2 Функциональные требования - Требования к данным
4.1 Логическая модель данных
4.2 Словарь данных
4.3 Отчеты
4.4 Сбор, целостность, хранение и удаление данных - Требования к внешнему интерфейсу
5.1. Пользовательские интерфейсы
5.2. Программные интерфейсы
5.3 Аппаратные интерфейсы
5.4. Интерфейсы связи - Атрибуты качества
6.1. Удобство использования
6.2. Производительность
6.3. Безопасность
6.4. Сохранность
6.х другие - Требования к интернационализации и локализации
- Прочие требования
Приложение A: Глоссарий и Приложение B: Модель
Функциональная декомпозиция и структуры иерархии работ (WBS)
Функциональная декомпозиция — это процесс разделения сложной проблемы, системы или структуры на более простые и понятные части. В разработке ПО функциональная декомпозиция помогает создать подробное визуальное представление функциональности системы — структуру иерархии работ.
Структура иерархии работ, или WBS, — это документ, который иллюстрирует, как сложные процессы разбиваются на более простые компоненты. WBS — это эффективный подход, позволяющий провести независимый анализ каждой части. Это также помогает получить полную картину проекта.
Мы предлагаем следующую логику функциональной декомпозиции:
- Найдите самую общую функцию.
- Найдите ближайшую подфункцию.
- Найдите следующий уровень подфункции.
- Проверьте свою схему.
Или процесс декомпозиции может выглядеть так:
Функция высокого уровня -> Подфункция -> Процесс -> Деятельность.
Мы должны разложить функции до такой степени, что части самого низкого уровня не могут быть разбиты дальше.
Важно понимать, что WBS отражает только функциональные требования, поэтому вам следует иметь дело с ним вместе со списком нефункциональных требований, чтобы иметь полную и точную картину.
Форматы требований: варианты использования и пользовательские истории
Поскольку нам необходимо сделать функциональные и нефункциональные требования понятными для всех заинтересованных сторон, мы должны зафиксировать их в удобном для чтения формате. Двумя наиболее типичными форматами являются варианты использования и пользовательские истории.
Случаи использования
Варианты использования описывают взаимодействие между системой и внешними пользователями, которое приводит к достижению определенных целей.
Каждый вариант использования включает в себя три основных элемента:
- Агенты. Это внешние пользователи, которые взаимодействуют с системой.
- Система. Система описывается функциональными требованиями, которые определяют предполагаемое поведение продукта.
- Цели. Цели взаимодействия пользователей и системы обозначены как цели.
Существует 2 способа представления вариантов использования: спецификация вариантов использования и диаграмма вариантов использования.
Спецификация варианта использования представляет собой последовательность событий и другую информацию, связанную с этим вариантом использования.
Типичный шаблон спецификации варианта использования включает следующую информацию:
- Описание,
- Состояние до и после взаимодействия,
- Основной путь взаимодействия,
- Альтернативный путь и
- Путь исключения.
Диаграмма вариантов использования не содержит большого количества деталей. Она показывает общий обзор отношений между участниками, различными вариантами использования и системой.
Диаграмма вариантов использования включает в себя следующие основные элементы.
- Случаи использования. Варианты использования, обычно нарисованные овалами, представляют собой различные сценарии взаимодействия, которые могут иметь участники с системой (вход в систему, совершение покупки, просмотр товаров и т. д . ).
- Границы системы. Границы очерчены рамкой, которая группирует различные варианты использования в системе.
- Агенты. Это рисунки, изображающие внешних пользователей (людей или системы), взаимодействующих с системой.
- Ассоциации. Ассоциации рисуются линиями, показывающими различные типы отношений между участниками и вариантами использования.
Истории пользователей
Пользовательская история — это документированное описание функциональности программного обеспечения, рассматриваемое с точки зрения конечного пользователя. Пользовательская история описывает, что именно пользователь хочет от системы. В проектах Agile пользовательские истории организованы в бэклог. В настоящее время пользовательские истории считаются лучшим форматом для элементов невыполненной работы.
Типичная история пользователя выглядит так:
Как <тип пользователя>, я хочу <какую-то цель>, чтобы <какая-то причина>.
Пример. Как администратор, я хочу добавить описания продуктов, чтобы пользователи могли позже просмотреть эти описания и сравнить продукты.
Пользовательские истории должны сопровождаться критериями приемки. Это условия, которым должен удовлетворять продукт, чтобы быть принятым пользователем, заинтересованными сторонами или владельцем продукта.
Каждая пользовательская история должна иметь хотя бы один критерий приемки.
Эффективные критерии приемки должны быть проверяемыми, краткими и полностью понятными всем членам команды и заинтересованным сторонам.
Мы можем записать их в виде контрольных списков, в виде обычного текста или в формате «Дано/Когда/Тогда».
Ниже приведен пример контрольного списка критериев приемки пользовательской истории, описывающей функцию поиска.
Поле поиска доступно в верхней панели.
Поиск начинается, когда пользователь нажимает кнопку «Отправить» .
Заполнителем по умолчанию является серый текст . Введите имя .
Заполнитель исчезает, когда пользователь начинает печатать.
Язык поиска — английский.
Пользователь может ввести не более 200 символов.
Он не поддерживает специальные символы. Если пользователь ввел специальный символ в поле поиска, отображается предупреждающее сообщение: Ввод поиска не может содержать специальные символы .
Наконец, все пользовательские истории должны соответствовать модели качества INVEST:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
- I – Независимый
- N – Договорной
- V – Ценный
- E – Оцениваемый
- S – Маленький
- Т – Проверяемый
Независимый. Вы можете запланировать и реализовать каждую пользовательскую историю отдельно. Очень полезно использовать процессы непрерывной интеграции.
Договорной. Все стороны соглашаются отдавать приоритет переговорам, а не спецификациям. Детали будут создаваться постоянно во время разработки.
Ценный. История должна быть ценной для клиента. Вы должны спросить себя с точки зрения клиента, «почему» вам необходимо реализовать данную функцию.
Достойно оценки. Качественную пользовательскую историю можно оценить. Это поможет команде составить график реализации и расставить приоритеты. Чем масштабнее история, тем труднее ее оценить.
Маленький. Хорошие пользовательские истории, как правило, достаточно малы, чтобы можно было планировать короткие выпуски. Небольшие истории позволяют сделать более конкретные оценки.
Тестируемый. Если мы сможем проверить историю, она будет достаточно ясной и хорошей. Протестированные истории означают, что требования выполнены и готовы к использованию.
Рекомендации по документированию требований
Создание документации является неотъемлемой частью любого проекта разработки программного обеспечения. Хорошо документированные требования гарантируют, что заинтересованные стороны и разработчики находятся на одной волне, и помогают определить объем и бюджет проекта. Вот несколько полезных советов о том, как создавать отличную документацию.
Требования должны быть четкими и понятными. Убедитесь, что вы формулируете требования кратко, без двусмысленностей и различных интерпретаций. Также старайтесь избегать технологического жаргона. Помните, что каждая аудитория индивидуальна, и заинтересованные стороны могут быть не знакомы со специализированной технической терминологией. Вместо этого обогатите свои документы визуальными эффектами, диаграммами и графиками, чтобы поддержать информацию и облегчить ее восприятие. Добавление глоссариев и перекрестных ссылок также полезно.
Требования должны быть конкретными, точными и полными. При написании документации соблюдайте последовательность языка и убедитесь, что ваши требования точны. Они должны охватывать все сценарии, но никогда не противоречить друг другу. Избегайте расплывчатости и слабых фраз, таких как «система должна работать быстро» или «когда что-то произойдет». Будьте конкретны и дайте количественную оценку терминам, чтобы все читатели могли понять их одинаково.
Требования должны быть проверяемыми. Пишите требования, чтобы после создания продукта тестирование могло показать, успешно ли они доставлены.
Требования должны быть выполнимыми и разумными. Сосредоточьтесь на функциональности и качественных характеристиках, которые нужны пользователям. Помните, что требования должны отражать бизнес-цели более высокого уровня.
Прототипы: понимание и требования к тестированию
Прежде чем продукт будет готов, часто необходимо увидеть, как реализованы функциональные требования или как будет работать будущий продукт. Вот почему создаются прототипы, каркасы и макеты. Они представляют, как будет выглядеть решение, и дают представление о том, как пользователи будут с ним взаимодействовать. Таким образом, они помогают устранить пробелы в видении и позволяют заинтересованным сторонам и командам получить общее представление о продуктах, находящихся в разработке.
Прототип программного обеспечения на самом деле является общим термином для различных результатов ранней стадии, которые созданы для демонстрации того, как могут быть реализованы требования. Его основная форма — каркасная.
Каркасы — это низкокачественные графические структуры веб-сайта или приложения. Они помогают сопоставить различные страницы продукта с разделами и интерактивными элементами.
Мокапы (макеты). Каркасы можно превратить в макеты — визуальные конструкции, передающие внешний вид конечного продукта. Со временем макеты могут стать окончательным дизайном продукта.
Прототипы. Следующий этап — создание прототипа продукта, который позволяет командам и заинтересованным сторонам понять, чего не хватает или как продукт можно улучшить. Часто после взаимодействия с прототипами существующий список требований корректируется.