In a typical software development project, business analysts define requirements in a lengthy Business Requirements Document – or BRD. Formats vary, but BRDs usually contain similar types of content. They start with an introduction providing an overview of the features to be included in the release at hand. There’s a section for outlining assumptions (which may or may not be given much thought).
The meat of the BRD lies in the requirements section – where a long list of statements describes the release’s desired functionality in detail. Those “The system shall…” requirements tell the development team what it needs to deliver.
Then there’s the section for defining non functional requirements. And while we understand the importance of non functional requirements, like security, usability, or regulatory needs, many business analysts neglect this content. Sometimes they skip it altogether. Or they may just write a few vague statements discovered by accident from stakeholders they stumbled across during requirements elicitation.
Business analysts are good at capturing functional requirements, but they often fail to define non functional requirements. These requirements serve as important constraints for the development team – leading it to a particular solution. When missed, results usually fail to meet business stakeholders’ expectations. This can be catastrophic in waterfall projects, where missed requirements don’t rear their ugly heads until user acceptance testing – 6, 9 or 12 months after requirements definition.
Why do business analysts skip non functional requirements – particularly when we all understand the potential impact? Here are 5 reasons:
- “I forgot a stakeholder.” Defining non functional requirements starts with stakeholder identification, but the people that can represent non-functional needs usually aren’t involved as core members of the project team. They pop in and out as needed for specific activities. Out of sight, out of mind – and business analysts forget to talk to those important people.
- “I’m not an expert.” Business analysts often lack experience in the more technical aspects of software development characteristic of non functional requirements – security for example. They don’t understand the concepts, so they don’t know the right questions to ask – or they don’t know how to interpret and document the information they collect. The lack of knowledge complicates the definition of non functional requirements.
- “It will delay the project.” Every project comes with its deadlines, and business analysts have to get their BRDs out the door on time. But it’s often impossible to coordinate schedules with the people they need to talk to for non-functional requirements elicitation. Many non functional requirements representatives, like legal and regulatory experts, have serious calendar constraints, so to avoid bottlenecks, business analysts skip those discussions altogether.
- “Everybody knows.” Project teams operate under a number of assumptions, and this is often the root cause of missed non-functional requirements. Business analysts think: “We’ve done this a hundred times, so everybody knows…” Assuming development teams understand important non-functional constraints leads to a lack of explicit definition and failure to deliver them.
- “But we’re Agile.” Agile methodologies don’t define a formal mechanism for recording non functional requirements. Business analysts can include them as acceptance criteria on user stories, but what if those non-functional requirements apply to many user stories? Do they have to repeat them over and over again? And if they wait to define them until they user story elaboration and grooming, they have to figure out a way to involve non functional requirements representatives. The lack of an Agile method for defining non functional requirements means they’re often missed.
Understanding the root causes of missing or misunderstood non functional requirements is the first step to improving them through training or tools.
