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?
2019-03-13 CS350 Software Engineering, SoC, KAIST 3
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 4
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 5
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 6
Requirements Engineering Overview(3/7)
• 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
2019-03-13 CS350 Software Engineering, SoC, KAIST 7
Requirements Engineering Overview(4/7)
• 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
2019-03-13 CS350 Software Engineering, SoC, KAIST 8
Requirements Engineering Overview(5/7)
• 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?
2019-03-13 CS350 Software Engineering, SoC, KAIST 9
Requirements Engineering Overview(6/7)
Seven Deadly Sins• Noise
• Irrelevant information• Confusing presentation
• Silence• Omissions
• Over-specification• Premature implementation decisions
• Contradiction• Inconsistency
• Ambiguity
• Forward reference
• Wishful thinking
2019-03-13 CS350 Software Engineering, SoC, KAIST 10
Requirements Engineering Overview(7/7)
Specification Qualities
• Clear, unambiguous, understandable
• Consistent
• Complete
• Functional
• Verifiable
• Traceable
• Easily changed
2019-03-13 CS350 Software Engineering, SoC, KAIST 11
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:
2019-03-13 CS350 Software Engineering, SoC, KAIST 12
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 13
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 14
Conceptual Class vs. Software Artifacts
2019-03-13 CS350 Software Engineering, SoC, KAIST 15
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”
2019-03-13 CS350 Software Engineering, SoC, KAIST 16
Example: ATM Machine
(b)
(a)
12
345
67
890
12
345
67
890
Actor(Bank
customer)
System
Actor(Remote
datacenter)
(ATM machine)
Concept 2
Concept 1
Actor
Concept 3
Concept n
Domain Model
Actor
2019-03-13 CS350 Software Engineering, SoC, KAIST 17
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 18
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 19
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 20
Use Case Diagram for ATM
• Let us try• Identify actors, use cases, system boundary
2019-03-13 CS350 Software Engineering, SoC, KAIST 21
Top-level Use Cases
2019-03-13 CS350 Software Engineering, SoC, KAIST 22
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 23
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 24
Domain Model for an ATM & Bank
2019-03-13 CS350 Software Engineering, SoC, KAIST 25
Domain Model for an ATM & Bank
ATM in Bank Consortium
2019-03-13 CS350 Software Engineering, SoC, KAIST 26
Refined Class D.
2019-03-13 CS350 Software Engineering, SoC, KAIST 27
High Level Sequence Diagram
• You can have more SDs…
2019-03-13 CS350 Software Engineering, SoC, KAIST 28
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
• ….
2019-03-13 CS350 Software Engineering, SoC, KAIST 29
Structured Analysis
• Consists of
-- Data Flow Diagram
-- Data Dictionary
-- Process Specification
2019-03-13 CS350 Software Engineering, SoC, KAIST 30
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)
+
*
* +
b
ad c
2019-03-13 CS350 Software Engineering, SoC, KAIST 31
Data Flow Diagram(Cont.)
• Example:
Automatic Teller Machine(ATM)
2019-03-13 CS350 Software Engineering, SoC, KAIST 32
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 33
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 34
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 35
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 36
FSM (2/3)
• Example: Producer/Consumer problem.
P1
C1
P2
210
C2
write
produce
consume
read
read read
write write
producer
consumer
buffer
2019-03-13 CS350 Software Engineering, SoC, KAIST 37
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 38
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 39
Petri Net (2/4)
• Example: Producer/Consumer problem.
P1 P2
C1 C2
0 1 2
write
produce
consume
read
read
write write
read
2019-03-13 CS350 Software Engineering, SoC, KAIST 40
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 41
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.
2019-03-13 CS350 Software Engineering, SoC, KAIST 42
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 43
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
2019-03-13 CS350 Software Engineering, SoC, KAIST 44
Exercise
Try the following case study
and examples.
2019-03-13 CS350 Software Engineering, SoC, KAIST 45
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
2019-03-13 CS350 Software Engineering, SoC Fall 2017 47
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
2019-03-13 CS350 Software Engineering, SoC Fall 2017 48
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?
2019-03-13 CS350 Software Engineering, SoC Fall 2017 49
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?
2019-03-13 CS350 Software Engineering, SoC, KAIST 50
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?
2019-03-13 CS350 Software Engineering, SoC, KAIST 51