工程立项建议及其可行性

王少华武汉大学国际软件学院空间信息与数字工程研究中心工程立项、可行性分析与需求获取2023/1/28结构化分析设计过程阶段关键问题结束标准问题定义问题是什么？关于规模和目标的报告书可行性研究有可行的解吗？系统的高层逻辑模型数据流图成本/效益分析需求分析系统必须做什么？系统的逻辑模型数据流图数据字典算法描述

2006年9月28日6时52分结构分析设计过程阶段关键问题结束标准总体设计概括地说，应该如何解决这个问题？可能的解法：系统流程图成本/效益分析推荐的系统结构；层次图或结构图详细设计怎样具体地实现这个系统？编码规格说明：HIPO图或PDL编码和单元测试正确的程序模块源程序清单；单元测试方案和结果综合测试符合要求的软件综合测试方案和结果；完整一致的软件配置维护持久地满足用户需要的软件完整准确的维护记录2006年9月28日6时52分本质上是功能分解，以实现功能的过程为中心，而用户的需求变化主要是针对功能的。这就使基于过程的设计不易被理解；且功能变化往往引起结构变化较大，稳定性不好。系统有明确的边界定义，且系统结构依赖于系统边界的定义，这样的系统不易扩充和修改。数据与操作分开处理，可能造成软构件对具体应用环境的依赖，可重用性(reusability)较差.结构化技术的缺点2006年9月28日6时52分管理的范围有效的项目管理集中于三个P上：人员(people)、问题(problem)和过程(process)。其顺序不是任意的。任何管理者如果忘记了软件工程是人的智力密集的劳动，他就永远不可能在项目管理上得到成功；任何管理者如果在项目开发早期没有支持有效的用户通信，他有可能为错误的问题建造一个不错的解决方案。最后，对过程不在意的管理者可能冒把有效的技术方法和工具插入到真空中的风险。2006年9月28日6时52分一、工程立项建议1、立项原因2、立项基础3、国内外研究现状4、工程意义与目标5、用户调查6、投资条件7、投资周期8、技术力量与基础9、软件硬件价格与性能10、数据源状况11、应用前景12、效益评估13、可运行性评价2006年9月28日6时52分问题定义问题定义阶段必须回答的关键问题是：“要解决的问题是什么？”问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。问题定义阶段是生命周期中最简短的阶段，一般只需要一天甚至更少的时间。2006年9月28日6时52分二、可行性研究这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有可行的解决办法或值得做吗？可行性研究比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。做还是不做？联想集团领导人柳传志曾说：“没钱赚的事我们不干；有钱赚但投不起钱的事不干；有钱赚也投得起钱但没有可靠的人选，这样的事也不干。”柳传志为决策立了上述准则，同时也为可以行性分析指明了重点。2006年9月28日6时52分2.1可行性研究的任务可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决，可行性研究的目的不是解决问题，而是确定问题是否值得去解，以及关键技术、难点、能否解决。必须分析几种主要的可能解法的利弊，从而判断原定的系统目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。一般说来，可行性研究的成本只是预期的工程总成本的5%-10%。软件领域的可行性分析主要考虑四个要素：经济、技术、社会环境和人。项目的意义（社会的意义）技术可行性经济可行性操作可行性2006年9月28日6时52分3.1.1可行性研究的任务继续项目

可行性分析的四个任务

经济可行性经济实力经济效益社会可行性是否存在侵犯、妨碍行为技术可行性技术资源有效性开发风险操作可行性项目的运行方式在用户组织内是否行的通现有管理制度、人员素质和操作方式是否可行2006年9月28日6时52分2.2可行行性研研究的的步骤骤1系统统定义义，复查系系统规规模和和目标标、性性质、、范围围、约约束和和限制制2研究究目前前正在在使用用的系系统。。研究现现行系系统（（人工工/旧旧软件件)，，描绘绘系统统流程程图，，审核核。现有的的系统统必然然有某某些缺缺点，，新系系统必必须能能解决决旧系系统中中存在在的问问题。。3.导导出新新系统统的逻逻辑模模型。。分析员员应该该画出出描绘绘现有有系统统的高高层系系统流流程图图，并并请有有关人人员检检验他他对现现有系系统认认识是是否正正确。。千万万不要要花费费太多多时间间去了了解和和描绘绘现有有系统统的实实现细细节，，例如如，除除非是是为了了阐明明一个个特别别关键键的算算法，，否则则不需需要根根据程程序代代码画画出程程序流流程图图。2006年年9月月28日6时52分分2.3导出出新系系统的的高层层逻辑辑模型型4.设设计方方案.优秀的的设计计过程程通常常总是是从现现有的的物理理系统统出发发，导导出现现有系系统的的逻辑模模型，再参参考现现有系系统的的逻辑辑模型型，设设想目目标系系统的的逻辑辑模型型，最最后根根据目目标系系统的的逻辑辑模型型建造造新的的物理理系统统，并并进行行可行行性评评价（（4方方面））分析员员能够够使用用数据流流图描绘数数据在在系统统中流流动和和处理理的情情况，，从中中概括括地表表达出出他对对新系系统的的设想想。通通常为为了把把新系系统描描绘得得更清清晰准准确，，还应应该有有一个个初步步的数数据字字典，，定义义系统统中使使用的的数据据。数据流流图和和数据据字典典共同同定义义了新新系统统的逻逻辑模模型，以后后可以以从这这个逻逻辑模模型出出发设设计新新系统统。2006年年9月月28日6时52分分2.4重新新定义义问题题分析员员应该该和用用户一一起再再次复复查问题定定义、、工程程规模模和目目标，这次次复查查应该该把数数据流流图和和数据据字典典作为为讨论论的基基础。。可行性性研究究的前前四个个步骤骤实质质上构构成一一个循循环。。分析析定义义问题题，分分析这这个问问题，，导出出一个个试探探性的的解；；在此此基础础上再再次定定义问问题，，再一一次分分析这这个问问题，，修改改这个个解；；继续续这个个循环环过程程，直直到提提出的的逻辑辑模型型完全全符合合系统统目标标。2006年年9月月28日6时52分分2.5导出出和评评价供供选择择的解解法5.推推荐可可行的的方案案。分析员员应该该从他他建议议的系系统逻逻辑模模型出出发，，导出出若干干个较较高层层次的的（较较抽象象的））物理理解法法供比比较和和选择择。其次可可以考考虑操操作方方面的的可行行性。。考虑经经济方方面的的可行行性，，对每每个可可能的的系统统进行行成本本/效效益分分析。。最后为为每个个在技技术、、操作作和经经济等等方面面都可可行的的系统统制定定实现现进度度表，，不需需要（（也不不可能能）制制定得得很详详细，，通常常中需需要估估计生生命周周期每每个阶阶段的的工作作量。。2006年年9月月28日6时52分分2.5.1经济可行行性经济经济可行性性分析主要要包括：““成本———收益”分分析和“短短期——长长远利益””分析。成本-收益益分析最容容易理解，，如果成本本高于收益益则表明亏亏损了，如如果成本大大大高于收收益那就亏亏大了。2006年年9月28日6时52分2.6成本本/效益分分析直接效益服务节省开支提高工作效效率间接效益科学决策快速决策社会效益2006年年9月28日6时52分2.6.1成本考虑虑的方面（1）办公公室房租。。（2）办公公用品，如如桌、椅、、书柜、照照明电器、、空调等。。（3）计算算机、打印印机、网络络等硬件设设备。（4）电话话、传真等等通讯设备备以及通讯讯费用。（5）资料料费。（6）办公公消耗，如如水电费、、打印复印印费等。（7）软件件开发人员员与行政人人员的工资资。（8）购买买系统软件件的费用，，如买操作作系统、数数据库、软软件开发工工具等。有有些老板买买盗版的系系统软件，，却按市场场价算成本本，可从美美国佬那里里赚一笔。。（9）做市市场调查、、可行性分分析、需求求分析的交交际费用。。（10）公公司人员培培训费用。。（11）产产品宣传费费用。如果果用Internet作宣传传，则要考考虑建设Web站点点的费用。。（12）如如果客户是是政府部门门，还要充充分考虑用用于吃喝玩玩乐、行贿贿的费用。。（13）如如果公司的的风水不好好，会有很很多莫名其其妙的管理理费。每戳戳一个红艳艳艳的公章章都要化一一把钞票。。2006年年9月28日6时52分2.6.2短期———长远利益益分析人们喜欢吃吃着碗里的的、看着锅锅里的，还还想着别人人家里的。。短期利益益和长远利利益兼得是是人们梦寐寐以求的事事。开发策略2006年年9月28日6时52分2.6.3成本估计计-系统规规模1、代码码行技术--面向规规模的估计计（代码行行KLOC）·每千行代代码(KLOC)的的错误数。。·每千行代代码(KLOC)的的缺陷数。。·每行代码码(LOC)的成本本。·每千行代代码(KLOC)的的文档页数数。·每人月错错误数。·每人月代代码行(LOC)。。·每页文档档的成本。。2、任务务分解技术术—面向功功能的估计计（功能点点）用户输入数数：计算每个用用户输入，，它们向软软件提供面面向应用的的数据。输输入应该与与查询区分分开来，分分别计算。。用户输出数数：计算每个用用户输出，，它们向用用户提供面面向应用的的信息。这这里，输出出是指报表、屏幕幕、出错信息，等等等。一个报报表中的单单个数据项项不单独计计算。用户查询数数：一个查询被被定义为一一次联机输输入，它导导致软件以以联机输出出的方式产产生实时的的响应。每每一个不同同的查询都都要计算。。文件数：计算每个逻逻辑的主文文件(如数数据的一个个逻辑组合合，它可能能是某个大型数据库库的一部分分或是一个独立的文件件)。外部接口数数：计算所有机机器可读的的接口(如如磁带或磁磁盘上的数数据文件)，利用这这些接口可可以将信息息从一个系系统传送到到另一个系系统。2006年年9月28日6时52分问题分解及及过程分解解首先把软件件开发工程程分解为若若干个相对对独立的任任务，估计计每个任务务的成本时时，通常先先估计完成成该任务需需要用的人人力（以人人月为单位位），再乘乘以每人每每月的平均均工资而得得出每个任任务的成本本。最常用的办办法是按开开发阶段划划分任务。。如果软件件系统很复复杂，由若若干个子系统组成，则可可以把每个个子系统再再按开发阶阶段进一步步划分成更更小的任务。典型环境下下各个开发发阶段需要要使用的人人力的百分分比大致如如表所示。。2006年年9月28日6时52分2006年年9月28日6时52分软件规模的的例子2006年年9月28日6时52分3、自动动估计成本本技术采用这种技技术必须有有长期搜集集的大量历历史数据为为基础，并并且需要有有良好的数数据库支持持。2006年年9月28日6时52分参考书籍软件成本估估算：COCOMOII模模型方法出版社：：机械工业出出版社作者：：[美]勃姆姆(Boehm,B.W)等等/译者：：李师贤/杜云梅/李卫华等等/功能点分析析—成功软软件项目的的测量实践践作者：（美）DavidGarmus&DavidHerron/出版社：清华大学出出版社2006年年9月28日6时52分功能点分析析法功能点分析析法(FPA：functionpointanalysis)是在在需求分析析阶段基于于系统功能能的一种规规模估算方方法，是基基于应用软软件的外部部、内部特特性以及软软件性能的的一种间接接的规模测测量。功能点可以以用于“需需求文档””、“设计计文档”、、“源代码码”、“测测试用例””度量，根根据具体方方法和编程程语言的不不同，功能能点可以转转换为代码码行。2006年年9月28日6时52分功能能点点分分析析法法的的步步骤骤2006年年9月月28日日6时时52分分功能能点点分分析析法法FP=总总计计数数值值××［［0.65＋＋0.01××ΣΣFi］其中中，，““总总计计数数值值””是是所所有有功功能能点点条条目目的的总总和和。。Fi(i=1到到14)是是基基于于对对图图4-6中中问问题题的的回回答答而而得得到到的的““复复杂杂度度调调整整值值””(0到到5)。。等等式式中中的的常常数数和和信信息息域域值值的的加加权权因因子子是是根根据据经经验验确确定定的的。。Fi：：1.系系统统需需要要可可靠靠的的备备份份和和复复原原吗吗？？2.需需要要数数据据通通信信吗吗？？3.有有分分布布处处理理功功能能吗吗？？4.性性能能很很关关键键吗吗？？5.系系统统是是否否在在一一个个已已有有的的、、很很实实用用的的操操作作环环境境中中运运行行？？6.系系统统需需要要联联机机数数据据项项吗吗？？7.联联机机数数据据项项是是否否需需要要在在多多屏屏幕幕或或多多操操作作之之间间切切换换以以完完成成输输入入？？8.需需要要联联机机更更新新主主文文件件吗吗？？9.输输入入、、输输出出、、文文件件或或查查询询很很复复杂杂吗吗？？10.内内部部处处理理复复杂杂吗吗？？11.代代码码需需要要被被设设计计成成是是可可复复用用的的吗吗？？12.设设计计中中需需要要包包括括转转换换及及安安装装吗吗？？13.系系统统的的设设计计支支持持不不同同组组织织的的多多次次安安装装吗吗？？14.应应用用的的设设计计方方便便用用户户修修改改和和使使用用吗吗？？2006年年9月月28日日6时时52分分总计计数数值值信息域值乐观值可能值悲观值估算数权值记数值输入数20243024496输出数12152216580查询数16222822488主控文件数44541040外部接口数2232714总计数值

3182006年年9月月28日日6时时52分分因子值因子值备份和还原4信息域值复杂度5数据通讯2内部处理复杂度5分布式处理0设计成可复用的代码4关键性能4设计中的转换及安装3先有的操作环境3多次安装5联机数据登录4方便修改的应用设计5多屏幕输入切换5复杂度调整因子1.17估算算14个个复复杂杂度度加加权权因因子子（（Fi,根根据据问问题题对对项项目目的的影影响响取取值值范范围围是是0～～5）），，表表3给给出出了了因因子子值值。。FP=总总计计数数值值××[0.65+0.01××ΣΣFi]=3662006年年9月月28日日6时时52分分工作作量量估估算算2006年年9月月28日日6时时52分分工作作量量估估算算语言每功能点的SLOC默认C++53Delphi518HTML414VisualBasic624SQLdefault13默认Java2462006年年9月月28日日6时时52分分工作作量量估估算算用java2完完成成上上述述项项目目(366功功能能点点)时时，，将将大大约约需需要要下下列列SLOC数数：：L=366××46=16836行行=16.836KLOCE＝＝5.2××L0.91＝5.2××16.3860.91＝66人人/月月DOC＝＝49××L1.01＝49××16.3861.01＝826页页2006年年9月月28日日6时时52分分成本本估估算算项目目的的成成本本估估算算包包括括许许多多因因素素：：人力力成成本本、、办办公公费费用用、、管管理理费费用用、、设设备备和和软软件件等等的的购购置置费费用用、、场场地地租租金金、、旅旅差差费费等等等等。。对项项目目成成本本的的估估算算取取决决于于公公司司所所采采用用的的成成本本核核算算方方法法。。有有的的公公司司某某些些费费用用并并没没有有计计入入项项目目成成本本中中，，而而是是按按管管理理费费用用等等分分摊摊。。有的的从从历历史史数数据据求出出生生产产率率度度量量和和每每行行成成本本，，即行行／／PM(人人月月)和和元元／／行行，则则LOC的的值值与与元元／／行行相相乘乘得得到到成成本本，，用用LOC的的值值与与行行／／PM相相除除得得到到工工作作量量。。具具体体可可按按公公司司的的具具体体情情况况选选择择。。2006年年9月月28日日6时时52分分成本本估估算算E＝＝5.2××L0.91，L是是源源代代码码行行数数(以以KLOC计计)，，E是是工工作作量量（（以以PM计计））D＝＝4.1××L0.36，D是是项项目目持持续续时时间间(以以月月计计)S＝＝0.54××E0.6，S是是人人员员需需要要量量(以以人人计计)DOC＝＝49××L1.01。DOC是是文文档档数数量量(以以页页计计)2006年年9月月28日日6时时52分分制定定计计划划对软软件件项项目目进进行行估估算算的的第第三三步步是是根根据据工工作作量量制定定项项目目计计划划，目目的的是是用用文文件件的的形形式式，，把把对对于于在在开开发发过过程程中中人员员安安排排、、工工作作量量分分解解、、开开始始和和完完成成时时间间、、开开发发进进度度、、所所需需经经费费预预算算、、所所需需软软、、硬硬件件条条件件等等问题题作作出出的的安安排排记记载载下下来来，，以以便便根根据据本本计计划划开展展和和检检查查本本项项目目的开开发发工工作作。。可可以以根根据据自自己己的的历历史史数数据据或或行行业业模模型型决决定定所所需需的的资资源源并并落落实实到到项项目目计计划划。。可可以以采采用用上上述述的的IBM模模型型或或McConnell给给出出的的方方法法粗粗略略地地给给出出项项目目持持续续时时间间（（以以IBM模模型型为为例例））：：项目需要的人人员S＝0.54×E0.6＝0.54××660.6＝7人项目持续时间间D＝4.1×L0.36＝4.1×16.3860.36＝11月2006年9月28日6时52分成本/效益分分析的方法成本/效益分分析的第一步步是估计开发发成本、运行行费用和新系系统将带来的的经济效益。。应该比较新系系统的开发成成本和经济效效益，以便从从经济角度判判断这个系统统是否值得投投资，投资是是现在进行的的，效益是将将来获得的，，不能简单地地比较成本和和效益，应该该考虑货币的时间价价值。2006年9月28日6时52分贷币的时间价价值假设年利率为为i,如果现现在存入P元元，则n年以以后可以得到到的钱数为：：F=P（1+i）n就是P元钱在在n年后的价价值。反之，，如果n年后后能收入F元元线，那么这这些钱的现在在价值是:P=F/（1+i）n修改一个已有有库存清单系系统，使它能能在每天送给给采购员一份份定货报表。。修改已有的的库存清单程程序并且编写写产生报表的的程序，估计计共需5000元；系统统修改后能及及时定货将消消除零件短缺缺问题，估计计因此每年可可以节省2500元，五五年共可省12500元元。但是，不不能简单地把把5000元元和12500元相比较较，因为前者者是现在投资资的钱，后者者是若干年以以后节省的钱钱。假定年利率为为12%，利利用上面计算算货币现在价价值的公式可可以算出修改改库存清单系系统后每年预预计节省的钱钱的现在价值值，如表所示示。2006年9月28日6时52分2006年9月28日6时52分投资回收期所谓投资回收收期就是使累累计的经济效效益等于最初初投资所需要要的时间。例如，修改库库存清单系统统两年以后可可以节省4225.12元，比最初初的投资（5000）元元还少774.88元，，第三年以后后将再节省1779.45元。774.88/1779.45=0.44因此，投资回回收期是2.44年。2006年9月28日6时52分技术可行性（1）在给定的时间间内能否实现现需求说明中中的功能。如果在项目目开发过程中中遇到难以克克服的技术问问题，麻烦就就大了。轻则则拖延进度，，重则断送项项目。（2）软件的质量如如何？有些应用对实实时性要求很很高，如果软软件运行慢如如蜗牛，即便便功能具备也也毫无实用价价值。有些高高风险的应用用对软件的正正确性与精确确性要求极高高，如果软件件出了差错而而造成客户利利益损失，那那么软件开发发方可要赔惨惨了。（3）软件的生产率率如何？如果生产率低低下，能赚到到的钱就少，，并且会逐渐渐丧失竞争力力。在统计软软件总的开发发时间时，不不能漏掉用于于维护的时间间。软件维护护是非常拖后后腿的事，它它能把前期拿拿到的利润慢慢慢地消耗光光。如果软件件的质量不好好，将会导致致维护的代价价很高，企图图通过偷工减减料而提高生生产率，是得得不偿失的事事。技术可行性分分析可以简单单地表述为：：做得了吗？做做得好吗？做做得快吗？2006年9月28日6时52分社会环境社会环境的可可行性至少包包括两种因素素：市场与政政策。市场又分为未成熟的市场场、成熟的市市场和将要消消亡的市场。涉足未成熟的的市场要冒很很大的风险，，要尽可能准准确地估计潜潜在的市场有有多大？自己己能占多少份份额？多长时时间能实现？？挤进成熟的市市场，虽然风风险不高，但但油水也不多多。如果供大大于求，即软软件开发公司司多，项目少少，那么在竞竞标时可能会会出现恶性杀杀价的情形。。国内第一批批卖计算机的的、做系统集集成的公司发发了财，别人人眼红了也挤挤进来，这个个行业的平均均利润也就下下降了。将要消亡的市市场就别进去去了。尽管很很多程序员怀怀念DOS时时代编程的那那种淋漓尽致致，可现在没没人要DOS应用软件了了。学校教学学尚可用用DOS软件，，商业软件公公司则不可再再去开发DOS软件。政策对软件公公司的生存与与发展影响非非常大。整个个90年代，，中国电信的的收费相当高高，仅此一招招就把国内互互联网企业打打得奄奄一息息。某些软件件行业的利润润很高，但可可能存在地方方保护政策，，使竞争不公公平。政策不不当将阻碍软软件公司的健健康发展，可可最怕的还是是政府干预企企业的正当行行为。2006年9月28日6时52分人有句名言：““人分四类———人物，人人才，人手，，人渣。”(董军,软件件工程思想)如果一个软件件公司里上述述四类人齐全全了，那么最最好的分工是是让“人物”当当领导，“人才”做第第一线的开发发人员，“人手”做行行政人员，“人渣”负责责市场（行贿贿）。这里只谈公司司的领导与开开发人员“行行还是不行””。“人物””毕竟是少数数，“人才””可是济济的的。举重若轻的那类“人才才”可以做领领导，举轻若重的那类人才适适合做软件开开发人员。假假如一群持有有学士、硕士士和博士文凭凭的毕业生到到软件公司应应聘，该如何何录用呢？董军的建议如下：：先选择本科毕毕业生，因为为他们正当青青春、干劲十十足、不摆架架子、不耻下下问、要求不不高、奉献甚甚多。其次选择硕士士毕业生，如如果该生没象象范进中举时时那么老，并并且在读硕士士时没有天天天去造文章而而丢弃了编程程工作，那么么让有经验的的学士程序员员带他们煅练练几个月就可可以用了。如果学士、硕硕士被其它公公司取光了，，那只好捡几几个博士充数数。博士到了了软件公司有有什么用呢？？我想不出有有什么用，只只知道他们挺挺值得可怜的的：从硕士读读到博士出头头，这六七年年时间，真本本事没学多少少，倒学会““眼高手低””甚至“弄虚虚作假”；2006年9月28日6时52分6、推荐行动动方针可行性分析的的关键是提出出是否继续进进行这项开发发工程。并且且说明选择这这个解决方案案的理由。2006年9月28日6时52分7、草拟开发发计划除了工程进度度表之外还应应该估计:对各种开发人人员（系统分分析员，程序序员，资料员员等）各种资源（计计算机硬件，，软件、数据据、工具等等等）的需要情情况应该指明什么么时候使用多多长时间还应该估计系系统生命周期期每个阶段的的成本。2006年9月28日6时52分8、书写文档档提交审查应该把上述可可行性研究各各个步骤的结结果写成清晰晰的文档，请请用户和使用用部门的负责责人仔细审查查，以决定是是否继续这项项工程以及是是否接受分析析员推荐的方方案。OVER2006年9月28日6时52分3.Analysis&Specification需求分析不论是为客户户做软件项目目还是为自己己做软件产品品，都要进行行需求分析。。需求分析最最恼人之处是是难以在项目目刚启动时搞搞清楚需求，，如果在项目目做了一大半半时需求发生生了变化，那那将使项目陷陷入困境。3.3节解释释需求分析为为什么困难，，3.4节讲讲述如何进行行需求分析。。本章的需求求分析均不涉涉及编程，所所以不考虑结结构化、面向向对象等分析析方法。Requirementselicitation（需求获取）：Theprocessofdiscoveringtheclient’srequirements.Requirementsanalysis(需求分析））：Theprocessofrefiningandextendingtheinitialrequirementsdetermined.2006年9月28日6时52分RequirementsDefinitionRequirementsDefinition（需求定义））Customer-orienteddescriptionsofthesystem’sfunctionsandconstraintsonitsoperation（功能描述与与操作约束））Arequirementisafeatureofthesystemoradescriptionofsomethingthesystemiscapableofdoinginordertofulfillthesystem’spurpose.实现2006年9月28日6时52分RequirementsDefinitionIEEE用户解决问题题或达到目的的所需的条件件或能力。系统或系统部部件要满足合合同、标准、、规范或其它它正式规定文文档所需具有有的条件或能能力。一种反映上面面两条所描述述的条件或能能力的文档说说明。真正的“需求求”实际上存存在人们的脑脑海中，任何何文档形式的的需求（例如如：需求规格格说明）仅是是一个模型或或一种叙述。。2006年9月28日6时52分需求分析的重重要性开发软件系统统最为困难的的部分就是准准确说明开发发什么。最为为困难的概念念性工作便是是编写出详细细技术需求，，这包括所有有面向用户、面面向机器和其其它软件系统统的接口。同时这也是是一旦做错，，将会最终给给系统带来极极大损害的部部分，而且以以后再对它进进行修改也极极为困难。2006年9月28日6时52分WhatisthisPhaseFor?Majormisconception(误解）determiningwhatclientwants“IknowyoubelieveyouunderstoodwhatyouthinkIsaid,butIamnotsureyourealizethatwhatyouheardisnotwhatImeant!”(我我知道你相信信你理解了你你认为我所说说的，但我不不能确定你是是否认识到你你所听到的并并不是我所意意指的，GeorgeRomney)Mustdetermineclient’s&user’sneeds,Nottheclientwants.chancesforsuccessslimifyoudon’’tfigurethisout!2006年9月28日6时52分thegoalofthespecificationorsystemanalysisphasethegoalofthespecificationorsystemanalysisphaseistobuildamodelofthesoftwareproductthattheclientrequires.Theinformationdomainofaproblemmustberepresentedandunderstood.理解和描述问问题的信息范范围Thefunctionsthatthesoftwareistoperformmustbedefined.定义软件的功功能Thebehaviorofthesoftware(asaconsequenceofexternalevents)mustberepresented.描述软件对外外部事件的响响应Themodelsthatdepictinformation,function,andbehaviormustbepartitionedinamannerthatuncoversdetailinalayered(orhierarchical)fashion.描述信息、功功能和行为的的模型必须以以分层的方式式显示细节来来划分开Theanalysisprocessshouldmovefromessentialinformationtowardimplementationdetail.描述2006年9月28日6时52分需求分析为什什么困难（1）客户说说不清楚需求求；有些客户对需需求只有朦胧胧的感觉，当当然说不清楚楚具体的需求求。有些客户心里里非常清楚想想要什么，但但却说不明白白。如果客户本身身就懂软件开开发，能把需需求说得清清清楚楚，这样样的需求分析析将会非常轻轻松、愉快。。如果客户全全不懂软件，，但信任软件件开发方，这这事也好办。。分析人员可可以引导客户户，先阐述常常规的需求，，再由客户否否定不需要的的，最终确定定客户真正的的需求。最怕怕的就是“不不懂装懂”或或者“半懂充充内行”的客客户，他们会会提出不切实实际的需求。。（2）需求自自身经常变动动；需求肯定会变变动（1）尽可能能地分析清楚楚哪些是稳定定的需求，哪哪些是易变的的需求。以便便在进行系统统设计时，将将软件的核心心建筑在稳定定的需求上，，否则将会吃吃尽苦头。（2）在合同同中一定要说说清楚“做什什么”和“不不做什么”。。如果合同含含含糊糊，日日后扯皮的事事情就多。（3）分析人人员或客户理理解有误。客户表达的需需求，不同的的分析人员可可能有不同的的理解。写好需求说明明书后，要请请客户方的各各个代表验证证。如果问题题很复杂，双双方都不太明明白，就有必必要请开发人人员快速构造造软件的原型型，双方再次次论证需求说说明书是否正正确。由于客户大多多不懂软件，，他们可能觉觉得软件是万万能的，会提提出一些无法法实现的需求求。2006年9月28日6时52分如何进行需求求分析-应该该了解什么Toelicittheclient’’sneeds,themembersoftherequirementsteammustbefamiliarwiththeapplicationdomain.(熟悉客客户领域知识识）Tobuildaglossary(术术语表）用正确的术语语进行正确的的交流应该先了解宏宏观的问题，，再了解细节节的问题。2006年9月28日6时52分（1）最好为为每个需求注注释“为什么么”，这样可可让程序员了了解需求的本本质，以便选选用最合适的的技术来实现现此需求。（2）需求说说明不可有二二义性，更不不能前后相矛矛盾。如果有有二义性或前前后相矛盾，，则要重新分分析此需求。。2006年9月28日6时52分TypeofRequirementsBussinessrequirementsAsystemrequirement(alsocalledabusinessrequirement)isadescriptionoftheneedsanddesiresforaninformationsystem.Arequirementmaydescribefunctions,features(attributes),andconstraints.（系统需求是是对信息系统统的需求描述述）Userrequirements用户使用产品品必须要完成成的任务（业业务需求）2006年9月28日6时52分TypeofRequirementsFunctionalrequirements（功能能需求）Afunctionalrequirementisafunctionorfeaturethatmustbeincludedinaninformationsystemtosatisfythebusinessneedandbeacceptabletotheusers.（满足系系统需求的、、被用户认可可的系统功能能或者特征））Afunctionalrequirementdescribesaninteractionbetweenthesystemanditsenvironment..（（系统与环境境间的交互））2006年9月28日6时52分TypeofRequirementsnon-functionalrequirementsAnonfunctionalrequirementisadescriptionofthefeatures,characteristics,andattributesofthesystemaswellasanyconstraintsthatmaylimittheboundariesoftheproposedsolution.(限定范围围）Anonfunctionalrequirementoraconstraintdescribesarestrictiononthesystemthatlimitsourchoicesforconstructingasolutiontotheproblem.（限限定选择的解解决方案）2006年年9月月28日6时52分分Non-functionalRequirementsDefinesystempropertiesandconstraintse.g.reliability,responsetimeandstoragerequirements.ConstraintsareI/Odevicecapability,systemrepresentations系统表表现,etc.Processrequirementsmayalsobespecifiedmandating要求aparticularCASEsystem,programminglanguageordevelopmentmethod(过程要要求））Non-functionalrequirementsmaybemorecriticalthanfunctionalrequirements.Ifthesearenotmet达到,thesystemisuseless2006年年9月月28日6时52分分Non-functionalRequirementsNon-functionalRequirementsProductRequirementsOrganizationalRequirementsExternalRequirementsUsabilityRequirementsEfficiencyRequirementsReliabilityRequirementsPortabilityRequirementsDeliveryRequirementsImplementationRequirementsStandardsRequirementsInteroperabilityRequirementsEthicalRequirementsLegislativeRequirementsPerformanceRequirementsSpaceRequirementsPrivacyRequirementsSafetyRequirements法制2006年年9月月28日6时52分分LevelofRequirements业务需需求项目视图与范围文档用户需求用例文档质量属性功能需求系统需求软件需求规格说明其他非功能需求约束条件2006年年9月月28日6时52分分TypesofRequirementsTherequirementsdefinitionandspecificationdocumentsdescribeeverythingabouthowthesystemistointeractwithitsenvironment.Includedarethefollowingkindsofitems.PhysicalEnvironmentWhereistheequipmenttofunction?Isthereonelocationorseveral?Arethereanyenvironmentalrestrictions,suchastemperature温度,humidity湿度,ormagneticinterference磁干扰扰?2006年年9月月28日6时52分分InterfacesIstheinputcomingfromoneormoreothersystems?Istheoutputgoingtooneormoreothersystems?Isthereaprescribedwayinwhichthedatamustbeformatted?Isthereaprescribedmediumthatthedatamustuse?UsersandFactorsWhowillusethesystem?Willtherebeseveraltypesofusers?Whatistheskilllevelofeachtypeofuser?Howeasywillitbeforausertounderstandandusethesystem?Howdifficultwillitbeforausertomisuse误用thesystem?TypesofRequirements2006年年9月月28日6时52分分FunctionalityWhatwillthesystemdo?Whenwillthesystemdoit?Arethereseveralmodesofoperation?Howandwhencanthesystembechangedorenhanced?Arethereconstraintsonexecutionspeed,responsetime,orthroughput?DocumentationHowmuchdocumentationisrequired?Shoulditbeon-line,inbookformat,orboth?Towhataudienceiseachtypeofdocumentationaddressed?TypesofRequirements2006年9月月28日日6时52分DataForbothinputandoutput,whatshouldtheformatofthedatabe?Howoftenwilltheybereceivedorsent?Howaccuratemusttheybe?Towhatdegreeofprecisionmustthecalculationsbemade?Howmuchdataflowthroughthesystem?Mustanydataberetainedforanyperiodoftime?TypesofRequirements2006年9月月28日日6时52分ResourcesWhatmaterials,personnel,orotherresourcesarerequiredtobuild,use,andmaintainthesystem?Whatskillsmustthedevelopershave?Howmuchphysicalspacewillbetakenupbythesystem?Whataretherequirementsforpower,heating,orairconditioning?Isthereaprescribedtimetablefordevelopment?Istherealimitontheamountofmoneytobespentondevelopmentoronhardwareandsoftware?TypesofRequirements2006年9月月28日日6时52分SecurityMustaccesstothesystemortoinformationbecontrolled?Howwilloneuser’sdatabeisolatedfromothers?Howwilluserprogramsbeisolatedfromotherprogramsandfromtheoperatingsystem?Howoftenwillthesystembebackedup?Mustthebackupcopiesbestoredatadifferentlocation?Shouldprecautionsbetakenagainstfire,waterdamage,ortheft?TypesofRequirements2006年年9月28日6时52分QualityAssuranceWhataretherequirementsforreliability,availability,maintainability,security,andtheotherqualityattributes?Howmustthecharacteristicsofthesystembedemonstratedtoothers?Mustthesystemdetectandisolatefaults?Whatistheprescribedmeantimebetweenfailures?Isthereamaximumtimeallowedforrestartingthesystemafterafailure?Howcanthesystemincorporatechangestothedesign?Willmaintenancemerelycorrecterrorsorwillitalsoincludeimprovingthesystem?Whatefficiencymeasureswillapplytoresourceusageandresponsetime?Howeasyshoulditbetomovethesystemfromonelocationtoanotherorfromonetypeofcomputertoanother?TypesofRequirements2006年年9月28日6时52分CharacteristicsofRequirementsAretherequirementscorrect?正确Aretherequirementsconsistent?一致Aretherequirementscomplete?完整Aretherequirementsrealistic?现实Doeseachrequirementdescribesomethingthatisneededbythecustomer?必需？Aretherequirementsverifiable?可证明Aretherequirementstraceable?可跟踪2006年年9月28日6时52分ProblemsofSoftwareRequirementsStakeholdersdon’’tknowwhattheyreallywant.Stakeholdersexpressrequirementsintheirownterms.Differentstakeholdersmayhavesomeconflictingrequirements.Organisationalandpoliticalfactorsmayinfluencethesystemrequirements.Therequirementschangeduringthedevelopmentprocess.Newstakeholdersmayemerge.Requirementsspecificationistoosimple.Requirementsproblemsresultin40-60%softwareproblems.2006年年9月28日6时52分RequirementsDevelopment确定产品所所期望的用用户类；获取每个用用户类的需需求；了解实际用用户任务和和目标以及及这些任务务所支持的的业务需求求；分析源于用用户的信息息，以区别别用户任务务需求、功功能需求、、业务规则则、质量属属性、建议议解决方法法和附加信信息；将系统级需需求分为若若干子系统统，并将需需求中的一一部分分配配给软件组组件；了解相关质质量属性的的重要性；；商讨实施优优先级的划划分；将所收集的的用户需求求编写成规规格说明和和模型；评审需求规规格说明，，确保对用用户需求达达到共同的的理解与认认识，并在在整个开发发小组接受受说明之前前将问题都都弄清楚。。2006年年9月28日6时52分RequirementsManagement定义需求基基线；评审提出的的需求变更更，评估每每项变更的的可能影响响，从而决决定是否实实施它；以一种可控控制的方式式将需求变变更融入到到项目中；；使当前的项项目计划与与需求一致致；估计变更需需求所产生生影响并在在此基础上上协商新的的承诺；让每项需求求都能与其其对应的设设计、源代代码和测试试用例联系系起来以实实现跟踪；；在整个项目目过程中跟跟踪需求状状态及其变变更情况。。2006年年9月28日6时52分RequirementElicitation需求获取的的工作内容容聆听用户需需求分析人员应应与各种层层次的客户户交流和沟沟通，尽量量清楚理解解。分析和整理理所获取的的信息从用户一般般性的陈述述中提取用用户的真正正需求。形成文档化化的描述问题和需求求都需要形形成文档化化的描述，，使各种人人员一致理理解和认可可。需求获取的的关键沟通和交流流正确和清楚楚地理解2006年年9月28日6时52分Stakeholders2006年年9月28日6时52分RequirementsAnalysisTechniquesInterviewing（（访谈）Questionnaires（问卷卷）consultanexpert、askforadvice（（请教专家家）Formsanalyses（表格格分析）Existingsystemsanalysis(现存系系统分析））Scenarios（情景））Rapidprototyping（快速原原型）2006年年9月28日6时52分Interviewing直接与客户户交谈。如果分析析人员生有有足球评论论员的那张张“大嘴””，就非常常容易侃出出需求，或或名记者的的提问技巧巧。Structuredvs.Unstructured(程程式化和非非程式化））whatisthedifference?whatarethetradeoffs折衷?"Asweknow,Thereareknownknowns.Therearethingsweknowweknow.WealsoknowThereareknownunknowns.ThatistosayWeknowtherearesomethingsWedonotknow.Buttherearealsounknownunknowns,Theoneswedon'tknowWedon'tknow."––DonaldRumsfield,February12,2002,DepartmentofDefensenewsbriefingSpecific，，preplaned,close-endedquestionsvs.Open-endedQuestions(谨防满无无目的地））ContextualInquiry（打破破砂锅问到到底、顺藤藤摸瓜，Why？））Wayofunderstandingusers’needs&workpracticesmaster–apprenticemodel（师徒））allowscustomertoteachuswhattheydo!masterdoesthework&talksaboutitwhileworkingweinterrupttoaskquestionsastheygoTheWhere,How,andWhatexposetheWhy2006年年9月28日6时52分Communication用户采购者市场人员需求分析员员开发人员产品代表用户管理员员系统设计员员2006年年9月28日6时52分ContextualInquiryPrinciplesContextgototheworkplace&seetheworkasitunfoldspeoplesummarize,butwewantdetails–keepitconcrete“Weusuallygetreportsbyemail””,ask“CanIseeone?”Partnership（（合合伙伙））master-apprenticerelationship,yes;othermodels,noavoidinterviewer/interviewee(stopswork)allowsmoreapprenticeinteraction(alternate:watching&probing寻寻根根究究底底)Interpretation（（解解释释））goodfactsonlythestartingpoint––designsbasedoninterpretationsValidate（（确确认认））––runinterpretationsbytheusertoseeifyouarerightFocusinterviewerneedsdataaboutspecifickindofwork“steer””conversationtostayonusefultopics（驾驾驭驭谈谈话话主主题题））2006年年9月月28日日6时时52分分UIDesignProcessSpecProductionDesignRefinementDesignExplorationDiscoveryAssessneeds评评估估需需求求understandclient’’sexpectations(期期望望)determinescopeofprojectcharacteristicsofusersevaluateexistingsiteand/orcompetition2006年9月28日6时52分CommentonHumanFactorsHUIHuman-computerinterfaceKeyaspectofsuccessfulsoftwareproductintendedusersmustinteractw/itNeedtoconsider(考虑的因因素）expertiseofintendedusers(资深专专家型）&cognitiveabilities(who)whattaskstheydonow&willdo(what)Becaref