Tuesday, January 24, 2006

Gathering Requirements

I wanted to briefly follow up on Tip #2 on my recent post about PL/SQL Coding.
http://thinkoracle.blogspot.com/2005/12/20-plsql-coding-tips.html

I am not intending to convince anyone WHY they should spend time gathering requirements, but rather simply HOW to do it. However, let it be known that there are people whose careers are entirely based on the requirements gathering process, that there are volumes of books on the subject, and there exists methods much more sophisticated and involved that what I am going to describe here.

This post is understandably technology-independent, which is good because it is based on my experience along with some articles I've read recently, which has involved a variety of industries and technologies.

Step 1: State Your Vision

Before prattling off a list of what the software must do, you should start by naming some clear, concise key objectives. The basic idea is that all the requirements you are about to list match these key objectives.

Ideally I like to mention in this brief opening statement how the stakeholder's needs can be fulfilled, pain reduced, and/or gain received.

What Are Requirements?

A requirement is based on a specific business-driven need that is necessary to accomplish the stated project vision. Each requirement should be enumerated (or otherwise identifiable), and should only describe WHAT should be provided, not HOW, and should thus not necessarily discuss implementation details. A requirement should also be testable/verifiable, and mention how that is planned to be done.

As I alluded to in Tip #1, my conviction is that the rationale behind a requirement is a necessary step. By explaining WHY something is necessary we can help keep the requirements complete, clear, concise, consistent and maybe some other things that start with c.

Depending on the application, requirements can be related to the functionality, the business interaction (with users), or the technical requirements (eg: time, space, performance, scalability, security, disaster recovery).

For example, requirements can include anything from business rules, the budget, the interface (web-based vs desktop), reporting abilities, performance (number of concurrent users), completion date/schedule, security needs, hardware, software, error/fault-tolerance, user technical level, system maintenance requirements, and so on.

How to Gather Requirements

Is this a brand new product, or is it meant to either replace or compete with another product? If the latter, you should evaluate what that product does, and how it can be improved.

Identify all the stakeholders, such as users, management and the nerds (technical folk). Talk to them either one-on-one or in groups.

Techniques

In my experience, I simply write a document. For more sophisticated approaches, you can look into use-case models, unified modeling language (UML), automatic requirements generation tools, prototypes, storyboard, agile software development or any other host of techniques.

One word about prototypes. Go ahead and use prototypes to help users express their needs. But when you're done, throw the prototype away. Tell management that a quality product will take time to develop, and working with hastily-thrown together prototype code is just going to wind up with a real mess. Trust me: Chuck it!

Common Requirements Errors

Based on some research articles, the most common types of errors when writing requirements are (in order):
1. Incorrect assumptions
2. Omitted requirements
3. Inconsistent requirements
4. Ambiguous requirements

What's Next?

Remember that requirements gathering is a cyclical process. Despite having a single author responsible for this document, there should be several stakeholders conducting several rounds of reviews and inspections. In fact, you should have a way to track the history of the requirements document, and it should be possible to revise it, even after it is finalized (this is the real world, after all).

Prioritize your requirements. You may even want to move some requirements to a "future release" section.

In my requirements document, I als like to add the following sections:
1. A list of all the assumptions that were made during the requirements gathering process, and why.
2. A list of constraints on either the software, the design, or the development process
3. A reference to any industry standards to which you want the software to conform (eg: ANSI SQL), and why.
4. A summary of how we expect the system to be used: how many concurrent users, transactions per day, etc.
5. Project-specific details, like the manpower, time, skill sets, deadlines, licenses, equipment that will be needed.
6. A project glossary of terms used in this application, including acronyms.

Granted this was just one man's very basic look at requirements gathering, but for many small to mid-sized projects, that should get us started in the right direction.

Comments:
Robert Vollman said....
A requirement is based on a specific business-driven need that is necessary to accomplish the stated project vision.


Yup. Don't tell me what you WANT, tell me what you NEED. I'll make sure you get it, but only if you TELL ME about it. The other point you made that I'd like to re-iterate is making sure to discuss WHAT needs to be accomplished, not HOW it should be accomplished. Developers are responsible for figuring out the most efficient methods for getting the task done - it's the users' responsibility to make sure the developer (or the analyst) understands the NEED. How the need is met isn't (or shouldn't be) important to the user as long as it fits the specs.
 
Years ago, I was in an environment where we used the old Oracle SQL*Forms to develop rought prototypes so we could better understand the user's needs. But we decided early on to intentionally put bugs in the prototype so the users (and especially the user managers) wouldn't think we had a nearly-finished product. That tactic served us well many times.
 
Nice article! The part about the requirements gathering process being cyclical is definitely accurate. It is very much an iterative process. The customer must understand the importance of clearly defining the software requirements up front. It can make all the difference in the success of their project. Our job is to help manage the process for them. Part of that involves educating the customer on how they can help with requirements gathering. There are a number of critical elements that the customer has control over that can make or break the success of gathering accurate requirements. We have a two-part series on this topic that you might be interested in: Requirements Capture: 10 Keys to a Successful Software Development Project - Part 1 and Requirements Capture: 10 Keys to a Successful Software Development Project - Part 2.
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?