Gathering Requirements

When designing a system, it is helpful to identify the people, organizations, or things that might interact with it. We call these things actors in the system. Note that an actor doesnt have to be a person. If a system needs to output a file in a certain format for a government agency, that agency might be considered an actor as well. Or, a board of directors may have influence over the rules of a system, in which case the entire board can be viewed as an actor. For the most part in our discussions here, however, actors will refer to people.

As you work with actors, you will certainly want to track information about them, such as their name , contact number, e-mail address, position, and so on. Position, however, does not necessarily play as vital a role as you might think in the design of a system. You might have two actors in developing a mail-routing system: the person who distributes the mail, and the president who will be paying for the system. In reality, the design of the system will be more driven by the person who actually distributes the mail than the person who pays for it. Of course, everyone gets to add their input.

Your first step is to identify who the actors in the system are and try to categorize them by their expertise of the system. For example, in our student-registration system, the registrar might be familiar with the typical daily operations of the office, but the Dean of Enrollments Management might have a more intimate knowledge of the policies that dictate enrollment or might even have knowledge of future changes.

We identify such actors as subject matter experts , or SMEs. These people, although they may not be using the system on a daily basis, have an expert knowledge of the system you are trying to automate.

You should start your interviewing with the SMEs. By doing this, you will gain a more intimate knowledge of the needs of the system and what the future needs might be for it. Also, you can identify which end users might also serve as good candidates for other interviews.

The Interview

It may seem obvious to state, but when youre performing an interview, be professional. Schedule the appointment well in advance, with several hours of time allotted. Arrive on time, and thank the person for their time in meeting with you. In your initial communication with the person, request that they have ready any sample reports or forms they currently use to do their job.

Have an agenda ready, and describe to the person the system you are going to create as well as how they fit into the system. Identify what benefits the system will have for them, and be sure to ask them what benefits they would like to see come out of it.

During the interview, ask the most important questions first, in case you run out of time. If a user begins to repeat something you have already heard , dont stop them by saying, Yeah, I got that. Instead, use it as an opportunity to enforce your understanding and also to present the image that you are on top of things. Listen more than you talk, and take detailed notes on everything.

Make sure you follow up by summarizing your meeting in a nontechnical fashion, even if its just a bulleted list, and send the person a copy of this document, thanking them again for their time.

It can also be beneficial to organize a meeting with several actors at once. Everything mentioned so far applies to a meeting with multiple actors as well, and you gain the advantage of not having to go back and forth between users to confirm he said, she said. During a meeting, to some degree you will need to play the ringleader and encourage the discussion of ideas. First, listen to all ideas presented by members of the group and assess how the group responds to those ideas. Invite input from all in attendance to either accept, decline, or build upon the ideas. Encourage input from everyone.

OOP Demystified
OOP Demystified
ISBN: 0072253630
EAN: 2147483647
Year: 2006
Pages: 130

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: