How to Write, Measure & Capture Non Functional Requirements

Non functional requirements are the goals that a product or functionality must achieve to be successful , as opposed to actual product behaviors (or functional requirements). Examples of non functional requirements for websites include performance, usability, and attractiveness, whereas the actual behaviors behind these might be design and page color.

Non functional behaviors vary, however, across systems and platforms. The challenge then becomes how teams measure, capture, and write down non functional requirements. Such is key to success after all.

In a sentence, we measure non functional requirements with ratios and sums, we capture them using unique identifiers (unique IDs), and we write them down using unique modeling language (UML) and standards of documentation. Let’s look into these below.

Examples of non functional requirements

Examples of non functional requirements include the following. This short list will help us understand writing, measuring, and capturing non functional requirements.

• Performance
• Capacity
• Availability
• Reliability

How to Write Non Functional Requirements

If you’re unfamiliar with how business analysts (BAs) gather or create non functional requirements, the process is called elicitation. Business analysts ask stakeholders specially-designed questions to find out what they want.

You can learn more about requirement analysis in other posts on AnalystAnswers.com. Here I want to look at writing and documenting. Indeed, a challenging aspect of non functional requirements is simply writing them down.

Writing non functional requirements is the periodic, structured process of explaining what they are, how to measure them, how to capture them, how to analyze them, and how to think about them. With these elements, BAs tell a story that any person can understand. Writing non functional requirements is thus a skill in consistency and impartiality.

Anyone should be able to understand

As a business analyst, you act as a sort of translator between business and technology teams. In other words, your audience is essentially the organization as a whole. This means that you must craft your message in a way that anyone can understand it. You must simplify, simply, simplify.

Format

One of the ways we can write non-functional requirements so they’re accessible to everyone is by using an industry standard format, often using images with unique modeling language. A very generalized format could look like the following:

• Goals: what do you hope to achieve with the use of non functional requirements?
  • Example: better understand customer contact with the brand by counting number of page views on the website.
• User personas: what are the demographics of users the functional requirements target indirectly?
  • Example: mothers under 30.
• User stories: what step-by-step process does a customer go through that will influence the functional requirements?
  • Example: customers often make first contact on the company page, which means there are many moments of contact we can’t record.
• Risks and opportunity costs: what opportunities do we miss by focusing on these non functional requirements? Are there any risks?
  • Example: perhaps the functional requirements underlying our non-functional requirements are unchangeable. There is no business value, then, to using resources to measure them.

Regularity

You must update your documentation on a regular basis. This will help with team communication. All too often a business analyst will document for him or herself, which means that team members cannot rely o the documentation to be up to date.

Unreliable documentation is useless to the organization, so make sure you update your standardized requirement document on a regular basis and that you communicate the schedule to your team.

How to measure non functional requirements

More often than not, we measure non functional requirements with either a ratio or a sum. We also refer to these sums and ratios as metrics.

In the world of requirements, it’s not uncommon to ask what metric is used to evaluate performance. In fact, performance is probably the most common yet least specific non functional requirement. Depending on the industry, performance measurements can vary greatly.

For example, look at the following products:

1. Performance
   • Website:
     • # of monthly visitors (sum)
     • number of pages per visitor (ratio)
     • bounce rate or number of visitors who only see one page (ratio)
     • duration of visit (sum)
   • Frying pan:
     • time to heat (sum of minutes)
     • amount of weight needed to support 1 cup of food (ratio)
   • Inflatable mattress:
     • number of people while remaining comfortable (sum)
     • amount of time to fill (sum of minutes)
   • Business:
     • sales or revenues (sum)
     • gross margin = revenues – costs/revenues (ratio)
2. Capacity
   • Website:
     • Maximum number of visitors before crashing (sum)
     • Requests per second (ratio)
     • Average response time (sum)
   • Frying pan:
     • maximum volume (sum)
   • Inflatable mattress:
     • maximum weight (sum)
     • maximum amount of air (sum)
   • Business:
     • maximum # of orders possible or inventory (sum)
     • Inventory days, or average inventory in $/average cost of good sold in$ (ratio)
3. Availability
   • Website:
     • number of accessing countries (sum)
     • largest contentful paint, or amount of time until user sees page content (sum)
   • Frying pan:
     • number of countries in which sold (sum)
   • Inflatable mattress:
     • number of countries in which sold (sum)
   • Business:
     • stores per 100km² (ratio)
4. Reliability
   • Website:
     • max number of visitors (sum)
     • days unaccessible per year (ratio)
   • Frying pan:
     • number of uses (sum)
   • Inflatable mattress:
     • number of uses (sum)
   • Business
     • customer satisfaction rate, or number of satisfied customers/total customer (ratio)

Getting inventive with measurements

You can even come up with your own performance metrics. At one company where I worked, we had an internal metric for the number of people signing up and purchasing an item through our portal within the first quarter of their active life.

I know it sounds elaborate, but this ratio was incredibly important to the business. It told us, regardless of total time spent as a member, how good we were at getting people to buy quickly.

As you can see, the measurement itself will vary depending on the context. Companies have more elaborate non functional requirements, products have simple non functional requirements, and software products have non functional requirements somewhere in between. Nevertheless, we measure nearly all non functional requirements using sums and ratios, also known as metrics.

How to capture non functional requirements

We capture non functional requirements by recording their metrics (sums or ratios), either manually or with digital tools that trace unique identifiers. For example, a kitchen manufacturer manually records maximum volume for a frying pan, and a webmaster uses Google Analytics to track visitors to his/her website.

Capturing non functional requirements may seem like a simple task, but it can prove to be work-heavy and costly. Imagine you run a kitchen tool manufacturing company (KitchenCo). All of your current products and non functional requirement metrics can be captured directly at the source in a warehouse.

However, you would like to introduce a new technology that helps users keep track of the food that they have cooked in your oven. Let’s assume the goal is to understand what kind of food your customers make. For legal reasons, you cannot take or collect pictures. You can, however, find out the temperature, cooking time, and convection-type via the the oven. The ability to record these items are your functional requirements.

Example

Now come the non functional requirements. In order to achieve your goal, you need to convince your users to connect their oven to the internet. You do this by proposing an analytics dashboard via a native app where users can view information on what they have cooked. This is a common technique for companies looking to get involved with the Internet of Things (IoT).

Now you see that the simple capture, or collection, of requirements requires investing in serious IT architecture.

In fact, this is both a challenge and an opportunity. Companies looking to capture digital metrics–that is, those that go beyond requirements we can collect in a warehouse–need to make the leap to data capturing technologies. This can be expensive.

Where there’s a buyer, there’s a seller. For companies looking to get involved in selling data capturing technologies, it looks like the sky is the limit. While big data companies like Google own the web, all kinds of industries are looking to get involved.

Capturing metrics to understand non functional requirements should for this reason become progressively easier in the future.

Conclusion

Writing, measuring, and capturing non functional requirements is a methodical process. In some ways, it remains unchanged. In others, it evolves with the times.

To write non functional requirements, your goal is to makes sure that anyone in your organization can read your documents on a regular basis. You should use a structured format that you update on a regular interval about which your company is aware.

To measure non functional requirements, you need a standard, numerical value or metric. Across industries, the most common way to do so is with sums or ratios. It’s easy to start mixing functional requirements and the metrics used to measure them, so pay attention to this.

To capture non functional requirements, your industry will determine the methodology. Data collection is a growing field, and the warehouse-based, manual capturing process will soon be outdated, even in the most conservative industries. More and more B2B solutions are hitting the market to help companies capture the metrics used to measure non functional requirements.

Keep your eyes open. A good business analyst might spot affordable data capturing opportunities for their company!