IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS

LECTURER : NOUF ALMUJALLY

22 – 10 – 2011

College Of Computer Science and Information, Information Systems Department

2 Requirement Engineering

3

Objectives

• Requirement Engineering Technology

• Software Requirement Specification and

Review

4Technology of Requirement Engineering

5

Requirements Elicitation Techniques

• Interviewing and questionnaires• Interviews are in-person meetings where the business analyst

asks questions to get information from the stakeholder.

• Requirements workshops• Workshops are facilitated meetings with multiple stakeholders

to draw out and document requirements

• Brainstorming are used to let the stakeholders come up with creative ideas or

new approaches to a problem

• Observation Observation is when the business analyst watches the users

performing their daily tasks and asks questions about the tasks and work

6

Requirements Elicitation Techniques (con.)

• Use Case• Use-cases are a scenario based technique which identify the actors

in an interaction and which describe the interaction itself.

• Storyboards• helps you take an idea and translate it into a visual story

• Prototyping• This is the use of partially finished versions of the software that have

been created to help validate requirements

A good business analyst should have excellent skills in eliciting good requirements and using the right elicitation technique for each situation.

7

Requirement Modelling and Analyzing

• Problem Decomposition• Abstract• Modelling• Multiple Viewpoints• Prototype

8

Problem Decomposition

• What is problem decomposition?• Decompose big problem into small

problems• Decrease and control problem complexity

• Sample of problem decomposition• Reader management• Book management• Book borrow

9

Abstract (1/2)

• What is abstract?• Catch the related parts and discard the

unrelated parts• To grasp the essence and core of problem

10

Abstract (2/2)

• Abstract of reader (related parts)• Name• Department• Photo• Type• Email• Telephone• Mobile

• Abstract of reader (unrelated parts) Height Age Thesis Father Blood Supervisor

11

Modelling (1/3)

• What is model of system• Model is the simplification of the real system and it

encompasses the related parts of system, ignores the unrelated parts of system

• Software requirement model describes the requirement of system to be developed in an accurate way

• Why modelling• Simplify the description and analysis of software

requirement• Specify the software requirements from multiple

viewpoints and different levels

12

Modelling (2/3)

• Methods for requirement modeling• Data flow requirement modelling• Object-oriented modelling

13

Modelling (3/3)

• Sample of modeling: Data Flow Diagram

14

Multiple Viewpoint

• What is multiple viewpoint• To describe and analyze software

requirements from multiple viewpoints and different levels

• To grab the customers’ requirements in a complete and clear way

15

Prototyping

• What is prototype?• Prototype is the intuitive and simple model of

systems to be developed.• It mainly focuses on the operation style,

process and interface.

• Why prototype?• Prototype as interaction media between

developers and customers• Prototype can easily find the problems of

software requirements

16Software Requirement Specification and Review

17

Software Requirement Specification (SRS)

• Software requirements should be written as a Document

• The SRS fully describes what the software will do and how it will be expected to perform.

• Functions and Behaviours E.g., borrow book, renew book

• Performances Response time should be less than 1 second

• Design constraints Running under Windows XP

• Others Schedule: 6 months

18

 A sample of a basic SRS outline

19

Review of SRS

• Reviews is necessary before SRS is to be submitted formally to designers

• Who participate in the reviews• Customers and end-users• Requirement analysts• Software designer

20

Attributes of a Good Requirement Specification

• Verifiability: Can the requirements be checked?• Consistency: Are there any requirements

conflicts?• Completeness: Are all functions required by the

customer included?• Comprehensibility: Is the requirement properly

understood?• Adaptability: Can the requirement be changed

without a large impact on other requirements?• Traceable: Is the origin of the requirement

clearly stated?

21

Questions ??

22

What should you do this week ?

• Review the lectures.• If you have any question related to the

assignment please ask me during the tutorial, by email or during the consultation hours.