OracleBlog

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.