ZEIT2301Design of Information Systems

Requirements Gathering

School of Engineering and Information Technology

UNSW@ADFA

Dr Kathryn Merrick

2

Week 03: Requirements Determination

Become familiar with requirements analysis techniques.

To identify criteria for a “good” requirement

To review requirements gathering techniques

Ref: text Ch 4

3

4

Analysis phase of the SDLC

The System Request outlined the business need for a new system.

In the Analysis phase, the analyst needs to gain a more thorough understanding of the business problem domain and user requirements.

What exactly is the problem this system will address?

Output from this phase is a Requirements Definition Report and models which illustrate this required system functionality

5

Analysis: What is the problem?

In researching this question, the first challenge is finding the right people to question, interview or observe.

A stakeholder is a “person, group or organization that can affect (or be affected by) a new system.” (Dennis et al)

Identify particular user groups and how they will use the system.

The second challenge is collecting and integrating the information that has been obtained when researching the problem.

Mistakes made at this stage can negatively impact later phases. Studies show that more than half of all system failures are due to

problems with requirements.

6

Requirements Determination

Determining the precise requirements of the system - all capabilities and constraints

“A requirement is simply a statement of what the system must do or what characteristic it must have”. Dennis et al.

May change over time as the project moves from analysis to design to implementation

In the early stage of analysis, the emphasis is on business requirements – the “what” of the system

Later, in design, requirements become more technical – describe “how” the system will be implemented

7

Functional and Non-Functional Requirements

Functional requirements Activities the system must perform Based on procedures and business functions Documented in analysis models

Eg: the library system must produce a report of overdue books

Non-functional (technical) requirements Describes operating environment, performance objectives,

security considerations, cultural factors Documented in narrative descriptions of technical requirements

Eg: the system must have a web interface; must interface with existing inventory system, etc

8

Non-Functional Requirements

9

Criteria for quality requirements

Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance

10

A Bad Requirement

Software will not be loaded from unknown sources onto the system without first having the software tested and approved.Software will not be loaded from unknown sources onto the system without first having the software tested and approved.

3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.

• Ambiguous – if the software is tested and approved, can it be loaded from unknown sources?

• (not) Testable – it is stated as a negative requirement making it difficult to verify.

• (not) Traceable – a unique identifier is missing.

11

A bad requirement

“Provide a means to transport a single individual from home to place of work”.

ManagementInterpretation

I TInterpretation

UserInterpretation

Ambiguous

12

Prioritising Requirements

MoSCoW Prioritisation M - MUST have this. S - SHOULD have this if at all possible. C - COULD have this if it does not effect anything else. W - WON'T have this time but would like in the future.

Managing change to avoid being overwhelmed by “requirements creep”

13

Requirements Analysis Strategies

The basic process of requirements analysis is divided into: Understanding the existing (as-is) system Identifying improvements Developing requirements for the new (to-be) system

There are three strategies for requirements analysis1. Business process automation2. Business process improvement3. Business process reengineering

14

1. Business Process Automation

BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work

Low risk, but low payoff

Planners in BPA projects invest significant time in understanding the current (as-is) system

Tends to solve problems rather than capitalize on opportunities Improvements tend to be small and incremental Problem analysis

15

2. Business Process Improvement

BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing

Typical approaches: Duration analysis – examine how long it takes to complete each

process Activity-based costing – examine the cost of each minor process

or step Informal benchmarking – study how other organizations perform

the process

16

3. Business Process Reengineering

BPR changes the fundamental way in which the organization operates

Limited study of the current (as-is) system goal is to focus on new ideas and new ways of doing business

Popular activities: Outcome analysis: eg outcomes from the customer’s point of view Technology analysis: technological opportunities Activity elimination: eg get customer to enter the info via the web

17

Selecting the Appropriate Strategies

18

Determining Requirements

Requirements are best determined by systems analysts and business people together

Techniques available to the systems analyst:1. Interviews

2. Questionnaires

3. Observation

4. Document analysis

5. Joint application development (JAD)

6. Throw-away prototyping

19

1. Interviews

Selecting interviewees Different perspectives: managers, users

Designing interview questions unstructured (broad), structured (narrow)

Preparing for the interview List questions, set priorities, schedule interview

Conducting the interview Be professional, record info, give interviewee time to ask

questions Post-interview follow-up

Review notes, look for gaps

20

Interviewing Strategies

Howcan order

processing beimproved?

How can we reduce thenumber of times that customers

return ordered items?

How can we reduce the number oferrors in order processing (e.g., shipping

the wrong products)?

Top-down

Bottom-up

High-level:Very general

Medium-level:Moderately specific

Low-level:Very specific

21

Types of Questions

Types of Questions Examples

Closed-Ended Questions * How many telephone orders are received per day?

* How do customers place orders?* What additional information would you like the new system to provide?

Open-Ended Questions * What do you think about the current system?* What are some of the problems you face on a daily basis?* How do you decide what types of marketing campaign to run?

Probing Questions * Why?* Can you give me an example?* Can you explain that in a bit more detail?

22

2. Questionnaires

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

23

Good Questionnaire Design

Begin with non-threatening 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

24

3. Observation

Observation helps check validity of information gathered other ways

Users/managers, when asked, often don’t remember everything they do

But behaviours change when people are watched

Be careful not to ignore periodic activities Weekly … Monthly … Annual

25

4. Document Analysis

Review existing reports, forms, and procedure descriptions

Provides clues about existing “as-is” current system

Typical documents Forms Reports Policy manuals

Look for user additions to forms

Look for unused form elements

26

5. Joint Application Development

Allows project managers, users, and developers to work together

May reduce scope creep by 50%

Avoids requirements being too specific or too vague

Often the most useful method for collecting information from users

27

JAD Meeting Room

JPEG Figure 5-5 Goes Here

28

The JAD Session

May involve several days over a period of a few weeks

Prepare questions as with interviews

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

Key RolesFacilitatorScribe

29

Managing Problems in JAD Sessions Reducing domination Encouraging non-contributors Avoid side discussions Agenda merry-go-round

the same issue raised continually Violent agreement

Inconsistent terminology masks potential agreement Unresolved conflict

Help group select a better alternative True conflict

Document as an open issue Use humor

30

Selecting Appropriate Techniques

As-is : understanding current system

Improves: identifies improvements

To-be: developing the new system

31

6. Prototyping in the Requirements phase

In RAD (Rapid Application Development), an ultimate technique of the requirements phase is rapid prototyping of the solution

This assists in clarifying difficult requirements and helps avoid misunderstandings

Agile, XP (eXtreme programming) and phased development methodologies emphasise involving users and using prototyping to elicit requirements in an incremental fashion.

32

The System Proposal

The System Proposal is the result of the planning and analysis phases

The System Proposal typically includes: Executive summary System request Work plan Feasibility analysis Requirements definition Evolving system models

33

Summary

After today’s lecture you should be aware of:

Functional and non-functional requirements

Quality requirements

Techniques for gathering system requirements