软件工程专业英语_Unit 02 Capturing the Requirements 需求获取

1、Unit 2 Capturing the Requirements需求获取Contents Part 1 Listening and Speaking Dialogue: Communication with Customers Listening Software Requirements Dictation: The Difference between Customer and End-User Part 2 Reading and Translating Section A: Software Requirements Section B: Use Cases and Scenario

2、s Part 3 Simulated Writing: Software Requirements 1.1 Dialogue: Communication with Customers Exercises Work in a group, and make up a similar conversation by replacing the statements with other expressions on the right side. 1.1 Dialogue: Communication with Customers Words draftdrft v. 起草，制定 bookbuk

3、 v. 登记，预订 refundrifnd v. 退还，偿还 depositdipzit n. 押金，预付金 modelmdl v. 建立模型 scenariosnriu n. 场景，某一特定情节 distinctivedistiktiv adj. 区别性的，特殊的 criterionkraitirin n. 标准，准则（复数为criteria） 1.1 Dialogue: Communication with Customers Phrases check in 登记，记录，报到 deal with 处理 up to （时间上）一直到 high season旺季 low season淡季 A

4、bbreviations VIP Very Important Person 重要人物，大人物1.1 Dialogue: Communication with Customers1.2 Listening Comprehension: Software Requirements Listen to the article and answer the following 3 questions based on it. After you hear a question, there will be a break of 15 seconds. During the break, you wi

5、ll decide which one is the best answer among the four choices marked (A), (B), (C) and (D).1.2 Listening Comprehension: Software Requirements Questions1. Which is the correct order of key steps in the software requirements stage according to this article?(A) Inception, elicitation, elaboration, nego

6、tiation, and validation(B) Elicitation, inception, elaboration, negotiation, and validation(C) Inception, elicitation, negotiation, elaboration, and validation(D) Elicitation, inception, negotiation, elaboration, and validation1.2 Listening Comprehension: Software Requirements Questions2. In which s

7、tep are requirements further expanded into an analysis model?(A) Negotiation (B) Validation(C) Elaboration (D) Specification1.2 Listening Comprehension: Software Requirements Questions3. In which steps should software team work with other stakeholders in the software requirements stage?(A) Inception

8、, negotiation, specification, and validation(B) Inception, elicitation, specification and validation(C) Inception, elicitation, negotiation, and validation(D) Inception, elaboration, negotiation, and specification1.2 Listening Comprehension: Software Requirements Words conductkndkt v. 实施，进行 genericd

9、nerik adj.一般的，普通的 distinctdistikt adj. 不同的，有区别的inceptioninsepn n. 开端 elicitationilisitein n. 导出，启发1.2 Listening Comprehension: Software Requirements Words elaborationilbrein n. 精化 overridinguvraidi adj. 首要的，压倒一切的 facilitate fsiliteit v. 使容易，使便利，促进 classkls n. 类 referencerefrns v. 把引作参考，引用1.3 Dictati

10、on: The Difference between Customer and End-User This article will be played three times. Listen carefully, and fill in the numbered spaces with the appropriate words you have heard. 1.3 Dictation: The Difference between Customer and End-User Words fundingfndi n. 提供资金 1.3 Dictation: The Difference b

11、etween Customer and End-User Phrases on the contrary 正相反 2.1 Section A: Software Requirements Words capturekpt(r) v. 获得，捕获 validationvlidein n. 验证，确认 specifyspesifai v. 详细说明，指定 Words interestintrst; intrest v. 使感兴趣，使参与 contextkntekst n. 上下文，环境，背景 documentdkjumnt v. 记录，纪实性地描述 performancepfmns n. 性能，业

12、绩，工作情况2.1 Section A: Software Requirements Phrases use case 用例2.1 Section A: Software Requirements Exercises I. Read the following statements carefully, and decide whether they are true (T) or false (F) according to the text. 1. Software requirements specification should accurately capture the clien

13、ts requirements and form the basis of software development and validation. 2. The goal of requirements validation is to understand such different aspects as the requirements of the problem, its context, and how it fits within the clients organization. 3. The model and the prototype are both useful f

14、or the correctness and completeness of requirements. 2.1 Section A: Software Requirements 4. The use case approach has become one of the most popular methods for specifying the functional specifications. 5. In requirements inspections, the representative of the client is responsible for ensuring tha

15、t all requirements are captured.2.1 Section A: Software Requirements II. Choose the best answer to each of the following questions according to the text.1. Which statement is wrong about the SRS?(A) It is the most important product in the requirements phase.(B) The most direct reason for the difficu

16、lty in SRS is the diversity of the parties involved.(C) A good SRS should specify not only all the functions of the software, but also other non-functional requirements.(D) SRS should be inspected by the team of reviewers.2.1 Section A: Software Requirements 2. Which statement is right about the act

17、ivity of requirement analysis?(A) Prototype is a theoretic design to validate the correctness and completeness of requirements.(B) During this activity, the understood problem is specified and written in SRS.(C) There are three main different approaches for modeling. (D) The main objective of this a

18、ctivity is to understand the problem.2.1 Section A: Software Requirements 3. Which statement is wrong about the use case approach?(A) Use cases specify the functionality of the system.(B) Use cases can be used for different basic activities in the requirements phase.(C) Each use case consists of man

19、y normal scenarios and many exceptional scenarios.(D) Use case occurs when a user interacts with the system for achieving some goal.2.1 Section A: Software Requirements IV. Translate the following passage into ChineseNon-functional requirementsNon-functional requirements are sometimes defined in ter

20、ms of metrics (i.e. something that can be measured about the system) to make them more tangible. Non-functional requirements may also describe aspects of the system that dont relate to its execution, but rather to its evolution over time (e.g. maintainability, extensibility, documentation, etc.).Non

21、-functional requirements are not straightforward requirement of the system, rather it is related to usability (in some way). For example, for a banking application, a major non-functional requirement will be available where the application should be available 24/7 with no downtime if possible.2.1 Se

22、ction A: Software Requirements 2.2 Section B: Use Cases and Scenarios Words laundry-list 细目清单 fictitiousfiktis adj. 虚构的，假想的，编造的 actorkt(r) n. 角色，行动者 agnosticnstik adj. 不可知论的，怀疑的 overdueuvdju adj. 过期的，迟到的 end-to-end 端到端 drill-down 深度探讨 artifacttifkt n. 人工制品，手工艺品 2.2 Section B: Use Cases and Scenarios

23、 Words fulfillfulfl v. 实现 enumerationinjumrein n. 列举事实，逐条陈述 free-form 自由形态的，结构不规则的 narrativenrtiv n.& adj. 叙述，故事，讲述的 discretediskrit adj. 离散的，不连续的 conveyknvei v. 传达 2.2 Section B: Use Cases and Scenarios Words fully-fledged 完善的，成熟的，羽毛丰满的 namelynemli adv. 也就是，即是，换句话说 pre-condition 前置条件，先决条件 post-

24、condition 后置条件 variantverint n. 变体，转化 2.2 Section B: Use Cases and Scenarios Phrases test case 测试用例 business scenario 业务场景，业务方案 with the advent of 随着的出现 Agile Methodologies 敏捷方法论，敏捷开发方法 Abbreviations UML Unified Modeling Language 统一建模语言2.2 Section B: Use Cases and Scenarios 2.2 Section B: Use Cases

25、and Scenarios Exercises I. Read the following statements carefully, and decide whether they are true (T) or false (F) according to the text.1. Business Use Case is also known as an Implementation Use Case.2. System Use Case is also known as an Abstract-Level Use Case.3. Use case diagrams contain bot

26、h the external entities that will be using the system (or goals) and the discrete use cases (also known as actors) that the users will be carrying out. 2.2 Section B: Use Cases and Scenarios4. Use cases typically are not a good way of defining non-functional requirements such as technical requiremen

27、ts or system qualities. 5. Unlike a scenario which is a step-by-step enumeration of the tasks carried out during a process (with the associated actors), a use case is much more free-form. 2.2 Section B: Use Cases and ScenariosII. Choose the best answer to each of the following questions according to

28、 the text.1. How many levels of use cases can be described?(A) One (B) Two (C) Three (D) Four2. In which of the following language are use case diagrams typically represented? (A) UML(B) C+(C) Python(D) Java 2.2 Section B: Use Cases and Scenarios3. Which of the following description is not right?(A)

29、 A user story is typically a narrative that describes how a user would experience the functionality of the system.(B) A use case is a definition of a specific business objective that the system needs to accomplish.(C) Use cases typically are not a good way of defining non-functional requirements suc

30、h as technical requirements or system qualities.(D) System Use Case is also known as an Abstract-Level Use Case. 2.2 Section B: Use Cases and Scenarios IV. Translate the following passage into Chinese. UML UML, short for Unified Modeling Language, is a standardized modeling language consisting of an

31、 integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. 2.2 Section B: Use Cases and ScenariosThe UML represents a coll

32、ection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software proje

33、cts. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.3. Simulated Writing: Software Requirements Software Requirements SpecificationThe requirements specification covers exactly the same ground as the requirements defini

34、tion, but from the perspective of the developers. Where the requirements definition is written in terms of the customers vocabulary, referring to objects, states, events, and activities in the customers world, the requirements specification is written in terms of the systems interface. We accomplish

35、 this by rewriting the requirements so that they refer only to those real-world objects (states, events, actions) that are sensed or actuated by the proposed system:3. Simulated Writing: Software Requirements(1) In documenting the systems interface, we describe all inputs and outputs in detail, incl

36、uding the sources of inputs, the destinations of outputs, the valve ranges and data formats of input and output data, protocols governing the order in which certain inputs and outputs must be exchanged, window formats and organization, and any timing constraints. Note that the user interface is rare

37、ly the only system interface; the system may interact with other software components (e.g. a database), special-purpose hardware, the Internet, and so on.3. Simulated Writing: Software Requirements(2) Next, we restate the required functionality in terms of the interfaces inputs and outputs. We may u

38、se a functional notation or data-flow diagrams to map inputs to outputs, or use logic to document functions pre-conditions and post-conditions. We may use state machines or events traces to illustrate exact sequences of operations or exact orderings of inputs and outputs. We may use an entity-relati

39、onship diagram to collect related activities and operations into classes. In the end, the specification should be complete, meaning that it should specify an output for any feasible sequence of inputs. Thus, we include validity checks on inputs and system responses to exceptional situations, such as

40、 violated pre-conditions.3. Simulated Writing: Software Requirements(3) Finally, we devise some fit criteria for each of the customers quality requirements, so that we can conclusively demonstrate whether our system meets these quality requirements.The result is a description of what the developers

41、are supposed to produce, written in sufficient detail to distinguish between acceptable and unacceptable solutions, but without saying how the proposed system should be designed or implemented.3. Simulated Writing: Software Requirements Software Requirements Template3. Simulated Writing: Software Re

42、quirements Software Requirements Revision HistoryDateDescriptionAuthorComments 3. Simulated Writing: Software Requirements Software Requirements Document ApprovalThe following Software Requirements Specification has been accepted and approved by the following:SignaturePrinted NameTitleDate Team Lead

43、er Instructor, 3. Simulated Writing: Software Requirements Software Requirements Table of Contents 3. Simulated Writing: Software Requirements Software Requirements 1. IntroductionThe introduction to the Software Requirement Specification (SRS) document should provide an overview of the complete SRS

44、 document. While writing this document please remember that this document should contain all of the information needed by a software engineer to adequately design and implement the software product described by the requirements listed in this document (Note: the following subsection annotates are la

45、rgely taken from the IEEE Guide to SRS).3. Simulated Writing: Software Requirements1.1 PurposeWhat is the purpose of this SRS and the (intended) audience for which it is written?1.2 ScopeThis subsection should:(1) Identify the software product(s) to be produced by name; for example, Host DBMS, Repor

46、t Generator, etc.(2) Explain what the software product(s) will do, and, if necessary, will not do.3. Simulated Writing: Software Requirements(3) Describe the application of the software being specified. As a portion of this, it should:1)Describe all relevant benefits, objectives, and goals as precis

47、ely as possible. For example, to say that one goal is to provide effective reporting capabilities is not as good as saying parameter-driven, user-definable reports with a 2h turnaround and on-line entry of user parameters.2)Be consistent with similar statements in higher-level specifications (for ex

48、ample, the System Requirement Specification), if they exist. What is the scope of this software product?3. Simulated Writing: Software Requirements1.3 Definitions, Acronyms, and AbbreviationsThis subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly

49、 interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents.3. Simulated Writing: Software Requirements1.4 ReferencesThis subsection should:(1) Provide a complete list of all documents referenced elsewhere in the SRS, or i

50、n a separate, specified document.(2) Identify each document by title, report number - if applicable - date, and publishing organization.(3) Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.3. Simulated

51、Writing: Software Requirements1.5 OverviewThis subsection should:(1) Describe what the rest of the SRS contains.(2) Explain how the SRS is organized.3. Simulated Writing: Software Requirements Software Requirements 2. General DescriptionThis section of the SRS should describe the general factors tha

52、t affect the product and its requirements. It should be made clear that this section does not state specific requirements; it only makes those requirements easier to understand.2.1 Product PerspectiveThis subsection of the SRS puts the product into perspective with other related products or projects

53、 (See the IEEE Guide to SRS for more details).3. Simulated Writing: Software Requirements Software Requirements 2. General Description2.2 Product FunctionsThis subsection of the SRS should provide a summary of the functions that the software will perform. 2.3 User CharacteristicsThis subsection of t

54、he SRS should describe those general characteristics of the eventual users of the product that will affect the specific requirements (See the IEEE Guide to SRS for more details).3. Simulated Writing: Software Requirements Software Requirements 2. General Description2.5 Assumptions and DependenciesTh

55、is subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption might be that a specific oper

56、ating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly.3. Simulated Writing: Software Requirements Software Requirements 2. General Description2.4 General ConstraintsThis su

57、bsection of the SRS should provide a general description of any other items that will limit the developers options for designing the system (See the IEEE Guide to SRS for a partial list of possible general constraints).3. Simulated Writing: Software Requirements Software Requirements 3. Specific Req

58、uirementsThis will be the largest and most important section of the SRS. The customer requirements will be embodied within Section 2, but this section will give the requirements that are used to guide the projects software design, implementation, and testing.3. Simulated Writing: Software Requiremen

59、ts Software Requirements 3. Specific RequirementsEach requirement in this section should be:CorrectTraceable (both forward and backward to prior/future artifacts)UnambiguousVerifiable (i.e., testable)Prioritized (with respect to importance and/or stability)CompleteConsistentUniquely identifiable (us

60、ually via numbering like 3.4.5.6)3. Simulated Writing: Software Requirements Software Requirements 3. Specific RequirementsAttention should be paid to carefully organize the requirements presented in this section so that they may be easily accessed and understood. Furthermore, this SRS is not the softwa