Software product success.
Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.
Cote’ recently posted a good comparison of the features of Enterprise Software versus Consumer Software. Although we may not agree with all the items in his lists (consumer software can have a login, and very often does have upgrade paths), we do appreciate the general classification. And we really like his insight:
Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to – a […]
Effective listening skills yield great requirements The better you are at listening, the more people will want to tell you. If you’ve ever watched The Actor’s Studio, you’ve heard over and over that the most important skill in acting is reflective listening. A marriage counselor will tell you that step […]
Learn from an early mistake of mine At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of them. The setup We were engaged […]
From Start to End has a great post, Some tips on presentations. Very little we can add here – check it out. Our top five presentation tips (our first four picks are from the list behind the link) Know your audience. A key preparation – you have to have a […]
Too many companies don’t document their requirements.
Worse still, too many companies over-document their requirements.
Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). Seven to ten people is a good number […]
We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.