要认识与掌握某一客观事物，必须经历由宏观到微观的多次反复的过程。只有从宏观上反复迭代几次，才能看清全貌，掌握事物的宏观发展规律。只有从微观上反复迭代几次，才能吃透每个细节，掌握事物的微观发展规律。
习 题 3
3.1 为什么说立项（或签订合同）是一切项目的源头，也是软件项目的源头？ 立项的过程就是软件企业决定是否去开发某个项目或产品的过程。只有立项完成以后企业领导部门才会下达“任务书”，开发部门开始组成开发团队，成立项目组。
3.2 立项的具体表现形式是什么？
企业的市场销售部门在市场调研的基础上，分析该产品是否有市场前景，以及企业是否有能力开发出该产品，并具体列出系统的功能、性能、接口和运行环境等方面的需求情况，当前客户群和潜在客户群情况，以及投入产出分析，然后写出立项建议书，召开立项论证会，决定是否立项。
3.3 《立项建议书》的编制者为什么主要是软件公司的市场销售人员，而不是开发人员？ 软件开发出来终归要推向市场的，软件能不能被市场接受是软件开发成功的标准。市场销售人员长期和市场客户打交道，他们最了解客户和市场的需求，最知道什么样的产品具有巨大商机。
3.4 为什么将项目的市场前景、功能、性能、接口、风险作为《立项建议书》的主要内容？
一切软件项目或软件产品，都是为了实现用户需求中的“功能、性能、接口”三项具体目标。软件是否有市场前景，是软件开发是否成功的标志，有了市场软件才能带来利润。风险分析是对开发此软件的政策风险、环境风险、技术风险、技能风险等进行分析，这对公司按时保质保量地完成软件开发，是必不可少的。
3.5 什么叫风险分析？技能风险与技术风险有何区别？
这里的风险分析是指软件立项过程中对产品开发、销售等可能出现的风险进行分析。分析方法是将一个大风险化解为多个小风险，然后再一个个克服小风险。
技术风险是指采用新技术的风险程度。技能风险是指项目组成员掌握新技术的风险程 度。两者的区别在于一个是说新技术（如新的开发工具，新的设计思想）本身的风险，一个是说人员要掌握这种新技术的风险。
3.6 行业领域业务专家与产品经理有何异同？ 行业领域业务专家是精通某行业领域业务的人，在讲标时能把投标书的内容准确、生动地表述出来，使客户心服口服。而产品经理是某产品需求分析和概要设计的经理或专家，主要负责产品的立项、需求、设计和销售等业务。两者的相同点是：必须精通该产品的功能、性能和接口。不同点是：前者突出熟悉产品的应用业务领域，后者突出熟悉产品的需求与设计。
3.7 《合同》、《任务书》、《立项建议书》三者有何异同？有何关系？
合同是与固定客户签订的协议书，签订合同后软件公司启动该项目的开发，该软件被称为“订单软件”。
立项建议书是相对“非订单软件”而言的，是相关人员对立项过程的书面描述。 任务书是企业决定开发某个软件时，对此任务的具体部署情况，以书面的形式表达出来，包括正文和附件。
只有立项建议书或合同签订以后才能下达任务书，三者都是软件开发的源头。
3.8 下达任务的时间和方法是什么？
满足以下三个条件中的任意一个，即可下达任务书： （1）企业已签订了项目《合同》。 （2）《立项建议书》已通过了评审。
（3）作为特殊情况，软件组织的上级下达了某个项目的指令性软件开发计划。例如，有跨组织、跨部门的某个大系统项目，软件的需求由它的系统总体设计组分配。 下达任务书的方法是：
（1）下达一份《任务书》的正文。包括任务的下达对象、内容、要求完成的日期、决定投入的资源、必要时包括任命项目经理（技术经理和产品经理）、其他保证措施、奖惩措施等。《任务书》的正文可长可短，若合同或立项建议书很详细，则正文可短。若合同或立项建议书很粗略很短，则正文应该详细，当然也应该很长。
（2）下达一份《任务书》的附件。一般情况下它就是软件《合同》或《立项建议书》，如果是指令性计划，它的格式和内容，也应与《合同》或《立项建议书》基本相同，即附件的内容应覆盖系统的功能点列表、性能点列表、接口列表、资源需求列表、开发进度列表、阶段评审列表等。
3.9 请进行社会调查，收集材料，用事实说明“立项就是决策”的道理。
2003年初冬，山东某软件公司的老总在西安出差，发现西安市的大中型餐厅基本上都有电子点菜系统，客人一点菜，信息马上出现在厨房大师傅眼前，大师傅马上炒菜，服务员很快上菜，他感到很有意思。后来一打听，这个“餐饮系统”是北京某软件公司开发的。于是这位老总又飞到北京，拜访了“餐饮系统”的开发公司，了解到该公司经济效益不错，而且还到几家餐饮店去就餐，亲身体验“餐饮系统”的使用情况，收集用户意见。返回山东后，老总拍着脑袋决定马上立项，快速开发本公司的“餐饮系统”。不到三个月，“餐饮系统”开发完毕，但是在后来的两年中，该系统在山东某市总共只卖出两套，投入与产出比是5︰1。这是为什么？就是因为该城市是中等城市，不像北京、西安是大城市，“餐饮系统”的客户群，实在是少得可怜。
立项就是决策，IT企业的决策必须按照决策程序进行，没有决策程序就要先制定决策程序，不能一个人拍脑袋定决策。
3.10 试述《商业MIS开发任务书》的优缺点及需要如何改进。 选作题，课外作业。
3.11 请在老师的指导下，选定一个项目，写出一份《立项建议书》。 选作题，课外作业。
3.12 对软件项目和产品的“功能、性能、接口”三项指标如何理解？
一切项目或产品都是为了解决自身的“功能、性能、接口”问题，软件项目或产品更是这样。所以，从软件立项、需求、设计、编程、测试、维护，自始至终都要毫不动摇地坚持“功能、性能、接口”三项指标。
3.13 请用PowerPoint工具制作一份“图书馆信息系统”的投标书，并进行试讲。 选作题，课外作业。
3.14 按照老师建议的其他实践项目，2~3人一组，完成项目的《立项任务书》和《投标书》，并进行《投标书》讨论与试讲。
选作题，课外作业。
习 题 4
4.1 为什么需求分析特别重要？ 需求分析特别重要，是因为：
（1）许多大型应用系统的失败，最后均归结到需求分析：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
（2）需求分析的输出文档是《用户需求报告》，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）需求分析要占用整个软件开发时间或工作量的30%左右。
（4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。
根据以上4个原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去作项目需求。正因为如此，“系统分析员”才是软件行业中的最高技术职称。
4.2 需求分析的目的是什么？需求分析的难点在哪里？ 软件需求分析，其目的是用于说明软件产品或软件项目需要满足的条件和限制。在软件工程项目中首先要获取用户的需求，通过对软件需要的提取、分析、文档化及验证，为进一步的设计和实现提供依据。
需求分析的难点是：在系统的功能、性能和接口方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。万一需求有一点变化，双方必须履行“需求变更管理程序”，而变更管理程序在签订合同时已经做了规定。要知道，合同是具有法律效力的。
4.3 需求分析的理论基础有哪些？
需求分析的理论基础有：什么是软件需求；软件需求需要量化；需求是一个过程；需求过程中的角色；需求过程是一个迭代的过程；需求来源等6条理论基础。
4.4 为什么说需求过程是一个迭代过程？
由于人们对客观事物的认识是不断深化的，所以需求过程是一个迭代过程，每次迭代提供更高质量和更详细内容的软件需求。这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为需求不足而被推翻。
在很多情况下，对需求的理解会随着设计过程和实现过程的深入而不断深化，这也会导致在软件生命周期的后期，重新修订软件需求。原因可能来自于错误的分析，客户环境和业务流程的改变，市场趋势的变化等。无论是什么原因，软件分析师应认识到需求变化的必然性，并采取相应的措施，减少需求变更对软件系统的影响。
4.5 为什么说需求分析是面向流程的？
系统的功能、性能、接口、界面都是在流程中动态实时的反映出来。在所有的流程（物流、人流、资金流、信息流、单据流、报表流、数据流）中，数据流最重要，也最具有代表性。因为在计算机网络系统内，一切流程都表现为数据流，或者说是数据流在不同方向的投影。而流程是动态的、实时的。所以说，需求分析是面向流程的。
4.6 需求分析的基本思路是什么？
需求分析的思路，是从用户的功能需求（系统需要做什么）出发，由系统的业务流程和数据流程导出系统的业务模型和功能模型，识别出系统的元数据和中间数据，为今后设计数据模型做好充分准备。同时，对系统的软、硬件环境配置，开发工具，开发工期，费用，开发进度，培训，系统风险进行评估。
4.7 解释术语：元数据、实体、中间数据。
元数据是组织数据的数据，描述数据的数据，关于数据的数据。 实体（指实体集或实体型），是一组相关元数据的集合。
中间数据（有的书上称为查询数据）是组织统计数据的数据，描述统计数据的数据，关于统计数据的数据。
4.8 为什么说元数据的分析与识别是需求分析的议题之一？
元数据是组织数据的数据，描述数据的数据，关于数据的数据。通俗地讲，元数据就是信息系统中实体名及其属性名的集合，或者说就是基表的表名与字段名的集合。由于信息系统的设计与实现，都是面向元数据的，所以说元数据的分析与识别是需求分析的议题之一。
元数据分析的出发点是业务模型和功能模型，落脚点是系统中的实体及其属性，是企事业单位的数据模型中的所有元素。
4.9 元数据与中间数据之间，有什么关系？请举例说明。
元数据与中间数据间的关系是一种因果关系。
元数据对应原始单据，中间数据对应查询、统计、报表。元数据将原始单据中录入的数据组织起来变成基表中的记录，这些记录称为基础数据。中间数据将输出数据组织起来变成中间表中的记录，这些记录称为统计数据。
中间表中的记录是由基表中的记录派生（推导、加工、处理）出来的，为了叙述简单，我们说“中间数据是由元数据派生出来的”。
例如，人力资源系统中的员工基本情况表中的“姓名、性别、出生日期、文化程度、毕业学校、身份证号”等是元数据，而通过统计后得出的软件开发部1980年以后出生的人员情况表中的“姓名、性别、文化程度、毕业学校”，它们是中间数据。
4.10 业界存在哪三种需求分析方法？你认为哪一种方案更好？
业界存在三种需求分析方法：面向功能分析、面向对象分析、面向数据分析。
以上这三种方法，各自适用于不同的目标系统。目前时尚的方法是面向对象，包括面向主体和面向方法。总的来说，对于系统软件和应用软件来说，面向功能需求分析的方法简单明了，而面向对象的需求分析方法则复杂抽象。对于以关系数据库为平台的信息系统软件来说，面向数据需求分析方法的特点是抓住了本质。但是，这三种分析方法都离不开面向流程分析这根总线：功能、对象、数据都是在流程中产生的，又都是为流程服务的。
4.11 需求管理过程的目标和内容是什么？
需求管理的目标，是保证软件项目或产品满足客户在软件功能、性能、接口三个方面的需求。
需求管理过程的内容，主要包括需求确认、需求评审、需求追踪和需求变更活动管理。
4.12 为什么对需求文档要进行同行评审？
同行评审，是软件工作产品验证的活动，其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。重点在于发现软件工作产品中的缺陷。另外，由于进行同行评审，使大量人员对软件系统中原本不熟悉的部分更加了解，因此同行评审还提高了项目的连续性，培训了后备人员。
4.13 《用户需求报告》与《需求分析规格说明书》有何差异？ （1）用户需求报告是对外的，需求规格说明书是对内的。
用户需求报告是站在用户（使用者）的角度、用他们可以看懂的语言（比如自然语言）写的，需要用户签字确认。
需求规格说明书则不同，它是对内的，不需要用户签字确认。它是站在开发者的角度、可以采用形式化或半形式化的语言进行描述。
（2）一般来说，用户需求报告是合同的产物，需求规格说明书是立项建议书的产物。 用户需求报告是对合同而言的。需求规格说明书是对立项建议书而言的。 （3）由用户需求报告可产生需求规格说明书。
签完合同后，一般是先写出用户需求报告，后写出需求规格说明书。当需求报告由用户签字确认后，需求规格说明书很快就出来了。
4.14 怎么理解“不符合项”？ 为什么要对它进行跟踪管理？
不符合项是指没有满足要求的项，不一定是错误，跟Bug是不同的。
跟踪的意思在于，获得需求目前的实现状态，确保用户所有的需求都得到满足。可靠的跟踪信息可为需求变更、系统维护、关键成员离开、系统再设计和类似系统设计等很多方面，提供参考和指导，并可以减少风险和提高项目成功率。
4.15 为什么说“只考虑目标系统是什么、而不考虑目标系统怎么做的需求分析观点，
是片面的、表面的、不可取的”？
因为有些需求分析问题，在需求分析阶段开发者感觉不出来，到了设计阶段才会感觉出来，此时才发现设计的资料不够、条件缺少，即需求没有完全到位，需要做第二次需求分析。所以说，