Illinois Institute of Technology

1. Illinois Institute of Technology CS487 Software Engineering Instructor David Lash

2. Writing the Requirements Specification • Start with a standard outline. • See ANSI/IEEE Std 830-19xx IEEE Guide to Software Requirements Specifications • Use consistent language to write specifications. • Provide a method of testing and tracing specifications.

3. General Specification Outline I) Introduction The goals + overall objectives. The context of the overall system. Scope. A) System reference B) Overall description C) Software project constraints

4. General Specification Outline II) Information Description - - Problem that the system solves, hardware, info/control flow, software and human interfaces. A) Information content representation B) Information flow representation 1) Data flow 2) Control flow

5. General Specification Outline III) Functional Description Detail on each function required to solve A) Functional partitioning - overall diagram of the structure of functions B) Function description 1) Processing narrative for each function 2) Restrictions/limitation 3) Performance requirements 4) Design constraints 5) Supporting diagrams

6. General Specification Outline • C) Control Description • 1) Control specification • 2) Design constraints • IV Behavioral Description • Operation of system in respect to external events and actions • 1) System states • 2) Events and actions

7. General Specification Outline V) Validation and Criteria what is a successful implementation? A) Performance bounds B) Classes to tests C) Expected software response D) Special consideration VI) Bibliography - references to documents related, vendor literature, tech references VII) Appendix - related data, algorithms, charts, graphs

8. Writing a Requirement • Always write in an active voice. • Active voice, the subject acts. • The systemprocesses 5 transactions per second. • Passive voice, the subject is acted upon. • The systemis to process 5 transactions per second.

9. Writing requirements • Specific and general requirements. • “Shall” indicates the requirement must operate exactly as specified. • On reception of a new messages, the software shall respond with an ACK, if the data is received without error; or a NACK, if the data received contains an error. • “Should”, “will” indicates the system generally operates this way.

10. Requirement Statement Example (Optional) Section Reference Specification Reference O4-1 [29]The date representation used for a character-oriented interface that interchanges date-sensitive information between communicating systems should conform to ISO 8601 calendar date complete representation and basic format (without separators).

11. Requirement Statement Example (Conditional) CR4-5 [33]If a system that supports an internal date representation with four digits for the calendar year interfaces with an interface that supports less than four digits for the calendar year, then the system’s message/protocol handler shall convert the incoming message/APDU calendar year representation to a four-digit format. It should then perform the necessary date operations. The reverse order is true for the outgoing direction.

12. Requirement Statement Example (Mandatory) R4-3 [31]The date/time representation used for the protocol of an object oriented interface and its associated information model shall conform to ISO 8601 calendar date complete representation and basic format. For example, in OIS/CMISE, the ASN.1 type Generalized Time syntax conforms to ISO 8601.