Non-Functional Requirements and System Qualities

29/04/2008 by Jon.

The topic of non-functional requirements has been raging for many years now and there seems little chance of it abating for some time to come. Most architects will be familiar with the issues here , particularly as they effect projects. Incomplete, unusable and sometimes missing non-functional requirements are a constant source of friction in projects.

There are a whole set of issues here but for me one of the root issues is understanding what a non-functional requirement is. There appears to be a fair amount of confusion here which is not helping us. If the architects can’t always agree and then can’t agree with the business analysts there is little hope of getting sensible answers out of the business owners.

A first step is to use a standard list of topics for what we mean. The best source I have come across are the SEI System Qualities, well described in this blog entry. Essentially we are looking at a well thought out and fairly complete list.

Agility - Agility is the ability of a system to be both flexible and undergo change rapidly. (MIT ESD 2001)

Flexibility - Flexibility is the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed. (Barbacci 1995)

Interoperability - Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. (IEEE 1990)

Maintainability - Maintainability is:

· The aptitude of a system to undergo repair and evolution. (Barbacci 2003)

· The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. (IEEE Std. 610.12)

Reliability - Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. (Bass 1998)

Reusability - Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. (IEEE 1990).

This is typically in the form reusing software that is an encapsulated unit of functionality.

Supportability - Supportability is the ease with which a software system is operationally maintained.

Performance - Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)

Security - Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)

Scalability - Scalability is the ability to maintain or improve performance while system demand increases.

Testability - Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met (IEEE 1990).

Usability - Usability is:

· The measure of a user’s ability to utilize a system effectively. (Clements 2002)

· The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. (IEEE Std. 610.12)

· A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed. (Barbacci 2003)

For full details of the references see the original blog entry above.

Now as ever with "standard" lists like this the first step is to look at it and ask yourself, "how does this relate to the problem in hand?". Personally I always split "performance" into "response time" and "throughput" as I find this useful. Usability is also an interesting one as I often work on package implementations so there is little scope for change here. As ever the art is to focus on the ones where the project faces the higher risks. The scarce resource is the attention of the project and your time so pick the ones that are most impactful on the task in hand, which will vary from project to project.

I have glossed over a key point here which would have anyone from the SEI throwing their hands up in horror by now. Non-functional requirements are not system qualities. This is the key tenet of the SEI approach. They just have requirements, no split of functional and non-functional, and then have the qualities that the system exhibits (as listed above). They have a point. It sometimes feels like a very pointless conversation when you are trying to decide whether a specific requirement is functional or non-functional. It makes little practical difference except in terms of which document the words end up in and potentially who approves them. Part of me says that the terms functional and non-functional are at least recognised by the people which gives them some value, confusing as they can be.

The compromise I tend to use is that the requirements can be functional or non-functional, but the system exhibits certain qualities, as per the list above. If you can start the business thinking about qualities rather than non-functional requirements then that’s great but we probably have some way to go as yet.

Posted in How to Architect | Print | No Comments »