is 466 Advanced topics in information Systems Lecturer : Nouf Almujally 22 – 10 – 2011

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

• What is Requirement Engineering?

• Task and Process of Requirement

Engineering

• Requirement Engineering Technology

• Software Requirement Specification and

Review

4

Questions?

• If you are required to develop a library information software system, what will you do firstly?

• What functions that the system may have?• What behaviors that the system may have?• What performances that the system may

have?• What is the scope and boundary of the

software?• ……. Etc.

5

Software Requirement

• To understand customers’ requirements about the software to be developed is extremely important

• Software requirement• Customers’ needs about the developed software,

including functions, performance, design constraints, schedule, etc.

• Sample of software requirements• Function: borrow book, renew book, …• Performance: the time of query book must be lower

1second• Constraints: software should be deployed and run under• windows OS• Schedule: development period is 6 months

6

Requirement Engineering

• What is requirement engineering ?

• The process to obtain customers or end-users

requirements of software

• includes a set of tasks that lead to an

understanding of software requirements

• Helps software engineers to better

understand the problem they will work to

solve

7

Who Does IT?

• Stakeholders : are individuals who affect or are affected by the software product• Customers: request, purchase, and/or pay for the

software product in order to meet their business objectives.

• End-users: use the product directly or use the product indirectly by receiving reports, outputs, or other information generated by the product

• The requirements analyst: responsible for eliciting the requirements from the customers, users, and other stakeholders, analyzing the requirements, writing the requirements specification, and communicating the requirements to development and other stakeholders

8

Who Does IT?

• The designers: responsible for translating the requirements into the software’s architectural and detailed designs that specify how the software will be implemented.

• The developers: responsible for implementing the designs by creating the software products.

• The project managers: responsible for planning, monitoring, and controlling the project and guiding the software development team to the successful delivery of the software

9

Importance of Requirement Engineering

• Basis and precondition of software development

• If you do not know what the problems are, you will

have no way to know how to solve

• Without it, the resulting software has a high

possibility of not meeting customers’ needs

• Establishes a solid base for design and construction• Standard to check whether the developed

software meets customers or end-users’ requirements

10

Importance of Requirement Engineering

11

Complexity of Requirement Engineering

• Customers are unable to express requirements explicitly Typically, they can not tell you what they want

clearly

• The requirements that customers or end-users present are often incomplete inaccurate inconsistent

• Software requirements are often extremely complex and large scale

12

Problems and Challenges

• If the above problems can not be solved, the developed software will be incorrect Lost the desired functions of customers Implemented functions are not the right

ones that customers or end-users want

• Therefore, technologies and methods are necessary to support requirement engineering

13Task and Process of Requirement Engineering

14

Task of Requirement Engineering

• Obtain and understand software requirements in a complete, consistent and accurate way, and generate software requirement specification (SRS) document.

15

Process of Requirement Engineering

Requirement engineering is completed through the following seven activities:• Inception• Elicitation• Elaboration• Negotiation• Specification• Validation• Management

16

Inception (1/2)

• Purpose• Identify and discuss with stakeholders• Anyone who benefits in a direct or indirect way

from the system which is being developed: Customers, end-users, consultants, product engineers, software engineers

• Approach• Find and create stakeholders list• Ask: “who else do you think I should talk to?” to

find more• Result

• A list of stakeholders

17

Inception (2/2)

• Questions when interacting with stakeholders:• Who is behind the request for this work?• Who will use the solution?• What will be the economic benefit of a

successful solution• Is there another source for the solution that

you need?

18

Elicitation (1/3)

requirements gathering

Purpose• Elicit requirements from all stakeholders• Identify the problem• Define the scope of problem• Propose elements of the solution• Negotiate different approaches, and• Specify a preliminary set of solution

requirements

19

Elicitation (2/3)

Approach• Meetings are conducted and attended by

both software engineers and customers• Rules for preparation and participation

are established• An agenda is suggested• A "facilitator" (can be a customer, a

developer, or an outsider) controls the meeting

20

Elicitation (3/3)

Result: elicitation work products• A statement of need and feasibility• A bounded statement of scope for the system or product• A list of stakeholders who participated in requirements

elicitation• A description of the system’s technical environment• A list of requirements and the domain constraints that

apply to each• A set of usage scenarios that provide insight into the use

of the system or product under different operating conditions

• Any prototypes developed to better define requirements

21

Elaboration (1/2)

Purpose• Create a refined analysis model of

software functions, features, and constraints for analyzing

Approach• Modelling, refinement• Scenario-based

• Use-case - descriptions of the interaction between an “actor” and the system

22

Use-case

23

Elaboration (2/2)

Approach• Behaviour-based: state diagram• Flow-oriented: data flow diagram

Result• Requirement analysis model of software,

which defines the informational, functional and behavioral domain of problem

24

Negotiation

Purpose• Conflict requirements• Unpractical requirements with limited resources• Agree on a deliverable system that is realistic for

developers and customers

Approach• Identify the potential conflict and unpractical requirements• Rank requirements and discuss conflicts• Reconcile these conflicts through negotiation• Eliminate, combined and modified requirements

Result: agreed software requirements

25

Specification

Purpose• Create the documents of software requirements

Approach• A written document• A set of models• A formal mathematical• A collection of user scenarios (use-cases)• A prototype

Result• Software requirement specification (SRS)

26

Validation (1/3)

Purpose• To find the errors or missing information in SRS

A review mechanism that looks for• Errors in content or interpretation• Areas where clarification may be required• Missing information• Inconsistencies (a major problem when large products or

systems are engineered)• Conflicting or unrealistic (unachievable) requirements.

Result• Validated software requirement specification

27

Validation (2/3)

Questions when validating• Is each requirement consistent with the overall

objective for the system/product?

• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous?

28

Validation (3/3)

Questions when validating (cont.)• Do any requirements conflict with other

requirements?

• Is each requirement achievable in the technical environment that will house the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information, function and behavior of the system to be built?

29

Management

• Requirement management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds• Each requirement is assigned a unique

identifier

30Technology of Requirement Engineering

31

Requirements Elicitation Techniques

• Interviewing and questionnaires• Requirements workshops• Brainstorming• Storyboards• Use Cases• Prototyping

32

Requirement Modelling and Analyzing

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

33

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

34

Abstract (1/2)

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

unrelated parts• To grasp the essence and core of problem

35

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

36

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

37

Modelling (2/3)

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

38

Modelling (3/3)

• Sample of modeling: Data Flow Diagram

39

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

40

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

41Software Requirement Specification and Review

42

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

43

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

44

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?

45

Questions ??

46

What should you do this week ?

• Review the lectures.• Monday is review lecture, please print the

slides.• If you have any question related to the

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