软件工程专业英语

杨秀伟

目录

  • 1 Unit 1  Starting a Software Project
    • 1.1 Part1  Listening & Speaking
    • 1.2 Part 2  Reading and Translating
    • 1.3 Part 3  Simulated Writing: Memo
  • 2 Unit 2  Capturing the Requirements
    • 2.1 Part1 Listening & Speaking
    • 2.2 Part 2 Reading and Translating
    • 2.3 Part 3 Simulated Writing
  • 3 Unit 3 Planning the Project
    • 3.1 Part 1 Listening & Speaking
    • 3.2 Part 2 Reading and Translating
    • 3.3 Part 3 Simulated Writing
  • 4 Unit 4 Working in a Team
    • 4.1 Part1 Listening & Speaking
    • 4.2 Part 2 Reading and Translating
    • 4.3 Part 3 Simulated Writing: PowerPoint Presentation
  • 5 Unit 5  Designing the System
    • 5.1 Part1 Listening & Speaking
    • 5.2 Part 2 Reading and Translating
    • 5.3 Part 3 Simulated Writing: Software Design Specification
  • 6 Implementing the System
    • 6.1 Part1 Listening & Speaking
    • 6.2 Part 2 Reading and Translating
    • 6.3 Simulated Writing: Progress Report
  • 7 Testing the System
    • 7.1 Part1 Listening & Speaking
    • 7.2 Part 2 Reading and Translating
    • 7.3 Part 3 Simulated Writing: Software Test Specification
  • 8 Delivering the System
    • 8.1 Part1 Listening & Speaking
    • 8.2 Part 2 Reading and Translating
    • 8.3 Part 3 Simulated Writing: User Guide
Part 3 Simulated Writing

•Simulated Writing: Software Requirements Specification

The requirements specification coversexactly the same ground as the requirements definition, but from the perspective of the developers. Where the requirements definition is written in terms of the customer's vocabulary, referring toobjects, states, events, and activities in the customer's world, the requirements specification is written in terms of the system's interface. We accomplish 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:

(1)   Indocumenting the system'si nterface, we describe all inputs and outputs in detail, including 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 anytiming constraints. Note that the user interface is rarely the only system interface; thesystem may interact with other software components (e.g. a database), special-purpose hardware, the Internet, and soon.

(2)  Next,we restate the required functionality in terms of the interfaces’ inputs and outputs. We may use afunctional notation or data-flowdiagrams 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-relation ship diagram to collect related activities and operations into classes. In the end, the specification should be complete, meaning that it should specifyan output for any feasible sequence of inputs. Thus,we include validity checks on inputs and systemresponses to exceptional situations, such asviolated pre-conditions.

(3)  Finally, we devise some fit criteria for each of the customer's quality requirements, so that we can conclusively demonstrate whether our system meets these quality requirements.

The result is a description of what the developers 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.