software engineering 2007/2008 chapter 4 capturing the requirements

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