ITEC 3010 Lecture 4 Investigating System Requirements 1

ITEC 3010 Lecture 4 Investigating System Requirements 1

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

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

• 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 4

5

• 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 6

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

• 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 8

9

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) 10

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 11

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

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? 13

• 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? 14

• 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? 15

• 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? ) 16

• 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? 17

• 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? 18

• 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? 19

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! 20

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 21

22

23

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 24

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 1. 2. 3. 4. Develop current system physical models Extract the current system logical models Develop new system logical model Develop new system physical model 25

• 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 26

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 27

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 28

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 29 like emails, memos etc. !

30

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) 31

Prepare Carry out Follow up 32

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? ”) 33

• 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 34

• 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) 35

36

Following Up the Interview • Have to absorb, understand 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 37

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 38 analyze

• 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! 39

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) 40 • Could use forms to structure observations (see next slide)

Organization: Company: Solid Steel Shelving Analyst: Joe Smith Scenario: Quality assurance Date: 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 41 the same week. - Observes on-screen results of QA model.

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 42 final system

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) 43

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) 44

45

• 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 46

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!) 47

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 48

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) 49

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 50

Setting for JAD sessions • Usually conducted in special rooms • Off-site location may be good • But need access (phone etc. ) to executives and technical staff not present • Resources – – Overhead projector Black or white board Flip chart Adequate work space 51

52

Advances to Support JAD sessions • Electronic support – Participants may have laptops connected in network – That way models and descriptions can be shown to everyone (could be done using a CASE tool) – Group Support Systems (GSSs) • System that enables multiple people to participate with comments at the same time, each on his or her computer • Allow for sharing of information and collaborative work • Runs on networked computers • Can include “chat” features to allow posting to participants • Allows inclusion of “shy” participants • Can store results of discussion and decisions made • Also allows for connection with participants at distant locations – end up with a “virtual” meeting (could include video hookup) 53

• Other forms of electronic support – Electronic white boards – Computer support for collaborative work (CSCW) software – Would allow for participation at remote sites who could work on documents at same time (shared files etc. ) 54

55

Limitations of JAD • Can be risky • Since done very fast may end up with suboptimal decisions • Details may be inappropriately defined or missed • However, JAD can be effective if done carefully with the result of shortening the schedule 56

Business Process Reengineering (BPR) • Popular buzzword over last ten years • Due to global competition many companies have had to completely rethink their assumptions about how to do business • Old rule of business: “If it isn’t broken, don’t fix it” • Newer way of thinking: “There is always a better way to do it, lets improve it” • Business process reengineering approach: “Let’s question basic assumptions to find a completely new way to do it that will bring dramatic and profound improvement” 57

Business Process Reengineering (cont. ) • Objective: to use IT in novel ways to achieve dramatic improvements in efficiencies and level of service • BPR and IT are closely aligned – Many systems analysts must also become business analysts – To assist in the process of rebuilding all internal business procedures based on new in innovative information technology 58