Software product success.
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.
Prioritizing software requirements
Jason at 37 signals recently posted about essential vs non-essential requirements – the software equivalent of Am I hot or not? He talks about the prioritization decisions their team went through as part of bringing Campfire to it’s launch. Campfire is an online collaboration application that just launched today. We will talk about how their prioritization
A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. We can’t let the other folks have all the fun, so we’ll chime in too.
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.
A real world example of converting from an MRD to a PRD. This is the process of translating from a market-requirements view of the product to a product-requirements view of the product.