Most developers like to follow the Nike creed: Just do it! The customer comes to us with a business need, and we immediately move into problem-solving mode. We want to jump in and start writing code. There is no better feeling than completing an application and showing the customer. Until, of course, the customer informs us that this is not quite what he or she had in mind.

Developers can sometimes forget that the first phase of any development project is gathering business requirements to understand what the customer wants. It is only when we agree on the business needs that we can move on to the fun stuff—design and construction.

This is the first of five articles that look at some of the main concepts of the analysis phase:

  • What business requirements are
  • How to gather business requirements
  • Process modeling
  • Data modeling
  • Conceptual systems design

At the end of this series, you should have a good sense of what the analysis phase of a large project might include. As always, not all of these concepts need to be applied to all projects. But once you know what the analysis phase may include, you can make a well-informed decision about what to include with your project.

It’s all about requirements
Gathering business requirements is the main purpose of the analysis phase. Business requirements are statements that describe what the customer and major stakeholders need and want. If you are automating a business process, the requirements describe the way the process should work. If you are building a house, they describe the size, room layout, lot size, room color, and so on. I like to think of requirements in two groups:

  1. Product requirements
  2. Process requirements

Between these two types of requirements, everything the customer needs should be identified.

Product requirements
Product requirements describe the business needs in terms of the main deliverables or products that are created. If you were building a bridge, for instance, most of the requirements would be product based. These might include the number of cars the bridge would hold, the strength of the steel, the water level it needs to span, and the color of the bridge.

Process requirements
Process requirements describe how people interact with a product and how a product interacts with other products. For example, when you discuss how data gets moved and how business transactions flow from one point to another, you are describing process requirements. If you need to handle billing transactions, most of the requirements could end up being process oriented. The requirements would include how billing transactions move from orders to invoicing to accounts receivable. They could describe at what points people look up a status, how people manually update an invoice, and what people should do if accounts are out of balance.

Prioritize the requirements
Fulfilling some requirements requires much more effort and cost than others. Therefore, it is important to prioritize the requirements after they are gathered. This could be as simple as classifying the requirements as high, medium, and low priority, giving the business customers and the project team the information they need to ensure that the most important requirements are incorporated into the final solution. In general, all of the high-priority requirements should be accommodated. As many medium requirements should be included as possible. As many of the low priority requirements should be accommodated as time and resources permit, which usually isn’t very many.

Beware of false requirements
If you could ask your customers what their requirements were and have them respond with everything they needed, the analysis phase would be a piece of cake. However, that is rarely the case. A number of challenges must be overcome:

  • No single customer normally knows all of the requirements up front. You should do a proper follow-up with a number of customers and stakeholders to make sure that you have as complete a picture as possible as to what is needed.
  • Different customers have different visions of what the business needs are. This requires consensus building so that you can reconcile differing and conflicting requirements.
  • Requirements are vague. This requires good follow-up and probing skills to obtain the correct level of detail.
  • Many statements are not requirements. Be careful to recognize when you are receiving a valid business requirement and when you are getting statements of scope, risk, approach, or simply opinion. When customers tell you they think the project should have all the funding it needs, they are giving you an opinion, not a business requirement.

Points to remember
As you begin the task of extracting business requirements as a part of your analysis work, keep these issues in mind:

  • Business requirements are statements that describe the needs of the customer and major stakeholders.
  • Gathering business requirements is the most important aspect of the analysis phase.
  • After the requirements are gathered, they should be prioritized and then formally approved by the customer and sponsor.
  • Customers and stakeholders may give you a lot of information during the requirements-gathering process. Much of what they tell you won’t be real requirements. This information must be filtered, followed up on, and reconciled with any conflicting statements.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching project management and life-cycle skills for the IS division. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep. He holds a bachelor’s degree in computer science from Iowa State University.