一、软件工程:3.需求分析
需求分析的任务就是准确地回答“系统必须做什么”。是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的功能、性能、运行环境等要求。
用户：知道做什么，不知道怎么做。
开发人员：知道怎么做，不知道做什么。
因此，系统分析员必须和用户密切配合、充分交流信息，得出经过用户认可的系统需求。
需求分析的目的是澄清用户的需求，并把双方共同的理解明确地表达成一份书面文档——需求规格说明书。
需求分析是一项软件工程活动，它包括：需求获取、需求建模、需求规格说明、需求评审。
需求分析模型是准确地描述需求的图形化工具，主要有实体关系图、数据流图、状态转换图。需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据结构、体系结构、接口和处理过程设计的模型。
如上图所示，目标系统模型的建立过程分 4步完成：
把分析的结果用正式的文档记录下来，作为最终软件配置的一个组成成分。需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。
作为需求分析阶段的复审手段，在需求分析的最后一步应该对功能的正确性、完整性和清晰性以及其他需求给予评价。
需求分析研究的对象是用户的要求。必须全面理解用户的各项要求，准确表达用户的要求。只有经过确切描述的软件需求才能成为软件设计的基础。
评审应由专人负责，评审组由软件开发成员、软件专家、领域专家和用户构成。
需求分析是一个不断的迭代过程。只有需求全面，准确无误，才能开发出用户满意的系统。
需求获取是软件开发工作中最重要的环节之一，其工作质量对整个软件系统开发的成败具有决定性影响。需求获取工作量大，所涉及的过程、人员、数据、信息非常多，因此要想获得真实、全面的需求必须要有正确的方法。常规的需求获取的方法有以下几种：
需求分析模型是准确地描述系统需求的图形化工具。它可以使人们更好地理解将要建造的系统，它有助于系统分析员理解系统的信息、功能和行为，成为确定需求规格说明完整性、一致性和精确性的重要依据，奠定软件设计基础。
需求分析建模的方法有结构化分析建模和面向对象分析建模。
结构化分析导出的分析模型包括数据模型、功能模型和行为模型。
需求分析模型以“数据字典”为核心，描述了软件使用的所有数据对象，围绕这个核心的是“实体关系图”、“数据流图”和“状态转换图”。
具体形式如下图所示：
实体关系图（ER，Entity-Relationship Diagram）：是一种数据模型，是以实体、关系、属性三个基本概念概括数据的基本结构，从而描述静态数据结构的概念模型。
ER包括三种基本元素：
关联的重数定义了在关联的一端可以存在的数据实体实例的数量。关联重数可以具有下列值之一：
两个数据对象之间按关联的重数有以下三种关联：
以下实体关系图描述的是教师、课程、学生三者之间的关系。
以下实体关系图描述的是出勤、职工、奖金、扣款之间的关系。
数据流图（DFD，Data flow diagram），是描述数据流和数据转换的图形工具，它是进行结构化分析的基本工具，也是进行软件体系结构设计的基础。
DFD有四种元素，其基本符号如图所示：
示例，工资计算系统的顶层（0层）数据流图：
在数据流图中有时也使用附加符号：*、+、⊕，分别表示与、或、互斥关系。
数据流图可分为不同层次，顶层（0层）DFD称为基本系统模型，可以将整个软件系统表示为一个具有输入和输出的黑匣子，其加工处理是软件项目的名称，用一个圆圈表示。
DFD中的每一个加工可以进一步扩展成一个独立的数据流图，以揭示系统中加工的细节。这种循序渐进的细化过程可以继续进行，直到最底层的 DFD图仅描述加工的原子过程为止。每一层数据流图必须与它上一层数据流图的输入输出保持平衡和一致。
数据流图是在需求陈述的基础上绘制的。
这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能。
第二层数据流图——销售细化：
第二层数据流图——采购细化：
当软件系统涉及时序关系时需要进行行为建模，由于数据流图不描述时序关系，系统的控制和事件流需要通过行为模型来描述。
在描述系统或各个数据对象的行为时，采用状态转换图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的行为。
状态转换图（STD，Status Transition Diagram），是描述系统状态如何响应外部事件进行转移的一种图形表示。
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有：初始状态、中间状态和最终状态。
事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。
在状态转换图中，圆圈“○”表示可得到的系统状态，箭头“→”表示从一种状态向另一种状态的转移。箭头旁标上事件名。
数据字典（DD，Data Dictionary）用来描述数据流图中的数据存储、数据加工和数据流。数据字典与数据流图配合，能够准确、清晰地表达数据处理的要求。
对于在数据流图中每一个被命名的图形元素均加以定义，其内容有:名字、别名或编号、分类、描述、定义、位置、其它。
在数据字典中，数据元素的定义可以是基本元素及其组合，数据进行自顶向下地分解，直到不需要进一步解释且参与人员都清楚其含义为止。
数据流定义实例：航班订票单的数据定义
数据元素定义实例：考试成绩的数据定义
数据文件定义实例：图书库存的数据定义
数据处理定义实例：编辑订票的数据定义
外部实体定义实例：教师的数据定义
存折＝户名＋所号＋帐号＋开户日＋性质＋(印密)＋1{存取行}50
户名＝2{字母}24
所号＝“001”..“999”
帐号＝“00000001”..“99999999”
开户日＝年＋月＋日
性质＝“1”..“6”注：“1”表示普通户，“5”表示工资户等
印密＝“0”注：印密在存折上不显示
存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核
需求规格说明书（SRS，Software Requirement Specification），是系统分析人员在需求分析阶段完成的文档，是软件需求分析的最终结果。
它的作用主要是：作为软件人员与用户之间事实上的技术合同；作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据。
SRS必须用统一格式的文档进行描述。为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，如中国国家标准推荐的SRS模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。
二、软件工程中需求分析的任务是什么
软件需求包括 3个不同的层次――业务需求、用户需求和功能需求。
除此之外，每个系统还有各种非功能需求。
业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
使用前景和范围（ vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter或 market requirement）文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求有时也被称作行为需求（ behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。
然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求说明书（ SRS）中。 SRS完整地描述了软件系统的预期特性。 SRS我们一般把它当作文档，其实， SRS还可以是包含需求信息的数据库或电子表格；
或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。
除了功能需求外， SRS中还包含非功能需求，包括性能指标和对质量属性的描述。
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
约束（constraint）限制了开发人员设计和构建系统时的选择范围。
行业需求：企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质，而对学历、年龄、性别、工作经验等的要求较低，相对于IT行业其他职位而言，软件测试的入行更加容易。
三、什么是需求分析,其目标是什么《软件工程》
需求分析，也叫软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统功能的过程。
需求分析的目标是把用户对待开发软件提出的要求或需要进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现的功能，完成的工作。此外，软件的一些非功能性需求、软件设计的约束条件、运行时与其他软件的关系等也是软件需求分析的目标。
扩展资料：
需求分析阶段分为四个方面：问题识别、分析与综合、制订规格说明、评审。
1、问题识别：从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求。
2、分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
3、制订规格说明书：编制文档，描述需求。需求分析阶段的成果是需求规格说明书，向下一阶段提交。
4、评审：对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
参考资料来源：百度百科-需求分析
好了，文章到这里就结束啦，如果本次分享的软件工程:需求分析_软件需求分析和软件工程中需求分析的任务是什么问题对您有所帮助，还望关注下本站哦！
