3．n个人被分成t个小组；每一个小组完成一个或多个功能任务；每一个小组有一个特定的结构，该结构是为同一个项目的所有小组定义的；和谐工作由小组和软件项目治理者共同操纵。
2.3问题
◇软件范畴〔详见第三部分——软件需求〕
软件项目治理的第一个活动是的确定。
范畴是通过回答以下问题来定义的：
背景：
信息目标：
功能和性能：
◇问题分解
问题分解，有时称为划分，是一个软件需求分析的核心活动。
在确定软件范畴的活动中并没有完成分解问题，分解一样用于两个要紧领域：
〔1〕〔2〕
2.4过程
软件过程的一样时期〔定义、开发和爱护〕适用于所有软件项目。
问题在于如何选择一个适合项目要开发的软件的过程模型。
小结：
软件项目治理是软件工程的爱护性活动。
它先于任何技术活动之前开始，且连续贯穿于整个运算机的定义、开发和爱护之中。
第3章软件项目打算
3.1项目打算目标
软件项目打算的目标是提供一个框架，使得治理者能够对、及进行合理的估算。
这些估确实是软件项目开始时在一个限定的时刻框架内所做的，同时随着项目的进展不断更新。
此外，估算应该定义〝〞及〝〞，使得项目的结果能够限制在一定范畴内。
3.2软件范畴
软件项目打算的一个活动是确定。
在系统工程时期应该对分配给软件的功能及性能加以评估，以建立一个项目范畴，该范畴在治理级及技术级均是无二义性的和可明白得的。
〔如何猎取定义软件范畴所需的信息将在软件需求部分详细讲解。
〕
3.3资源
软件打算的第二个任务是估算完成。
◇人力资源
一个软件项目所需的人员数目在完成了开发工作量的估算之后就能够确定。
◇可复用的软件资源
可复用性是指。
在打算进行过程中应该考虑的四种软件资源分类是：
可直截了当使用的构件：
具有完全体会的构件：
具有部分体会的构件：
新构件：
◇环境资源
支持软件项目的环境，通常被称为软件工程环境，集成了硬件及软件两大部分。
3.4自行开发和购买的决策
（1）购买可直截了当使用的软件〔或被授权使用〕；
（2）购买〝具有完全体会〞或〝具有部分体会〞的软件构件，然后进行修改和集成，以满足特定的需求；
（3）软件能够由一个别处的承包商依照买方的专门需求定制开发。
软件猎取的步骤依照要购买的软件的要求程度及最终价格来定义。
在某种情形下〔如，低成本的PC软件〕，直截了当购买并试验比起对可选的软件包进行冗长的评估要廉价得多。
而关于比较昂贵的软件产品，可采纳以下指导原那么：
（1）建立所需软件的功能及性能需求，定义任何可能的可测量特性。
（2）估算内部开发的成本及交付日期。
（3）选择三到四个最符合你的需求的候选软件。
（4）选择能够有助于建筑所需软件的可复用软件构件。
（5）建立一个比较矩阵，对关键功能进行认真比较。
或者，进行基准测试，以比较候选软件。
（6）依照往常产品的质量、开发商的支持、产品的方向、以及其名声，来评估每个候选软件包或构件。
（7）联系该软件的其他用户并询问其意见。
自行开发或是购买的决策是依照以下条件决定的：
（1）？
（2）？
（3）？
第4章风险治理
4.1软件风险
项目风险威逼到项目打算。
技术风险威逼到要开发软件的质量及交付时刻。
商业风险威逼到要开发软件的生存能力。
第5章项目进度安排及跟踪
5.1差不多概念
尽管软件延期交付的缘故专门多，然而大多数都能够追溯到下面列出的一个或多个全然缘故上：
◆一个不现实的截止期限。
◆客户需求发生变化。
◆所需的资源数量估量不足。
◆在项目开始时，没有考虑风险。
◆事先无法估量的技术困难。
◆事先无法估量的人力困难。
◆人员之间的交流不畅。
◆项目治理者未能发觉进度拖后。
5.2差不多原那么
同软件工程的所有其他领域一样，有一些差不多原那么能够指导软件项目的进度安排：
◇划分：
项目必须被划分成假设干能够治理的活动和任务。
为了实现项目的划分，对产品和过程都需要进行分解。
◇相互依靠性：
各个被划分的活动或任务之间的相互关系必须是确定的。
有些任务必须顺序发生；而其他的那么能够并发进行。
有些活动只有在其他活动产生的工作产品完成时才能够开始，而其他的那么能够独立进行。
◇时刻分配：
必须为每个被调度的任务分配一定数量的工作单位〔例如，假设干人天的工作量〕。
此外，必须为每个任务指定开始和终止日期，这些日期是与工作完成的方式相互依靠的〔全职依旧兼职〕是工作方式的函数。
◇工作量确认：
每个项目都有预定数量的人员参与。
在进行时刻分配时，项目治理者必须确保在任意时段中分配给任务人员数量可不能超过项目组中的人员数量。
◇定义责任：
每个被调度的任务都应该指定某个特定的小组成员来负责。
◇定义结果：
每个被调度的任务都应该有一个定义好的结果。
关于软件项目而言，结果通常是一个工作产品〔例如一个模块的设计〕或某个工作产品的一部分。
通常将多个工作产品组合成〝可交付产品〞。
◇定义里程碑：
每个任务或任务组都应该与一个项目里程碑相关联。
当一个或多个工作产品通过质量复审同时得到认可时，标志着一个里程碑的完成。
注：
随着项目进度的进展，上述每一条原那么都会被用到。
5.3人员与工作量之间的关系
工作量分布：
40-20-40规那么：
第三部分软件需求
●什么是软件需求？
●什么缘故要进行软件需求调研？
●如何通过工程方法获得高质的软件需求？
●如何通过需求治理在工程进展中坚持需求约定集成性和精确性？
第6章差不多的软件需求？
6.1软件需求
需求的层次：
软件需求包括三个不同层次——、和——也包括非功能需求。
业务需求：
反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范畴文档中予以说明。
用户需求：
文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
功能说明：
定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
6.2不适当的需求过程所引起的一些风险：
◇用户不多导致产品无法被同意；
◇用户需求的增加带来过度的耗费和降低产品的质量；
◇模棱两可的需求说明可能导致时刻的白费和返工；
◇用户增加一些不必要的特点和开发人员画蛇添足；
◇过分简略的需求说明以致遗漏某些关键需求；
◇忽略某类用户的需求将导致众多客户的不满；
◇不完善的需求说明使得项目打算和跟踪无法准确进行。
6.3高质量的需求过程带来的好处
1．重做工作大大减少；
2．幸免高出的68倍成本；
3．使产品更富吸引力；
4．拥有忠实的客户关系。
6.4优秀需求具有的特点
1．完整性
2．正确性
3．可行性
4．必要性
5．划分优先级
6．无二义性
7．可验证性
6.5需求的开发
需求开发可分为：
、、和四个时期。
第7章客户的需求观
7.1谁是客户
通常意义下，客户是指直截了当或间接从产品中猎取利益的个人或组织。
软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者或是获得产品所产生的结果的人。
7.2客户与开发人员之间的合作关系
只有当双方参与者都明白要成功需要什么，同时也应明白要成功合作伙伴方需要什么时，才能建立起一种合作关系。
由于项目压力与日渐增，所有风险承担者有着一个共同的目标这一点容易被遗忘。
事实上大伙儿都想开发出一个既能实现商业价值，又能满足用户需求，还能使开发者感到满足的优秀软件产品。
第8章需求工程的举荐方法
8.1需求猎取
（1）确定需求开发过程
（2）编写项目视图和范畴文档
（3）将用户群分类并归纳各自特点
（4）选择每类用户的产品代表
（5）建立起典型用户的核心队伍
（6）让用户代表确定使用实例
（7）召开应用程序开发联系会议
（8）分析用户工作流程
（9）确定质量属性和其它非功能需求
（10）通过检查当前系统的问题报告来进一步完善需求
（11）跨项目重用需求
8.2需求分析
需求分析包括提炼、分析和认真审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地点。
分析员通过评判来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。
分析的目的在于开发出高质量和具体的需求，如此你就能作出有用的项目估算并能够进行设计、构造和测试。
8.3需求规格说明
不管你的需求从何而来，也不管你是如何样得到的，你都必须用一种统一的方式来将它们编写成可视文档。
业务需求要写成项目视图和范畴文档。
用户需求要用一种标准使用实例模板编写成文档。
而软件需求规格说明那么包含了软件的功能需求和非功能需求。
8.4需求验证
验证是为了确保需求说明准确、完整的表达必要的质量特点。
第9章软件需求与风险治理
与需求有关的风险:
◆需求猎取
◆需求分析
◆需求规格说明
◆需求验证
第10章建立项目视图与范畴
项目视图和范畴的文档把业务需求集中在一个简单、紧凑的文档里，那个文档为以后的开发工作奠定了基础。
第11章倾听客户的需求
11.1需求猎取的指导方针
需求猎取可能是软件开发中最困难、最关键、最易出错及最需要的方面。
需求猎取只有通过有效的客户——开发者的合作才能成功。
分析者必须建立一个对问题进行完全的环境，而这些问题与产品有关。
11.2对客户输入进行分类
不要希望你的客户会给需求分析者提供一个简洁、完整、组织良好的需求清单。
分析者必须把代表客户需求的许多信息分成不同的类型，如此他们就能合理地编写信息文档并把它们用于最合理的方式上。
11.3如何明白你何时完成需求的猎取
◆假如用户不能想出更多的使用实例，也许你就完成了收集需求的工作。
用户总是按其重要性的顺序来确定使用实例的。
◆假如用户提出新的使用实例，但你能够从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获得的其它使用实例的可选过程。
◆假如用户开始重复原先讨论过的问题，现在，也许你就完成了收集需求的工作。
◆假如所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
◆假如用户提出对今后产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
第12章编写需求文档
12.1用户需求规格说明书模板〔见附件〕
12.2编写需求文档的原那么
◆保持语句和段落的简短
◆采纳主动语态的表达方式
◆编写具有正确的语法、拼写和标点的完整句子
◆使用的术语与词汇表中所定义的应该一致
◆需求陈述应该具有一致的样式
◆为了减少不确定性，必须幸免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可同意的和健壮的。
◆幸免使用比较性的词汇，例如，提高、最大化、最小化和最正确化。
定量地说明所需要提高的程度或者说清一些参数可同意的最大值和最小值。
第13章软件的质量属性
13.1非功能需求
用户总是强调确定他们的功能、行为或需求——软件让他们做的情况。
除此之外，用户对产品如何良好地运转抱有许多期望。
这些特性包括：
产品的易用程度如何，执行速度如何，可靠性如何，当发生专门情形时，系统如何处理。
这些被称为软件质量属性的特性是系统非功能部分的需求。
13.2定义质量属性
对用户重要的属性
（1）有效性：
有效性指的是在预定的启动时刻中，系统真正可用同时完全运行时刻所占的百分比。
（2）效率：
效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的。
假如系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。
（3）灵活性：
就像我们所明白的可扩充性、增加性、可延伸性和可扩展性一样，灵活性说明了在产品中增加新功能时所需工作量的大小。
（4）完整性：
完整性〔或安全性〕要紧涉及：
防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。
（5）互操作性：
互操作性说明了产品与其它系统交换数据和服务的难易程度。
（6）可靠性：
可靠性是软件无故障执行一段时刻的概率。
（7）健壮性：
健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或专门的操作情形时，能连续正确运行功能的程度。
（8）可用性：
可用性也称为〝易用性〞和〝人类工程〞，它所描述的是许多组成〝用户友好〞的因素。
可用性衡量预备输入、操作和明白得产品输出所花费的努力。
13.3属性的取舍
有时，不可幸免地要对一些特定的属性进行取舍。
用户和开发者必须确定哪些属性比其它属性更为重要，并定出优先级。
在他们决策时，要始终遵照优先级。
第14章设定需求优先级
什么缘故要设定需求的优先级：
当客户的期望专门高、开发时刻短同时资源有限时，你必须尽早确定出所交付的产品应具备的最重要的功能。
建立每个功能的相对重要性有助于你规划软件的构造，以最少的费用提供产品的最大功能。
因为在这些开发中，交付进度安排专门紧迫同时不可改变日期，你需要排除或推迟一些不重要的功能。
第15章需求的质量验证
大多数软件开发者都经历过开发时期后期或在交付产品之后才发觉需求的问题。
当以原先需求为基础的工作完成以后，要修补需求错误就需要作大量的工作。
需求验证是需求开发的第四部分〔其余三个为猎取、分析和编写规格说明〕。
需求验证所包括的活动是为了确定以下几方面的内容：
◆软件需求规格说明正确描述了预期的系统行为和特点。
◆从系统需求或其它来源中得到软件需求。
◆需求是完全的和高质量的。
◆所有对需求的看法是一致的。
◆需求为连续进行产品设计、构造和测试提供了足够的基础。
更好的需求将会带来更好的产品质量和客户更大的中意程度，这能够降低产品生存期中的爱护、增强和客户支持的费用。
在需求质量上的投资能够使你节约更多的钱。
附件
用户需求规格说明书
1．引言
1．1背景
[给出需求的提出者、用户、开发单位、主管单位，说明待开发产品的名称、起源、产生背景以及和其它产品之间的联系。
]
1．2比较分析
[阐述待开发产品与同类产品或产品的历史版本之间的比较分析。
]
1．3任务概述和开发目标
[简单描述需求摘要，说明待开发产品所要做的工作和产品的开发目标、应用目标和效益目标。
]
2．功能
［从用户的角度动身，基于服务的目标，对满足用户需求的产品功能做一个简要、清晰、合理的、可行的描述和定义。
］
3．性能和限制
［说明满足用户需求的待开发产品的相关重要性能和使用限制（如时刻特性，数据精度，处理能力等）。
］
4．接口
4．1用户界面
［描述用户对待开发产品使用的用户界面的需求，如操纵板样式、输入输出设备，开关，指示灯，软件界面等。
］
4．2与其他系统、产品的接口联系和要求
［描述待开发产品与其他系统和产品相关的接口联系和功能要求。
］
5．用户群及其特点
［说明使用待开发产品的可能的最终用户，并描述他们的相关特性〔如教育水平、工作体会、技术熟练程度等。
〕］
6．工作环境
［描述待开发产品工作环境的限制〔如硬件、软件、网络、物理、气候、社会环境等〕。
］
7．规格、质量
［描述与客户或开发人员有重要关系的待开发产品的质量特性，这些特性应为确定、定量，并可验证的。
同时说明产品在安全性、可靠性、健壮性、可爱护性、可移植性等方面的要求。
］
8．设计约束及限制
［描述开发产品时对各种行业标准、规范、国家规定、法规、开发平台、开发技术、使用设备、元器件、编程工具、操作系统、数据库等方面的限制。
］
9．安装、使用和爱护
［说明用户对待开发产品在安装、使用和爱护方面的专门要求，如操作方式，系统复原方式等。
］
10．以后可能需求
［说明以后或下一版本中，对待开发产品所要满足的可能需求。
］
11．其他需求
［上面未说明的其他需求。
］
12．产品交付日程
13．附录
13．1定义，术语和缩写词
［缩写词和名词、术语定义。
］
13．2参考资料
［编写本规格书所参考的各种资料，如需求报告、用户合同、相关研发治理规范、背景资料、其它标准。
］
升级会员 