1. CSC480 Software Engineering
Documenting Requirements

2. Topics User & system requirements
Functional & non-functional requirements
Ways to express requirements

3. Requirement Analysis
Requirements generally express what an application is meant to do (i.e., explore the problem domain)
Generally, they don’t try to express how to accomplish these functions (i.e., explore the solution domain)

4. What Is a Requirement? The following statement (Y) sounds like one
The system should allow the user to access his account balance
And what is not? See the following statement (N)
Customers’ account balances will be stored in a table called “balance” in an Access database

5. Types of Requirement Targeted audience Levels of description
C-requirements – targeted primarily for customers, in a non-techie format
D-requirements – targeted primarily for developers, with detailed descriptions
Levels of description

6. Requirements Readers

7. Types of Requirement Levels of description
As the basis for a bid for a contract
A high-level abstract statement of a service or of a system constraint
Open for interpretation
As the contract itself
A detailed mathematical functional specification
must be defined in detail

8. Definitions and Specifications

9. Why Req’ts Must Be Written?
Developers tend to believe that the source code express all the requirements
But without requirements, the team cannot
Know what goals it is trying to accomplish
Inspect and test its work properly
Track its productivity
Gather data for estimations in future projects
Satisfy its customer

10. Each Requirement Must Be
expressed properly, (clarity)
made easily accessible,
numbered, (traceability)
accompanied by tests that verify it, (testability)
provided for in the design, (traceability)
accounted for by code, (traceability)
tested in isolation,
tested in concert with other requirements, and
validated by testing after the application has been built.

11. IEEE 830-1993 SRS Table of Contents
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
System interfaces
User interfaces
Hardware interfaces
Software interfaces
Communications
interfaces
Memory constraints
Operations
Site adaptation
requirements
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and
dependencies
2.6. Apportioning of
3. Specific requirements
-- see chapter four --
4. Supporting information

12. Functional v.s. Non-Functional
Functional requirements
Specify services must be provided
Non-functional requirements
Performance – speed, throughput
Reliability and availability
Error handling
Interfaces (with user or other applications)
Constraints – tool & language, standards, platform, etc
Inverse requirements – what the app doesn’t do

13. Non-functional
requirement types

14. Desired Attributes for SRD
Completeness
Consistency
Nonambiguity
Each requirement should be testable
Each requirement should be numbered and the number should be used in tracing the fulfillment in design through testing

15. Problems w/ Natural Language
Lack of clarity
Precision is difficult without making the document difficult to read
Requirements confusion
Functional and non-functional requirements tend to be mixed-up
Requirements amalgamation
Several different requirements may be expressed together

16. Editor Grid Requirement
2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

17. Requirement problems
Grid requirement mixes three different kinds of requirement
Conceptual functional requirement (the need for a grid)
Non-functional requirement (grid units)
Non-functional UI requirement (grid switching)

18. Structured presentation

19. Using Diagrams – informal
Story-boarding
Informal diagrams with icons and links
Mock-up screens
Use simple GUI screens/pages to illustrate navigation among them

20. Using Diagrams – formal
Use case diagrams
Actors-system interactions
State-transition diagrams
The logics of transitioning from one state to another

21. Use Case Diagram for the Voice Mail System

22. Leave a Message Use Case
Use case details
Leave a Message
1. The caller carries out Reach an Extension.
2. The caller speaks the message.
3. The caller hangs up.
4. The voice mail system place the recorded message in the recipient’s mailbox.
Use case
Reach an Extension
Leave a Message
Caller
Log in
Retrieve Messages
Change the Greeting
Owner
Change the Passcode

23. Voice Mail System State-Transition Diagram