Типы требований к ПО с примерами | часть 2
--
Откуда берутся требования? Какие вообще бывают требования? Об этом — читайте в этой статье.
В части 1 мы разобрались, что такое требования, зачем они нужны и почему ими нужно заниматься. Теперь давайте узнаем, откуда их брать, и какими они вообще бывают :)
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
Источники требований
Все требования приходят от заказчиков, или людей связанных с ними (сотрудников, пользователей и тп.)
Для выявления требований чаще всего используются следующие техники:
- Интервью (либо переписка) – опрос, часто в формате вопрос ответ между аналитиком и заказчиком / пользователем
- Фокусные группы – расширенное интервью с несколькими пользователями
- Мозговой штурм – позволяет за короткий промежуток времени собрать большое количество идей, которые в дальнейшем изучаются и анализируются
- Наблюдение – позволяет выявить процессы, о которых не упомянули в интервью, занимает много времени
- Прототипирование – один из лучших способов понять и уточнить требования
Так же существуют более сложные методы, при котором аналитик должен «сам во всем разобраться», и уточнить собранную информацию у заказчиков:
- Анализ документов
- Моделирование процессов
- Самостоятельное описание
Типы требований
Почти в каждом проекте существует 3 заинтересованных стороны:
- Заказчики продукта
- Пользователи продукта
- Разработчики продукта
Все они смотрят на «продукт» со своей колокольни, следовательно требования разделяются на соответствующие группы или уровни.
Уровень заказчика (бизнес-требований)
На этом уровне находится только один тип требований – бизнес требования (business requirements).
Они выражают цель, ради которой создается продукт (зачем он вообще нужен, каким образом он будет приносить прибыль). Они часто представлены простым текстом, без каких либо технических подробностей.
Нужен инструмент, позволяющий помочь отделу поддержки проверять качество выполнения заказов.
Нужно автоматизировать процесс начисления бонусов за приглашенных друзей.
Основываясь на этих требованиях можно получить общее видение проекта.
Уровень пользователя
Описывают “взгляд” на продукт глазами пользователя.
Включает в себя:
- Пользовательские требования (user requirements) — описание задач, которые может выполнять пользователь при помощи системы. Оформляются в виде пользовательских историй (user stories, cases, scenarios). Эти требования могут быть использованы для оценки времени, сложности, стоимости разработки.
После первого входа сотрудника отдела поддержки в систему отображается обучающее видео для ознакомления с функциями приложения.
Аналитик должен иметь возможность в любой момент получить отчет о приглашенных друзьях за указанный промежуток времени.
Пример оформления этих же требований в виде User Stories
Как сотрудник отдела поддержки, я могу просмотреть обучающее видео для ознакомления с функциями приложения после первого входа в систему, чтоб понимать, что я могу в ней делать
Как аналитик, я могу заполнить и отправить форму “получить отчет о друзьях”, и мне на почту придет письмо с .xls отчетом, содержащий информацию о приглашенных друзьях за указанный мной промежуток времени
- Бизнес правила (business rules) — описывают особенности принятых в предметной области процессов, ограничений, правил.
Доступ к инструменту предоставляется только сотрудникам поддержки уровня Main support и выше.
Аналитики не должны иметь возможности изменять полученные отчеты.
- Атрибуты качества (quality attributes) — описывают ключевые показатели качества продукта.
Не зависимо от количества заказов, максимальное время открытия списка проверок не должно превышать 5 секунд.
Система должна работать с большими объёмами данных (сотни тысяч записей).
Уровень разработки (продуктных требований)
Содержит наиболее детализированное описание функций продукта, которые должны быть реализованными.
Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.
К уровню разработки относятся следующие типы требований:
- Функциональные требования (functional requirements) — описывают что должна и что НЕ должна делать система.
Список проверок должен быть отсортирован по конечной дате выполнения (deadline) заказа.
Никакая личная информация пользователя (логин, пароль, номера телефонов, и тд.) не должна отображаться в отчетах.
- Нефункциональные требования (non-functional requirements) — описывают свойства системы при реализации своего поведения. (По сути это более техническое и детальное описание атрибутов качества)
Приложение должно поддерживать работу с мобильных устройств (минимальная ширина экрана – 320 px).
Обьем используемой оперативной памяти не должен превышать 256 Мб .
Как показывает практика, не функциональных требований часто больше, чем функциональных, по-этому их можно разбивать на подгруппы.
Не функциональные требования
Основными подгруппами являются:
- Ограничения (limitations) — факторы, которые ограничивают выбор способов и средств реализации продукта.
Приложение должно работать в последних версиях браузеров Chrome, Firefox, Safari.
Приложение должно работать на Raspberry PI 3b+.
- Требования к интерфейсам (external interfaces requirements) — особенности взаимодействия системы с другими системами
Весь трафик между браузером и сервером должен быть зашифрован (HTTPS соединение).
Отправка письма с отчетом на почту аналитиков должно выполняться согласно RFC3207 (SMTP over TLS).
- Требования к данным (data requirements) — описывают структуры данных, описания баз данных, особенности их использования.
Все данные системы должны храниться в БД под управлением СУБД MySQL.
Для ускорения поиска данных по определенному пользователю должны быть предусмотрены индексы по соответствующим полям таблицы.
- … можно выделять и другие подгруппы, так как эта группа требований основывается на атрибутах качества, которых может быть очень-очень много :)
Теперь у вас есть понимание того, что:
- требования можно получать разными способами
- не все требования одинаковы. Их формат и детализация зависят от уровня, к которому они относятся
Осталось определиться с тем, что такое “качественные” требования, и какими свойствами они должны обладать, чтоб с ними было проще работать в дальнейшем.
Об этом — в следующей статье ⬇️
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
Тебе не хватает практики по тестированию?
👉 Получи практическое задание!
Хочешь расти быстрей, как профессионал?
👉 Оставляй заявку на менторство!
Понравилась статья? Есть еще:
