Copyright © Jerzy R. Nawrocki

The Requirements Documentand IEEE 830

The Requirements Documentand IEEE 830

Jerzy.Nawrocki@put.poznan.plwww.cs.put.poznan.pl/jnawrocki/require

Requirements Engineering & Project Management

Lecture 3

J.Nawrocki, Requirements document & IEEE 830

Requirements in context (Project lifecycle)

Problem description

Operational scenarios

Requirements

Design & implementation

J.Nawrocki, Requirements document & IEEE 830

Struktura SRS

1. Introduction2. Overall description of the product3. Functional requirements4. Non-functional requirementsAppendicesIndex

IEEE Std 830-1998

J.Nawrocki, Requirements document & IEEE 830

SRS Structure

1. Introduction1.1 Purpose of the document1.2 Scope of the product1.3 Definitions, acronyms and abbreviations1.4 References1.5 Overview of the document

2. Overall description of the product3. Functional requirements4. Non-functional requirementsAppendicesIndex

IEEE Std 830-1998

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.

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.

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.

J.Nawrocki, Requirements document & IEEE 830

1.3 Definitions, acronyms and abbreviations

ASAP – As Soon As PossibleExplorer – see MS Explorer...MS Explorer – Microsoft’s product that allows reading web pagesNIP – Tax identification number in Poland (in Polish „Numer

identyfikacji podatkowej”)PWA – Polish Writers Associations

Alphabetic order!

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.

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.

J.Nawrocki, Requirements document & IEEE 830

SRS Structure

1. Introduction2. Overall description of the product

2.1 Product perspective (context)2.2 User characteristics2.3 Main product functions2.4 Constraints2.5 Assumptions and dependencies

3. Functional requirements4. Non-functional requirementsAppendicesIndex

IEEE Std 830-1998

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-MemberE-MemberMember

Board

PolCard

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.

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.

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].

J.Nawrocki, Requirements document & IEEE 830

2.5 Assumptions and dependencies

The presented requirements are based on requlations known as of 1 September 2005.

J.Nawrocki, Requirements document & IEEE 830

SRS Structure

1. Introduction2. Overall description of the product3. 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 mail4. Non-functional requirementsAppendicesIndex

IEEE Std 830-1998

J.Nawrocki, Requirements document & IEEE 830

A Use Case

Updating the dataUpdating the dataActorActor: MemberGoalGoal: Update personal data.Main scenarioMain scenario1. 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. ExtensionsExtensions1a.1a. Account or password is incorrect. 1a1.1a1. System presents a message and returns to Step 1.

J.Nawrocki, Requirements document & IEEE 830

Meetings

Prolog

Meeting

Epilog

Agenda1 Opening2 The problem3 Problem stakeholders4 Implications5 Proposed solution6 Closing

Purpose + Agenda + Timing

Report (e.g. Project Vision)

J.Nawrocki, Requirements document & IEEE 830

Summary

• Project lifecycle (problem & operational scenarios)

• SRS document structure compliant with IEEE 830

• Meeting organization (prolog, meeting, epilog)

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?