Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © Jerzy R. Nawrocki The Requirements Document and IEEE 830 Requirements Engineering.

Similar presentations


Presentation on theme: "Copyright © Jerzy R. Nawrocki The Requirements Document and IEEE 830 Requirements Engineering."— Presentation transcript:

1 Copyright © Jerzy R. Nawrocki The Requirements Document and IEEE 830 Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/require Requirements Engineering & Project Management Lecture 3

2 J.Nawrocki, Requirements document & IEEE 830 Requirements in context (Project lifecycle) Problem description Operational scenarios Requirements Design & implementation

3 J.Nawrocki, Requirements document & IEEE 830 Struktura SRS 1. Introduction 2. Overall description of the product 3. Functional requirements 4. Non-functional requirements Appendices Index IEEE Std 830-1998

4 J.Nawrocki, Requirements document & IEEE 830 SRS Structure 1. Introduction 1.1 Purpose of the document 1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the document 2. Overall description of the product 3. Functional requirements 4. Non-functional requirements Appendices Index IEEE Std 830-1998

5 J.Nawrocki, Requirements document & IEEE 830 1.1 Purpose of the document Role of SRS + the readers The document presents software requirements, i.e. it describes functionality of the software that will be built as well as other constraints imposed on it. The document is aimed at end-users, designers, programmers, testers, and manual writers.

6 J.Nawrocki, Requirements document & IEEE 830 1.2 Scope of the product Identification of the product by name. What the product will do and what will not. Application of the specified product. Product Vision: What’s the problem? Who suffers? What are the implications? General idea how to solve the problem.

7 J.Nawrocki, Requirements document & IEEE 830 1.2 Scope of the product Identification of the product by name. What the product will do and what will not. Application of the specified product. Polish Writers Association has over 10 000 members. The members frequently change their address data and there are problems with updating them fast. The problem concerns both the members (about 500 change their data a year), and the board, which suffers from communication troubles. As a consequence unpaid member dues amount to about 15 000 zł. The problem can be solved by acquiring an Internet-based system, e-Member, allowing updating address data by Internet.

8 J.Nawrocki, Requirements document & IEEE 830 1.3 Definitions, acronyms and abbreviations ASAP – As Soon As Possible Explorer – see MS Explorer... MS Explorer – Microsoft’s product that allows reading web pages NIP – Tax identification number in Poland (in Polish „Numer identyfikacji podatkowej”) PWA – Polish Writers Associations Alphabetic order!

9 J.Nawrocki, Requirements document & IEEE 830 1.4 References The system should present avarage value and standard deviation [Montgomery97]. [Montgomery97] D.Montgomery, Introduction to Statistical Quality Control, John Wiley & Sons, Boston, 1997. [act2000] Polish act „ Ustawa z dnia 16.11.2000 o przeciwdziałaniu wprowadzaniu do obrotu finansowego wartości majątkowych pochodzących z nielegalnych lub nieujawnionych źródeł oraz o przeciwdziałaniu finansowaniu terroryzmu ”, Dz.U. 22 December 2000.

10 J.Nawrocki, Requirements document & IEEE 830 1.5 Overview of the document What is in the subsequent parts of the document? In Chapter 2 a general description of the product is presented along with short characteristic of end-users and the functionality that will be available to them. Chapter 3 containts detailed description of functional requirements. They have been split according to user classes (roles). Those requirements are a starting point to description of non-functional requirements that are presented in Chapter 4.

11 J.Nawrocki, Requirements document & IEEE 830 SRS Structure 1. Introduction 2. Overall description of the product 2.1 Product perspective (context) 2.2 User characteristics 2.3 Main product functions 2.4 Constraints 2.5 Assumptions and dependencies 3. Functional requirements 4. Non-functional requirements Appendices Index IEEE Std 830-1998

12 J.Nawrocki, Requirements document & IEEE 830 2.1 Product perspective The described system is to communicate with the PolCard system to implement electronic payments. The context diagram is presented in Fig. 1. E-Member Member Board PolCard

13 J.Nawrocki, Requirements document & IEEE 830 2.2 User characteristics The following roles has been identified: Member of the association – Most of the PWA members (over 80%) are 30 to 55 years old. Some of them have sight problems. From a inquire conducted recently it follows that 80% members have a computer at home and they know how to read web pages or they are willing to get to know. Board – All the board members have computers and they are proficient with using web pages.

14 J.Nawrocki, Requirements document & IEEE 830 2.3 Main product functions The product will offer the following functionality. An PWA member can: Read his/her data stored in the system Update his/her data. PWA Board can: Send serial mail to PWA members.

15 J.Nawrocki, Requirements document & IEEE 830 2.4 Constraints The system must obey requlations imposed by the Polish act concerning personal data [personal-data-act].

16 J.Nawrocki, Requirements document & IEEE 830 2.5 Assumptions and dependencies The presented requirements are based on requlations known as of 1 September 2005.

17 J.Nawrocki, Requirements document & IEEE 830 SRS Structure 1. Introduction 2. Overall description of the product 3. Functional requirements 3.1 PWA Member 3.1.1 Reading the data 3.1.2 Updating the data 3.2 PWA Board 3.2.2.1 Broadcasting mail 4. Non-functional requirements Appendices Index IEEE Std 830-1998

18 J.Nawrocki, Requirements document & IEEE 830 A Use Case Updating the data Actor Actor: Member Goal Goal: Update personal data. Main scenario 1.Member enters his account and password. 2.System presents the personal web page. 3.Member selects the update option. 4.System presents the personal data ready for update. 5.Member changes the data. 6.System asks for acknowledgement. 7.Member confirms the changes.Extensions 1a. 1a. Account or password is incorrect. 1a1. 1a1. System presents a message and returns to Step 1.

19 J.Nawrocki, Requirements document & IEEE 830 Meetings Prolog Meeting Epilog Agenda 1 Opening 2 The problem 3 Problem stakeholders 4 Implications 5 Proposed solution 6 Closing Purpose + Agenda + Timing Report (e.g. Project Vision)

20 J.Nawrocki, Requirements document & IEEE 830 Summary Project lifecycle (problem & operational scenarios) SRS document structure compliant with IEEE 830 Meeting organization (prolog, meeting, epilog)

21 J.Nawrocki, Requirements document & IEEE 830 Lecture evaluation 1. General impression (1 - 6) 2. Too fast or too slow? 3. Have you learned something important? 4. What to improve?


Download ppt "Copyright © Jerzy R. Nawrocki The Requirements Document and IEEE 830 Requirements Engineering."

Similar presentations


Ads by Google