Imagine walking into a large sports equipment store, telling the clerk you'd need some sports shoes. You can expect that this level of 'requirement' will not even get you to the right part of the store. Even asking more specifically for running shoes will only take you to a vast set of shelves with models ranging from sprinting spikes to cross-country trail running shoes. It is obvious that formulating specific requirements here is fundamental for being served well. Obviously, an experienced clerk will support you in formulating and refining your requirements by asking the right questions, and having you try on certain models. In the end you will be able to take an educated decision if the offer meets your needs and taste, and budget.
This is the happy path of requirements engineering. But imagine you are yourself uncertain of what you need or exaggerate on your current skill or ambition. In this case you may well end up with shoes of perfect quality but not matching your actual need at all. Likely a waste of money and not fun to run in.
You wonder why formulating and capturing high quality requirements is neglected so often in business transformation projects, especially those involving IT system implementations.
Waterfall and agile frameworks have the tool set to break down high-level user demands into more and more detailed pieces amenable for development and testing. In either case, accurately capturing the user or business need is the pivotal starting point. However, working top down from a set of starting requirements bears the risk of missing out on critical (starting) requirements or insufficient context.
Especially for complex systems, we at bpExperts GmbH believe that a process-centric approach to requirements engineering – founded on high quality process documentation – is the most robust and sustainable to address the concern above. IT systems are meant to support business processes following strategic and operative objectives. Process-centricity promotes and enforces this ensuring that the needs and expectations of all stakeholders are met, leading to higher satisfaction.
Effective Implementation
The clear association of requirements with the supported business process and objectives enables prioritization and focus on the most value-adding features and capabilities. With this it will be easier to formulate a robust, value-oriented and therefore future-proof implementation strategy, and define a development roadmap starting from a first release or minimal viable product to more mature and functionally enhanced subsequent releases.
Efficient Development
Contextualising requirements with the supported business process and anticipated business outcomes enables developer to see the bigger picture and ask the right questions in case information is missing. The more agile the development process, the more important it is to facilitate collaboration and decision making. Process-orientation provides a reliable reference for understanding dependencies and limitations and connects higher and lower level requirements comprehensibly. In a waterfall setting, this approach enables assessing the completeness or requirements (in scope and content) before the actual development start and thus avoids inefficient change requests.
Quality Assurance and Testing
Especially for complex systems, comprehensive testing of all conceivable paths and functionality combinations is hardly possible nor meaningful. Instead, the established practice is to adopt a risk-based approach to testing. For estimating the 'Severity' of a potential impact it is vitally important to connect a requirement to its contribution to the anticipated outcome. Connecting a requirement to the process supports estimating how often a requirement and the resulting capability or feature will be leveraged and thus drive establishing the 'Occurrence' likelihood. This way, well-written and –anchored requirements enable rational and effective test strategies, easily justified during audits.
In summary, just like the fish rots from the head down, low quality requirements are bound to lead to bad quality or ill-fitting systems. They should be worked out and documented as the starting point for any implementation activity. That does not rule out that requirements may need to be refined, sliced and diced on the way but make sure to not trick yourself. "Reverse engineering" requirements for an existing solution is likely not giving the benefits outlined above.
Anchoring requirements to the business process and business objectives, makes writing high quality requirements easier by supporting comprehensiveness and comprehensibility. High-quality business requirements lead to systems that are not only operationally efficient but also strategically aligned with organizational objectives, providing sustainable value.
Please get in touch if you would like to learn more on how to establish and leverage Business Process Management to support your transformation initiative.