信息学院第五章.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * 为了发现用例模型的错漏。 功能需求的完备性：现有的用例模型是否完整地描述了系统功能，这也是判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么需要抽象一些新的用例来记录这些需求，或是将它们归纳在一些现有的用例之中。 模型是否易于理解。用例模型最大的优点就在于它应该易于被与软件相关的各类人员所理解，因而用例建模最主要的指导原则就是它的可理解性。 * * * * * * * * * * 在一般的用例图中，我们只表述参与者和用例之间的关系，即它们之间的通讯关联。 除此之外，我们还可以描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include)、扩展(extend)和泛化(generalization)关系。 利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来重用，使得用例模型更易于维护。 但是在应用中要小心选用这些关系，一般来说这些关系都会增加用例和关系的个数，从而增加用例模型的复杂度。而且一般都是在用例模型完成之后才对用例模型进行调整，所以在用例建模的初期不必要急于抽象用例之间的关系。 * * * * * * * * * * * * 防止两人以上同时对一模块修改，导致混乱。比如你用souresafe时。你在进入修改前，必须先check-in，表示此模块正被你修改，其他组成员此时只能看，而不能改，否则乱套。当你完成修改后。再check-out，那么其他组成员才可以check-in. * * 系统的内部特性 系统为了满足合同、规范或其他规定文档所需具有的条件或能力 业务需求（business requirement） 用户需求（user requirement） 功能需求（functional requirement） 同时也包括非功能需求、软件需求规格说明（software requirements specification，SRS）等。 * * 1)业务需求其实是业务建模流程，在这个流程中，参与者主要是业务流程分析员。主要目的是对企业目前的业务流程进行评估，并根据要进行的项目，确定进行何种程度的业务建模（你要做一个ERP项目就意味着你必须优化业务流程，而上对个部门级MIS项目就没有必要用牛刀了）。 2)然后你会得到一个叫做业务前景（Business Vision）的东西，其实就是项目成功后会是个什么样子，并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，业务需求就是需求过程的宪法，任何需求不得与之相违背。 * 用户需求——用户要干什么，先不要考虑系统，也就是说，没有系统用户也要完成的事（工作、任务、流程、责任等）这里系统指软件系统。另外实际工作中，给用户/客户看用例是不现实的，没有任何人愿意读用例，无论用例用多么简单或直观的形式描述，即使用户具有软件开发的背景。现实中，用户更关心系统能干什么（系统特征列表），有界面原型更好。 * 系统需求——系统要干什么，考虑用户需求中的那些事可以通过系统来做，系统需求可以整理成系统特征。 功能需求依赖于用户需求，可以说是用户需求在系统上的一个映射（Mapping）。开发者思考的角度从用户转移到开发者。 在这个层次上，为用户做一个软件原型是一个很不错的主意。直到现在，用户对软件还是没有一个实实在在的概念，如果你给用户一个原型，用户就会说，哦，我的XX系统原来就是这样的。这就避免了用户在软件开发完成后才看到软件所带来的一些风险。是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目，很多时候，用一些非正规的方法来生成原型：如果你要开发一个WEB系统，让你的美工做几个页面给用户看看，如果你做一个C/S系统，做一个界面给用户，都已经足够用了，甚至你完全可以在黑板上画一画你将来的软件的面貌都可以。用户大都是比较友善的，不要把问题想的过于复杂。 * 软件需求包括了6个特性：功能性；可用性；可靠性；性能；可支持性；设计约束； 功能性：需求是软件最重要的需求，也是最直观、用户最关心的软件需求，它又可分为普通功能和全局性功能（就如同台面上的和背后的区别啦）。普通功能泛指软件完成的一个功能或提供的一个服务，例如，一个订单管理软件通常有输入订单和订单查询等功能；全局性功能是适用于阮家浓缩铀应用场景的功能，如出错处理等。 可用性： （系统复杂性；界面简单化）泛指能使最终用户方便使用软件的相关需求。 可靠性：包括与系统可靠性相关的各种指标，例如正常运行率、平均无故障时间、平均修复时间、精确度、最高错误或缺陷率等。 性能：记录与系