Upload
jordan-booth
View
229
Download
0
Tags:
Embed Size (px)
Citation preview
2007/2008 Software Engineering
Chapter 4
Capturing the Requirements
Learning objectives
Explain why it is necessary to elicit requirements from software customers, and the role of requirements in the software life-cycle
Identify the characteristics that make individual requirements good or bad;
Describe the types of requirements that should be included in a requirements document;
Describe the notations and methods that can be used for capturing requirements
Explain how and why requirements reviews should be done to ensure quality
Describe how to document requirements for use by the design and test teams
4.1 THE REQUIREMENTS PROCESS
requirement A requirement is an expression of desired( 渴望的 ) b
ehavior The goal of the requirements phase is to understand t
he customer’s problem and needs During the specification phase, we will decide which r
equirements will be fulfilled(履行 ) by our software system;
During the design phase, we will devise a plane for how the specified behavior will be implemented
The person performing requirement tasks usually is called requirements analyst or systems analyst
4.1 THE REQUIREMENTS PROCESS
Process for capturing the requirements,
FIGURE 4.1 Process for capturing the requirements
引出 分析 详述 确认
4.2 REQUIREMENTS ELICITATION
Requirements elicitation is an especially critical part of the process. We must use a variety of techniques to determine what the users and customers really want.It is only by discussing the requirements with everyone who has a stake in the system, coalescing( 接合 ) these different views into a coherent( 粘在一起的 , 一致的 , 连贯的 ) set of requirements and reviewing these documents with these stakeholders that we all come to an agreement about what the requirement are.
So who are the stakeholders( 股东 ) Clients Customer Users Domain experts Market researc
hers Lawyer or auditors Software engineers
4.3 TYPE OF REQUIREMENTS
functional requirement describes requirement behavior in terms of required activities.
A quality requirement, or nonfunctional requirement, describes some quality characteristic that the software solution must possess.
A design constraint( 约束 ) is a design decision that has already been made and that restricts( 限制 , 约束 ) the set of solutions to our problem.
A process constraint is a restriction on the techniques or resource that can be used to build the system.
4.3 TYPE OF REQUIREMENTS
1. Resolving( 分解 ) Conflicts( 冲突 ) Requirements that absolutely must be met Requirements that are highly desirable (合意的)
but not necessary Requirements that are possible but could be eliminat
ed (消灭)2. Two Kinds of Requirements Documents A requirements definition is a complete listing of e
verything the customers wants to achieve. The requirements specification restates( 重申 ) the re
quirements as a specification of how the proposed system shall behave
4.4 CHARACTERISTICS OF REQUIREMENTS
Correct (正确的 ) Consistent ( 可靠的 ) Unambiguous ( 不含糊的 , 明确的 ) Complete (全部的 ) Feasible (切实可行的 ) Relevant ( 合乎逻辑、精确的 ) Testable (可测试的 ) Traceable (可追踪的 )
4.5 MODELING NOTATIONS
1. Entity-Relationship Diagrams (实体 -关系图 ) Entity-Relationship Diagrams is a popular graphical notio
nal paradigm for representing conceptual models
FIRURE 4.4 Entity-relationship diagram of turnstile problem
4.5 MODELING NOTATIONS
2. Example: UML Class Diagrams
FIGURE 4.5 UML class model of the library problem
4.5 MODELING NOTATIONS
3. Event Trances An event trance is a graphical description of a
sequence of events that are exchanged between real-
world entities
FIGURE 4.6 Event traces in the turnstile problem
4.5 MODELING NOTATIONS
4. Example: Message Sequence Chart Message Sequence Charts are an enhanced event-
trance notation
FIGURE 4.7 Message Sequence Chart for library loan transaction
4.5 MODELING NOTATIONS
5. State Machines A state machine is a graphical description of all dialog
between the system and its environment.
FIGURE 4.8 Finite-state model of the turnstile problem
4.5 MODELING NOTATIONS
6. Example:UML Statechart Diagrams UML Statechart diagrams depicts the dynamic behavior of
the objects in a UML class
FIGURE 4.9 UML statechart diagram for the publication class
4.5 MODELING NOTATIONS
7. Example: Petri Nets Petri Nets are a form of state-transition notation that is
used to model concurrent activities
FIGURE 4.12 Petri net of book loan
4.5 MODELING NOTATIONS
8. Data Flow Diagrams a data-flow diagram(DFD)models functionality and
the flow of data from one function to another
FIGURE 4.14 Data-flow diagram of the library problem
4.5 MODELING NOTATIONS
9. Example: Use Cases UML use-cases diagram is similar to a top-level data-fl
ow diagram that depicts observable, user-initiated( 发起 )functionality in terms of interactions between the system and its environment.
FIGURE 4.15 Library use cases
4.8 REQUIREMENTS DOCUMENTATION
① Requirements Definition First,we outline(略述 ) the general purpose and scope of the system Next, we describe the background and the rationale behind the pr
oposal for a new system Once we record this overview of the problem, we describe the es
sential(实质性的 ) characteristics of an acceptable solution. As part of the problem’s context, we describe the environment in
which the system will operate If the customer has a proposal for solving the problem, we outlin
e a description of the proposal Finally we list any assumptions( 设想 ) we make about how the en
vironment behaves
4.8 REQUIREMENTS DOCUMENTATION
② Requirements Specification In documenting the system’s interface,we describe
all inputs and outputs in detail Next,we restate( 重申 ) the required functionality in
terms of the interfaces’ inputs and outputs Finally, we devise fit criteria( 标准 ) for each of the
customer’s quality requirements,so that we can conclusively( 最后的 ) demonstrate( 范例 ) whether our system meets these quality requirements
4.8 REQUIREMENTS DOCUMENTATION
③ Process Management and Requirements Traceability
The requirements that define what the system should do
The design modules that generated from the requirements
The program code that implements the design The tests that verify the functionality of the system The documents that describe the system
4.9 REQUIREMENTS VALIDATION
① Requirements Validation (确认 ) Correct (正确的 ) Consistent ( 可靠的 ) Unambiguous ( 不含糊的 , 明确的 ) Complete (全部的 ) Feasible (切实可行的 ) Relevant ( 合乎逻辑、精确的 ) Testable (可测试的 ) Traceable (可追踪的 )
4.9 REQUIREMENTS VALIDATION
②What does the requirements review entail( 必要性 )? We review the stated goals and objectives of the sys
tem. We compare the requirements with the goals and obj
ectives to verify that all requirements are necessary We review the environment in which the system is t
o operate, examining the interfaces between our proposed system and all other system and checking that their descriptions are complete and correct
4.9 REQUIREMENTS VALIDATION
The customer’s representatives review the information flow and the proposed functions, to confirm that they accurately reflect the customer’s needs and intention. Our representatives review the proposed functions and constraints, to confirm that they are realistic and within our development abilities. All requirements are checked again for omission(遗漏 ), incompleteness, and inconsistency .
If any risk is involved in the development or in the actual functioning of the system, it is assessed and documented. We discuss and compare alternatives, and we and our customer agree on the approaches to be used.
We talk about testing the system. How will the requirements continue to be verified and validated as development progresses (and requirements change and grow)? Who will provide the test data? If the system is to have a phased implementation, how will the requirements be checked during the intermediate phases?
4.9 REQUIREMENTS VALIDATION
③ Verification
we want to check that our requirement-specification document corresponds( 符合 ) to our requirements-definition document