subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.
We must sell the software first
We write a lot about value-driven prioritization of software requirements. It’s easy (when defining requirements) to forget that we have to sell the product before anyone gets any value from it. With internal use software for large companies (like enterprise software, intranets, erp systems), “sell it” means “get high user adoption rates.” High user rates are key to getting ROI when process-improvement is one of the targets of the software.
Prioritizing software requirements across releases
When prioritizing requirements for the first release of our software, we’ve stressed the importance of including 100% of the ‘must have’ requirements in the first release of the software. We’ve also used Kano analysis to categorize requirements as ‘must be’, ‘surprise and delight’, and ‘more is better’ requirements. In this post we’ll talk about an approach to allocating these requirements across releases.
Prioritizing Software Requirements – Kano Take Two
In our previous post on Kano requirements classification, we introduced the concepts and showed how to apply them. One of our readers commented privately that we didn’t show how to use the techniques for prioritization. We’ll do that in this post.
Prioritizing Software Requirements With Kano Analysis
We’ve talked before about three ways to prioritize software requirements. We’ve also talked about incorporating risk analysis into ROI calculations for requirements. In this post we will look at how Kano analysis can be applied to prioritizing requirements.