Functional and Non-Functional Requirements

“BA as Translator”

This is post three of five that shares learning and insight gained during a recent consulting experience. There are generally two types of requirements

1) Functional: describes WHAT the system/process does – the processes, workflows, validations, and calculations – the system either will or will not perform.

2) Non-Functional: describes HOW the system does what it does – considered a “quality” criteria that is associated with the system performance.  It does not define the action the system does, but it does define how well the system needs to perform the action.

Most business clients have an easy time describing the functional requirements of a solution because it is things that the solution will do. Non-functional requirements are more difficult to describe because they are more subjective, but they are just as important because they influence whether or not a client will find a solution “usable” and “acceptable”. Non-Functional requirements for an IT system design and implementation project may include:

• Scalability
• Availability
• Maintainability
• Language
• User interface
• Security
• Responsiveness
• Interoperability
• And many others (take a look at Wikipedia for a long list)

Non-Functional requirements for a non-IT project may include:

• Usability
• Texture
• Fit
• Form
• Function
• And others

Most stakeholders and business analysts find it easy to define functional requirements, because people instinctively think about WHAT they do; however, non-functional requirements are difficult to define because they are amorphous.  Thus, to develop a set of non-functional requirements the business analysis may;

1) Exercise expert judgement about client expectations and document the non-functional requirements with little consultation, or

2) Conduct a standard elicitation activity (interview, focus groups or workshop), but phrase the questions in business terms so that the stakeholder(s) recognize(s) the items you are addressing and do not realize that they are defining non-functional requirements.

For example, rather than speaking about capacity and availability of a system, ask questions about tangible items in the context of the business.

Non-Functional Requirement Type	Sample question to pose to stakeholder
Capacity	How many people will access the system? What is the maximum number of people using the system per hour? What is the average number of people using the system per hour? How many transactions (events) should the system store for reference? What is the maximum number of transactions (events) that will take place in one hour? What is the average number of transactions (events) that will take place in one hour? What is the number of warehouses operated by the company? What is the number of office locations around the world? How are the offices distributed around the world?  In which countries?
Availability	What are the standard hours of operation of the business? Does anyone need to access the system outside of the standard hours? Does anyone access the system from other locations?  If so, which ones?

In this way, Business Analysts are translators.  We speak to business stakeholders in terms that they understand, and then process, paraphrase, and write the appropriate requirements in terms that the system architecture, design, and engineering team will understand. Stay tuned to post four for more information about the use of table to clarify scope and operational requirements.