The Pareto Principle in Functional Analysis and Requirements (FRA)
We, products guys, were born to bring innovative thinking into our daily life and make brand new ideas. The metaphor “don’t reinvent the wheel” appears incorrect, because doing something that already exists can make you understand how it works and how it can be improved. Our goal is to learn new skills and use them to discover fresh approaches.
There is a great principle, which I use in seeking to understand which functional variables have the highest cumulative effects on the usage of the application. Neither broad knowledge nor magical formulas are required to implement this technic. It is a purely rational thing, and it works perfectly.
Now, I want to draw your attention to the Pareto principle, also knows as “80–20 rule.” The Pareto principle says that, for many events, approximately 80% of the effects come from 20% of the causes. Mr. Vilfredo Pareto (1848–1923) was a genial Italian engineer and sociologist who observed 80% of the land in Italy was owned by 20% of the population. Later, the same phenomena (“80–20 rule”) were detected in different spheres of the everyday world. There is a book collection referring to this phenomenon, and I’m attaching two of my best picks here (Blue Ocean Strategy and The 4-Hour Work Week).
The “80–20 rule” is an observation, and surely it is not a law of nature. Consider above before starting applying it either in analyzing optimization efforts (QA) or determining functional specifications. Personally speaking, I found the Pareto Chart powerful in requirements analysis. It helps to visualize what matters most.
Let’s imagine we are designing a workshop scheduling application that is used to manage service appointments and utilize workshop resources effectively (core idea). Such a sophisticated tool consists of very different requirements, and therefore the Pareto principle may help. To support the product core idea, one should classify use cases as functional variables and measure them (frequency, quantity, cost, or time). Here, I would suggest grouping different service appointment types per period. However, someone may consider a different approach. Standard services to offer, resources skill set available, or a or source of appointments could work with the Pareto Principle as well.
Procedure: Sample data are collected and recorded in each category in the table below:
Using the data above, we now build the Pareto Chart.
The figure presents how many service appointment types were received in each of the five categories with cumulative values. If all categories require a particular set of functionality, starting with functional requirements dealing with small and quick services would have the most substantial impact on the usage.
The Pareto chart is a suitable instrument to analyze data about the frequency of events (problems) or cause in a process. Or by encountering different requirements on the same application, and one wants to focus on the most significant. I am successfully using it in communication with stakeholders about product-related decisions.
Please see the useful links related to the topic above.
