The amazing adventures of Doug Hughes

Acquire Your Requirements

February 4, 2005

Before one can begin building an application one has to know what it is that the application needs to do. This sounds like a simple idea, but it’s really not. Take a look at my old entry on why software projects fail and you will see that the first reason listed is "Project Requirements are Poorly Defined".

Many failed projects start out with great intentions. Perhaps a developer, manager, business analyst or executive comes up with a brilliant idea. Immediately, a developer, or a whole team of developers, is called into an emergency meeting and a brain storm session ensues. In this session ideas fly widely! Proposals are proposed! Considerations are considered! Ideas are thought out, planned, sliced, diced and dissected. A new application, website, component or whatnot is conceived. Then, when the orgy is completed, everyone stumbles out of the conference room, feeling a little dazed, strung out and worse for wear.

But the ideas! Oh, the ideas!

Three weeks later the team is reassembled for a demonstration of the new application, website, component or whatnot. But, the afterglow is gone. The orgy of ideas has turned into a nettlesome collection of preconceived notions. The product which is demonstrated does not do what anyone expected it to! How can that be? Everyone agreed on what the project would be, didn’t they? Well, let’s check the requirements document…

Wait a second; we don’t have a requirements document!

Oh yes we do! The developers took notes!

Notes?! Did someone sign off on the notes?

It turns out that, no, no one signed off on the notes. And even if they did, the notes were composed entirely of these words:

Build a new application, website, component or whatnot with a bunch of wiz-bang features.

Has this ever happened to you? I expect so. The question then beckons, what can you do about this?

The answer lies in requirements gathering. I have a simple forms application I wrote which I work though when gathering requirements. The form focuses on the following items:

  • The business process which will be modeled by the application
  • The user and systems which will use and interact the new application
  • The resources which the system depends on and creates
  • The functionality of the system as related to the first three items.

At some unspecified point in the future I will release this application for free. I can’t do that at the moment. As a substitute I will provide the questions on this form.

Before we get to that point, consider that a requirements document is fluid and should feed the design and architecture phase of development. I prefer an iterative technique where each iteration builds on top of work completed in previous iterations. On each iteration you should revisit the requirements document. You will want to adjust it to incorporate new requirements and update it for the next iteration’s requirements.

You may also want to consider keeping versioned numbers of the document. The version number might correspond to the latest change requirements. You can also refer your clients to specific versions of the document when they have questions. Lastly, your clients should sign off on the requirements for each version of the document.

The requirements document also feeds right into the first phases of architecture. The first steps into a UML diagramming tend to be though Use Case and Class diagrams. Your requirements document will help you better identify your use cases and actors which lead into modeling classes and then into other portions of UML.

Without further ado, here are the questions I use when creating my requirements documents:

General

  1. What is the project name?
  2. Provide a document version number.
  3. Quickly describe the business process which will be modeled or replaced.

Business Process

Identify major portions of the business process. For each, answer the following questions.

  1. Name this major portion of the business process.
  2. Describe this major portion of the current existing business process.
    1. What are the goals of this process?

System Users

Identify the system users and roles. These may be people, systems, devices, etc. These are classifications of people and not individuals. For each user or role answer the following questions.
General System User Info

  1. Identify the user or role.
  2. Identify the type of user or role (person, system, device, etc).

Description

  1. Describe the user or role.

Responsibilities

  1. Describe the user or role’s responsibilities.
    1. What are the user or role’s responsibilities?
    2. Do may people share the same set of responsibilities with this user or role?
    3. How do this user or role’s responsibilities different from others?

Constraints

  1. Describe any unchangeable constraints which affect how this user or role performs their responsibilities. For example:
    1. Are there any legal, contractual or regulatory restrictions on how this user or role does their job?
    2. What authority or access rights are required to do this job?

Rules

  1. Describe any existing rules, policies or procedures which determine how the user or role does their job.

Resources

  1. What information or resources is this user or role dependant upon? For example:
    1. What resources does the user or role acquire and dispose of?
    2. What information does the user or role rely on to do their job?
    3. What information is the user or role responsible for (approving, acquiring, requisitioning)

Performance

  1. Describe any system performance related considerations for the user/role. For example:
    1. How many of this user or role will need to use the system?
    2. How many of this user or role will concurrently access the system?
    3. How slow can the system be before affecting the user or role’s ability to perform their responsibilities?

Resources

Identify resources, information, or data which the system will rely on. Refer to the resources section under system users for examples to draw from. For each resource answer the following questions.
General Resource Info

  1. Identify the resource.
  2. Describe the resource.

Constraints

  1. Describe any unchangeable constraints on this resource. For example, legal, contractual, or regulatory constraints.
    1. What restrictions influence the acquisition of the resource?
    2. Are there any legal or contractual constraints on how the resource is used?

Rules

  1. Describe any existing rules, policies or procedures which affect this resource.
    1. What level of authority is required or who is allowed to use the resource?
    2. What policies govern the use of this resource?

Performance

  1. Describe any performance related considerations with this resource.
    1. How much time is allowed for transactions using this resource?
    2. Does the quantity of the resource affect the system’s ability to process it?

Functionality

Identify the functional portions of the system. Review the user section for inspiration. For each piece of functionality answer the following questions.
General

  1. Identify the functionality

Description

  1. Describe the business process requirements for this element of functionality.
    1. Describe why a user needs the system to have this functionality.
    2. What do users expect to happen when this functionality is used?
    3. What happens if this functionality does not work?
    4. What are the possible outcomes for this functionality?
    5. Which users/roles use this functionality?
    6. If different users/roles use this functionality, do they do it for the same reasons?

Constraints

  1. Describe any unchangeable constraints on this functionality. For example, legal, contractual, or regulatory constraints.
    1. What restrictions influence the use of the functionality?
    2. Are there any legal or contractual constraints on how the functionality is used?

Rules

  1. Describe any existing rules, policies or procedures which affect this functionality.
    1. What level of authority is required or who is allowed to use the functionality?
    2. What policies govern the use of this functionality?

Performance

  1. Describe any performance related considerations with this functionality.
    1. How much time is allowed for transactions using this functionality?
    2. Does the quantity of the functionality affect the system’s ability to process it?

Signoffs

To clarify the difference between constraints and rules, think of constraints as unchangeable while rules are agreed upon ways of working. For example a tightrope walker can agree to use a net but can not change the law of gravity. The law of gravity is an unchangeable constraint. The use of a net is an agreed upon way of working and is changeable.

I have an example requirements document I wrote for the ongoing UML entries I’ve been adding. The requirements document is for a Search System API based around the Lucene search engine. The document can be downloaded in the attachments section below. Because this is merely for internal development I have not added a version number or a signoff.

I will be following this entry with another entry on UML use case diagrams.

What’s your strategy for requirements gathering?

Category:

Blog

12 Comments

Comments on: "Acquire Your Requirements" (12)

  1. Boyzoid said:
    February 7, 2005 at 12:00 am

    My requirements process follows a very similar flow as your example. It has aided me tremendouisly.

    I am currently working on a fairly big project for my former employer. The president of the company is notorious for, "Can we make it do this?" When I made it do that, he would say,"OK, now can we make it do this?" More often that not, the second question would force me to re-write what was produced from the first question. Had I known the second question from the start, I may have approached the solution to the first question differently.

    To avoid ‘scope creep’, after the requirements or specifications document had been signed by the client, anything request for changes or additions, gets its own requirements document, and is not part of the original agreement or project (Translation: more $$$$).

    Like

  2. Vishnu Prasad said:
    December 20, 2007 at 12:00 am

    njh

    Like

  3. Jonathan said:
    September 16, 2008 at 12:00 am

    Hi Doug,

    Did you ever release this requirements application?

    Like

  4. Doug Hughes said:
    September 17, 2008 at 12:00 am

    @Jonathan – No, it never really saw the light of day.

    Like

  5. Jonathan said:
    September 17, 2008 at 12:00 am

    I’d love to have a copy if you have it lying around.

    Like

  6. Abel Davila said:
    December 16, 2008 at 12:00 am

    Agreed. I would love a copy of the requirements application as well.

    Thank you.

    Abel Davila, ACIR, CDR
    abel.davila@abbott.com

    Like

  7. Kevin Frye said:
    April 28, 2009 at 12:00 am

    I would love to have a copy of the requirements application as well.

    Like

  8. Vibhanshu Sharma said:
    June 7, 2009 at 12:00 am

    Great Blog Doug. I would love to have a copy of the requirements application as well.

    Like

  9. Dini said:
    July 13, 2009 at 12:00 am

    Hi,

    I would also love to have a copy of the requirements application as i would help in my learning.

    Ta

    Like

  10. Doug Hughes said:
    July 13, 2009 at 12:00 am

    Sorry, this application when the way of the dodo. It’s not around any more. Sorry! I hope the article itself is still useful.

    Like

  11. Kamlesh said:
    September 27, 2011 at 5:30 am

    Hi, I would love to get the copy of the application as well. it will help me creating my college project related to the online examination system.

    Like

  12. UML: Use Case Diagrams « Alagad – Custom Software Done Right said:
    February 11, 2013 at 5:50 pm

    […] my series on learning the UML. This entry covers Use Case Diagrams. This entry builds on top of my entry on requirements gathering which was posted last week. I will be using the requirements document created for that entry to […]

    Like

Comments are closed.

Tag Cloud

%d bloggers like this: