CS350 Lecture 3 Requirements...

CS350 Lecture 2 Requirements Engineering

Doo-Hwan Bae

bae@se.kaist.ac.kr

Contents

• Overview of Requirements Engineering

• OO Analysis: Domain modeling, Use-case, sequence, class

• Structured Analysis: Dataflow diagraming

• Finite State Machines: State transition diagraming

• Petri-Nets: control/operational

2019-03-13 CS350 Software Engineering, SoC, KAIST 2

Importance of Requirements (1/2)

• Problem: Sorting a given list of numbers in ascending order.

In order to solve it, answer the following questions

• Is the given problem statement sufficient to develop a program?

• If not, what additional information do we need to know?

Importance of Requirements (2/2) in SW Development ProjectsSome advices from industry practitioners• Do not make assumptions as to the user/customer’s needs, ask them.

• Involve the end users as soon as possible, get in touch with the actual people that will be using the software on a daily basis, they are the ones that truly understand what Is needed.

• Scope creep is major issue in most project, especially custom development. A clear and defined scope is going to save a lot of headaches for all involved in the long run.

• A great way to show a customer what you envision is with a prototype.

• A well written, clear and easy to follow documentation of the requirements is essential and before they sign off, go over it with the customer

• It is important to understand the environment in which the software will run

Requirements Engineering Overview (1/7)

• Must state what to do, not how to do.

• Identify the qualities required for the application.

• Functional and nonfunctional

• Used by both customer and designers

Requirements Engineering Overview(2/7)

• Three steps in RE• Requirements Elicitation (gathering and analysis)

-- understand/analyze 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.

• 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

• Separate functional requirements into three views:• A model of data/static structure:

• Entity relationship diagrams, domain model (class diagram)

• A model of function:

• Data flow diagrams, use case diagram

• A model of control:

• Control flow diagrams, State Machines, Petri nets, sequencediagram

• 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?

Seven Deadly Sins• 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

Specification Methods

• Representative methods:• OO Analysis: object-oriented

• Domain/Class, , Use-case, Sequence diagram

• Structured Analysis: • Dataflow diagram, Data dictionary

• Finite State Machines: • State transition diagram

• Petri-Nets:

Domain Modeling

• 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? —We do domain modeling based on the following sources:• Knowledge of how system-to-be is supposed to behave (from requirements analysis,

e.g., use cases)

• Studying the work domain (or, problem domain)

• Knowledge base of software designs

• Developer’s past experience with software design

Domain Modeling

• What?• Illustrates meaningful conceptual classes in a problem domain

• Is a representation of real-world concepts, not software artifacts

• Is the most important objects/classes in OO development• 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

Domain Model

Actors

Domain Model

Actors

In domain analysis, we consider

the system as a “transparent box”

Example: ATM Machine

Actor(Bank

customer)

System

Actor(Remote

datacenter)

(ATM machine)

Concept 2

Concept 1

Concept 3

Concept n

Domain Model

Building Domain Model from Use Cases

Step 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

Internal

concepts

Concept 3Concept 3

Concept 5Concept 5

Concept 4Concept 4

Concept 6Concept 6

Initial ATM Requirements ( Problem )

• A customer uses a bank ATM for checking balances of bank accounts, depositing funds, withdrawing cashes, and transferring funds.

• A bank ATM consists of a keypad, screen, cash dispenser, ATM card reader, cash deposit slot.

• A user can have a checking account and saving account.• A customer enters his/her card and password for authentication and then choose a transaction to be executed. After the transaction is over, the ATM returns the card and receipt, and stores the transaction for bookkeeping.

• Once the request from the ATM is passed, the bank checks the account and process a requested transaction and update the account.

Identify Use Cases

• Identify actors first• Actor: a person/thing that initiate actions to a system or receives results of actions

from the system

• Use cases are “Why the customer goes to the ATM?”

• Find action terms from the initial requirements• Check balances• Deposit funds• Withdraw cashes• Transfer funds• Enters card/password• Authenticate• Choose a transaction• Return a card..• Check, process, update

Use Case Diagram for ATM

• Let us try• Identify actors, use cases, system boundary

Top-level Use Cases

Identify the classes

• Identify all the nouns or noun phrases.Customer, bank, ATM, (bank) account, funds, cash, keypad, screen, cash dispenser, cash deposit slot, user, checking account, saving account, card, password, transaction, receipt, bookkeeping, request.

• Eliminate redundant, irrelevant, implementation constructs, attributes, etc.

Initial Class Diagram (Domain Model)

• Objects: ATM, Keypad, Deposit slot, Cash dispenser, Screen, Transaction, Bank, Account, Customer

• Draw a class diagram with only classes and relationships

Domain Model for an ATM & Bank

ATM in Bank Consortium

Refined Class D.

High Level Sequence Diagram

• You can have more SDs…

Refining Diagrams

• Now we have• Use case diagram

• Initial class diagram (domain diagram)

• Sequence diagram

• Once, the initial requirements analysis/specification is over, refining those diagrams until ..

• Then, verify the results

• Also, identify Non-functional requirements

• ….

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)

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 1

Payment = 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

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.

produce

consume

read read

write write

producer

consumer

buffer

FSM (3/3)

• Drawback;• 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/4)

• 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/4)

• Example: Producer/Consumer problem.

produce

consume

write write

Petri Net (3/4)

• Modeling examples• Finite state machines.

• Parallel activities.

• Data flow computations.

• Communication protocols.

• Synchronous control.

• Producer-consumer problem with priority.

• Formal languages.

Petri Net (4/4)

• Drawback:• 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.

• Also requirements document will be used as a contract

• Requirements changes are inevitable. Be prepared!

• In addition to functional requirements, nonfunctional requirements are also important

• for value-added software development

Exercise

Try the following case study

and examples.

Requirements Engineering: Case Study(1/4)• University’s library want to ‘automate its operations’ by SW.

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.

• Starting with the above statements, you are expected to specify its requirements.

2019-03-13 CS350 Software Engineering, SoC Fall 2017 46

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

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

Solution to it:

-- Duplicating each card a number of times

-- Use database

• During Requirements Analysis, a number of user R’s can 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)• 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?

Examples: Wrong Specifications(1/2)

• 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."

• Q: What are 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?

Examples: Wrong Specification(2/2)

• Example: A text editor• ``The whole text should be kept in lines of equal length, with the

length specified by the user. Unless the user is given an explicithyper-nation command, a carriage return should occur only at theend of a word."

• Q: What is inconsistent?

CS350 Lecture 3 Requirements...

Documents

CD3403 CS350 User Manual

Aritech CS350 & CD3412 User Manual Guide

CS350 Operating Systemsali/cs350-f19/synch.pdfReview: Processes Aprocessisaninstanceofarunningprogram-Athreadisanexecutioncontext-Processcanhaveoneormorethreads-Threadsshareaddressspace(code,data,heap),openfiles

CS350/550 Software Engineering

CS350 CD3412 User Manual

Life’s Best Advices 'Arabic

Welcome to Bowdoin | Bowdoin Collegeltoma/teaching/cs350/spring06/Lecture-Handout… · ±=0¥ 1 < % 0-, # $ :

Services for Solicitors · IHT advices Charities Duties and personal liability of Trustees VAT advices Financial reviews Pensions Advices regarding implications of Bankruptcy ‘Your

BPP_Reprint Payment Advices

TEN ADVICES OF

CS350 Lecture 0 - KAISTse.kaist.ac.kr/wp-content/uploads/2018/08/CS350-Lecture-0-v2.pdf · • Do you have any evidence for why or why not it is important? 2018-08-27 CS350 Software

Banks Advices April2012

CS350 Lecture 3 Requirements Engineeringse.kaist.ac.kr/wp-content/uploads/2019/09/CS-350-Lecture...CS350 Lecture 2-1 Requirements Engineering 1 Doo-Hwan Bae School of Computing, KAIST

Priceless Advices - Askimam

Life’s Best Advices

Retrospectives Advices

CS350 CH06 Non Binary Trees

Aritech CS350 Installation Instructions

CS350 Lecture 0se.kaist.ac.kr/wp-content/uploads/2017/12/cs350-Lecture... · 2018-02-25 · CS350 Lecture 0: Overview Spring 2018 Doo-Hwan Bae. School of Computing. bae@se.kaist.ac.kr

Sustainability Advices