Case in Point

One marketing SME wrote a description of a data query that she needed: “Select all of the people in the database who live in the United States and have attended a class.” This sounded simple enough, but after many iterations of this query, the actual requirements were more like:

• Include people with a valid mailing address (meaning there was data in the street address, city, state, and zip code fields)

• Exclude people with a country code other than United States

• Exclude people who had requested no mail (do not mail indicator is on)

• Include people who had attended a class in the last three years

• Exclude people who had registered for a class and then canceled their registration

• Include people who are currently registered for a class in the upcoming six months

• List each person’s preferred address (there were two mailing addresses for each contact, a primary and alternate)

When I told the SME that this query was very different than what was originally requested, she did not agree: “Of course it should only include valid mailing addresses. Who would select invalid ones?” In her mind, there were several “requirements” that were so obvious that they did not need to be written down. She did not understand how queries are written—specifying every necessary field requirement. The most important lesson that we learned from this exercise was that when this SME requested a query, we had to ask many questions about her assumptions before we even guessed about whether or not we could create it!

Developer Preferences

Developers are stakeholders also. You need to think about how best to communicate with developers as much as you think about communicating with the business people. Understanding how developers think is similar to understanding how accountants or marketers think. You need to learn about their job and get an understanding of what they do and how they do it. The better you understand the work of developers, the better you will be able to communicate with them. Developers usually prefer short, concise, visual requirements (see the section on communicating with developers in Chapter 5).

Project Manager Preferences

Project managers (PMs) are focused on developing a plan to get the project done and then sticking to the plan as closely as possible. The PM wants you to understand the business area just enough to be successful. No more and no less. He or she wants you to present requirements to stakeholders in a format that will allow for quick and painless approvals and quick and efficient development. Usually, the PM doesn’t have a stake in what types of diagrams or models you use. The most important thing that you can do for the PM is to estimate how long you will need to accomplish your work on the project. The best way for you to develop this estimate is to think through all of your work and develop a detailed plan. This includes a requirements communication plan and list of requirements deliverables (see the section on business analysis planning in Chapter 7).