THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM-Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm pdf

1
THI
THI
Ế
Ế
T K
T K
Ế
Ế
V
V
À
À
XÂY D
XÂY D
Ự
Ự
NG PH
NG PH
Ầ
Ầ
N M
N M
Ề
Ề
M
M
(SOFTWARE DESIGN AND CONSTRUCTION)
(SOFTWARE DESIGN AND CONSTRUCTION)
Năm
Năm

h
h
ọ
ọ
c
c
2008
2008
-
-
2009
2009
Giáo viên: PGS. Huỳnh QuyếtThắng
BM Công nghệ phầnmềm
Khoa CNTT, ĐHBK HN
2
Chương 1. Tổng hợpvàphântíchcácyêucầuphầnmềm
1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
2. Phát hiệncácyêucầuphầnmềm (Software Elicitation)
3. Phân tích yêu cầuphầnmềm và xây dựng các đặc tính xác
định chấtlượng yêu cầu và các yêu cầukhác
4. Đặctả các yêu cầuphầnmềm
5. Xác định nguồngốcyêucầuvàma trận theo dõi các yêu
cầuphầnmềm
6. Thẩm định xác minh các yêu cầuphầnmềm (verification
requirement)
7. Quảnlýthayđổiyêucầuphầnmềm
3
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác

Requirements Analysis:
z Detect and resolve conflicts between requirements
z Discover the bounds of the software and how it must
interact with its environment
z Elaborate system requirements to derive software
requirements
4
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
Requirements Analysis (KPAs):
z Requirements Classification
z Conceptual Modeling
z Architectural Design and Requirements Allocation
z Requirements Negotiation
5
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(1) Requirements Classification
6
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
z Functional software requirements
• Functional requirements express how the system
behaves. These requirements are usually action
oriented
z Nonfunctional software requirements:
• Usability
• Reliability
• Performance
• Supportability

z Design constraints:
• Typically impose limitations on the design of the
system or the processes we use to build a system
7
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(2) Conceptual Modeling
z The development of models of a real-world problem is key
to software requirements analysis. Their purpose is to aid in
understanding the problem, rather than to initiate design of
the solution. Hence, conceptual models comprise models of
entities from the problem domain configured to reflect their
real-world relationships and dependencies.
z Several kinds of models can be developed. These include
data and control flows, state models, event traces, user
interactions, object models, data models, and many others.
8
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(2) Conceptual Modeling
z Several kinds of models can be developed. The factors that
influence the choice of model include:
• The nature of the problem. Some types of software
demand that certain aspects be analyzed particularly
rigorously.
• The expertise of the software engineer. It is often more
productive to adopt a modeling notation or method with
which the software engineer has experience.
• The process requirements of the customer.
• The availability of methods and tools.

9
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(3) Architectural Design and Requirements Allocation
z At some point, the architecture of the solution must be
derived. Architectural design is the point at which the
requirements process overlaps with software or systems
design, and illustrates how impossible it is to cleanly
decouple the two tasks.
z In many cases, the software engineer acts as software
architect because the process of analyzing and elaborating
the requirements demands that the components that will be
responsible for satisfying the requirements be identified.
This is requirements allocation–the assignment, to
components, of the responsibility for satisfying
requirements.
10
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(3) Architectural Design and Requirements Allocation:
z Allocation is important to permit detailed analysis of
requirements. Hence, for example, once a set of
requirements has been allocated to a component, the
individual requirements can be further analyzed to discover
further requirements on how the component needs to
interact with other components in order to satisfy the
allocated requirements. In large projects, allocation
stimulates a new round of analysis for each subsystem.
z Iterating Requirements and Design
z Using Parent-Child Requirements to Increase Specificity

11
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(3) Architectural Design and Requirements Allocation:
z Architectural design is closely identified with conceptual
modeling. The mapping from real-world domain entities to
software components is not always obvious, so architectural
design is identified as a separate topic. The requirements of
notations and methods are broadly the same for both
conceptual modeling and architectural design.
z IEEE Std 1471-2000, Recommended Practice for
Architectural Description of Software Intensive Systems,
suggests a multiple-viewpoint approach to describing the
architecture of systems and their software items.
12
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(4) Requirements Negotiation
z Another term commonly used for this sub-topic is ‘conflict
resolution’. This concerns resolving problems with
requirements where conflicts occur between two
stakeholders requiring mutually incompatible features,
between requirements and resources, or between functional
and non-functional requirements, for example.
13
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
(4) Requirements Negotiation
z In most cases, it is unwise for the software engineer to make
a unilateral decision, and so it becomes necessary to consult

with the stakeholder (s) to reach a consensus on an
appropriate trade-off. It is often important for contractual
reasons that such decisions be traceable back to the
customer. We have classified this as a software
requirements analysis topic because problems emerge as the
result of analysis. However, a strong case can also be made
for considering it a requirements validation topic.
14
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
Using the Use Cases
z To support the design and coding activities, the use cases
developed in the elicitation activities must be more fully
elaborated.
z Use cases are most appropriate when the system is rich in
functionality and must support differing types of users.
z Use cases are not as effective when applied to systems with
few or no users and minimal interfaces, those with mostly
nonfunctional requirements, and design constraints.
15
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
Các đặc tính chấtlượng đốivớingườisử dụng:
Availability (đáp ứng)
Efficiency (hiệuquả)
Flexibility (mềmdẻo)
Integrity (bảomật)
Interoperability (khả năng kếthợpvớihệ thống)
Realibility (tin cậy)
Robustness (khả năng kiểm soát các dữ liệu không

chính xác)
Usability (dễ sử dụng)
16
1.3. Phân tích các yêu cầuphầnmềmvàxâydựng các đặc
tính xác định chấtlượng yêu cầu và các yêu cầukhác
Các đặc tính chấtlượng đốivớingườipháttriển:
Maintainability (bảodưỡng)
Portability (hiệuquả)
Reusability (mềmdẻo)
Testability (bảomật)
z Tổng hợpcó12 thuộc tính chấtlượng
z Cầnphảicânbằng các thuộctínhchấtlượng