1. CSC480 Software Engineering Lecture 7 September 16, 2002

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  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 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 requirements 3. Specific requirements -- see chapter four -- 4. Supporting information -- see chapter four --

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 Data flow diagrams (DFD)  Data traffic among processing units State-transition diagrams  The logics of transitioning from one state to another

21. Initialize Use Case for Encounter Encounter foreign character player designer Set rules actors Encounter Travel to adjacent area Initialize 1. System displays player’s main character in the dressing room. 2. System displays a window for setting his character's qualities. 3. Player allocates the qualities of his main character. 4. Player chooses an exit from the dressing room. 5. System moves player’s main character into the area on the other side of the exit. Initialize Use case Use case details

22. Engage Foreign Character Use Case player designer Initialize Use case Encounter Travel to adjacent area Set rules Engage Foreign Character 1. System displays the foreign character in the same area as the player’s. 2. System exchanges quality values between the two characters. 3. System displays the results of the engagement. 4. System displays player’s character in a random area. Engage foreign character Use case details

23. Data Flow Diagram: Explanation of Symbols Account # & deposit Get deposit Check deposit Processing element Data type Direction of data flow

24. Data Flow Diagram: Explanation of Symbols Account # & deposit balance query User account database account data Get deposit Create account summary Check deposit Printer Input Output Processing element Data type Direction of data flow Data store …...

25. Partial Encounter State-Transition Diagram Setting up Preparing Waiting Complete setup Foreign character enters area Engaging Player clicks qualities menu

26. Using Conditions in State-Transition Diagrams Engaging Waiting [foreign character absent] [foreign character present] Player moves to adjacent area event condition state