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