Requirement Analysis

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

THE BASIC WATERFALL MODEL Requirements analysis Design Implementation Testing Maintenance

The Software Lifecycle

Dilbert On Requirements

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

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

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?)

OVERALL STRUCTURE FOR REQ. SPEC. (Ansi/IEEE Standard 830) 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms and Abbreviations 1.4. References 1.5. Overview 2. General Description 2.1. Product Perspective 2.2. Product Functions 2.3. User Characteristics 2.4. General Constraints 2.5. Assumptions and Dependencies 3. Specific Requirements

ANSI/IEEE: Specific requirements 3. Specific requirements 3.1. Functional Requirements 3.2. External Interface Requirements 3.3. Performance Requirements 3.4 Design Constraints 3.4.1. Standards Compliance 3.4.2. Hardware Limitations … 3.5. Attributes 3.5.1. Security 3.5.2. Maintainability … 3.6. Other Requirements 3.6.1. Data Base …

ANSI/IEEE: FUNCTIONAL REQUIREMENTS 3.1. Functional Requirements 3.1.1. Functional Requirement 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Functional Requirement 2 … 3.1.n Functional Requirement n

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

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

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.

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

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