Coming back to Jochen König's post about the relationship between system quality and requirements management (Why system quality starts with business requirements quality) I would like to add some hands-on examples.
When entering a shoe shop to buy some new ones for a specific purpose, it is advisable to think about desired features, appearance, sustainability or situation to wear beforehand.
However, usually the situation is different. You are entering a shoe shop with your kids, partner or friend giving you advice:
Take the pink ones with glitter, Mommy, they look great!
I would take the black ones as they do not look dirty that fast.
Let's buy pumps instead of running shoes to go out tonight!
And the nightmare takes it course leaving the shoe shop with pink glittery pumps you will not be able to wear in muddy forest for your next training session. To go out at night failed as you are totally tired and just decided to choose the couch for spending the evening.
Sounds quite familiar to my digitization project situations where we usually have not only one business representative to collect and especially formulate requirements but several ones from different departments. In the middle of this, solution architects totally confused, trying to design suggested requirements into the new tool. What a mess, usually ending in a lot of very general or ill-fitting requirements formulated to finally escape from these exhausting workshops.
Ineffective requirement
"I want a button to schedule production so that we can make new material."
We at bpExperts believe this is where applying a clearly defined Business Process Management (BPM) methodology provides guidance throughout the requirement collection sessions and helps visualizing the corresponding discussion points.
A sequence flow in our business scenarios visualizes inter-department or inter-domain interactions where input data from one domain is required to fulfill the subsequent business scenario in another domain. Predecessors and successors are visualized to summarize the flow from end to end.
For each specific process an adapted SIPOC (successor - input - process - output - consumer) technique guides finding all elements for formulating effective requirements related to departments & business roles, input and output data, relevant compliance topics, etc., that need to be considered or KPIs that are supposed to be achieved.
Effective requirement
"As a Production Scheduler, I want to be able to quickly create and schedule planned orders for new product launches in the production planning tool so that we can efficiently meet the market demand within the Make2order scenario and optimize resource utilization. "
Looking at the figures above, you will find it easy to see how the 'effective requirement' references the model and thus provides the context and detail for a 'right first time' solution design and implementation. Where needed, the models also guide business or solution architects in fleshing out further details, e.g. on required data or regulatory boundaries. And maybe most importantly, the model context enables prioritization and sequencing requirements from a business (value) perspective.
In summary, the activities around requirement collection may look costly and time-consuming. However, it enables your team to elaborate about a specific requirement in detail, learning more about the surrounding environment and the end-to-end-flow throughout the company. Especially business representatives in digitization projects get a clear structure to nail down their requirements specifically and reducing the extra effort later during implementation, testing or training when requirements have not met their expectations.
Please get in touch if you want to learn more about process management capabilities to facilitate your requirement engineering.