CS 5103 Software Engineering Lecture 04 Requirement Specification

CS 5103 Software Engineering Lecture 04 Requirement Specification UML Use Cases

Last class Ø Requirement Engineering Ø Ø 2 Concepts Ø Definition Ø Stakeholders Ø Types of requirements Process Ø Elicitation Ø Analysis Ø Specification Ø Validation

Elicitation Approaches 3 Ø Brainstorming Ø Interviewing Ø Ethnography Ø Strawman/Prototype Ø Testable User Story

Today’s class Ø Ø Requirement Engineering Ø Analysis Ø Specification Ø Validation Use case diagram Ø 4 A good notation for requirement specification

Combination of different approaches Ø Brainstorm + interview Ø Ø Interview + strawman/prototype Ø Ø Asking people after observing their work Prototype + ethnography Ø 5 Talk to interviewee with a strawman/prototype Interview + ethnography Ø Ø Raise some questions, then ask more people Observe how people work on a prototype

Requirements Engineering Process Elicitation Analysis Specification Validation 6

Requirements Analysis Requirements analysts have to understand the Ø system from each stakeholder's point of view l 7 Stakeholders have different views of the system Ø Requirements analysts resolve conflicting views Ø Requirements analysts prioritize requirements l Essential requirements l Desirable requirements l Optional requirements

Requirements Analysis Goal Ø Ø Categorization, negotiation, and decision: Ø Ø Determine the scope of the software Ø Few established fixed approaches Ø Large amount of mental work based on domain knowledge Project manager/customer representative often plays the key role 8

Requirements Specification Ø Specify requirements l Document what is required of the system to be developed l State the requirements from the perspective of the developers l 9 May be a formal document (IEEE-SRS)

Requirements Specification Ø Natural Language Specification Ø Structure Specification Ø Graph Notation Specification Ø Mathematical Specification Formal 10

Natural language specification Ø Ø Ø The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Diagrams and tables can be used for better understanding of the specification 11

Guidelines for writing requirements Ø Formatting Ø Invent a standard format and use it for all requirements Ø Ø Ø Font, size, indentation, … Use text highlighting to identify key parts of the requirement. Wording Ø Use language in a consistent way. Ø E. g. always use shall for mandatory requirements, should for desirable requirements Ø Avoid the use of computer jargon Ø Including a list of term definitions

Guidelines for writing requirements Ø Contents Ø Avoid ambiguity in expression Ø Add as much details as you can (think as a developer)

An example of natural language specification 1. 1 If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales for the current month is under 5% Any problems with this specification?

An example of natural language specification 1. 1 If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales for the current month is under 5% Any problems with this specification? Ambiguity: 5% of actual sales or target sales?

An example of natural language specification 1. 1 If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales for the current month is under 5% Any problems with this specification? Potential term inconsistency: sales & actual sales

An example of natural language specification 1. 1 If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales for the current month is under 5% Any problems with this specification? Lack of details: What are contents in the report? When and how to print?

An example of natural language specification 1. 1 If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales for the current month is under 5% Any problems with this specification? Terms require definition: Actual sales, target sales, current month

Advantages of Natural Language Ø Ø Ø Expressive, can express almost any concepts, although not precisely Can be understood by users, customers, developers, etc. Easy to write

Problems with natural language Ø Ambiguity, imprecision Ø Contradictions can happen Ø Ø Functional and non-functional requirements tend to be mixed-up Several different requirements may be expressed together

Requirements Specification Ø Natural Language Specification Ø Structure Specification Ø Graph Notation Specification Ø Mathematical Specification Formal 21

Structured specifications Ø The structure of a requirement is predefined Ø The freedom of the requirements writer is limited Ø Some common structures: Ø Forms Ø Tables Chapter 4 Requirements engineering 22

Form-based specifications Ø Ø Ø Definition of the function or entity Ø Description of the action to be taken Input & Output Ø Description of inputs and where they come from. Ø Description of outputs and where they go to Ø Pre and post conditions (if any) Dependencies Ø Information needed & other entities used Ø The side effects (if any) of the function Ø E. g. , reduced credit score when you query it

Example: Insulin pump for blood sugar control Chapter 4 Requirements engineering 24

Example: Insulin Pump Chapter 4 Requirements engineering 25

Tabular specification Ø Ø A map from inputs to outputs in the form of a table Ø Each line corresponds to a case in inputs Ø The corresponding action is filled in Particularly useful when you have to define a number of possible alternative courses of action.

Example: Insulin Pump Condition Action Sugar level falling (r 2 < r 1) Comp. Dose = 0 Sugar level stable (r 2 = r 1) Comp. Dose = 0 Sugar level increasing and rate Comp. Dose = 0 of increase decreasing ((r 2 – r 1) < (r 1 – r 0)) Sugar level increasing and rate Comp. Dose = of increase stable or increasing round ((r 2 – r 1)/4) ((r 2 – r 1) ≥ (r 1 – r 0)) If rounded result = 0 then Comp. Dose = Chapter 4 Requirements engineering Minimum. Dose 27

Pros & Cons: structures Ø Pros Ø Ø Easier to control quality compared with pure natural language Still easy to write and understand Reduce imprecision and missing of details Cons Ø Ø Ø The form of structure has strong impact on the quality of specification, and is not easy to design Less expressiveness due to the rigid structures Still has the problem of natural language expression, such as ambiguity, missing term definitions, etc.

Requirements Specification Ø Natural Language Specification Ø Structure Specification Ø Graph Notation Specification Ø Mathematical Specification Formal 29

Graph Notation Specification Ø Predefined Graphical models Ø Supplemented by text annotations Ø Existing techniques: Ø Ø 30 UML: Use case diagram Widely used: we will introduce later

Requirements Specification Ø Natural Language Specification Ø Structure Specification Ø Graph Notation Specification Ø Mathematical Specification Formal 31

Mathematic Specification Ø Ø Ø Write specification using predefined formal languages Define all concepts, inputs, and corresponding outputs /actions formally Some popular specification languages: Ø Ø Ø Z language Alloy …

Example: word split with Z language Ø Textual Description Ø Purpose: Breaking a text into words Ø A text is a sequence of characters. Ø Certain characters are blanks: spaces, line breaks, and tabs Ø A word is a sequence of non-blank characters Ø A separator is a sequence of blank characters.

Example: word split with Z language Ø Concept Definition: char == [CHAR] (CHAR is defined as all characters) blank == [space, line break, tab] TEXT == seq char (seq is a predefined function, meaning a sequence of elements from its set-type argument) SEPARATOR == seq 1 blank WORD == seq 1 (char blank) Note: TEXT includes the empty sequence, but SPACE and WORD must have at least one character, so we declare them to be seq 1 (non-empty sequences).

Example: word split with Z language Ø Requirement of function words: TEXT -> seq WORD forall s: SPACE; w: WORD; l, r: TEXT words <> = <> & words s = <> & words w = < w > & words (sr) = words r & words (ls) = words l & words (lsr) = words l + words r

Pros & Cons Ø Pros Ø Ø Precise, little ambiguity (almost pseudo code) Computer readable, so correctness can be checked with automatic tools (e. g. model checker) Easy to write test case based on the specification (providing oracles) Cons Ø Ø Ø Hard to understand Hard to write, costly to find people writing it and using it Expressiveness depending on the specification language (often not expressive enough)

In practice Ø Natural language Ø Ø Structure Ø Ø Often used as a supplement to natural language Graph Notation Ø Ø Widely used, especially for small projects Widely used in industry, business information systems Mathematics Ø What software often involves mathematical specification? Ø Compilers (programming language) Ø Browsers (HTML) Ø Database systems (SQL)

Today’s class Ø Ø Requirement Engineering Ø Specification Ø Validation Use case diagram Ø 38 A good notation for requirement specification

Requirements validation Ø Ø Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Ø Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. 39

Requirements Validation Ø 40 Validation can be done with techniques Ø Review Ø Prototype Ø Writing test cases Ø Verification of properties

Requirements validation techniques Ø Requirements reviews Ø Ø Systematic manual analysis of the requirements Regular reviews should be held while the requirements definition is being formulated Both client and contractor staff should be involved in reviews Reviews may be formal (with completed documents) or informal 41

Requirements validation techniques Ø Prototyping Ø Ø Using an executable model of the system to check requirements. Covered in previous lectures Test-case generation Ø Ø Developing tests for requirements to check testability Used in extreme programming, also used as a validation technique 42

Specification Verification Ø Verification can be done with techniques Ø Consistency checking Ø Ø Completeness checking Ø Ø 43 No contradictions All concepts are well defined Formal verification of the above or other properties Ø Usually require mathematical specification Ø Model checking, automatic reasoning, …

History of UML Ø UML appeared in 1997 after many years of modeling war: 50+ modeling languages Ø Three leading languages Ø Booch, OMT, OOSE Ø 1994 Rumbaugh (OMT) joined Booch (in Rational) Ø 1995 Rational bought Objectory Ø Jacobson, Ø OOSE -- use cases UML = OMT + Booch + OOSE + …

Introduction Ø UML is a set of modeling notations, which include 13 diagrams Ø Static structure of the system Ø Class diagram Ø Object diagram Ø … … Ø Dynamic behavior of the system Ø Use case diagram Ø Sequence diagram Ø … …

We will introduce: Ø 46 UML Ø Use case diagram (requirement) Ø Class diagram (general design) Ø Sequence diagram (detailed design)

UML Use Case Diagram Ø Used as a graphics notation for requirement engineering Ø System: drawn as a box Ø Actors: outside the system Ø Use cases: inside the system Ø Relations among use cases

Actors Ø Actors are external to the system Ø An actor specifies a role Ø Ø Ø Users that operate the system directly Other software systems or hardware pieces that interact with the system One person or thing may play many roles in relation to the system simultaneously or over time

Use Cases Ø Use cases are usages of the system Ø Use cases capture the functional requirements Ø Ø Ø Use cases provide the high-level descriptions of the system’s functionality in terms of interactions Use cases show inputs and outputs between the system and the environment Use cases are from the user’s point of view

Use Case – An Example ATM system Ø Ø Withdraw cash Ø Check account balance Ø Maintain usage statistics Ø …

Legend Actor: an entity in the environment that initiates and interacts with the system Use case: usage of system a set of sequences of actions Association: relation between actor and use cases <<include>> Includes dependency: a sub use case <<extend>> Extends dependency: a subtype of use cases

Initial Use Case Diagram for ATM

Elaborated Use Case Diagram for ATM

Today’s class Ø Requirement Engineering Ø Ø Natural Language Ø Structure Ø Graph Notation Ø Mathematical Validation Use case diagram Ø 54 Specification A good notation for requirement specification

Next class Ø 55 UML Ø Use case diagram Ø Class diagram Ø Sequence diagram

Thanks! 56