1 / 21

The Requirements Document and IEEE 830

Requirements Engineering & Project Management Lecture 3. The Requirements Document and IEEE 830. Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/require. Requirements in context (Project lifecycle). Problem description. Operational scenarios. Requirements.

armine
Download Presentation

The Requirements Document and IEEE 830

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Engineering & Project Management Lecture 3 The Requirements Documentand IEEE 830 Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/require

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

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

  4. SRS Structure IEEE Std 830-1998 • 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 J.Nawrocki, Requirements document & IEEE 830

  5. 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. J.Nawrocki, Requirements document & IEEE 830

  6. 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. J.Nawrocki, Requirements document & IEEE 830

  7. 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. J.Nawrocki, Requirements document & IEEE 830

  8. 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! J.Nawrocki, Requirements document & IEEE 830

  9. 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. J.Nawrocki, Requirements document & IEEE 830

  10. 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. J.Nawrocki, Requirements document & IEEE 830

  11. SRS Structure IEEE Std 830-1998 • 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 J.Nawrocki, Requirements document & IEEE 830

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

  13. 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. J.Nawrocki, Requirements document & IEEE 830

  14. 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. J.Nawrocki, Requirements document & IEEE 830

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

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

  17. SRS Structure IEEE Std 830-1998 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 J.Nawrocki, Requirements document & IEEE 830

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

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

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

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

More Related