CSC480 Software Engineering Documenting Requirements

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

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)

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

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

Requirements Readers

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

Definitions and Specifications

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

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.

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 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces 2.1.6. Memory constraints 2.1.7. Operations 2.1.8. 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

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

Non-functional requirement types

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

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

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.

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)

Structured presentation

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

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

Use Case Diagram for the Voice Mail System

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

Voice Mail System State-Transition Diagram