if you think about it, tasks itself are goals for projects

I don’t quite agree with that – goals are high-level concepts, tasks are steps that have to be done in order to reach the goals. One goal might map into hundreds of tasks.

I like the overall message, but there is the non-trivial problem of distinguishing a goal from a feature from a requirement. These are all just words. One person’s goal is another person’s requirement.

Ah, you caught me The original version had one more section, on differences between goals, features and requirements, but I decided that the post was too long and something had to be thrown out. There is a lot of ambiguity with those terms, as they mean different things for different people/projects.

For me, both features and requirements describe the viewpoint of the customer, they must not imply a design or a solution.

Features are names of high-level use cases (Bill Heyman accused me of avoiding the term high-level use cases, so I’ll use it here – thanks for reminding me Bill), describing how a goal will be fulfilled. They can almost be used in the promotional material for the finished product (‘Supports all popular credit cards’). Features give you a notion of what might be required, and provide a framework for discussion and design, but do not go into the details.

Requirements are for me low level, describing how things work from a user perspective. This is also where business and technical requests come into play. For the credit card example, the requirements list might include ‘System allows punters to register a credit card’, ‘System requires punters to verify the address using voice or SMS before processing any transactions’ and ‘System keeps card data in a PCI-compliant storage’. I’ll quote Scott Berkun again: ‘At best, this is a list of victory conditions, describing what the end result will be, without explaining too much about how it will be achieved‘. On the end, I try to specify requirements so that they can almost be used as a contract for the project, so they are detailed as much as possible, to avoid ambiguity. Often, requirements list can almost be used to produce a work-item list (technical specs do a better job for this, but you should be able to anticipate work items from the requirements list).

You could try to differentiate the “why” from the “how” as the rubric, but that is slippery as each why is based upon an assumption which has it’s own why.

You could try to differentiate based upon the border of the system being built. If the why involves measurements external to the system being developed, that can often be determined. (Reminds me of context diagrams from the old Yourdon/DeMarco days).

Or maybe you define the context or “point of view” for every statement. A goal may be from the point of the view of the customers boss or customers. A Feature is from the point of the view of the system user. A requirement is from the point of the view of the system builder.

All of the above crossed my mind as I tried to decide whether to use this article to provoke thought on a current product planning exercise.