Функциональные требования что это
Требования, какие и зачем
Mar 14, 2019 · 4 min read
AnalystBlog
Блог серийного аналитика. Если для вас «анализ» не пустой звук, вы хотите научиться выявлять и формулировать…
Какие бывают требования?
В статье я буду использовать классификацию Вигерса, как одну из самых распространенных и достаточно подробных. На самом деле классификации требований (как и определения требований) существует довольно много, но они плюс-минус все похожи.
По ходу статьи я буду давать свои комментарии под такими сносками.
И так, по Вигерсу все требования делятся на два лагеря: функциональные и нефункциональные.
Функциональные требования в свою очередь подразделяются на:
Нефункциональные требования подразделяются на:
Вот вам для наглядности классическая картинка из Вигерса:
Остановимся на каждом типе требований подробнее.
Функциональные требования
Как понятно из названия это требования непосредственно к функциональности системы (сервиса, приложения), которую от нее ожидают.
Бизнес-требова н ия — описывают цель создания системы с точки зрения организации, т.е. какие задачи с помощью создаваемой системы планирует решить организация и какую пользу этот ей принесет.
Бизнес-требования, как правило, фиксируются в концепте ( concept) или уставе проекта ( project charter), иногда еще в так называемом в документе рыночных требований ( market requirements document). В общем, в любом верхнеуровневом документе, который описывает образ и границы системы.
Если требования собираются для модуля существующей системы или небольшого приложения, т.е. без выделения отдельного проекта, то бизнес-требования фиксируются в отдельном разделе документа с функциональными требованиями. Обычно достаточно указать бизнес-цель создания системы, и то, каким образом планируется достичь эту цель.
Требования пользователей ( user requirements) описывают цели и задачи, которые пользователям позволит решить система. Простым языком я бы называл это “хотелки” пользователей. В отдельный документ такие требования конечно не выносятся, а просто фиксируются в виде “Пользовательских Историй” ( User Story) в тасктрекерах.
В мире гибких методологий (Agile, Scrum) беклог вашего проекта как раз наполняется подобными User Stories, при этом я всегда рекомендую аналитика подниматься от этих требований вверх, чтобы точно понимать какую цель преследует та или иная хотелка.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, что-бы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда их именуют “требованиями поведения” (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования фиксируются в отдельном документе который и будет основным документом используемым командой в процессе разработки и тестирования, обычно его называют SRS (Software Requirement Specification).
Термином системные требования ( system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы. Так пишет Вигерс, и лично мне это кажется непонятным, потому раскрою тут подробнее. Многие ошибочно полагают что системные требования это верхний уровень требований к системе, или требования к железу на котором система будет работать. На самом деле все проще — системные требования, это тоже самое что и пользовательские требования, но от других систем, т.е. говоря русским языком — это требования по интеграции вашей системы в корпоративный ландшафт.
Системные требования — это требования которые предъявляют вашей системе системы с которыми запланирована интеграция.
Обычно системные требования фиксируются: в контрактах заключаемых между системами, или в заголовочных файлах (хэдерах).
Я не рекомендую описывать системные требования в SRS, т.к. SRS это все же внутренний документ, которым будут пользоваться только ваши разработчики, в то время как контракт или хэдер — общие документы, и им пользуются обе стороны взаимодействия, потому в SRS вставляем только ссылку на контракт/хэдер, а все описание взаимодействия оставляем там.
Фух, разобрались с функциональными, перейдем к НФТ.
Нефункциональные требования (НФТ)
Про эти требования все постоянно забывают, ввиду нехватки времени и кажущейся неважности этих самых НФТ. Но тем не менее, знать и помнить про них надо обязательно.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес правила обычно фиксируются в SRS, в разделе ограничений.
Иногда к бизнес-правилам относят и различные негласные внутрикорпоративные договоренности, если вы новенький в компании не забудьте уточнить их наличие.
Атрибуты качества ( quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Атрибуты качества обычно фиксируются в соответствующем разделе SRS.
Иногда атрибуты качества называют “критерии успеха” — имея ввиду что по этим критериям пользователи будут оценивать будут оценивать качество вашей системы. Желательно выявить их на этапе сбора требований, и зафиксировать в user story и SRS. Т.о. вы не забудете предусмотреть реализацию мониторинга за этими показателями.
Ограничения ( constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, а так же описывают внешние взаимодействия между системой и внешним миром.
Спасибо что дочитали до конца, надеюсь, статья оказалась для вас полезной!
Все самое свежее в моем телеграм-канале, присоединяйтесь:
Функциональные и нефункциональные требования: полное руководство
Точно знать, какие функции и возможности клиент хочет от приложения, довольно сложно для команды разработчиков программного обеспечения. Во избежание недоразумений заказчику и команде разработчиков программного обеспечения необходимо определить требования к проекту: как функциональные, так и нефункциональные требования для будущего приложения. В этой статье мы объясним разницу между двумя типами требований и поделимся лучшими практиками их сбора.
Что такое функциональные требования?
При разработке программного обеспечения функциональные требования определяют функции, которые должно выполнять все приложение или только один из его компонентов. Функция состоит из трех шагов: ввод данных — поведение системы — вывод данных. Он может вычислять, манипулировать данными, выполнять бизнес-процессы, устанавливать взаимодействие с пользователем или выполнять любые другие задачи.
Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.
Функциональные требования важны, поскольку они показывают разработчикам программного обеспечения, как должна вести себя система. Если система не соответствует функциональным требованиям, значит, она не работает должным образом.
Что такое нефункциональные требования?
Нефункциональные требования определяют стандарты производительности и атрибуты качества программного обеспечения, например удобство использования системы, эффективность, безопасность, масштабируемость и т.д.
В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд.
Если приложение не соответствует нефункциональным требованиям, оно продолжает выполнять свои основные функции, однако не сможет обеспечить удобство для пользователя.
Нефункциональные требования важны, поскольку они помогают разработчикам программного обеспечения определять возможности и ограничения системы, которые необходимы для разработки высококачественного программного обеспечения. Следовательно, нефункциональные требования так же важны, как и функциональные требования для успешного внедрения продукта.
Почему важна разница между функциональными и нефункциональными требованиями?
Четко определенные функциональные и нефункциональные требования помогают разработчикам программного обеспечения создавать продукт, точно соответствующий потребностям клиента. Однако действительно ли необходимо знать разницу между функциональными и нефункциональными требованиями?
Основная причина знать разницу между функциональными и нефункциональными требованиями заключается в том, что они определяют объем работ по проекту. Разработчики программного обеспечения должны идти в ногу с этим объемом, чтобы разработать приложение в рамках своих временных рамок и бюджета.
Если объем работ постоянно меняется, команде разработчиков приходится продлевать сроки, и затраты на разработку возрастают. Это может привести к неблагоприятным последствиям для проекта.
Важность различения двух типов требований имеет первостепенное значение при создании MVP. Команда разработчиков и заказчик должны обсудить, какие функции и функции следует реализовать в приложении в первую очередь. Заказчик может иметь собственное видение проекта и его требований. Если заказчик решает удалить или изменить какую-либо функцию, важно понимать, что это за требование. В большинстве случаев разработчики программного обеспечения могут просто изменить нефункциональные требования, в то время как функциональные требования потребуют дополнительной работы и серьезных изменений.
Когда заказчик и поставщик разработки программного обеспечения знают разницу между функциональными и нефункциональными требованиями, это помогает им более точно определять объем работ, более точно ранжировать требования по важности, оптимизировать затраты на проект и лучше удовлетворять потребности заказчика..
Как собираются функциональные и нефункциональные требования?
В идеале, прежде чем обращаться в компанию по разработке программного обеспечения, у клиентов уже должны быть под рукой все функциональные и нефункциональные требования. Поэтому их необходимо подготовить заранее самостоятельно или попросить стороннего поставщика.
Давайте посмотрим, что включает в себя каждый тип требований.
Функциональные требования можно разделить на три группы:
Нефункциональные требования подпадают под различные категории, в том числе:
Примеры и передовой опыт
Существует множество других форматов, которые могут помочь в выполнении требований проекта. Давайте посмотрим на самые эффективные.
Истории пользователей
Обычно требования формулируются в виде пользовательских историй. Пользовательские истории — это требования, предъявляемые пользователем. Обычно они имеют форму нескольких простых предложений, имеющих один и тот же образец:
Как (пользователь) я хочу (цель), чтобы (причина).
Пример пользовательской истории: как руководитель проекта я хочу понимать прогресс команды разработки программного обеспечения, чтобы я мог сообщить о результатах генеральному директору и заинтересованным сторонам проекта.
Разработчики программного обеспечения обычно составляют требования с использованием пользовательских историй, когда они хотят донести идеи о функциях и функциях продукта до участников, не являющихся техническими специалистами.
Сценарии использования
Сценарии использования шире, чем пользовательские истории. Они включают типы пользователей и все возможные действия, которые пользователь может выполнять в приложении. В отличие от пользовательских историй, описывающих конечную цель функции, варианты использования включают последовательность шагов, ведущих к цели.
Например, если вы хотите создать приложение для управления логистикой и цепочкой поставок, разработчики программного обеспечения должны подумать о следующих ролях: продавцы, покупатели, поставщики, менеджеры, диспетчеры и многие другие.
Действия для этих ролей могут выглядеть следующим образом:
Документ со спецификацией требований к программному обеспечению
Спецификация требований к программному обеспечению ( SRS ) — это документ, на который группа разработчиков программного обеспечения полагается при создании приложения. Он включает в себя все потребности и пожелания клиентов, переведенные на понятный для команды разработчиков язык — подробное описание всех функций и возможностей продукта.
Основные разделы, которые обычно включаются в документ SRS:
Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.
Однако есть и другие документы, не менее важные для успешного запуска и развития проекта.
Заключение
С помощью специализированных программных услуг компании могут создавать приложения любого типа для эффективного развития своего бизнеса. Однако для того, чтобы приложение действительно соответствовало потребностям их бизнеса, оно должно иметь подробные функциональные и нефункциональные требования.
Чтобы сформировать функциональные и нефункциональные требования, вы можете обратиться за помощью к своей компании-разработчику программного обеспечения, сторонним компаниям или сделать это самостоятельно. Хорошо продуманные требования гарантируют, что ваш партнер по разработке программного обеспечения будет полностью понимать, как разработать цифровое решение, которое полностью соответствует вашим ожиданиям и удовлетворяет потребности вашего бизнеса.
Типы требований к ПО с примерами | часть 2
Jan 1, 2019 · 4 min read
Откуда берутся требования? Какие вообще бывают требования? Об этом — читайте в этой статье.
В части 1 мы разобрались, что такое требования, зачем они нужны и почему ими нужно заниматься. Теперь давайте узнаем, откуда их брать, и какими они вообще бывают 🙂
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
QA_PRO | Тестирование
Информация по обеспечению качества (QA), контролю качества (QC) и тестированию ПО
Источники требований
Все требования приходят от заказчиков, или людей связанных с ними (сотрудников, пользователей и тп.)
Для выявления требований чаще всего используются следующие техники:
Так же существуют более сложные методы, при котором аналитик должен «сам во всем разобраться», и уточнить собранную информацию у заказчиков:
Типы требований
П о чти в каждом проекте существует 3 заинтересованных стороны:
Все они смотрят на «продукт» со своей колокольни, следовательно требования разделяются на соответствующие группы или уровни.
Уровень заказчика (бизнес-требований)
На этом уровне находится только один тип требований – бизнес требования (business requirements).
Они выражают цель, ради которой создается продукт (зачем он вообще нужен, каким образом он будет приносить прибыль). Они часто представлены простым текстом, без каких либо технических подробностей.
Нужен инструмент, позволяющий помочь отделу поддержки проверять качество выполнения заказов.
Нужно автоматизировать процесс начисления бонусов за приглашенных друзей.
Основываясь на этих требованиях можно получить общее видение проекта.
Уровень пользователя
Описывают “взгляд” на продукт глазами пользователя.
После первого входа сотрудника отдела поддержки в систему отображается обучающее видео для ознакомления с функциями приложения.
Аналитик должен иметь возможность в любой момент получить отчет о приглашенных друзьях за указанный промежуток времени.
Пример оформления этих же требований в виде User Stories
Как сотрудник отдела поддержки, я могу просмотреть обучающее видео для ознакомления с функциями приложения после первого входа в систему, чтоб понимать, что я могу в ней делать
Доступ к инструменту предоставляется только сотрудникам поддержки уровня Main support и выше.
Аналитики не должны иметь возможности изменять полученные отчеты.
Не зависимо от количества заказов, максимальное время открытия списка проверок не должно превышать 5 секунд.
Система должна работать с большими объёмами данных (сотни тысяч записей).
Уровень разработки (продуктных требований)
Содержит наиболее детализированное описание функций продукта, которые должны быть реализованными.
Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.
К уровню разработки относятся следующие типы требований:
Список проверок должен быть отсортирован по конечной дате выполнения (deadline) заказа.
Никакая личная информация пользователя (логин, пароль, номера телефонов, и тд.) не должна отображаться в отчетах.
Приложение должно поддерживать работу с мобильных устройств (минимальная ширина экрана – 320 px).
Как показывает практика, не функциональных требований часто больше, чем функциональных, по-этому их можно разбивать на подгруппы.
Не функциональные требования
Основными подгруппами являются:
Приложение должно работать в последних версиях браузеров Chrome, Firefox, Safari.
Приложение должно работать на Raspberry PI 3b+.
Весь трафик между браузером и сервером должен быть зашифрован (HTTPS соединение).
Отправка письма с отчетом на почту аналитиков должно выполняться согласно RFC3207 (SMTP over TLS).
Все данные системы должны храниться в БД под управлением СУБД MySQL.
Для ускорения поиска данных по определенному пользователю должны быть предусмотрены индексы по соответствующим полям таблицы.
Теперь у вас есть понимание того, что:
Осталось определиться с тем, что такое “качественные” требования, и какими свойствами они должны обладать, чтоб с ними было проще работать в дальнейшем.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?