CS350 Lecture 3 Requirements Engineering

Doo-Hwan Bae

bae@se.kaist.ac.kr

Requirements Engineering(1/3)

• Requirements Engineering• Emphasizes an iterative and cooperative process of

• analyze the problem (gathering and analysis)• documents the resulting observations (specification)• checking the accuracy of the understanding gained. (verification)

• Def. of Requirement• A condition of capability needed by a user to solve a problem or achieve an objective.

• User• can be an end user of the system

• the end user: mostly source for functional requirements

• other stakeholders: • the stakeholders: source for nonfunctional requirements

Requirements Engineering(2/3)

• Three processes in RE- Requirements Elicitation (gathering and analysis)-- understand the problem

- Requirements Specification

-- Once the problem is understood, it has to be specified

-- Or, describe the product to be delivered

-- Informal and formal methods, used.

- Requirements validation and verification

-- Once described, the different parties involved have to agree upon its nature.

-- Validation: the correct R’s are stated.

-- Verification: The R’s are stated correctly.

Requirements Engineering(3/3)

• Requirements vs.• Specification vs.• Program

5

Example System Requirements

Identifier Priority Requirement

REQ1 5The system shall keep the door locked at all times, unless commanded otherwise byauthorized user. When the lock is disarmed, a countdown shall be initiated at the endof which the lock shall be automatically armed (if still disarmed).

REQ2 2 The system shall lock the door when commanded by pressing a dedicated button.REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices.

REQ4 4The system should allow mistakes while entering the key code. However, to resist “dictionary attacks,” the number of allowed failed attempts shall be small, say three, after which the system will block and the alarm bell shall be sounded.

REQ5 2 The system shall maintain a history log of all attempted accesses for later review.REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones.

REQ7 2 The system shall allow configuring the preferences for device activation when the user provides a valid key code, as well as when a burglary attempt is detected.

REQ8 1The system should allow searching the history log by specifying one or more of these parameters: the time frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function shall be available over the Web by pointing a browser to a specified URL.

REQ9 1 The system should allow filing inquiries about “suspicious” accesses. This function shall be available over the Web.

• Problem: Requirements prioritization.

• See how solved in agile methods.

Requirements Engineering: Case Study(1/4)• University’s library automating its operations.

Start with the library containing a number of cabinets, each holds a huge number of cards, one per book. Each card contains the names of the authors, the book title, ISBN, publication year, etc.. The cards are ordered alphabetically by the name of the first author of each book.

• You are expected to specify its requirements. Is there any ambiguity or uncertainty, here?

Requirements Engineering: Case Study(2/4)• What are the ambiguities, here?

It only works well if we know the first author’s name.

• During Requirements Analysis, a number of user R’s will be raised: - Adding, deleting, and changing records

- Give a list of all books written by X

- Give a list of all books whose title contains Y

- Give a list of all books on topic Z

- Give a list of all books that arrived after date D

Requirements Engineering: Case Study(3/4)• Group User R’s into several categories (MoSCoW)

- Must haves: Essential features

- Should haves: Nice features

- Could haves: if time allows

- Won’t haves: not today

• Predict a number of future requirements• Storing information about the books that have been ordered but have not been received.• Storing information about the library members, such as their names and addresses, and the

dates on which books are lent to them• Library management may wish to use the system to get information on member profiles in

order to improve the title acquisition process

Requirements Engineering:Case Study(4/4)• Other Requirements

- Which machine, which OS, which DBMS, terminal?

- Which classes of users can be distinguished?

- What is the size of the DB, how is it expected to grow?

- What response time should the system offer?

- How much will a system of this kind cost?

Requirements Analysis and Specification

• Identify the qualities required for the application.• Functional and nonfunctional• Must state what to do, not how to do.• Used by both customer and designers• Separate functional requirements into three views:

• A model of data: Entity relationship diagrams, domain model (diagram)• A model of function: Data flow diagrams, use case diagram• A model of control: Control flow diagrams, State Machines, Petri nets, sequence diagram

Domain Modeling(1/2)

• Why? —The goal of domain modeling is to understand how system-to-be will work

• Requirements analysis determined how users will interact with system-to-be (external behavior)

• Domain modeling determines how elements of system-to-be interact (internal behavior) to produce the external behavior

• Where(What info.)? —We do domain modeling based on:• Knowledge of how system-to-be is supposed to behave (from requirements analysis,

e.g., use cases)• Studying the work domain (or, problem domain)• Developer’s past experience with software design

Domain Modeling(2/2)

• What?• Illustrates meaningful conceptual classes in a problem domain• Is a representation of real-world concepts, not software components• Is the most important OO artifacts

• Decompose the system into a set of objects, rather than functions!

• How?• Identify nouns and noun phrases in textual descriptions of the

domain• Use use cases in use-case diagrams

• Add associations for relationships that must be retained• Add attributes necessary for information to be preserved

Conceptual Class vs. Software Artifacts

Use Case Analysis vs. Domain Analysis

(b)(a)

In use case analysis, we consider the system as a “black box”

Use Case 1

Use Case 2

Use Case NActor

System

Actors

Use Case 1

Use Case 2

Use Case NActor

System

Actors

Actor

Domain Model

Actors

Actor

Domain Model

Actors

In domain analysis, we consider the system as a “transparent box”

Example: ATM Machine

(b)

(a)

12 34 5 67 8 90

12 34 5 67 8 90

Actor(Bank

customer)

System

Actor(Remote

datacenter)(ATM machine)

Concept 2

Concept 1

Actor

Concept 3

Concept n

Domain Model

Actor

Building Domain Model from Use CasesStep 1: Identifying the boundary concepts

Step 2: Identifying the internal concepts

Actor A

Actor B Actor D

Actor C

Boundary concepts

Concept 2Concept 2

Concept 3Concept 3

Concept 4Concept 4

Concept 1Concept 1

Actor A

Actor B

Actor C

Actor D

Concept 1Concept 1

Concept 2Concept 2

Internalconcepts

Concept 3Concept 3

Concept 5Concept 5

Concept 4Concept 4

Concept 6Concept 6

The Seven Deadly Sins in RE

• Noise• Irrelevant information• Confusing presentation

• Silence• Omissions

• Over-specification• Premature implementation decisions

• Contradiction• Inconsistency

• Ambiguity• Forward reference• Wishful thinking

Specification Qualities

• Clear, unambiguous, understandable• Consistent• Complete• Functional• Verifiable• Traceable• Easily changed

Examples: Wrong Specifications

• Example: "select" command in word processing.• ``Selecting is the process for designating areas of your document that you want to work on.

Most editing and formatting actions require two steps:first you select what you want towork on, such as text or graphics, then you initiate the appropriate action."

• Q: What is ambiguous?

• Example: Space shuttle monitoring system• ``The message must be triplicated. The three copies must be forwarded through three

different physical channels. The receiver accepts the message on the basis of a two-out-of-three voting policy."

• Q: What is not clear?

Classification of Specification Styles

• Formal or informal• Operational: describe the desired behavior.

• Data flow diagrams.• Finite state machines.• Petri nets.

• Descriptive: describe the desired properties.• Entity-relationship diagrams.• Logic specifications.• Algebraic specifications.

• Verification• Observing the dynamic behavior of the specified system.• Analyzing the properties of the specified system.

Structured Analysis

• Consists of -- Data Flow Diagram

-- Data Dictionary

-- Process Specification

Data Flow Diagram

• For business data processing, where control aspects may notplay significant role.

• Components• Function, or action:• Data store:• External entity:• Data flow:

• Conceptual Example:(a + b) * ( c + a * d)

+

*

* +

ba d c

Data Flow Diagram(Cont.)

• Example: Automatic Teller Machine(ATM)

Data Flow Diagram (Cont.)

• Drawback: • Cannot give a precise and detailed definition.• Cannot simulate the system with DFDs.• Extensions

• Integrate with different description, i.e., STD• Augment DFD with control flow, Ward&Mellor• Revise DFD, to make it fully formal.

Data Dictionary(1/2)

• Contains formal definitions of all the data items shown in DFD• Provides precise detail concerning the data entities• Format

-- Alphabetically ordered list of entries

-- Consists of formal definitions and verbal descriptions

• Notations:data-element-name = expression+ : concatenation| : alternatives

‘’ : literals[ ] : options{ } : repetitions

Data Dictionary(2/2)

• Example 1Payment = US-dollars | Korean-Wons

US-dollars = ‘$’ + dollar-amt + ‘.’ + cent-amt

* Payment is the income received from subscribers. It is entered as dollars and cents.

Korean-Wons = ‘w’ + …..

dollar-amt = {digit}

cent-amt = digit + digit

digit = 0|1|2|…..|9

UML

• Use case diagram• Sequence diagram• Class diagram• ….

Finite State Machine (FSM) (1/3)

• Emphasize control aspects of the application.• Components

• A finite set of states• A finite set of input• A transition function

FSM (2/3)

• Example: Producer/Consumer problem.

P1

C1

P2

210

C2

write

produce

consume

read

read read

write write

producer

consumer

buffer

FSM (3/3)

• Drawbacks;• Computation power is limited.• (Not easy to specify data info.)• The cardinality of the state space growth• Difficult to specify asynchronous activities.

Petri Net (1/5)

• Specify asynchronous systems• Components

• A finite set of places:• A finite set of transitions:• A finite set of arrows:

• from places to transitions,• from transitions to places.

• Tokens

Petri Net (2/5)

• Example: Producer/Consumer problem.

P1 P2

C1 C2

0 1 2

write

produce

consume

read

read

write write

read

Petri Net (3/5)

• Input places• preconditions• input data• input signals• resources needed• conditions• Transitions• events• computation step• signal processor• tasks or jobs• clause in logic

• Output places• postcondition• output data• output signal• resources released• conclusions

Petri Net (4/5)

• Modeling examples• Finite state machines.• Parallel activities.• Data flow computations.• Communication protocols.• Synchronous control.• Producer-consumer problem with priority.• Formal languages.

Petri Net (5/5)

• Drawbacks:• Too simple to specify complex systems.• Not possible to specify a selection policy.• Timing issues for real-time systems.

• Extensions:• Assigning values to tokens.• Specifying scheduling policies.• Incorporate timing constraints.

Nonfunctional Requirements• User interface & human factors• Documentation• Hardware consideration• Performance characterization• System interfacing• Quality issues• System modification• Physical environments• Security issues• Resources and management issues

Summary

• Remember that in the real world, no one will give you the exact, complete, consistent, and unambiguous requirements for software development.

• Requirements changes are inevitable• In addition to functional requirements, nonfunctional requirements are also important for value-added software development.

Exercise

• Think about Petri-net modeling of the following:* Multiprocessor systems with 5 processors, three common memories, and two buses

Summary

• Identifying requirements is the first, the most important step of software development.

• Requirement elicitation, specification, & verification• Various ways to specify

• UML diagrams,…