Functional Requirements

Slides:



Advertisements
Similar presentations
Chapter 11 Designing the User Interface
Advertisements

Project Analysis Course ( ) Final Project Report Overview.
© 2010 Bennett, McRobb and Farmer1 Use Case Description Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 1 Use Cases: an Introduction  Adriano Comai 1999.
CS3773 Software Engineering Lecture 03 UML Use Cases.
Conversation Form l One path through a use case that emphasizes interactions between an actor and the system l Can show optional and repeated actions l.
Documenting Requirements using Use Case Diagrams
COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Intro to System Requirements Lecture 2 Use-Cases.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Chapter 13: Designing the User Interface
Use Case Modeling. Use case diagram For each use case we develop  Object class diagram (with attributes only)  System sequence diagram (analysis) 
Chapter 7: The Object-Oriented Approach to Requirements
ConOps and Use Cases Copyright, 2003 © Jerzy R. Nawrocki Requirements Engineering.
CS 4310: Software Engineering Lecture 3 Requirements and Design.
Project Analysis Course ( ) Week 2 Activities.
Use Cases Requirements Engineering & Project Management Lecture 2.
Use Cases 2 ENGR ♯10 Peter Andreae
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
OCAN College Access Program Data Submissions Vonetta Woods HEI Analyst, Ohio Board of Regents
Use Cases Ivar Jacobson - guru at Rational Corp., defined UML.
Intro: Use Case and Use Case Diagram Documentation.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Use-Cases Elicitation and FAST Copyright, 2003 © Jerzy R. Nawrocki Requirements Engineering.
University Of Palestine. Department of Information Technology.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 20. Review Software Requirements Requirements Engineering Process.
Requirements Documentation CSCI 5801: Software Engineering.
Copyright © Jerzy R. Nawrocki The Requirements Document and IEEE 830 Requirements Engineering.
Faculty of Computer & Information
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Business Analysis with For PG MDI, Gurgaon Kamna Malik, Ph.D.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
1 Modeling System Requirements with Use Cases. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
1. The Requirements Process Requirements Input Example
UML - Development Process 1 Software Development Process Using UML.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Page 1  Copyright © 1997 by Rational Software Corporation Putting the UML to Work The ESU University wants to computerize their registration system –
Use Cases Discuss the what and how of use cases: Basics Examples Benefits Parts Stages Guidelines.
Chapter 5 Validating Form Data with JavaScript
Using Use Case Diagrams
Chapter 4: Business Process and Functional Modeling, continued
RSA Case Study.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Use Case Modeling - II Lecture # 27.
Use Cases Discuss the what and how of use cases: Basics Benefits
Requirements Engineering Lecture 2
Chapter 5 유스케이스 개요 Introduction to Use Cases
Recall The Team Skills Analyzing the Problem (with 5 steps)
Use Case Model.
UML Use Case Diagrams.
Back Office Training: Time Entry, Payroll & Paycheck Corrections
CSC480 Software Engineering
User Guide Portman Concur
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Software Requirements Specification Document
Using Use Case Diagrams
Use Case Document Example
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Chapter 5 Understanding Requirements
Interaction Modeling Extracted from textbook:
Chapter 5 Understanding Requirements
Requirements Document
Chapter 5 Understanding Requirements.
A partially automated class scheduling system
Requirements Engineering Lecture 6
Presentation transcript:

Functional Requirements (c) Jerzy Nawrocki Requirements Eng. & Project Manag. Functional Requirements Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl XPrince dla architektów

Aim of the lecture To present how to specify functional requirements with use cases.

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Agenda Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Agenda Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

Requirement in RequisitePro Rational RequisitePro name (tag), text, attributes

Attribute Matrix in RequisitePro Tag Short text Attribute Attribute Full text

Lost rationale Do we need a given functionality?

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Agenda Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

1967: Ericsson, telecommunication systems Ivar Jacobson 1967: Ericsson, telecommunication systems 1985: Ph.D., The Royal Institute of Tech., Stockholm 1987: Founder of Objectory AB 1995: Objectory AB merges with Rational 2003: IBM buys Rational http://www.analisi-disegno.com/uml/JacobsonInterview.html http://www.jaczone.com/

Use Case Diagram in UML Find flight Construct itinerary Airline reservation Travel agent Reserve flight Issue ticket Merchant bank

Use case A story describing how an actor (user or device) cooperates with the system to accomplish a given purpose.

Updating personal data A Use Case Updating personal data Actor: Member 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.

Updating personal data A Use Case Use-case name Actor: Name Main scenario: Action . . . Extensions: Step.a. Event Step.a1. Action Step.a2. Action Step.b. Event Step.b1. Action Updating personal data

Updating personal data A Use Case Use-case name Actor: Name Main scenario: Action . . . Extensions: Step.a. Event Step.a1. Action Step.a2. Action Step.b. Event Step.b1. Action Updating personal data

Updating personal data A Use Case Use-case name Actor: Name Main scenario: Action . . . Extensions: Step.a. Event Step.a1. Action Step.a2. Action Step.b. Event Step.b1. Action Member Updating personal data

Updating personal data Member enters his account and password A Use Case Use-case name Actor: Name Main scenario: Action . . . Extensions: Step.a. Event Step.a1. Action Step.a2. Action Step.b. Event Step.b1. Action Member Updating personal data Member enters his account and password

A Use Case Use-case name Actor: Name Main scenario: Action . . . Extensions: Step.a. Event Step.a1. Action Step.a2. Action Step.b. Event Step.b1. Action Member Updating personal data Member enters his account and password Account or password is incorrect

The same goal Scenario #1 Scenario #2 Scenario #3 Use cases The same goal A use case Main scenario: Step Extensions: 1a. Event 1a1. Alternative step Scenario #1 Scenario #2 Scenario #3

Shortest form of use cases Dean: Sets number of places for each MS Degree Programme. Gets list of students assigned to each MS Programme. Student: Enters her preferences by sequencing MS Degree Programmes from the most to the least interesting. Gets information about the MS Programme to which she has been assigned. Scope description

Human-Computer Interaction Description Definition of a use case A story describing how an actor (user person or device) cooperates with the system other actors (people or devices) to accomplish a given purpose.

Business Process Description Definition of a use case A story describing how an actor (user person or device) cooperates with the system other actors (people or devices) to accomplish a given purpose.

Business Process Description Get Paid for Car Accident Actors: Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representative Main: 1. Claimant submits claim with substantiating data. 2. Insurance Company verifies that Claimant owns a valid policy. 3. Insurance Company assigns Agent to examine the case. 4. Agent verifies that all details are within policy guidelines. 5. Insurance Company pays Claimant. Extensions: 1a. Submitted data is incomplete: 1a1. Insurance Company requests missing information. 1a2. Claimant supplies missing information. 2a. Claimant does not own a valid policy: . . .

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Agenda Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

Control flow in computer programs For every program there is an equivalent program using only sequence and iteration (while) as control structures. Corrado Böhm INAC-CNR, Rome C. Böhm, G. Jacopini, Flow diagrams, Turing Machines and Languages with only Two Formation Rules, Comm. of the ACM , 9(5): 366-371,1966.

Goto considered harmful Structured programming: sequence selection (if-then-else) iteration (while-do) Edsger W. Dijkstra Eindhoven Univ. of Technology E.W. Dijkstra, Go To Statement Considered Harmful, Comm. of the ACM, Volume 11 (3): 147 – 148, 1968.  

If-then-else considered harmful Boolean Primary (int n){ int i, result; if (n < 1) {result= False; ERROR "Wrong input" } else if (n==1 or n==2) result= True; else if (n % 2 == 0) result= False; else { result= True; for (i=3; i < n/2; i+=2) return result;

If-then-else considered harmful Boolean Primary (int n){ int i, result; if (n < 1) {result= False; ERROR "Wrong input" } else if (n==1 or n==2) result= True; else if (n % 2 == 0) result= False; else { result= True; for (i=3; i < n/2; i+=2) return result;

If-then-else considered harmful Boolean Primary (int n){ int i, result; if (n < 1) {result= False; ERROR "Wrong input" } else if (n==1 or n==2) result= True; else if (n % 2 == 0) result= False; else { result= True; for (i=3; i < n/2; i+=2) return result; Checking if N is a primary number Main: 1. User enters N. 2. System set an auxiliary variable RESULT to TRUE and K to 3. 3. In case N is divisible by K system sets RESULT to FALSE. 4. System increments K by 2 and returns to step 3. Extensions: 2a. N < 1 2a1. Error message is displayed. 2b. N=1 or N=2 2b1. RESULT is set to TRUE. 2c. N is even ...

If-then-else considered harmful Boolean Primary (int n){ int i, result; if (n < 1) {result= False; ERROR "Wrong input" } else if (n==1 or n==2) result= True; else if (n % 2 == 0) result= False; else { result= True; for (i=3; i < n/2; i+=2) return result; Checking if N is a primary number Main: 1. User enters N. 2. System set an auxiliary variable RESULT to TRUE and K to 3. 3. In case N is divisible by K system sets RESULT to FALSE. 4. System increments K by 2 and returns to step 3. Extensions: 2a. N < 1 2a1. Error message is displayed. 2b. N=1 or N=2 2b1. RESULT is set to TRUE. 2c. N is even ...

If-then-else considered harmful Boolean Primary (int n){ int i, result; if (n < 1) {result= False; ERROR "Wrong input" } else if (n==1 or n==2) result= True; else if (n % 2 == 0) result= False; else { result= True; for (i=3; i < n/2; i+=2) return result; Checking if N is a primary number Main: 1. User enters N. 2. System set an auxiliary variable RESULT to TRUE and K to 3. 3. In case N is divisible by K system sets RESULT to FALSE. 4. System increments K by 2 and returns to step 3. Extensions: 2a. N < 1 2a1. Error message is displayed. 2b. N=1 or N=2 2b1. RESULT is set to TRUE. 2c. N is even ...

Main Extension Use-case paradigm Start Action 1 Action 2 Action 2-1 Step 3 Step 2 Step 1 Action 1 Extension Event 2a (interrupt) Step 2-2 Step 2-1 Action 2-1 Action 2-2 Action 2 Action 3 Stop

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Agenda Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

User-valued transactions Use-case patterns Use-case names Creating employee record Deleting employee record Hiring employee Firing employee User-valued transactions Identify the valuable services that the system delivers to the actors to satisfy their business purposes.

Registering for a course Do you like it? Registering for a course Main: Display a blank schedule. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. Do. Student clicks on a course. Update the lower window to show the times the course is available. Student clicks on a course time and then clicks on the „Add Course” button. . . .

Too many user interface details Registering for a course Do you like it? Registering for a course Main: Display a blank schedule. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. Do. Student clicks on a course. Update the lower window to show the times the course is available. Student clicks on a course time and then clicks on the „Add Course” button. . . .

Behaviour description Use case patterns Behaviour description Use cases are for behavioural description. User interface should be described elsewhere.

Registering for a course Do you like it? Registering for a course Main: Display a blank schedule. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. Do. Student clicks on a course. Update the lower window to show the times the course is available. Student clicks on a course time and then clicks on the „Add Course” button. . . .

Actor Intention Accomplished Use case patterns Actor Intention Accomplished Write each step to show clearly which actor is performing the action, and what the actor gets accomplished.

Registering for a course A corrected use case Registering for a course Main: System displays a blank schedule. Student points to a course he is interested in. System shows the times the course is available. Student chooses the course. . . .

Use case patterns Use case length A use case should have from 3 to 9 steps.

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Agenda Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

Software Requirements Specification IEEE Std 830-1998 1. Introduction 2. Overall description of the product 3. Functional requirements 4. Non-functional requirements Appendices Index

Software Requirements Specification 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

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.

Identification of the product by name. 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.

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!

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.

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.

SRS Structure 1. Introduction 2. Overall description of the product 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

2.1 Product perspective E-Member 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

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.

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.

2.4 Constraints The system must obey requlations imposed by the Polish act concerning personal data [personal-data-act].

2.5 Assumptions and dependencies The presented requirements are based on requlations known as of 1 September 2005.

SRS Structure 1. Introduction 2. Overall description of the product 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

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.

Earlier approaches to FR Use cases If-then considered harmful (c) Jerzy Nawrocki Summary Earlier approaches to FR Use cases If-then considered harmful Use-case patterns Use cases and IEEE 830 XPrince dla architektów

Bechmark for Use-Case Management System What use cases (can) appear in practice? What expressions appear within them and how frequently? A „standard” (typical) FRS with use cases. Are any papers on that subject?

Thank you for your attention!