Over the years of building software products from scratch in an agile, and iterative fashion, here’s an interesting thought process for software engineering that I’ve recognized to be working very well —
FURPS is an acronym used by Requirement gatherers to categorize requirements into Functionality, Usability. Reliability, Performance, and Supportability.
What I’ve noticed is, if you take them as part of your software development planning and efforts allocation, IN THAT ORDER in terms of the priority, it helps to optimize for the efficiency of the value delivery as the effect of your software building/product delivery.
Let me explain this idea more concretely-
Let’s say you are building a new product from scratch, then the effort allocation for the Version 0 (which might be a Proof of Concept product) can be thought something like this —
Functionality – 60 % or more of your efforts should be put here. Why? because this is V0, and everyone wants to just see whether this works! Nothing is more important than functional software at this point. A common understanding here is that the software is kept as simple as possible at any given point of time while delivering on the functionality.
Usability – 20 % of your efforts should go here. Why? usability is an important factor, but not as critical as functionality, even in case of business to consumer products, and especially in the case of business to business products. Hence, apart from having a “common-sense” usability aspects baked into your product, no special efforts are required here at this point in software development.
Reliability – 10 % of your efforts should go here. Why? as a V0 of the product, the reliability of this software is an inherent effect of its simplicity. When your software isn’t doing too many things, and there aren’t much intra-component communication or complex infrastructure setup, your software is reliable by default. You don’t need to invest too much on reliability at this point.
Performance – 5 %. Why? because premature optimization is the root of all evil! At V0, you are not going to have any particular performance or scalability problems. Even if you have. you probably can’t predict them really well when you are building V0, as you may not be fully aware of the expected behaviour of the user and the system. The best thing here is to wait, roll-out and watch as the performance problems occur. “Common-sense” performance optimization is good enough at this point.
Supportability – 5 %. Why? As a V0, you won’t fully know about how and in what ways supportability might be needed. And at V0, the product builders are best suited to provide the support, can be production hot-fixes, or can be pulling data/reports. Then the product builders would get a good understanding of supportability requirements for the future.
Let’s say you are finished with your V0, and your consumers/stakeholders are happy with the software in the sense that they are confident on “this works”. Now the natural next step is (depending upon the business and consumer need), is to build Version 1 of this software, which would be a more complete solution.
In such a case, the efforts allocation can be done in the following ways —
Functionality – 40%. Why? because you are building on top of the simple software that you’ve built for V0. Building functionality with relatively fewer efforts allocation will help you to be focused, keeping it simple, yet delivering what is needed.
Usability – 30%. Why? At this point, you know about what are the most critical pain-points for your users, and you must focus to solve those while keeping it simple.
Reliability – 10% Why? At V1, everyone would expect the software to function reliably. Here you should fix common reliability issues that you’ve noticed in V0 production.
Performance – 10%. Why? at this point, you have already know the performance bottlenecks, and your stakeholders might want to scale it up for the larger audience. So relatively better focus on performance helps here.
Supportability – 10%. Why? because now you have gone through the support process yourself, and you now know what is needed, and you are better suited to build APIs/ tools to better support your software or hand it over to other folks to do it.
With iteration 1, your software is now more stable. Now usually the stakeholders and users expect some new features and better usability with each iteration.
Hence from now onwards, you can do something like this —
Functionality – 30 % — Now you’ve built some base systems and components, adding new features would be easy. You can also use this time to reduce tech-debts or refactoring code-smells etc.
Usability – 30 % — This is the time to really invest on usability. You should really go through each flow, design aspects, and start iterating on improving usability.
Reliability – 20% — Primarily to mitigate the impact of additional functionality being built as part of V2 on reliability, You must not break working software at the expense of adding something new at this point.
Performance – 20% — Primarily to mitigate the impact of additional functionality being built as part of v2 and scale.
Supportability – 10% — to add on to the supportability and tooling that you have built on V1, and to support the new functionality being built-in v2.
From iteration 3 onwards, you will find the “equilibrium” levels of these figures, which should guide you further, in the process.
To conclude, while building software, most efforts should be put on building the functionality, followed by usability, then reliability, performance, and usability. The concrete figures on how much efforts that are put will vary as the time (and iterations) progress, but “FURPS in that order” would still be a general theme.
The figures used in the above example will vary depending upon the type of software you’re building, and are representative of the general idea.
All of this thought process has come from my personal experience building software over the years, and not from a formal course or study on this matter.
What are your thoughts on this? Feel free to share in the comments!