UC01: XXXXXXXXXX
Description
XXXXXXXXXXXXXXXXXXXXXXXX
Interacting Actors
· XXXXXXX
Related Use Cases
XXXXXXX
Preconditions/Assumptions for all Flows
· XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow of Events
Main Flow Description
XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow Preconditions/Assumptions
· None
Main Flow Description
1. XXXXXXXXXXXXXXXXXXXXXXXX
2 XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow Postconditions
· XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow Notes
· None.
Alternate Flow of Events #1
XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Description
XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Preconditions/Assumptions
XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Description
1. XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Postconditions
· XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Notes
· None.
Postconditions for all Flows
· None
Exceptions for all Flows
XXXXXXXXXXXXXXXXXXXXXXXX
Business Rules for all Flows
XXXXXXXXXXXXXXXXXXXXXXXX
Design Notes for all Flows
· XXXXXXXXXXXXXXXXXXXXXXXX
Issues/Comments for all Flows
· None.
]]>
在对pȝ的设计范围进行确认后Q下一阶段的工作便是划分每个业务目标的层次l构
目标层次的划分如下图Q?/p>
水^面以上的为概要目标，对相似功能业务的一U概括。对于属于概要目标范围的用例说明Q用例序号之后做(*)号以作区?/p>
水^面上的ؓ(f)用户目标Q也是业务功能炏V?/p>
水^面一下的为子功能点，包含于用L(fng)标之中。对于属于子功能范围的用例说明，最好在用例序号之后?+)号以作区?/p>
执行者与场景Q?/strong>
用例目标层次划分后，该到用户目标用例的定义，q里面最主要的概念就是执行者与场景
a.攉一个用L(fng)标的所有场景，定义L功场景。其他场景ؓ(f)扩展?/p>
L行者完成了目标Q所有系l相兌的需求都被满Iq个场景是L功场景?/p>
其他的成功场景和所有的错误处理场景Q都?x)在L功场景的扩展中进行描q?/p>
b.场景M的描q?/p>
两个执行者之间的交互q程——客戯入地址{?/p>
保护pȝ客户需求的认q程——系l确认PIN密码{?/p>
满pȝ客户需求的内部变化——系l扣除某个品的库存{?/p>
1. 使用单的语法
句子不宜q长Q句子结构不要过于复杂。^铺直叙，明扼要。重复解释一个问题，有时不失ZU必要?/p>
2. usecase步骤的描q尽量不要过?/p>
10步以内。太长不易于理解。让读者看h很繁琐?/p>
3.增加直观性，辅以囑Ş化的手段来阐释：(x)UML 的usecase图。图形唯一的缺点在于维护，一Ҏ(gu)变，可以让所有的N甅R?/p>
定pȝ边界:
1.in-out list
TopicQؓ(f)pȝ需求点。以in 标志为系l内部需求，以out标志pȝ外部需求。系l内的属于工作内容，pȝ外的属于考虑范畴。内外表法不只可以用在用例编写阶D，也可以用在需求分析阶 Dc?/p>
2 actor-goal list
]]>
1.问题与客戯成共?/p>
q个p有签字式的——协议，也有非签字式的——确认?/p>
CQ所有的p都基于双方的理解。文字的东西往往?x)引h义，?sh)话认又往往׃严肃。图形化的方法可以I补这些缺憾。个人经验，文字的描q比较适用? 早v的问题收集，或者是单的问题认。复杂的问题需要交l图形化来解冻Iwireframe——虚拟界面，是个不错的选择。它除了可以攉输入输出数据 ，q可以给客户一个比较直观的感觉。当Ӟq个也相对费时一些。但对于需求的认臛_重要Q可以减客户与软g人员的误解?/p>
2.扑և问题背后的发生原?/p>
韦伯说过Q社?x)行为是行动者赋予主观意义的人类行ؓ(f)。Q何hQ团体、组l）的活动在C会(x)中都?x)牵涉到另一个hQ团体、组l）。Q何行为本w都h意义Q如 无意义，则无行ؓ(f)?/p>
扯远了，q是谈谈需求问题。客户问题的提出Q是Z解决问题。要惌决问题，必需知道问题是如何生的。也是_(d)要想扑ֈ蛋，必需先找C蛋的鸡， 研究它的zd轨迹Q最后定位鸡蛋的位置——解决问题。在C会(x)学里Q找C行ؓ(f)的意义，也就掌握了行为本w。记住，无意义就无行为，有行为则必有意义?/p>
3.定pȝ用户
包括用户的角色和权限。这是系l能够运行v来的基本条g。如果不能引赯够的重视Q对于系l将是严重的N。笔者曾做过一个office resource managementpȝQ从初始的一个角色对应一个office,C个role对应多个office,一个h一个角ԌC个h多个角色。修改之多， 之繁重，不能与ha?/p>
4.定pȝ边界
在实践过E中Q个人引入了"内外?来定义系l边界。这个在E后的usecase中具体描q?/p>
5.划分子系l的三个原则Q?/p>
a.职责不同的功能划归不同子pȝQ将一cd含统一职责的功能划分ؓ(f)一个子pȝ。如权限理pȝ与业务系l分R（企业pȝ需要统一的权限管理：(x)安全认证 以及(qing)pȝ授权Q，再如C会(x)保障信息pȝ按业务类别的划分Q养老，ȝQ工伤，׃Q生肌Ӏ按照业务规则划分又可以分ؓ(f)Q公׃务（单位Q个人）Q待遇，? ?/p>
b.需要不同开发技能的单元划归不同子系l?如报表系l与数据仓库的独立开发?/p>
C.软g工程理的划分：(x)
1)兼顾工作量的相对均衡Q进一步切分太大的子系l。交l不同的teamq行q行开发?/p>
2)同一cd用\复用模块划分Z个子pȝQ如规则引擎Q简单报表，css
theme理Q数据同步\交换Q基q_的二ơ开?l一弹出式查?输入校验,面lg){等?/p>
题解Q做了多个系l的需求分析之后，有做ȝ的必要了?/p>
在需求分析阶D，甚至是整个Y件开发阶D，需求的变化是唯一不变的东ѝ项目中最隑ց的也是如何去控制需求。这个有点复杂，攑ֈ后箋文章去说Q先说说如何 客L(fng)问题信息转化为需求：(x)
1.分清客户的问题是“需?#8221;q是一?#8220;需?#8221;
需要，指问题已明确。需求则表示问题未明?/p>
2.分清最好有与必L?/p>
必须有，q个是硬性需求；最好有Q非性需求。根据项目的实际情况Q如成本Q时?计划)Q范围的U束来综合评定?/p>
3.客户寚w题的描述是ؓ(f)了说明问题还是提供一U解x?/p>
在收集和分析客户需求时Q一定要搞清楚客h在描q问题本w还是问题的解决Ҏ(gu)
4 有哪些h使用q个pȝ
俗语_(d)有什么样的客P有什么样的系l。客L(fng)能力以及(qing)偏好Q包括理解力Q对pȝ的设计至关重要?/p>
5.有那些h不喜Ƣ这个系l?/p>
是办公室政治Q是易用性？是稳定性？maybe something else
6.挖掘潜在问题QŞ成问题链
客户大都没有pȝ训练Q他们对问题的描q往往比较零散和随意。如何将问题H成链，挖掘更深层次的问题是需求分析h员需要帮助他们完成的。记住是帮助Q不? 他们按照你的思维思考问题。这里面最隄部分属于如果从Y件专业h员的角度提出。同时又要让自己的的不干扰到客户的原始需求?/p>
Ҏ(gu)个h的经验，需求阶D|大的(zhn)哀在于你出于最好的目的却造成了最坏的l果——徏议客户如何如何，有时?x)掩盖客L(fng)真实x。客户信L们的Q? 他们误以为我们的可以解决他们的问题，然而有时事与愿q。所以，我们应该多听客户的想法，延迟你的与引对{?/p>
7.非功能性需求的采集
易用性，扩展性，交互性，性能Q安全性等{?/p>