Unit 1 UseCase（用例）

1.Reading（阅读）

1.1 Read the texts on use cases（阅读以下各个用例文本）

Text 1 What Is a Use Case

·Scenario-based requirements process

·Focus on functional requirements

◆"what" the system will do instead of "how"

◆describe the interactions between the system and its users

1.Terminology of Use Case

●Actors

The people or external computer systems that will communicate with your system.

●Goals

The things that the Actors want to achieve.

·Use Case Title

Each Goal turns into a Use Case Title.The title is a verb phrase and describes what the Actor wants to do.

·Use Case Body

A bunch of things that describe the "joint requirements" of the system and its Actors:main sunny-day scenario,preconditions,postconditions,frequency,performance,business rules and notes.

Fig.1-1 A Use Case Diagram

Fig.1-2 A Simple Text Use Case

·Non-use-case Requirements

Use Cases are usually only one-third of the volume of requirements.You also need business rules,computational algorithms,constraints,user interface guidelines and prototypes,and non-functional requirements.

2.Forms of Use Cases

3.Format of Use Case

(1)For each use case,write a "sunny-day scenario" (a scenario where everything works well).

(2)You can add failure branches later:

·Scenarios describing how to recover from failing steps

·Scenarios describing how to clean up when a scenario can not reach its goal

But do not spend a lot of time on failures until you write and review the success scenarios.

Use case writing is an iterative process…

(3)Make it clear "who has the ball" at each step of a scenario.

·Use active voice in each step.

·The "subject" of each sentence is either the name of an actor or "the system".

4.An Example of a Use Case

·Goal:Buy a book on the web

·Who wants to do it?A Customer.

·What do they need?A web connection and a credit card.

·How do they start?Go to http://www.amazon.com.

·What is the normal sequence of events?

(1)Customer clicks on "search",and types in a title.

(2)System displays a list of books that match.

(3)Customer chooses a book from the list,and clicks on "buy this book".

(4)System prompts the user for credit card and delivery details.

(5)Customer provides the requested information.

(6)System checks if the credit card is valid.

(7)System displays the finished order,sends the order number to the Customer.

5.Notes on Use Case Writing

·Use cases are the easiest way to describe functional requirements.

·Write them in a language that makes sense to developers and users.

6.What Is a "Failure Scenario"?

·Description of how the system fails.

◆One of the steps of the main scenario fails,the system performs a smooth shutdown.

◆One of the steps fails,the system "recovers".

◆Failure might be caused by a user (invalid input).

◆Failure could be resource exhaustion (ATM runs out of cash).

◆Failure could be a real external failure (network failure,virus,etc.).

7.Important Rules for Reviewing Use Cases

·There are two important kinds of reviewers:

◆Users/stakeholders:they look for things that might be missing in the requirements.

◆ Technical users of the requirements (designers,coders,and testers):they want the requirements to be complete and unambiguous.

· Pretend to be one of the actors—can you write the first chapter of the user manual from the use cases?

Text 2 What Is a Use Case Scenario?

When a cardholder tries to withdraw cash from an ATM,things do not always happen the same way.Sometimes he gets his money,sometimes he might have insufficient funds,or the ATM may be out of cash.These can be examples of use case scenarios.

1.Capturing Use Case Scenarios with Descriptions

Once we understand the actor and the goal for a use case,and the key use case scenarios,we can begin some high-level interaction design.Actors interact with the system by pressing buttons,typing into text boxes and clicking on icons to achieve the goal.

A classic mistake at this early stage of design lies in the technical detail and a specific user interface design.This is the wrong time to make these low-level decisions.We first need to understand the business logic,so we can focus on the business goal.Instead of saying the user presses the "enter" button,we say the user confirms his choice.

A good way to write use case is to split the actions into two columns,one for actors and the other for the system.Then we can see the order of events in a scenario,and who is doing what.

These use case descriptions will form the basis of our high-level object oriented design,the UI design,system test design,and user documentation.

Fig.1-3 A Use Case:The Order of Events and the Responsibilities of the Actor(s) and System in a Scenario

WARNING!

99%of teams are unaware that use case descriptions above are not system requirements documents.These are high-level interaction designs.

2.Describe Use Case Scenarios with Sequence Diagrams

If you are familiar with UML sequence diagrams,then you can describe a use case scenario above with a sequence diagram.This also shows the order of events,the interactions,and who is doing what.

Fig.1-4 A Use Case Scenario with a Sequence Diagram

1.2 High Frequency Vocabulary（常用词汇）

usecase 用例 scenario n.场景，剧情

based adj.基于……的 requirement n.需求

process n/v.过程；处理 focuson 关注

functional adj.功能的 what pron.什么

is v.是 system n.系统

will v.会，将要 do v.做

not adv.不，非 how adv.如何

describe v.描述 interaction n.交互

between prep.在……之间 and conj.和，与

its adj.它的 user n.使用者，用户

one num.一个，一 her det.她的

more adj.更多的，更加 actor n.参与者

terminology n.术语 people n.人，人们

computer n.计算机 communicate v.交流

with prep.与，用 goal n.目标

thing n.事情，事物 want v.要

achieve v.达到，取得 title n.标题，标签，书名

each pron.每个 turn into 变成

verb phrase 动词短语 body n.主体

abunch of 一组，一群 joint adj.联合的，共同的

main adj.主要的 sunnyday 艳阳天

precondition n.前提条件 postcondition n.后续条件

frequency n.频率 performance n.执行，性能

business n.业务，商务 rule n.规则

note n.注解，注释 non-prefix.非

are v.是 usually adv.通常

only adv.仅仅 one-third n.三分之一

you pron.你 volume n.量

also adv.也 need v.需要

computational adj.计算的 algorithm n.算法

interface n.界面 guideline n.指引，指导

prototype n.原型，框架 some det.一些

basic adj.基本的 concept n.概念

diagram n.图，图表 simple adj.简单的

text n.文本，文字 add v.添加

withdraw v.提取，取回 cash n.现金

his det.他的 card n.卡

read v.读 information n.信息

enter v.输入 detail n.详情，细节

important adj.重要的 format n.格式

documentation n.文件编撰，记录everything pron.事事，每件事

work v.运作，工作 well adv.好

can v.能 failure n.失败

where adv./其中；conj.在……地方branch n.分支

later adv.之后 recover v.恢复，复原

failing adj.失败的 step n.步骤

clean up 清理 reach v.到达

but conj.但是 spend v.花费

a lot of　许多　time　n.　时间

until conj.直至 write v.写

review v.回顾，评估 success n.成功

iterative adj.重复的 make v.确保，制作

clear adj.清楚的 whohastheball 谁掌控局势

active voice　主动语态　subject　n.　主语

sentence n.句子 either adv.也

name n.名字 if conj.如果，是否

be v.是，会 perform v.执行，实施

way n.方式 start v.开始

from prep.从 finish v.结束

or conj.或者 easiest adj.最容易的

language n.语言 makesense 有意义，说得通

developer n.程序员，开发人员example n.例子

buy v.买 book n.书

web n.互联网 customer n.客户

who pron.谁 connection n.连接

credit card　信用卡　go　v.　去

normal adj.正常的 sequence n.序列

event n.事件 click v.点击

search n./v.搜索 type v.打字

display v.显示 list n./v.清单；列举

match v.匹配 choose v.选择

prompt v.提示 delivery n.送货，交货

provide v.提供 request v.请求

check v.检查 valid adj.合法的

order n./v.订单，顺序；订购send v.发送

number n.号码，数字 most adv./adj.最；大多数

then conj.然后 stakeholder n.利益攸关方

architect n.设计师 tester n.测试员

coder n.程序员 stage n.阶段

missing adj.缺失的 constraint n.限制

when conj.何时，当……的时候document n./v.文件，记录

might v.可能 description n.描述

smooth adj.平稳的 shutdown n.关闭，关机

cause v.造成，导致 invalid adj.非法的，无效的

input v./n.输入

could v.能 resource n.资源

exhaustion n.枯竭 run out 耗尽，用完

real adj.真的 external adj.外部的

network n.网络 virus n.病毒

two num.二 thereare 有

kind n.种，类 reviewer n.审查人

look for 寻找 requirement n.要求，需求

designer n.设计师 test n.测试

they pron.他/它/她们 complete adj./v.完整的；完成

unambiguous adj.没有歧义的 pretend v.假装

first adv.首先 chapter n.章

manual n.手册 cardholder n.持卡人

always adv.总是 happen v.发生

same adj.同样的 sometimes adv.有时

get v.得到，变得 money n.钱

have v.有 insufficient adj.不足的

fund n.金额，资金 may v.可能

outof 缺乏 capture v.捕捉

once conj.一旦 we pron.我们

understand v.懂得，理解 key n.关键，答案，键

begin v.开始 high-level adj.高层次的，高水平的

design v./n.设计 interact v.交互作用

press v.按，压 button n.按钮

text box　文本框　icon　n.　图标

classic adj.经典的 mistake n.错误

early adj.早期的 into prep.进入

technical adj.技术的 specific adj.特殊的，特定的

wrong adj.错误的 low-level adj.低层次的，低水平的

decision n.决定，决策 logic n.逻辑

instead of 代替；不是……say v.说

confirm v.确认 choice n.选择

good adj.好的 split v.拆分

action n.行动，行为 column n.栏目

see v.看见 form v./n.形成；表单，形式

object-oriented adj.面向对象的 UI n.用户界面

withdrawal n.取钱，提款 option n.选项

specify v.指定，说明 amount n.金额，数量

sufficient adj.足够的 eject v.弹出，推出

take v.取，拿 dispense v.发放

debit v.借记 account n.账户

thank v.感谢 welcome v./n.欢迎

await v.等待 next adj.下一个的

warning n.警告 team n.团队

unaware adj.不知道 above prep.在……以上

without prep.没有，无须 responsibility n.责任

show v.显示 this pron.这，这个

1.3 Language Points（语言点）

（1）英语词汇主要可分类为名词（n.）、动词（v.）、形容词（adj.）、代词（pron.）、数词（num.）等。名词表示物体、概念等，动词表示动作，形容词描述其后接名词的性质，例如simple。

（2）动词通过加后缀可以变成名词。例如interact是动词，加ion后变为interaction，变成名词。学习者应该记住若干常用后缀。

（3）动词词尾加ed或ing可以变成形容词。例如request是动词，词尾加ed后成requested，变成形容词“被要求的”；或者加ing后成requesting，变成形容词“请求的”。

（4）英语名词分为可数名词和不可数名词。可数名词如果要表示数量不止一个，一般要在词尾加s或者es。如document加s成为documents，表示“多个文件”。汉语词汇没有相应用法，中国人往往忘记加s或es。不可数名词没有多数概念，不能加复数词尾。中国人学习名词时应注意词典中的［N-UNCOUNT］标志，如果有则是不可数名词。例如，不论你认为有多少信息，都只能说information，而不能说informations。这也是中国人学习英语的一个难点。

（5）有些名词单数变复数不是单数词尾加s或es的规则变化，而是有较大差异的拼写形式。如data是复数，datum是单数。注意不要在data后面再加s。这类不规则名词的复数变化也是容易出错的。

（6）英语动词可以进一步划分为及物动词和不及物动词。及物动词表示动作通常直接涉及某个对象，例如buy a book（买一本书），a book就是buy这个动作所涉及的对象，放在buy后面，所以语法上称a book为宾语。及物动词在词典中的标志为vt.。因为中文有类似用法，中国人通常不会在这方面出错。不及物动词表示的动作通常不涉及任何对象。例如，the system fails（系统出错）中，动词fail后面不跟名词，没有动作对象，不能直接加宾语。不及物动词在词典中的标志为vi.。中式英语的表现形式之一就是把不及物动词当及物动词用。学习者查词典时一定要注意动词是否标志为vi.。

（7）有时不及物动词表示的动作确实需要涉及某个对象，而不及物动词又不能直接后接宾语，这时就要使用介词（prep.）作中介，联系不及物动词和它的宾语。例如communicate（交流）是不及物动词，如果要涉及交流的对象，如the system（系统），就要使用介词with来连接，即communicate with the system。不同的动词只能按照习惯用法搭配特定的介词，不能乱用。为了避免错误，学习者应该多查词典或互联网上的例句。

（8）有些动词同时具备及物和不及物两种词性，例如run可以作不及物动词：the system runs well；也可以作及物动词，如run the system。

（9）动词涉及的对象即宾语，由名词或名词短语表示。在动词短语中，一个动词可以后接不止一个宾语。如果有两个宾语，要用and（和）连接两个宾语，如need web connection and a credit card。

1.4 Reading Comprehension （阅读理解）

1.4.1 Judge whether the following statements are true(T)or false(F)according to Text 1.

根据Text 1的内容判断下列说法正确与否。

T F

（1）用例是一种功能需求描述。（　）（　）

（2）用例说明系统应做什么，不是怎么做。（　）（　）

（3）用例描述人机互动。（　）（　）

（4）用例中的作用者只能指人。（　）（　）

（5）一个用例只能有一个目标。（　）（　）

（6）用例主体包括多个需求。（　）（　）

（7）用例能表示所有软件需求。（　）（　）

（8）用例只能用文本格式表示。（　）（　）

（9）一个用例必须有一个成功场景。（　）（　）

（10）必须同时为用例写失败场景。（　）（　）

（11）场景的每一步要写明谁是主导角色。（　）（　）

（12）可以用主动句或被动句描写各个步骤。（　）（　）

（13）文中的用例案例是关于网购电器的。（　）（　）

（14）用例是写给开发人员看的。（　）（　）

（15）失败场景不包括外部因素。（　）（　）

（16）用例可以用来开发测试用例。（　）（　）

（17）用例可以用于写使用手册。（　）（　）

1.4.2 Judge whether the following statements are true (T)or false(F) according to Text 2.

根据Text 2的内容判断下列说法正确与否。

T F

（1）用例不是用于底层设计。（　）（　）

（2）用例应该包括技术细节的说明。（　）（　）

（3）用例应该用较为抽象的语言描述各个步骤。（　）（　）

（4）用例的步骤应该分列于作用者栏和系统栏。（　）（　）

（5）步骤的前后顺序不重要。（　）（　）

（6）用例等于需求规约。（　）（　）

（7）图1-3（Fig.1-3）和图1-4（Fig.1-4）是同一个用例的两种表示方式。（　）（　）