软件需求讲义-第三部分(部分)

软件(ruǎnjiàn)需求（三）共六十页需求(xūqiú)获取与需求(xūqiú)分析寻找客户(kèhù)的需求（导出问题）理解用户的需要（途径或方式）需求获取的方法定义系统

管理客户

需求建模结构化分析面向对象的建模用例建模商业建模共六十页第5章寻找(xúnzhǎo)用户的需要调查是识别需求的基础，是建立系统逻辑模型的基础。调查包括：业务处理过程是什么样的？(干什么？)业务过程应该怎样完成？(怎么干？)业务谁负责，完成业务需要什么输入，能输出什么？传统的系统调查方法有：资料收集访谈实地观察问卷调查常用的需求引导方法有：原型法联合(liánhé)应用开发（JAD）会议观摩法共六十页调查方法(fāngfǎ)1——资料收集可以收集以下资料：组织机构、部门职能、岗位职责说明业务流程说明、操作规程管理工作标准和人员配备单位内部管理用的各种单据、报表、报告历史的系统分析文档从现有(xiànyǒu)文档中获取客观事实共六十页调查方法(fāngfǎ)2——访谈（interview）与业务领域专家的面谈是获取需求的基本技术。面谈类型(lèixíng)：结构化面谈：有为面谈专门设计的问题非结构化面谈：通常为开放式问题优点：激发面谈对象主动贡献、自由表达的机会，可以得到更多反馈，近距离接触还能获得隐性信息缺点：耗时、成本高，取决于分析员的人际交往能力，受制于地理位置共六十页调查方法(fāngfǎ)3——实地观察（observation）直接参与到企业活动中，或观察他人执行活动来了解系统，“耳听为虚，眼见为实”。优点：收集到的信息可靠，获得确切的感性认识，了解物理环境和事务背景缺点：被观察者因为不自然可能与常规表现有差异，可能会漏掉特殊情形(qíngxing)下的任务，观察会被打断共六十页调查(diàochá)方法4——调查问卷（questionnaire）调查表可以收集大规模的事实表格(biǎogé)。调查表类型：固定格式调查表：只能选择问题答案自由格式调查表：允许自由填写文字优点：方便填写，廉价，允许匿名，可以进行快速表格分析缺点：不够灵活，无法保证能深入回答问题，无法保证问卷回收数量，设计好的调查表十分困难共六十页需求(xūqiú)引导方法一般用户在开发之初，对所要开发的信息系统应该具有的功能和所能达到的结果并没有清楚的认识(rènshi)，因此，需求调查比现行组织系统调查难度更大。对用户进行引导和启发，让用户获得软件系统的感性认识，引导他们发现现行组织管理和业务处理中所存在的问题，从而发掘需求和找到解决方案。采用以下需求引导方法：原型法联合应用开发（JAD）会议观摩法共六十页需求引导(yǐndǎo)方法1——原型法利用快速开发工具，根据用户的初步需求，构造出信息系统的初步原型。优点：用户和调查人员深度沟通，能准确地反映了用户需求，澄清和纠正模糊和矛盾(máodùn)的问题。缺点：额外工作量，原型开发工具购买成本共六十页需求引导方法(fāngfǎ)２——JAD会议JAD，jointapplicationdevelopment是一种类似于头脑风暴的技术，在一个或多个工作会议中将所有利益相关者带到一起，集中讨论和解决最重要的问题。参加人员：领导（主持人）、记录员、客户(kèhù)、开发人员优点：群体智慧，提高生产力，更理智的判断，降低犯错缺点：会议长度难以控制，人员之间容易受干扰和影响共六十页需求引导(yǐndǎo)方法３——观摩在系统开发之初，可以让用户参观同行业或同类型成功的信息系统。用户看到这些具体(jùtǐ)系统，将会对信息系统的功能、作用、外在效果、人机交互方式等产生直观印象，这样就会引导和启发用户，通过类比思维，提出自己软件系统的需求。可采用研究类似产品或解决方案来替代观摩。共六十页第6章理解用户(yònghù)的需求用户陈述的问题往往是表面现象，我们有必要和用户一起挖掘出问题背后的问题，即找出问题的根源，从而从根本上解决问题。确定解决方案的约束条件。了解用户需求的第一步是在有关问题的定义上和用户达成一致。确定系统的涉众，除了开发(kāifā)团队和用户等直接涉众，我们还要找到间接的涉众。共六十页了解问题(wèntí)产生的根本原因（一）

鱼骨图共六十页了解问题(wèntí)产生的根本原因（二）帕累托图（ParetoChart）共六十页确定(quèdìng)解决方案的约束条件潜在的系统(xìtǒng)约束共六十页到期催还功能(gōngnéng)的约束分析共六十页在问题定义上达成(dáchéng)共识描述(miáoshù)问题的模版

共六十页确定(quèdìng)涉众和用户涉众(stakeholder)，在软件开发项目中主要是指和这个项目有密切相关利益的人，他们共同感兴趣的就是需求(xūqiú)分析阶段。这些涉众包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。共六十页确定(quèdìng)涉众的问题举例

共六十页获取(huòqǔ)需求的案例我们将要开发一个在线图书借阅系统系统。传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要(xūyào)的书。为了把书送到借阅人手里，我们已经联系了快递公司，初步达成协议，由他们往返借阅人和图书馆之间，把图书送出和收回。读者在网上出示和验证借书卡，找到他们需要(xūyào)的书，提交申请，图书管理员确认后，就会通知快递公司来取书，当读者拿到书之后，快递公司需要(xūyào)把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要(xūyào)付费的。还书基本上也是同样的过程。共六十页在线(zàixiàn)图书借阅系统中的涉众共六十页第7章需求获取(huòqǔ)的方法获取需求是一个确定和理解(lǐjiě)不同涉众的需要和约束的过程。获取需求的方法：面向目标，基于场景，面向方面，面向视点，基于知识。需求描述语言可分为三种：非形式化、半形式化和形式化语言。共六十页主要的获取(huòqǔ)方法面向目标（Goal）的方法基于场景（Scenario）的方法*面向方面（Aspect）的方法面向视点(shìdiǎn)（Viewpoint）的方法基于知识的方法共六十页用例与场景(chǎngjǐng)（Scenarios）用例描述的是一组动作序列，在复杂的系统中，用例细节可能存在多种不同的情节，称为变体。比如：购买商品的用例中收款可以是现金支付(zhīfù)、信用卡支付(zhīfù)或支票支付(zhīfù)。针对每一种情况有不同的场景，一个场景就是一个具体的故事现场，重现一个参与者如何具体完成用例。主成功场景：故事的主线，用例通常得到成功执行的典型场景。扩展场景：失败场景，或因为一些特别条件而出现行为分支的步骤（包括失败和成功）共六十页场景(chǎngjǐng)示例：用例名称借出图书参与者图书管理员（主要参与者），读者（次要参与者）假设图书馆是开架借阅，读者总是找到书后办理借书手续，因此，借书不需要验证库存，而且每本书都是可识别的。前置条件图书管理员已被识别和授权后置条件存储借书记录，更新库存数量，所借图书状态为出借主事件流1．图书管理员将读者借书卡提供给系统；2．系统验证读者身份和借书条件；3．图书管理员将读者所借图书输入系统；4．系统记录借书信息，并且修改图书的状态和此种书的可借数量；5．系统累加读者的借书数量；6．重复3-5，直到图书管理员确认全部图书登记完毕；7．系统打印借书清单，交易成功完成。备选事件流2a．非法读者

1．系统提示读者身份错误，用例结束2b．读者借书数已达限额

1．系统提示读者已达结束限额，用例结束2c．读者有过期未还书籍

1．系统提示读者应归还的书籍列表和到期日，用例结束5a．读者借书数已达限额

1．系统提示，并要求结束输入

2．图书管理员确认借书完成5b．读者有该书的预定记录

1.删除该书的预定信息共六十页需求(xūqiú)描述语言非形式化语言主要是指自然语言和进行了一些结构化的类自然语言，在目前实践中应用最为广泛。形式化语言主要以数学与逻辑的形式对系统需求进行描述，例如Z、VDM、STATECHARTS、Petri网等。半形式化方法如图、表等方式(fāngshì)，或者有选择的采用一些数学或逻辑的描述方式(fāngshì)，试图兼顾可理解性和描述的准确性，在一定程度上兼具形式化语言和非形式化语言的特征（包括其优点和缺点），其代表例如PSL、SADT、UML等。共六十页第8章定义(dìngyì)系统确定项目范围涉及三个要素：项目所要提交的功能，项目可用资源，实现项目可用的时间。让客户满意并不意味着就要满足(mǎnzú)客户所有的需求。建立的项目需求基线必须满足：至少对客户来说，是可以接受的；在开发团队看来，具有合理的成功可能性。前景文档获取用户的需要、系统的特性以及项目的其它需求。它的范围跨越需求金字塔的上两级，在较高的抽象级别上定义问题和解决方案。共六十页项目(xiàngmù)的范围问题共六十页客户(kèhù)要求的总比实际的要多签订合约的时候，项目范围描述不清楚。客户和项目组对写成书面文件的需求理解(lǐjiě)不一致。客户总有在结项之前把每一件事情都做得淋漓尽致的初衷。项目组人员总是无条件迁就客户，客户有求必应。

共六十页确定系统(xìtǒng)的界限定义系统的关键首先是要给出系统的边界。该边界把我们的系统和外部世界一分为二，换言之，系统边界确定了我们系统的内涵，即它究竟包括哪些功能，可以解决哪些问题。我们可以根据(gēnjù)确定的系统边界给出系统的环境模型。它指出了我们的系统以及其它和它交互的系统之间的关系。共六十页在线(zàixiàn)图书借阅系统的界限共六十页确立系统(xìtǒng)基线基线必须满足：至少对客户来说，是可以接受的。在开发团队看来，具有(jùyǒu)合理的成功可能性。共六十页建立基线(jīxiàn)的步骤首先是建立系统的特征表。对前面取得(qǔdé)的特征表，我们先来对每项特征设定其优先级。接下来的工作就是要评估每项特征所需花费的工作量。还有一项因素要考虑，那就是与每项特征相关的风险。在上述工作的基础上，我们要考虑在各种因素之间寻求最佳的平衡点。共六十页项目(xiàngmù)前景文档前景文档获取用户的需要、系统的特性以及项目的其它需求。它的范围(fànwéi)跨越需求金字塔的上两级，在较高的抽象级别上定义问题和解决方案。前景文档用一般的术语描述应用，包括对目标市场、系统用户以及应用特征的描述。前景文档是项目早期的工作重点，是早期搜集需求信息阶段的总结性成果。共六十页项目前景(qiánjǐng)文档模板1.业务需求

（a）业务背景

（b）业务机会

（c）业务目标和成功条件

（d）客户和市场需要

（e）业务风险2.解决方案的前景

（a）前景描述

（b）主要的系统特征

（c）假设(jiǎshè)和依赖条件共六十页项目(xiàngmù)前景文档模板（续）3.项目范围(fànwéi)和限制

（a）初始发布的范围（基线）

（b）后续发布的范围

（c）限制和排除条件4.业务环境（a）涉众简介

（b）项目的优先级

（c）运行环境共六十页业务(yèwù)需求描述了新系统将带个投资人、购买者和用户的主要利益。背景对历史和现状进行概括，说明为什么开发该产品。业务机会（1）商业产品：描述存在的市场机遇及参与竞争(jìngzhēng)的市场。（2）信息系统：描述要解决的业务问题或需改进的业务流程，及系统的应用环境。（3）与已有的产品或解决方案比较，指出新产品的优点。（4）说明哪些问题没有新产品无法解决。（5）新产品如何符合市场潮流、技术发展或企业战略。共六十页业务需求——业务目标(mùbiāo)与成功标准用量化和可衡量的方式概述新产品提供(tígōng)了哪些重要的业务利益。共六十页业务需求——客户(kèhù)和市场需求、业务风险客户和市场需求描述典型客户和特定市场的需求，包括当前已有产品不能满足的需求。指出新产品解决的问题。业务风险概述与产品开发相关(xiāngguān)的主要风险。包括市场竞争、时间问题、用户认可、实现问题以及可能对业务造成的负面影响等要评估每项风险可能造成损失的发生几率、影响程度。共六十页前景(qiánjǐng)文档举例示例：下面将以“自助食堂订餐系统”这样一个小型项目，示范项目前景文档的书写。因为是一个小项目，故对模板稍作简化，有时会将几个部分合并，避免(bìmiǎn)重复。每个项目都应该考虑如何适应标准模板，以尽量适合项目的规模和本质。共六十页业务需求(xūqiú)示例业务需求1.1

背景、业务机会和客户需要目前，Impact公司的大多数员工平均每天要花费60分钟去自助食堂选择购买并用午餐，其中大约20分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午餐、及以现金或信用卡方式结算餐费上。当员工出去用午餐时，他们平均有90分钟不在岗。有些员工提前给自助食堂打电话预定午餐，请自助食堂提前准备。但是，并不总能如愿，因为自助食堂有些食物已经卖出，而同时自助食堂又不可避免地浪费大量食物，因为有些食物没有卖出去只好倒掉。早餐和晚餐同样面临这样(zhèyàng)的问题，只是用餐的员工比午餐要少得多。共六十页业务需求(xūqiú)示例（续）

许多员工都要求：通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的日期和时间内将所订的午餐送到公司的指定地点(dìdiǎn)。通过这样一个系统，使用这一服务的员工可以节约相当可观的时间，而且订到自己喜欢的食物的机会也增大了，这既提高了他们的工作生活质量，也提高了他们的工作效率。自助食堂提前了解到客户需要哪些食物，就可以减少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地饭店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店大量的购餐协议而有可能节约费用。Impact公司也可以只在自助食堂或本地饭店订餐。共六十页业务需求(xūqiú)示例（续）1.2业务目标（BusinessObjective，BO）和成功标准（SuccessCrite，SC)BO-1：初始版本发布之后的6个月内，自助食堂的食物浪费(làngfèi)减少50%。BO-2：初始版本发布之后的12个月内，自助食堂的运作费用减少50%。BO-3：初始版本发布之后的3个月内，每个员工每天的平均有效工作时间增加20分钟。SC-1：目前通过自助食堂解决午餐的员工，在初始版本发布之后的6个月内，他们中有75%的人使用“自助食堂订餐系统”。SC-2：初始版本发布之后的3个月内，对自助食堂满意度的季度调查评价要提高0.5，而在初始版本发布之后的12个月内，这种满意度要提高1.0。共六十页业务需求(xūqiú)示例（续）1.3业务风险（RIsk，RI）RI-1：使用该系统(xìtǒng)的员工太少，减少了对系统(xìtǒng)开发和变更自助食堂经营过程的投资回报。（可能性0.3，影响9）RI-2：本地饭店可能并不认为降价是员工使用这一系统的正当理由，这会降低员工对该系统的满意度，并可能会减少他们对这一系统的使用。（可能性0.4，影响3）RI-3：“自助食堂员工联合会”可能要求与自助食堂工作人员重新签订合同，以反映新的员工角色和自助食堂营业时间。（可能性0.6，影响3）共六十页解决方案的前景(qiánjǐng)描述系统的战略前景，即该系统将实现的业务目标。前景陈述概括新产品的长期目标和意图，应反映能够满足不同涉众需求的平衡观点。可以从如下关键字方面阐述：产品名称产品类别目标客户需求或机会的声明主要竞争产品、当前系统和当前业务过程(guòchéng)新产品的主要竞争优势共六十页解决方案的前景(qiánjǐng)（续）主要的系统特性为新产品的每一项特性进行惟一的命名或编号(biānhào)突出其超越原有产品或竞争产品的特性假设和依赖条件记录涉众所提出的每一项假设。由于一方所作的假设往往不为其他方所知，因此有必要记录下来并检查。共六十页解决方案的前景(qiánjǐng)示例解决方案的前景2.1前景陈述

对那些希望通过公司自助食堂或本地饭店(fàndiàn)在线订餐的员工来说，“自助食堂订餐系统”是一个基于Internet的应用程序，它可以接受个人或团体订餐，结算用餐费用，并触发将订餐送到公司内的指定位置。与当前的电话订餐和人工订餐不同，使用“自助食堂订餐系统”的员工并不需要到食堂内去用餐，这就可以节约他们的时间，又可以增加他们对食物的选择范围。共六十页解决方案的前景(qiánjǐng)示例（续）2.2主要特性（Feature）FE-1：根据自助食堂提供的选择菜单或送货菜单来订餐。FE-2：根据本地饭店的送货菜单来订餐。FE-3：创建、浏览、修改和删除(shānchú)用餐预订服务。FE-4：注册用餐的付费方式。FE-5：请求送餐。FE-6：创建、浏览、修改和删除自助食堂菜单。FE-7：预定自助食堂菜单上没有的定做菜。FE-8：生成自助食堂定做菜的食谱和配料列表。FE-9：通过公司内联网可以访问系统，或者授权的员工通过外部Internet访问系统。共六十页解决方案的前景(qiánjǐng)示例（续）2.3假设（ASsumption）和依赖（DEpendency)AS-1:自助食堂内有可以访问公司内联网的计算机和打印机，这样自助食堂就可以处理订单量，不会遗漏(yílòu)送货时间。AS-2:自助食堂有送货人员和送货车辆，这样就能满足所有的订单的送货要求：最多比请求的送货时间晚15分钟。DE-1:如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一系统进行双向通信。共六十页项目范围(fànwéi)和限制范围定义解决方案的概念和范围。限制则列出产品不会提供的某些功能。必须拒绝超出范围的需求，除非它非常有意义。记录下被拒绝的需求的内容(nèiróng)、原因，以防此类需求被再次提出。共六十页项目范围(fànwéi)和限制示例项目范围和局限性3.1初始版本(bǎnběn)和后续版本(bǎnběn)的范围共六十页项目范围(fànwéi)和限制示例（续）3.2限制与排除（LImitation）LI-1:自助食堂内有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单是食堂整个菜单的一个子集。LI-2:“自助食堂订餐系统”只能(zhīnénɡ)用于本地Impact公司总部的自助食堂。共六十页业务(yèwù)环境概述项目的一些业务问题，包括主要(zhǔyào)的涉众类别，以及项目的管理优先级。涉众简介涉众类型从产品得到的主要价值或利益，包括：提高生产力、减少返工、节约成本、手工劳动自动化、能够进行全新的工作、符合相关的标准或法规、比现有产品更实用等可能对产品采取的态度感兴趣的主要特性和功能必须遵循的约束共六十页业务(yèwù)环境——项目优先级要想有效地决策，涉众必须就项目的优先