Ways to Gather Requirements

1. Ways to Gather Requirements Trisha Cummings

2. Five Techniques • Interviews • Joint Application Development • Questionnaires • Document Analysis • Observation

3. Interview Tips • Prepare to interview users by reading background documentation first. • To reduce conflicts, identify user groups and ask the client to select official user representatives/subject matter experts who are authorized to speak for all the users they represent and who have current, working knowledge of the area to be discussed. • Make a written list of questions to help you interview. • Provide them in advance so the interviewees can prepare. • Information needed depends on the system,

4. information to find out from users might include: • What are the user types, their required skills? • What work do they do; what do they authorize? • What problems and irritations they have doing the work? • What are the work cycles and timing; how often something is done and how long it takes; what is the criticality of its timing? • What is the sequence of work steps or processing? (In addition to ensuring the system performs the work correctly, this information can affect project planning if the system will be made operational in stages.)

5. What is the work product at the conclusion of each step? (In addition to tangible items, decisions, approvals, completed reviews, and other intellectual outputs are also work products.) • Where is the work is performed? • What organizational goals and objectives, legal requirements, or other needs does the work support? • How the work is performed (don't assume it is done the same way you know from another organization)?

6. What information is required to do the work; what are the sources? • What parts of the work tend to change and how often they change? • What the outcomes of the work are (decisions, reports, items, etc.) • Is there any information that was missed by your questions?

7. Watch for areas in the business process that use subjective decision-making. • You will need to work with users or their management to clarify policy if this activity will be automated. • Delays in agreement on the policy often occur and can stall your effort. • Users may present a requirement as a solution. • Find out why they want this solution by asking "what" that solution provides or does. • Asking "why" makes it sound as if their request must be justified to you.

8. Users resent being told the information they are providing is not needed. • If the information is relevant to the topic, but too detailed for the current discussion, ask if you can return for that information later. • Be sure to put in your notes that additional detail is available and from whom so you can come back for it without having to ask who has it. • Requesting the same information over and over indicates incompetence. • Users will complain to their management about this because it keeps them from doing their real work, and it will come back to you. • Establish and index a library of documents that have been provided. • Put meeting notes and minutes in the library. Ideally this will be an electronic repository so it can be used by the entire team. • Do not go to users for information until you have checked the repository. • Keep track of hardcopy documents, also.

9. If possible, assign one analyst to take notes while another interviews. • Keep track of issues and unresolved items during the meeting, get concurrence on notes taken during the meeting before the meeting ends. • Reserve time to read notes back. It works better than distributing notes for comment after the meeting. • People forget or try to insert agendas when no one else is there to object. • You will also clear up misunderstandings while the subject is still fresh in everyone's mind. • Assign/get volunteers to resolve issues. Obtain user prioritization of the requirements. • Provide everyone with written notes from the meeting within a couple of days after the meeting. • Remember, it isn't the users' job to tell you what kind of technology they need. • If you want to know what kind of technical capabilities they might like, be prepared to give them examples.

10. Try to see the work performed. • Get copies of forms, outputs, and information used in the work, including help sheets and notes posted by the users at their desks. • Identify all parties who will use the requirements (for example, testers, designers, architects). • All of them, along with the users/subject matter experts, are responsible for reviewing the requirements and approving them. • The formal review and sign-off may require additional revisions before the requirements can be baselined. • Resolve requirements conflicts by prioritization, additional clarification of the requirements, and negotiations with affected parties. • During negotiations, have everyone explain their roles to the other parties so all gain perspective on the effects of the requirement. • More than one meeting may be required.

11. In establishing responsiblities for the various reviewers, remember that approval of the requirements for baselining is not necessarily approval for implementation. Determining if a requirement should be scheduled for implemention is based on priority, cost, and other considerations. The decision is usually made by a project sponsor or project manager.

12. Joint Application Development • A popular fact-finding technique that brings users into the development process as active participants. • The JAD process is based on four simple ideas: • People who actually do a job have the best understanding of that job. • People who are trained in information technology have the best understanding of the possibilities of that technology. • Information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and affect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community. • The best information systems are designed when all of these groups work together on a project as equal partners.

13. Key participants • Executive Sponsor: The executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions and provide the necessary resources and support for the project. They might attend the opening and closing session. • Project Leader/Manager: Generally the leader of the application development team answers questions about the project regarding scope, time, coordination issues and resources. They may contribute to the sessions as long as they do not inhibit the participants.

14. Facilitator/Session Leader: Chairs the meeting and directs traffic by keeping the group on the meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the meeting and those which need to be assigned at the end of the meeting for follow-up investigation and resolution. The facilitator serves the participants and does not contribute information to the meeting. • Scribe/Modeller/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and does not contribute information to the meeting. • Participants: Customers in the business area directly or indirectly being affected by this project, who are experts in their field and can make decisions about their work. They are the source of the input to the session. • Observers: Generally members of the application development team assigned to the project. They are to sit behind the participants and are to silently observe the proceedings.3,6,7,8,

15. 9 Key Steps • Identify project objectives and limitations It is vital to have clear objectives for the workshop and for the project as a whole. The pre-workshop activities, the planning and scoping, set the expectations of the workshop sponsors and participants. Scoping identifies the business functions that are within the scope of the project. It also tries to assess both the project design and implementation complexity. The political sensitivity of the project should be assessed. Has this been tried in the past? How many false starts were there? How many implementation failures were there? Sizing is important. For best results, systems projects should be sized so that a complete design - right down to screens and menus - can be designed in 8 to 10 workshop days. • Identify critical success factors It is important to identify the critical success factors for both the development project and the business function being studied. How will we know that the planned changes have been effective? How will success be measured? Planning for outcomes assessment helps us judge the effectiveness and the quality of the implemented system over its entire operational life.

16. Define project deliverables In general, the deliverables from a workshop are documentation and a design. It is important to define the form and level of detail of the workshop documentation. What types of diagrams will be provided? What type or form of narrative will be supplied? It is a good idea to start using a CASE tool for diagramming support right from the start. Most of the available tools have well to great diagramming capabilities but their narrative support is generally weak. The narrative is best produced with your standard word processing software. • Define the schedule of workshop activities Workshops vary in length from one to five days. The initial workshop for a project should not be less than three days. It takes the participants most of the first day to get comfortable with their roles, with each other, and with the environment. The second day is spent learning to understand each other and developing a common language with which to communicate issues and concerns. By the third day, everyone is working together on the problem and real productivity is achieved. After the initial workshop, the team-building has been done. Shorter workshops can be scheduled for subsequent phases of the project, for instance, to verify a prototype. However, it will take the participants from one to three hours to re-establish the team psychology of the initial workshop.

17. Select the participants These are the business users, the IS professionals, and the outside experts that will be needed for a successful workshop. • Prepare the workshop material Before the workshop, the project manager and the facilitator perform an analysis and build a preliminary design or straw man to focus the workshop. The workshop material consists of documentation, worksheets, diagrams, and even props that will help the participants understand the business function under investigation.

18. Organize workshop activities and exercises The facilitator must design workshop exercises and activities to provide interim deliverables that build towards the final output of the workshop. The pre-workshop activities help design those workshop exercises. For example, for a Business Area Analysis, what's in it? A decomposition diagram? A high-level entity-relationship diagram? A normalized data model? A state transition diagram? A dependency diagram? All of the above? None of the above? It is important to define the level of technical diagramming that is appropriate to the environment. The most important thing about a diagram is that it must be understood by the users. Once the diagram choice is made, the facilitator designs exercises into the workshop agenda to get the group to develop those diagrams. A workshop combines exercises that are serially oriented to build on one another, and parallel exercises, with each sub-team working on a piece of the problem or working on the same thing for a different functional area. High-intensity exercises led by the facilitator energize the group and direct it towards a specific goal. Low-intensity exercises allow for detailed discussions before decisions. The discussions can involve the total group or teams can work out the issues and present a limited number of suggestions for the whole group to consider. To integrate the participants, the facilitator can match people with similar expertise from different departments. To help participants learn from each other, he can mix the expertise. It's up to the facilitator to mix and match the sub-team members to accomplish the organizational, cultural, and political objectives of the workshop. A workshop operates on both the technical level and the political level. It is the facilitator's job to build consensus and communications, to force issues out early in the process. There is no need to worry about the technical implementation of a system if the underlying business issues cannot be resolved.

19. Prepare, inform, educate the workshop participants All of the participants in the workshop must be made aware of the objectives and limitations of the project and the expected deliverables of the workshop. Briefing of participants should take place 1 to 5 days before the workshop. This briefing may be teleconferenced if participants are widely dispersed. The briefing document might be called the Familiarization Guide, Briefing Guide, Project Scope Definition, or the Management Definition Guide - or anything else that seems appropriate. It is a document of eight to twelve pages, and it provides a clear definition of the scope of the project for the participants. The briefing itself lasts two to four hours. It provides the psychological preparation everyone needs to move forward into the workshop. • Coordinate workshop logistics Workshops should be held off-site to avoid interruptions. Projectors, screens, PCS, tables, markers, masking tape, Post-It notes, and lots of other props should be prepared. What specific facilities and props are needed is up to the facilitator. They can vary from simple flip charts to electronic white boards. In any case, the layout of the room must promote the communication and interaction of the participants.2

20. Questionnaires • Objectives in designing questionnaires • There are two main objectives in designing a questionnaire: • To maximize the proportion of subjects answering our questionnaire - that is, the response rate. • To obtain accurate relevant information for our survey.

21. To maximize our response rate, we have to consider carefully how we administer the questionnaire, establish rapport, explain the purpose of the survey, and remind those who have not responded. • The length of the questionnaire should be appropriate. • In order to obtain accurate relevant information, we have to give some thought to what questions we ask, how we ask them, the order we ask them in, and the general layout of the questionnaire.

22. Deciding what to ask • There are three potential types of information: • Information we are primarily interested in-that is, dependent variables. • Information which might explain the dependent variables-that is, independent variables. • Other factors related to both dependent and independent factors which may distort the results and have to be adjusted for - that is, confounding variables.

23. Advantages of open or closed format • Open format • Allows exploration of the range of possible themes arising from an issue • Can be used even if a comprehensive range of alternative choices cannot be compiled • Closed-that is, forced choice-format • Easy and quick to fill in • Minimize discrimination against the less literate (in self administered questionnaire) or the less articulate (in interview questionnaire) • Easy to code, record, and analyze results quantitatively • Easy to report results

24. Wording of individual questions The way questions are phrased is important and there are some general rules for constructing good questions in a questionnaire. Use short and simple sentences Short, simple sentences are generally less confusing and ambiguous than long, complex ones. As a rule of thumb, most sentences should contain one or two clauses. Sentences with more than three clauses should be rephrased.

25. Ask for only one piece of information at a time For example, "Please rate the lecture in terms of its content and presentation" asks for two pieces of information at the same time. It should be divided into two parts: "Please rate the lecture in terms of (a) its content, (b) its presentation." Avoid negatives if possible Negatives should be used only sparingly. For example, instead of asking students whether they agree with the statement, "Small group teaching should not be abolished," the statement should be rephrased as, "Small group teaching should continue." Double negatives should always be avoided. Ask precise questions Questions may be ambiguous because a word or term may have a different meaning. For example, if we ask students to rate their interest in "medicine," this term might mean "general medicine" (as opposed to general surgery) to some, but inclusive of all clinical specialties (as opposed to professions outside medicine) to others.

26. Another source of ambiguity is a failure to specify a frame of reference. Ensure those you ask have the necessary knowledge Sensitive issues It is often difficult to obtain truthful answers to sensitive questions. Minimize bias People tend to answer questions in a way they perceive to be socially desired or expected by the questioner and they often look for clues in the questions. Many apparently neutral questions can potentially lead to bias.

27. Level of details • It is important to ask for the exact level of details required. • On the one hand, you might not be able to fulfill the purposes of the survey if you omit to ask essential details. • On the other hand, it is important to avoid unnecessary details. • People are less inclined to complete long questionnaires. • This is particularly important for confidential sensitive information, such as personal financial matters or marital relationship issues.

28. evaluation of questionnaires • Questionnaires must be pretested - on a small sample of people characteristic of those in the survey. • This gives an idea of the questions that may need to be rephrased • Deletions • Additions

29. Document Analysis • Look at all the current documents • Are workers using any self created documentation • Are there old we aren’t using them documents? • These are good in helping you avoid things that they already found useless • Or by asking why aren’t you using them you can maybe see how to integrate what they needed into the current model.

30. Observations • Sit and watch • Show you what’s happening • Versus what’s suppose to happen • Do not disturb people • Jot down questions for later • Remember watched people are watching their p’s and q’s

31. Concluding • You need to pick the right technique • Some things to consider when choosing a technique • You need to know the type of information • How detailed your information is • The range covered by the information • Is the information integrated among various sources • How involved is your user • What is the cost

32. Resources • INTERVIEWING USERS—TIPS http://www.jiludwig.com/Interviews.html • Wikipedia - Joint application design http://en.wikipedia.org/wiki/Joint_application_design • How to design a questionnaire http://student.bmj.com/back_issues/0601/education/187.html