Introduction to Requirements Specification 1 Outline n Requirement

Introduction to Requirements Specification 1

Outline n Requirement Engineering n Software Lifecycle and Software Processes 2

3

Three Level Requirements n n n Stakeholder Needs Features of the System Software Requirements 4

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

Stakeholders in SE n Customers n n Users n n n Those who pay for the software Those who use the software Software developers Development Managers Problem: The customer often doesn’t have good grasp of what he wants. 6

Features of the System 7

Software Requirements 8

Importance of Requirements n The set of requirements constitute a contract between the client and the software developer n It should be written such that all stakeholders can understand what the system will do. n It allows developer to map problem domain concepts to solution domain concepts 9

Importance of Requirements 10

How Do We … ? n … know what the system is supposed to do? n n n By proper requirements development … keep track of the current status of requirements? … determine the impact of a requirements change? n By proper requirements management 11

We are focusing on these stages of RE Elicitation Analysis Negotiation Validation, Verification Introduction Representation, Specification Requirements Management 12 12

Requirements Engineering: General View 13

Requirements Development Process 14

Requirements Development Process n n 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. 15

What is Requirements Management? 16

Requirements Types 17

Functional Requirements Describe the functionality or services that the system is expected to provide n Address the input-output behavior of a system n 18

Examples of Functional Requirements 3. 1. 1{FR 1} Software shall automatically detect the presence of the network. 3. 1. 2{FR 2} Software shall automatically detect the presence of other computers running the application that are connected to the network. 19

Non-Functional Requirements 20

Design Constraints 21

Requirements Gathering: Dice Game n 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. 22

Modeling: Bridge between Requirements and Solution n Modeling a system involves: n n 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 23

How Do You Expect to Use the Dice Game ? n “Happy end” scenario Dice Game: • Roll two dice. System: • CONGRATULATIONS! You won the game. 24

How Do You Expect to Use the Dice Game ? n Not so “happy end” scenario Dice Game: • Roll two dice. System: • Looser, try again … 25

Modeling: Dice Game n 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 26

Modeling: Dice Game Modeling Structure Rolls 1 Player 2 name Die Face. Value 2 1 Plays 1 Dice. Game total 1 Includes 27

Modeling: Dice Game Modeling Behavior : Dice. Game Die 1: Die 2: Die Play() roll() Get. Face. Value() Result() Total() 28

Role of Visual Modeling 29

Modeling Requirements: Requirements Specifications n Definition: “Specifications represent a model of how inputs are related to system reactions and outputs” n n n 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 30

Modeling of The Problem: Problems? n Abstraction might capture only part of the real world truth (i. e. , incomplete) n n 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 31

Errors in Requirements might be also dangerous … 32

References 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/tr 12. 92. pdf Mildred Shaw (1997). Soft System Methodology. http: //sern. ucalgary. ca/courses/seng/613/F 97/grp 2/ssm. htm References 33 33

References Pictures: http: //japanesecentral. com/Siryoo/pictureclips/clothes/suit. jpg http: //www. bchu. org/whyweight/Success_Strategy/Content. htm http: //www. customnames. com/New. Vinyl. List. html http: //pacovilla. com/vweb/gallery/slideshow. php? set_album. Name=Pacos. Toy. Box http: //www. tacojohns. com/HTML/Graphics/Food/Burritos/Medium/Combo. Burrito. gif http: //www. cia. gov/cia/information/artifacts/model. htm All references on recipe cards References 34 34