It’s abundantly evident that flawed non-functional requirements lead to faulty software and that business analysts often miss critical non-functional requirements – like those related to compliance, security, or performance – for a number of reasons. So how do business analysts improve their abilities to define high-quality non-functional requirements as quickly as possible? By following a logical process and leveraging the right tools and techniques.
The Process of Defining Non-Functional Requirements
At a high level, the process of defining non-functional requirements looks like this:
- Perform stakeholder identification.
- Build visuals – like process flows or system context diagrams – to help describe the environment.
- Identify areas that may need non-functional requirements elicitation.
- Review a predefined catalog of common non-functional requirements categories, determine which are appropriate, and then identify questions (also from a predefined list) that should be asked for each category.
- Hold elicitation sessions with stakeholders and record the responses.
- Define the non-functional requirements.
- Validate the non-functional requirements.
Pay special attention to Step 4. If your business analysts don’t have a predefined catalog of common non-functional requirements categories and potential elicitation questions, they should! It’s one of the best ways to help them define high-quality non-functional requirements fast.
The Beauty of Leveraging a List of Common Non-Functional Requirements Categories
A predefined list of common non-functional requirements categories serves as a “cheat sheet” for business analysts, reducing the risk of missing critical requirements. For example, most software requires secure access, and to define access security requirements, business analysts need to understand:
- User registration requirements: How are new user accounts established?
- User authorization requirements: Who gives users permission to use system functions?
- User authentication requirements: How do we know the users are who they claim to be?
Diving deeper into user registration requirements, business analysts need to think about:
- Self-registration and the standard for authenticating user-entered information
- Password formats and existing password policies
- The processes and policies for changing passwords
- Procedures and policies required for de-registration
- Data protection – which is particularly important for compliance
- The need to provide visitor access for one-day or one-time users
Rather than starting with a blank piece of paper, business analysts who have a list of common non-functional requirements categories and what they mean have a head start. They can quickly identify what’s relevant to their projects, using that information to understand and structure non-functional requirements in their documentation or requirements tools. And when you consider that access security is only one of a number of non-functional requirements categories – including performance, compliance, and availability – you can quickly see how having this predefined information in hand can improve the quality of non-functional requirements and the speed with which business analysts define them.
Jumpstarting Interview Design with a Predefined List of Common Elicitation Questions
If you want to accelerate non-functional requirements definition, don’t stop at predefining requirements categories. Just as non-functional requirement categories are common across organizations and projects, so are the questions business analysts ask to elicit them. Asking the right questions is critical to capturing the most accurate and complete information, so providing business analysts with a list of common interview questions gives them an even bigger head start.
Taking the access security example a step further, business analysts commonly ask questions like:
- What internal users interface with the system?
- What external users interface with the system?
- What level of access is made available without user/customer authorization and authentication?
- What authorized users are authorized for access at all times?
- How soon should the system time out because of inactivity?
- How promptly is approval needed?
This is a small segment of dozens of questions business analysts usually ask to establish access security requirements. They’re also questions that would be asked for almost every software development project. Instead of recreating the wheel for each project, business analysts with a predefined list of common elicitation questions can pick and choose the best ones for their purpose. Additionally, those questions and the requirements they bring out can likely be reused across projects, accelerating non-functional requirements definition across the organization.
What if You Don’t Have These Lists of Common Categories and Questions?
Fortunately, you don’t have to create this information from scratch. Because non-functional requirements categories and elicitation questions are similar across organizations, projects, and even industries, requirements leaders have done that for you. Blueprint’s Non-Functional Requirements Accelerator provides a catalog of more than 2,000 elicitation questions for non-functional requirements in 14 categories – based on Roxanne Miller’s book The Quest for Software Requirements. The Accelerator’s list of predefined categories helps business analysts think about elicitation questions in buckets, and the lists of predefined questions within each category speed up interview design and improve requirements coverage. The benefits can be massive in productivity and software quality.
If you want to learn more about improving your non-functional requirements and Blueprint’s Non-Functional Requirements Accelerator, please contact us today for more information.
