1 / 8

S WE 51 3 : Software Engineering

S WE 51 3 : Software Engineering. Requirements II. Details in Requirements. Requirements must be specific Examples -- university admissions system Requests for information received by email must be answered within one business day .

graham-king
Télécharger la présentation

S WE 51 3 : Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SWE 513: Software Engineering Requirements II

  2. Details in Requirements Requirements must be specific Examples -- university admissions system Requests for information received by email must be answered within one business day. An admissions officer who is talking to an applicant by telephone must be able to retrieve the applicant's records within 10 seconds. No financial aid offer may exceed the maximum defined in Section 8.7.

  3. Documentation Reasons for documentation: visibility (e.g., project plan, interim report) user support (e.g., user manual) team communication (e.g., interface specifications) maintenance and evolution (e.g., requirements) Characteristics of documentation: accurate and kept current appropriate for audience maintained online (usually) simple but professional in style and appearance Documentation is expensive --> Quality not volume

  4. Requirements Specification: Purpose 1. Document that describes the requirements to the stakeholders in a precise manner • Expressed in the terms that the stakeholders understand • As precise and specific as possible • Comprehensible from many viewpoints • Reviewed by stakeholders so that they understand implications • Must be clear about assumptions (things left out)

  5. Requirements Specification: Purpose 2. It describes the requirements to the implementers • As precise and specific as possible • Expressed in terms that they understand • Comprehensible to new team members

  6. Requirements Specification: Purpose 3. It records the requirements for the future • An essential part of system evolution 4. If may be a contractual document

  7. Requirements Specification: Process The client must understand the requirements specification. • Do not assume that anybody has read a document. • Do not assume that anybody understands a document. Go through the requirements specification with the client, line by line. It is usual for the client and developer to sign the requirements document when it is agreed. [Compare with the plans to build a house. This is the specification of the system that you are about to build.]

  8. Requirements Analysis v. System Design Dilemma. • Requirements analysis should make minimal assumptions about the system design. • But the requirements definition must be consistent with computing technology and the resources available. In practice, analysis and design are interwoven. However: 1. Do not to allow the requirements analysis to prejudge the system design. 2. Do not allow assumptions about the design to have influence the requirements analysis.

More Related