Requirements Engineering

• 교과목명: 소프트웨어공학

• 해당 주차: 6-2

• 동국대학교 조영석

이 문서는 나눔글꼴로 작성되었습니다. 설치하기

2

Requirements Modeling

Flow-oriented modeling Data flow diagram (DFD)

1ANALYZE-

OLD-SYSTEM

3CODE-AND-

TEST-SYSTEM

2DESIGN-

NEW-SYSTEM

REQUEST-FOR-NEW-SYSTEM

PROBLEM-SPECIFICATION

DESIGN-SPECIFICATION

FINISHED-SYSTEM

Data Flow w/ Data Item and data flow direction

Process: functionality

3

Requirements Modeling

Flow-oriented modeling Data flow diagram (DFD)

1ANALYZE-

OLD-SYSTEM

3CODE-AND-

TEST-SYSTEM

2DESIGN-

NEW-SYSTEM

REQUEST-FOR-NEW-SYSTEM

PROBLEM-SPECIFICATION

DESIGN-SPECIFICATION

FINISHED-SYSTEM

Build-New-System

Request-for-New-System

Finished-System

DFD above is partitioned as DFD below.

DFD on the left will be created as the draft Structure Chart during the design phase.

Build-New-System

Code-and-Test-System

Design-New-System

Analyze-Old-System

Partitioning continues until the further partition is meaningless.

4

Requirements Modeling

Flow-oriented modeling Data flow diagram (DFD) Divide and Conquer

– Processes are partitioned according to the level of abstraction. Labels (Names) for each Data Flow must be defined in the Data

Dictionary prior to be attached. The sequence of execution for each Process is NOT considered

when DFDs are created. – Leave it for the design phase. – Decide as late as possible!

Focus on the flow of data first, then describe activities to be accomplished in each Process.

5

Requirements Modeling

Flow-oriented modeling Data flow diagram (DFD) Symbols used to create DFD

NAME SYMBOL ALTERNATE FORMS

Terminator symbol

Data store symbol

or

Process symbol

Data flow symbol DATA-FLOW-NAME

TERMINATOR- NAME

FILE-

NAME

1

PROCESS-NAME

TERMINATOR- NAME

1

PROCESS-NAME

File

Name

File

Name

6

Requirements Modeling

Structured Language Use of predefined structured elements from programming

languages: IF-THEN-ELSE, FOR, WHILE, etc. Programming language independent Easier to express Easier to read Can be standardized Example:

IF (input is an odd number) THEN increase by 1; ELSE multiply by 2;

7

Requirements Modeling

Prototyping Not a working system Shows the final system Good method to define and confirm requirements Users can see the shape of the final system Users confirm whether the system is what they really

want Developers confirm what system they exactly build The best way of communication between users and

developers

8

Requirements Validation

Requirements validation Requirements must be consistent with system objectives. Each requirements must be consistent with each other. All requirements must be completely specified. Missing requirements will cause problems in later phases.

Remove ambiguities. All requirements must be achievable technically. Is the use of models adequate? Are all requirements verifiable?

9

Domain Analysis

Domain analysis Analyze the domain of the system being built. Collect requirements required by domain. For example, response time for real-time systems

Users often do not recognize or state domain requirements.

10

Requirements Management

Requirements management Requirements must be complete and consistent. New requirements may be introduced during the software

processes. Business environment changes Social changes Technological changes Customer requirements changes

Traceablility – Relationships and/or links between requirements must be kept and maintained.

Requirements from different stakeholders may be contradictory. Therefore, requirements must be negotiated.

11

Specification with Natural Language

Easy and natural way of requirements description, BUT Problems in specification with a natural language exist. Not clear Low precision Difficult to read

Causes confusion Functional and non-functional requirements may be mixed up.

Inappropriate grouping of requirements More than one requirements may be described in a statement.

Mixed level of abstraction Higher level of abstraction for some parts and lower level of

abstraction for other parts

이 문서는 나눔글꼴로 작성되었습니다. 설치하기

감사합니다.