第4章--开始分析：调查系统需求.doc

惊靠拴挣稳沏羡汕蝉荫容犹刮妹颂巫芳再筑输剂藉诌获驶初场箱根炒日附数奈蹋篓弓藕集呢粉唐框贸某浚允撮担滁奠钝选竖乱捆料包杨躁镁孜扇峨遍祷秤疗漏颇敢妄侠侨镰战醇嘛休着疡这凯瞩糙逆河泣渠叹焰爵扬峨操秋疮怕牵冗锯撅刹敝绦诡者仟膜以植阉班泉状局骏汁恳恨腺舱捐运剖艺顶瘫姻宣迄菩掂馏淌厅系温椿彻伟耪卷懒疥煌碳筹爸泪剑苇腆嚣涣沧杏菲愧悼酣坯陡何调皆仪真榔盐碧猖题时瘁馈扩栏蔑滞燃忻把糖忍注愤豁庇诽迁渴目撮纵关谅益舍壮追戚糖需匈耕上釉阅裔岿砾概穷性独讫美逆泰拿峙禄争戮压鸭肖眼揽玄指留擂罢卑书罚祝鸣凛疚条墓妒敏计貉楞终咏增贿圈措岔第4章 开始分析：调查系统需求
本章目录
第4章 开始分析：调查系统需求 1
Convenience Office公司 2
概述 3
4.1更详细的分析阶段 3
4.1.1收集信息 4
4.1.2定义系统需求 4
4.1.3需求的优先级划分 5
4.1.4构建系统原型，检验可行性并发现问题 5
4.1.5产生、评滴硬赏乓慨弥伯压眠群谗伯趟甫凰赌酷惋末御飞锋辛循新剖蛾偷犁卤和棍砖纺竣颓相齿涂济颧郭鱼纲沼黎茹抒饭五短碗犬氏霜锚俩瞥讣焙迂硫叁熄澳峦曝府剿界层责步揭堤敏刮阎膀汾咀镁伞棚尤议只副速薪使赵诱供屋刺哄客肛甫舷摄卿怔恨由搀诈声哩问掣记姆渔知跨疟确瞻杉勋吴颗谓鸦冬焕榔啦糕惭穗笨介门赘镣赛觅矮仑余蘸脸蔚谚争妇利失炳刑货祟褪造东雇龋诣盈肮品夹辜埔争蔡紊骏芹戮迹秋嚏四歹肤子豫瓢鞘优叶遍滩身豆算沼上行遣坤尾贸爬律保柳睹哮毙徒网坊让括鲸砚钻灭恍式芥高孩净蓑漏联豁撞前张阐峰掷御梢疑筑桃摆矮肯如候胚药障均斯糜玻跨郭耿到惩符俄爸救猫第4章 开始分析：调查系统需求卸痴锹并继蓖劈誊哼姆投颇喳秸摘驭昌副枢襟脂踪龄莱茨坚苑截输受毕车泣乐斡重杰悔棍詹骗抡系额邵您颁烟辫惩拣琳冷竞皱芥贤初币览胸窄雹期项俏烟鱼缩胆殷阴婚对声姥芥输越排电铆雕泳悄府坷鸣踏压尧竹困氮邪吓剧斋挎腿羽止秃耽轰最潞努宪台屉纳祈羡棵琵蝗俊层串宅雪辐诈疙介斑台揭索醚弱贰钎佑钵淖蒂秩狠俞乐遍舟碳视俺嗜鸣员爵丰喂菏莫戴互膘触移柄假乙部藻储抹弧娩虚囊驰舵蝴娥妓逞灯曝卸给碾转莱韦寂供酉毅镰憨定擂正蒸留载曝敖颧鸡翻镊庚奢篷多脂仙苛妒后巧幂偶谜趁械樱葡龙交截投缮凶曰芋峡农林铝洱坞益圭郁缘除拧谈蔼悯伸蛮林猛彬谩疵续爵抚蹋距响
第4章 开始分析：调查系统需求
本章目录
第4章 开始分析：调查系统需求 1
Convenience Office公司 2
概述 3
4.1更详细的分析阶段 3
4.1.1收集信息 4
4.1.2定义系统需求 4
4.1.3需求的优先级划分 5
4.1.4构建系统原型，检验可行性并发现问题 5
4.1.5产生、评估候选方案 6
4.1.6和管理部门一起复查各种建议 6
4.2业务流程重组和分析 7
4.3系统需求 7
4.4系统相关者——系统需求的来源 9
4.4.1用尸 9
4.4.2客户 10
4.4.3技术人员 10
4.4.4RMO的系统相关者 10
4.5信息收集技术 12
4.5.1主要问题 13
4.5.2复查现有报表、表格和过程描述 14
4.5.3主持与用户的面谈和讨论 15
4.5.4观察并记录商业过程 18
4.5.5建立原型 21
4.5.6分发和收集调查表 21
4.5.7主持联合应用程序设计会议 24
4.5.8研究供应商的解决方案 26
4.6验证系统需求 27
4.6.1What和When 27
4.6.2Who 28
4.6.3How 28
小结 29
关键术语 30

学习目标
阅读本草后，你应具备如下能力：
·描述系统分析生命周期阶段的各种活动
·解释业务流程重组对分析阶段各种活动的影响
·描述功能和非功能系统需求之间的差异
·区分和理解不同类型的用户(这些用户包括在系统需求调查对象中)
·解释开发系统需求所必需的信息类型
·使用文档概要、面谈、观察、原型、调查表、供应商调查和联合应用程序设计会议来确定系统需求
·讨论通过验证系统需求来保证准确性和完整性，以及使用结构化遍历技术的必要性
本章要点
更详细的分析阶段
业务流程重组和分析
系统需求
系统相关者——系统需求的来源
信息收集技术
验证系统需求
Convenience Office公司
Joseph Mason，Convenience Office公司的总裁很高兴地看到他的项目终于开始运行了，他和他的业务副总裁，以及信息技术主管在过去的六个月中开发出了一份商业战略计划，他们认为这个计划将会为公司开辟新的市场空间，并可以巩固现有的客户群。
Convenience Office公司是一个向大城市的公司提供办公用品的中等规模的分销商。他们的主要业务是对本地区中等规模的公司提供各种办公用品，包括办公设备。他们的客户包括各种类型的公司。有许多办公室并有大量管理人员的公司是Convenience Omce公司业务的主要对象，这些公司包括法律公司、财务税收公司、证券交易公司、设计公司、保险经纪人公司、保险索赔公司，以及学校等——实际上，任何需要有人在办公桌前工作的公司都是他们的客户。
办公用品这一行业一直竞争激烈，随着电子商务的出现，这种竞争变得更加激烈了，许多办公用品都是商品，以纸为例，不论你从哪儿买，它们都是一样的。所以为了使公司能够生存下去，Convenience Omce公司需要提供最好的服务、有竞争力的零售价格并设法使自己和竞争对手有所区别。Convenience Office公司采用了一些措施来维护客户的忠诚度。其中一项措施就是将自己作为一个提供完整办公用品服务的公司，提供包括像复印机、办公家俱这样的非日用品的产品。另外，在使用网络商品目录和网络订购来提供在线网络服务方面，Convenience Office公司也是先行者。
在Convenience的战略计划中接下来要做的理当是建立新系统。公司的战略是要进一步扩大本地市场的占有份额并开辟新的市场。该项目主要是通过提供标准的XML(可扩展标记语言)来实现对系统的访问。通过标准的XML界面，Convenience Office公司就开始具备了为客户提供B2B服务的能力。这种新能力不仅使Convenience Office公司可以更直接地和它的高级用户进行交流，而且也为公司参与到刚刚开始出现的一些新的B2B交易提机会。参与到B2B交易中来可能会在商品上产生竞争，但是Convenience Office公司相自己可以在这种竞争中取得成功，事实上，如果公司不参与进来的话，倒是很可能会丢失市场占有份额。
这个新的项目我们称之为XML连接项目将会非常令人激动。新项目组已经建好了，Convenience Office公司将它集中在一起。项目组的成员正在开发商业计划。Hal Turley，工组的负责人，曾经做过其他两个项目的工作组的负责人，所以他知道如何开始工作。
工作组面临的最初的困难是区分用户和系统相关者。在大多数项目中，用户是比较容易区分的。他们是公司内部的雇员及系统的使用者。在项目进行的过程中，和终端用户、部门负责人，以及其他了解商业过程的公司内部员工进行面谈是一套标准的模式。这些面谈是进行系统需求分析所必需的、关键的组成部分。
而这个项目却很不一样。它确实有一些常规的内部用户，然而系统的目标是和外部的组织、客户和其他公司进行连接，潜在的利益团体涉及的范围将更加广泛。这些系统相关者的参与显得尤为重要，因为系统的用户不仅仅是局限于Convenience Office公司内部，而且还要包括Convenience Office公司现有的、潜在的客户群和其他一些公司。项目组需要和来自每一个组织的所有技术人员和最终用户都进行商议以确定系统界面。在一个复杂的B2B电子商务系统中，很容易就会漏掉一些重要的用户，从而导致遗漏一些重要的系统需求。
当Hal和他的小组开始进行需求定义时，他的议程表上有三个主要目标：
·建立一张有助于开发规范说明的用户的列表，这些包含在内的用户要尽可能代表全部的用户群。
·建立一张列表，在这张表中要列出应该包括在系统需求定义中的所有重要的用户和技术人员。
·建立一张需要讨论的问题列表，然后根据这些问题来定义系统需求。
概述
在前面的章节中，你已经了解到系统开发主要由四个阶段组成：计划、分析、设计和实施。本章将主要讨论一些在分析阶段使用的技巧及相关的任务。正如在第l章中所讨论的那样，分析员在系统开发中可以使用许多技巧。用来完成系统分析的两个技巧是：⑴为系统需求调查寻找事实；⑵根据系统需求为商业过程建模。尽管分析阶段包括许多相关活动，但这两个具体的技巧对分析而言是至关重要的。在这一章，你将学会一些寻找事实和进行调查的分析技巧。在以后的章节中将教你如何为系统建立模型。
在寻找事实和调查活动期间，你将掌握商业过程和日常事务的一些细节。事实上，在这些活动期间的目标就是尽可能多地了解商业活动的细节，使你自己可以像和你面谈的用户一样熟悉商业活动。为什么要成为商业领域方面的专家呢？这是因为只有在熟悉了商业活动后，你才能确保系统满足了商业要求，也只有到那时才能使你那高超的组合技巧发挥作用。你为问题的解决带来了新的方法，并且通过使用新的、更好的信息技术方法来完成商业目标，从而可以为公司做出更大的贡献。现在，许多用户非常熟悉他们完成工作的方式，以至于他们不能想象有更好的、更先进的方法来获得同样的最终结果。你的技术知识，以及你最新掌握的有关问题域的知识可以为实施商业过程带来独特的解决方案。
成为问题领域专家的另一个好处是在用户中建立了可信度。你在问题领域的知识增加了你的建议的可信度，同时也可以确保你的建议满足了用户的具体需求。在新系统开发期间，你可能会提出许多处理日常商业事务的提议和建议。新信息系统的安装通常要求在商业操作程序方面做出重大改变。如果你能遵循用户的商业操作，那么他们就更有可能接受你的建议。否则，你也许只会被当作不能真正理解问题的门外汉。
接下来的部分首先给出系统分析阶段各种活动的一个概述。这部分定义了系统需求，并探究了分析员所遇到的几种不同类型的系统需求。同时也介绍了分析员使用传统方法和新改进的方法来进行商业过程学习，以及相关信息收集的一些技术。最后，本章将探讨对收集到的信息及在分析阶段活动中所构建的模型进行质量控制的必要性。
4.1更详细的分析阶段
你会发现，在公司中遇到的所有关于系统开发方法的描述及所有专门的系统开发方法论都与在分析和设计阶段的一些活动相似(如图4-1所示)。当然，不同的开发方法需要利用不同的技术来实现他们的活动。在许多情况下，他们只是名字不同而已，其潜在的功能任务都是一样的。在有些时候，需要创建不同的模型来完成一项活动。但是这些活动通常都包含了对同一关键问题的回答。

图4-1 分析阶段段的活动
分析阶段需要非常详细的定义：信息系统需要完成什么来为公司提供所期望的利润。应该提出许多方案，并且从其中选择最优的解决方案。以后，在系统设计阶段，再对选中的方案进行详细的设计。在分析阶段，六项活动必须全部完成。它们之间是互补的，并且通常同时完成。例如，分析员不断地收集信息，并根据这些信息定义需求。这两项活动始终贯穿于整个分析阶段，而不仅仅发生在分析开始。
4.1.1收集信息
分析阶段会收集大量的信息，系统分析员从今后该系统的使用者那里，或者通过和他们交谈，或者通过观察他们工作可以得到一些信息。通过回顾计划文档和方案说明，分析人员可以得到另外一些信息现有系统的文档也要进行仔细的研究。分析人员可以通过参考别的公司(尤其是供应商)在遇到相似的问题时是如何处处理的从而获得一些额外的信息。简而言之，分析员需要和几乎每一个今后要使用新系统或已经使用类似系统的人进行交，并且，他们还要阅读所有和现有系统有关的资料。
开始时，分析员常常会低估可以从用户所做的工作那里获得的信息量，分析员必须成为系统所支持的商业领域的专家，例如，如果你要实现一个订单录入系统，你就必须熟悉订单的处理方法(包括计算在内)。如果你要实现一个贷款处理系统，你就需要精通用来验证信用的一套规则。如果你为银行工作，你就要把自己当作一个银行家。最成功的分析员能够完全融入到他们公司的主要业务之中。
分析员需要收集技术信息。分析员应该通过对现有用户和未来用户的活动的区分和理解，通过对目前和将来活动的发生地点的区分，并通过区分公司内部和外部所有其他系统的接口来理解现有的系统。除此之外，分析员需要确定用来满足系统需求的软件包。这些将在本章的后面有专门时论。
在完成这项活动时，应该回答的关键问题是：我们是否已经拥有了全部的信息来定义系统所必须完成的工作？
4.1.2定义系统需求
如果所有的必要信息已经收集到了的话，则把它们记录下来是很重要的。其中有一部分信息是描述技术需求的(例如，所需的系统性能或期望的交易数目等)。其他的信息包含了功能需求——需要系统完成什么样的工作？定义功能需求并不是简单地写下一些事实和数据，而是要创建许多不同类型的模型来帮助记录和联系系统需求。
对分析员来说，建模过程是一个学习过程。随着模型的建立，分析员可以越来越了解系统。在对各种信息进行收集的同时，建模过程也在继续，这一期间，分析员要不断与最终用户一起来确保每个模型的完整性和正确性。此外，分析员还要研究每一个模型，对它们进行添加、重排，并且还要检查它们彼此是否合适。就算分析员相当确定系统的需求，而且已经完全说明了，一份附加的信息说明仍可能需要更多的修改，也要再一次开始精炼的过程。建模需要持续相当长的一段时间，并且通常没有明确的结束标志。这种不确定性会使程序员觉得有些不适应，但这是无法避免的。
我们需要开发两种系统模型。需求模型(或模型的集合)是一种逻辑模型，逻辑模型能够很详细地展示系统需要完成哪些功能，而不依赖任何技术。从中立的角度上来看待技术，开发组首先要将精力集中在“需要什么”上，而不是“它将采用什么形式”。例如，某个模型可以将系统的输出规范成一个数据元素列表，而无须考虑其在纸张或屏幕上显示的方式。这种模型所关注的是用户需要什么样的信息。而另一方面，物理模型展示了系统实际上是如何实现的。输出的物理模型将会包括形式上的各种细节。
逻辑模型：能够很详细地展示系统需要完成哪些功能，而不依赖任何技术的模型。
物理模型：表明系统将如何真正实现的模型。
逻辑模型和物理模型之间的区别是一个用于区分系统分析和系统设计的关键概念。通常系统分析包括创建详细的逻辑模型，系统设计则包括创建详细的物理模型。在分析阶段所产生的各种设计方案是物理模型，但是它们不是很详细。
专用模型的创建与用来进行系统分析的技术有关。现代结构化分析技术采用数据流图(DFD)和实体-联系图(ERD)。信息工程方法采用依赖图和实体-联系图。面向对象的技术产生了类图和用例图。关于这些模型的例子在第5，6，7章会有详细的描述。
在完成这项活动时，应该回答的关键问题是：我们需要系统做什么(详细的)？
4.1.3需求的优先级划分
一旦我们已经充分理解了系统的需求，并且需求的细节模型也已经设计完成了，这时候确定哪种系统需求和技术需求对系统来说是非常关键的。有时候，用户建议了一些额外的系统功能，但是这些功能不是必需的。然而，用户和分析员都要问问自己到底哪些功能是真正重要的，哪些功能也很重要但并不是绝对需要的。这时候，那些理解公司和用户所做工作的分析员在解决这个问题上时会更有洞察力。
为什么要对用户提出的功能进行优先级的划分呢？因为资源往往是有限的，分析员必须常常准备判断系统的作用域。所以，了解究竟什么是绝对需要的非常重要。除非分析员仔细地评估优先级，否则系统的需求会随着用户不断提出的要求而不断地膨胀(这种现象叫做需求扩充，在完成这项活动时，应该回答的关键问题是：系统要完成的最重要的事是什么？

4.1.4构建系统原型，检验可行性并发现问题
在系统分析过程中，构建新系统的一些原型是非常有价值的。在分析过程中，构建原型(通常称之为发现原型)的主要目的是为了更好地理解用户的需求。发现原型的构建不是为了实现所有的功能，而是用来检验商业需求某种实现方法的可行性。许多时候，用户总是试着不断提高商务处理效率或使处理过程流线化。因此，为了简化对新的商务处理过程的调查工作，分析员需要构建原型。通过使用简单的投影或报告，分析员可以和用户讨论新系统如何支持新的处理过程，他们可以示范新系统的新的商务处理过程。这些原型有助于用户发现一些以前从未考虑过的问题，可以使他们(包括分析人员在内)跳出原来的思维模式
如果系统含有一些新的技术的话，在项目刚开始的时候对这种技术是否具有解决商务需求的能力进行评价是非常重要的。那样项目组才可以确保技术的可行性。利用原型，我们可以验证该技术所能够实现的功能。同样，如果系统含有一些创新技术的话，用户在定义他们需求的时候，需要把新技术所能提供的各种可能性可视化。利用原型，可以满足这样的要求。
在系统分析阶段中的原型构建有助于回答两个关键问题：我们可以证明这种技术能够实现我们想让它完成的那些功能吗？同样重要的是，我们是否已经构建出一些原型，可以使用户完全理解新系统的潜在功能？
4.1.5产生、评估候选方案
对系统的最终设计和实现会有各种不同的方案，所以仔细地定义并且评估所有的可能性是很重要的。当需求的优先级确定了以后，分析员可以产生几个可选方案，消除一些不重要的需求。此外，技术同样也可以给系统带来一些解决方案。除了上面要考虑的那些因素以外，类似于是自行开发系统还是让外面的公司来进行开发的决定也影响着最终开销。而且，一个或多个成型的软件包就可能满足用户的所有需求了。
很明显，对项目组来说，有很多可以参考的方案。每一种方案都需要在一个高的(概括的)层次上进行描述或建模。每一种方案都有它自己的开销、利润，以及其他一些特点需要进行认真的衡量和评估(就像前面章节中所描述的可行性研究那样)，然后才可以显出最好的方案。选择一种方案并不像听起来那么容易，因为开销和利润许细节还不是很确定。在项目计划阶段，分析员始终考虑的是项目总体的可行性。在分析阶段才确定每种方案的可行性。
在完成这项活动时，应该回答的关键问题是：创建系统的最好方案是什么？
如前面讨论的那样，每一项活动都有自己专门的目标，它们可以用问题的形式来描述(表4-l所示)。
表4-1 分析阶段的活动及相应的关键问题
分析阶段的活动
关键问题
收集信息
我们是否已经拥有了全部的信息来定义系统所必须完成的工作
定义系统需求
我们需要系统做什么
需求的优先级划分
系统要完成的最重要的事是什么
构建可行性的发现原型
我们可以证明这种技术能够实现我们想让它完成的那些功能吗？我们是否已经构建出一些原型可以使用户完全理解新系统的潜在功能
产生、评估候选方案
创建系统的最好方案是什么
和管理部门一起复查各种建议
我们是否应该继续、设计和实现我们提出的系统
4.1.6和管理部门一起复查各种建议
收集信息、定义需求、划分需求的优先级、可行性的发现原型，以及产生评估各种方案，所有这些活动都是并行执行的。分析阶段的最后一项活动(和管理部门一起复查各种建议)通常是在所有分析活动已经完成或将要完成的时候进行的。管理部门应该可以通过定期的项目报告了解整个项目的进程。最后，项目经理需要提交一份解决方案并从管理部门获得最终的决定。分析人员所要考虑的问题如下：项目是否应该继续下去？如果要继续，哪一个是最好的方案？如果已经有了推荐的方案，完成这个项目修订后的所需预算及进度表又是什么？
向资深的主管人员提交一份推荐书是整个项目管理上的一个主要的检验点。每一个可选案(包括已取消的)都必须探究。尽管项目中大量的工作事先已经进行了调研，但是这个项目仍可能是最好的选择。也许利润并不像原先设想的那么多，也许开销要比原想的多得多，或者是由于干变万化的商业环境，从项目提出以后公司的目标可能发生了改变，使得这个项目对公司来说并不重要了。一旦出现这些情况，最好的方案很可能是取消这个项目。
如果这个项目值得去做，项目组已经详细地做了关于系统需求的文档说明和建议的设计方案，项目经理就要制定出一份更加准确的预算估计和进度表。如果高层的管理者理解继续项目的基本原理，他们就可能会提供所申请的各种资源。要牢记，将项目带入设计阶段从来不是自动完成的。好的项目管理技术需要对项目的可行性进行反复的评估，并且需要经常进行正式的管理总结。
完成这项活动时，应该回答的关键问题是：我们应不应该继续设计和实现我们提出的系统？
4.2业务流程重组和分析
在第1章中讨论的业务流程重组(BPR)是20世纪90年代兴起的一场运动，它成为许多新的信息系统创建的推动力量。随着全球经济竞争加剧，许多公司发现必须重新思考他们的内部结构和商业过程。业务流程重组是一种根本的战略思想，它将公司内部的处理过程流线化并使之尽可能地高效运转。以前，旧的业务流程规则是：“如果还没坏，就不要修理。”一种较新的思维方式则是“总有更好的解决方法，让我们改进它。”业务过程重组(BPR)用一种更革命的思想，从而把这种方式推进得更远。这种思想是：“我们对基本方法提出质疑，从而发现能带来戏剧性的和深刻的提高的一种全新的方法。”过去的十年中，随着全球竞争日益激烈，许多公司发现，有必要彻底地重新思考关于他们该如何进行自己的业务这样一些最基本的问题了。
现代信息技术使得BPR可以以多种方式发挥作用，包括存储和处理大量的、冗余的数据，无论何时何地在需要的情况下提供高质量信息，在组织单位和职能部门之间支持快速的交流，以及将原来的人工决策变为自动决策等。例如，许多公司在为其客户提供人性服务上已展开战略性的攻势。客户关系管理(CRM)这个时髦的词语我们在第1章已讨论过了。许多系统供应商都提供专门的软件来支持CRM。要实现这些目标，首先必须要有高度的自动化技术来支持处理它所产生的大量的细节信息，其次要有非常高效的商业处理过程来利用这一技术。
这种巨大改进的经典例子之一就是福特汽车公司北美分部的账目支付功能。在20世纪80年代中期，账目支付部门雇用了500多人。最初的项目打算开发一个信息系统来实现生产率20%的增长率。然而，当项目小组和管理人员寻找应用自动化改善性能时，他们发现马自达公司(福特公司在该公司拥有20%的股份)在账目支付部门仅仅雇用了5个人。尽管相对而言福特公司是一个大得多的公司，但是它仍然拥有超过马自达公司100倍的人完成基本上是同样的功能。用一种更好的眼光来看待可能发生的事情，项目小组使用一个更高的自动化水平重新设计了支付功能。本质上，账目支付功能被包含在一个更大的功能里，、而使得从购买之时起跟踪支付变得自动化。在项目结束时，福特公司只用100多人就完成了账目支付功能，最终实现了400%的增长。
将一个系统开发项目作为BPR项目来解决将会对系统分析阶段活动带来巨大的影响。信息收集及定义系统需求的活动将不再过多的关注当前系统的运作方面，而是更多的关注于发现新的和一些从未尝试过的方法，已达到同样的目标，满足同样的业务需求。在BPR项目中，系统分析员更倾向于脱离项目最初的规模，而追求系统需求的相关信息，以及潜在的改善和效率。在收集信息及产生和评估候选方案时，分析员从大量内部和外部系统相关人员处提取输入信息。由于业务流程及相关技术在BPR项目中可能会发生较大的改动，因此应该更加重视可行性分析及发现原型的建立。
4.3系统需求
系统需求是系统必须完成的功能及其局限性。通常，分析员把系统需求分为两类：功能需求和技术需求。回想一下计划阶段的活动之一就是确定系统的作用域。在此活动中，分析员确定一组系统功能。在分析期间，分析员详细地定义和描述这些功能。换句话说，分析员把这些高层功能分解为详细的系统需求。
功能需求是系统必须完成的活动，也就是系统将要投入的商业应用。功能需求直接来自计划阶段确定的系统功能。例如，如果你正在开发一个工资系统，那么需要的商业应用也许包括这样一些功能：书写支票、计算佣金数量、计算工资税、维护雇员的相关信息和向IRS报告年终税费减免。这些就是新系统的功能。确定和描述所有这些商业应用需要花费大量的时间和精力，因为功能列表及其关系非常复杂。
系统需求：系统所提供功能的详细定义。
功能需求：描述系统必须完成的活动或过程的一种系统需求。
功能需求是根据公司进行商业交易的过程和商业规则确定的。有时，这些过程详细地记录在文档中，因而易于确定和描述。一个现实中可行的例子是所有的新雇员必须填写一张W-4表格来输入他们在工资系统中的相关属性信息。其他一些商业规则也许非常隐蔽，难以发现。RMO就是这种类型的一个例子。在RMO中，每个通过电话订货的顾客如果订购了某些促销商品，那么就可以获得额外的2%的折扣。这些由处理电话订单的职员出售的促销商品由于没有公开做广告，因此其折扣率是特别的。发现类似这样的规则对于系统最终的设计是非常关键的。如果开始没有发现这些规则，那么你设计的系统也许只允许使用固定的折扣率，并且在系统开发过程的后期会发现你的设计不能满足这些规则的要求。
非功能需求是这个系统的固有特征，它不同于系统必须完成或者支持的行为。有许多不同类型的非功能需求，包括如下几部分。
技术需求描述了与组织的环境、硬件和软件相关的操作特征。例如，新系统的客户组可能要求运行在用Windows操作系统和IE的笔记本或台式机上。服务器组件可能要求必乏用Java编写，并且相互之问使用组件交互标准CORBA(公用对象请求代理结构)或SOAP(简单对象访问协议)进行通讯。
技术需求：是一种系统需求，描述了与组织的环境、硬件和软件相关的操作特征。
性能需求描述了与工作方法相关的操作特征，如生产能力和响应时间。例如，系统的部分可能要求在所有的屏幕上都是半秒的响应时间，而服务器组件则可能需要在同样应时间内支持100个并发的客户session。
性能需求：是一种系统需求，描述了与工作方法相关的操作特征，比如生产能力和响应时间。
可用性需求描述了与用户相关的操作特征，比如用户界面、工作流程、在线帮助及文档。例如，基于Web的界面可能要求符合整个组织范围内的图形设计准则，比如菜单布局格式、色彩设计、组织标志的使用，以及必要的法律免责声明。
可用性需求：是一种系统需求，描述了与用户相关的操作特征，比如用户界面、工作程、在线帮助及文档。
可靠性需求描述了系统的可靠性，即系统出现了服务损耗、不正当处理，以及错误检测和恢复。可靠性需求通常是性能需求的一个子集。
可靠性需求：是一种系统需求，描述了系统的可靠性，比如，服务损耗、不正当理，以及错误检测和恢复。
安全需求描述了哪些用户可以在什么样的条件下执行系统功能。比如，对某些系统输出的访问可能受限于特定级别的管理人员或某些部门的员工。一些来自家庭的访问需要得到授权，而其他的一些访问只是来自该机构的本地网络。安全需求也可以应用在网络通信和数据存储等两个方面。例如，一个公司可能需要在通过Internet传送数据的时候要使用到加密技术，并且通过用户名和密码控制对数据库服务器的访问。
安全需求：是一种系统需求，描述了用户对特定功能的访问以及访问的条件。
对于新系统的完整定义，功能需求和非功能需求这两种类型都是必不可少的，并且系统分析阶段，它们都包含在系统需求调查中。功能需求通常记载在图表和文本模型中，而非功能需求则通常记载在针对模型的叙述性描述里。
4.4系统相关者——系统需求的来源
系统功能需求信息的主要来源是新系统的各种系统相关者。系统相关者是对系统成功实施感兴趣的人。通常，我们把系统相关者分为三类：①用户，那些实际使用系统处理日常事务的人；②客户，即那些购买和拥有系统的人；③技术人员，确保系统运在公司的计算机环境下的人。图4-2显示了对新系统感兴趣的各种系统相关者。前面我经讨论了用户和客户之间的差异。在分析阶段，分析员也需要考虑技术人员。在决定系统需求时最重要的步骤之一就是确定各种系统相关者。过去，由于在项目中只包括了一些系统相关者，并且系统仅仅是为这些人所设计，因此随着新系统的建立产生了一些问题此，你的首要任务之一就是确定对新系统感兴趣的各类系统相关者。你的第二个任务就是确保从各类系统相关者中识别出关键的人作为商业领域的专家。
系统相关者：对新系统的成功感兴趣的所有人。

图4-2对新系统开发感兴趣的各种系统相关者
4.4.1 用户
用户角色，也就是系统用户的类型，应该从两个方向进行定义：水平方向和垂直方向。在水平方向上的意思是说分析员必须在商业部门中寻找信息流。例如，一个新的库存系统也许将要影响进货部门、仓库、销售部门和生产部门。你必须确保这些部门的每个人讲述他们的需求。销售部门可能提供一些需求信息来帮助你确定系统什么时候，以及如何更新系统库存量，或者它可能向你提供在销售后、发货前提交一定数量的某种产品的信息。生产部门也许需要库存系统的信息来帮助制定生产计划。水平方向表明许多不同的部门。甚至那些看起来和新系统无关的部门，都应该包括在系统需求定义中。
在垂直方向上，我们需要职员、中层管理人员及高层管理人员提供信息需求。这些系统相关者中的每一个都将对系统有不同的信息需求，因此我们必须在设计时把这些信息需求包括在内。接下来的部分讲述了垂直方向上各种用户的特征和信息需求。这些相同的特征也适用于水平方向上的各个部门。
商业用户
商业用户是使用系统处理公司日常事务的人。我们通常把这些操作称为事务。事务是公司内完成的一项工作，例如“输入订单”。在第l章，你知道了事务处理系统是一个处理操作的系统。商业用户提供了日常的商业事务信息，同时他们也提供了系统应该如何持这些日常事务的信息。
事务：在一个组织中完成的一件工作或一项活动这样一件单一的事情。
信息用户
信息用户是需要从系统中获得现有信息的人。他可以是操作用户也可以是其他人。在某些情况下，企业也许想让信息对顾客是直接可用的。然而，系统不允许顾客在商业交易中输入信息，而仅允许其查看某些信息。查询用户可以向分析员提供这样一些信息：哪些信息是每天、每周、每月或每年都可以使用的，信息使用哪种格式对用户而言最便于浏览。
管理用户
管理人员负责使公司高效地完成每天的日常事务。因此，他们需要从系统中获得统计要信息。管理人员回答如下类型的问题以帮助分析员：
·系统必须生成哪些类型的报表？
·系统必须维护哪些类型的业绩统计数字？
·系统必须保存哪些类型的大量信息？新系统必须支持多大数量的交易？
·系统中是否有足够的控制来避免错误和人为破坏？
·可以向系统请求获得多少信息？这些请求的频率可以有多快？
主管用户
一个公司的高级行政人员不仅对刚刚讨论的日常问题感兴趣，更对企业的战略计划问题感兴趣。通常他们想从系统中获得信息，以便他们能够比较资源利用是否得到了全面改进。他们也许想把系统和其他系统连接起来，从而使得系统可以向他们提供工商业发展和方向等方面的战略信息。

外部用户
现在越来越多的系统允许外部实体直接访问系统。客户可以通过互联网直接访问系统。供应商可以通过访问系统来检查库存并初始化账单交易，由于这些用户不是公司的常规人员，所以他们比较难以区分和访问。然而，现在他们属于系统开发所需要的重点考对象。
4.4.2 客户
尽管项目小组必须满足用户的信息处理需求，但它也有责任满足客户的需求。在第3章我们把客户定义为给项目提供资金的人或团体。在许多情况下，客户和主管用户是同一组人。然而，客户也可能是单独的一组人，例如，客户可能是母公司的理事会或董事会。我们把客户包括在重要的系统相关者列表中是因为项目小组必须在项目的整个开发过程始终向客户提供项目进展的概要情况。客户或领导委员会的直接代表通常也负责批准或否决资金的使用。
4.4.3技术人员
尽管技术人员并不是真正的用户群，但他们是许多技术需求的来源。技术人员包括建立和维护公司计算机环境的人。这些人在诸如编程语言、计算机平台和其他设备方面对项目提供帮助。对某些项目来说，项目小组始终包括一组技术人员。而对另外一些项目说，只在需要时才把技术人员包括在内。
4.4.4 RMO的系统相关者
为了说明系统相关者对系统的不同看法，让我们看一下为RMO开发的客户支持系统。调查系统需求的一个重要部分是确定所有的系统相关者。在收集信息时，如果没有一些用户、客户和重要的技术人员进行咨询，那么所得到的需求信息将是不完备的。RMO中，新的订单处理系统的操作用户不仅包括处理邮件订单的职员，而且也包括通过电话处理订单的内部销售代表。他们对系统应该向他们提供什么功能持有不同的观点。销售代表关心为顾客查寻产品信息、证实产品的有效性和确定发货日期。负责邮件订单的职员关心的是把订单信息扫描进系统，而不是通过键盘把订单信息输入系统。仓库管理工人(他们负责在收到订单后装载货物)需要如下信息：装载完毕的订单信息、将要装载的订单信息、延期订货的订单信息，此外他们也需要标准操作界面来实现订单汇总发货和打印装货单。
John和Liz Blankens作为公司拥有者，对已订购和装载的产品报表特别感兴趣。此外他们对观察产品的季节性趋势也很关心。对于提供运动设备的企业，紧跟商品潮流而在淡季时退出是非常重要的。
RMO客户支持系统的部分开发资金来自RMO的内部流动资金。然而，资金也可以通过银行的专用信用部门获得。对于季节性需求，RMO通常有一个短期贷款额度。由于对资本货物来说，这个项目是一项比较长期的投资，因此Blankens夫妇为新系统争取到了另一种贷款。由于投资银行对项目的成功也非常感兴趣，因此在这种情况下，项目小组甚至要与银行人员举行面谈来看银行想要系统保存资金信息的哪些具体格式。
最后，由于系统将包括一些新技术——Internet和分布式系统，所以要求技术人员有大量相关知识。图4-3表明了RMO公司的上层成员，在图中指出了需要包含在需求定义中一些人。灰色的位置表明了主管人员和中层管理者，他们都作为系统相关者被涵盖在内。项目经理将列出所有和系统需求定义相关的用户的名单。这张公司图只是一个开始，其他的部门经理和一些关键的雇员也将被添加进来。

图4-3 RMO公司新系统的系统相关者
项目组如何确定要和哪些用户进行会谈呢？通常这是一个很难回答的问题。不过我们可通过分析新系统的作用域来开始这个过程。在确定系统的作用域以后，工作组必须认真分出所有以任何方式从系统中获取所需信息的人。这时，我们宁可多包含一些相关的人，也不能漏掉一些重要的需求来源。Barbara Halifax给John MacMurty发了一份备忘录来向他报告她对CSS相关者的划分的最新进展，以及她对信息收集的计划（见Barbara备忘录）。
备忘录
2005.3.10
To：John MacMurty
From：Barbara Halifax
RE：客户支持系统的更新
当我们开始进行项目中的事实发现活动的时候，我想让你知道我们正处在会谈和提问阶段。你可以附着的那张公司图上看出，我们已经确定了一些资深的管理者，他们应该是我们在事实发现过程中所要台谈的对象。如果我们漏掉一些重要的人员，请告知。
我们也和各部门的经理一起列出了各个部门需要进行会谈的人员名单。在有些部门，经理希望我们进行成组会谈，并让一些用户参与到mini-JAD会议中来。我觉得这样很好地帮助我们尽快地得出最后的结论。
然而，我们现在确实有个主要的问题。我们如何确定外部用户，如网络客户？我们如何将他们也包含进来？你觉得RMO愿意提供一种激励客户的方案吗(也许是以100美元的酬宾形式或是其他的某种方式)？
最后，你应该知道我们已经收集了所有现有表单、报告的复印件。使用现有的文档有助于我们解决一系列问题从而可以使我们开始工作。因为我们鼓励用户“跳出原有的模式来思考”，所以我们有可能在会时不使用调查表，而只是了解一些大家的想法和问题。
BH
cc：Steven Deerfield．Ming Lee
4.5信息收集技术