Question 7 in The Joel Test: 12 Steps to Better Code is about knowing what you’re building.  For an organization this often means a spec.  It almost always meant having a spec when the Joel wrote the test in 2000.  These days writing a technical specification is out of fashion in a lot of startups and small teams.  While the method of documenting it may become unfashionable, knowing what you’re building never goes out of fashion.

The Joel Test:
7. Do you have a spec?

The Big Swinging Developer Test:
7. Can you gather requirements?

The term "requirements" is one of those words in development that everyone knows, but doesn’t always agree on the defintion.  Some folks think of hundreds of pages of text that comes from a wicked-expensive consulting firm and always starts with "The system shall".  Others may think of User Stories or some other agile term because the most agile aspect of agile development is, in fact, the terminology.  My personal definition is "knowing what the system needs to do in order to be considered a success."  I split this incredibly broad statement into three buckets, based on who is affected by the decisions made.  These folks, incidentally, are the same ones who should be consulted throughout any requirements gathering phase.

Group 1: The Users
This one may seem like a no-brainer, but if that were the case then fewer companies would get it wrong.  Gathering requirements from users is all about finding out how they approach the problem that you’re trying to solve.  Getting this information can be as easy as asking the following questions:

1. What are you currently doing that works well?
2. What are you currently doing that’s difficult?
3. What is it that you wish you could do, but currently can’t?
4. What is it that you currently do, but wish that you didn’t have to?

Note that "gathering requirements" is different than "writing requirements".  Being a Big Swinging Developer means adapting to your environment, so if you’re in a consulting role in a large org, that may mean firing up Rational’s RequisitePro and cranking out your findings in "The system shall" format.  If you’re in a smaller and (dare I say it) more agile environment, it may mean that all documentation must be submitted on cocktail napkins.

Group 2: Other Developers
The single most ignored source of requirements is hiding in plain sight: other developers.  The chance of you being the only developer to work with your app is indistinguishable from zero.   Whether it’s integration, enhancement, maintenance, or whatever else, other developers will need to use your stuff.  This is where things like plug-in architectures, configuration flexibility,  and APIs come in.  Or ask how  your code will be tested for both functional completeness and performance.  Look down the road and picture what future developers on the app will need, much like you look down the road to picture what users will need. If you’ve never thought about it before you’ll be amazed at how all those little decisions can affect the success of the app in the future.  One of the reasons that developers get ignored as a requirements source is that most developers consider these types of decisions to be design decisions.  But how can they be design decisions if the requirements are unknown?  If you think that you know everything there is to know about what an app will ever need then you’re probably impossible to work with.  Learn how to ask and it’ll pay off big time.

Group 3: Operations
One of the things I learned from the really good developers at BindView was that software needs to participate well in a network ecosystem.  This means that everyone runs their network a little differently and you need to meet the network’s needs rather than requiring the network to meet yours.  This is especially true in enterprise software, but it still holds true for web apps since you have folks running the hosting setup.  Operations requirements is everything from installation, to provisioning (i.e. adding new users and reference data), to security (I pity the fool who releases a Windows app that doesn’t support AD groups), to logging (for monitoring health and errors), to backup (including archival/retrieval of old data).  If you’re doing in-house development then this can be as easy as talking to your operations folks and you can even use the list of 4 questions above.  If you’re selling commercial software, make sure you talk to your customer’s network admins about their needs.  Nothing will kill you in a purchasing bake off like the inability to play well with Operations.

In the list above, you’re only responsible for being a representative of the second group.  You don’t have to be an end user of the system and you don’t have to have extensive operations experience.  What you need is the ability to talk to these folks about their need, but above all else you need a genuine respect for the impact that your software will have on them.