The main point of Laura’s article is the importance of engaging users to find out what they really care about. In this post we are going to pick up on another point she makes indirectly.
Laura also points out indirectly that the inclination of companies is all too often to build software that looks good on paper instead of software that is good in practice. A sort of rat-race of me-too’s and copycatting. Companies that add features solely because the competition has them are in for trouble.

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.

Another great Dilbert - http://www.dilbert.com/comics/dilbert/archive/dilbert-20060226.html
I won’t show the cartoon here, but here’s a quote from the first two panels:
Pointy-haired boss: Why is your project four months behind?
Dilbert: I still don’t have the user’s requirements because she’s a complete nut-job.
[...]
This cartoon does point out the critical importance of eliciting the requirements, not requesting the requirements. [...]

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.

Why won’t my boss approve my project? I’ve done the math - it’s a good investment. Because it isn’t good enough. We learn the math and rationale behind these decisions in this article.

What do you hate about Tyner Blain’s blog?
ack/nak posted a great idea - ask customers what they hate about you.
Seth Godin has a book - Permission Marketing: Turning Strangers into Friends and Friends into Customers, and in his free ebook, Flipping the Funnel, he expands on what he originally wrote. He talks about [...]

Seriously.

There’s a crazy deal being offered by Axosoft. Buy a 5-user version of their $500 software suite for $5, but the offer expires February 24th. The link to buy the software is here - and only available on blogs. Axosoft is trying a social marketing experiment to see if they can promote their products and brand via the blog universe. It isn’t clear at what hour the offer expires, so you might want to get it on the 23rd.

Should we test our software? Should we test it more?

The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”

We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?

Seth Godin has a post titled The Reason. In each of his examples, Seth asks and answers the reason why we do things that don’t have an obvious rationale.

Requirements elicitation is about asking why. When we ask why correctly, we get great insight, which enables great requirements, which can yield great software. When we ask why incorrectly, we can get a great big mess.

Developing great software requirements demands iteration

In our previous post of an example of the software development process, we showed a linear flow through the process, as depicted in several posts over a couple weeks. What we failed to show was any of the iteration cycles, as Deepak points out by asking a great question in the comments on that post. In this post, we will show a little more about how the process works by showing how iteration fits into the machinery of software development.