part ii inception - ntut.edu.twwkchen/courses/ooad/files/... · 2019-03-12 · what is inception? 3...

1

1

PART IIInception

inc. elaboration construction transition

iteration phase

development cycle

Chapter 4Inception is Not

the Requirements Phase

2

3

What is Inception? 1• What does “inception” mean?

Answer:beginning; start; commencement

4

What is Inception? 1• Inception is the initial short step to

establish a common vision and basic scope for the project – Include analysis of perhaps 10% of the use

cases, – Analysis of the critical non-functional

requirement, – Creation of a business case, and – Preparation of the development environment

so that programming can start in the following elaboration phase

3

5

What is Inception? 2• The following kinds of questions are

explored– What is the vision and business case for this project – Feasible?– Buy and/or build this system?– Rough unreliable range of cost ? Is it $10K, $100K,

millions?– Should we proceed or stop? – Do the stakeholders have basic agreement on the

vision of the project, and is it worth investing in serious investigation?

6

What is Inception? 3• Defining the vision and obtaining an order-of-magnitude

(unreliable) estimate requires doing some requirements exploration.

• However, the purpose of the inception phase is not to define all the requirements or generate a believable estimate or project plan

• Most requirements analysis occurs during the elaboration phase, in parallel with early production-quality programming and testing

4

7

How Long is Inception?• Inception phase should be relatively short for

most projects– One or a few weeks long. – On many projects, if it is more than a week long,

then the point of inception has been missed• It is to decide if the project is worth a serious investigation,

not to do that investigation

– May include the first requirements workshop, planning for the first iteration, and then quickly moving forward to elaboration

8

Sample Inception Artifacts

A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project.

Development Case

Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources.

Phase Plan & Software Development Plan

Describes what to do in the first elaboration iteration.Iteration Plan

To clarify the vision, and validate technical ideas.Prototypes and proof-of-concepts

Describes the risks (business, technical, resource, schedule) and ideas for their mitigation or response.

Risk List & Risk Management Plan

Key domain terminology, and data dictionary.Glossary

Describes other requirements, mostly non-functional. During inception, it is useful to have some idea of the key non-functional requirements that have will have a major impact on the architecture.

Supplementary Specification

Describes the functional requirements. During inception, the names of most use cases will be identified, and perhaps 10% of the use cases will be analyzed in detail.

Use-Case Model

Describes the high-level goals and constraints, the business case, and provides an executive summary.

Vision and Business Case

CommentArtifact

These artifacts are only partially completed in this phase. They will be iteratively refined in subsequent iterations

5

9

Isn't That a Lot of Documentation?

• Recall that artifacts should be considered optional. • Choose to create only those that really add value for

the project, and drop them if their worth is not proved • And since this is evolutionary development, the point is

not to create complete specifications during this phase, but initial, rough documents, that are refined during the elaboration iterations, in response to the invaluable feedback from early programming and testing

• The point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness

• Most UML diagramming will occur in the next phase -elaboration

Chapter 5Evolutionary

Requirements

6

11

Software Engineering Proverb

The sooner you start, the longer it takes. - Fred Books你愈急著開始，花的時間愈長。- Fred Brooks

這是Brooks在1975出版的The Mythical Man Month裡的一句雋語，強調軟體專案的充分準備不致於浪費，如果你跳過需求蒐集，你設計的東西就非客戶所需，如果你的設計不佳，你將會發展一些無意義的程式。以今日的軟體發展法來看，這句格言似乎理所當然，而且已歷經三十幾年，其間軟體發展方法也多所改變，但是至今仍然有用，Brooks這句格言是在提醒，從事好的設計仍然是軟體發展的重要過程。

12

Requirements Analysis 1As Marketing requested it (swing).

7

13

Requirements Analysis 2As Sales ordered it.

14

Requirements Analysis 3As Engineering designed it.

8

15

Requirements Analysis 4As Production manufactured it.

16

Requirements Analysis 5As Maintenance installed it.

9

17

Requirements Analysis 6What the customer wanted.

18

Requirements Analysis• Question: How to avoid distortions when

capturing requirements?

What the customer wanted. As Maintenance installed it.

10

19

What are Requirements? • Requirements

– capabilities and conditions to which the system (the project) must conform

• The manage requirements practice of UP– A systematic approach to finding, documenting,

organizing, and tracking the changing requirements of a system

• A prime challenge of requirements analysis is to find, communicate, and remember (write down) what is really needed, in a form that clearly speaks to the client and development team members (unambiguously)

20

What are Requirements? • Question: Given two stereo/TV systems of the

same price and picture quality, one has the following features and the other does not. Which one would you buy?– Support Karaoke/KTV? (Mic, changing keys,…)– Support iPhone dock– Support Android dock– Support Bluetooth– Support Miracast/Airplay– Support Youtube playback

Next page

You are greedy, right?

11

21

What are Requirements? • Question: If you need to pay for each of the

following additional features, would you buy all of them?– Support Karaoke/KTV? (Mic, changing keys,…)– Support iPhone dock– Support Android dock– Support Bluetooth– Support Miracast/Airplay– Support Youtube playback Nice to have

Must have

22

Actual Use of Waterfall-specified Features

Almost 65% of the waterfall-specified features were of little or no value!

Based on a study of thousands of projects

12

23

Evolutionary vs. Waterfall Requirements

• Waterfall viewing a software project as similar to predictable mass manufacturing, with low change rates– Attempts to freeze or fully define requirements at the start – Was unskillful and led to many failures

• Evolutionary requirements analysis combined with early design and programming– Start production-quality programming and testing long before

most of the requirements have been analyzed or specified – Perhaps when only 10% or 20% of the most architecturally

significant, risky, and high-business-value requirements have been specified

24

What are Skillful Means to Find Requirements

• Finding the requirements– Writing use cases with customers– Having requirements workshops that include

both developers and customers– Focusing groups with proxy customers – Having a demo of the results of each

iteration to the customers, to solicit feedback

13

25

The Types and Categories of Requirements 3

• In common usage, requirements are categorized as– functional (behavioral)– non-functional (everything else)

26


• In UP, requirements are categorized according to the FURPS+ model. – Functional: features, capability, security– Usability: human factors, help, documentation– Reliability: frequency of failure, recoverability,

predictability– Performance: response times, throughput, accuracy,

availability, resource usage.– Supportability: adaptability, maintainability,

internationalization, configurability

14

27


• The “+” in FURPS+ indicates sub-factors– Implementation: resource limitation,

languages and tools, hardware, ..– Interface: constraint imposed by interfacing

with external systems– Operations: system management in its

operational setting– Packaging: for example, a physical box– Legal: licensing and so forth

28

Requirements Organized in UP Artifacts

• The UP offers several requirements artifacts– Use case Model: primarily functional requirements– Supplementary Specification: everything not in the

use cases (Non-functional requirements)– Glossary: defines noteworthy terms (encompassed

the concept of the data dictionary)– Vision: summarizes high-level requirements that are

elaborated in the Use-Case Model and Supplementary Specification, and summarizes the business case for the project. A short executive overview document for quickly learning the project’s big picture (summary).

– Business rules (also called Domain rules): (e.g., government tax laws)

15

Chapter 6Use Cases

30

Use Case• Question: You are outsourcing a software

application system. How to do write a software specification document for your system?

16

31

Introduction• Use cases are text stories, widely used to

discover and record requirements. • The influence of UP artifacts (next page)

– High-level goals and use case diagrams are input to the creation of the use case text

– The use cases are input to many other analysis, design, implementation, project management, and test artifacts

32

Sample UP Artifact Influence

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

17

33

Use Case Example• Informally, use cases are text stories of some

actor using a system to meet goals• An example brief format use case

– Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items

34

What are Actors, Scenarios, and Use Cases? 1

• Informally, an actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier

• A scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance. – It is one particular story of using a system, or one

path through the use case• A use case is a collection of related success and

failure scenarios that describe an actor using a system to support a goal

18

35

What are Actors, Scenarios, and Use Cases? 2

• A casual format use case with alternate scenariosHandle ReturnsMain Success Scenario: A customer arrives at a checkout with

items to return. The cashier uses the POS system to record each returned item …

Alternate Scenarios:If the customer paid by credit, and the reimbursement

transaction to their credit account is rejected, inform the customer and pay them with cash.

If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted).

If the system detects failure to communicate with the external accounting system, …

36

Use Case 1• Motivation: Why Use Cases?

– Use case makes it easier for customers to contribute to their definition and review

– Use cases emphasize the user goals and perspective• A more user-centric emphasis compared to simply asking for a list

of system features

Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. …

…for (i = 0; i < 100; i++){

…}

customer

19

37

Use Case 1• Use case

– Are text documents, not diagrams• use case modeling is primarily an act of writing

text, not drawing diagrams

– There is nothing object-oriented about use cases

– Use cases are a key requirements input to classic OOA/D

38

Use Case 2• Are Use Cases Functional Requirements?

– Are functional or behavioral requirements that indicate what the system will do. In terms of the FURPS+ requirements types, they emphasize the "F", but can also be used for other types.

• The usage of use case– Decide and describe the functional requirements of the system– Bring agreement between the customer and software developer– Give a clear and consistent description of what the system

should do– Provide a basis for performing tests that verify the system

delivers the functionality stated– Trace the functional requirements into actual classes and

operations in the system

20

39

Scenarios 1• Scenario

– Is a specific sequence of actions and interactionsbetween actors and the system; it is also called a use case instance.

– It is one particular story of using a system, or onepath through the use case.

– For example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial.

I would like a book of stamps, please.

That will be $7.80.

Here is $10.

Thanks. Here are your stamps and your change.

Yes.

OK. Will that be all?

40

Scenarios 2• Scenario

– A use case represents a collection of scenarios: primary, plus zero or more alternates.

– The primary scenario corresponds to the main system interactions, usually the ‘success’ scenario.

– Alternate scenarios correspond to lessfrequent interactions and exceptions.

21

41

Another View

User Goal

Interaction 1 Interaction 2 Interaction n

…

Use case 2

Scenario 1 Scenario 2

…

Scenario n

… …

42

Three Kinds of Actors• An actor is anything with behavior

– including the system under discussion (SuD) itself when it calls upon the services of other systems.

– roles played not only by people, but by organizations, software, and machines.

• Primary and supporting actors will appear in the action steps of the use case text.

• Three kind of Actors– Primary actor has user goals fulfilled through using services.

(e.g., the cashier). Find user goals to drive the use cases.– Supporting actor provides a service (e.g., the automated

payment authorization service is an example). Often a computer system, but could be an organization or person. The purpose is to clarify external interfaces and protocols.

– Offstage actor has an interest in the behavior of the use case, but is not primary or supporting (e.g., a government tax agency).

22

43

Three Common Use Case Formats

• Brief (high level)– Terse one-paragraph summary, usually of the main success

scenario. – When? During early requirements analysis, to get a quick sense

of subject and scope. May take only a few minutes to create.

• Casual– Informal paragraph format. Multiple paragraphs that cover

various scenarios.– When? As above.

• Fully dressed– All steps and variations are written in detail, and there are

supporting sections, such as preconditions and success guarantees.

– When? After many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in detail.

44

Fully addressed Use Case Template

Such as open issues.Miscellaneous

Influences investigation, testing, and timing of implementation.

Frequency of Occurrence

Varying I/O methods and data formats.Technology and Data Variations List

Related non-functional requirements.Special Requirements

Alternate scenarios of success or failure.Extensions

A typical, unconditional happy path scenario of success.Main Success Scenario

What must be true on successful completion, and worth telling the reader.

Success Guarantee

What must be true on start, and worth telling the reader?Preconditions

Who cares about this use case, and what do they want?Stakeholders and Interests

Calls on the system to deliver its services.Primary Actor

"user-goal" or "subfunction"Level

The system under design.Scope

Start with a verb.Use Case NameCommentUse Case Section

23

45

Fully Use Case Example 1Use Case UC1: Process Sale (16 pages)

Scope: NextGen POS applicationLevel: user goalPrimary Actor: CashierStakeholders and Interests:

– Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are deducted from his/her salary.

– Salesperson: Wants sales commissions updated.– Customer: Wants purchase and fast service with minimal effort.

Wants easily visible display of entered items and prices. Wants proof of purchase to support returns.

– Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components (e.g., remote credit validation) are unavailable. Wants automatic and fast update of accounting and inventory.

46

Fully Use Case Example 2Use Case UC1: Process Sale

– Manager: Wants to be able to quickly perform overrideoperations, and easily debug Cashier problems.

– Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such as national, state, and county.

– Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store.

Preconditions: Cashier is identified and authenticated.Success Guarantee (or Postconditions): Sale is saved. Tax is correctly

calculated. Accounting and Inventory are updated. Commissionsrecorded. Receipt is generated. Payment authorization approvalsare recorded.

24

47


Main Success Scenario (or Basic Flow)1.Customer arrives at POS checkout with goods and/or services to

purchase.2.Cashier starts a new sale.3.Cashier enters item identifier.4.System records sale line item and presents item description,

price, and running total. Price calculated from a set of price rules.

Cashier repeats steps 3-4 until indicates done.5.System presents total with taxes calculated.6.Cashier tells Customer the total, and asks for payment.7.Customer pays and System handles payment.8.System logs completed sale and sends sale and payment

information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory).

9.System presents receipt.10.Customer leaves with receipt and goods (if any).

48


Extensions (or Alternative Flows)*a. At any time, Manager requests an override operation:

1. System enters Manager-authorized mode.2. Manager or Cashier performs one Manager-mode operation.

e.g., cash balance change, resume a suspended sale on another register, void a sale, etc.

3. System reverts to Cashier-authorized mode.*b. At any time, System fails: To support recovery and correct

accounting, ensure all transaction sensitive state and events can be recovered from any step of the scenario.

1. Cashier restarts System, logs in, and requests recovery of prior state.

2. System reconstructs prior state.2a. System detects anomalies preventing recovery:

1.System signals error to the Cashier, records the error, and enters a clean state.

2.Cashier starts a new sale.

25

49


Extensions (or Alternative Flows) (cont’d)1a. Customer or Manager indicate to resume a suspended sale.

1.Cashier performs resume operation, and enters the ID to retrieve the sale.

2.System displays the state of the resumed sale, with subtotal.2a. Sale not found.

1.System signals error to the Cashier.2.Cashier probably starts new sale and re-enters all

items.3.Cashier continues with sale (probably entering more items

or handling payment).2-4a. Customer tells Cashier they have a tax-exempt status (e.g.,

seniors, native peoples)1.Cashier verifies, and then enters tax-exempt status code.2.System records status (which it will use during tax

calculations)

50


Extensions (or Alternative Flows) (cont’d)3a. Invalid item ID (not found in system):

1. System signals error and rejects entry.2. Cashier responds to the error:

2a. There is a human-readable item ID (e.g., a numeric UPC):1.Cashier manually enters the item ID.2.System displays description and price.2a. Invalid item ID: System signals error. Cashier tries

alternate method2b. There is no item ID, but there is a price on the tag:

1.Cashier asks Manager to perform an override operation.2.Managers performs override.3.Cashier indicates manual price entry, enters price, and

requests standard taxation for this amount (because there is no product information, the tax engine can't otherwise deduce how to tax it)

2c. Cashier performs Find Product Help to obtain true item ID and price.

2d. Otherwise, Cashier asks an employee for the true item ID or price, and does either manual ID or manual price entry (see above).

26

51


Extensions (or Alternative Flows) (cont’d)3b. There are multiple of same item category and tracking unique

item identity not important (e.g., 5 packages of veggie-burgers):

1.Cashier can enter item category identifier and the quantity.3c. Item requires manual category and price entry (such as

flowers or cards with a price on them):1.Cashier enters special manual category code, plus the price.

3-6a: Customer asks Cashier to remove (i.e., void) an item from the purchase: This is only legal if the item value is less than the void limit for Cashiers, otherwise a Manager override is needed.

1.Cashier enters item identifier for removal from sale.2.System removes item and displays updated running total.

2a. Item price exceeds void limit for Cashiers:1.System signals error, and suggests Manager override.2.Cashier requests Manager override, gets it, and

repeats operation.

52


Extensions (or Alternative Flows) (cont’d)3-6b. Customer tells Cashier to cancel sale:

1.Cashier cancels sale on System.3-6c. Cashier suspends the sale:

1.System records sale so that it is available for retrieval on any POS register.

2.System presents a "suspend receipt" that includes the line items, and a sale ID used to retrieve and resume the sale.

4a. The system supplied item price is not wanted (e.g., Customer complained about something and is offered a lower price):

1.Cashier requests approval from Manager.2.Manager performs override operation.3.Cashier enters manual override price.4.System presents new price.

27

53


Extensions (or Alternative Flows) (cont’d)5a. System detects failure to communicate with external tax

calculation system service:1.System restarts the service on the POS node, and continues.

1a. System detects that the service does not restart.1.System signals error.2.Cashier may manually calculate and enter the tax,

or cancel the sale.5b. Customer says they are eligible for a discount (e.g., employee,

preferred customer):1.Cashier signals discount request.2.Cashier enters Customer identification.3.System presents discount total, based on discount rules.

54


Extensions (or Alternative Flows) (cont’d)5c. Customer says they have credit in their account, to apply to

the sale:1.Cashier signals credit request.2.Cashier enters Customer identification.3.Systems applies credit up to price=0, and reduces remaining credit.

6a. Customer says they intended to pay by cash but don't have enough cash:

1.Cashier asks for alternate payment method.1a. Customer tells Cashier to cancel sale. Cashier cancels sale

on System.7a. Paying by cash:

1.Cashier enters the cash amount tendered.2.System presents the balance due, and releases the cash drawer.3.Cashier deposits cash tendered and returns balance in cash to

Customer.4.System records the cash payment.

28

55


Extensions (or Alternative Flows) (cont’d)7b. Paying by credit:

1.Customer enters their credit account information.2.System displays their payment for verification.3.Cashier confirms.

3a. Cashier cancels payment step:1.System reverts to "item entry" mode.

4.System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval.

4a. System detects failure to collaborate with external system:

1.System signals error to Cashier.2.Cashier asks Customer for alternate payment.

56


Extensions (or Alternative Flows) (cont’d)5.System receives payment approval, signals approval to

Cashier, and releases cash drawer (to insert signed credit payment receipt).

5a. System receives payment denial:1.System signals denial to Cashier.2.Cashier asks Customer for alternate payment.

5b. Timeout waiting for response.1.System signals timeout to Cashier.2.Cashier may try again, or ask Customer for alternate

payment.6.System records the credit payment, which includes the

payment approval.7.System presents credit payment signature input mechanism.8.Cashier asks Customer for a credit payment signature.

Customer enters signature.9.If signature on paper receipt, Cashier places receipt in cash

drawer and closes it.

29

57


Extensions (or Alternative Flows) (cont’d)7c. Paying by check…7d. Paying by debit…7e. Cashier cancels payment step:

1.System reverts to "item entry" mode.7f. Customer presents coupons:

1.Before handling payment, Cashier records each coupon and System reduces price as appropriate. System records the used coupons for accounting reasons.

1a. Coupon entered is not for any purchased item:1.System signals error to Cashier.

9a. There are product rebates:1.System presents the rebate forms and rebate receipts for each

item with a rebate.9b. Customer requests gift receipt (no prices visible):

1.Cashier requests gift receipt and System presents it.9c. Printer out of paper.

1.If System can detect the fault, will signal the problem.2.Cashier replaces paper.3.Cashier requests another receipt.

58


Special Requirements– Touch screen UI on a large flat panel monitor. Text must be

visible from 1 meter.– Credit authorization response within 30 seconds 90% of the

time.– Somehow, we want robust recovery when access to remote

services such the inventory system is failing.– Language internationalization on the text displayed.– Pluggable business rules to be insertable at steps 3 and 7.– …

30

59


Technology and Data Variations List:*a. Manager override entered by swiping an override card through

a card reader, or entering an authorization code via the keyboard.

3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.

3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.

7a. Credit account information entered by card reader or keyboard.

7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture.

Frequency of Occurrence: Could be nearly continuous.

60


Open Issues:– What are the tax law variations?– Explore the remote service recovery issue.– What customization is needed for different businesses?– Must a cashier take their cash drawer when they log out?– Can the customer directly use the card reader, or does the

cashier have to do it?

31

61

What do the Sections in Use Case Template Mean? 1

• Scope:– bounds the system (or systems) under design

• Level:– A user-goal level use case is the common kind that describe the

scenarios to fulfill the goals of a primary actor to get work done; it roughly corresponds to an elementary business process (EBP) in business process engineering

– A subfunction-level use case describes substeps required to support a user goal, and is usually created to factor out duplicate substeps shared by several regular use cases (to avoid duplicating common text); (e.g., Pay by Credit)

Process sale

Process rentalPay by Credit

62


• Primary Actor:– The principal actor that calls upon system services to fulfill a

goal

• Stakeholders (next page) and Interests List: Important!– By starting with the stakeholders and their interests before

writing the remainder of the use case, we have a method to remind us what the more detailed responsibilities of the system should be.

– The stakeholder interest viewpoint provides a thorough and methodical procedure for discovering and recording all the required behaviors

32

63


• Project stakeholders (利害關係人)– Entities that have an interest in the project.– Stakeholders may be inside or outside an

organization– Examples of project stakeholders:

• Project leader, Project team members, Senior management, Project customer, Resource Managers, Line Managers, Product usergroup, Project testers, Subcontractors to the project, Consultantsto the project

64


• Preconditions and Success Guarantees(Postconditions): – Don't bother with a precondition or success guarantee unless

you are stating something non-obvious and noteworthy, to help the reader gain insight

– Preconditions: state what must always be true before a scenario is begun in the use case.

– Success guarantees (or postconditions): state what must be true after successful completion of the use case either the main success scenario or some alternate path

33

65


• Main Success Scenario and Steps (or Basic Flow):– Also been called the “happy path” scenario, “Basic Flow”, or

“Typical Flow”– Describes a typical success path that satisfies the interests of

the stakeholders– The scenario records the steps of three kinds:

• An interaction between actors (Note: actor can be a system)• A validation (usually by the system)• A state change by the system (e.g., recording or modifying

something)– It is a common idiom to always capitalize the actors' names

(e.g., Cashier) for ease of identification– Often does NOT include any conditions or branching (next page)

• Defer all conditional and branching statements to the Extensions section.

66


• Question: Why deferring all conditional and branching statements to the Extensions section?

34

67


• Extensions (or Alternate Flows):– Extensions are important and normally comprise the majority

of the text– Indicate all the other scenarios or branches, both success and

failure– In thorough use case writing, the combination of the happy

path and extension scenarios should satisfy "nearly" all the interests of the stakeholders

• Non-functional requirements expressed in the Supplementary Specification rather than the use cases

– An extension has two parts: the condition and the handling

68

Guideline: Write in an Essential UI-Free Style 2

• Question: which of the following writings is better? (A) or (B)?

(A)

…5a. System detects failure to communicate with external tax calculation system…

(B)…External tax calculation system not working…

35

69


• Extensions (continue)– Guideline: When possible, write the condition as something

that can be detected by the system or an actor.• Example (preferable)

– 5a. System detects failure to communicate with external tax calculation system service:

• Example (not preferred)– 5a. External tax calculation system not working:

• The former style is preferred because this is something the system can detect; the latter is an inference

– Extension handling can be summarized in one step, or include a sequence (3a; 2-4a)

– At the end of extension handling, the scenario merges back with the main success scenario, unless the extension indicates otherwise (such as by halting the system)

70


• Extensions (continue)– Sometimes, a particular extension point is quite complex, (e.g.,

"paying by credit" extension). This can be a motivation to express the extension as a separate subfunction-level use case

• 7b. Paying by credit:– Customer enters their credit account information.– System sends payment authorization request to an external Payment

Authorization Service System, and requests payment approval.– 2a. System detects failure to collaborate with external system:

1. System signals error to Cashier.2. Cashier asks Customer for alternate payment.

– If it is desirable to describe an extension condition as possible during any steps, the labels *a, *b, …, can be used

36

71


• Performing Another Use Case Scenario– Sometimes, a use case branches to perform another use case

scenario. For example, the story Find Product Help is a distinct use case that is sometimes performed while within Process Sale

– In Cockburn notation, performing this second use case is shown with underlining

• Special Requirements:– If a non-functional requirement, quality attribute, or constraint

relates specifically to a use case, record it with the use case. – These include qualities such as performance, reliability, and

usability, and design constraints (often in I/O devices) that have been mandated or considered likely

72


• Technology and Data Variations List:– Often there are technical variations in how something must be

done, but not what, and it is noteworthy to record this in the use case.

– A common example is a technical constraint imposed by a stakeholder regarding input or output technologies (e.g., support credit account input using a card reader and the keyboard)

– It is also necessary to understand variations in data schemes, such as using UPCs or EANs for item identifiers, encoded in bar code symbology

37

Use cases give context

73

• Question: Why not use a feature list to capture the requirements? Is the following feature list a good requirement document? (next page)

Feature List1. The system can record sales2. The cashier can enter items to the system3. The system can show running total4. The system can handle payments5. The system can produce receipts6. The system can compute taxes

74

Use cases give context• Good context information better

understanding

楊過吐出一口鮮血 (遇襲?)

Yan spits out some blood (ambushed?)

楊過坐正，吐出一口鮮血 (比武後?)

Yan sits up and spits out some blood (after a fight?)

楊過坐正，張嘴吐出一口鮮血 (不緊急?)

Yan sits up, opens his mouth, and spits out some blood (not urget?)

The Romance of the Condor Heroes

38

Use cases give context

75

楊過坐正，張嘴吐出一口鮮血，鬆了一口氣 (吐血是好事?)

Yan sits up, opens his mouth, and spits out some blood. He feels relieved.(blood spitting is good?)

經過幾番折騰，楊過坐正，張嘴吐出一口鮮血，鬆了一口氣 (故意的？)

After several rounds, Yan sits up, opens his mouth, and spits out some blood. He feels relieved. (on purpose?)

經過幾番折騰，牙醫終於拔出智齒，楊過坐正，張嘴吐出一口鮮血，鬆了一口氣 (!@#$%^)

After several rounds, the dentist finally takes out Yan’s wisdom tooth. Yan sits up, opens his mouth, and spits out some blood. He feels relieved.

(!@#$%^?)

76

Use cases give context• Good context information better

understanding

• Difficult to understand little or no context information

• Use cases give context and keep readers from getting lost in a sea of requirements (next page)

39

77

Use cases give contextFeature List1. The system can record

sales2. The cashier can enter

items to the system3. The system can show

running total4. The system can handle

payments5. The system can produce

receipts6. The system can compute

taxes

Main Success Scenario1.Customer arrives at POS checkout with

goods and/or services to purchase.2.Cashier starts a new sale.3.Cashier enters item identifier.4.System records sale line item and

presents item description, price, and running total. Price calculated from a set of price rules.

Cashier repeats steps 3-4 until indicates done.

5.System presents total with taxes calculated.

6.Cashier tells Customer the total, and asks for payment.

7.Customer pays and System handles payment.

8.System logs completed sale …9.System presents receipt.

No context information

78


• Question: which of the followings related to login is better? (A) or (B)?

(A)

…Administrator enters ID and password in dialog box (see Picture 3).System authenticates Administrator.…

(B)

…Administrator identifies self.System authenticates identity.…

40

79


• Guideline– Write use cases in an essential style; keep the user interface

out and focus on actor intent• During a requirements workshop, the cashier may say

one of his goals is to "log in." – The cashier was probably thinking of a GUI, dialog box, user ID,

and password. This is a mechanism to achieve a goal, rather than the goal itself.

– This root-goal discovery process can open up the vision to new and improved solutions

• Essential Style Writing– During early requirements work, "keep the user interface out,

focus on intent." – The narrative is expressed at the level of the user's intentions

and system's responsibilities rather than their concrete actions – They remain free of technology and mechanism details,

especially those related to the UI

80


• Concrete Style - Avoid, During Early Requirements Work.– Concrete style, user interface decisions are embedded in

the use case text. • Administrator enters ID and password in dialog box (see Picture 3).• System authenticates Administrator.• System displays the "edit users" window (see Picture 4).• …

– Essential Style: Assume that the Manage Users use case requires identification and authentication:

• …• Administrator identifies self.• System authenticates identity.

41

81

Guideline: Write Terse Use Cases

• Guideline: Write Terse Use Cases– Delete "noise" words. – Even small changes add up, such as "System

authenticates…" rather than "The System authenticates…"

82

Guideline: Write Black-Box Use Cases

• Question: which of the follows is the best? (A), (B), or (C)?

(A)…The system records the sale.…

(B)…The system writes the sale to a database.…

(C)…The system generates a SQL INSERT statement for the sale.…

42

83

Guideline: Write Black-Box Use Cases

• Guideline: Write Black-Box Use Cases– Do not describe the internal workings of the system,

its components, or design. – Specify what the system must do (the behavior or

functional requirements) without deciding how it will do it (the design).

– The definition of "analysis" versus "design" is "what" versus "how."

Black-box style Not Black-box style

The system records the sale.

The system writes the sale to a database. … or (even worse):

The system generates a SQL INSERT statement for the sale…

84

Guideline: Take an Actor and Actor-Goal Perspective

• Guideline: Take an Actor and Actor-Goal Perspective– Write requirements focusing on the users or actors

of a system, asking about their goals and typical situations.

– Focus on understanding what the actor considers a valuable result.

– The old feature and function list approach to capturing requirements is not good because it did not encourage asking who is using the product, and what provides the value.

43

85

Guideline: How to Find Use Cases 1

• Guideline: How to Find Use Cases?– The basic procedure is:

1. Choose the system boundary. 2. Identify the primary actors

that have goals fulfilled through using services of the system.

3. Identify the goals for each primary actor.4. Define use cases that satisfy user goals; name

them according to their goal. Usually, user-goal level use cases will be one-to-one with

user goals

86


• Step 1. Choose the system boundary.

– Is it just a software application, the hardware and application

as a unit, that plus a person using it, or an entire organization?

44

87


• Step 2. Identify the primary actors– that have goals fulfilled through using services of the

system.

• Guideline: Brainstorm the primary actors first, as this sets up the framework for further investigation

88

Who Is The Primary Actor?• Is the Cashier or Customer the Primary Actor?

– Depends on the system boundary of the system under design, and who we are primarily designing the system for

• Primary actors and goals at different system boundaries

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collect taxes on sales Sales Activity

System

Goal: Analyze sales and performance data

45

89

Who Is The Primary Actor?• NextGen POS

– The customer is an actor, but not a primary actor– The cashier is the primary actor because the system is being

designed to serve the cashier’ goals.– The system does not have a UI or functionality designed for the

customer• Ticket-buying Website

– The system is designed for the customer to use directly– Showing the customer as the primary actor is correct.

• Ticket-buying with a phone agent– When a customer calls in, the agent is simply a proxy of the

customer– The system is not designed to meet the goals of the agent– Showing the customer as the primary actor is correct.

90


• Step 3. Identify the goals for each primary actor• Questions to Help Find Actors and Goals?

– Who starts and stops the system?– Who does system administration?– Who does user and security management?– Is "time" an actor because the system does something in

response to a time event?– Is there a monitoring process that restarts the system if it fails?– Who evaluates system activity or performance?– How are software updates handled? Push or pull update?– Who evaluates logs? Are they remotely retrieved?– In addition to human primary actors, are there any external

software or robotic systems that call upon services of the system?

– Who gets notified when there are errors or failures?

46

91

Why Ask About Actor Goals Rather Than Use Cases?

• The viewpoint of use case modeling is to find these actors and their goals, and create solutions that produce a result of value

• Imagine we are together in a requirements workshop. We could ask either:– "What do you do?" (roughly a task-oriented question) or,– "What are your goals whose results have measurable value?"– Prefer the second question since it opens up the vision for new

and improved solutions, focus on adding business value, and get to the heart of what the stakeholders want from the system

92


• Step 4: Define Use Cases– Define one use case for each user goal. – Name the use case similar to the user goal

• For example, Goal: process a sale; Use Case: Process Sale.

– Start the name of use cases with a verb.– A common exception to one use case per goal is to

collapse CRUD (create, retrieve, update, delete) separate goals into one CRUD use case, idiomatically called Manage .

• For example, the goals "edit user," "delete user," and so forth are all satisfied by the Manage Users use case.

47

93

Guideline: What Tests Can Help Find Useful Use Cases 1

• Question: Which of the followings are valid use cases (for application requirements analysis)?– Negotiate a Supplier Contract– Handle Returns– Log In– Move Piece on Game Board (Monopoly)

94


• What is a useful level to express use cases for application requirements analysis? The rules of thumb:– The Boss Test– The EBP Test– The Size Test

Negotiate a Supplier Contract

Boss Test

EBP Test

Size Test

48

95


• The Boss Test– Your boss asks, "What have you been doing all day?"

You reply: "Logging in!" Is your boss happy?– If yes, the use case passes Boss Test– If not, the use case fails Boss Test

• It may be a use case at some low goal level, but not the desirable level of focus for requirements analysis.

– That doesn't mean to always ignore boss-test-failing use cases.

• User authentication may fail the boss test, but may be important and difficult

96


• The EBP Test– Elementary Business Process (EBP)

• A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state, e.g., Approve Credit or Price Order

– Does the use case reflect an EBP?• If yes, the use case passes EBP Test• If not, the use case fails EBP Test

49

97


• The Size Test– A use case typically contains many steps (often

require 3~10 pages of text in the fully dressed format)

• A use case is very seldom a single step/action– Is the use case big enough (having many steps)?

• If yes, the use case passes Size Test.• If not, the use case fails Size test.

– A common mistake is to define just a single step as a use case, such as defining a use case called Enter an Item ID.

– You can see a hint of the error by its small size

98


• Applying the TestsBoss Test EBP Test Size Test

Negotiate a Supplier ContractHandle ReturnsLog InMove Piece on Game Board

Not OK: much broader and longer than an EBP. Could be modeled as a business use case, rather than a system use case

OK

OKOK

OK

OK

Not OKOK

NA

OK

NANot OK

50

99


• Most use cases should satisfy the tests, but exceptionsare common– It is sometimes useful to write separate subfunction-level use

cases (e.g., "paying by credit")– Authenticate User is may be complex enough to warrant careful

analysis (e.g., single sign-on”).

100

Applying UML: Use Case Diagrams 1

• UML Use Case Diagram– Illustrates the names of use cases and actors, and the

relationships between them• Use case diagram is an excellent picture of the system

context; – It makes a good context diagram– Showing the boundary of a system, what lies outside of it, and

how it gets used. – It serves as a communication tool that summarizes the behavior

of a system and its actors. • Guideline: Downplay Diagramming, Keep it Short and

Simple.– If an organization is spending many hours/days working on a

use case diagram and discussing use case relationships, rather than focusing on writing text, effort has been misplaced.

51

101


«actor»

102


NextGen

Process Sale

Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

«actor»Payment

AuthorizationService

Notation suggestions

52

103


Alternate actor notation

To clarify, some prefer to highlight external computer system actors with an alternate notation

104

Applying UML: Activity Diagrams

• Use cases involve process and workflow analysis– Activity diagrams can be a useful alternative or adjunct to

writing the use case text, especially for business use cases that describe complex workflows involving many parties and concurrent actions

– See UML activity diagram in page 477

53

105

Motivation: Other Benefits of Use Cases 1

• Other benefits– Use cases are a simple, widely-understood form (a story or

scenario form).– Another motivation is to replace detailed, low-level

function lists with use cases

106

Motivation: Other Benefits of Use Cases 2

• High-Level System Feature Lists Are Acceptable – A terse, high-level feature list, called system features, added

to a Vision document can usefully summarize system functionality.

– Summary of System Features, for POS.• sales capture• payment authorization (credit, debit, check)• system administration for users, security, code and

constants tables, and so on• …

• When Are Detailed Feature Lists Appropriate Rather than Use Cases?– Sometimes use cases do not really fit; some applications cry

out for a feature-driven viewpoint (e.g., application servers, database products, and other middleware or back-end systems)

54

107

Example: Monopoly GameUse Case UC1: Play Monopoly GameScope: Monopoly applicationLevel: user goalPrimary Actor: ObserverStakeholders and Interests:

Observer: Wants to easily observe the output of the game simulation.Main Success Scenario:

1.Observer requests new game initialization, enters number of players.2.Observer starts play.3.System displays game trace for next player move (see domain rules, and "game

trace" in glossary for trace details).Repeat step 3 until a winner or Observer cancels.

Extensions:*a. At any time, System fails:

(To support recovery, System logs after each completed move)1.Observer restarts System.2.System detects prior failure, reconstructs state, and prompts to continue.3.Observer chooses to continue (from last completed player turn).

Special Requirements:Provide both graphical and text trace modes.

108

Work With Use Cases in Iterative Methods

• UP encourages use-case driven development. – Functional requirements are primarily recorded in use cases– Use cases are an important part of iterative planning. The work

of an iteration is in part defined by choosing some use case scenarios, or entire use cases.

– Use cases are a key input to estimation.– Use-case realizations drive the design. The team designs

collaborating objects and subsystems in order to perform or realize the use cases.

– Use cases often influence the organization of user manuals.– Functional or system testing corresponds to the scenarios of

use cases.– UI "wizards" or shortcuts may be created for the most common

scenarios of important use cases to ease common tasks.

55

109

Evolve Use Cases Across the Iterations 1

Discipline Artifact Incep1 week

Elab 14 weeks

Requirements

Use-Case Model

2-day requirements workshop. Most use cases identified by name, and summarized in a short paragraph. Pick 10% from the high-level list to analyze and write in detail. This 10% will be the most architecturally important, risky, and high-business value.

Near the end of this iteration, host a 2-dayrequirements workshop. Obtain insight and feedbackfrom the implementation work, then complete 30% of the use cases in detail.

110

Evolve Use Cases Across the Iterations 2

Elab 24 weeks

Elab 33 weeks

Elab 43 weeks

Near the end of this iteration, host a 2-dayrequirements workshop. Obtain insight and feedback from the implementation work, then complete 50% of the use cases in detail.

Repeat, complete 70% of all use cases in detail.

Repeat with the goal of 80~90% of the use cases clarified and written in detail.

Only a small portion of these have been built in elaboration; the remainder are done in construction.

56

111

Process And Setting Context For Writing Use Cases

January February

Use Case: Capture a Sale. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

Use Case: Handle Returns. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

WhenOnce during inception. Short; do not try to define or polish all requirements.

Several times during elaboration iterations.

WhereAt a requirements workshop.

WhoMany, including end users and developers, will play the role of requirements specifier, helping to write use cases.

Led by system analyst who is responsible for requirements definition.

How: ToolsSoftware:

For use case text, use a web-enabled requirements tool that integrates with a popular word processor.

For use case diagrams, a UML CASE tool.Hyperlink the use cases; present them on the project website.

Hardware: Use two projectors attached to dual video cards and set the display width double to improve the spaciousness of the drawing area or display 2 adjacent word processor windows .

Developer

CustomerSystemAnalyst

End User

Two adjacent projections.

SoftwareArchitect

112

Sample UP Artifacts and Timing

sSW Architecture Document

rsDesign ModelDesign

rsGlossary

rsSupplementary Specification

rsVision

rsUse-Case ModelRequirements

sDomain ModelBusiness Modeling

C1..CnE1..EnI1Iteration

Const.Elab.Incep.ArtifactDiscipline

57

113

Case Study: Use Cases in the NextGen Inception Phase

Cash InCash OutManage UsersStart UpShut DownManage System Tables…

Process RentalAnalyze Sales ActivityManage Security…

Process SaleHandle Returns

BriefCasualFully Dressed

Chapter 7Other

Requirements

58

115

Other Requirement Artifacts • Supplementary Specification

– Captures and identifies other kinds of requirements, such as reports, documentation, packaging, supportability, licensing, ..

• Vision– Summarizes the "vision" of the project an executive summary. It

serves to tersely communicate the big ideas.• Glossary

– Captures terms and definitions; it can also play the role of a data dictionary.

• Business Rules (or Domain Rules)– Capture long-living and spanning rules or policies, such as tax

laws, that transcend one particular application.• Guideline: These Artifacts should be at the Project

Website

Required in the homework assignments

116

Reliable Specifications: An Oxymoron?

• Writing a Vision and Supplementary Specification is worthwhile as an exercise in clarifying a first approximation of what is wanted– the motivation for the product, and as a repository for the big

ideas. – But they are not nor is any requirements artifact a reliable

specification

• Treat written requirements lightly, start programming early, and continually ideally, daily engage users and tests for feedback

59

117

POS Supplementary Specification 1

• Revision History

Craig Larman

First draft. To be refined primarily during elaboration.

Jan 10, 2031

Inception draft

AuthorDescriptionDateVersion

• Introduction– This document is the repository of all NextGen POS

requirements not captured in the use cases.• Functionality

– Functionality common across many use cases– Logging and Error Handling

• Log all errors to persistent storage.

118


– Pluggable Rules• At various scenario points of several use cases (to be defined) support the

ability to customize the functionality of the system with a set of arbitrary rules that execute at that point or event.

– Security• All usage requires user authentication.

• Usability– Human Factors:

• The customer will be able to see a large-monitor display of the POS. Therefore:

– Text should be easily visible from 1 meter.– Avoid colors associated with common forms of color blindness.

• Speed, ease, and error-free processing are paramount in sales processing, as the buyer wishes to leave quickly, or they perceive the purchasing experience (and seller) as less positive.

• The cashier is often looking at the customer or items, not the computer display. Therefore, signals and warnings should be conveyed with sound rather than only via graphics.

60

119


• Reliability– Recoverability: if there is failure to use external services

(payment authorizer, accounting system, ...) try to solve with a local solution (e.g., Store and forward) in order to still complete a sale. Much more analysis is needed here...

• Performance: – As mentioned under human factors, buyers want to complete

sales processing very quickly. One bottleneck is external payment authorization. Our goal: authorization in less than1 minute, 90% of the time.

• Supportability– Adaptability:

• Different customers of the NextGen POS have unique business rule and processing needs while processing a sale. Therefore, at several defined points in the scenario (for example, when a new sale is initiated, when a new line item is added) pluggable business rule will be enabled.

120


– Configurability• Different customers desire varying network configurations for their

POS systems, such as thick versus thin clients, two-tier versus N-tier physical layers, and so forth. In addition, they desire the ability to modify these configurations, to reflect their changing business and performance needs. Therefore, the system will be somewhat configurable to reflect these needs. Much more analysis is needed in this area to discover the areas and degree of flexibility, and the effort to achieve it.

• Implementation Constraints– NextGen leadership insists on a Java technologies solution,

predicting this will improve long-term porting and supportability, in addition to ease of development.

• Purchased Components– Tax calculator. Must support pluggable calculators for different

countries.

61

121


• Free Open Source Components– In general, we recommend maximizing the use of free Java technology

open source components on this project.– Although it is premature to definitively design and choose components,

we suggest the following as likely candidates:• JLog logging framework• …

• Interfaces– Noteworthy Hardware and Interfaces

• Touch screen monitor (this is perceived by operating systems as a regular monitor, and the touch gestures as mouse events)

• Barcode laser scanner (these normally attach to a special keyboard, and the scanned input is perceived in software as keystrokes)

• Receipt printer• Credit/debit card reader• Signature reader (but not in release 1)

122


– Software Interfaces• For most external collaborating systems (tax calculator, accounting,

inventory, ... ) we need to be able to plug in varying systems and thus varying interfaces.

• Application-Specific Domain (Business) Rules– (See the separate Business Rules document for general rules.)

ID Rule Changeability Source

RULE1 Purchaser discount rules. Examples:Employee 20% off.Preferred Customer 10% off.Senior15% off.

High.Each retailer uses different rules.

Retailer policy.

62

123



RULE2 Sale (transaction-level) discount rules.Applies to pre-tax total. Examples:10% off if total greater than $100 USD.5% off each Monday.10% off all sales from 10am to 3pm today.Tofu 50% off from 9am-10am today.

High.Each retailer uses different rules, and they may change daily or hourly.

Retailer policy.


RULE 3 Product (line item level) discount rules.Examples:10% off tractors this week.Buy 2 veggieburgers, get 1 free.

High.Each retailer uses different rules, and they may change daily or hourly.

Retailer policy.

124


• Legal Issues– We recommend some open source components if their licensing

restrictions can be resolved to allow resale of products that include open source software.

– All tax rules must, by law, be applied during sales. Note that these can change frequently.

• Information in Domains of Interest– Pricing

• In addition to the pricing rules described in the domain rules section, note that products have an original price, and optionally a permanent markdown price. A product's price (before further discounts) is the permanent markdown price, if present. Organizations maintain the original price even if there is a permanent markdown price, for accounting and tax reasons.

63

125


– Credit and Debit Payment Handling• When an electronic credit or debit payment is approved by a

payment authorization service, they are responsible for paying the seller, not the buyer. Consequently, for each payment, the seller needs to record monies owing in their accounts receivable, from the authorization service. Usually on a nightly basis, the authorization service will perform an electronic funds transfer to the seller's account for the daily total owing, less a (small) per transaction fee that the service charges.

– Sales Tax• Sales tax calculations can be very complex, and regularly change

in response to legislation at all levels of government. Therefore, delegating tax calculations to third-party calculator software (of which there are several available) is advisable. Tax may be owing to city, region, state, and national bodies. Some items may be tax exempt without qualification, or exempt depending on the buyer or target recipient (for example, a farmer or a child).

126


– Item Identifiers: UPCs, EANs, SKUs, Bar Codes, and Bar Code Readers

• The NextGen POS needs to support various item identifier schemes. UPCs (Universal Product Codes), EANs (European Article Numbering) and SKUs (Stock Keeping Units) are three common identifier systems for products that are sold. Japanese Article Numbers (JANs) are a kind of EAN version.

64

127


Question: Can you write a good requirement documentation, including both functional and non-function requirements?

Experience

128

Commentary: Supplementary Specification 1

• Supplementary specification– Captures other requirements, information, and

constraints not easily captured in the use cases or glossary

– Including system-wide "URPS+" (usability, reliability, performance, supportability, and more) quality attributes or non-functional requirements.

• Non-functional requirements specific to a use case can be first briefly written within in the special requirements section of the use case

65

129


• Elements of the Supplementary Specification– FURPS+

• Some functions or features don't fit in a use case format. we did think of the functionality in terms of features, such as "add EJB Entity Bean 1.0 support."

– Reports– Hardware/software constraints (operating and networking

systems, …)– Development constraints (for example, process or development

tools)– Other design and implementation constraints– Internationalization concerns (units, languages)

130


• Elements of the Supplementary Specification – Documentation (user, installation, administration) and help– Licensing and other legal concerns– Packaging– Standards (technical, safety, quality)– Physical environment concerns (for example, heat or vibration)– Operational concerns (for example, how do errors get handled,

or how often should backups be done?)– Application-specific domain rules– Information in domains of interest (for example, what is the

entire cycle of credit payment handling?)

66

131


• Quality Attributes (or "-ilities") – These include usability, reliability, and so forth.– Architectural analysis and design are largely concerned with

the identification and resolution of the quality attributes in the context of the functional requirements.

• Functionality in the Supplementary Spec? – Shouldn't that be in the Use Cases? (some functions don’t fit)

• Application-Specific Domain (Business) Rules– General, broad domain rules such as tax laws belong in the UP

Business Rules artifact, as a central shared repository. – However, more narrow application-specific rules, such as how

to calculate a line-item discount, can be recorded in the Supplementary Specification

• Information in Domains of Interest– Provide context and deeper insight for the development team– Document may contain pointers to important literature or

experts, formulas, laws, or other references.

132

NextGen Example: (Partial) Vision 1

67

133



Craig Larman


Jan 10, 2031

Inception draft


• Introduction– We envision a next generation fault-tolerant point-of-sale

(POS) application, NextGen POS, with the flexibility to support varying customer business rules, multiple terminaland user interface mechanisms, and integration with multiple third-party supporting systems.

• Positioning

134


– Business Opportunity• Existing POS products are not adaptable to the customer's business,

in terms of varying business rules and varying network designs (for example, thin client or not; 2, 3, or 4-tier architectures). In addition, they do not scale well as terminals and business increase. And, none can work in either on-line or off-line mode, dynamically adapting depending on failures. None easily integrate with many third-party systems. None allow for new terminal technologies such as mobile PDAs. There is marketplace dissatisfaction with this inflexible state of affairs, and demand for a POS that rectifies this.

– Problem Statement• Traditional POS systems are inflexible, fault intolerant, and

difficult to integrate with third-party systems. This leads to problems in timely sales processing, instituting improved processes that don't match the software, and accurate and timely accounting and inventory data to support measurement and planning, among other concerns. This affects cashiers, store managers, system administrators, and corporate management.

68

135


– Product Position Statement• Terse summary of who the system is for, its outstanding features,

and what differentiates it from the competition– Alternatives and Competition...

• Stakeholder Descriptions– Market Demographics...– Stakeholder (Non-User) Summary...– User Summary...– Key High-Level Goals and Problems of the Stakeholders

• A one-day requirements workshop with subject matter experts and other stakeholders, and surveys at several retail outlets led to identification of the following key goals and problems:

136


High-Level Goal

Priority Problems and Concerns Current Solutions

Fast, robust, integrated sales processing

high Reduced speed as load increases.Loss of sales processing capability if components fail.Lack of up-to-date and accurate information from accounting and other systems due to non-integration with existing accounting, inventory, and HR systems. Leads to difficulties in measuring and planning.Inability to customize business rulesto unique business requirements.Difficulty in adding new terminal or user interface types (for example, mobile PDAs).

Existing POS products provide basic sales processing, but do not address these problems.

. . . . . . . . . . . .

69

137


– User-Level Goals• The users (and external systems) need a system to fulfill these

goals:– This may be the Actor-Goal List created during use-case modeling, or

a more terse summary.– Cashier: process sales, handle returns, cash in, cash out– System administrator: manage users, manage security, manage system

tables– Manager: start up, shut down– Sales activity system: analyze sales data– …

– User Environment…• Product Overview

– Product Perspective• The NextGen POS will usually reside in stores; if mobile terminals are used,

they will be in close proximity to the store network, either inside or close outside. It will provide services to users, and collaborate with other systems, as indicated in Figure Vision-1.

138


– Summary of Benefits

NextGen POS

Cashier

System Administrator

Store Manager

Calls upon services

Calls upon services

冠ctor?Payment

AuthorizationService

冠ctor?Tax Calculator

冠ctor?Accounting

System

冠ctor?Human

Resources System

冠ctor?Inventory System

冠ctor?Sales Activity

System

Supporting Feature Stakeholder BenefitFunctionally, the system will provide all the common services a sales organization requires, including sales capture, payment authorization, return handling, and so forth.

Automated, fast point-of-sale services.

Automatic detection of failures, switching to local offline processing for unavailable services.

Continued sales processing when external components fail.

Pluggable business rules at various scenario points during sales processing.

Flexible business logic configuration.

Real-time transactions with third-party systems, using industry standard protocols.

Timely, accurate sales, accounting, and inventory information, to support measuring and planning.

. . . . . .

Figure vision- 1. NextGen POS system context diagram

70

139


– Assumptions and Dependencies...– Cost and Pricing...– Licensing and Installation...

• Summary of System Features– sales capture– payment authorization (credit, debit, check)– system administration for users, security, code and constants tables,

and so forth.– automatic offline sales processing when external components fail– real-time transactions, based on industry standards, with third-party

systems, including inventory, accounting, human resources, tax calculators, and payment authorization services

– definition and execution of customized "pluggable" business rules at fixed, common points in the processing scenarios

– …• Other Requirements and Constraints

– Including design constraints, usability, reliability, performance, supportability, design constraints, documentation, packaging, and so forth: See the Supplementary Specification and use cases.

As discussed below, system features are a terse format to summarize functionality.

140

Commentary: Vision 1• When someone joins the project, it is useful to be able

to say, – "Welcome! Please go read the 7-page Vision at the project

website."

• It is also useful to have an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project.

• It should summarize some of the information in the Use-Case Model and Supplementary Specification

71

141

Commentary: Vision 2• The Key High-Level Goals and Problems of the

Stakeholders – This section summarizes the goals and problems at a high level

often higher than specific use cases and reveals important non-functional and quality goals that may belong to one use case or span many, such as

• We need fault-tolerant sales processing.• We need the ability to customize the business rules

– Guideline: Some Facilitation Methods (group facilitation techniques to discover root problem and goals, and support idea generation and prioritization)

• Mind mapping, product vision box creation, fishbone diagrams, pareto diagrams, brainstorming, multi-voting, dot voting, nominal group process, brainwriting, and affinity grouping.

• Apply several of these during the same workshop

142

Commentary: Vision 3• Summary of System Features

– Simply listing the use case names is not sufficient in the Vision to grasp the major features

• Too detailed or low-level. People want a short summary of the big ideas. There could be 30 or 50 use cases

• The use case name can hide interesting major features stakeholders really want to know about (e.g., payment authorization functionality is embedded in the Process Sale use case)

• Some noteworthy features span or are orthogonal to the use cases. (e.g., during the first NextGen requirements workshop, someone might say “The system should be able to interact with existing third-party accounting, inventory, and tax calculation systems.”)

72

143

Commentary: Vision 4• Summary of System Features

– An alternative, complementary way to express system functions is with features, or more specifically in this context, system features

• System features are high-level, terse statements summarizing system functions.

– In the UP, a system feature is "an externally observable service provided by the system which directly fulfills a stakeholder need ."

– Features are behavioral functions a system can do. They should pass this linguistic test:

• The system does .• E.g. The system does payment authorization.

– How to Write the Feature List? • Guideline: Terse is good in the Vision — indeed, in any

document.

144

Commentary: Vision 5• It is common to organize a two-level hierarchy of

system features. For example:– The major features include:– POS services:

• sales capture• payment authorization• …

– Inventory management:• automatic reordering• …

• How many system features should the Vision contain? • Guideline

– A Vision with less than 10 features is desirable — more can't be quickly grasped. If more, consider grouping and abstracting the features.

73

145

Commentary: Vision 6• Guideline: Should We Duplicate Other Requirements in

the Vision?– For other requirements, avoid their duplication or near-

duplication in both the Vision and Supplementary Specification (SS). Rather, record them only in the SS. In the Vision, direct the reader to the SS for the other requirements.

• Guideline: Should You Write the Vision or Use Cases First? – It isn't useful to be rigid about the order. (one artifact

influences and helps clarify another)– Nevertheless, a suggested sequence is:

• Write a brief first draft of the Vision.• Identify user goals and the supporting use cases by name.• Write some use cases in detail, and start the Supplementary

Specification.• Refine the Vision, summarizing information from these.

146

NextGen Example: A (Partial) Glossary 1


Craig Larman


Jan 10, 2031Inception draft


• Definition

Validation by an external payment authorization service that they will make or guarantee the payment to the seller.

payment authorization

A product or service for saleitem

AliasesValidation Rules

FormatDefinition and InformationTerm

74

147

NextGen Example: A (Partial) Glossary 2

……

Universal Product Code

Digit 12 is a check digit.

12-digit code of several subparts.

Numeric code that identifies a product. Usually symbolized with a bar code placed on products.See www.uc-council.org for details of format and validation.

UPC

A composite of elements electronically sent to an authorization service, usually as a char array. Elements include: store ID, customer account number, amount, and timestamp.

payment authorization request

AliasesValidation Rules

FormatDefinition and InformationTerm

148

Commentary: Glossary (Data Dictionary) 1

• The Glossary is a list of noteworthy terms and their definitions• Guideline: Start the Glossary early. It will quickly become a

repository of detailed information.• In the UP, the Glossary also plays the role of a data dictionary

– A document that records data/metadata. • During inception the glossary should be a simple document of

terms and descriptions. • During elaboration, it may expand into a data dictionary.• Term attributes could include:

– aliases– description– format (type, length, unit)– relationships to other elements– range of values– validation rules

constitute requirements with implications on the behavior of the system

75

149

Commentary: Glossary (Data Dictionary) 2

• Guideline: Can We use the Glossary to Record Composite Terms?– The Glossary is not only for atomic terms such as "product

price."– It can include composite elements such as "sale" (which

includes date and location) and nicknames used to describe a collection of data transmitted between actors in the use cases.

– E.g. in the Process Sale use case, • System sends payment authorization request to an external

Payment Authorization Service, and requests payment approval.• "Payment authorization request" is a nickname for an aggregate of

data, which needs to be explained in the Glossary.

150

NextGen Example: Business Rules (Domain Rules) 1


Craig Larman


Jan 10, 2031Inception draft


• Definition

The policy of virtually all credit authorization companies.

Buyer "signature" will continue to be required,but within 2 years most of our customers want signature capture on a digital capture device, and within 5 years we expect there to be demand for support of the new unique digital code "signature" now supported by USA law.

Signature required for credit payments.

RULE1

SourceChangeabilityRuleID

76

151

NextGen Example: Business Rules (Domain Rules) 2

credit authorization company policy

LowCredit payment reversals may only be paid as a credit to the buyer's credit account, not as cash.

RULE3

lawHigh. Tax laws change annually, at all government levels.

Tax rules. Sales require added taxes. See government statutes for current details.

RULE2

SourceChangeabilityRuleID

152

Commentary: Domain Rules• Domain rules (business rules) dictate how a domain or

business may operate. – They are not requirements of any one application– Company policies, physical laws (e.g. how oil flows

underground), and government laws are common domain rules.• It's useful to identify and record domain rules in a

separate application-independent artifact– This analysis can be shared and reused across the organization

and across projects.• The rules can help clarify ambiguities in the use cases

– NextGen POS, if the Process Sale use case should be written with an alternative to allow credit payments without signature capture, there is a business rule (RULE1) that clarifies whether this will not be allowed by any credit authorization company.

77

153

Evolutionary Requirements in Iterative Methods

rsData Model

sSW Architecture Document

rsDesign ModelDesign

rsBusiness Rules

rsGlossary

rsSupplementary Specification

rsVision

rsUse-Case ModelRequirements

sDomain ModelBusiness Modeling

T1..T2C1..CnE1..EnI1Iteration

Trans.Const.Elab.Incep.ArtifactDiscipline

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks fal

part ii inception - ntut.edu.twwkchen/courses/ooad/files/... · 2019-03-12 · what is inception? 3...

Documents