第4讲工程立项、可行性分析与需求获取

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

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分2.6.3问题分解及过程分解

首先把软件开发工程分解为若干个相对独立的任务，估计每个任务的成本时，通常先估计完成该任务需要用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本。最常用的办法是按开发阶段划分任务。如果软件系统很复杂，由若干个子系统组成，则可以把每个子系统再按开发阶段进一步划分成更小的任务。典型环境下各个开发阶段需要使用的人力的百分比大致如表所示。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.836KLOC

E＝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分RequirementsDefinitionRequirements

Definition（需求定义）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-functional

requirementsAnonfunctionalrequirementisadescriptionofthefeatures,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)Becarefulofbook’shintthatgoodUIdesignmightjustbe“commonsense”canonlybemadesuccessfulbyinvolvinguserinrepeatedprocessofdesign,prototype,test（使用户成功参与设计、原型、测试的重复进程）showntobetruetime&timeagaindesigneregobias(自我偏见）–wearenottheusersanymoreUser-friendlinessTakeSSD4ifyouwanttoreallylearnthis2006年9月28日6时52分ScenariosIllustratethemajorevents/actionstousersAscenarioisawayausermightutilizethetargetproducttoaccomplishsomeobjective.利用目标产品完成某一功能的方式oftenusestoryboards（情景板）&paperprototypesespeciallyusefulforUIdesignTolisttheactionscomprisingthescenario2006年9月28日6时52分RequirementsAnalysisTechniquesIllustratethemajorevents/actionstousersoftenusestoryboards&paperprototypesespeciallyusefulforUIdesign2006年9月28日6时52分2006年9月28日6时52分2006年9月28日6时52分FromScenariostoRapidPrototypes2006年9月28日6时52分TheusefulofScenariosTheycanbedemonstratethebehavioroftheproductinawaythatiscomprehensibletouser.Thiscanresultinadditionalrequirementscomingtolight.用用户理解的方式说明软件行为，并能发现额外的需求。Becausescenarioscanbeunderstoodbyusers,theutilizationofscenarioscanensurethattheclientandusersplayanactiverolethroughouttherequirementsanalysisprocess.在需求分析的整个进程中扮演重要积极角色。Scenarios(UseCases)playanimportantroleinobject-orientedanalysis.情景在面向对象分析中扮演重要角色。2006年9月28日6时52分RapidPrototypingAllowusersto“see”&useproposedsolutionsDevelopspecificationfromtheprototype/requirementsproceedwithrestofstagesinwaterfallmodelPrototypemustbeconstructed&changedquicklykeyfunctionalityomitsthingslikescalability,errorchecking,saving,etc.donotspendalotoftimeperfectingthecode/structureitisOKifithardlyworksorcrasheseveryfewminutesplantothrowitaway!becauseyouwill!putinfrontofcustomerASAP(尽快）&modifyinresponse2006年9月28日6时52分RapidPrototypingTools&TechniquesUIprototyping&otherrapiddevtoolshelpe.g.,DENIMHTML/HypertextsimplymockingupaUIinHTMLtoflipscreensalsodoneinPowerPoint,Director,HyperCard,etc.Interpretedlanguages&dev.environmentsSmalltalk,Lisp,java2006年9月28日6时52分DangerousVariantsofRPUsetherapidprototypingasthespecification?“productwilldowhatRPdoesplusfileupdating,etc.”notimewasteddrawingupspecsproblemsunlikelytobeacceptedasalegalcontracthardtomakegoodtestcasesw/oaspec.thereisnospecificationtorefertoduringmaintenanceRefinetherapidprototypeuntilitistheproduct?becomesbuild-and-fix->expensive!remember,putittogetherfast&nowyouaregonnachangeit!performanceconstraintsunlikelytobemetprototypeinadifferentlanguagetoavoidthis!目的不同，侧重点不同2006年9月28日6时52分SoftwarePrototype一个软件原型是所提出的新产品的部分实现，它比开发人员常用的技术术语更易于理解。建立原型的主要原因是为了解决在产品开发的早期阶段需求不确定的问题，用户、经理和其他非技术项目风险承担者发现在确定和开发产品时，原型可以使他们的想象更具体化。作用：明确并完善需求；探索设计选择方案；发展为最终的产品。类型：抛弃式原型和演化式原型2006年9月28日6时52分ThrowawayPrototype当我们遇到需求中的不确定性、二义性、不完整性或含糊性时，最有效的解决方法是建立抛弃式原型。使用过程：2006年9月28日6时52分EvolutionaryPrototype演化式原型适合于基于Web应用的系统开发，这种系统往往随着开发的进展本身的需求也在发生变化。与丢弃式原型不同，演化式模型一开始就必须具有健壮性和产品质量级的代码。使用过程：2006年9月28日6时52分PrototypeSelection矛盾2006年9月28日6时52分PrototypingMethodsandToolsFourthgenerationtechniquesencompassabroadarrayofdatabasequeryandreport-inglanguages,programandapplicationgeneratorsandotherveryhigh-levelnonprocedurallanguagesgenerateexecutablecodequicklyReusablesoftwarecomponentsUseasetofexistingsoftwarecomponentsFormalspecificationandprototypingenvironmentsformallanguagesautomatedtools2006年9月28日6时52分ManagementImplicationsofRapidPrototypingCanuserapidprototypingtoachieveconsensus（一致意见）Expectationsmustbemanagedinadvance（提前管理期望）immediatedeliveryoffinishedproductinstantmaintenanceofoperatingproductRPshowntoleadtoproductsw/lesscode&effortincentivetoleaveunessentialfeatures（非本质）outoftheRP->oftenleaveoutofthefinalproductalsoleadtoeasiertolearn&useproductsWaterfallmodelassumesgetthingsright1sttimebadassumption…iterativeRPismorerealisticBepreparedformoreclient/userinteraction2006年9月28日6时52分Questionnaire（问卷调查）Thetechniqueisusefulwhentheopinionsofhundredsofindividualsneedtobedetermined.征求多人意见。Moreaccurate.Thereisnowaythataquestioncanbeposedinresponsetoananswer.(根据某一个回答再提问）2006年9月28日6时52分Formsanalyses（表格分析）