Requirements

Woof! The first thing is to figure out the goals of the IS you’re building. That’s requirements analysis.

There are two steps:

  • Identify the stakeholders
  • Figure out what each stakeholder wants from the IS

Who are the stakeholders?

Stakeholders are people affected by the IS. Here are stakeholders for the Adopt-a-Dog Web site project:

  • People who want to adopt a dog
  • People with a dog that needs to be adopted
  • People looking for training, or veterinary services
  • People who want to donate money
  • Potential volunteers
  • Current volunteers
  • Adopt-a-Dog management
Exercise: Stakeholders for Crack Plumbing’s Web site
Plumbing Crack Plumbing is a plumbing company in Yourtown. They install and repair faucets, water heaters, toilets, sinks, tubs and showers, garbage disposals, and so on. They do residential work mainly.

Crack Plumbing has been in business for almost 40 years. Apart from the owner, Jim Crack, there’s an office assistant, six licensed plumbers, and three apprentices. Jim’s looking to expand, and wants to hire two more plumbers.

You’ve been hired to make a Web site for Crack Plumbing. Who are the stakeholders?

(If you were logged in as a student, you could submit an exercise solution, and get some feedback.)

What do stakeholders want?

We asked the stakeholders what they wanted from the IS. Here’s what they said.

People who want to adopt a dog

  • What dogs are available?
  • Can I visit the dogs?
  • What does it cost to adopt a dog?
  • Will I be allowed to adopt a dog?

People with a dog that needs to be adopted

  • Can I leave my dog with Adopt-a-Dog?
  • Will Adopt-a-Dog look after my dog?
  • Will my dog have a good home?
Exercise: What do Crack’s customers want?
Plumbing Earlier, you learned about Crack Plumbing. You’re building a Web site for them. One of the stakeholders are the customers. What do they want from the Web site?

(If you were logged in as a student, you could submit an exercise solution, and get some feedback.)

People looking for training, or veterinary services

  • What services are available?
  • What do they cost?
  • When and where can I get services?

People who want to donate money

  • How will my money be used?
  • How do I donate?
  • Are donations tax deductible?

Potential volunteers

  • What jobs are available?
  • What hours would I work?
  • Is there training?

Current volunteers

  • When am I scheduled to work?

Adopt-a-Dog management

  • How is content on the site updated?
  • How much time will it take to keep the site updated?
  • Where will the site be hosted?
  • What will hosting cost?
Exercise: What does the business owner want?
Plumbing Earlier, you learned about Crack Plumbing. You’re building a Web site for them. One of the stakeholders is Jim Crack, the owner of the company. What would he want from the Web site?

(If you were logged in as a student, you could submit an exercise solution, and get some feedback.)

Scope

Scope is the size of the IS. The more requirements an IS meets, the larger its scope, the longer it will take to make, and the more it will cost.

You might decide that some of the requirements will cost too much, in money and time. For example, current volunteers want to know “When am I scheduled to work?” Maintaining schedules on the site for all 20 workers would take time. Maybe the volunteer coordinator doesn’t want the job. There’s also the question of privacy. Do volunteers want their schedules posted for all the world to see? If not, then how would the site restrict who can see the schedule? Possibly with accounts, with user names and passwords. Who sets up the accounts? ARGH!

Let’s not do that one right now. It’s too hard.

Another one is “What dogs are available?” Dogs come and go, so someone would have to update that information. Placing dogs is the primary goal of Adopt-a-Dog, so there’s much value in having that information available. Let’s do that one.

Beware of scope creep!

A project starts out small. “Let’s add this,” someone says. “Hey, it would be cool to do this thing,” says another.

Soon, your project takes twice as long as you thought it would.

Requirements analysis is hard

IS projects sometimes fail. Billing systems, Web sites, shopping cart systems… late, over budget, and – worst of all – they don’t do what the business needs. Why does this happen?

Poor requirements analysis is often the cause. Because it’s hard.

Adela
Adela
Wait, what? How do you find out what people want? Don’t you just ask them?
Ruben
Ruben
Right! That’s what you do. But people often don’t know what they want.
Adela
Adela
OK, now you’ve lost me.
Ruben
Ruben
Say you ask a sales rep what she wants from a customer tracking system. The rep has never had a customer tracking system before. You’re asking her to imagine what it would be like to use something that doesn’t exist!

That’s hard to get right.

How would you make the rep’s job easier? Anyone got ideas?
Marcus
Marcus
Well, the rep would have to use the new system to figure out what she wanted from it.

But the new system doesn’t exist.

Maybe a time machine would help?
Georgina
Georgina
Hey! Maybe it’s like computer games. Before a game comes out, the game company makes… well, a mock-up. They ask people to look at it, and say whether they might like it, and what to change.

Then they make an alpha version, with some of the game features. You can get some on Steam.

Could you do something like that? Make a mock-up of the system?
Ruben
Ruben
Right! That’s what you do. You make prototypes of the system. The first prototype might be just drawings of screens and reports. You ask the rep what she thinks of it. She has something she can evaluate. You take her feedback, and make the next prototype. Maybe there’s some real software this time, but with just one or two of the most important functions. The rep gives you more feedback. Keep doing this until you and the rep are confident that you know what the system should do.
Ray
Ray
What ends up happening to the prototypes you make?
Ruben
Ruben
You throw them away, once you’ve got the requirements.
Ray
Ray
Won’t the money people say that’s wasteful?
Ruben
Ruben
Yes, some will. You reply:

What would rather do?

  • Build an entire system, and then find out that it doesn’t do what the business needs?
  • Invest a little to make sure that the project is on target?

Which is more wasteful?

When you’re not sure what the final system should be like (and you usually aren’t), invest in prototypes. It’s a good investment.

Summary

Requirements analysis is figuring out the goals of the IS. Identify the stakeholders, then figure out what each stakeholder wants from the IS.

Scope is the size of the IS. The more requirements an IS meets, the larger its scope, the longer it will take to make, and the more it will cost. Beware of scope creep!

When IS projects fail, poor requirements analysis is often the cause. People have a hard time imagining what it would be like to use a system that doesn’t exist. You can make prototypes of the system, so people have something they can evaluate.