Strategies for Successful Development

Process and technology for small teams building real software

The No-Spec Spec: Purpose

Posted by S4SD (Seth Morris) on 2008/10/09

This is part of the series The No-Spec Spec

"Purpose" Description

The Purpose document is the user- and client-focused The purpose document is fairly close to an MRD (Market/Marketing Requirements Document). If you have a good MRD, you could call it the Purpose and move along, but the chances are that a team that can’t get a good spec also can’t get a good MRD.

The Purpose document may be somewhat longer than the Fit and Identity pieces, depending on the level of detail and size of the project. It should answer:

  • Why will a user use the product?
  • What problem will the user expect the product to solve?
  • What business process (or user process/goal) is the user trying to accomplish when using the product?
  • If the customer is different from the user, what is the customer’s goal?

These seem very basic, but they form the reality check for functionality. Late in a project, these are the ultimate test for any change in requirements. Referring to these can prevent most late-project schedule- or quality-damaging changes and almost all developer gold-plating.

This is a simple document. Hopefully the product managers can produce it in 30 minutes or less and hopefully it contains less than two pages of text. It may be longer if the Purpose requires images or background information to explain1, but the critical user and client goals should be relatively short.

Change rules:

    If the Fit changes, this and all other documents need to be rewritten. The Fit may indicate that the user, customer, or business problem has changed.
      The Fit may change without affecting the Purpose if the business model or the business environment changes but the user doesn’t. This is a good thing. It means that even though the project relates to the company/team in a different way (and presumably the old way was wrong), but the problem the project was trying to solve was correct. The need still has to be filled (and all the work up until now is still valid).

    If the Identity changes, the purpose needs to be re-examined. The Purpose is the how to the Identity’s what—and to some degree to the Identity’s why. If the product as a whole is different, that probably indicates that the goal of the product has changed.
      If the Identity changes and the Purpose doesn’t, that indicates that the Identity was incorrect to begin with, but again the problem the project is solving was identified correctly.

If the Purpose of the project changes, you need to re-evaluate each of the:
    Assumptions: What is true about the new problem or value-add that wasn’t true before?
    Environment: Does the new Purpose indicate a change in where, when, or under what conditions the product will be used?
    Capability: Is the new Purpose part of a different larger framing context?
    Behavior: What is the new functionality? This is the item almost certain to change if the Purpose does.

1) Examples of projects that might require additional detail in a Purpose document would be financial software that should include background information on the behavior of the financial instruments, kiosk software that may require screen mock-ups to indicate process flow, or software that cannot assume literacy in the localized language and requires special interface elements.

Listening to: King Crimson – In the Court of the Crimson King – Moonchild/The Dream/The Illusion



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: