软件需求分析

全部答案为网络收集，侵权致歉，可联系删除。

简答题：

1.基线

基线定义：

基线（base line）是软件工程活动从一个环节转入另外一个环节时对阶段产品或组件的标识。

早基线，晚冻结

早基线：为了迟早启动开发，基线计划越早越好。

晚冻结：把文档看成是动态，并准备随时更改。

建立基线需要哪些条件

用户确认(根据用户的沟通交流，确认需求)

团队确认(项目团队确认项目需求)

技术确认(技术依赖性确认)

风险确认(项目风险评估确认)

业务确认(对每个主题域，将所有的需求项分等级，确定优先级)

什么是“需求基线”？

需求基线，通俗点说就是把这些需求都划一根“线”，说明这些需求已经确定下来，添加新的需求和修改原有的需求都必须通过需求变更流程来操作。目的就是为了防止需求的滥变给程序架构造成重大影响。

需求基线如何划定？

需求基线不是写出来的，而是在需求规格说明书评审通过以后所形成的，具体的步骤是开发人员先完成需求规格说明书的写作，然后组织相关人员对需求进行评审，在评审通过以后就纳入到配置库进行管理，形成需求基线 。

1.划定基线时，优先级越高的需求项应放在较早的安排；

2.若一个需求项估算量过大，比如超过了3个“迭代人日”，就必须进一步拆分需求项；

3.当开发人员人数较多，比如超过5个时，为了便于开发管理要划分多个开发小组，这时划分任务时要考虑人员分组的因素；

4.落到实地的进度计划，为了提高准确度要考虑人员产能系数的因素，可以根据其工作年限、工资水平或者人员等级水平等作为产能系数的依据；

基线管理

需求变更和迭代过程未完成这两个因素影响基线划定。一般采用的策略是，划定两次基线，一个基线投入开发迭代，另一个基线开始细化需求，从而实现流水线作业。

2.软件需求中的自定义模块

定义软件需求模块

（1）在程序设计中，为完成所确立需求所需的一段程序或子程序；

（2）业务需求模块反映了组织机构或客户对系统、产品高层次的目标要求。

（3）用户需求模块描述了用户使用产品必须要完成的任务。

（4）功能需求模块定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

（5）非功能需求模块描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

软件需求模块划分的步骤

(1) 分析系统的需求，得出需求列表；

(2) 对需求进行归类，并划分出优先级；

(3) 根据需求对系统进行模块分析，抽取出核心模块；

(4) 将核心模块进行细化扩展，逐层得到各个子模块，完成模块划分。

软件需求模块划分的准则

（1）确保每个模块的独立性，所谓模块独立性，即：不同模块相互之间的联系尽可能少，尽可能的减少公共的变量和数据结构。每个需求模块尽可能的在逻辑上独立，功能上完整单一，数据上与其他需求模块无太多的耦合如果各个需求模块之间的联系过多，模块独立性差容易引起系统结构混乱，层次划分不清晰。导致有的需求和多个需求模块均有关联，严重影响系统设计。

（2）在对软件进行模块划分的过程中，要充分遵照当前系统的框架结构。模块的划分要和系统的结构层次相结合，根据系统的层次对各个模块也进行层次划分。

（3）在设计需求模块的时候，需要遵循每个需求模块功能单一、接口简单、结构精简的原则。对每个需求模块的设计确保该模块的规模不要太大，接口尽量的单一简化。

3.软件的用户友好

定义：

机器和人看作同一个系统，这个系统有多个模块，包括机器模块和人类模块。机器模块之间的界面使用通常的程序接口。人机交互的界面就是机器模块和人类模块之间的接口。每个界面必须提供一定的抽象，用于防止使用者得到它不该知道的细节。这个使用者可能是机器模块，也可能是人类模块。软件的用户友好就是像提供给机器模块的良好抽象界面一样，提供给人类模块良好的人机交互界面，从而提升系统对于人类的可扩展性。

如何实现软件的用户友好

前端：

1.提供给用户充分而必要（不多余）的机制来帮助用户完成任务。

2.所提供的机制之间应该能够进行组合，并尽量使得完成同一项任务只有一种组合，减少冗余和重叠。

3.提供给用户的信息不管是符号还是图形，应该容易在人脑中建立起直观的模型，方便用户进行高效操作，换言之，注重UI的设计。

4.在任一特定时刻，应该只提供与当前被关注对象相关的操作，而不是提供所有情况下的所有操作供用户选择。

5.建立良好的用户反馈机制，方便对产品提出意见和反馈。

后端：

1.最大限度的掩盖程序内部的实现，尽量不让用户知道他不必要知道的东西。

2.良好的可访问性以及服务可用的持续性；

3.良好的可用性，bug越少，体验越好；

4.良好的性能，是否能及时快速的响应用户的操作；

5.良好的可操作性，代码实现充分考虑用户的输入习惯；

4.优化需求文档

需求文档的意义：

把正确的东西交给正确的人，满足协同人员的诉求。

如何优化需求文档：

1.具有可迭代的需求版本和需求优先级，帮助团队理解需求的价值和重要性，发挥指导性作用。

2.注重需求XYZ的使用，一句话说明白用户需求，即作为X，需要Y，以便Z，在用户的角度输出用户心理的呼唤。

3.注重图文并茂的表达，对功能与逻辑进行文字说明和图形分析。

4.添加效果图，效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。

5.利用交互原型设计软件制作产品原型，添加元素标注并说明功能需求。

5.需求管理（产品质量的基础）整合分类

1.项目经理以及项目其他成员。及时和项目组成员同步关键的项目进展，同时产出关键节点上的各种文件。

2.产品经理。定期复盘，找时间回顾每个版本的bug。

3.研发人员（前端人员，后端人员）。

6.数据字典

数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理过程（五个部分）进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明，简而言之数据字典是描述系统中数据的信息的集合，数据字典是在需求分析阶段被建立的。

好的数据字典对于企业内部与外部能起到什么作用

数据字典最重要的用途是作为分析阶段的工具。

有助于改进分析员，发小组之间的通信。

有助于改进不同开发人员，不同开发小组之间的通信。

有助于要求所有开发人员根据公共数据字典描述数据和设计模块，避免许多麻烦口问题。

数据库数据字典不仅是每个数据库的中心，而且对每个用户也是非常重要的信息。用户可以用SQL语句

访问数据库数据字典。

数据字典如何体现规范性：

1.数据字段命名，全部使用小写英文单词，单词之间用下划线隔开。

2.表名由一个或多个英文单词组成，其中每个单词都采用单数形式，每个单词首字母要大写，单词间不用任何连接符号。

3.视图若由多个表产生，就用下划线连接几个表名

4.如果整个网站系统又包括多个子系统，则需要在原表名之前加子系统名称，子系统名应为该子系统名称的缩写，并全部采用小写英文字符。

5.存储过程，命名规则采用P表名存取过程名。

问答题：

什么是软件需求说明书

软件需求说明书，又称软件需求规格说明书，英文名为Software Requirements Specification（SRS），是需求人员在需求分析阶段需要完成的产物。它的作用是作为用户和软件开发者达成的技术协议书，作为设计工作的基础和依据，作为测试和验收的依据。

1.用户怎么准备软件需求说明书

1.引言，指出编写目的，开发背景，对专门术语的定义以及用到的参考资料 。

2.任务概述，指出软件开发的意图，软件最终用户的特点，以及软件开发工作的假定和约束。

3.需求规定，指出包括对功能的规定，对性能的要求，输入输出要求，故障处理要求，数据管理能力要求和其他的专门要求，如可维护性，可扩充性，易读性，可靠性等。

4.运行需求规定，指出软件运行需要的硬件设备，支持的软件，与其他软件的接口以及控制该软件的方法和信号。

2.软件开发中，遇到软件设计，软件需求双方存在矛盾怎么协调关系

1.首先需要明确一点，在软件设计开发的过程中，发生矛盾是一定会出现的情况，以积极地平常心去看待，有助于矛盾的解决。

2.软件开发过程中摒弃“客户永远是对的”的想法，区别对待需求方提出的需求，对于软件需求方的需求进行分级管理，出现矛盾时，尽量优先满足关键性需求，改良性需求和可选性需求则在能够完成的条件下进行尝试。

3.坚持相互协作的基本思想，用户抵制的项目基本很难成功，在讨论需求时，开发人员与用户应该相互理解，尽量去解决矛盾，对于无法解决的矛盾也要积极向软件需求方提供替代的解决方案。

4.考虑到设计人员任务较重，安排专门的人员在开发过程中与软件设计人员和需求方进行沟通，了解需求方的真正需求并告知给设计人员，保障沟通的及时有效性。

5.选用适当的开发模型，例如使用建立原型的开发模型可以让需求方先看到一部分实用的东西，进而会对自己的需求有更详细的解释，方便设计人员进行完善。

6.需求评审注重细节。需求评审的时候，为了减少研发人员的业务思考，避免产品研发过程中对需求的误解，一份高保真的原型和详细的需求描述很重要。前期沟通得越清楚，后期的沟通成本就越小。

7.迭代应对变化，对于需求变更频繁的产品，用迭代的方式进行研发能够减少不确定性。特别是C端使用的产品，根据用户的反馈，一周一迭代就是一个很好的控制需求变更的方法。

8。以不变应万变，若在迭代的过程中遇到需求变更，最好的方法就是先不开发此功能，充分考虑变化带来的后果，放到下一个迭代之后再实现这个需求对应的功能。

3.如何看待项目经理，产品经理......五个角色

1.项目经理：确保项目目标的实现，领导项目团队准时、优质地完成全部工作，负责与团队沟通，监督项目进度，协调项目组成员的进度，进行项目总结，并及时向上级汇报项目的进展情况和需求的变更情况，重点在开发管理沟通。

2.产品经理：在产品设计阶段考虑划定产品范围，考虑成本需求，负责指导产品的优化迭代，作为内部和外部干系人，需要同时与客户和开发团队进行沟通，并在项目完成后负责验收，重点在业务沟通。

3.系统架构师：对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。负责理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架），从事研发工作，起从业务向技术转换的桥梁作用。

4.软件设计师：负责开发项目的系统分析、研发与组织实施，负责开发符合系统要求的软件内容，修改以有的系统方案，以维持优良的操作性能及正常的信息沟通。

5.系统测试师：完成公司硬件相关产品的研发阶段测试工作，配合业务平台进行相关业务测试工作;根据产品需求和设计文档，制定测试计划，并分析测试需求、技术测试流程;根据产品测试需求完成测试环境的设计与配置工作;执行具体测试任务并确认测试结果、缺陷跟踪，完成测试报告及测试结果分析;是产品交付前的最后一道工序。

案例分析题：

小明在a公司和a公司合作申请技术著作权和相应的科研论文，在论文专利还没有授权时到了b公司，在b公司用了该技术，构成软件侵权吗？如何看待该行为？

软件侵权、风险管理、风险防控、软件的附加产品

答：不构成侵权，根据软件侵权中常用的法规《著作权法》和《专利法》，软件本身所适用技术设计由《专利法》保护，虽然a公司和小明作为该专利的共同所有者，且a公司对专利的使用并不知情，但由于专利没有授权，因此不侵权。但是，为了保护中专利权人的合法利益，专利法第规定“发明专利申请公布后，申请人可以要求实施其发明的单位或者个人支付适当的费用。”因此a公司可以申请一定的补偿。

从b公司角度来看，使用这类有专利纠纷的技术开发软件就是有风险的行为，因此必须进行风险管理。风险控制的四种方法有风险回避，放弃本次开发，损失控制，比如和a公司进行协商等，风险转移，通过合同或保险等方式转移可能出现的纠纷成本，风险保留，继续使用小明有纠纷的技术进行开发。这取决于最终b公司的决策。