REQUIREMENT SPECIFICATION University of Tampere CS Department Jyrki

REQUIREMENT SPECIFICATION University of Tampere, CS Department Jyrki Nummenmaa • Today: Requirements Specification • Requirements tell us what the system should do - not how it should do it. • Requirements are independent of the implementation tools, programming paradigm, etc. • However, the requirements are then analysed with the intended implementation methodology in mind. Software Engineering – http: //www. cs. uta. fi/se

Requirement specification – motivation and basics University of Tampere, CS Department Jyrki Nummenmaa • Requirement specification is generally a crucial phase of an average software project - if it succeeds then a complete failure is unlikely. • The requirements specification can be used as a basis for a contract. • The requirements specification can (and should) also be eventually used to evaluate if the software fulfills the requirements. • As users generally can not work with formal specifications, natural language specifications must or should often be used. Software Engineering – http: //www. cs. uta. fi/se

Typical Documents University of Tampere, CS Department Jyrki Nummenmaa • Basic textual document, e. g. according to the ANSI/IEEE Standard 830 – will be discussed later. • A conceptual model of the domain, which may be already available or built separately. • A description of the processes, e. g. a data flow diagram. • A textual description of the use cases – will be discussed later. Software Engineering – http: //www. cs. uta. fi/se

Formal Languages? University of Tampere, CS Department Jyrki Nummenmaa • Usually much too difficult to understand even for an above average user. • You may be able to verify the system, but how can you verify the requirements? • They are usually used for critical well-defined systems and/or concurrent processing, which is notoriously difficult to handle. Software Engineering – http: //www. cs. uta. fi/se

Graphical Languages? University of Tampere, CS Department Jyrki Nummenmaa • Examples: - Entity-Relationship (ER) model for conceptual description - Data Flow diagrams for process description - These are, however, often more suitable for analysis and design tasks. • Simple languages (like the above) work well in practice • In requirement specification, they should be used to model the application domain and the processes. • If a domain conceptual model exists, it should be used to accompany the requirements. Software Engineering – http: //www. cs. uta. fi/se

Good Requirements Specification Qualities University of Tampere, CS Department Jyrki Nummenmaa • • Complete Accurate Unambiguous Verifiable (How can you verify ”user friendliness”? ) Consistent Modifiable (also the requirements change) Traceable (where has each requirement come from? ) Software Engineering – http: //www. cs. uta. fi/se

Ansi/IEEE Standard 830 University of Tampere, CS Department Jyrki Nummenmaa • 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 Software Engineering – http: //www. cs. uta. fi/se

ANSI/IEEE: Specific requirements University of Tampere, CS Department Jyrki Nummenmaa • 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 … Software Engineering – http: //www. cs. uta. fi/se

ANSI/IEEE: Specific requirements University of Tampere, CS Department Jyrki Nummenmaa • 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 … • 4. Extensions (acceptance criteria, other material. . . ) Software Engineering – http: //www. cs. uta. fi/se

ANSI/IEEE: Functional Requirements University of Tampere, CS Department Jyrki Nummenmaa • 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 • A typical way to express the requirements is ”The system shall” – ”Järjestelmän on. . . ” • Use cases (coming later) describe functionalities Software Engineering – http: //www. cs. uta. fi/se

An Alternative Template University of Tampere, CS Department Jyrki Nummenmaa • Go to Pressman’s book’s web pages (http: //www. pressman 5. com) and from their choose ”professional resources” and then http: //www. rspa. com and from there you can find work product templates. The one we are looking for is called ”System specification”. • Ok, you can go to rspa pages directly as well, but it may be a good idea to check up pressman’s pages as well. Software Engineering – http: //www. cs. uta. fi/se

Techniques For Getting The Requirements From Users University of Tampere, CS Department Jyrki Nummenmaa • 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 Software Engineering – http: //www. cs. uta. fi/se

What can go wrong? / 1 University of Tampere, CS Department Jyrki Nummenmaa • 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 - Sometimes the users disagree strongly. • Noise - Do not include material which does not contain relevant information Software Engineering – http: //www. cs. uta. fi/se

What can go wrong? / 2 University of Tampere, CS Department Jyrki Nummenmaa • 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. Software Engineering – http: //www. cs. uta. fi/se

Who should do requirement specification? University of Tampere, CS Department Jyrki Nummenmaa • 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). Software Engineering – http: //www. cs. uta. fi/se