"WP2 Introduction to the requirement specification"
WP2 – Introduction to the requirement specification Purpose • To introduce to the concept and the ideas behind the specification • … and to answer the question: How? Agenda • 14:00 – Overview of the requirement specification • 14:30 – ~15 minutes for each partner to present their comments and to suggest additions to the requirement specification 1 Outline • Background to the specification • About the requirement specification – Involved parties – Users – Requirement system – Functional requirements – Non functional requirements – Product components and hardware requirements – Configuration – Acceptance conditions • Questions 2 Background to the specification Considered material • Questionnaires, Material from Tallinn (context diagrams, schemes and figures etc.) Goal • To take into consideration the ”concept” behind INNOMET • To answer the question: Who will do what? • And, most important, to summarize the requirements in a structured and well defined way so that we all can discuss what the systems shall encompass and agree on the functionality 3 Involved parties Name Organisation E-mail *Function PL SD DD TQ HU Mattias Larsson KTH – Sweden firstname.lastname@example.org SE EE FI IT *PL application project leader, SD responsible software design and coding, DD responsible for database design and implementation, TQ test and quality coordinator HU, SE, EE, FI, IT the responsible person for setting up the application in their country 4 Users Three different types of users have been identified; • Ordinary users • Advanced users -Company representatives -Educational institution representatives • Administrative users What suits one user might not suit the next. . . 5 Requirement system • Each requirement is described using: - Requirement No. - Description - Priority - Status - Commentary • The purpose is to ensure that the most important parts are implemented • Our goal is to achieve priority level Normal • One level is finished then all requirements therein are fulfilled 6 Functional requirements • Divided according to belonging (ordinary users, advanced users and administrators) • Ordinary user functions - For the general public, students and professionals that want to extract some information form the system • Advanced user functions - A way of “describing” the organization in terms of roles, needed competence for a certain role (companies) and education (educational institutions) - A ”digitalized” version of the questionnaires • Administrative user functions - Intended to simplify system management The requirement specification describes what functions the system should include not how this is done (up to the programmers to decide) 7 Non functional requirements Non-functional requirements are divided according to compatibility, efficiency and reliability • Compatibility is important to ensure easy deployment • Efficiency is important to ensure usefulness • . . . and reliability is important to ensure data integrity (to ensure that the data are pure and not corrupted) 8 Product components and hardware requirements Product components… that should be delivered • HTML pages for ordinary, advanced and administrative users • User guides (printed and in HTML format) • Technical documentation Hardware and software requirements • Hardware - PC • Operating system - Linux • WWW server - Apache • Database - To be decided 9 Configuration • Multi language support • Easy configurable search paths • Flexible design 10 Acceptance conditions • After the project group has accepted the content of the requirement specification we should agree on the acceptance conditions. - What should the system contain in order to be accepted (the system should fulfil the requirements in the requirement specification – at least level basic) - . . . and how do we perform the acceptance test • Suggestions for acceptance test - The application project group should demonstrate the system - After the demonstration the members of INNOMET should be given some time to test the system - During this period the users can give comments. If these lie within the frame of the requirement specification it should result in actions by the application project group. 11 Questions • What parts are missing? • What parts can be deleted? • The priority levels (i.e. priority basic, normal or extra). What part are important? • Who is responsible for what (i.e. to divide the responsibilities)? • And finally, to agree on the content 12