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
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?
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?
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.
That’s hard to get right.
How would you make the rep’s job easier? Anyone got ideas?
But the new system doesn’t exist.
Maybe a time machine would help?
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?
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.