Week 1 & 2

Introduction

Dr. Eman Al-MagharyDr. Eman Al-Maghary

Requirements EngineeringRequirements Engineering

AgendaSoftware Lifecycle and Software

Processes Introduction to RE

2

Engineering Character of Software Development

Large software development project requires an Engineering approach:

Life-CycleTeamworkRequires an overall plan, organization and communication

3

Some Process Models

Waterfall RUP:

Incremental Iterative

Specialized: Formal Methods

4

The Linear (Waterfall) Model

5

old fashioned but reasonable approach when requirements are well understood

Rational Unified Process (RUP)

7

8

Inception Elaboration Construction Transition

Iteration 1 Iteration 2 Iteration 3

Iteration PlanningRqmts Capture

Analysis & DesignImplementation

Test Prepare Release

“Mini-Waterfall” Process

RUP: Key pointsDefines the function of the system from the

user point of view applying scenario-based approach.

Uses Unified Modeling Language (UML): industrial standard notation

Rational: a software tools supporting UP and UML, used widely in industry

14

Modeling: Bridge between Requirements and Solution

Modeling a system involves: identifying the things that are important

to your particular view Their propertiesconsider how specific instances of these things

must fit together.

Modeling a system is affected by how you expect to use the system

Example: NEXT

15

Requirements Gathering: Dice Game

Requirements gathering is the Starting Point (WHAT, i.e., problem oriented)

16

Dice GameDice Game: A player plays the dice game the dice game includes two dice. A player rolls two dice. If the total is seven, the player wins; otherwise the player loses.

How Do You Expect to Use the Dice Game ?

“Happy end” scenario

17

Dice Game:• Roll two dice.

System:•CONGRATULATIONS! You won the game.

User:• I want to play this game.

How Do You Expect to Use the Dice Game ?

Not so “happy end” scenario

18

Dice Game:• Roll two dice.

System:• Looser, try again …

User:• I want to play this game.

Modeling: Dice Game Modeling Features:

19

Play with two dice

Dice GameDice Game: A player plays the dice game the dice game includes two dice.A player rolls two dice.If the total is seven, the player wins; otherwise the player loses.

Modeling: Dice Game Modeling Structure

20

Player

name

Die

FaceValue

DiceGame

total

Rolls1 2

1

1

Plays1

2

Includes

Modeling: Dice Game Modeling Behavior

21

: DiceGame

Die1: Die

Die2:Die

Play()

GetFaceValue()

roll()

roll()

GetFaceValue()

Total() Result()

Modeling Requirements:Requirements Specifications

Definition: “Specifications represent a model of how inputs are related to system reactions and outputs”

Specification is an ABSTRACTION of the Requirements

Specifications will increase the technical level of details given in the requirements

22

Modeling of The Problem: Problems?

Abstraction might capture only part of the real world truth (i.e., incomplete)A book may have more than one writersSomebody else is paid to write the book …

Domain Knowledge is requiredComplexity of the Problem is an issue

23

Software ComplexityLarge and Complex software systems:

Complex: Overall Behavior can only be predicted with some degree of uncertainty

Large: systems built with a large number of components Size complexitySize complexity: the vast amount of information to be

gathered and analyzed during the requirements & specification stage may cause incorrect and incomplete specification

Other sourcesOther sources for complexity: Environmental complexity Problem domain complexity Communication complexity

24

Specialized Process Models:The Formal Methods Model

Formal method— process to apply when a mathematical specification is to be developed

Enable software engineers to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation.

Offers (the promise of) defect-free softwareTraining is required

25

Software Engineering: Key PointsSE: A discipline for the systematic production

and maintenance of software developed by a team, which is fault-free, delivered on time,within budget, andsatisfies the user’s needs

GOAL: to produce a good quality software that is useful for people

26

AgendaSoftware Lifecycle and Software Processes Introduction to RE

27

What is a Good Quality Software?A software is good if it MEETS

CUSTOMERS EXPECTATIONS:

it is (at least) correct, reliable, maintainable, user-friendly …

the total cost it incurs over all phases of its life cycle is minimal and within the budget

28

Why Comprehension of User Requirements is Important?

Techniques: interviews, workshops, storyboards Rely on individual’s ability in communicating with the

stakeholders

29

RE objectives: Unambiguous, complete and consistent

problem documentation.

Barriers to requirements elicitation “Yes, But” syndrome “The Undiscovered Ruins” syndrome “The User and The Developer” syndrome

Stakeholders in SECustomers

Those who pay for the software

UsersThose who use the software

Software developersDevelopment Managers

30

31

32

33

How Do We … ?… know what the system is supposed to do?

By proper requirements development… keep track of the current status of

requirements?… determine the impact of a requirements

change?By proper requirements management

34

35

36

work with the customer on

gathering requirements

process this information to understand it, classify in various categories, and relate the customer needs to possible software

requirements

Structure the customer input and derived requirements as written documents and

diagrams

you’ll ask your customer to confirm that what you’ve written is accurate and

complete and to correct errors

37

•Elicitation: work with the customer on gathering requirements•Analysis: process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements•Specification: Structure the customer input and derived requirements as written documents and diagrams•Validation: you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors.This iterative process continues throughout requirements development, No single formulaic approach to requirements development.

Software-Intensive SystemsSoftware (on its own) is useless

Software is an abstract description of a set of computations

Software only becomes useful when run on some hardware we sometimes take the hardware for granted

Software + Hardware = “Computer System”A Computer System (on its own) is useless

Only useful in the context of some human activity that it can support we sometimes take the human context for granted

38

Software-Intensive Systems (cont.)

39

A new computer system will change human activities in significant ways

Software + Hardware + Human Activities = “Software-Intensive System”

‘Software’ makes many things possibleIt is complex and adaptableIt can be rapidly changed on-the-flyIt turns general-purpose hardware into a huge

variety of useful machines

Quality = Fitness for purpose

40

Software technology is everywhereAffects nearly all aspects of our livesBut our experience of software technology is often

frustrating/disappointingSoftware is designed for a purpose

If it doesn’t work well then either: …the designer didn’t have an adequate understanding of

the purpose …or we are using the software for a purpose different

from the intended oneRequirements analysis is about identifying this

purposeInadequate understanding of the purpose leads to

poor quality software

Quality = Fitness for purpose (cont.)

41

The purpose is found in human activitiesE.g. Purpose of a banking system comes from the

business activities of banks and the needs of their customers

The purpose is often complex: Many different kinds of people and activities Conflicting interests among them

Complexity of Purpose

42

People and software are closely-coupledComplex modes of interactionLong duration of interactionMixed-initiative interactionSocially-situated interaction…software systems and human activity shape each other in complex ways

The problems we’d like software to solve are “wicked”No definitive formulation of the problemNo stopping rule (each solution leads to new insights)Solutions are not right or wrongNo objective test of how good a solution is (subjective judgment needed)Each problem is unique (no other problem is exactly like it)Each problem can be treated as a symptom of another problemProblems often have strong political, ethical or professional dimensions

Dealing with problem complexity

43

AbstractionIgnore detail to see the big pictureTreat objects as the same by ignoring certain

differences(beware: every abstraction involves choice over

what is important)

DecompositionPartition a problem into independent pieces, to

study separately(beware: the parts are rarely independent really)

Dealing with problem complexity (cont.)

44

ProjectionSeparate different concerns (views) and describe them

separatelyDifferent from decomposition as it does not partition

the problem space(beware: different views will be inconsistent most of

the time)Modularization

Choose structures that are stable over time, to localize change

(beware: any structure will make some changes easier and others harder)

Definition of RE

45

Requirements Engineering (RE) is a set of activities concerned with identifying and

communicating the purpose of a software-intensive system, and the contexts in which it

will be used. Hence, RE acts as the bridge between the real world needs of users,

customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software intensive

technologies.

Requirements Engineering (RE) is a set of activities concerned with identifying and

communicating the purpose of a software-intensive system, and the contexts in which it

will be used. Hence, RE acts as the bridge between the real world needs of users,

customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software intensive

technologies.

Cost of getting it wrong

46

Cost of fixing errorsTypical development process:

requirements analysis ⇒ software design ⇒ programming ⇒ development testing ⇒ acceptance testing ⇒ operation

Errors cost more to fix the longer they are undetectedE.g. A requirements error found in testing costs 100 times

more than a programming error found in testing

Causes of project failureSurvey of US software projects by the Standish group:

Top 3 success factors: 1) User involvement 2) Executive management support 3) Clear statement of requirements

Top 3 factors leading to failure: 1) Lack of user input 2) Incomplete requirements & specs 3) Changing requirements & specs

Requirements ProblemsRequirements don’t reflect real needs of the

customerRequirements are inconsistent and/or

incompleteIt is expensive to make changes to

requirements after they have been agreedThere are misunderstandings between

customers and developers

47

Requirements PhaseThe requirements phase:

Elicitation of systems requirements as specified by the user

Review of these requirements for ambiguities and inconsistencies

Transformation of the requirements to a description of what the software will do without describing how it will do it.

48

System Requirements ElicitationElicitation of accurate requirements is

important becauseThe later in the development life cycle that

a software error is detected, the more expensive it will be to repair

Many errors remain latent and are not detected until well after the phase during which they are made

Many requirement errors are made

49

Requirements DocumentFormal document used to communicate

requirements to customers, engineers and managers

Serves as the baseline for the systemMust be formally changed via a change

control processIEEE Std. 830: 1998 (I will email it to you)

50

Requirements DocumentDescribes the following

services and functions of the systemsystem constraintsemergent propertiesidentification of system integration to other

systemsdomain informationdevelopment process constraints

51