(this is a post moved from my old blog.  My old blog post now links to this one)

I've been asked this a few times now:  "If I have a functional or technical requirement, why do I need tasks?  The requirement IS my task, right?"

The answer is, as is the case for most topics of debate in the world of PM/RM/CM/SCM (enough already!), it depends!

(NOTE: Before reading further, try to dissassociate these terms from actual physical entities in a tool.  By this I mean, don't think of MS Project whan I mention a "task", and don't think of a Word document when I discuss "requirements.")

Requirements and tasks, while they both can be interpreted as instructions for work, inherently have attributes unique to themselves.  To explore and identify these attributes, let's look at the definition of each.

Requirements

A requirement, defined by our friends at dictionary.com is:

  1. Something that is required; a necessity.
  2. Something obligatory; a prerequisite

Does this definition mention that this is an instruction for work?  Yes and no.  While a requirement doesn't necessarily state "Go do this," it does have that implication.  For example:

FR 101:  The system shall provide a search mechanism.

All vagueness aside, this requirement doesn't actually directly say, "Build a search mechanism".  It more simply states that in order for this project to be successful, there needs to be a search mechanism.  But the task itself is implied:  "The system shall provide a search mechanism[, so go make one]."

Requirements are success criteria, answering "Why are we doing this?", and "What exactly is this thing going to be?"

If you have a relatively small team, detailed requirements, and don't see the need to record work done against requirements implementation in much detail, then simply using requirements as "assignments of work" may be perfectly feasible.

Tasks

A task is defined as:

  1. A piece of work assigned or done as part of one's duties.
  2. A difficult or tedious undertaking.
  3. A function to be performed; an objective.

Tasks, by definition, are much more explicit in their direction to a particular consumer.  They specifically attribute themselves to a consumer as a unit of work to be done.

Tasks are work criteria, answering "What exactly am I supposed to do?"

If you have a need for more granular work tracking, or your requirements are defined in a way that it may take multiple consumers or efforts to implement them, I'd recommend using tasks to at least some degree. 

Using Requirements and Tasks Together

The easiest way to see a marriage between requirements and tasks is by admitting that some requirements may need multiple things to be done to be implemented.  Take our earlier sample requirement:

FR 101:  The system shall provide a search mechanism.

Simple enough, right?  Well, to implement this requirement, perhaps a search dialog needs to be created.  A database query needs to be established.  The actual search operation itself may need to be threaded to minimize impact to the foreground application.  If you're a PM managing your development team, you may want to know more specifically what your developer is working on today than, "I worked 5 hours on FR 101".  You will see better reporting metrics if instead you can see, "I worked 2 hours on the search dialog, and 3 hours on the database query."

So what?  Why does all this matter?  Whether or not you use both requirements and tasks, or just one type of artifact, is ultimately up to you.  But take a gander at user scenarios/needs that I've experienced, and you might get a better idea of what to do in your environment:

Scenario/Need Possible Solution
Small team, most with multiple roles.  Fast, "crank-it-out" style of develoment, with customer-defined requirements. Requirements.  You may not care about how the customer's needs break down into units of work, and your team is small enough that everyone pretty much knows everyone else's load.
Medium-sized team, with BA's, PM, and developers.  Quick-churning style, but requirements are more refined, and are managed independently of development effort. Requirements + Tasks.  If requirements are managed separately from development, and are refined "on the fly", breaking requirements down into development tasks will better provide the PM control over the work assignments of his/her team.
Large-sized team, with BA team, possibly more than one PM, dev leads, and developers. Requirements + Tasks.  A team of substantial size needs to have measures behind different phases of software delivery, for load-balancing, productivity tracking, cost allocating, and often regulatory compliance.  The PM, or even the VP of App Dev, will need metrics to see how requirements are being translated into workload in the development phase.
Small- to medium-sized team.  Little or no customer-focus ("grassroots" application). Either, not necessarily both.  You can use requirements as elements of work, and capture overall implementation, or use tasks to simply define the work to be done (the task itself will imply the requirement).

Well, that's my 2 cents.  I know there are many opinions out there (I'm sure there are even more approaches!) about this topic.  The beauty of having multiple solutions to an issue such as is this that it allows us PM's and SCM guys to keep jobs!