一个大型软件系统的需求通常是会发生变化的。在进行需求变更时，可以参考以下需求变更策略：
①所有需求变更必须遵循变更控制过程。
②对于未获得批准的变更，不应该做设计和实现工作。
③变更应该由项目变更控制委员会决定实现哪些变更。
④项目风险承担者应该能够了解变更数据库的内容。
⑤决不能从数据库中删除或者修改变更请求的原始文档。
⑥每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

极限编程是一种重要的敏捷开发方法，包含规划、设计、编码和测试4个框架活动的规则和实践。极限编程中使用的重要技术是重构，既包括设计技术的重构，也包括构建技术的重构；极限编程提倡在基本设计完成后，团队不应该直接开始编码，而是开发一系列用于检测本次发布的包括所有故事（story）的单元测试；极限编程活动中的关键概念之一是"结对编程"，推荐两个人面对同一台计算机共同开发代码；极限编程过程中建立的单元测试应当使用一个可以自动实施的框架，支持代码修改后即时的回归测试策略。

需求分析使得系统工程师能够刻画出软件的功能需求（明确所开发的软件必须具备什么样的功能）、性能需求（明确待开发的软件的技术性能指标）、环境需求（明确软件运行时所需要的软、硬件的要求）、用户界面需求（明确人机交互方式、输入输出数据格式）。需求分析要指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是发现、求精、建模和规约的过程。包括详细地精化由系统工程师建立并在软件项目计划中精化的软件范围，创建所需数据、信息和控制流以及操作行为的模型。

复杂系统的复杂之处主要在于其各子系统之间关联的复杂性。例如，人体本身就是一个复杂系统。虽然骨骼系统、神经系统、消化系统和血液循环系统等都有清晰的结构，可以清晰地描述其性能，但各子系统之间相互关联的机制却仍难以把握。

敏捷软件过程主要有四大价值观：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。这种价值观的前提是软件需求是难以提前确定的，而是会不断地发生变化，可以采用可执行原型和部分实现的可运行系统来了解用户需求，通过用户的反馈来明确需求。从制订计划的角度来看，分析、设计、实现和测试并不容易预测。

逆向工程导出的信息可分为如下4个抽象层次：
①实现级：包括程序的抽象语法树、符号表等信息。
②结构级：包括反映程序分量之间相互依赖关系的信息，如调用图、结构图等。
③功能级：包括反映程序段功能及程序段之间关系的信息。
④领域级：包括反映程序分量或程序与应用领域概念之间对应关系的信息。

用户文档主要描述所交付系统的功能和使用方法，并不关心这些功能是怎样实现的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。用户文档一般包括以下内容：
①功能描述：说明系统能做什么。
②安装文档：说明怎样安装这个系统及怎样使系统适应特定的硬件配置。
③使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的）。
④参考手册：详尽描述用户可以使用的所有系统设施，以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）。
⑤操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况。试题中只有安装文档属于用户文档。其他的：需求说明书、系统设计文档、系统测试计划均属于开发文档。

用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。它确定了一个和系统参与者进行交互，并可由系统执行的动作序列。用例模型描述的是外部执行者（Actor）所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。
两个用例之间的关系主要有两种情况：一种是用于重用的包含关系，用构造型Include表示；另一种是用于分离出不同行为的扩展，用构造型Extend表示。
①包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示它们。
②扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，可以断定将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。

面向功能的软件度量是对软件和软件开发过程的间接度量，注意力集中于程序的功能性和实用性，而不是对LOC计数。该度量是由Albrecht首先提出来的。他提出了一种叫做功能点方法的生产率度量法，该方法利用有关软件数据域的一些计数度量和软件复杂性估计的经验关系式，导出功能点FPs(Function Points)。 　　
功能点通过填写图表格来计算。首先要确定5个数据域的特征，并在表格中相应位置给出计数。数据域的值以如下方式定义： 　　
①用户输入数：每个用户输入应是面向不同应用的输入数据，对它们都要进行计数。输入数据应区别于查询数据，它们应分别计数。 　　
②用户输出数：各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。在这里的"输出"是指报告、屏幕信息、错误信息等，在报告中的各个数据项不应再分别计数。 　　
③用户查询数：查询是一种联机输入，它引发软件以联机方式产生某种即时响应。每一个不同的查询都要计数。 　　
④文件数：每一个逻辑主文件都应计数。这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一部分，也可以是一个单独的文件。 　　
⑤外部接口数：对所有使用来将信息传送到另一个系统中的接口(即磁带、磁盘和可读写光盘上的数据文件)均应计数。 　　
一旦收集到上述数据，就可以计算出与每一个计数相关的加权复杂性值。

UML采用4+1视图来描述软件和软件开发过程。
①逻辑视图：以问题域的语汇组成的类和对象集合。
②进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。
③实现视图：对组成基于系统的物理代码的文件和组件进行建模。
④部署视图：把构件部署到一个组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。
⑤用例视图：最基本的需求分析模型。