requirements is difficult. Capturing architecturally significant requirements is
difficult. This article discusses the root causes of this difficulty, and
suggests a systematic approach to capturing architectural requirements to
ensure that these elusive, and yet extremely important, system specifications
are not overlooked.
an Architectural Requirement?
Because this article focuses on an approach to
gathering requirements of particular significance to the architecture of a
system1, let's start with the definition of an architectural requirement.
Rational Unified Process® (RUP®) gives the following
definition for any requirement:
requirement describes a condition or capability to which a system must conform;
either derived directly from user needs, or stated in a contract, standard,
specification, or other formally imposed document.
requirement, in turn, is any requirement that is architecturally significant,
whether this significance be implicit or explicit. Implicit architectural
requirements are those requirements that have particular attributes. For
example, any high-risk, high-priority, or low-stability requirement could be
considered to be architecturally significant. However, this article will focus
primarily on explicit requirements, which are often technical in nature. The
following are examples of explicit architectural requirements:
The product will be localized
(support multiple human languages).
The persistence will be handled
by a relational database.
The database will be Oracle 8i.
The system will run seven days a
week, twenty-four hours per day.
An online help system is
All presentation logic will be
written in Visual Basic.
As you may notice, these requirements are extremely
mixed. Some are functional, some non-functional; some are independent of
technical mechanisms, others are not. What we need is a systematic approach
that provides a framework for classifying architectural requirements, which
ensures that valuable statements such as those listed above are not overlooked.
FURPS+ System for Classifying Requirements
One such classification system was devised by
Robert Grady at Hewlett-Packard.2 It goes by the acronym FURPS+ which represents:
The "+" in FURPS+ also helps us to
remember concerns such as:
Let's look at each category in detail
The Functional Requirements Specification documents
the operations and activities that a system must be able to perform.
Functional Requirements should include:
Descriptions of data to be
entered into the system
Descriptions of operations
performed by each screen
Descriptions of work-flows
performed by the system
Descriptions of system reports or
Who can enter the data into the
How the system meets applicable
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
Functional Requirement Creation
Examples of Functional Requirements
Functional requirements should include functions
performed by specific screens, outlines of work-flows performed by the system,
and other business or compliance requirements the system must meet. Download an
example functional requirements specification or use these quick examples below.
Field 1 accepts numeric data
Field 2 only accepts dates before
the current date.
Screen 1 can print on-screen data
to the printer.
· Data must be entered before a request can be approved.
All personnel using the system
will be trained according to internal SOP AA-101.
The database will have a
functional audit trail.
The system will limit access to
The spreadsheet can secure data
with electronic signatures.
Members of the Data Entry group
can enter requests but can not approve or delete requests.
Members of the Managers group can
enter or approve a request but can not delete requests.
Members of the Administrators
group cannot enter or approve requests but can delete requests.
Depending on the system being described, different categories of
requirements are appropriate. System Owners, Key End-Users, Developers,
Engineers, and Quality Assurance should all participate in the requirement
gathering process, as appropriate to the system.
Requirements outlined in the Functional Requirements Specification are
usually tested in the Operational Qualification.
The Functional Requirements Specification describes what the system must
do; how the system does it is described in the Design Specification.
If a User Requirement Specification was written, all requirements
outlined in the User Requirement Specification should be addressed in the
Functional Requirements Specification.
The Functional Requirements Specification should be signed by the System
Owner and Quality Assurance. If key end-users, developers, or engineers were
involved with developing the requirements, it may be appropriate to have them
sign and approve the document as well.
Depending on the size and complexity of the program, the Functional
Requirements Specification document can be combined with either the user
requirements specification or the design specification.
A functional requirement
describes what a software system
should do, while non-functional requirements place constraints on how the system will do so.
Reliability, Performance, and Supportability Requirements
The remaining "URPS" categories describe
non-functional requirements that are generally architecturally significant.
Usability is concerned with characteristics
such as aesthetics and consistency in the
Reliability is concerned with characteristics
such as availability (the amount of system
"up time"), accuracy of system calculations, and the system's
ability to recover from failure.
Performance is concerned with characteristics
such as throughput, response time, recovery
time, start-up time, and shutdown time.
Implementation, Interface, and Physical Requirements
The "+" in the FURPS+ acronym is used to
identify additional categories that generally represent constraints.
A design requirement, often called a design constraint, specifies or
constrains the options for designing a system. For example, if you specify that
a relational database is required, that's a design constraint.
An implementation requirement specifies or constrains the coding or
construction of a system. Examples might include required standards,
implementation languages, and resource limits.
An interface requirement specifies an external item with which a
system must interact, or constraints on formats or other factors used within
such an interaction.
A physical requirement specifies a physical constraint imposed on the
hardware used to house the system Â— shape, size, or weight, for example.
Approach for Gathering Architectural Requirements
The approach to gathering architectural requirements
we will explore is simple:
Maintain a complete list of
architectural requirements (regardless of whether all items are relevant to a
particular projectFor each architectural requirement, formulate one or more
questions that can help in the specification process. Make sure all the system's stakeholders can
understand these questions.
Assist stakeholders by showing
them the potential impact of answering a question one way or the other.
Capture the responses from your
stakeholders to each of the questions.
Assist the architect by ensuring
that the stakeholders Â— in addition to answering these questions Â— assign a
priority or weighting to each architectural requirement. This weighting will
allow the architect to make tradeoffs between requirements.
It is worth noting that this approach is possible
because, at a high level, the set of architectural requirements that must be
considered is finite. You can also apply this approach to requirements
gathering within particular problem domains that also have finite,
well-defined, sets of considerations. For a financial system, for example,
there would be an imperative to pose certain finance-related questions.
Architectural Requirements Questionnaire