软件工程专业英语

杨秀伟

目录

  • 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: Software Design Specification

–Software  Design Specification

An important product of the design process is a set of documents that describe the system to be built. As we have seen, one part must tell the customers and users in natural language what the system will do; a second part uses technical terminology to describe the system's structure, data, and functions.Thus, the contents of the two parts may overlap, but the ways of expressing them may not.

The design documents should contain a section, called the design rationale,outlining the critical issues and trade-offs that were consideredin generating the design.This guiding philosophy helps the customers and other developers under stand how and why certain parts of the design fit  together.

The design also contains descriptions of the components ofthe system. One section should address how the users interact with the system.

Usually, a set of diagrams or formal notations describe the overall organization and structure  of the system, including  all  levels of abstraction.

If  the system is distributed, the configuration in the design is detailed enough to show the topology of the network, how the network nodes will  access one another, and the allocation of functions to the nodes. If the system requirements include constraints on timing,or if the nodes of the network must be synchronized, the design describes how the timing will work. Similarly, the design contains information about the control and routing of messages. It may also include prescriptions for the integrity of the network: making sure that the data are  accurate or can be recovered  after  afailure.

If the customer requires it, elements of the design may address monitoring system performance. In addition, there may be amanual override of the system, and the design describes how it will work. Other sections ofthe design documents may address fault location  and  isolation, system reconfiguration, or special security  measures.

Finally, the  design is cross-referenced with the requirements to demonstrate how the design is derived from them. This correspondence forces us to check for completeness and consistency. In addition, such across-reference will make enhancements or modifications easier to tracklater. For example, if a requirement changes, the  cross-reference  points to the corresponding  design changes  needed.