Introduction to Gathering Requirements and Creating Use Cases

Studies indicate that between 40% and 60% of all defects found in software projects can be traced back to errors made while gathering requirements. This is huge! Finding problems while they are just in the planning stages is MUCH easier to deal with than finding them after the code has been written. So, how can developers avoid these errors and create a solid design for their software? This article will describe various methods for gathering software requirements and writing Use Cases - the first two steps in the software development process.

Imagine you are about to build a house...

You're not sure exactly what you want to build, but you know you want a "nice" house, a "big" house, and you know that you have a budget of $200,000. So, the first thing you do is go to the lumberyard and purchase various materials - lumber, windows, doors, drywall, roofing and cement blocks. You get the materials delivered and you grab the first 2x4 and start building the house. Blueprints? Who needs them? Heck, you know what you are doing and you've been inside a lot of houses right? This notion, of course, seems absurd, but that's exactly the way most software applications are built today. Developers talk to the client for a few minutes, get a general idea of what the client needs, and then sit down at the computer and start to code...

Wait a minute! There are better ways to do this! You may want to say, "But I don't have time to figure all these things out, I've got to get this done! The deadlines are tight on this project!" Before you do, take a moment to consider how much quicker it is to fix a problem early in the process, rather than later. The earlier you discover the problems, the less time is wasted and the fewer things are affected. If we take a look back at the house example, think about this: how much quicker and cheaper would it be to change the blueprint and build a two-story house rather than to build a one-story house and then rip off the roof to add the second story? The typical outcome of incomplete requirements is a huge gap between what the developers think they are supposed to build and what the users think they will get. This, of course, makes the software take longer to build and drives the cost up.

So, let's take a look at what exactly software requirements are and what techniques we can use to collect them.

Requirements

There are basically two types of software requirements - Functional and Non-Functional. As the name implies, Functional requirements describe the functionality of the product. They describe exactly what tasks the software must perform. Functional requirements define the scope of the system, the product boundaries, and its connections to adjacent systems. Functional requirements also define the business rules. Business rules are the rules that the system must conform to, based on the individual business. This includes defining the data that must be tracked. The business rules are the most important type of functional requirements and most of your requirements will be of this type.

Non-Functional requirements describe the look and feel of the system. This includes the visual properties of the system, its usability, and the performance requirements - how big, how fast, etc. Non-Functional requirements also include the product's intended operating environment and any maintainability, portability and security issues. Non-Functional requirements also include cultural and political issues as well as legal requirements that the software must conform to.

It's important to point out that various sources, such as books and web sites, describe the different types of software requirements using other categories, often with contradictory terminology. The important part, however, is not which category the requirements fall into, but that all the requirements in the business process have been identified and documented.

So, now that we know what types of information we should be collecting, let's take a look at the characteristics of good requirements. Good requirements have the following attributes. They are:

• Complete - they very thoroughly describe the criteria
• Correct - they are accurate and true
• Feasible - they can be accomplished and individual requirements do not contradict each other.
• Necessary - they are truly needed for the system to function properly and they are really what the client wants.
• Prioritized - in the case that not all parts of the system can be implemented at the same time, it's important to be able to distinguish "absolutely necessary" from "nice to have".
• Unambiguous - they are clear and cannot be misinterpreted
• Verifiable - once implemented, it can be confirmed that the system has met the requirement through observation and testing

By: Ellen Whitney

Ellen Whitney, Vice President

Ellen Whitney is Vice President of EPS Software Corporation, as well as a senior developer specializing in the design and implementation of object-oriented software systems. Ellen’s thorough knowledge of the development process has benefited many clients as well as having made her a lecturer and international author. She is also Managing Editor of CODE Magazine and has been architecting software since 1989. In her current role she works extensively with the Sales and Marketing Departments and is responsible for setting the overall goals and direction of the company.

ellen@eps-software.com