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

1

1

Requirements

Use Cases

Today’s goals

❚ How can we document requirements? ❚ What are different ways of writing Use Cases? ❚ When do Use Cases (do not) fit for capturing requirements?

CS361 4-2

Announcements

❚ First project iteration (started this week)

❙ Milestone 1 is due end of this week ❙ Look at the grading rubric

❚ HW 2

❙ Three phases: submission (Jan 23rd), peer review (Jan 29th), review the reviewer (Feb 1st)

CS361 5-3 CS361 5-4

Homework 2

❚ Divide each project team into pairs ❚ 1) Make use case diagram of system ❚ 2) Make actor-goal list ❚ 3) Write use case briefs for 2 use cases ❚ 4) Write casual use cases for the 2 ❚ 5) Write fully dressed use cases for the 2

CS361 4-5

Requirements

❚ Functional requirements

❙ inputs, outputs, and the relations between them

❚ Non-functional requirements

• scalability
• maintainability
• portability
• ...
• security
• reliability
• efficiency
• usability

CS361 4-6

Capturing functional requirements

❚ Inputs, outputs, and the relationship between them ❚ Use Cases useful for business systems ❚ Formats, standard interfaces ❚ Business rules and complex formula

2

CS361 4-7

Functional requirements

❚ Command language

❙ The “get” command will transfer ...

❚ Web pages

❙ Input forms, dynamic pages

❚ Connections to other systems

❙ Files, sockets, XML, …

❚ Reports, displays

CS361 4-8

Functional requirements:

Michael Jackson’s Design methodology

Spreadsheet Operator Machine Required Behavior

• f spreadsheet

Lathe Operator Machine Required Behavior

• f lathe

Specification Requirements

CS361 4-9

Non-functional requirements

❚ Performance

❙ Must answer a query in 3 seconds

❚ Usability

❙ New user must be able to finish buying a book in 15 minutes ❙ 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-10

Nonfunctional requirements

❚ Technology

❙ Must use Java

❚ Business

❙ Must get it finished in 1 year spending less than $1,000,000.

CS361 4-11

❚ Functional requirements - in theory, can specify completely ❚ Non-functional requirements - hard to specify, can’t specify completely ❚ Requirements should be specific, so you can tell whether you met them. ❚ Requirements should be as precise as necessary, but no more

CS361 4-12

System description

❚ Typical description has two parts

❙ data ❙ operations on that data

❚ Three possible descriptions

❙ Requirements: the what part ❙ Specification ❙ Design: the how part

3

CS361 4-13

Many notations

❚ UML

❙ Use cases ❙ Class diagram ❙ State diagram

❚ Finite state machine ❚ Data flow diagram ❚ Programming language ❚ Pseudocode

CS361 4-14

Many purposes

❚ Communicate to

❙ User ❙ Developers ❙ Boss

❚ Complete - lots of detail ❚ Easy to read - less detail

CS361 3-15

Health Claims Processing

❚ R1) Receives health claims and supporting documents via many sources: electronically, fax, on paper. ❚ R2) Scanned paper and fax processed by

• OCR. Documents first subject to form

dropout, deskewing, despeckling. ❚ R3) All images are logged to optical disk.

CS361 3-16

❚ R4) Fields with low confidence levels are repaired by hand. Certain types of claims are transmitted to an offshore data entry vendor. ❚ R5) Match the plan and the health care provider. ❚ R6) Existing mainframe system processes accepted claims and sends notifications through the Post Office

CS361 3-17

❚ R7) Determine if claim can be paid, and how much. If there are inconsistencies, suspend the claim until a human (adjudicator) can look at it. ❚ R8) Adjudicator looks at documents about claim and history of client and can ask for more information, can accept claim, or can reject claim.

CS361 3-18

Use case diagram

❚ Shows context - what is in and out of the system ❚ Shows actors and use cases ❚ Shows relationships between actors and use cases

4

CS361 3-19

❚ Actor: Role of something or someone that interacts with System ❚ Use case: Something that the System does, or that happens to the System. Always involves an actor. ❚ System: The thing you are studying

Provider Fax to claim Electronic claim Automatic Claim Processing Knowledge Worker Paper claim Claims Processing System

<<include>>

Mainframe Post office Adjudication Adjudicator

CS361 4-21

Resources for Use Cases

❚ Invented by Ivar Jacobsen ❚ Popularized by Alistair Cockburn ❚ http://alistair.cockburn.us/index.php/ Resources_for_writing_use_cases

❙ Use Case Fundamentals ❙ Use Cases, Ten Years Later ❙ Sample systems requirement document

CS361 4-22

Systems Context Diagram for Claims Processing

Claims Processing System Electronic claim Postal System Mainframe Claim adjudicator Fax Data repair Postal System Data entry

CS361 4-23

Use Cases

❚ Text - a form of writing. ❚ Describes the system’s behavior as it responds to a request from an actor. ❚ Many kinds of use cases

❙ Brief / detailed ❙ Requirement / specification / design

CS361 4-24

Use cases

❚ Describe the sequence of events that happen when the system responds to a request

❙ Can describe alternatives ❙ Can describe errors

5

CS361 4-25

Use cases are text

❚ Use cases should be easy to read

❙ keep them short ❙ tell a story ❙ write full sentences with active verb phrases ❙ make the actors visible in each sentence

Parts of use case

❚ Primary actor – who starts it? ❚ Why the use case? Primary actor has goal. ❚ Normal steps ❚ Alternative steps (errors, options)

CS361 4-26 CS361 4-27

Many ways of writing use cases

❚ User stories ❚ Actor-goal list ❚ Use case briefs ❚ Casual use cases ❚ “Fully dressed” use cases

CS361 4-28

Use Cases and Requirements

❚ An important part of requirements ❚ Help manage requirements ❚ Help requirement traceability

CS361 4-29

Traceability

❚ Traceability - the ability to trace the effect

• f a requirement and determine who

caused it

❙ Why do we have this requirement? Who wrote it? ❙ How is this requirement met? ❙ What requirement caused this design? ❙ Backward and forward traceability

CS361 4-30

Manage requirements

❚ Must agree to change in requirements

❙ Usually increases price ❙ Must be reviewed

❚ Make sure each part of design is due to a requirement ❚ Analyze problems: what was the root cause of this bug?

6

CS361 4-31

Scenarios and Use Cases

❚ Scenario is concrete and detailed

❙ names of people ❙ $ values, particular dates, particular amounts

❚ Scenario is a test case ❚ Use Case is a contract, and collects all the scenarios

CS361 4-32

When use cases don’t work

❚ Compilers

❙ one use case - compile a program

❚ Despeckler

❙ one use case - remove speckles

❚ No interaction ❚ Complexity is caused by

❙ input format ❙ transformation

CS361 4-33

Summary

❚ Use cases are useful, but not perfect ❚ Many ways to write use cases ❚ Big projects need big use cases ❚ Use the simplest way you can!

CS361 4-34

Reading

❚ Read UML distilled ❚ Read http://alistair.cockburn.us/ index.php/ Resources_for_writing_use_cases