ITEC 3010 Lecture 4 Investigating System Requirements

1. ITEC 3010Lecture 4Investigating System Requirements

2. The Activities of the Analysis Phase ‏ Figure 4-3 Systems Analysis and Design in a Changing World, 5th Edition 2

3. Analysis Phase Activities • Gather Information • Involves gathering lots of information • Can get information from people who will be using the system • By interviewing them • By observing them • Can get other information by reviewing documents and policy statements (e.g. At a bank) • Can involve the analyst actually doing some or part of the task to get a feel for what is done • In order to automate order-entry you may need to become an “expert” on the task (knowing how orders are processed) • Need to understand current and future users, locations, system interfaces, possible solutions, etc.

4. Define System Requirements • Involves modelling • Logical Model • Any model that shows what the system is required to do without committing to any one technology – requirements model is logical • Physical Model • Any model that shows how the system will actually be implemented • Models are often graphical in nature • Data flow diagrams (DFDs) • Entity-relationship diagrams (ERDs) • Natural Language is ambiguous

6. Prioritize Requirements • Important to establish which functional and technical requirements are most critical • Why? Because resources are always limited and you want to address the most important things • If not addressed can lead to “scope creep”, where the scope of the project just seems to expand over time

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

8. 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 project as an option • May have found costs were too high • May have found benefits were lower than thought • Maybe the business environment suddenly changed making the project obsolete • Detailed documentation has been collected • System requirements • Proposed solution

10. Requirements Specification • Requirement specification results from Analysis phase • What is a requirement? • A feature of the system or description of something the system is capable of doing to fulfill the system’s purpose • It addresses the purpose of the system (i.e. What it is supposed to do) and not how it will be implemented (However, Non-Functional requirements might require the analyst to look closer to how it will be implemented)

11. Functional and Technical Requirements • Functional Requirements • A system requirement that describes a function or process that the system must support • E.g. “system will calculate tax amounts, report year end tax deductions” • Non-Functional Requirements / Technical Requirements • A system requirement that describes an operating environment or performance objective. Describe constraints on functional requirements • E.g. Tax amounts should be accurate, Calculate Tax amount should be easy to use • Security • Safety • Privacy

12. Summary of Types of Requirements PHYSICAL ENVIRONMENT INTERFACES USER AND HUMAN FACTORS QUALITY ASSURANCE Requirements FUNCTIONALITY SECURITY DOCUMENTATION RESOURCES DATA

13. Types of Requirements/Questions Asked • Physical Environment • Where is the equipment to function? • Is there one location or several? • Are there any environmental restrictions such as temperature, humidity or magnetic interference? • Interfaces • Is the input coming from one or more systems? • Is the output going to one or more systems? • Is there a prescribed way in which the data must be formatted? • Is there a prescribed medium that the data must use?

14. Users and Human Factors • Who will use the system? • Will there be several types of users? • What is the skill level of each type of user? • What kind of training will be required for each type of user? • How easy will it be for a user to understand the system? • How difficult will it be for a user to misuse the system?

15. Functionality • What will the system do? • When will the system do it? • How and when can the system be changed or enhanced? • Are there constraints on execution speed, response time, or throughput? (Non-Functional Req. frequently associated with FR) • Documentation • How much documentation is required? • To what audience is the documentation addressed?

16. Data • For both input and output, what should be the format of the data? • How often will it be received or sent? • How accurate must it be? • To what degree of precision must the calculations be made? • How much data flows through the system? • Must the data be retained for any period of time? • Resources • What materials, personnel or other resources are required to build, use and maintain the system? • What hardware is required? • What software is required? (e.g.. Databases?)

17. Resources (continued) • What skills must the developers have? • How much physical space will be taken up by the system? • Is there a prescribed timetable for development? • Is there a limit on the amount of money to be spent on development or on hardware and software?

18. Security • Must access to the system or to information be controlled? • How will one user’s data be isolated from other’s? • How will user programs be isolated from other programs and from the operating system? • How often will the system be backed up? • Must the backup copies be stored at a different location? • Should precautions be taken against fire or theft?

19. Quality Assurance • What are the requirements for reliability? • How the characteristics of the system must be demonstrated to others? • Must the system detect and isolate faults? • What is the prescribed mean time between failures? • Is there a maximum time allowed for restarting the system after a failure? • How can the system incorporate changes to the design? • Will maintenance merely correct errors, or will it also include improving the system? • What efficiency measures will apply to resource usage and response time? • How easy should it be to move the system from one location to another or from one type of computer to another?

20. Stakeholders – The source of system requirements • Stakeholders: People who have an interest in the success of the new system • The users: who actually use the system • The clients: who pay for and own the system • The technical staff: who ensure the system runs • Must identify stakeholders • Cannot forget an important group – e.g. users!

21. User Stakeholders • Can identify users horizontally – i.e. Across departments • Can also identify users vertically – i.e. Hierarchy within a department (e.g. lower, middle and upper managers) • Type of users • Business operations users – use the system daily to perform operations (transactions – a piece of work) • Query users – could be business people or customers – request info • Management users – want reports, performance stats, want to know volumes of transactions etc. • Executive users – want information to help with strategic issues, e.g. compare improvements in resource utilization

24. Stakeholders at Rocky Mountain Outfitters • Operational users of the new order system • Inside sales representatives (who take orders) • Clerks (who process order) • Warehouse workers • Each type of user has their own needs and preferences • Project funded from internal cash flow • Since the system involves new technology (Internet) need involvement from technical staff

25. Identifying System Requirements • Main Objective of Analysis Phase • To understand the business functions and develop system requirements • Question of studying existing systems first or not • Using structured approach, analyst first documents the existing system then extrapolates the requirements of the new system • Approach • Develop current system physical models • Extract the current system logical models • Develop new system logical model • Develop new system physical model

26. Faster approach • Identify current system procedures immediately (as much as needed, don’t necessarily define specific processes) • Develop requirements and models for new system (i.e. develop logical model) • In either approach, need to balance investigation of old procedures with need to focus on requirements of the new system

27. Questions asked (overall) • What are the current business processes and operations? • Ask the users, “What do you do ?” • Assess what current functions can remain and which should be eliminated by technology • How should the business processes be performed? • Ask the user “How can it be done?”, “What steps should be followed? (using the new system)”. How else ? • What information is needed? • Specific information requirements, e.g. Databases needed

28. Skills Needed and Methods Used • Understanding of user needs • Ability to analyze and solve business problems • Being able to identify and capture business rules • Methods • Distribute questionnaires to stakeholders • Review existing reports, forms and procedure descriptions • Conduct interviews and discussion with users • Observe business processes and workflows in real life (can video or audio record activities, do usability testing etc.) • Build prototypes • Conduct joint application design (JAD) sessions

29. Review Existing Reports, Forms and Procedure Descriptions • Review of existing documents very useful • Can help you get a preliminary understanding of processes involved in a company • Can be used in conjunction with interviews • Can be used to develop interview questions • Can be used in interviews themselves • As visual aids • Working documents for discussion • Review of forms helps to identify business rules • Helps to discover discrepancies and redundancies • Can be extended to looking at other types of documents like emails, memos etc.!

31. Conducting Interviews and Discussions with Users • Interviewing stakeholders is one of the most effective ways to understand business functions • Can be time-consuming and resource expensive • A number of members of the project team meet with individuals (or groups of users) • List of detailed questions is prepared and discussion continues until all the processing requirements are understood • May involve multiple sessions (often does) • Can involve new approaches (Protocol analysis, Ethnography etc. – ITEC 4040)

32. Prepare Carry out Follow up

33. Preparing for the Interview • Must establish objective – what do you want to get out of it? • Determining 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, but not more than three • Can compare notes • 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?”)

34. Last step in preparing: make the interview arrangements (where to meet and when – good to pick a quiet room) Conducting the Interview • Have to limit time of interview • Avoid “marathon” interviews • Look for error or exception conditions – e.g. get them to describe when things go wrong • 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

35. Probe for details • In addition to looking for exception conditions, the analyst must probe to get a complete understanding of procedures and rules • Take careful notes • Recording? • Try to follow some logical agenda during the interview • Semi-structured interviews often useful (unstructured interviews can often get out of control)

37. Following Up the Interview • Have to absorb, understand and document the information collected from the interview • Should write it up as text and also document it by constructing diagrammatic models • Review with others who attended the interviews

38. Observing Business Procedures and Workflows • Early (but not too early) in the investigation should observe the activities in the organization as they really occur • 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”) • More involved methods – e.g. Videotaping the workplace and using methods from social science to analyze

39. When observing • Should attempt to be unobtrusive, so you don’t change the users’ behaviour because you are watching them! • May require consent to do this (e.g. videotaping intensive care unit in a hospital) • May require repeated or extended observation periods to really understand what is going on • If you are observing (and not recording) then best to have more than one observer go along • As text mentions, common sense and sensitivity to needs and feelings of the users is VERY important!

40. Observing Activities: some notes • Decide what is to be observed • Decide what level of detail should be looked at (how concrete the observation should be) • Create categories that capture key activities • Prepare materials for observation (forms to fill in for note taking) • Decide when to observe and what tools you’ll take (e.g. camera, tape recorder, or just recording on paper) • Decide on approach to sampling – e.g. observe three one hour periods, or by event (e.g. board meetings) • Should be used in conjunction with other methods (e.g. interviews) • Could use forms to structure observations (see next slide)

41. Organization: Company: Solid Steel ShelvingAnalyst: Joe SmithScenario: Quality assuranceDate: 9/3/1999 Decision Maker (Actor)Observation of Information-Related Activity Quality Assurance Manager - Asks shop floor supervisor for the day’s production report. Shop floor Supervisor - Prints out the daily computerized production report. - Discusses recurring problems in production runs with quality assurance (QA) manger. Quality Assurance Manager - Reads production report. - Compares current report with other reports from the same week. - Observes on-screen results of QA model.

42. Building Prototypes • Prototype: A preliminary working model of a larger system • Uses: • To test feasibility • To help identify processing requirements • To compare different design and interface alternatives • Different names • Throwaway prototypes • Discovery prototypes – used in analysis phase • Design prototypes – used in design • Evolving prototypes • Prototypes that grow and eventually may end up becoming the final system

43. Prototypes as tools during Analysis • During analysis a discovery prototype • E.g. use of a prototype to determine screen formats and processing sequences (then thrown away) • Can show users or clients ideas early on to refine requirements (also used later on in design phase a lot) • Characteristics of Prototypes • Operative: a prototype should be a working model, with some real functionality • Focused: a prototype should be focused on a single objective • 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)

44. Distribute and Collect Questionnaires • Allows to collect information from large numbers of users • Can obtain early insight into information needs • Can be useful for collecting demographic or quantitative information • e.g. “how many orders do you enter a day?” “What is your educational background?” • Can collect information using scales, e.g. “On a scale of 1 to 7 how important is system speed?” – closed-ended questions which do not invite discussion • Less useful for collecting other types of qualitative information (e.g. system usability, user-interface needs)

46. Types of Questions in Questionnaires • Closed-ended questions (to determine quantitative information (Part I in figure 4-5) • Opinion questions/Qualitative (Part II in figure 4-5) • Open-ended questions / Requests for explanation or problems (Part III in figure 4-5) • Note – some current use of questionnaires • Deployment over the WWW is easy • Can use text entry boxes for explanation or problems • Can automatically summarize questionnaire results

47. Limitations of Questionnaires • Not well suited for learning about processes, workflows or techniques (e.g. to answer “How do you do this process?” - better to interview or observe) • Questions that encourage elaboration are called “open-ended” – can be put in a questionnaire but if there are too many of these, questionnaires tend not to get returned! • Relies in user’s memory of their use of systems (researches show this differs from what they actually do in many cases!)

48. Joint Application Design (JAD) Sessions • JAD: a technique to define requirements or design a system in a single session by having all the necessary people participating together • Normal interviews take lots of time and effort • May require many meetings (months) • JAD idea: why not compress all these activities into a shorter series of meetings with users and team members • JAD session may last a day to a week • Try to have all the stakeholders present to make decisions • All fact-finding, model-building etc. done in the JAD session

49. JAD Participants • JAD session leader • Trained in group dynamics and facilitating group discussion • Must ensure agenda and objectives are met • Often system analyst appointed as leader but better if someone actually trained to lead group decision making • May not be the expert in the business area though • Users • Managers are good to have at the meeting since important decisions have to be made • If executives cannot be at the meeting, they at least should be contactable (or visit once a day)

50. JAD Participants - continued • Technical staff • A representative from the technical support group should be present (e.g. for info. regarding things like networks, operating environments etc.) • Project team members • System analysts • User experts • Assist in discussion, clarify points, build models and document the results • Members of the project team are the experts on ensuring the objectives are met