REQUIREMENT Requirement specification – SPECIFICATION motivation and basics • Today: Requirements Specification • Requirement specification is generally a crucial phase of an Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department average software project - if it succeeds then a complete failure is unlikely. • Requirements tell us what the system should do - not how it should do it. • The requirements specification can be used as a basis for a contract. • Requirements are independent of the implementation tools, programming paradigm, etc. • The requirements specification can (and should) also be eventually used to evaluate if the software fulfills the • However, the requirements are then analysed with the requirements. intended implementation methodology in mind. • 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 Software Engineering – http://www.cs.uta.fi/se Typical Documents Formal Languages? • Basic textual document, e.g. according to the ANSI/IEEE • Usually much too difficult to understand even for an above Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department Standard 830 – will be discussed later. average user. • A conceptual model of the domain, which may be already • You may be able to verify the system, but how can you verify available or built separately. the requirements? • A description of the processes, e.g. a data flow diagram. • They are usually used for critical well-defined systems and/or concurrent processing, which is notoriously difficult to handle. • A textual description of the use cases – will be discussed later. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Good Requirements Graphical Languages? Specification Qualities • Examples: • Complete Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department - Entity-Relationship (ER) model for conceptual • Accurate description • Unambiguous - Data Flow diagrams for process description • Verifiable (How can you verify ”user friendliness”?) - These are, however, often more suitable for analysis and • Consistent design tasks. • Modifiable (also the requirements change) • Simple languages (like the above) work well in practice • Traceable (where has each requirement come from?) • 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 Software Engineering – http://www.cs.uta.fi/se 1
ANSI/IEEE: Ansi/IEEE Standard 830 Specific requirements • 1. Introduction • 3. Specific requirements Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department 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 Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se ANSI/IEEE: ANSI/IEEE: Specific requirements Functional Requirements • 3. Specific requirements • 3.1. Functional Requirements Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department 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 system 3.6.1. Data Base … shall” – ”Järjestelmän on ...” • 4. Extensions (acceptance criteria, other material...) • Use cases (coming later) describe functionalities Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Techniques For Getting The An Alternative Template Requirements From Users • Go to Pressman’s book’s web pages • Asking Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department (http://www.pressman5.com) and from their choose - Interview ”professional resources” and then http://www.rspa.com and - Questionnaire from there you can find work product templates. The one we - ”Brainstorming” sessions are looking for is called ”System specification”. • Analysing an existing system • Ok, you can go to rspa pages directly as well, but it may be a - We must understand how the new system will good idea to check up pressman’s pages as well. 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 Software Engineering – http://www.cs.uta.fi/se 2
What can go wrong? / 1 What can go wrong? / 2 • Missing specifications Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department - 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. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Who should do requirement specification? • Someone who can communicate with the users Jyrki Nummenmaa University of Tampere, CS Department • 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 3
Recommend
More recommend
