1

Introduction to Requirements Specification

2

Outline

Requirement Engineering Software Lifecycle and Software Processes

3

4

Three Level Requirements Stakeholder Needs Features of the System Software Requirements

5

Stakeholder Needs(extracted from the slides of Peter Hauker, Rational)

6

Stakeholders in SE Customers

Those who pay for the software Users

Those who use the software Software developers Development Managers

Problem: The customer often doesn’t have good grasp of what he wants.

7

Features of the System

8

Software Requirements

9

Importance of Requirements The set of requirements constitute a

contract between the client and the software developer It should be written such that all

stakeholders can understand what the system will do.

It allows developer to map problem domain concepts to solution domain concepts

10

Importance of Requirements

11

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

12Introduction 12

We are focusing on these stages of RE

Elicitation

Analysis

Negotiation

RequirementsManagementValidation,

Verification

Representation,Specification

13

Requirements Engineering: General View

14

Requirements Development Process

15

Requirements Development Process

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.

16

What is Requirements Management?

17

Requirements Types

18

Functional Requirements

Describe the functionality or services that the system is expected to provide

Address the input-output behavior of a system

19

Examples of Functional Requirements

3.1.1{FR1}Software shall automatically detect the presence of the network.

3.1.2{FR2}Software shall automatically detect the

presence of other computers running the application that are connected to the network.

20

Non-Functional Requirements

21

Design Constraints

22

Requirements Gathering: Dice Game

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

Dice Game:• A player rolls two dice. If the total is seven, the player wins; otherwise he loses.

23

Modeling: Bridge between Requirements and

Solution Modeling a system involves:

identifying the things that are important to your particular view

Their properties consider how specific instances of these

things must fit together. Modeling a system is affected

by how you expect to use the system

24

How Do You Expect to Use the Dice Game ?

“ Happy end” scenario

Dice Game:• Roll two dice.

System:•CONGRATULATIONS! You won the game.

25

How Do You Expect to Use the Dice Game ?

Not so “happy end” scenario

Dice Game:• Roll two dice.

System:• Looser, try again …

26

Modeling: Dice Game Modeling Features:

Dice Game:• A player rolls two dice. If the total is seven, the player wins; otherwise he loses.

Play with one user and two dice

27

Modeling: Dice Game

Modeling Structure

Player

name

Die

FaceValue

DiceGame

total

Rolls1 2

1

1

Plays1

2

Includes

28

Modeling: Dice Game

Modeling Behavior: DiceGame

Die1: Die

Die2:Die

Play()

GetFaceValue()

roll()

roll()

GetFaceValue()

Total() Result()

29

Role of Visual Modeling

30

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

Needed for: complex, large, or critical problems.

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

31

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 writers Somebody else is paid to write the book …

Domain Knowledge is required Complexity of the Problem is an issue

32

Errors in Requirements might be also dangerous …

33

References

References 33

Collaboration (2006). Requirements Analysis.http://en.wikipedia.org/wiki/Requirements_engineering

Karl E. Wiegers (2000). When Telepathy Won’t Do: Requirements Engineering Key Practices.http://www.processimpact.com/articles/telepathy.html

HCi Consulting (2001-2). Software requirements analysis, and why it doesn't work.http://www.jiludwig.com/HCI_Journal_article.html

Michael G. Christel, Kyo C. Kang (1992). Issues in Requirements Elicitation.http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf

Mildred Shaw (1997). Soft System Methodology.http://sern.ucalgary.ca/courses/seng/613/F97/grp2/ssm.htm

34

References

References 34

Pictures:http://japanesecentral.com/Siryoo/pictureclips/clothes/suit.jpghttp://www.bchu.org/whyweight/Success_Strategy/Content.htmhttp://www.customnames.com/NewVinylList.htmlhttp://pacovilla.com/v-web/gallery/slideshow.php?set_albumName=PacosToyBoxhttp://www.tacojohns.com/HTML/Graphics/Food/Burritos/Medium/Combo-Burrito.gifhttp://www.cia.gov/cia/information/artifacts/model.htm

All references on recipe cards