ITEC 3010 “Systems Analysis and Design, I” LECTURE 4: Investigating System Requirements

1. ITEC 3010 “Systems Analysis and Design, I” LECTURE 4: Investigating System Requirements [Prof. Peter Khaiter]

2. Lecture Outline • The Analysis Phase • System Requirements • Models and Modeling • Stakeholders • Information Gathering • Prototypes • Joint Application Design Sessions • Structured Walkthrough

3. The Analysis Phase in More Detail • Gather information (from people who will be using the system) • by interviewing them • by observing their work • by reviewing documents and policy statements (e.g. at a bank) • Define system requirements • Functional and nonfunctional • Prioritize requirements • Prototype for feasibility and discovery • Generate and evaluate alternatives • Review recommendations with management

4. The Activities of the Analysis Phase

5. The Analysis Phase Gather Information • System analyst needs to become an expert in the business area the system will support or should even actually do some or part of the task to get a feel for what is done (e.g., in order to automate order-entry, may need to know how orders are processed) • Gathered information involves: • Understanding the existing system • Identifying all current and future users, locations, system interfaces (inside and outside the organization) • Identifying possible software package solutions that might be used

6. The Analysis Phase Prioritize Requirements • Establish which functional and technical requirements are most critical • Why? Since resources are always limited and you want to address the most important things • Unless evaluation priorities, system requirements tend to expand as users make more suggestions (called “scope creep”) Prototype for Feasibility and Discovery • If system involves new technology, the team may need to get experience working with it. Creating prototypes can be very valuable • Prototyping helps to understand possibilities and limitations of the technology • Good idea for projects where requirements are hard to define beforehand • By showing prototypes to end users can get feedback into what is really needed • Prototypes help users (and analysts) to discover requirements they might not thought about otherwise, i.e. think creatively

7. The Analysis Phase Generate and Evaluate Alternatives • Could include considering more than one method to develop system • Could involve in-house development or outsourcing to a consulting firm • Might be able to use “off the shelf” software package • Each alternative has costs and benefits to be considered • Also must consider technical feasibility Review Recommendations with Management • Usually done when all the above are completed • Must decide if project should continue at all • Must decide on which alternative is best (if you are going ahead with the project) • NOTE: at this point should include CANCELLATION of the project as an option Possible reasons • May have found costs were too high • May have found benefits were lower than thought • Business environment may suddenly change making the project less important

8. Activities of the Analysis Phase and Their Key Questions‏

9. System Requirements • System requirements – specifications that define the functions of the new system • Two sets of requirements: • Functional requirements • Nonfunctional requirements‏

10. Functional requirements • Functional requirements • Activities system must perform (use cases)‏ • Based on procedures and business functions • Documented in analysis models • E.g.: “reduce fuel costs by calculating where is it best to fuel up”

11. Nonfunctional requirements • Nonfunctional requirements • Technical requirement – hardware and software • Performance requirement – workload measures • Usability requirement – user interface, workflow • Reliability requirement – outages, error detection • Security requirement – access & protection • E.g.: “the new system must be run in a client-server environment with Windows NT”, “must have one second response time”

12. Models and Modeling • Requirements are describes by a collection of models • Complex systems require more than one type of model • Models represent some aspect of the system being built • Process of creating models helps analyst clarify and refine design • Models assist communication with system users

13. Reasons for Modeling

14. Types of Models • Different types of models are used in information systems development • Mathematical– formulas that describe technical aspects of the system (e.g., processing rules) • Descriptive– narrative memos, reports, or lists that describe aspects of the system • Graphical– diagrams and schematic representations of some aspect of the system

15. Some Descriptive Models

16. Overview of Models Used in Analysis and Design • Analysis activities named “define system requirements” • Logical models • Provide detail without regard to specific technology (perfect technology assumption) • Design models • Physical models • Provide technical details (non-perfect technology assumption) • Extend logical models

17. Models Created During Analysis

18. Stakeholders—The Source of System Requirements • People with interest in successful system implementation • Three primary groups of stakeholders • Users (use system)‏ • Clients (pay for and own system)‏ • Technical staff (ensure system operation)‏ • Every type of stakeholder is identified by analyst - one of the most important first steps in determining systems requirements • The second task is to identify the critical person from each stakeholder type to be available as the business expert.

19. Stakeholders Interested in New System Development

20. Users as Stakeholders • Horizontal users (i.e., across departments) • Vertical users or hierarchy within a department (i.e., clerical staff, middle management, and senior executives) • Business users – perform day-to-day operations (transactions): provide information about daily operations and how system supports them • Information users - who need current information • Management users – who need summary information • Executive users – who need strategic information • External users may have access to system (e.g., via Internet)

21. Clients and Technical Staff as Stakeholders Client Stakeholders • They pay for the project so they are important! • Project team must provide project status reviews to the clients Technical Stakeholders • The technical staff includes people who establish and maintain the computing environment of the organization • They are source of many technical requirements – provide guidance in such areas as programming language, computer platform, equipment, etc.

22. RMO Stakeholders

23. Techniques for Information Gathering • Analysis phase done to understand business functions and develop system requirements • Original structured approach • Create physical and logical models of existing system • Derive requirements from existing system model • Create physical and logical models of new system • Current approach • Identify logical requirements for new system • Balance the review of current business functions with new system requirements

24. Traditional Approach to Identifying System Requirements

25. Current Approach to Identifying System Requirements

26. The transition from information gathering to model building

27. Methods of Information Gathering • Distribute questionnaires to stakeholders • Review existing reports, forms, and procedure descriptions • Interview and discuss processes with users • Observe and document business processes • Build prototypes • Conduct joint application design (JAD) sessions • Research vendor solutions

28. Just For Fun

29. Question Topics • What kind of information are we looking for during information gathering? • We need to obtain information that will enable us to build the logical model of the new IS • What Are the Business Processes? – i.e. understanding of business functions, building a comprehensive list of all the business process (focus on the current system). • How is the Business Processes Performed? – i.e., focus on how the new system should support the functions (visualize new and more efficient approaches to performing the business processes by new system) • What Information is required? – i.e., elaboration of the second information in terms of defining specific information that the new system must provide.

30. Themes for information-gathering questions

31. Review Existing Reports, Forms, and Procedure Descriptions Serves two purposes: • Provides a preliminary understanding of processes involved in a company • Can be useful in conjunction with interviews • Can be used to develop interview questions • Can be used in interviews themselves (as visual aids and as working documents for discussion • Helps to identify business rules that may not come up in the interview • Helps to discover discrepancies and redundancies • Can be extended to looking at other types of documents like emails, memos, etc

32. Sample Order Form for RMO‏

33. Conduct Interviews and Discussions with Users • One of the most effective ways to understand business functions and rules • Can be time consuming and resource expensive • Team members meet with individuals or groups of users • May require multiple sessions to • Meet all users • Understand all processing requirements • List of detailed questions prepared • Can involve new approaches (critical incident method and cognitive task analysis – not mentioned in text) • To be effective should be organized in three areas: (1) preparing for the interview (2) conducting the interview (3) following up the interview

34. Sample Checklist to Prepare for User Interviews

35. Preparing for the Interview • Must establish objective – what do you want to get out of it? • Determine users • Could interview users with different levels of experience, computer expertise, bank expertise… • Good to have at least two project team members at the interview • Can compare notes in order to ensure accuracy • Prepare detailed questions • Good to structure the questions • Can include both open-ended (e.g. “how do you do this function?”) and closed-ended questions (“how many times a day do you do this?”) • Last step in preparing: make the interview arrangements (where to meet and when – good to pick a quiet room). Each participant should know the objective of the meeting, have a chance to preview the questions or materials to be reviewed

36. Conducting the Interview (1 of 2) • See text for variety of tips: like dress well, be polite and arrive on time! • Limit the time of the interview (plan for about an our and a half) • If it is required more time to cover all questions, schedule another session. • It is better to have several shorter interviews than one long “marathon” • Look for errors or exception conditions – e.g. get them to describe when things go wrong (“What if it doesn’t arrive?”, “What if the balance is incorrect?”) • In critical incident method can ask to describe an easy case, as well as a “scenario from hell” • “What ifs” can be explored as well as probing about real incidents • The ability to think of the exceptions is very important; it couldn’t be learned from a textbook, but only from experience

37. Conducting the Interview (2 of 2) • Probe for details • In addition to looking for exception conditions, the analyst must probe to get a complete understanding of procedures and rules • It is easier to get general overview than details on how it works and what information is used • Take careful notes (it provides the basis for the next interview) • Try to follow some logical agenda during the interview (it helps to prod your memory on issues and items that should be discussed in an interview).

38. Sample Agenda for Interview

39. Following Up the Interview • The first task is to absorb, understand and document the information collected from the interview • Can write it up as text and also document by constructing diagrammatic models of business processes • Review results with others who attended the interviews (within a day or at most two) • Make a list of questions that need further elaboration (open-items list) • Make a list of new questions based an areas that need more elaboration or that are missing information • Send a thank-you note or email to the users who participated in the interview

40. A Sample Open-Items List

41. Observe and document business processes (1 of 2) • Varies from office walkthroughs to performing actual tasks • Not necessary to observe all processes at same level of detail • May make users nervous, so use common sense • Can document workflows with UML activity diagrams

42. Observe and document business processes (2 of 2) • Early in the investigation activities, time should be scheduled to observe the business procedures in the organization that the new system will support • Excellent way to learn • how people do their jobs • what problems they may have • how to improve any systems they are using • Can consist of • Quick walkthrough of the office or plant • Scheduling several hours to observe a user doing a real task (“day in the life”) • Doing the task yourself to see what is involved

43. Documenting • A workflow (sequence of processing steps that completely handles one business transaction) is an effective way to capture information • Activity diagram is a type of workflow diagram that describes the user activities and their sequential flow • Synchronization bar – symbol to control splitting or merging of a path on an activity diagram • Swimlane – bounded area that contains activities of a single agent Sample • It represents a customer requesting a quote from a salesperson • If it is a simple request, the salesperson can enter the data and create the quote • If it is a complex request, the salesperson requests assistance from a technical expert to generate the quote • In both cases, the computer system calculates the details of the quote

44. Activity Diagram Symbols

45. Activity Diagramthat Models a Workflow

46. Activity Diagram with Concurrent Paths

47. Building Prototypes • Prototype is an initial working model of a larger, more complex system • Used for many purposes: • To test feasibility • To help identify processing requirements • To compare different design and interface alternatives • Different names to describe different uses • Throwaway prototypes • Discovery prototypes – used in the analysis phase for a single discovery objective and then discarded once the concept has been tested • Design prototypes – used in the design phase to test various design alternatives • Evolving prototypes – prototypes that grow and evolve and may be used as the final, live system

48. Prototypes • Characteristics of Prototypes: • Operative: a prototype should be a working model, with some real functionality (if not working, but just shows what it looks like, its called a mock-up) • Focused: a prototype should be focused on a single objective (to test a specific concept or verify an approach) • Quick: the prototype should be built and modified quickly (so can validate an approach, and if it is wrong, fix it fast in an iterative process) • Built and modified rapidly with CASE tools

49. Distribute and Collect Questionnaires • Have a limited and specific use • Allow to collect information from a large number of stakeholders • Can be used to get a preliminary insight on the information needs of the various stakeholders • Not well suited for gathering detailed information • Three groups of questions: • Quantitative (e.g., “How many customers a day?”) • Closed-ended (express opinion on a predetermined scale: ““On a scale of 1 to 10 rate system performance” ) - direct respondent, simple and short answer is assumed; easy to tabulate and process • Open-ended - encourage discussion and elaboration, no predetermined answer

50. quantitative Sample RMO Questionnaire Closed-ended open-ended