10 May 2004 | David Heinemeier Hansson said...

It's a great way to establish a baseline that says "less than this isn't really all that helpful", but I think it should be a horizontal ruler on a larger list: The complete prioritization of all features in the specification.

This is important for two reasons:

1) If you, as the client, doesn't specify the order in which features are to be implemented out, someone else will. And that someone won't have the insight into your business or domain. Which means they'll prioritize for different reasons (such as what is most fun).

2) Once you've received 25% of the most important features on that list, it's more than a little likely that you'll change your mind about the remaining 75%. You'll recognize that some things aren't really needed after all and others are even if they weren't specified to begin with.

So explicitly prioritizing the entire list will make it much easier to change your mind about the requirements. At a time when you know more about what you want.

Morgan Jones, a former CIA analyst, has an excellent tool for doing this prioritizing on large lists. It's called pair ranking. He talks about it a lot in his wonderful book called The Thinker's Toolkit. There's an amazon excerpt on the pair ranking available.

10 May 2004 | gavin said...

Here's what we've been trying: instead of a traditional functional spec for a feature, give us the Top 10 things this feature needs to do. Don't use conjunctions; simple sentences only. No more arguing about the format of the spec or trying to deciper Word's version control or going back and forth on something tangential. These Top 10 sentences have provided similar benefits to what you're seeing with your "at the very least" clause. Great stuff.

10 May 2004 | Darrel said...

I concur.

Change of subject:

Can you get the Firefox, can't-scroll-left-to-see-rest-of-SVN-bug fixed? (You need to give your body a min-width = to the width of the container DIV).

10 May 2004 | Brenda said...

By functional specs do you mean functional requirements? Generally, a functional spec is a different doc.

As a requirements-gathering technique, I agree that the approach you mentioned is elegant. But much too vague to be a "spec". Great for having conversations with clients and setting expectations. Not so useful for the people who have to actually build the thing on an impossible schedule and budget -- which would require a prioritization scheme more complex than "bare minimum" and "balls out".

10 May 2004 | JF said...

By functional specs do you mean functional requirements? Generally, a functional spec is a different doc.

Yeah, I meant requirements. I'm not much one for terminology and labels so I botched it. ;)

11 May 2004 | dan said...

In our design documents we've taken to prioritizing the requirements with mandatory, important and optional. Like you said it has helped whittle down the requirements into what we really need. It's also nice to be able to squeeze in a few optionals to make people happy.

It has worked out quite well.

11 May 2004 | Scorched said...

find a book called "Secrets of Software Success"
I make three lists for every project: Must Have, Would Like to Have, Would Be Nifty to Have

I would elaborate, but I'm in the middle of a Must Have list.

11 May 2004 | ~bc said...

Hey, is there any good resources that give some guidance on creating specs, and RFPs for shops that are just starting out? I've worked with a few clients thus far, freelance w/ a partner, and this is always our weakest point. And of course, everything relates back to these two things.... so we figure, improve these, improve our client relationship, and less "oh, also, could you do x,y,z?"

Thanks

11 May 2004 | Don Schenck said...

Uh ... isn't this just RUP? That's how we did RUP. Guess we was just lucky.

11 May 2004 | Rob Jones said...

RUP is way overkill for most projects. If you are building software for airliners or the military its fine (and ususally required), but most web based projects are way too short term and (unfortunately) undefined to do RUP. We have a guy here at work who always wants to do RUP and I swear it looks like it would take us a year just to figure out what need to be in a requirements doc ;)

As far as "must have features ", this is what requirements dictate. I think its a dangerous area getting into "nice to have" requirements. "Nice to haves" are not required, so they dont belong in a requirements doc. Every client I know will expect those to be done once they see them in docs.

Sometimes we have ideas that can be added that make the interaction nicer (But take time to implement) and we put thses extensions onto our use cases, but definitely dont add them to the requirments doc.

good thread!

11 May 2004 | Don Schenck said...

RUP doesn't need to be overkill, although most zealots end up pushing it that way.

RUP can keep it's width, you simply don't go as deep. A requirements document can be simple and short; it's the process that works, not the documentation or it's complexity.

We fought that battle to the point where the process became more important than the product. But we fought on and won that battle and the development war.

11 May 2004 | Matt said...

You should only work on the "at the very least". This isn't doing the minimum. Adding feature X would be great, but using Y with feature X would be what would really draw in more business - then it seems worthy to invest in the expanded Y with X and that should become the important requirement and the new "at the very least". Something either is important or it is not - and there are several variables which factor into this.

12 May 2004 | Notablog.com said...

I was just in the happy position of submitting briefs to 3 professional branding agencies. Each agency sent me a word doc to complete with several questions. Although each was quite different each one used some variation of the "at the very least" idea. I think it is a good way of eliminating some of the chaff which comes when a company (or a person even) talks about themselves and where they want to go.

25 May 2004 | Jaime said...

I follow with Scorched. I always have a "priority" property in my requirements. A line item is always a "Must Have", "Should Have", or "Nice to Have". I define them to clients as a "Must Have" must be included or the project will not be successful. A missing "should have" will not absolutely keep the project from being successful, but it will severely impact the likelihood. A "nice to have" is not necessary, but if schedule and budget allow, it will make the project success rate soar.