Requirements / Software requirements specification

Joel Spolsky Speaks Specs

Posted on:

It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.

Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons

Product Management / Requirements / Requirements gathering / Use Cases

Challenging Requirements

Posted on:

The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.

Process Improvement / Project Management / Software development / Use Cases

Where Did You Get That Estimate?

Posted on:

How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.

Austin TX / Requirements / Software development / Software requirements specification

Requirements vs Design – Which is Which and Why?

Posted on:

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.

Communication / Requirements

Everything I Needed To Know I Forgot in Kindergarden

Posted on:

“WHY?” is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.