1 / 61

Functional Requirements

Requirements Eng. & Project Manag. Functional Requirements. Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl. Aim of the lecture. To present how to specify functional requirements with use cases . Agenda. Earlier approaches to FR Use cases If-then considered harmful Use-case patterns

cybil
Download Presentation

Functional Requirements

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 Eng. & Project Manag. Functional Requirements Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl

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

  3. Agenda • Earlier approaches to FR • Use cases • If-then considered harmful • Use-case patterns • Use cases and IEEE 830

  4. Agenda • Earlier approaches to FR • Use cases • If-then considered harmful • Use-case patterns • Use cases and IEEE 830

  5. Requirement in RequisitePro • name (tag), • text, • attributes Rational RequisitePro

  6. Attribute Matrix in RequisitePro Tag Short text Attribute Attribute Full text

  7. Lost rationale Do we need a given functionality?

  8. Agenda • Earlier approaches to FR • Use cases • If-then considered harmful • Use-case patterns • Use cases and IEEE 830

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

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

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

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

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

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

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

  16. A Use Case • Use-case name • Actor: Name • Main scenario: • Action • Action • 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

  17. A Use Case • Use-case name • Actor: Name • Main scenario: • Action • Action • 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

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

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

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

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

  22. 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: . . .

  23. Agenda • Earlier approaches to FR • Use cases • If-then considered harmful • Use-case patterns • Use cases and IEEE 830

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

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

  26. 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) result= False; } return result; }

  27. 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) result= False; } return result; }

  28. 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) result= False; } 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 ...

  29. 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) result= False; } 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 ...

  30. 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) result= False; } 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 ...

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

  32. Agenda • Earlier approaches to FR • Use cases • If-then considered harmful • Use-case patterns • Use cases and IEEE 830

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

  34. 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. • . . .

  35. Too many user interface details 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. • . . .

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

  37. 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. • . . .

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

  39. 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. • . . .

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

  41. Agenda • Earlier approaches to FR • Use cases • If-then considered harmful • Use-case patterns • Use cases and IEEE 830

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

  43. IEEE Std 830-1998 Software Requirements Specification • 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

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

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

  46. 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!

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

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

  49. IEEE Std 830-1998 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

  50. Member E-Member PolCard Board 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.

More Related