HZCU 软件需求分析

服啦，这门课！根本！不用复习！

考试内容

20道选择40分。基本书上都能找到原话，就1道是UML的，其他基本都是软件需求书里的。

10道判断20分。判断全靠自己判断了。

8道简答40分，一直写啊写，狂写。基本书上一模一样不需要准备，只要翻到然后拼命抄。

简答题：

愿景与范围是什么，范围变更的影响

需求获取怎么确认完成

怎么识别用例

外部质量因素哪些，什么作用

优先级排序方法，大概概述

需求跟踪矩阵是什么，什么作用

使用需求管理工具的好处

还有一道忘记了…

题型

选择30道 简答5道 综合3题

好像又是选择判断简答了，服啦，最后是选择判断简答。

这个更抽象，啥都不知道。听说简答都是书本的，希望吧。

PPT复习

课程介绍

主要包括需求开发和需求管理两个部分。需求开发包括需求获取、需求分析、规格定义和需求验证四个方面。需求管理包括需求评审、需求变更控制和需求跟踪等内容。

需求工程项目计划

软件需求规格说明书SRS

需求变更管理

需求工程项目收尾

第一讲 绪论

需求工程发展过程：跟随软件开发生命周期理论而逐步演化、完善；从需求分析阶段演变而来；80年代逐步形成子领域–需求工程；90年代成为研究重点；1993年开始两年1次ISRE需求工程国际研讨会议；1994年开始两年1次ICRE需求工程国际会议；其后逐步成立了各种需求工程工作小组，在深度、广度上飞速发展。

需求工程的重要性：需求是根本（软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求。需求是评判项目成功与否的标准。）；需求的影响（逐步放大）；不合格需求的主要原因(用户参与不够,用户需求不断增加,需求说明模糊,不必要的特性,规格说明太粗,不对用户进行分类,计划不准确);需求是变化的(需求需要跟踪、更新；需求需要管理、控制；管理的标准需求基准Baseline审核后的软件需求规格说明文件SRS)

需求的定义：IEEE用户解决问题或达到目标所需的条件或能力；为满足合同、标准、规范或其他正式规定文件的要求，系统或系统部件所应具备的条件或能力；描述（1）、（2）中条件或能力的说明文件。Rational正在构件的系统必须符合的条件或必须具备的功能。

需求工程：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

需求的目的：需求是说明要开发什么！

需求工程的目的：做出高质量而并非完美的需求分析，在一个可接受的风险限度上实施需求分析；避免项目失败；提高客户满意度。

需求的层次特征：三个层次。业务需求（反映组织机构或客户对系统、产品的高层次的目标要求。项目视图（项目章程）、范围文件）用户需求（描述用户使用产品必须完成的任务。用例描述）功能需求（定义开发人员必须实现的软件功能。软件需求规格说明SRS）

需求的质量特性：需求说明的特征（完整性，正确性，可行性，必要性，区分优先级，无无二义性，可验证性）规格说明的要求（完整性，一致性，可修改性，可跟踪性）

需求开发过程：需求获取，需求分析，需求规格说明，需求规格审核

需求管理过程：变更评估，变更控制，变更跟踪

需求工程方法：四个面向。面向过程（主要研究系统输入/输出的转化方式，不关心数据及其控制。SA,SADT,可执行/可操作模型,VDM,Z）面向数据（以数据结构的方式描述和分析系统状态，ERM）面向控制（强调控制过程的同步、死锁、并发，描述进程的激活与挂起过程，数据流程图）面向对象（UML–Unified Modeling Language；用例驱动建模–Use case Driven；统一化的需求管理–RUP）

软件生命周期：瀑布模型、螺旋模型、迭代模型、快速原型

相关标准：SEI CMM,ISO 9000,IEEE,GB

CMM:Initial,repeatable,defined,managed,optimizing

PMBOK–项目管理知识体系:5个项目管理过程：1.Initiation --启动2.Planning –计划3.Execution–执行4.Control --控制5.Closing --收尾9大项目管理领域：1.Integration Management –综合管理2.Scope Management –范围管理3.Time Management –时间管理4.Cost Management –成本管理5.Quality Management –质量管理6.Human Resource Management –人力资源管理7.Communication Management –沟通管理8.Risk Management –风险管理9.Procurement Management –采购管理

PMBOK与需求工程的关系：需求工程是软件开发生命周期中的重要一环；应以整体软件工程开发管理角度来规划需求工程；需求工程的开展应该以项目方式进行；具有5个项目管理过程需要应用9大项目管理领域知识；尤其在：风险的识别与分析–风险管理，变更的控制与管理–范围管理。

IPMA国际项目管理协会IPMP国际项目管理专业资质认证

第六讲 软件需求获取

需求获取的指导方针：客户与开发者的广泛合作与有效交流结果，必须取得对客户需求的普遍理解，采取一切有效措施，达到上述目标。

需求获取的方法与技术：确定需求开发过程，编写项目视图和范围文档，用户群分类，选择产品代表，建立核心队伍，确定使用实例，召开应用程序开发联系会议（JAD），分析用户工作流程，确定质量属性，检查问题报告，需求重用

确定需求开发过程：采用项目管理的思想（启动计划执行控制结尾）。需求过程贯穿整个项目过程。制定需求工程计划（时间、资源、成本，工作分解结构WBS，活动排序，进度计划）。建议的需求工程过程（开发过程，管理过程）。

编写项目视图和范围文档：项目视图（描述了产品所涉及的各个方面，在理想情况下所具有的功能）范围（描述产品应包括和不应包括的部分，明确项目的局限性）

关联图（上下文图）context diagram。结构化分析所形成的数据流图的最高抽象层。描述待开发系统与外部世界的关系。确定通过某一接口与系统相连的外部实体。确定外部实体与系统间的数据流和物流。是一种关联分析说明图，通过关联图可以找出因素之间的因果关系，便于统观全局、分析以及拟定解决问题的措施和计划。确定系统的边界和范围。

用户群分类：需求的来源（访问并与有潜力的用户探讨，把对目前的或竞争产品的描述写成文档，系统需求规格说明，对当前系统的问题报告和增强要求，市场调查和用户问卷调查，观察正在工作的用户，用户任务的内容分析）用户分类（客户，直接用户，间接用户，其他形式的用户）用户代表（不同用户类需求的代言人，参与整个软件开发生命周期，尽快确定用户类和相应的代表，全面反映系统的真实需求，兼顾用户类的不同专业层次需求）设定不同的用户级别（关键用户：这类用户对产品的后续成功至关重要，必须给予这类用户提出的需求高优先级。次要用户：他们使用该产品，但他们意见对产品的长期成功并无影响。不重要用户：这类用户的优先级最低，包括不常用、未授权和无相应技能的用户，以及误用产品的用户。）

选择产品代表：什么是产品代表（项目开发组的成员；来自相关用户团体，提供客户的需求；客户-开发者关系的结构化与形式化）谁来做产品代表（每个产品代表都代表一个特定的用户类；充当那类用户与开发者的主要接口；必须是真正的用户）产品代表做什么

建立核心队伍：相对固定。全面反映用户的需求（功能需求，非功能需求）。注意人员的来源（有代表性；考虑典型用户；行业专家、职业经理、职业技师；同类产品的长期使用者）。参与整个开发过程，并起作用。

确定使用实例：什么是实例（1986年，Ivar Jacoboson提出（发明）描述系统和外部“执行者”（Actor）的交互顺序。执行者可以是：人、软/硬件、其他实体，可以映射为：一个或多个客操作的用户类）使用实例的目的（描述用户需要使用系统完成的所有任务。理论上，包括所有合理的系统功能）使用实例的好处（以任务为中心：明确给定了用户执行的各项任务；以用户为中心；有助于分析者和开发者理解用户的业务和应用领域；有助于从实例中生成测试用例；便于后续分析、设计、实现过程；便于跟踪、管理）

使用实例概念：一个使用实例是相关情景说明（Scenario）的集合。一个情景说明是使用实例的例子。情景说明是事件的普通过程（Normal Course）。情景说明中的普通过程描述了系统与执行者之间交互的顺序。使用实例中其他说明可以描述成可选过程（Alternative Course）。引起任务不能顺利完成的情况称为例外（Exception）。

使用实例的使用方法：明确执行者和他们的角色，确定业务过程；确定系统所能反映的外部事件，将事件与参与的执行者及特定的使用实例联系起来；以特定说明形式说明业务过程，从中获得使用实例，并确定其中的执行者；从现有的功能需求说明中获得使用实例。

用例与关联图的关系：关联图或DFD是描述业务需求中业务处理过程及相关数据流的重要工具。用例描述了业务需求中业务处理过程的输入input、转换transformation和输出output。通过抽象的情景说明以及上述技术工具的使用，能够对业务过程进行建模，客观地反映业务需求。

召开应用程序开发联系会议（JAD）：目的（广泛交流，全面沟通，发掘、确认需求；达成对需求的一致理解）参加人员（用户代表，项目小组，分析、开发人员）技术工具（头脑风暴，访谈，检查表）检查表（通常是一列问题清单，覆盖问题域的关键部分，帮助发现错误、遗漏和不足，是一种非常有用的评审技术，面向不同的问题，准备不同的模板。）

分析用户工作流程：技术（观察、学习）业务流程分析（关联图/DFD，情景说明）目标（明确用户的业务目标，进一步明确用例与功能需求，逐步细化需求）

确定质量属性：非功能需求。什么是质量属性（什么是质量属性）。有哪些质量属性（从用户的角度，有效性高效性灵活性完整性互操作性可靠性强壮性可用性。从开发者的角度，可维护性可移植性可重用性可测试性）。用户属性的优先级（属性需求产生矛盾时，便于对需求属性的取舍）。

检查问题报告：目的（进一步完善需求）。当前系统的问题报告。补充需求。来源（技术支持人员，客户服务人员）。

需求重用：尽量使项目需求的定义具有相对的独立性、可重用性；总结、积累每个项目的需求资料；发现那些与以往项目需求相似或相同的需求；审核、重用这些需求资料，提高项目效率。

客户输入的分类：业务需求（从系统或产品中得到的资金、市场或其他业务利润的需求）使用场景或情景说明（客户描述的业务工作流活动）业务规则（业务过程操作原则）功能需求（系统所展示的可观察到的行为，如：客户要求“系统必须能够<执行某些功能>”）质量属性（描述系统如何更好地执行某些功能的要求）外部接口需求（系统与外部的联系方式，如：“从<某个设备>读取数据”，“以<某种格式>存取文件”等等）系统限制（各种合理的限制条件。如：“内存最多<多少>”，”只能使用<某种语言>”等等）数据定义（对数据项或数据结构的取值约定。如：“代码的编码规则，缺省的代码值”等等）解决思想（用户与系统交互的特定方法，以使系统产生一系列活动，注意，此时客户正暗示系统的某种特定实现方式，应加以识别和区分）

需求获取的注意事项：需求主要是关于系统做什么，而不是怎么做；需求获取的方法，如：关联图、使用实例等，是为了提高与用户交流的效率，而不是为了给设计者设限；慎重选择用户代表（产品代表），既全面反映各类用户需求，又能提高交流效率

从项目管理角度看需求获取：始终以项目的观点看待需求工程；需求工程过程是项目管理生命周期阶段内的一个子过程；项目范围的管理依赖于项目视图和范围文档（范围蔓延控制、范围变更权衡、范围变更控制）

需求获取的完成标志：用户不能提出更多的使用实例；用户提出的使用实例是其他相关实例的可选过程；开始重复讨论以前的问题；新需求的优先级总是低于已有的需求；开始讨论对未来产品的要求；不再出现新的功能特性

第七讲 软件需求分析

需求分析的目的：提炼、分析、审查已收集的需求；确保所有相关人员理解一致；找出错误、遗漏与不足；使所有的需求与规格说明达到优秀的质量要求

需求分析的主要方法：绘制关联图（定义系统与系统外部实体间的界限和接口），创建开发原型（使双方对问题的理解更加清晰，使双方对问题的理解更加清晰），分析可行性（成本、性能的前提要求，各项需求的实现风险，需求间的冲突，外界依赖条件，技术障碍），确定需求优先级（以最小的费用，获得最大的功能；确定产品版本的具体功能；便于需求变更管理），为需求建立模型（描述问题域的逻辑特征：数据组成、事务和转换、对象和状态等等；帮助检测需求中的不一致性、模糊性、错误和遗漏；便于分析者和客户在需求上形成一致的、综合的理解，提高沟通效率；除了文本描述，还需要图形分析模型方法：数据流图DFD实体关系图ERD状态转换图STD对话框图对象类图交互作用图），编写数据字典（对系统用到的所有数据项和结构的定义 。确保理解和使用的一致 ：需求阶段：定义所有客户数据项 ；确保一致的术语和定义 。数据字典的维护独立于SRS，将贯串于整个项目过程。 表示方法： ✓ 巴克斯-诺尔形式(BNF – Backus-Naur Form) ✓ 正则表达式(Regular Expressions) ✓ 名称不同，其实都是数据表达式），应用质量功能调配QFD（将产品特性、属性与客户的重要性联系起来 ；明确那些客户最为关注的特性 ； 从客户的角度，需求分为三大类： ✓ 期望需求：如果缺少，会不满意！ ✓ 普通需求： ✓ 兴奋需求：如不提供，也不会受到责怪）

确定需求优先级：技术方法（一般方法：分为三类：高、中、低；质量功能开发 – QFD；全面质量管理 - TQM）主要参与者（项目经理；重要客户代表，开发者代表）

数据流图(DFD - Data Flow Diagram)：结构化系统分析的基本工具；一个数据流图定义了系统转化过程、系统所操纵 的数据或物质的收集（存储），以及它们之间的 数据流或物质流；是对当前业务过程或新系统操作步骤的一种表示 方法；加入控制元素后，可用于实时系统建模；适用于： • 事务处理系统 • 功能密集型应用

实体关系图(ERD – Entity-Relationship Diagram)：描绘系统中的数据关系 ；实体：是物理数据项或者数据项的集合，用单数名词 命名并在矩形方框中表示；关系：实体对之间逻辑上和数量上的联系，用菱形框 代表，以关联的属性来命名；实体和关系的连线上用数字或字母表示实体的单联系 和多联系；一对一、一对多、多对多 ；用于组织业务数据元素，提供系统的数据组织关系及 其相互间的联系。

状态转换图(STD – State Transition Diagram) ：是有限状态机的一种简洁、完整、无二义性的表示；三种元素： （1）矩形：表示可能的系统状态 （2）箭头：用以连接一对矩形框，表示允许的状态改变或转换 （3）箭头上的文本：表明引起状态转换的条件 ；不表示系统所执行的处理，只表示处理结果可能的状 态转换 ；有助于开发者理解系统的预期行为； 有助于检查功能需求的完整性 ；有助于获取测试用例

对话框图(DM - Dialog Map) ：状态转换图的一种特定形式 ；代表高层抽象的用户界面体系结构 ；描绘系统中的对话元素和它们之间的导航连接，不涉及具体的屏 幕设计 ；与系统的情节叙述密切关联 ；对话元素作为一个状态，用矩形表示 ；导航选择作为转换，用箭头表示 ；触发条件以文本方式标在箭头上，触发条件可以是：（1）一个用户动作 （2）一个数据值 （3）一个系统条件 （4）上述情况的组合

对象类图(CD – Class Diagram) ： 用图形方式描述面向对象分析所确定的类以及它们之 间的关系 （1）类名 （2）类的属性 （3）类的操作 （4）类之间的联系

交互作用图 ： 描述重要的互相作用，显示参与的对象和对象之间按时间排序的消息；

顺序图(Sequence Diagram)： • 显示按时间顺序排列的对象交互作用的图，特别是用于显示交互作用中的对象 和交换的消息序列。 • 与协同图不同的是，时序图包括时间序列，但不包括对象关系。 • 时序图可以以类属形式（描述所有可能的场景）和实例形式（描述一个实际场 景）存在。 • 时序图和协同图表示的信息相似，但显示的方式不同

联系图/协作图(Collaboration Diagram)： • 描述对象交互作用的图，包括对象及其相互之间的链接关系。与时序图不同， 协同图表示对象之间的关系。描述对象之间所交换的信息。

活动图(Activity Diagram)： • 状态图的特例，其中全部或大部分状态是动作状态，而且其中全部或大部分的 状态迁移由源状态中动作的完成来触发。

第八讲 软件需求规范与定义

需求规格说明的目的：需求的文档化、可视化、统一化； 关于系统功能与非功能需求的详细说明 ➢ 业务需求 – 项目视图和范围文档 ➢ 用户需求 – 使用实例文档 ➢ 功能需求和非功能需求 – 软件需求规格说明 ；取得用户的理解与认可；评审通过，成为基准，开始设计工作

需求规格说明的主要方法：采用软件需求规格说明模板；指明需求的来源； 为每项需求注上标号 ；记录业务规范；创建需求跟踪能力矩阵

采用软件需求规格说明模板：目的（ ✓ 精确地阐述一个软件系统必须提供的功能和性 能以及它所要考虑的限制条件。 ✓ 不仅是系统测试和用户文档的基础，也是所有 子系统项目规划、设计和编码的基础。 ✓ 提供统一的文档结构，便于编写与管理）编写方法（✓ 结构化的自然语言 – Use case 描述 ✓ 图形化建模 ✓ 形式化规格说明 – Z、SDL（ITU-T））

指明需求的来源：目的（✓ 便于需求理解 ✓ 便于达成一致 ✓ 便于跟踪回溯 ✓ 便于变更管理）方式（ 在每项需求与其他的系统元素之间建立关 联关系 – 联系链）

记录业务规范 ➢ 是关于产品的操作原则 ➢ 成为独立的SRS部分 / 独立文档 ➢ 由相应的功能需求实现，建立对应关

创建需求跟踪能力矩阵Rational RequisitePro：作用（✓ 需求变更影响分析 ✓ 设计变更影响分析 ✓ 测试计划/用例设计或回归测试 ✓ 程序修改影响范围判断）组织方式（✓ 矩阵结构 ✓ 将每项需求与实现、测试它的设计和代码部分联系起来 ✓ 将不同层次的需求相互联系起来 ✓ 类似数据库的表结构 ✓ 每个功能性需求向后连接一个特定的使用实例，向前连接一个或 多个设计、代码和测试元素。 ✓ 设计元素可以是模型中的对象，如数据流图、关系数据模型中的 表单、对象类等。 ✓ 代码可以是类中的方法，源代码文件名、过程或函数。 ✓ 可以延伸到整个项目的相关中间结果。）多维矩阵结构（定义需求间/需求与其他元素间可能的各种不同的联系）

第九讲 软件需求验证与审核

需求验证的目的：保证需求说明准确、完整地表达必要的质 量特点 ；客户的参与占重要位置 ； 具体要求： ➢ 确保SRS正确描述了预期的系统行为和特征 ➢ 确保从系统需求或其它来源中获得软件需求 ➢ 确保需求是完整的和高质量的 ➢ 确保对需求的理解是一致的 ➢ 为继续进行产品设计、构造和测试打下必要 的基础

需求验证与审核的主要方法：审查需求文档（保证质量 ；形成基准、进入下一阶段 ；组织形式： ✓ 专门的评审会议 ✓ 正式的 / 非正式的； 参与人员： ✓ 各类用户代表、分析人员、设计人员、测试人员 等 类似JAD ✓ 角色分工：作者、调解者、读者、记录员等 ✓ 限制在7人以内！）；以需求为依据编写测试用例（）；编写用户手册（）；确定合格标准（）

审查需求文档：评审标准（需求评审检查表，使用实例文档审查清单）进入审查的标准（✓ 文档符合标准模板 ✓ 文档已经做过评写检查和语法检查 ✓ 已经检查了版面安排方面的错误 ✓ 已经获得了必要的相关资料，如：SyRS ✓ 文档已经按行编号，以便于定位查找 ✓ 文档中所有未解决的问题已经都标为TBD ✓ 已经准备好文档相关的术语词汇表 ✓ 其他）退出审查的标准（ ✓ 已经明确阐述了审查员提出的所有问题 ✓ 已经按要求正确修改了文档 ✓ 修订过的文档已经检查了拼写和语法错误 ✓ 所有TBD问题已经解决、或者已经记录下每个待 确定问题的解决过程、目标期限和提出问题的人 ✓ 文档已经登记进入项目的配置管理系统 ✓ 相关评审资料已经送到有关的收集处）

以需求为依据编写测试用例：黑盒测试方法；帮助客户进行需求确认；与功能需求相互对应，覆盖全部需求 ；验证测试结果与预期的一致性；验证需求模型的准确性

编写用户手册：需求开发早期形成初始版本；可以辅助需求分析 ；要求： ✓ 覆盖全部用户可见功能 ✓ 语言浅显易懂 ✓ 其他需求，如：质量属性、性能需求及用户不 可见功能在SRS中描述。GB 8567-88

确定合格标准： 由用户确定；描述合格系统/产品的各项要求；进行合格的测试

第十二讲 软件需求管理

需求管理的目的：控制对需求基准的变动；保持项目计划与需求一致；控制单个需求和需求文档的版本情况 ；管理需求和联系链之间的联系（管理单个 需求与其他项目可交付产品之间的依赖关 系）；跟踪基线中需求的状态。

主要方法和步骤：①确定需求变更控制过程（1.需要修改基线时，填写《变更申请表》，提交CCB。 ✓ 2. CCB召开需求变更申请评审会，评审该申请。 ✓ 3. 若CCB否决申请，项目负责人将《变更申请表》存档。 ✓ 4. 若CCB通过申请，项目负责人根据需求跟踪矩阵，列出 所有相关文档。 ✓ 5. 项目负责人指定此变更的实现者和验证者，实现、验证 相应的变更。 ✓ 6. 项目负责人更新相关需求，并通知相关部门和人员，需 求发生变更。）②建立变更控制委员会CCB（对任何基线产品的变更作出决定。 ➢ 根据项目的大小，可以分级、分专业控制， 也可以只有1-2个人 ➢ 目的：提高工作效率、作出正确判断与决策 ➢ 工作总则： ✓ 目的、授权范围、成员、决策过程及操作 步骤等等开展工作的细节）③进行需求变更影响分析（提供对建议的变更的准确理解 ➢ 辅助变更批准决策 ➢ 确定具体的变更后操作，评估相应的工作量 ➢ 依赖于跟踪能力数据的质量和完整性 ➢ 保证变更只能在项目时间、预算、资源的限 制内进行协商）④进行需求变更影响分析（变更涉及问题核对表，变更影响的软件元素核对表，影响分析报告）⑤跟踪所有受需求变更影响的工作产品（ 跟踪能力 – 跟踪一个需求使用期限的全过程 ，从需求源到实现的前后生存期 ➢ 表明每个需求的需求跟踪能力链 ➢ 通过需求跟踪能力矩阵实现 ➢ 采用需求能力跟踪工具 – 相关的需求管理软 件，如Rational RequisitePro等）⑥建立需求基准版本和需求控制版本文档（需求版本控制是需求管理的一个必要方面 ➢ 必须保证需求文档的每个版本被统一确定 ➢ 基准版本 – 被评审采纳的正式发布版本 ➢ 区分草稿、定稿，形成控制版本文档 ➢ 借助工具进行管理 ✓ 需求管理工具，如Rational RequisitePro ✓ 配置管理工具，如VSS、CVS）⑦维护需求变更的历史记录（记录需求变更文档的各种信息 ✓ 版本号、版本发布日期 ✓ 变更内容、原因 ✓ 负责人、更新日期、新的版本号 ➢ 借助需求管理工具自动实现！）⑧跟踪每项需求的状态（建立历史信息库 ➢ 保存每一项功能需求及其重要属性，包括相 应的状态。）⑨衡量需求稳定性（记录基准需求的数量 ➢ 记录每周/每月的变更数量（增、删、改） ➢ 是否发身频繁变更现象？分析原因）⑩使用需求管理工具（➢ 管理版本和变更 ➢ 存储需求属性 ➢ 帮助影响分析 ➢ 跟踪需求状态 ➢ 实现访问控制 ➢ 协助与风险承担者进行沟通 ➢ 利于需求重用）

采用文档方法的限制： ✓ 很难保持文档与现实的一致 ✓ 需要手工通知受变更影响的相关人员 ✓ 难于保存每个需求的增补信息 ✓ 难于在需求与其相应的实例、设计、代码 、测试和项目任务间建立关系链 ✓ 难于跟踪每个需求的状态

➢ Rational RequisitePro 以文档为核心，同时 提供在数据库中存储需求的能力，可以定义 属性和能力跟踪关系链。 ➢ Rational RequisitePro 可以 ✓ 建立需求与Rational Rose的使用实例的 关系 ✓ 建立需求与Rotional TeamTest的测试实 例的联系

作业

预备作业

*（1）什么是需求？什么是软件需求？*

什么是需求：

字典对“需求”的解释为：“被命令或者强制性的东西：需要或者必要。”

需求在广义上指的是某种必要的东西，是为了达成特定目标所必需的。这个概念可以应用于各种领域，包括但不限于商业、工程和软件开发。需求通常描述了需要达到的条件或者必须拥有的特性。

什么是软件需求：

Ian Sommerville and Peter Sawyer（1997）所提出的观点，需求是对我们应当执行的任务的规范说明，它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。

软件需求有三种不同的层次：业务需求、用户需求和功能需求。

软件需求则是指在软件开发领域中，对软件产品功能、性能、设计和开发标准的具体要求。

*（2）举例说明你是以什么方式和步骤去完成某个特定活动的。*

例如在上学期的软件工程课中，目标是开发一个校园跑腿小程序。这是一个典型的软件工程项目，它遵循软件开发的标准流程，包括初步分析、设计、实现、测试和部署等阶段。我们开发的方式和步骤是这样的：首先，我们进行了项目的可行性分析，评估了项目的技术可行性、经济可行性和法律可行性。这一步骤包括编写了第一版报告并根据收到的反馈进行了修订。同时我们制定了详细的项目开发计划，包括甘特图，明确了项目的时间线、里程碑和责任分配。接下来，我们进行了需求分析，详细定义了软件需要满足的业务需求、用户需求和功能需求。这个过程同样包括了一份初版报告及其修订版本，以确保所有需求都被准确理解和记录。基于需求分析，我们设计了系统的原型，这帮助我们和用户进行了初步的交流和理解，确保设计方向符合用户期望。然后我们完成了概要设计，确定了系统的总体架构和组件之间的交互方式，并编写了对应的说明书。概要设计的基础上，我们进一步细化，完成了详细设计说明书的第一版和修订版，详细说明了系统的每一个模块和组件。根据需求和系统设计，我们进行了数据库的设计，确保数据的组织方式能有效支持系统功能。根据需求和系统设计，我们进行了数据库的设计，确保数据的组织方式能有效支持系统功能。为了确保软件的质量，我们编写了测试用例，并进行了系统测试，包括单元测试、集成测试和用户接受测试。最后我们准备了系统演示说明，为演示软件的功能和特性做准备。整理了项目的完整文档，以确保项目的每个阶段都有详细的记录。我们还编写了系统的安装和部署说明，确保用户能够正确安装和部署这个小程序。

WBS

读后感

没有银子弹

首先，“没有银子弹”这个概念强调了一个关键事实：没有简单的方法或工具可以显著提高软件开发的生产力或质量。布鲁克斯将软件开发的复杂性分为本质的和偶发的两类。本质复杂性源自软件开发的复杂和抽象本质，而偶发复杂性则来自于软件开发过程中所使用的工具和方法的不完善。在软件需求分析课程中，我们学习了识别和理解用户需求的方法，这些方法旨在减少项目失败的风险，而这恰恰是布鲁克斯论文中提到的软件开发中不可避免的本质复杂性的一部分。

软件需求分析的核心是理解用户的需求，这包括对需求的搜集、分析、规范和验证。这个过程需要与用户进行深入的沟通和协作，确保开发团队可以准确地捕捉到用户的需求，并将这些需求转化为软件解决方案。这个过程的挑战在于需求往往是多变和模糊的，用户自己可能也不能完全明确他们所需要的。因此，需求分析阶段是应对软件开发本质复杂性的关键环节，这一点与布鲁克斯的观点不谋而合。

在处理软件开发的复杂性时，布鲁克斯建议采用原型化、增量开发等方法。这些方法有助于在开发过程中逐步揭示和精化需求，允许团队对项目的不确定性和复杂性有更好的控制。在软件需求分析课程中，我们同样学习了如何通过使用原型和迭代方法来提高需求的明确性和准确性。通过这样的实践，我们可以更有效地管理用户的期望，减少开发过程中的变更和返工，从而提高项目的成功率。

布鲁克斯还强调了良好的项目管理和沟通在软件开发成功中的重要性。这一点在需求分析中尤为重要，因为需求分析阶段是项目各方利益相关者交流和协商的关键时期。有效的沟通不仅有助于准确捕捉需求，还有助于建立团队成员之间的信任和理解，这对于项目的顺利进行至关重要。

六西格玛和第五项修炼

《六西格玛管理》是一种旨在通过消除缺陷和减少变异性来提高产品和服务质量的管理策略。六西格玛（6 Sigma）的核心是DMAIC（定义、测量、分析、改进、控制）和DFSS（设计六西格玛）两大方法论，它们是用于流程设计和改进的一套科学工具和管理方法。六西格玛管理法强调数据的重要性，依据数据进行决策，通过量化的方法来识别和消除流程中的缺陷，从而提高效率和顾客满意度，降低成本。

《第五项修炼》则是彼得·圣吉（Peter M. Senge）的经典管理学著作，提出了构建学习型组织的五项修炼理念和方法。这五项修炼包括：系统思考、共同愿景、个人精通、心智模式和团队学习。圣吉在书中强调，学习型组织是一个能够持续适应和创新的组织，通过培养成员的学习能力和共同愿景，以及促进个人和团队的成长，可以实现组织的长期发展和成功。《第五项修炼》中的核心理念是系统思考，即看待问题和决策时要考虑整个系统的行为和相互作用，而不仅仅是局部或短期效应。圣吉认为，通过这种思考方式，组织可以更好地理解和应对复杂多变的商业环境。

这两本书都为企业和组织提供了宝贵的管理理念和实践方法，帮助它们在竞争激烈的市场中脱颖而出。《六西格玛管理》侧重于质量和流程改进，而《第五项修炼》则侧重于组织学习和发展，两者相辅相成，共同推动组织的持续进步和创新。

蓝海战略

找到的书是《蓝海战略》（Blue Ocean Strategy），是由W. Chan Kim和Renée Mauborgne两位学者提出的一种商业战略理念。该理念首次在2004年发表于《哈佛商业评论》上，后来在2005年出版成书，迅速成为全球商业领域内广受关注的战略管理理论。

核心思想是鼓励企业不要在竞争激烈的“红海”市场中争斗，而应该通过创新来开拓尚未被开发的市场空间，即“蓝海”市场。在“蓝海”中，由于竞争者较少或者没有，企业可以享受到较高的利润空间和增长潜力。

《蓝海战略》提出了一系列工具和框架，帮助企业识别并开拓新的市场空间。这包括了“战略布局图”（Strategic Move Canvas）和“价值曲线”（Value Curve）等工具，用以分析现有市场的竞争格局和企业自身的战略定位。

该战略强调的是创新和价值创造，鼓励企业通过重新定义游戏规则来获得市场领导地位，而不是通过与竞争对手的直接对抗。《蓝海战略》的理念对于企业家、管理者和战略规划者都有着重要的启发和指导意义。

TSP

经过查找，找到的书是《TSP—Leading a Development Team》（中文译为《TSP：领导开发团队》）。按照中文译名搜的时候找不到资源，还是得按原名搜。这本书也是Watts S. Humphrey（维基百科：https://en.wikipedia.org/wiki/Watts_Humphrey）写的，他同时也是PSP方面的专家。他是软件工程领域的知名专家和领导者。Humphrey在软件工程领域有着五十多年的工作经验，曾在卡内基梅隆大学的软件工程研究所（SEI）工作。他是团队软件过程（TSP）和个人软件过程（PSP）的创始人，这两种过程方法在软件开发领域得到广泛应用。

这本书主要围绕团队领导力展开，作者通过自己五十多年的开发工作经验，强调了领导力在团队创造力和项目成功中的至关重要性。作者指出，优秀的领导者一旦担任领导职务，他们能够出色地完成工作。相反，项目失败几乎总是因为领导力不足。作者描述了有效领导者与无效领导者之间的区别，并旨在帮助读者在遇到领导挑战时能够理解、预见并纠正常见的领导失误。

作者还介绍了软件工程研究所（SEI）在卡内基梅隆大学开发的团队软件过程（TSP），旨在指导软件开发团队。TSP不仅适用于软件开发团队，还适用于包括硬件、系统、测试等专业人员的团队。此外，作者还提到了个人软件过程（PSP）培训，以帮助团队成员掌握使用TSP所需的新技能。

总的来说，这本书涵盖了团队领导力的主要方面，包括团队成功的条件、团队类型、团队建设过程、团队工作、管理报告、项目审查、团队发展等内容。作者强调了团队的重要性，认为团队是人类为进行创造性工作而设计的最强大工具。通过与团队合作的经历，作者深刻体会到了团队的力量和乐趣。

RUP

统一软件开发过程（Rational Unified Process, RUP）是一种软件工程方法，旨在通过迭代式开发流程有效地开发和部署软件。最初由Rational Software公司开发，后来该公司被IBM收购，因此RUP也称为IBM-Rational Unified Process。RUP是一个重量级的过程，特别适合大型软件团队开发大型项目。它提倡迭代式开发，管理需求，使用基于构件的体系架构，软件的可视化建模，验证软件质量，以及控制软件的变更。

RUP强调角色、行为、产品和工作流四个核心元素。角色定义某人或一组人的职责，行为是目标明确的独立工作单元，产品是行为的产出，包括模型、源代码、文档等，而工作流则描述了行为的序列，展现了角色间的关系。RUP工作以设计和维护一系列模型为核心，这些模型以统一建模语言（UML）描述，支持通过CASE工具创建、修改和版本管理。RUP的核心工作流包括商业建模、需求分析、分析与设计、实现、测试、部署、配置管理、项目管理和环境等九个方面。

RUP的生命周期分为四个阶段：起始阶段、细化阶段、构建阶段和移交阶段。每个阶段有其特定目的，从构建产品的设想到最终交付给用户，包括业务模型、系统范围的确定、功能详细确定及架构设计、产品构建，最后是产品交付、培训和维护等。

虽然RUP是一个详尽和全面的框架，但它也可以针对小型项目进行裁剪和适配，允许采用敏捷方法等轻量级方法。这种灵活性意味着RUP并不是只适用于大型项目，通过合理裁剪，它也可以适应不同规模和需求的项目。总的来说，RUP提供了一个强大的框架，通过其迭代式开发和强调质量的原则，帮助项目团队有效地管理复杂的软件开发过程。不过，应用RUP时需要考虑到项目的具体情况，合理调整和裁剪过程以满足项目需求。

PSP

主要介绍了个人软件过程（PSP）的概念、原则和方法，以及如何将其应用于软件工作中。从PSP与一般质量原则的关系开始讨论，描述了PSP的发展历程、原则和方法。接着总结了PSP课程、教学策略、PSP经验数据、PSP在大学课程中的应用以及PSP在工业界中的推广情况。最后，对涉及PSP的未来趋势进行了评论。

其中还提到了PSP的设计目标是在计划的成本范围内按时生产零缺陷产品，并介绍了PSP与团队软件过程（TSP）结合使用时对工程师实现这些目标的有效性。强调了PSP为工程师提供了一个有纪律的个人框架来进行软件工作，包括方法、表单和脚本，展示了如何规划、测量和管理工作。还提到了PSP适用于任何编程语言或设计方法论，可以用于软件工作的大多数方面，如编写需求、运行测试、定义流程和修复缺陷。

大致上看详细介绍了PSP的概念、原则、方法以及在工业界和学术界中的应用情况，旨在帮助软件工程师提高个人和团队的工作效率和质量。旨在为软件工程师提供一个有纪律的个人框架来规划、测量和管理他们的工作。

PMBOK

《项目管理知识体系指南》（PMBOK Guide）是由美国项目管理协会（PMI）发布的一本涵盖项目管理标准的著作，自1987年首次发表以来，已经成为全球项目管理实践中的重要参考资料。它不仅被广泛接受为项目管理的标准，并且得到了包括美国国家标准协会（ANSI）在内的认证。PMBOK Guide历经多个版本的更新，至今已经发展至第七版。

PMBOK Guide的核心内容基于五大过程组（启动、规划、执行、监控与控制、收尾）和十大知识领域，包括范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、干系人管理和整合管理。这一框架旨在通过一系列逻辑分组的过程，应用知识、技能、工具和技术来满足项目要求。

从第六版到第七版，PMBOK Guide发生了重大变化。第七版首次提出了12项项目管理原则和8个项目绩效领域，基于这些重新构建了项目管理的知识体系。这标志着对项目管理视角的一次全新的演变，第七版更加注重项目交付的最终价值和原则，而不仅仅是关注项目的产出和可交付物。PMBOK Guide第七版的出现，反映了项目管理实践的发展趋势和对项目管理者能力要求的变化，强调了项目管理的灵活性、适应性和价值导向。它不仅提高了指南内容的可读性和实用性，同时保持了相关性和可信性，使其更适应当前快速变化的项目环境。

书本

直接记在书本上了

《软件需求》看目录和最后20道题目（好吧不需要）

《uml2》看每章题目（好吧不需要）

CSDN选择判断题

1、需求分析的任务是分析系统做什么

2、需求分析阶段，开发人员那里获得的最重要的信息是用户要让软件做什么。

3、“为了解决这个问题，目标系统必须做什么？”这是生存周期中需求分析阶段要确定的事。

4、需求分析是软件开发工作的基础。

5、从瀑布模型看，在它的生存周期中的八个阶段中，需求分析阶段出问题了对软件的影响最大。

6、需求分析是要完整、准确、清晰、具体地确定系统所要完成的工作，其依据是前一阶段的文档可行性研究报告。

7、需求分析是由分析人员经了解用户的需求，认真仔细的调研、分析、最终应建立目标统一的逻辑模型并写出需求规格说明书。

8、需求分析是分析员经过了解用户的要求，认真细致的调研、分析，最终应建立目标系统的逻辑模型，并写出软件规格书明书。

9、在不同的软件需求中，功能需求描述了用户使用产品必须要完成的任务，可以在用例模型或方案脚本予以说明，非功能需求是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求。

10、软件需求分析阶段的工作，可以划分为四个方面：对问题的识别、分析与综合，编写需求分析文档以及需求分析评审。

11、结构化分析建立功能模型的工具是DFD。

12、数据流图和数据字典共同组成系统的功能模型。

13、数据流图是进行软件需求分析常用的工具，其中最基本的图符是：处理，数据流，数据存储和数据源点/终点，其中“椭圆”可用来代表流图中的数据处理。

14、数据流是数据流图的基本成分，多个不同的数据流可以流向一个加工，也可以从一个加工中流出。

15、数据流图中的每个处理至少有一个输入流和一个输出流。

16、在分层数据流图中，若某层的加工K分解成下层的数据流图L，则K与L的输入、输出数据流必须相同。

17、画分层DFD图的基本原则是数据守恒原则，子、父图平衡的原则、数据流封闭的原则。

18、需求规格说明书的作用包括：软件验收的依据、用户与开发人员对软件要做什么的共同理解、软件设计的依据。

19、需求分析是由分析人员经了解用户的需求，认真仔细的调研，分析，最终建立目标系统的逻辑模型并写出需求规格说明书。

20、软件需求规格说明书是软件需求分析的重要文件，其包含数据描述、功能描述、性能描述。

21、数据字典是对数据定义信息的集合，它所定义的对象都包含在数据流图中。

22、数据字典是软件需求分析阶段的最重要工具之一，其最基本的功能是数据定义。

23、数据流图是描述数据在软件中流动和变换的过程，面对数据流图中所包含的元素的定义则是数据字典。

24、数据字典的作用是为用户与开发人员之间统一认识、作为概要设计的依据、为需求分析阶段定义各类条目。

25、描述复杂的事务时，图形远叙述优越的多，在需求分析阶段可以使用IPO图和层次方框图等图形工具。

26、信息建模方法是从数据角度对现实世界建立模型，其基本工具是实体联系图。

27、使用实体-联系图（ER图）建立的概念性数据模型中包含数据对象、属性、联系3种互相关联的信息。

28、使用结构化分析方法，采用的基本手段是分解和抽象。

CSDN简答题

什么是软件危机？为什么会出现软件危机？软件危机的表现是什么？

软件危机指在计算机软件的开发和维护过程中所遇到的一系列严重问题

典型表现有：对软件开发成本和进度的估计常常很不准确；软件产品的质量往往靠不住；用户对已完成的软件系统不满意的现象经常发生；软件常常是不可维护的；软件中没有适当的文档资料；软件成本在计算机系统总成本所占的比例逐年上升；软件开发生产率提高的速度，往往跟不上计算机应用迅速普及深入的趋势。

什么是软件生命周期和软件生命周期模型

软件生命周期模型是指软件开发过程中，由软件定义、软件开发和运行维护三个时期组成的整个过程。

软件生命周期模型是指在软件开发过程中，将软件的生命周期划分成那些阶段以及各个阶段执行顺序的框架。

常见的软件生命周期模型有瀑布模型、快速原型模型、增量模型、螺旋模型和喷泉模型。

可行性分析包括哪些工作

可行性分析的任务是在尽可能短的时间内确定软件项目是否能够开发，是否值得开发，是否符合用户的期望和需求。

技术可行性：使用现有的技术能实现这个系统吗？（自身团队角度）经济可行性：这个系统的经济效益能超过它的开发成本吗？（甲方客户角度）操作可行性：系统的操作方式在这个用户组织内行得通吗？（用户角度）必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。

如何收集需求？哪些需求可收集？

观察法，体验法，问卷调查法，访谈法，单据分析法，报表分析法等

符合产品定位的需求，目标用户的需求

数据流和数据字典的关系

数据字典是数据流图的定义，数据流图是数据字典的应用；数据字典是数据流图的细化，数据流图是数据字典的概括；数据字典是数据流图的解释，数据流图是数据字典的展示。数据流图和数据字典同时存在才有意义。

需求分析的基本任务

需求分析的基本任务是深入具体地了解用户的需求，在所要开发的系统必须做什么这个问题上和用户取得一致的看法，确定系统的功能需求和非功能需求，给出目标系统的逻辑模型。

①：确定对系统的综合需求。分析员和用户双方确定对系统的综合要求，具体有功能需求、性能需求、环境需求、接口要求、用户界面需求等的综合需求。②：分析系统的数据需求。分析系统的数据要求通常用建立数据模型方法（E-R图），复杂的数据结构利用图形工具辅助描绘。常用工具有层次方框图和Warnier图等③：建立软件的逻辑模型。通常用数据流图、数据字典及实体、联系图和主要的处理算法描述目标系统的逻辑模型④：编写软件需求规格说明书。⑤：需求分析评审。目的发现需求分析的错误和缺陷，然后修改开发计划。补在④修订系统开发计划

验证软件需求从哪些方面进行

一致性：所有需求必须是一致的，任何一条需求都不能和其他需求互相矛盾。完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。有效性:必须证明需求是正确有效的，确实能解决用户面对的问题。

如何进行需求分析

获取原始需求，写出需求陈述，建立模型，请用户评价模型并修正模型，撰写规格说明。

软件质量的含义

软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应具有的隐含特征相一致的程度。

CMM等级

初始级：指软件过程是无序的，没有明确的规范和标准，软件开发的成功依赖于个人的努力和能力。可重复级：指软件过程有一定的规划和管理，能够重复使用以前成功的经验和方法，能够控制成本和进度。已定义级：指软件过程有明确的定义和标准，能够根据组织的目标和策略进行定制和优化，能够提高质量和生产率。已管理级：指软件过程有量化的目标和度量，能够通过数据分析和反馈进行监控和控制，能够保证过程的稳定性和一致。优化级：指软件过程有持续改进的机制，能够通过创新和技术引入进行过程的优化，能够预防和消除缺陷和问题。

什么是结构化分析

是面向数据流的分析方法，是使用数据流图、数据字典、结构化语言、判定树和判定表等工具，来建立一种新的称为结构化说明书的目标文档。结构化分析方法采用归纳思维和演绎思维的逻辑方法，逐步建立目标系统的逻辑模型（包括数据模型、功能模型和行为模型），进而描绘出满足用户要求的软件系统。结构化需求分析方法基于“分解“和”抽象“的基本指导思想，采用面向数据流自顶向下逐步求精的分析策略，逐步建立目标系统的逻辑模型。

需求分析常用方法

①：功能分解法②：结构化分析方法③：信息建模法④：面向对象方法

需求分析步骤

①：需求获取：调查研究。②：需求提炼：分析建模。③：需求描述：编写SRS（需求规格说明书）。④：需求验证。

怎样理解分析阶段的任务是决定“做什么，”而不是“怎么做”

需求分析实际上是调查、评价以至肯定用户对软件需求的过程，其目的在于精化软件的作用范围，也是分析和确认软件系统构成的过程，以确定未来系统的主要成分及他们之间的接口细节。因此需求分析实际上是一个对用户意图不断进行揭示和判断的过程，它并不考虑系统的具体实现，而是完整地、严密地描述应当“做什么”的一种过程。

什么是数据流图

①：数据流图是SA方法中用于表示系统逻辑模型的一种工具。②：它描述系统由哪几部分组成，各部分之间的联系等，以直观的图形清晰地描述了系统数据的流动和处理过程。③：箭头表示数据流；圆或椭圆表示变换数据的处理；方框表示数据的原点或终点；双杠或单杠表示数据存储（文件）。

什么是数据字典

①：是对数据流图中所包含元素的定义的集合。②：作用正是在软件分析和设计的过程中，给人提供数据描述，即对数据存储和加工等名字进行定义③：数据流、数据流分量（数据基本项）、数据存储（文件）和加工（处理）。

简述半形式化的结构化分析描述工

①：数据流图。数据流图是一种描述“分解”的结构化过程建模工具。它描述系统由哪几部分组成，各部分之间的联系等②：数据字典。是关于数据的信息的集合，用来定义数据流图中的数据和加工，对数据流图中包含的所有元素的定义的汇集。③：描述加工逻辑的结构化语言、判定表和判定树。数据流图中的不能被再分解的每一个基本加工处理逻辑的详细描述采用结构化语言，判定表和判定树。

资料分享

分享一下UML书本题目答案和读后感

链接：https://pan.baidu.com/s/1MIWXgSsf1Z15k4iubhDC_Q?pwd=1234
提取码：1234
–来自百度网盘超级会员V3的分享