1. Requirement Analysis

2. Waterfall Model What is a waterfall? What is a waterfall model?
A short video to watch and listen

5. THE BASIC WATERFALL MODEL
Requirements analysis
Design
Implementation
Testing
Maintenance

6. The Software Lifecycle

7. Dilbert On Requirements

9. Requirement Analysis
Requirements tell us what the system should do - not how it should do it.

10. Requirements Analysis Summary
Requirement Analysis (John Knight & Thomas Horton 2007)

11. GOOD REQUIREMENTS SPECIFICATION QUALITIES
Complete
Accurate
Unambiguous
Verifiable (How can you verify ”user friendliness”?)
Consistent
Modifiable (also the requirements change)
Traceable (where has each requirement come from?)

12. OVERALL STRUCTURE FOR REQ. SPEC. (Ansi/IEEE Standard 830)
1. Introduction Purpose Scope Definitions, Acronyms and Abbreviations References Overview 2. General Description Product Perspective Product Functions User Characteristics General Constraints Assumptions and Dependencies 3. Specific Requirements

13. ANSI/IEEE: Specific requirements
3. Specific requirements Functional Requirements External Interface Requirements Performance Requirements Design Constraints Standards Compliance Hardware Limitations … Attributes Security Maintainability … Other Requirements Data Base …

14. ANSI/IEEE: FUNCTIONAL REQUIREMENTS
3.1. Functional Requirements Functional Requirement Introduction Inputs Processing Outputs Functional Requirement 2 … n Functional Requirement n

15. TECHNIQUES FOR GETTING THE REQUIREMENTS FROM USERS
Asking - Interview - Questionnaire - ”Brainstorming” sessions
Analysing an existing system - We must understand how the new system will differ from any old such system
Analysing the environment - e.g. process analysis
Prototyping - Gives best feedback and more formal specifications but can be expensive

16. REQUIREMENTS ANALYSIS - What can go wrong?
Missing specifications - Happens often - Experience helps - Sometimes it is impossible to notice
Contradictions - Do not document the same thing many times - Integrate different users’ views with the users
Noise - Do not include material which does not contain relevant information

17. REQUIREMENT SPECIFICATION - What can go wrong? (2)
Documenting a solution rather than the problem - If the users know some information technology, they want to start solving the problem as they express it. - Many formal (also graphical) methods tend to direct the process into this.
Unrealistic requirements - Although we model the problem rather than the solution, it is good to have some idea of what is possible.

18. Dictation for Relaxation
Lion King 1
Lion King 2
Lion King 3

19. Finally
Remember:
---No job is finished till the paperwork is done!