1 Good Requirements Graphical Languages? Specification Qualities - PDF document

REQUIREMENT SPECIFICATION The Basic Waterfall Model • Today: Requirements Specification Requirements • Requirements tell us what the system should do - specification not how it should do it. Analysis & • Requirements are independent of the Design implementation tools, programming paradigm, etc. Implementation • However, the requirements are then analysed with the intended implementation methodology in mind. Testing Maintenance 1.10.2004 Software Engineering 2004 1 1.10.2004 Software Engineering 2004 2 Jyrki Nummenmaa Jyrki Nummenmaa Requirement specification – Prototyping motivation and basics • Requirement specification is generally the most crucial phase of an average software project - if it Requirements spec. - V&V succeeds then a complete failure is unlikely. • The requirements specification can be used as a Design - V&V basis for a contract. Quick Analysis • The requirements specification can (and should) & Design - V&V also be eventually used to evaluate if the software Implementation - V&V fulfills the requirements. Quick Implementa- tion - V&V • As users generally can not work with formal Testing - V&V specifications, natural language specifications must or should often be used. V&V = Verification and Validation Maintenance - V&V 1.10.2004 Software Engineering 2004 3 1.10.2004 Software Engineering 2004 4 Jyrki Nummenmaa Jyrki Nummenmaa Typical Documents Formal Languages? • Basic textual document, e.g. according to the • Usually much too difficult to understand even for ANSI/IEEE Standard 830 – will be discussed later. an above average user. • A conceptual model of the domain, which may be • You may be able to verify the system, but how can already available or built separately. you verify the requirements? • A description of the processes, e.g. a data flow • They are usually used for critical well-defined diagram. systems and/or concurrent processing, which is notoriously difficult to handle. • A textual description of the use cases – will be discussed later. 1.10.2004 Software Engineering 2004 5 1.10.2004 Software Engineering 2004 6 Jyrki Nummenmaa Jyrki Nummenmaa 1

Good Requirements Graphical Languages? Specification Qualities • Examples: • Complete - Entity-Relationship (ER) model for conceptual • Accurate description • Unambiguous - Data Flow diagrams for process description • Verifiable (How can you verify ”user friendliness”?) • Simple languages (like the above) work well in • Consistent practice • Modifiable (also the requirements change) • In requirement specification, they should be used • Traceable (where has each requirement come to model the application domain and the from?) processes. 1.10.2004 Software Engineering 2004 7 1.10.2004 Software Engineering 2004 8 Jyrki Nummenmaa Jyrki Nummenmaa Overall Structure For Req. Spec. ANSI/IEEE: (Ansi/IEEE Standard 830) Specific requirements • 1. Introduction • 3. Specific requirements 1.1. Purpose 3.1. Functional Requirements 1.2. Scope 3.2. External Interface Requirements 1.3. Definitions, Acronyms and Abbreviations 3.3. Performance Requirements 1.4. References 3.4 Design Constraints 1.5. Overview 3.4.1. Standards Compliance 2. General Description 3.4.2. Hardware Limitations … 2.1. Product Perspective 3.5. Attributes 2.2. Product Functions 3.5.1. Security 2.3. User Characteristics 3.5.2. Maintainability … 2.4. General Constraints 3.6. Other Requirements 2.5. Assumptions and Dependencies 3.6.1. Data Base … 3. Specific Requirements 1.10.2004 Software Engineering 2004 9 1.10.2004 Software Engineering 2004 10 Jyrki Nummenmaa Jyrki Nummenmaa ANSI/IEEE: ANSI/IEEE: Specific requirements Functional Requirements • 3. Specific requirements • 3.1. Functional Requirements 3.1. Functional Requirements 3.1.1. Functional Requirement 1 3.2. External Interface Requirements 3.1.1.1 Introduction 3.3. Performance Requirements 3.1.1.2 Inputs 3.4 Design Constraints 3.1.1.3 Processing 3.4.1. Standards Compliance 3.1.1.4 Outputs 3.4.2. Hardware Limitations … 3.1.2 Functional Requirement 2 3.5. Attributes … 3.5.1. Security 3.5.2. Maintainability … 3.1.n Functional Requirement n 3.6. Other Requirements • A typical way to express the requirements is ”The 3.6.1. Data Base … system shall” – ”Järjestelmän on ...” • 4. Extensions (acceptance criteria, other material...) • Use cases (coming later) describe functionalities 1.10.2004 Software Engineering 2004 11 1.10.2004 Software Engineering 2004 12 Jyrki Nummenmaa Jyrki Nummenmaa 2

Techniques For Getting The An Alternative Template Requirements From Users • Go to Pressman’s book’s web pages • Asking (http://www.pressman5.com) and from their - Interview choose ”professional resources” and then - Questionnaire http://www.rspa.com and from there you can find - ”Brainstorming” sessions work product templates. The one we are looking • Analysing an existing system for is called ”System specification”. - We must understand how the new system will • Ok, you can go to rspa pages directly as well, but differ from any old such system it may be a good idea to check up pressman’s • Analysing the environment pages as well. - e.g. process analysis • Prototyping - Gives best feedback and more formal specifications but can be expensive 1.10.2004 Software Engineering 2004 13 1.10.2004 Software Engineering 2004 14 Jyrki Nummenmaa Jyrki Nummenmaa What can go wrong? / 1 What can go wrong? / 2 • Missing specifications - Happens often • Documenting a solution rather than the problem - Experience helps - If the users know some information technology, - Sometimes it is impossible to notice they want to start solving the problem as they • Contradictions express it. - Do not document the same thing many times - Many formal (also graphical) methods tend to - Integrate different users’ views with the users direct the process into this. - Sometimes the users disagree strongly. • Unrealistic requirements • Noise - Although we model the problem rather than the - Do not include material which does not contain solution, it is good to have some idea of what relevant information is possible. 1.10.2004 Software Engineering 2004 15 1.10.2004 Software Engineering 2004 16 Jyrki Nummenmaa Jyrki Nummenmaa Who should do requirement specification? • Someone who can communicate with the users • Someone who has experience • Someone who knows similar systems and/or the application area • Someone who knows what is possible and how (and how much work is roughly needed). 1.10.2004 Software Engineering 2004 17 Jyrki Nummenmaa 3