6. ANALYSIS 6. ANALYSIS PHASE- PHASE-

Requirements Requirements DeterminationDetermination

System Analysis And Design

Program: BSCS II (Advent Semester – 2014)

Lecturer: Rebecca Asiimwe

Email: rasiimwe@technology.ucu.ac.ug

Objectives

Slide 2

• Understand Requirements and

• Requirements analysis techniques

• Understand when to use each requirements analysis technique.

• Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation.

• Understand when to use each requirements-gathering technique.

Introduction

Slide 3

• The goal of this phase is to understand the requirements of the new system and latter develop a system that addresses them.

• First Challenge is collecting and integrating the information

• The second challenge is finding the right people to participate.

Requirements Determination

Slide 4

• This is the most critical step of the entire SDLC because it is here that the major elements of the system first begin to emerge, and the system is easy to change since little work has been done yet. As the system moves further into development, it becomes harder to return to requirements determination and to make major changes.

• More than half of the systems fail due to problems with the requirements.

• The purpose is to turn the very-high explanation of the business requirements in the system request into a more precise list of requirements that can be used as input to rest of the analysis phase

What are Requirements?

Slide 5

• Requirements – simply a statement of WHAT the system must do OR a characteristic it must have.

• Requirements tell the developer what the system will do and not how to design the system.

Types of Requirements

Slide 6

• Requirements written from the business and user perspective – User requirements

• Business/ user requirements evolve to become more technical and they describe how the system will be implemented and they are written from developer perspective- system requirements

User Requirements Classifications

Slide 7

• Functional requirements: relate directly to a process the system has to perform or information it needs to contain. They define the functions that the system needs to have, for example a requirement that states that the system must have the ability to search for available inventory or to report actual and budgeted expenses.

• Non-functional requirements: refer to behavioral properties that the system must have, for example performance, usability, security, quality etc, used mainly in the design phase.

Requirements Definition

Slide 8

• The requirements definition report- just called the requirements definition is a straightforward text report that simply lists the functional and non functional requirements in an outline format.

• Each numbered (in a legal / outline format) for clear identification.

Functional Requirements

Slide 9

Nonfunctional Requirements

Slide 10

Requirement Analysis Techniques

Slide 11

• Before the project team can determine what requirements are appropriate for a given system, they need to have a clear vision of the kind of system that will be created and level of change that it will bring to the organization.

• Basic process of analysis is divided into three steps– Understanding as-is system– Identify improvements– Develop requirements for the to-be system

Requirements Analysis Techniques

Slide 12

1. BPA (Business Process Automation)

2. BPI (Business Process Improvement)

3. BPR (Business Process Reengineering)

• The above techniques are used by analysts to help users discover their needs

Business Process Automation (BPA)

– Doesn’t change basic operations – Automates some operations– More time is spent understating the current as-is

system before improvements.

• BPA Techniques– Problem Analysis (ask stakeholders to indentify

problems with as-is system and describe how to solve them in the to-be system)

– Root Cause Analysis (root causes of problems are investigated)

Slide 13

Business Process Improvement (BPI)

Slide 14

• Business Process Improvement (BPI) – Making moderate changes to the way an

organization operates to take advantage of new opportunities offered by technology

– Can improve efficiency– Can improve effectiveness– Study the as-is system (though with less time

than BPA)– Primary focus- improving business processes

BPI Components

Slide 15

• Duration Analysis– Detailed examination of the amount of time taken

to perform each process in the current as-is system

• Activity-Based Costing– Examines major process costs

• Informal Benchmarking– Studies how other organizations perform their

business processes in order to learn how the organization can do better.

Business Process Reengineering (BPR)

Slide 16

• Changes how the organization operates• Making major changes to take advantage of new ideas and

technology• Spends little time on understanding the as-is; goal is to focus on

new ideas and new ways of doing business.• BPR Activities:

– Outcome Analysis (defines the outcomes that provide value to the customer)

– Technology analysis (identify interesting technologies and see how they might fit into the processes of the organization)

– Activity Elimination (business processes are simply eliminated that may prove to be no needed)

Select Appropriate Technique

Slide 17

• Assess Potential Business Value

• Determine Project Cost

• Specify Breadth or Scope of Analysis

• Determine Risk of Failure

Business Process Techniques

Slide 18

Requirements Gathering

Slide 19

• An analyst is like a detective- knows that there is a problem to be solved and must look for clues that uncover the solution.

• Clues are not obvious- needs to talk to stake holders / notice details

• Requirements gathering process is used to build political support for the project and establish trust and rapport between the project team and the users. All key stakeholders (the people who can affect the system or will be affected by it) must be included.

• Choose the best and appropriate ways of gathering information.

Techniques forRequirements Gathering

Slide 20

• Interviews

• Questionnaires

• Document analysis

• Observation

• Joint Application Design (JAD) sessions

• Prototyping

• E.t.c

Techniques for Requirements Gathering - Interviews

Slide 21

• Most commonly used requirements-gathering technique

• 5 basic steps to the interview process:– Selecting interviewees– Designing interview questions– Preparing for interview– Conducting the interview– Post interview follow-up

Conducting the Interview

Slide 22

• Appear professional and unbiased• Record all information• Check on organizational policy regarding tape

recording• Be sure you understand all issues and terms• Separate facts from opinions• Give the interviewee time to ask questions• Be sure to thank the interviewee• End on time

Conducting the InterviewPractical Tips

Slide 23

• Don’t worry, be happy

• Pay attention

• Summarize key points

• Be succinct (concise / to the point)

• Be honest

• Watch body language

Post-Interview Follow-Up

Slide 24

• Prepare interview notes

• Prepare interview report (contains interview notes, information that was collected over the course of the interview and is summarized in a useful format)

• Look for gaps and new questions

Interview Report

Slide 25

INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________Interviewer _______________Date _______________Primary Purpose:

Summary of Interview:

Open Items:

Detailed Notes:

JOINT APPLICATION DESIGN (JAD)

Slide 26

JAD Session

Slide 27

• An information-gathering technique that allows the project team, users, and management to work together to identify requirements.

• Structured process in which 10-20 users meet together under the direction of a facilitator skilled in JAD techniques.

• More structured than interviews.

JAD

Slide 28

• Allows project managers, users, and developers to work together.

• May reduce scope creep by 50%

• Avoids requirements being too specific or too vague

JAD - Important Roles

Slide 29

• Facilitator– sets the meeting agenda and guides the

discussion

• Scribe– assist the facilitator by recording notes,

making copies, etc.

• Project team, users, and management participate in the discussions.

JAD - Setting

Slide 30

• U-Shaped seating

• Away from distractions

• Whiteboard/flip chart used

• Prototyping tools (some people design screens in JAD session- prototyping tools aid in this)

• e-JAD

The JAD Session

Slide 31

• Tend to last 5 to 10 days over a three week period• Prepare questions as with interviews• Follows a formal agenda and ground rules • Facilitator activities

– Keep session on track– Help with technical terms and jargon– Record group input– Help resolve issues

• Post-session follow-up to summarize JAD findings

Managing Problems in JAD Sessions

Slide 32

• Reducing domination- one person should not monopolize the conversation so that only his/her requirements are in the findings.

• Facilitator and other participants should encourage non-contributors

• Side discussions in breaks are recommended

• Agenda merry-go-round:- happens when a member keeps returning to the same issue every few minutes and will not let go. Let them talk as you note down what they say, if they bring up the same issue, refer to the flip chart and let others contribute to the issue.

Managing Problems in JAD Sessions

• Violent agreement- participants agree on issues because they are using different terms. Facilitator has to define and translate terms into different words and find common ground so that parties realize that they really agree.

• Unresolved conflict: Participants can’t agree and can’t determine what alternatives are better. In this case, structure the issue, ask the group for criteria by which they can identify good alternatives, then ask the group to assess the alternatives using the list.

• True conflict- Group can’t agree on an issue- postpone the discussion and move on. Return to it later.

• Use humor when needed, keep the session enjoyable –encourages participation.

Slide 33

Techniques for Requirements Elicitation - Questionnaires

Slide 34

• Useful when the opinions of a large number of individuals need to be determined

• Forms of questionnaires:

– paper

– email or Web

• Design of questions is critical to success

Questionnaire Steps

Slide 35

• Selecting participants– Using samples of the population

• Designing the questionnaire– Careful question selection

• Administering the questionnaire– Working to get good response rate

• Questionnaire follow-up– Send results to participants

Good Questionnaire Design

Slide 36

• Begin with nonthreatening and interesting questions.• Group items into logically coherent sections.• Do not put important items at the very end of the

questionnaire.• Do not crowd a page with too many items.• Avoid abbreviations.• Avoid biased or suggestive items or terms.• Number questions to avoid confusion.• Pretest the questionnaire to identify confusing

questions.• Provide anonymity to respondents.

Document Analysis

Slide 37

• Examination of the various forms or documents used by the client in the business environment

• Provides clues about existing “as-is” system

Document Analysis

Slide 38

• Example of documents reviewed and analyzed

– Forms– Reports– Policy manuals

• Look for user additions to forms

• Look for unused form elements

Techniques for Requirements Gathering – Observation

Slide 39

• Powerful tool for gathering information about an existing system

• Methods of observation:

– personal observation

– video cameras

Techniques for Requirements Gathering – Observation

Slide 40

• Video cameras– Set up video cameras within the

workplace to record exactly what is being done

– Must have prior written permission from those being observed

Observation

Slide 41

• Users/managers often don’t remember everything they do

• Checks validity of information gathered through other methods

• Behaviors change when people are watched

• Careful not to ignore periodic activities– Weekly … Monthly … Annual

Selecting a Technique

Slide 42

Problems of Requirements Analysis

Slide 43

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.

• Different stakeholders may have conflicting requirements.

• Organizational and political factors may influence the system requirements.

• The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

Summary

Slide 44

• First Step to system development is to determine requirements

• Systems analysts use the following techniques – Interviews, – JAD, – Questionnaires, – Document Analysis, – Observation

Q & A

45