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 include the following. This short list will help us understand writing, measuring, and capturing 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.
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.
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:
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.
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:
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.
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.
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.
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!
Noah is the founder & Editor-in-Chief at AnalystAnswers. He is a transatlantic professional and entrepreneur with 5+ years of corporate finance and data analytics experience, as well as 3+ years in consumer financial products and business software. He started AnalystAnswers to provide aspiring professionals with accessible explanations of otherwise dense finance and data concepts. Noah believes everyone can benefit from an analytical mindset in growing digital world. When he's not busy at work, Noah likes to explore new European cities, exercise, and spend time with friends and family.
