Lecture Requirement engineering Chapter 4 Requirement analysis

Lecture Requirement engineering Chapter 4 Requirement analysis. This chapter provides knowledge of data flow diagram, use case modelling and use case diagram. Lecture Requirement engineering Chapter 4 Requirement analysis. This chapter provides knowledge of data flow diagram, use case modelling and use case diagram.

DFD definition

DFD components

DFD Key definition

DFD level

Data flow diagram shows business processes and the data that flows between them

Data flow modeling takes a functional

decomposition approach to systems analysis, breaking complex problems into progressive levels of detail

The DFD is a diagram that consists principally

of four symbols, namely the external entity, the data flow, the process and the data store

Additionally, a physical flow can be shown on the DFD of the current system

External entity: are those things that are identified as needing to interact with the system under consideration

Gane and Sarson

Symbol DeMarco and Yourdan Symbol Example

Process: an activity that receives data and carries out some form of transformation or manipulation before outputting

Naming convention of a process:

 Name of a system

 Name of a subsystem

 A verb

Process: an activity that receives data and carries out some form of transformation or manipulation before outputting

Gane and

Sarson Symbol DeMarco and Yourdan Symbol

Data flow: Data move in a specific direction from an origin to a destination

Gane and Sarson

Symbol DeMarco and Yourdan Symbol

Data store: places where data may be stored

Gane and Sarson

Symbol DeMarco and Yourdan Symbol

Decomposition is the process of modeling the system and its components in increasing levels

of detail

Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD

DFDs exist in a hierarchy, beginning with the simplest, highest, system level and ending

with the lower level diagrams with detailed

Shows the context into which the business

process fits

Shows the overall business process as just one process

Shows all the outside entities that receive

information from or contribute information to the system

Context Diagram can be drawn by following steps:

 Step 1 - List the documents used in the system

 Step 2 - List all the sources & recipients

 Step 3 - Draw a box representing the system and show the flow of documents from these sources and recipients Those areas which are known to be inside the system are hidden within the box

Example

Shows all the processes that comprise the overall system

Shows how information moves from and to each process

Adds data stores

Shows all the processes that comprise a single process on the level 0 diagram

Shows how information moves from and to

each of these processes

Shows in more detail the content of higher

level process

Level 1 diagrams may not be needed for all

level 0 processes

 Shows all processes that comprise a single process

on the level 1 diagram

 Shows how information moves from and to each of these processes

 Level 2 diagrams may not be needed for all level 1 processes

 Correctly numbering each process helps the user understand where the process fits into the overall system

 Build the context diagram

 Create DFD fragments for each scenario

 Organize DFD fragments into level 0

 Decompose level 0 DFDs as needed

 Validate DFDs with user

Use case definition

Use case diagram

UML (Unified Modelling Language) provides a

common vocabulary of object-oriented terms and diagramming techniques that is rich

enough to model any systems development

project from analysis through implementation

Use cases are text stories that are useful for discovering and recording requirements

Use-case modeling is primarily an act of

writing text, not drawing diagrams

UML defines a use case diagram to illustrate the names of use cases and actors, and their relationships

Process Sale: A customer arrives at a checkout

with items to purchase The cashier uses the POS system to record each purchased item

The system presents a running total and item details The customer enters payment

line-information, which the system validates and records The system updates inventory The

customer receives a receipt from the system and then leaves with the items

A use case can be written in one of 3

 A fully-dressed use case has these sections:

 Use case name

 Success guarantee (postconditions)

 Main success scenario

Actor: something with behavior, outside the

system under discussion

Scenario: a specific sequence of actions and

interactions Sometimes called a use case

instance

Use case: a collection of related

success/failure scenarios

Primary actor: has a user goals filfilled

through using services of the systems

Supporting actor: provides service to the

system

Offstage: interested but not directly involved

Ex: the tax agency

Choose the system boundary

Identify primary actors

Identify goals for each primary actor

Define use cases in terms of user goals

The EBP (elementary business process) test:

 a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the

data in a consistent state, e.g Approve Credit or Price Order

A common use case mistake

 Defining many use cases at too low a levell that is

as a signle step, subfunction, or subtask within an EBP

The EBP (elementary business process) test:

 a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the

data in a consistent state, e.g Approve Credit or Price Order

A common use case mistake

 Defining many use cases at too low a levell that is

as a signle step, subfunction, or subtask within an EBP

Represents the scope of the subject, e.g., a system or an individual business process

Includes the name of the subject inside or

on top

System name

is a user or external system with which a system being modeled interacts

Are placed outside the system boundary

<<actor>>

Actor/Role

Represents a major piece of system functionality

Is placed inside the system boundary

Is labeled with a descriptive verb-noun phrase

Use case

Actor – Actor:

 Generalization : An actor may specialize multiple actors, and an actor may be specialized by multiple actors

Sinh viên

Sinh viên chưa tốt nghiệp Sinh viên đã

tốt nghiệp

Actor – Use case:

 Association : it

indicates that the actor communicates with

the system and

participates in the use case

Use case – Use case:

 Extend : the extension

use case will extend (or

be inserted into) and

augment the base use

case

base <<extend>> extending

Use case – Use case:

 Include : indicates that

the base use case will

include or call the

inclusion use case

base <<Include>> included

Đăng ký HP

Đăng nhập

Use case – Use case:

 Generalization :

address this situation

by factoring out and reusing similar

behavior from multiple use cases