1

ITEC 3010

Lecture 4

Investigating System Requirements

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

Requirements

PHYSICALENVIRONMENT

INTERFACES USER AND HUMAN FACTORS

FUNCTIONALITY

DOCUMENTATIONDATARESOURCES

SECURITY

QUALITYASSURANCE

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? (eg. 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– Need usability testing to get at this! (text doesn’t mention)

• 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

– Approach1. Develop current system physical models2. Extract the current system logical models3. Develop new system logical model4. Develop new system physical model

25

• Faster approach– Identify current system procedures immediately (as

much as need to, don’t necessarily define specific processes)

– Develop requirements and models for new system (ie. 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

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)

29

30

• Types of Questions in Questionnaires– Closed-ended questions (to determine

quantitative information (Part I in figure 4-5)– Opinion questions (Part II in figure 4-5)– 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

31

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

32

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

33

34

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)

35

Prepare

Carry out

Follow up

36

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– I like to audiotape interview (when allowed!)

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

37

• Last step in preparing: make the interview arrangements (where to meet and when – good to pick a quiet room)

Conducting the Interview

• See text for variety of tips, like dress well, be polite and arrive on time!

• 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

38

• 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– Text says tape recorders make people nervous, but

notes and taping is good combo! – Privacy.

• Try to follow some logical agenda during the interview

• Semi-structured interviews often most useful (unstructured interviews can often get out of control)

39

40

Following Up the Interview

• Have to absorb, understand and document the information collected from the interview

• Can write it up as text and also document by constructing diagrammatic models

• Review with others who attended the interviews• Make a list of questions that need further

elaboration (see figure 4-9 for an example of a sample “Open-items” list)

41

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

42

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

43

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)• Can be used in conjunction with other methods (e.g.

interviews)• Could use forms to structure observations (see next slide)

44

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

45

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

46

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)

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