Software Engineering 2007/2008 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( 渴望的 ) behavior The goal of the requirements phase is to understand the customer’s problem and needs During the specification phase, we will decide which requirements 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 researchers 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 eliminated （消灭） 2. Two Kinds of Requirements Documents A requirements definition is a complete listing of everything the customers wants to achieve. The requirements specification restates( 重申 ) the requirements 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 notional 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- flow 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 proposal for a new system  Once we record this overview of the problem, we describe the essential ( 实质性的 ) 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 outline a description of the proposal  Finally we list any assumptions( 设想 ) we make about how the environment 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 system.  We compare the requirements with the goals and objectives to verify that all requirements are necessary  We review the environment in which the system is to 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