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

Slides:



Advertisements
Similar presentations
Planning at CMM level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering.
Advertisements

Project Management with XPrince Requirements Eng. & Project Management Lecture 10 Jerzy Nawrocki „Trabrennen” in.
Information System Design IT60105 Lecture 3 System Requirement Specification.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
WKES 3202 SOFTWARE REQUIREMENTS ENGINEERING SEMESTER 1 SESSION 2004/2005.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
A summary of the PSS-05 URD template
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Requirements Engineering
Chapter 7: The Object-Oriented Approach to Requirements
ConOps and Use Cases Copyright, 2003 © Jerzy R. Nawrocki Requirements Engineering.
IT 499 Bachelor Capstone Week 9.
Chapter 4 Requirements Engineering
Lecture 18: Specifications
CS 4310: Software Engineering Lecture 3 Requirements and Design.
Typical Software Documents with an emphasis on writing proposals.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Requirements specification Copyright, 2001 © Jerzy R. Nawrocki Quality Management.
Copyright © Jerzy R. Nawrocki Requirements Review Requirements Engineering & Project.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Quality Model for Requirements Eng. Copyright, 2002 © Jerzy R. Nawrocki Quality.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
BMAN Integrative Team Project Week 2 Professor Linda A Macaulay.
Software Requirements Engineering CSE 305 Lecture-2.
Requirements Verification & Validation Requirements Engineering & Project Management.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
Good Practices of Requirements Eng. Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Use-Cases Elicitation and FAST Copyright, 2003 © Jerzy R. Nawrocki Requirements Engineering.
University Of Palestine. Department of Information Technology.
Some Sub-Activities within Requirements Engineering 1.Prototyping 2.Requirements Documentation 3.Requirements Validation 4.Requirements Measurements 5.Requirements.
Project Planning & Initiation Requirements Engineering & Project Management Lecture.
CIS 499 Senior Seminar Introduction to IT project management.
Requirements Documentation CSCI 5801: Software Engineering.
Lecture 7: Requirements Engineering
Quality of Usage Scenarios Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Implementing XP at PUT Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Professional Certificate in Electoral Processes Understanding and Demonstrating Assessment Criteria Facilitator: Tony Cash.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CONTENTS OF THE SRS REPORT. Software Requirements Specification (SRS) template The SRS document describes recommended approaches for the specification.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Systems Development Life Cycle
SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 T Software Architectures.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Project Management with XPrince Requirements Eng. & Project Management Lecture 11 Jerzy Nawrocki „Trabrennen” in.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
1. The Requirements Process Requirements Input Example
Configuration Management at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Quality Model for RE Process Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Change Management Requirements Engineering & Project Management Lecture 10.
Introduction to Quality Management Copyright, 2000 © Jerzy R. Nawrocki Quality.
Configuration Management (II) Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Research Methods Technical Writing Thesis Conference/Journal Papers
CSC480 Software Engineering Lecture 7 September 16, 2002.
Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Requirements Management and Changes Copyright, 2003 © Jerzy R. Nawrocki Requirements.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
1 Software Requirements Engineering (CS 708) Dr. Ghulam Ahmad Farrukh.
1 Requirements Elicitation – 2 Lecture # Requirements Engineering Process Requirements Elicitation Requirements Analysis and Negotiation Requirements.
Requirements Engineering Lecture 2
Functional Requirements
CSC480 Software Engineering
Software Requirements Specification Document
Requirements Document
Requirement Analysis.
Applied Software Project Management
Requirements Engineering Lecture 6
Presentation transcript:

Copyright © Jerzy R. Nawrocki The Requirements Document and IEEE 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. Introduction 2. Overall description of the product 3. Functional requirements 4. Non-functional requirements Appendices Index IEEE Std

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

J.Nawrocki, Requirements document & IEEE 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 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 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 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 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 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 References The system should present avarage value and standard deviation [Montgomery97]. [Montgomery97] D.Montgomery, Introduction to Statistical Quality Control, John Wiley & Sons, Boston, [act2000] Polish act „ Ustawa z dnia 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 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. 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

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

J.Nawrocki, Requirements document & IEEE 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 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 Constraints The system must obey requlations imposed by the Polish act concerning personal data [personal-data-act].

J.Nawrocki, Requirements document & IEEE 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. Introduction 2. Overall description of the product 3. Functional requirements 3.1 PWA Member Reading the data Updating the data 3.2 PWA Board Broadcasting mail 4. Non-functional requirements Appendices Index IEEE Std

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.

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)

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?