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.
Agile / Interaction design / Requirements / Requirements gathering / Software requirements specification / UX
Posted on:
Interaction design explained by Alan Cooper
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.
Consulting / Lists / Process Improvement / Project Management / Software development
Posted on:
Top ten tips for preventing innovation
At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.
What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.
Definitions / Slightly off-topic
Posted on:
Definition of NPV – Net Present Value
Net present value, or NPV is the great equalizer of financial analysis.
NPV allows us to compare any two investments and determine which is the better investment.
NPV tells us how many dollars, today, we would be willing to spend to receive money in the future. NPV lets us compare investments that pay back money in very different ways – we can decide if we would rather have $10,000 in one year, or $500 per month for 20 months. Without NPV, the two investments appear to be the same (they both return $10,000), but one of them is better than the other.
Foundation series / Usability / UX
Posted on:
Foundation Series: User Experience Disciplines
UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. There are several disciplines within this field, we’ll introduce each of them.
Requirements / Requirements gathering / Software development
Posted on:
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.
Process Improvement / Software development / Testing
Posted on:
The code freeze is killing the dinosaurs
The software development process for most companies has a flow – gather requirements, design, implement, test, release. There can be feedback loops, iterative cycles, spirals or waterfalls, but they all have these steps. When teams “freeze the code” and submit to test, they are creating their own mini-ice age and dooming themselves to extinction.
Requirements / Slightly off-topic
Posted on:
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.
Prioritization / Process Improvement / Requirements / Software development / Software requirements specification
Posted on:
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.