On the right tool for the right product
By: Christian Ehrenborg, Simone Bernardi, Celeris AB
On the right tool for the right product
User Stories, Epics, Functions, Specification by Example, Use Cases etc. are often advocated during the software product development process. Still often not enough attention is put on the type of product to be built. Different products require different methods. You use different building technics building a skyscraper or a barn. So, you will have different requirements methods depending on the type of product. There is not a “one size fit all” solution. At least not in the software development business.When looking at this from a requirements management perspective, products can be broadly categories in 4 clusters:
1. Web products are developed to hit a moving target, with high release frequency. They are not maintained for a long period, and no support is provided for old versions. This makes them ideal for a scrum setup, as the development team does the creative design via User Stories, where the requirements writer describes a need and asks the team to solve it.
2. Devices and games have another profile than Web products. In this case there is usually a team designing the look and feel of the product. There is a clear target for the product, and it will be maintained for a few years, after which there will be a new version of the product. The next generation usually leverages on the previous one. So, there is a need for documented requirements and architecture, that can be reused (at least in part) when creating the new version of the product. The big difference is that the creative design (usually limited to the “look and feel”) is created by a team and the other needs to adhere to it. It would namely not be a consistent product if each development team found their own creative solution to their problems. In these projects requirements are often written as detailed stories on how it shall work. The story describes how the user does different tasks. Games have by nature a tendency towards scenarios, specification by example, and epics. Whereas devices – like GPS, MP4 players and smart phones tend to Use Cases. The long stories are often too long to fit into sprints. So, they are cut into smaller User Stories. These are stories without any creative possibilities, they are functional requirements expressed as user stories. So don’t mix this type of User Stories with the type used in Web products.
3. Administrative products are maintained for years to come, and consequently there is a clear need for requirements and documentation. New generations of developers must take over and continue the task of maintaining the system. The creative design was usually done a long time ago and there is little room to solve a problem in a new creative way. Requirements in administrative products target to make sure the right system is built, and describe the purpose and usage of the system for next generation of developers. This means that pure User Stories are not enough. There is the need for the “how” part. How the system fulfils the needs on a conceptual level. This is the essence of the solution, the information you are looking for when you must “get into” an old system. The description that makes you understands both the requirements and why the team selected the actual architecture. One of the best sources for this are Use Cases or Specification by Examples. Depending on the quality of the requirements work; this information may be easy or hard to get, but that kind of documents are the main source. This is the reason why administrative system tends to employ Use Cases as a part of their requirements method. The common way is usually to do Use Cases and then cut them into sprint-able requirements (often in the form of User Stories). But, in reality, you are talking about functional requirements written as User Stories.
4. Critical products like medical devices, airplanes, and military equipment have one aspect in common – if things go wrong, humans can die. This puts several restrictions on requirements management and their product development. Things must be documented (usually via Scenario-based and functional requirements). The design has to prove fulfilment of requirements, which must be reviewed, proved and verified. So, requirements management is stricter, there are more specifications to write and more requirements to verify. Proof is the word. And proofs are generated by verification and traceability.
In conclusion
Different types of products have different needs in terms of requirements management and documentation. It is not due to tradition; it is due to intrinsic needs in the problem of creating and maintaining a product of a specific type during its lifecycle. Failing to identify the type of product and type of requirements management may result in unnecessary inefficiencies and duplication of work, if not substantial financial damage for the companies involved in the development process.
