1
play

1 Functional requirements: Michael Jackson s Design Functional - PDF document

Dec 17, 2023 •137 likes •211 views

Today s goals Requirements How can we document requirements? What are different ways of writing Use Cases? When do Use Cases (do not) fit for Use Cases capturing requirements? CS361 4-2 1 Announcements Homework 2 First

  1. Today ’ s goals Requirements ❚ How can we document requirements? ❚ What are different ways of writing Use Cases? ❚ When do Use Cases (do not) fit for Use Cases capturing requirements? CS361 4-2 1 Announcements Homework 2 ❚ First project iteration (started this week) ❚ Divide each project team into pairs ❙ Milestone 1 is due end of this week ❚ 1) Make use case diagram of system ❙ Look at the grading rubric ❚ 2) Make actor-goal list ❚ HW 2 ❚ 3) Write use case briefs for 2 use cases ❙ Three phases: submission ( Jan 23rd ), peer review ❚ 4) Write casual use cases for the 2 ( Jan 29th ), review the reviewer ( Feb 1 st ) ❚ 5) Write fully dressed use cases for the 2 CS361 5-3 CS361 5-4 Capturing functional Requirements requirements ❚ Functional requirements ❚ Inputs, outputs, and the relationship ❙ inputs, outputs, and the relations between them between them ❚ Non-functional requirements ❚ Use Cases useful for business systems • security • scalability • reliability • maintainability ❚ Formats, standard interfaces • efficiency • portability ❚ Business rules and complex formula • usability • ... CS361 4-5 CS361 4-6 1

  2. Functional requirements: Michael Jackson ’ s Design Functional requirements methodology ❚ Command language Lathe Required ❙ The “ get ” command will transfer ... Behavior Machine of lathe ❚ Web pages Operator ❙ Input forms, dynamic pages Specification Requirements ❚ Connections to other systems ❙ Files, sockets, XML, … Spreadsheet Required ❚ Reports, displays Behavior Machine of spreadsheet Operator CS361 4-7 CS361 4-8 Non-functional requirements Nonfunctional requirements ❚ Performance ❚ Technology ❙ Must answer a query in 3 seconds ❙ Must use Java ❚ Usability ❚ Business ❙ New user must be able to finish buying a book in 15 ❙ Must get it finished in 1 year spending less minutes than $1,000,000. ❙ 90% of users must say they like interface ❚ Maintainability ❙ New programmers should be able to fix first bug in two weeks on the job CS361 4-9 CS361 4-10 System description ❚ Functional requirements - in theory, can specify ❚ Typical description has two parts completely ❚ Non-functional requirements - hard to specify, ❙ data can’t specify completely ❙ operations on that data ❚ Requirements should be specific, so you can tell ❚ Three possible descriptions whether you met them. ❚ Requirements should be as precise as ❙ Requirements: the what part necessary, but no more ❙ Specification ❙ Design: the how part CS361 4-11 CS361 4-12 2

  3. Many notations Many purposes ❚ UML ❚ Communicate to ❙ Use cases ❙ User ❙ Class diagram ❙ Developers ❙ State diagram ❙ Boss ❚ Finite state machine ❚ Data flow diagram ❚ Complete - lots of detail ❚ Programming language ❚ Easy to read - less detail ❚ Pseudocode CS361 4-13 CS361 4-14 Health Claims Processing ❚ R1) Receives health claims and ❚ R4) Fields with low confidence levels are supporting documents via many sources: repaired by hand. Certain types of claims electronically, fax, on paper. are transmitted to an offshore data entry vendor. ❚ R2) Scanned paper and fax processed by OCR. Documents first subject to form ❚ R5) Match the plan and the health care dropout, deskewing, despeckling. provider. ❚ R3) All images are logged to optical disk. ❚ R6) Existing mainframe system processes accepted claims and sends notifications through the Post Office CS361 3-15 CS361 3-16 Use case diagram ❚ R7) Determine if claim can be paid, and ❚ Shows context - what is in and out of the how much. If there are inconsistencies, system suspend the claim until a human ❚ Shows actors and use cases (adjudicator) can look at it. ❚ Shows relationships between actors and ❚ R8) Adjudicator looks at documents use cases about claim and history of client and can ask for more information, can accept claim, or can reject claim. CS361 3-17 CS361 3-18 3

  4. Claims Processing System ❚ Actor: Role of something or someone that Paper claim <<include>> Knowledge interacts with System Provider Worker Fax to claim ❚ Use case: Something that the System Automatic Claim Processing does, or that happens to the System. Electronic claim Always involves an actor. Mainframe ❚ System: The thing you are studying Adjudication Adjudicator Post office CS361 3-19 Systems Context Diagram Resources for Use Cases for Claims Processing ❚ Invented by Ivar Jacobsen Claim adjudicator Data entry Data repair ❚ Popularized by Alistair Cockburn Electronic Claims Processing Mainframe ❚ http://alistair.cockburn.us/index.php/ claim System Resources_for_writing_use_cases Fax Postal ❙ Use Case Fundamentals System Postal ❙ Use Cases, Ten Years Later System ❙ Sample systems requirement document CS361 4-21 CS361 4-22 Use Cases Use cases ❚ Text - a form of writing. ❚ Describe the sequence of events that happen when the system responds to a ❚ Describes the system ’ s behavior as it request responds to a request from an actor. ❙ Can describe alternatives ❚ Many kinds of use cases ❙ Can describe errors ❙ Brief / detailed ❙ Requirement / specification / design CS361 4-23 CS361 4-24 4

  5. Use cases are text Parts of use case ❚ Use cases should be easy to read ❚ Primary actor – who starts it? ❙ keep them short ❚ Why the use case? Primary actor has goal. ❙ tell a story ❚ Normal steps ❙ write full sentences with active verb phrases ❚ Alternative steps (errors, options) ❙ make the actors visible in each sentence CS361 4-25 CS361 4-26 Many ways of writing use Use Cases and cases Requirements ❚ User stories ❚ An important part of requirements ❚ Actor-goal list ❚ Help manage requirements ❚ Use case briefs ❚ Help requirement traceability ❚ Casual use cases ❚ “ Fully dressed ” use cases CS361 4-27 CS361 4-28 Traceability Manage requirements ❚ Traceability - the ability to trace the effect ❚ Must agree to change in requirements of a requirement and determine who ❙ Usually increases price caused it ❙ Must be reviewed ❙ Why do we have this requirement? Who ❚ Make sure each part of design is due to a wrote it? requirement ❙ How is this requirement met? ❚ Analyze problems: what was the root ❙ What requirement caused this design? cause of this bug? ❙ Backward and forward traceability CS361 4-29 CS361 4-30 5

  6. When use cases don ’ t Scenarios and Use Cases work ❚ Scenario is concrete and detailed ❚ Compilers ❙ names of people ❙ one use case - compile a program ❙ $ values, particular dates, particular amounts ❚ Despeckler ❚ Scenario is a test case ❙ one use case - remove speckles ❚ Use Case is a contract, and collects all the ❚ No interaction scenarios ❚ Complexity is caused by ❙ input format ❙ transformation CS361 4-31 CS361 4-32 Summary Reading ❚ Use cases are useful, but not perfect ❚ Read UML distilled ❚ Many ways to write use cases ❚ Read http://alistair.cockburn.us/ index.php/ ❚ Big projects need big use cases Resources_for_writing_use_cases ❚ Use the simplest way you can! CS361 4-33 CS361 4-34 6

Recommend

More recommend