Among the many challenges today’s business analysts face, that of discovering and documenting non-functional requirements may be the most important.
Why are Non-Functional Requirements So Critical?
While functional requirements describe what a system should do, non-functional requirements define how well it needs to function. Roxanne Miller’s book, The Quest for Software Requirements, describes three categories of non-functional requirements:
- Operation requirements represent how well the system must perform for daily use. How reliable and efficient should it be? What level of availability do its users need?
- Revision requirements represent how easy it should be to correct errors and add functions to the system. Is it easy to maintain? Is it scalable and flexible?
- Transition requirements represent how easy it should be to adapt the system in the face of technical environment changes. Can you move it to other operating environments efficiently? Can parts of it be reused?
Simply put, non-functional requirements describe the quality attributes of a solution. And teams must consider them as a critical prerequisite for successful IT projects, because ultimately, they shape the quality of the final product.
Do Business Analysts Get It?
Historically, business analysts have often under-emphasized non-functional requirements or ignored them altogether for a few common-sense reasons:
- Most business analysts and their business stakeholders will agree that talking about what users will see and how they’ll interact with an application is much more exciting than discussing “boring” topics like security access rights, system backups, and performance. Business analysts want to do the fun stuff – process mapping, user interface modeling, prototyping. That’s where the best conversations take place.
- Business analysts have also been given little guidance or training on non-functional requirements. In the plethora of new business-analysis-oriented books, certifications, and web sites, non-functional requirements don’t get much bandwidth. So, determining how to elicit and document them can be daunting, particularly for new business analysts.
- Finally, non-functional requirements tend to be more technically oriented than many business analysts’ backgrounds, upping the intimidation factor.
Agile Muddies the Waters Further
The transition to Agile has further complicated business analysts’ attempts to discover and document non-functional requirements. Agile practices represent requirements in the form of user stories: “As a <type of user>, I want <something> so that <some benefit>.” Non-functional requirements just don’t fit that format intuitively.
Additionally, most Agile guides don’t provide good direction on folding non-functional requirements into Agile development processes. This is a major gap, because most organizations are trying to adopt Agile methods. Fortunately, thought-leaders on scaling Agile have recognized this, knowing there is no room for compromise on non-functional requirements in very large, business-critical IT applications. Frameworks like the Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD) process decision framework provide practical guidance for integrating Agile practices into large enterprises. Agile is “growing up” – but it’s not there yet.
Why Business Analysts Must Get It
Business analysts can no longer under-deliver when it comes to non-functional requirements for two reasons:
- We’re developing in a highly complex technical environment. When our technology and user environments were simpler, we could overlook non-functional requirements without much impact. The risk was small. But times have changed – teams develop software in incredibly complex environments. Today’s enterprise solutions span physical locations and leverage a diverse set of technologies, yet they must interoperate, be secure, adhere to compliance requirements, and perform almost instantly. Testing of non-functional requirements in business analysis has also become more complicated, so requirements must be clear and complete.
- The business environment has also intensified. Regulatory requirements – which often include non-functional requirements in business analysis – aren’t optional. And competition among businesses has ramped up the need for innovation and faster solution delivery. Today’s systems have to support large, distributed teams – often employed by multiple companies – without fail. Organizations depend on them every day to execute business processes, making system quality paramount. Thus, the need for quality non-functional requirements.
Here’s the Good News
Non-functional requirements in business analysis may not be sexy, but they are easier to get right than most people perceive. And there are ways to speed up their discovery and documentation. We see companies recognizing that:
- You can reuse many non-functional requirements. If your Sales teams require 24×7 availability of the software solutions that support customer relationship management and proposal development, any project touching those systems will likely have that same requirement. The same goes for regulatory requirements. They will most likely cross projects and systems, so why not develop a standard library of these types of non-functional requirements to speed up the requirements gathering process? (This is where requirements software and a managed requirements repository come in handy, by the way.)
- Tools and templates can give you a jumpstart. Requirements definition and management software have matured vastly. They can help you categorize and organize all types of requirements – including non-functional requirements – for effective, efficient definition, management, traceability, test case development, and reuse.
- There’s guidance out there. Roxanne Miller’s book, which focuses solely on non-functional requirements, provides detailed leadership in involving the right stakeholders, improving elicitation techniques, and asking the right questions to discover and document non-functional requirements.
This is movement in a positive direction for business analysts, project teams, and the users of the systems they develop.
