Information Technology Reference
In-Depth Information
elements of functionality and identity. A platform-based development approach
leverages this commonality, utilizing a set of reusable assets across the family.
These strategies have important implications for software architecture. In particular,
it is not just the functional requirements of the first product or release that must be
supported by the architecture. The functional requirements of early (nearly con-
current) releases need to be explicitly taken into account. Later releases are
accommodated through architectural qualities such as extensibility, flexibility, etc.
The latter are expressed as non-functional requirements. As such, use cases have
quickly become a widespread practice for capturing functional requirements. This is
especially true in the object-oriented community where they originated, but their
applicability is not limited to object-oriented systems.
5.3.2 Identifying the Non-Functional Requirements
Non-functional requirements are requirements that are not directly concerned with
specific functions delivered by the system. They may relate to emergent system
properties such as reliability, response time, etc. Therefore, they may specify
system performance, security, availability and other emergent properties. How-
ever, failing to meet non-functional requirements can mean that the whole system
is unusable. Identifying non-functional requirements means identifying the origin.
Nonfunctional requirements arise through user needs, because of budget con-
straints, organizational policies and the need for interoperability with software or
hardware systems. A problem with non-functional requirements is that they are
difficult to verify since users often state these requirements in terms that are overly
vague. (Sommerville
2004
). Here are some questions for identifying non-func-
tional requirements (Malan and Bredemeyer
2001
).
User interface and human factors:
• What type of user will be using the system?
• Will more than one type of user be using the system?
• What sort of training will be required for each type of user?
• Is it particularly important that the system be easy to learn?
• Is it particularly important that users be protected from making errors?
• What sort of input/output devices for the human interface are available, and
what are their characteristics?
Documentation
• What kind of documentation is required?
• What audience is to be addressed by each document?
Hardware considerations
• What hardware is the proposed system to be used on?
