Как написать функциональные требования к программе

Самое полное руководство по управлению требованиями и отслеживаемости

Что такое функциональные требования? Этот вопрос часто ставит в тупик как владельцев бизнеса, так и разработчиков. Функциональное требование можно рассматривать как особенность продукта, которую обнаруживает пользователь. Это может быть очевидная функция, например, большая кнопка «Добавить в корзину».

Но это также может быть и менее очевидная функция, например, правильный расчет налога с продаж для онлайн-покупки пользователя. В этом полном руководстве мы разобьем функциональные требования на их простейшие формы и приведем примеры каждого типа. Мы также определим, что каждый тип требований означает для вашего бизнеса и как их создать.

Функциональные требования: примеры и шаблоны

Что такое функциональные требования?

Функциональное требование — это заявление о том, как должна вести себя система. Он определяет, что система должна делать, чтобы удовлетворить потребности или ожидания пользователя. Функциональные требования можно рассматривать как функции, которые обнаруживает пользователь. Они отличаются от нефункциональных требований, которые определяют, как система должна работать внутри (например, производительность, безопасность и т. д.).

Что такое функциональные требования 🛰 ? Четкая постановка задач разработчику

Функциональные требования состоят из двух частей: функции и поведения. Функция — это то, что делает система (например, «рассчитать налог с продаж»). Поведение определяется тем, как это делает система (например, «Система должна рассчитать налог с продаж путем умножения покупной цены на налоговую ставку»).

Типы функциональных требований

Вот наиболее распространенные типы функциональных требований:

• Деловые правила
• Сертификационные требования
• Требования к отчетности
• Административные функции
• Уровни авторизации
• Отслеживание аудита
• Внешние интерфейсы
• Управление данными
• Правовые и нормативные требования

Создание функциональных требований

При создании функциональных требований важно помнить, что они должны быть конкретными, измеримыми, достижимыми, актуальными и привязанными ко времени (SMART). Другими словами, ваши функциональные требования должны:

• Уточните, что должна делать система
• Быть измеримым, чтобы вы могли сказать, делает ли это система
• Быть достижимым в установленные вами сроки
• Будьте релевантны вашим бизнес-целям
• Будьте привязаны ко времени, чтобы вы могли отслеживать свой прогресс

Следуя этим рекомендациям, вы можете быть уверены, что ваши функциональные требования ясны и помогут вашей команде разработчиков создать правильный продукт.

Примеры:

Чтобы дать вам лучшее представление о функциональных требованиях, давайте рассмотрим несколько примеров.

Пример # 1

: Пользователь должен иметь возможность войти в систему, используя свое имя пользователя и пароль.

В этом примере функция — «вход», а поведение — «Система должна позволять пользователю входить в систему, используя свое имя пользователя и пароль».

4. Функциональные требования, тикеты, JIRA (Курс бизнес-аналитик с нуля)

Пример # 2

: Система рассчитывает налог с продаж для покупки пользователя.

В этом примере функция — «рассчитать налог с продаж», а поведение — «Система должна рассчитать налог с продаж путем умножения покупной цены на налоговую ставку».

Пример # 3

: система отправляет пользователю электронное письмо с подтверждением после того, как он успешно разместил заказ.

В этом примере функция — «отправить электронное письмо с подтверждением», а поведение — «система должна отправить электронное письмо с подтверждением пользователю после того, как он успешно разместил заказ».

Как видите, функциональные требования — это конкретные утверждения о том, что должна делать система. Они отличаются от нефункциональных требований, которые определяют внутреннюю работу системы (например, производительность, безопасность и т. д.).

При создании функциональных требований важно помнить, что они должны быть конкретными, измеримыми, достижимыми, актуальными и ограниченными по времени (SMART). Следуя этим рекомендациям, вы можете быть уверены, что ваши функциональные требования ясны и помогут вашей команде разработчиков создать правильный продукт.

Чем функциональные требования отличаются от нефункциональных требований?

Функциональные требования, как следует из названия, описывают функции разрабатываемой системы. Это описание того, какой будет система и как она будет функционировать для удовлетворения потребностей пользователей. Они обеспечивают четкое описание того, как система должна реагировать на конкретную команду, функции и ожидания пользователей.

Нефункциональные требования объясняют ограничения и ограничения разрабатываемой системы. Эти требования никак не влияют на функциональность приложения. Кроме того, существует обычная практика разделения нефункциональных требований на различные категории, например:

• Пользовательский интерфейс
• Надежность
• Безопасность
• Перфоманс
• Обслуживание
• Стандартный

Подклассификация нефункциональных требований является хорошей практикой. Это помогает при создании контрольного списка требований, которые должны быть выполнены в разрабатываемой системе.

Нефункциональные требования так же важны, как и функциональные. Если функциональные требования определяют, что должна делать система, то нефункциональные требования описывают, как она будет это делать. Например, новое приложение должно предоставить нам окончательный список всех подключенных пользователей. Это часть функциональных требований. Если в требовании говорится, что система будет работать только в системах Windows и Linux, это будет частью нефункциональных требований.

Единственная разница между ними заключается в том, что система не может функционировать, не удовлетворяя всем функциональным требованиям. С другой стороны, система даст вам желаемый результат, даже если она не удовлетворяет нефункциональным требованиям.

Источник: visuresolutions.com

Способ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования

Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (Unified Modeling Language — UML). Несмотря на безусловные плюсы, использование UML сопряжено с рядом трудностей методического характера, на которые мы хотели бы обратить внимание читателя. Прежде всего, в UML вводится собственный понятийный аппарат, в рамках которого традиционные термины и понятия, связанные с созданием автоматизированных систем и используемые в течение десятилетий, заменяются на термины и понятия, не нашедшие пока в полной мере отражения в международных и отечественных стандартах в области информационных технологий.

Особенно это касается базового элемента языка UML «Use Case», который трактуется отечественными переводчиками как «вариант использования», «прецедент». При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно — путаницы возникает все больше и больше.

Так, участники некоторых Интернет- форумов дошли до того, что сравнивают «Use Case» с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.

Как печальный итог, использование терминов и понятий UML, по существу представляющих собой ошибки отечественных переводчиков, в недостаточной мере знакомых с процессами создания АС, привели к тому, что в различных средствах информации появились статьи, книги, модели и прочие источники, имеющие откровенные ошибки в трактовке процессов, моделей, документов, связанных с созданием АС. Особенно это явно проявилось при описании предметной области и определения требований к АС.

В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм «Use Case Diagram» и «Actvity Diagram» универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование «Use Case» в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.

Итак, рассмотрим процесс определения требований согласно действующим отечественным стандартам.

При использовании стандартов создания АС в соответствии с [1, 2] на стадии «Техническое задание» в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии «Эскизное проектирование» и «Техническое проектирование», описание автоматизируемых функций АС производится на стадии «Техническое проектирование».

При разработке АС в соответствии с [1] должны быть отслежены связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны.

В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций [1-3].

Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:

технического задания;
предварительной схемы функциональной структуры системы (эскизное проектирование);
окончательной схемы функциональной структуры (техническое проектирование);
описания автоматизируемых функций системы.

Таблица 1. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими

№ стадии по ГОСТ 34.601-90

Наименование
стадии по ГОСТ 34.601-90

Документы, модели, создаваемые на стадиях по

ГОСТ 34.602-89,
ГОСТ 34.201-89

ГОСТ, в котором описан документ

Техническое задание (ТЗ)

Схема функциональной структуры

РД 50-34.698-90 п. 2.3.

Схема функциональной структуры

РД 50-34.698-90 п. 2.5

В соответствии с [4] ТЗ на АС есть документ, оформленный в установленном порядке и определяющий цели создания АС, требования к АС и основные исходные данные, необходимые для ее разработки, а также план-график создания АС.

В ТЗ определяются:

требования к системе в целом;
требования к функциям (задачам), выполняемым системой;
требования к видам обеспечения.

Функциональные требования к системе определяют, действия системы, которые она должна выполнять. Функциональные требования реализуются через функции системы [5]. Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы [6], а под задачей — функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида [4].

Не функциональные требования есть ограничения, накладываемые на работу системы, и стандарты, которым должна соответствовать система [5].

В схеме функциональной структуры [7] отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком.

В описании автоматизируемых функций [7] приводят:

перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;
описание процесса выполнения функций;

необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком.

Теперь рассмотрим определение требований с использованием понятия «Use Case». Как уже говорилось ранее, в стандарте UML отсутствует привязка к стадиям создания АС, однако, производители CASE — средств для работы с UML и методологий использования UML, как правило, предлагают схожие подходы к работе с требованиями.

Рассмотрим, например, подход компании Sparx System, являющейся производителем инструментария Еnterprise Architect, поддерживающим создание моделей предметной области и АС с использованием UML 2.0. Ими предложен шаблон модели требований, представленный на рис. 1. На рис. 2 представлен пример модели требования с использованием шаблона.

Как видно из шаблона модели требований и его примера для моделирования требований предлагается использовать элемент UML «Requirement». Для моделирования функций системы предлагается использовать элемент «Use Case». При этом элемент «Use Case» в описании UML, представленном в инструменте Еenterprise Architect, трактуется следующим образом: «Use Case elements are used to build Use Case models. These describe the functionality of the system to be built. Use Case Model describes a system’s functionality in terms of Use Cases».

Другими словами, элемент «Use Case» используется для построения модели «Use case Model». Модель «Use case Model» используется для описания функциональности системы.

Под функциональностью системы в соответствии с [8] понимается совокупность свойств программного средства, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности.

В спецификациях OMG UML ( UML Superstructure Specification, v2.0, p. 17 ) элемент «Use Case» определяется как: «The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system».

Другими словами, элемент «Use Case» определяет последовательность действий системы, которые она может выполнять, включая ее взаимодействие с пользователем системы.

Рис. 1. Способ моделирования требований к системе

Рис. 2. Пример реализации требования

В дополнении к сказанному выше, хотелось представить определение модели «Use Case Model» из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process компании IBM: «The use-case model is a model of the system’s intended functions and its environment …»[5] (рис. 3).

Рис. 3. Определение модели «Use Case Model»

Модель «Use case Model» есть модель предполагаемых функций системы и ее окружения, и служит контрактом между клиентами и разработчиками. Модель используется как существенные входные данные в деятельности по анализу, проектированию и тестированию.

В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели «Use Case Model», функции системы и элемента «Use Case» в соответствии с описанием UML 2.0.

Таблица 2. Сравнение определений моделей и их элементов

Определение схемы функциональной структуры

Определение модели «UseCaseModel»

В схеме функциональной структуры отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком

Use Case elements are used to build Use Case models. These describe the functionality of the system to be built.

Use Case Model describes a system’s functionality in terms of Use Cases

Определение элемента «UseCase»

Совокупность действий АС, направленная на достижение определенной цели. Описание процесса выполнения функции включает необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком

The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

Сравнение определения схемы функциональной структуры с определением модели Use Case Model, определения функции системы и элементов «Use Case» показывает, что эти модели и элементы сопоставимы друг с другом.

Таким образом, для моделирования требований к АС мы будем использовать элемент требование «Requirement», а функций, реализующих требование, элемент «Use Case».

В соответствии с [2] описание функционального требования должно включать, связанные с требованием: функции системы, пользователей системы, печатные документы, импортируемые/экспортируемые данные, правила и ограничения, нефункциональные требования, связи между функциональными требованиями, экранные формы.

Предлагается описывать функциональное требование к системе и функции, его реализующие, с использованием следующего шаблона. Описание шаблона дано на примере описания конкретного требования.

Шаблон описания требования

Общие сведения о требовании

Должно быть автоматизировано формирование отчета об остатках товара

Цель, которая будет
достигнута при реализации
требования

Оперативное получение информации о текущих остатках на складе компании

Требование руководителя компании

Пользователи, которым
доступна работа с функциями системы, реализующими требование

Источник данных (ручной ввод, использование записей БД, данных из смежной системы)

Отчет должен формироваться на основе записей в базе данных, содержащих информацию о количестве остатков товара на складе

Правила, связанные с
требованием

Отчет формируется в двух экземплярах

Функции, реализующие требования

Формирование отчета «Остатки товара»

Связи между требованием и функциями

В разделе должно быть представлена модель, отображающая связи между требования и функциями, реализующими требование, и если требуется, описание связей. Модель «Требование и функции»:

Описание процесса выполнения функции

В разделе должны быть представлены модели процесса выполнения функции и их описание. Основные этапы формирования отчета:

Источник: www.interface.ru

Как мы создали шаблон функциональных требований к разработке ПО

Всем привет, мы – Таня и Лиза, системные аналитики в МТС Банке, работаем над мобильным приложением и сайтом для физических лиц. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашем банке.

Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ.

Потребность в единообразии

В документации содержатся описания экранных форм, взаимодействия с бэком, обработки ошибок, архитектурные диаграммы, бизнес-требования. Все это должно помочь тестировщикам, разработчикам и бизнесу понять происходящее в функционале без необходимости лезть в код.

Многие аналитики, сами того не желая, пишут непонятную и запутанную документацию без структуры. Или бывает такое, что аналитик пишет понятно, но из-за того, что он работает над проектом не один, в общей массе получается каша. Ведь полное описание даже небольшой фичи каждому аналитику представляется абсолютно по-своему. Это сильно затрудняет как работу над документацией, так и ее восприятие.

Поэтому мы постарались собрать лучшие мысли наших аналитиков, отмести ненужное и на основе этого создать шаблон документации. Сначала мы хотели найти какое-то готовое решение, но сейчас есть в основном ГОСТы, для нас они перегружены. Есть еще открытые стандарты типа UML, но их можно использовать только точечно. Например, для построения диаграмм. Все наши потребности такие стандарты не закрывают.

Структура шаблона

В ходе обсуждений и анализа актуальной документации выяснилось, что самое главное для нас – наличие следующих разделов:

• точки входа;
• бизнес-требования;
• пользовательские сценарии;
• дизайн;
• архитектура.

Давайте пройдемся по каждому из разделов.