In my experience, when challenged to improve the quality of their software development efforts, so many software companies put excessive focus on software process methodology.  They read about Agile, Scrum, or some other flavor of iterative development and convince themselves that implementing some specific methodology is going to 'fix' their problems when their primary problems aren't process at all but instead center around their inability to manage requirements and track project status.

For now, let's focus on requirements.  Every software project, no matter how large or small, is catalyzed by a need.  This need is elicited, described, and organized formally or informally into requirements.  Then those requirements are communicated to a development team responsible for actually producing something tangible via a specification.  Unfortunately, a specification usually is a set of documents that read like a drunken stream of consciousness or a set of vague statements someone threw onto a paper to check off the 'we have a specification' box. 

I'm nice in saying that this specification inadequately describes software that needs to be built or the modification of existing software, but improving the specification itself is a subject others have written about more intelligently than I ever could.  My focus is on what the development team does with that specification once it has been inherited.  Typically, development teams just run with whatever they receive regardless of quality (because taking the time to fix things would take too long/don't fit in the schedule/insert lame excuse here), confronting this lump of a specification in one of two ways.  Should the schedule be tailored to fit the requirements as they are?  Or should requirements be right-sized to fit the iteration plan (you do have an iteration plan, don't you)? 

Resources are finite by definition, so it is imperative that requirements be structured in a way that lends them to be managed.  This means the project team should work with the person or team responsible for the requirements and mold them into bite-sized chunks.  Bite-sized chunks can be scheduled, tasked, monitored, tracked, and managed.  This process of organizing requirements is given far too little attention, and I would argue, at least where the development team is concerned, it may be the most important part of the requirements phase of a project, and potentially the most important part of the project altogether.  Without properly organized requirements, a team has very limited means by which to manage the scope and quality of a software project.  If the project scope and quality cannot be managed, odds are the project will fail.

I believe a few rules of thumb of how software requirements are organized can go a long way towards properly managing a software project:

  • Requirements should not be too technical or architecturally focused.  Many software projects will have requirements such as 'Create Data Access Layer' and 'Create Business Objects'.  This is inappropriate.  Requirements should illustrate a business need.
  • Requirements should be relatively comparable.  Ideally, you should be able to say some requirement X is more important than requirements Y and Z.  This is critical when it comes to scheduling work and managing scope.
    • Requirements that are tightly-coupled should be combined into a single requirement.  Resist splitting a large set of tightly-coupled requirements if at all possible, and only split them if the methodology being employed provides no alternatives.
    • A large requirement that, when analyzed, is really a laundry list of needs should be split.  If a project team is forced to trim scope, it will be easy to figure out what can be trimmed if requirements are organized into a reasonable level of granularity.
  • Requirements should not, in my opinion, be separated by type (as some Agile pundits might argue).  Consider the MSF for Agile process template that ships with Team Foundation Server.  There are two requirement-like work items:  Scenario and Quality of Service.  A Scenario might be some business need 'Do X' and a Quality of Service would be 'Be able to do X one thousand times in an hour'.  Those requirements are implicitly coupled, so I think the simplicity of managing one requirement makes more sense.  Ditch separating qualitative requirements that are tightly coupled with a quantitative requirement.  Instead, have qualitative and quantitative descriptions for a single requirement.
  • To borrow Einstein, requirements should be described as simple a manner as possible, but no simpler than is necessary.  Don't get bogged down in describing a requirement in every detail imaginable.  You'll never get it completely right up front, so don't be completely paralyzed by the fact that you don't know everything there is to know before you start laying down a design and code.
  • You should be able to estimate requirements to some level of comfort.  If your requirements are so vague that the estimation process would be more accurate if estimates came out of a bingo hopper, you need more detail and more granularity.

A software project that doesn't start organized will never get organized, so give your project a fighting chance by investing in the elicitation and organization of requirements.  Your project will be easier to manage and the overall goals will be transparent to everyone involved.  This makes for a happy software company where smart people want to work.

For more on software requirements, check out the following reads:
Software Requirements by Wiegers
Managing Software Requirements - A Unified Approach by Leffingwell and Widrig

The requirements phase of a software project is often a combination of sophistry and blind trust, and there is certainly no 'right' way of doing things.  I'm sure you have an opinion, so let me know whether I nailed it, I'm off my rocker, or I'm somewhere in between.

So you might be asking, "I get all of that, but where does Team System enter the picture?"  We'll get to that in this space before I'm done.