Write an essay of 2 pages maximum explaining the difference between the function

Question

Write an essay of 2 pages maximum explaining the difference between the functional and non-functional requirements.

The essay must discuss the following points.

- Explain and define functional requirements.

- Explain and define non-functional requirements.

- Explain and discuss the differences between the functional and non-functional requirements.

Mention the main criteria that distinguish the two types.

- Give examples of functional requirements from an existing or hypothetical system.

- Give examples of non-functional requirements from an existing or hypothetical system.

Explanation / Answer

Functional requirements:

The Functional Requirements Specification is designed to be read by a general audience. Readers should understand the system, but no particular technical knowledge should be required to understand the document.

In Software engineering and systems engineering, a functional requirement defines a function of a system or its component. A function is described as a set of inputs, the behavior, and outputs.

Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements 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 are "system shall be <requirement>". The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is 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.

In some cases a requirements analyst generates use cases after gathering and validating a set of functional requirements. The hierarchy of functional requirements is: user/stakeholder request --- feature --- use case --- business rule. 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.

Non-functional requirement:

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually Architecturally Significant Requirements.

Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do <requirement>", an individual action of part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model. In contrast, non-functional requirements are in the form of "system shall be <requirement>", an overall property of the system as a whole or of a particular aspect and not a specific function.

Qualities—that is non-functional requirements—can be divided into two main categories:

Difference between functional and nonfunctional requirements:

Functional Requirements

Most requirements definition focuses mainly on functional requirements, which are based upon the expected functioning of the product or system to be created. Functioning typically is equated with product/system features for which you might have a menu or button choice, such as: identify a customer, select an item to order, and calculate the amount due.

All things considered, requirements definers probably are best at identifying functional requirements, although they often overlook and get wrong more of the functional requirements than they ordinarily recognize. On hindsight reflection, they frequently do realize that many of the problems which surface later, and thus are harder and more expensive to fix, are attributable to inadequately addressed nonfunctional requirements.

Nonfunctional Requirements

Nonfunctional requirements refer to a whole slew (I've identified more than 30) of attributes including performance levels, security, and the various "ilities," such as usability, reliability, and availability. Invariably, requirements definers get wrapped up in how the product/system is expected to function and lose sight of these added elements.

When such factors are not addressed adequately, seemingly proper product/system functioning in fact fails to function. For example, a system may identify customers in such a slow, insecure, and difficult to use manner that it can cause mistakes which make data unreliable, provoke frustration-based attempted work-arounds that can create further problems, and ultimately lead to abandonment.

That's the recognized way in which nonfunctional requirements impact product/system success. Other often unrecognized issues also need to be appreciated.

"Nonfunctional" is misleading

First, I would encourage calling them "quality factors" or "quality attributes" rather than "nonfunctional requirements," which I believe is misleading. "Nonfunctional" implies they exist in the abstract or can be pigeon-holed, which can only lead to nonsensical questions such as, "How much usability do you need?" You don't need a bunch of usability. Rather, these requirements are relevant only with respect to functionality. For example, usability requirements pertain to particular usage situations; and a given product or system can have many different usability requirements—for each of the respective usage situations.

Also I'll caution against calling them a common alternative term, "quality requirements," which implies erroneously that these factors by themselves are what is meant by "quality." Instead, quality first and foremost comes from suitable functionality. Speed, ease of use, and the like contribute to quality if and only if associated with useful functionality.

Templates and checklists are helpful for remembering to find out about these factors but should not dictate the manner in which they are stored. That is, you shouldn't just have a group of usability requirements, a group of security requirements, and so on. Rather, all the relevant quality factors modifying a particular requirement should be captured with it.

Both Are Really Design

A second, far less recognized but very important issue with functional and nonfunctional requirements is that they actually are forms of high-level design pertaining to a product or system which is expected to be created. A tip off is that frequently they are called "specifications" instead of or in addition to "requirements." "Specification" is design.

Problems occur when the bulk of requirements definition is focused on specifying the product's functional and nonfunctional requirements, which is usually what happens. The product/system will provide value if and only if it actually satisfies the REAL, business requirements.

When most of the attention is directed toward the product/system presumed solution, there's too little understanding of what the product/system must accomplish to provide value; and what seems like a suitable product/system often turns out not to provide the value it should.

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.