1. 1 SWE 513: Software Engineering Requirements II

2. 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. 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. 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. 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. 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. 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. 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.