The CTO - my good product friend - Erik Bjernulf and I spent one week in Karlskrona. We visited the World Conference for Requirement Engineering. Both Erik and I were to share some findings on how to work with product requirements. The conference gathered over 300 researchers in the field.
We listened to researchers from Brazil in how to handle requirements in partnerships. We were intrigued by Dutch professors in how to handle requirements on platforms, by Indian doctors to automate the work, and by Intel in dealing with landing zones. It was an intense week by design, a nerdy week for requirements geeks; we loved it.
As we drove home in Erik's extremely uncomfortable Porsche, we discussed the week. What do we bring with us? We ended up with 10 principles on how to evaluate how Requirement ways of working. It is almost like a checklist when designing a process or evaluating your way of working with requirements.
- Framework - on what shall the requirement be applied. Is it a part of service development, packaging, or the technology
- Process - Do we have a continuous way of elicitating (collecting) and handling requirements.
- Ideation - Do we secure that ideation is done in different parts of the process?
- Structure - are we able to structure the requirements into a format we can deal with and connect it with the other requirements (like User Story)
- Validation - Do we have a way to throw away non-valid requirements quickly, so they do not waste precious time (like Triage)
- Valuation - Do we have a way to evaluate requirements from a financial perspective and how they help us implement the strategy?
- Prioritization - does the prioritization model deliver the right result? Based on resources, financial and strategic perspectives?
- Handover - How well is the handover working between the Product team and development team?
- Selection - How is the development team selecting items to develop and release?
- Feedback - how does the feedback flow work to the product team on what requirements are implemented?
In addition, we should also look at the teams involved in doing the work. We have used the 10 principles both to evaluate requirement management work and to design it. It has proven helpful, and it has identified major problems and to fix them.
Attached is the tool and a very brief article on it where the 10 principles are grouped into 5 areas.
Empty space, drag to resize
Empty space, drag to resize
Oops, looks like you're not logged in!
Log in in order to access the tool!
We'll continually release new Instant Solutions
Get The Program Brochure
Submit the form below to have The Program Brochure delivered to your inbox
Sign in or sign up
To get access to all the tools and the show archive.