Введение
Любая задача, которую система должна уметь выполнять.
В разработке программного обеспечения и системной инженерии функциональное требование определяет функцию системы или ее компонента, где функция описывается как обобщение (или спецификация или утверждение) поведения между входными данными и выходными данными. Функциональные требования могут включать вычисления, технические детали, манипулирование и обработку данных, а также другие специфические функции, определяющие, что система должна делать. Поведенческие требования описывают все случаи, когда система использует функциональные требования, и фиксируются в вариантах использования. Функциональные требования поддерживаются нефункциональными требованиями (также известными как "требования к качеству"), которые накладывают ограничения на проектирование или реализацию (например, требования к производительности, безопасности или надежности). Как правило, функциональные требования выражаются в форме "система должна выполнять <требование>", а нефункциональные требования – в форме "система должна обладать <требованием>". План реализации функциональных требований подробно описывается в проекте системы, в то время как нефункциональные требования подробно описываются в архитектуре системы. Как определено в инженерии требований, функциональные требования определяют конкретные результаты работы системы. Это следует противопоставлять нефункциональным требованиям, которые определяют общие характеристики, такие как стоимость и надежность. Функциональные требования определяют прикладную архитектуру системы, а нефункциональные требования – техническую архитектуру системы. Каждый вариант использования иллюстрирует поведенческие сценарии посредством одного или нескольких функциональных требований. Однако часто аналитик начинает с выявления набора вариантов использования, из которых он может вывести функциональные требования, которые необходимо реализовать для выполнения пользователем каждого варианта использования.
In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a summary (or specification or statement) of behavior between inputs and outputs. Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases. Functional requirements are supported by non functional requirements (also known as "quality requirements"), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form "system must do <requirement>," while non functional requirements take the form "system shall be <requirement>." The plan for implementing functional requirements is detailed in the system design, whereas non functional requirements are detailed in the system architecture. As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non functional requirements, which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system, while non functional requirements drive the technical architecture of a system. Each use case illustrates behavioral scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that must be implemented to allow a user to perform each use case.
Процесс
Типичное функциональное требование содержит уникальное имя и номер, краткое описание и обоснование. Эта информация помогает читателю понять, зачем необходимо данное требование, и отслеживать его на протяжении всего процесса разработки системы. Основная часть требования – это описание требуемого поведения, которое должно быть ясным и понятным. Описанное поведение может быть основано на организационных или бизнес-правилах, либо выявлено в ходе встреч с пользователями, заинтересованными сторонами и другими экспертами внутри организации. Многие требования могут быть обнаружены в процессе разработки сценариев использования. В этом случае аналитик требований может создать предварительное требование с именем и описанием, а детали изучить позже, когда они станут более известны.