< Zurück | Inhalt | Weiter >

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 engineer- ing 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 docu- ment 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.


11.7 DOCUMENTING, PROTOTYPING, AND STAKEHOLDER BUY-IN


Once a project is started, the design must be documented. A prototype may be built to validate and refine the design. Finally, everyone with a stake in the success of the design has to be brought up to speed and needs to agree on what is to be built.