Scribd
Upload
68 views1 page

Soft Eng

The document discusses functional and nonfunctional requirements for software. Functional requirements define what a product must do, like determining eligibility or paying a claim. Nonfunctional requirements define quality attributes like performance, security, and usability. Both types of requirements must be precise and testable to guide software development.

Uploaded by

Hazael Estabillo Lopez
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
68 views1 page

Soft Eng

The document discusses functional and nonfunctional requirements for software. Functional requirements define what a product must do, like determining eligibility or paying a claim. Nonfunctional requirements define quality attributes like performance, security, and usability. Both types of requirements must be precise and testable to guide software development.

Uploaded by

Hazael Estabillo Lopez
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
You are on page 1/ 1

The International Institute of Business Analysis (IIBA) defines functional requirements as “the product

capabilities, or things that a product must do for its users.”1 Functional requirements define how
software behaves to meet user needs. For example, imagine a health insurance company designing a
claims system. There will be functional requirements such as “Determine Claimant Eligibility,”
“Adjudicate Claim,” and “Pay Claim.” These high-level functional requirements will also include many
detailed functional requirements. For example, “Pay Claim” might include the functional requirement
“Determine Payee” (the insured or the service provider).

The IIBA defines nonfunctional requirements as “the quality attributes, design and implementation
constraints, and external interfaces which a product must have.”2 Quality attributes are often
affectionately called the “ilities” because the names of many of them end in “ility.” Examples of quality
attributes include availability, maintainability, performance, portability, reliability, robustness, security,
scalability, testability, usability, and others. Many nonfunctional requirements are global in nature; they
apply to an entire system. Performance requirements -- such as requirement for response time or
throughput -- are often global. Some nonfunctional requirements may apply to (or vary by) specific
usages of the system. For example, 24×7 availability may be needed for some, but not all, of the users of
the system.

Depending on your organization’s approach to software development, functional requirements may be


expressed as requirements statements, use cases, scenarios, or user stories. Nonfunctional
requirements may be captured as narrative statements, formatted templates, or acceptance criteria.

Whatever approach you use to define requirements, it’s important to express functional and
nonfunctional requirements precisely enough, from a business perspective, to make them testable. For
example, stating that the system must be able to “Pay Claim,” or from a performance perspective, that
“the system must be fast,” says everything and nothing at the same time. You can’t test either one
objectively.

To make the functional requirement “Pay Claim” testable, you need to refine it by working with business
subject matter experts to understand all its steps, along with the applicable data and rules. You also
need to explore its variations; “Pay the insured” or “Pay the service provider” may have some differing
steps, data, and rules. To turn the vague nonfunctional requirement for a “fast” system into a testable
requirement, business subject matter experts need to provide measurable expectations for
performance. A testable version of the performance requirement might read, “for <a specific usage>
with <specific network load and concurrency>, the maximum amount of time between a user’s click of
an “enter” key and the start of a response delivered to the user will be no more than six seconds 80% of
the time, and never longer than nine seconds.”

You might also like