1 SYS366 Week 5 - Lecture 1 Systems Requirements Gathering: Identifying Software Requirements

1

SYS366

Week 5 - Lecture 1Systems Requirements Gathering:

Identifying Software Requirements

2

Agenda

Identifying Software Requirements – Functional Requirements– Technical Requirements– Data Requirements

Fact Finding Methods

3

Identifying Requirements

Objective of the requirements capture and analysis phases is to understand business processes and develop requirements for the new system

4

5

Identifying System Requirements

“A requirement is a desired feature, property or behavior of a system.” *

* Unified Modeling Language

6

7


“Features can be functional or

non-functional.” *

* Use Case Modeling, by Bittner & Spence, page 75.

8


Software Requirements – “Individual statements of conditions and capabilities

to which the system must conform.” *


9


Each Software Requirement Is the specification of an externally observable behavior of the system– Inputs to the system– Outputs from the system– The processing of the system– Attributes of the system– Attributes of the system environment

Use Case Modeling, by Bittner & Spence, page 5.

10

What is Software Development?

Software Development implies developing some software – but it does not involve simply coding programs

Software is developed to turn manual processes into automated processes or to improve/enhance existing automated processes.

11

What does this have to do with Systems?

Software Development entails understanding the problem to be solved, understanding how a business operates and understanding that the solution to be developed will be of value to the business

12


“Software Requirements specify the things that the software does on behalf of the user or another

system.” *


13

Requirements Gathering

Analyst needs to find out what the user requires in the new system or what the user requires to be changed in an existing system– Gather the requirements by doing fact finding– Document the requirements

14


For an existing system, analyst needs to find out:– Functionality

Some of the functionality of the existing system will be included in the new system (can be acquired from existing documentation and code)

– Data needs Some of the data of the existing system will need

to be migrated into the new system

15


For a new system, analyst needs to find out:– Functionality

What are the activities the system needs to perform?

How is the user to interact with the system?Are other systems to interact with the system?

– Data needsWhat information is needed?

16


Scope of the System

Functional Technical DataRequirements Requirements Requirements

17

Functional Requirements

Describe what a system does or is expected to do “Specify the input and output behavior of a system”*

*Use Case Modeling, by Bittner & Spence, page 8.

18

Functional Requirements

Include– Descriptions of the processing which the system will be

required to carry out– Details of the inputs into the system from paper forms

and documents or the interactions between people and the system or transfers from other systems

– Details of the outputs that are expected from the system in the form of printed documents and reports, screen displays and transfers to other systems

:

19

Technical Requirements

“Specify the other qualities that the system must have, such as those related to the usability, reliability, performance and supportability of the system”*

Describe the aspects of the system that are concerned with how well it provides the functional requirements.

Include:– Performance criteria– Anticipated volumes of data– Security requirements

*Use Case Modeling, by Bittner & Spence, page 8.

20

Data Requirements

Describe what information the system is going to need or produce – really a part of Functional and Technical Requirements

Include– Details of the data that must be held in the system

21

Themes To Guide Investigation

What are business processes and operations? How should the business processes be performed? What are the information requirements?

Understand the Users’ Needs!

22

Today

Identifying System Requirements – Functional Requirements– Technical Requirements– Data Requirements


23


Conduct interviews and discussion with users Distribute and collect stakeholder questionnaires Review existing reports, forms, and procedure

descriptions Observe business processes and workflows Build prototypes Conduct JAD sessions

24


– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD

25

Interviews

We are going to concentrate on interview techniques; the rest of the slides explain the other methods for fact finding

26

Interviews

Primary technique for fact finding and information gathering

Most effective way to understand business functions and business rules

Usually requires multiple sessions Usually conducted with customers/clients/users Clients are not always able to express their

requirements clearly it is up to the analyst to ask the right questions to help the client express their requirements

27

Conducting effective interviews

– Determine who you are going to interview– Know what information that stakeholder can provide

for you– Prepare for the interview– Conduct the interview– Follow up on the interview

28

Determine who you are going to interview

Can be business or technical stakeholders– Business stakeholders provide the functional and

data requirements– Technical stakeholders provide the technical and

data requirements

29


Executives– Will provide information related to strategic issues

about the business – Need statistical and summary information

Management– Will provide a broad perspective about the business

as well as information about the system being developed

– Need statistical and summary information

30


Operational staff – will provide information about how the work is

actually done– Domain experts

31

Types of interviews

Structured Interview– Formal style– Requires significant preparation

Unstructured Interview– Informal– No pre-determined questions or objectives

32

Structured Interview

Preparing for the interview– Establish the objectives for the interview– Have a clear agenda– Prepared in advance with a list of open and closed

ended questions– Set the time and location for the interview– Inform all participants of the objective, time and

location

33


Questions– Questions should allow you to keep on track and

avoid getting off topic during the interview– Keep length of questions reasonable (15-20 words

or less)

34


Questions can be prepared from any of the following:– Observations made when existing form and reports

may have been reviewed– Observations made when reviewing the strategic,

tactical or operational plans– Observations made when observing employees

doing current job tasks

35


Phrase questions to avoid misunderstandings - use simple terms and wording

Do not ask questions that give clues to expected answers

Avoid asking two questions in one Do not ask questions that can raise concerns about job

security or other negative issues

36


Questioning Strategies

How canorder processing

be improved?

How can wereduce the number

of times that customersreturn items they’ve ordered?

How can we eliminate shipping the wrong products?

High-level: very general

Medium-level: moderatelyspecific

Low-level: very specific

Top Down

Bottom UP

37


Open ended questions– Encourages unstructured responses and generates discussion– Useful when you need to understand a larger process or to

draw out opinions or suggestions from the person being interviewed

– Examples What do you think about the current system? How do you decide what type of marketing campaigns to

run?

38


Closed ended questions– Limited or restricted response – a simple definitive

answer– Used to get information that is more specific or

when you need to verify facts– Examples:

How do customers place orders?How many orders to you receive a day?

39


How to conduct the interview– Dress appropriately; Arrive on time– Welcome the participants; introduce the attendees;

state the objective and agenda– Ask permission if you want to tape record the

interview– Ask questions from script

40


How to conduct the interview– Listen closely to the interviewee and encourage

them to expand on key points– Take thorough notes– Identify and document unanswered questions– At end of interview, review outstanding questions

that require follow up– Set date and time for the next, follow-up interview

41



42

Questionnaires

A document which contains a number of questions Can be paper form or electronic form (email or web-

based) Allows the analyst to collect information from a large

number of people– People outside the organization (I.e. customers)– Business users spread across a large geographic

area

43

Questionnaires

Limited and specific information from a large number of stakeholders

Preliminary insight Not well suited for gathering detailed information Open-ended questions vs. close-ended questions

44

Questionnaires

Similar process to interviewing– Determine who will receive the questionnaire– Design the questionnaire

Determine objective of questionnaire Design questions

– Follow up questionnaire

45

Questionnaires

Determine who will receive the questionnaire– Select a sample audience who are representative of

an entire group– Assume 30-50% return rate for paper and email

questionnaires– Assume a 5-30% return rate for web-based

questionnaires

46

Questionnaires

Design the Questionnaire– Clearly state the following in the questionnaire:

The purpose of the questionnaireWhy the respondent was selected to receive the

questionnaireWhen the questionnaire is to be returned

47

Questionnaires

Design the Questionnaire– Let the respondent know when/where they can see

the accumulated questionnaire responses– Consider providing an inducement to have the

respondent complete the questionnaire (I.e. a pen)

48

Questionnaires

Design the Questionnaire– Keep the questionnaire brief and user friendly– Provide clear instructions on how to complete the

questionnaire– Arrange the questions in a logical order; going from

easy to more complex topics

49

Questionnaires

Design the Questionnaire– Phrase questions to avoid misunderstandings, use

simple terms and wording– Do not ask questions that give clues to expected

answers– Avoid asking two questions in one– Limit the use of open ended questions that will be

difficult to tabulate

50

Questionnaires

Design the Questionnaire– Do not ask questions that can raise concerns about

job security or other negative issues– Include a section at the end of the questionnaire for

general comments– Test the questionnaire whenever possible on a

small test group before finalizing it

51



52

Review Existing Reports, Forms, and Procedure Descriptions

Purposes– Preliminary understanding of processes– Guidelines / visual cues to guide interviews

Identify business rules, discrepancies, and redundancies

Be cautious of outdated material

53

Reviewing existing documentation

Most beneficial to new employees or consultants hired to work on a project

Types of documentation that is reviewed:– Company reports– Organization charts– Policy and Procedures manuals– Job Descriptions– Documentation of existing systems

54

Reviewing existing documentation

Allows the analyst to get an understanding of the organization prior to meeting with employees

Allows the analyst to prepare questions for either interviews or questionnaires (other fact finding techniques)

55



56

Observation

An effective way to gather requirements if obtaining complete information was not effective through other fact finding techniques (I.e. interviews and questionnaires)

Or An effective way to verify information gathered from

other fact finding sources (such as interviews)

57

Observation

Observation can be done by having the analyst observe the client from a distance (without actually interrupting the client) or by actually doing the work of the client

58

Observation

Should be carried out for a period of time and at different time intervals, not just once, so that the analyst can observe different workloads and to ensure that what the client does is consistent over different periods of time

59

Observation

Allows the analyst to follow an entire process from start to finish

Can upset the client if they feel threatened by new activity going on around them – the client may behave differently from what they normally do

60



61

Prototypes

A demonstration system– Represents a graphical user interface– Simulates system behavior for various events– Any data displayed on a GUI screen is hard-coded; not

retrieved from a database Constructed to visualize the system Allows the customer to provide feedback An effective way to gather requirements for a new

system Supports JAD or RAD type sessions

62



63

Other Methods

Joint Application Development (JAD)– A series of workshops that bring together all

stakeholders (users and systems personnel)

64

Other Methods

Joint Application Development (JAD)– Consists of the following types of attendees:

Facilitator: the person who conducts the meeting and keeps it on track (generally the analyst)

Note taker: the person who records the information for the session

Clients/Customers/Users: the people who communicate the requirements, take decisions and approve the project

Developers: the people who are part of the development team and need to gather information

65

Other Methods

Joint Application Development (JAD)– Takes advantage of the group dynamics– Increased productivity– May require more than one session– One session may last a few hours, several days or

several weeks

66



67

Other Methods

Rapid Application Development (RAD)– An approach to software development where the

system solution is delivered – fast– Most appropriate for systems which are not the

organization’s core business

68

Other Methods

Rapid Application Development (RAD)– Can result in:

Inconsistent GUI designsPoorly documented systemsSoftware that is difficult to maintain

Documents

1 SYS366 Week 5 - Lecture 1 Systems Requirements Gathering: Identifying Software Requirements