Java Reference
In-Depth Information
• Who is going to use the data that comes from the use of the software (i.e.,
who will read the reports generated from the data collected either directly
or indirectly from the running of the software)?
• Who is going to support the software and who will support the machines
on which it will run?
All these people can be considered “stakeholders” in the project.
So where do you start? That's a political more than a technical question.
Start with your boss and with whoever is the major backer of the project. Then
ask your customers. For in-house IT projects, the “customers” are usually very
accessible; for software products, the customer's point of view may need to be
represented by marketing and/or customer support people who have had direct
contact with the customer base.
11.6
R
EQUIREMENTS FOR THE
B
UDGET
A
PPLICATION
Let's take a look at how such requirements might evolve. We'll look at the
situation through the eyes of a fictional IT guy named Bob.
2
11.6.1
Bob gets called in to the office of his manager, Ellen. The conversation goes
something like this:
Monday Morning, 10
A
.
M
.
Bob:
Yes, Ellen, you wanted to see me?
Ellen:
Come in, Bob. Yes. We're just about to enter another budget
planning cycle. We've got to propose our next year's budget to the VP by the
end of the quarter, and I got to thinking . . .
Bob:
Uh-oh.
Ellen:
. . . on my way to work today, I got to thinking that we ought to
be able to develop a software tool that would help us do a better job of this
process.
2. We're avoiding giving Bob a title because titles vary so much within our industry. Call
someone an analyst and it may mean that they never code. Call someone a programmer and it
may mean that they only code and never deal with requirements or even designs. Some use
those terms interchangeably. We'll just call him an IT guy.
