Section 11.6. Requirements for the Budget Application


11.6. Requirements for the Budget Application

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]

[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.

11.6.1. Monday Morning, 10 A.M.

Bob gets called in to the office of his manager, Ellen. The conversation goes something like this:

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.

Bob: We've used a spreadsheet these past few years to do our budgets. You want us to develop another spreadsheet application?

Ellen: No, I want a whole new application.

Bob: You want us to reinvent the spreadsheet?

Ellen: No, I want something simpler and more specific to the budgeting process.

Bob: Tell me more. What are the key features that you see in this application?

Ellen: Well, first of all it needs to be able to work concurrently with all the users. With our spreadsheet, we'd have to take turns with the data entry or we'd risk loosing each other's changes.

Bob: It may just be that we're not using our spreadsheet's advanced features. Shouldn't we investigate that first?

Ellen: No, I'd rather have us invest our time in building the tool we know that we need. At the end of the day your investigation may only show that we still need the tool, and by then it might be too late to build it.

Bob: I hear you saying that the deadline is rapidly approaching.

Ellen: YesI want to be able to use it for the budget planning at the end of this quarter. How long do you think it will take you to build it?

Bob: Build what?

Ellen: Haven't you been listening? The budget tool!

Bob: I know that you mean the budget toolbut you haven't really given me enough requirements upon which to base an estimate. Tell me more about how you envision this tool being used.

Ellen: Well, in the past we've taken last year's numbers and just bumped them up by a few percent. Then we look at each category and tweak them. I want a different approach this year. I'm going to take our department's budget, give it a bump, then assign a chunk to each of my reports. I want you to take those discretionary dollars and spell out how you would spend them.

Bob: Shouldn't we be providing you with estimates of what we need for the coming year, rather than you telling us what we have to spend?

Ellen: In theory, perhaps so. But in practice we can only grow the budget by so much. I'd rather skip the charade and jump right to allocating the dollars we will likely be able to spend. Then as the year progresses, I'd like to use this tool to track our spending against this plan.

Bob: But isn't that why we have that big SAP application?

Ellen: Have you ever tried to use it?! Please! The CFO thought it looked greatand on paper it did. But that user interface makes it almost impossible to be productive. And it's as slow as molasses.[3]

[3] Remember, this is a fictional account. We are providing justification for why they can't use the corporate application. Anyone's use of such a tool can be less than optimal, reflecting more on themselves than on the value and usability of the tool.

Bob: But back to this new application ... I'm assuming you'll want a GUI on this?

Ellen: Of course. Give it a standard, simple GUI. Something like this. (She begins to draw on her whiteboard.)

For any given department there will be a "pool" of money. Those dollars are displayed and can be subdivided into smaller pools of money by creating subaccounts.

But as the money is subdivided those new accounts and associated dollars should become visible by others. And as dollars are spent during the year, we'll want to track those dollars, so those amounts should be visible, too, and subtracted from the overall pool of available dollars.

Bob: Wait ... back up. What needs to be entered to subdivide an account?

Ellen: The user just picks an account, then chooses to subdivide it, entering the amount to put in each account ... or even just a percent of the larger pot of money.

Bob: So if he picks one account to subdivide, does it split into two, or three or how many?

Ellen: Let the user choose, but maybe two as a default.

Bob: OK, but we may need to take a harder look at that interaction.

Ellen: So how long will that take? Can you have it ready by the end of this month?

Bob: I'd like to try the "spiral" approach on this project. I can have something for you by the end of this weekfrom which you can tell me if I'm heading in the right direction. It will just be a beginning, but you'll be able to see something run. By the way, is this tool only for our group?

Ellen: For now it is, but I could see other departments wanting to use it some day. Who knows how far it could go?

11.6.2. Back at His Desk

Bob is now back at his desk pondering the conversation he had with Ellen. "These are not like the requirements we learned about in my software engineering courses," he muses. "I've got that sketch of the UI and a brief description of its functionality. But there seem to be so many unanswered questions."

So what is Bob supposed to do? He could go back and try to get more "face time" with Ellen, and ask lots more questions. Sometimes that's a smart thing to do. Other times such repetition is seen as annoying and a sign of a slow-witted analyst, never mind how obscure the initial discussions were or how many times someone changed their mind about what they want. You will have to judge each situation as you encounter it. At some point, though, you have to deal with whatever information you've been given, and try to make the best of it.

So where do you turn? The next best things to do are to begin to document the requirements as you understand them, to prototype a solution, and to start getting buy-in from other stakeholders. Each of these activities may help bring out more requirements, but that's not a bad side effect.



    Java Application Development with Linux
    Java Application Development on Linux
    ISBN: 013143697X
    EAN: 2147483647
    Year: 2004
    Pages: 292

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net