There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.
This Software Sucks! – Say Users
You need to read Scott Berkun’s Essay # 46 – Why software sucks (and what to do about it). His content is great, his style is easy and fun, and he has good insights. If his other essays are this good, he goes in the same bucket as Joel Spoelsky and Paul Graham for us. As Berkun points out, we don’t set out to write bad software. Here’s how we can avoid some of the different mistakes.
Second-Mover Opportunities: Bringing a Gun To a Knife Fight
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.
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.
Dilbert gathers requirements
Another great Dilbert – http://dilbert.com/strips/comic/2006-02-26/ 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 […]
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.
The Reason Why
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.
Software Requirements Specification Iteration and Prototyping
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.
Software development process example
We’ve presented an example of the software development process across several posts over the last two weeks. In this post we tie them all together, showing the steps in process order.