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:
- User interface
- And many others (take a look at Wikipedia for a long list)
Non-Functional requirements for a non-IT project may include:
- 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|
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.