Home | | Software Architectures | Functional Requirements - Software Architectures

Chapter: Software Architectures : Introduction and Architectural Drivers

Functional Requirements - Software Architectures

Capturing requirements is difficult. Capturing architecturally significant requirements is particularly difficult.

Functional Requirements

 

General Requirements

 

Capturing requirements is difficult. Capturing architecturally significant requirements is particularly 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.

 

What Is 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:

 

A 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.

 

An architectural 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 required.

 

·                                 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.

 

The 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:

 

·                                 Functionality

 

·                                 Usability

 

·                                 Reliability


·                                 Performance

 

·                                 Supportability

 

The "+" in FURPS+ also helps us to remember concerns such as:

 

·                                 Design requirements

 

·                                 Implementation requirements

 

·                                 Interface requirements

 

·                                 Physical requirements

 

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 other outputs

 

·    Who can enter the data into the system

 

·    How the system meets applicable regulatory 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.



Rapid 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.

 

Interface requirements

 

·    Field 1 accepts numeric data entry.

 

·    Field 2 only accepts dates before the current date.

 

·    Screen 1 can print on-screen data to the printer.

 

Business Requirements

 

· Data must be entered before a request can be approved.

·    Clicking the Approve button moves the request to the Approval Workflow.

 

·    All personnel using the system will be trained according to internal SOP AA-101.

 

Regulatory/Compliance Requirements

 

·    The database will have a functional audit trail.

 

·    The system will limit access to authorized users.

 

·    The spreadsheet can secure data with electronic signatures.

 

Security Requirements

 

·    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.

 

Additional Comments

 

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.

 

The functional requirement is describing the behavior of the system as it relates to the system's functionality. The non-functional requirement elaborates a performance characteristic of the system.

Functional Requirements

 These requirements generally represent the main product features. In a warehouse application, we might have requirements pertaining to order processing or stock control, for example. However, functional requirements are not always domain-specific. Providing printing capability is a functional requirement of particular significance to architecture, for example.

 


Usability, 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 user interface.

 

·         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.

·                Supportability is concerned with characteristics such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.

 

Design, 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.

 

An Approach for Gathering Architectural Requirements

 

The approach to gathering architectural requirements we will explore is simple:

 

1.                 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.

 

2.     Assist stakeholders by showing them the potential impact of answering a question one way or the other.

 

3.                             Capture the responses from your stakeholders to each of the questions.

 

4.      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.

 

The Architectural Requirements Questionnaire

 

This approach is best represented in the form of a simple table provided to stakeholders as an Architectural Requirements Questionnaire. Table 3 shows a portion of such a questionnaire and includes example answers.





Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Software Architectures : Introduction and Architectural Drivers : Functional Requirements - Software Architectures |


Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.