软件需求分析

第一二章的阅读笔记 需求工程 （1） 需求工程定义： 　 需求工程 是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。 （ 2 ） 需求工程(RE)可分为 　　1.系统需求工程（如果是针对由软硬件共同组成的整个系统） 　　2.软件需求工程（如果仅是专门针对纯软件部分）。 　　软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。 需求工程师的能力 需求工程师岗位职责 1.根据产品规划或者项目要求，对客户进行需求调研，整理客户需求； 2.负责编写用户需求说明书； 3.负责将完成的项目模块给客户做演示，并收集完成模块的意见； 4.协助系统架构师、系统分析师对需求进行理解； 5.指导测试工程师根据测试需求，组建测试环境的工作。 需求工程师工作内容 1.在项目经理和高级开发工程师指导下，根据公司战略进行调研和数据分析，规划相关产品战略，长短期目标与产品策略； 2.搭建系统开发环境，并使用SVN、VSS、TFS等版本控制工具； 3

1 引言 1.1 编写目的 为学校同学提供一个处理闲置物品的平台，减少资源浪费。 1. 2 背景说明 a.跳蚤市场 b.任务提出者：二柱子 开发者：高尉雅、卢萌、许兴华 用户：学生 实现该软件的计算中心或计算机网络：校园网 C.该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 专门术语的定义：急售 外文首字母组词的原词组。 1. 4 参考资料 列出用得着的参考资料，如: a.本项目的经核准的计划任务书或合同、上级机关的批文 b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 任务概述 2.1 目标 1、实现基本的商品交易功能，包括发布商品、搜索商品和分享等； 2、实现基本的系统设置和用户管理功能； 3、提供用户交流的平台，如留言板等； 4、实现其他功能，如热销物品排名、物品关键字模糊查询等。 2. 2 用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束 2.3 假定和约束 列出进行本软件开发工作的假定和约束，例如经贵限制、开发期限等。 3 需求规定 3.1 对功能的规定 用户可以自己上传相应的商品图片，自定价格。 3.2 对性能的规定 3

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。 需求分析可分为需求提出、需求描述及需求评审三个阶段。 需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。 在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。 在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体

目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2. 参考资料 列出本说明书中引用和参考的资料，如： a．本项目的经核准的 计划任务书 或合同

1.实战中的软件工程——MSF的原则，MSF团队模型和开发模式，CargoCult。 MSF是什么呢？在前面的章节中讲了很多方法论和宣言，但这里介绍的是微软的一个宣言（Microsoft Solution Framework）,MSF有着九个基本原则：推动信息共享与沟通；为共同的远景而工作；充分授权和信任；各司其职，对项目共同负责；交付增量的价值；保持敏捷，预期和适应变化；投资质量；学习所有的经验；与顾客合作。下面对这些原则依次进行了介绍和理解。 首先是推动共享与沟通 。就是所有信息都保留且公开，也就是把所有的信息都共享，都用来沟通。这个原则的好处是能够让整个项目的开发流程更加的具备合理性和逻辑性。这样在管理这个项目时就更加简单了。 第二点，为共同的远景而工作 。其实就是大家一个团队的，力要往一处使，不能说每个人各做各的，到最后谁也好不了。要明白整个项目其实就是每个人的合作组成的。也就是统一思想，上下一条心。 第三点，充分授权和信任 。这一点的关键是授权。也就是每个成员都要有自己的授权，他们在有权在职权范围内完成任务。这个原则其实际是MSF模式的核心之一，团队之间要平等协作，并且各个成员之间得到充分的授权。这样的话，每个人都会负担起自己应该负担的责任，并且有足够的权利去做好自己分内的任务。 第四点，各司其职，对项目共同负责 。这点其实和第三点有着一些相似之处

工作成果： 完成软件需求规格说明书4.0，包括：项目开发企划，项目概述，可行性分析，NABCD分析，进行产品调研，需求获取，涉众分析，功能需求分析，性能需求分析，领域需求分析和其他需求分析。 完成设计规格说明书3.0，包括：需求概述、总体设计、系统详细设计。其中系统详细设计分为注册、登录、登记书籍、查询书籍、购买书籍、咨询、留言、修改书籍信息、订单管理、发布公告、修改公告、用户管理模块。 网页部分实现：静态网站搭建。 小组分工： 人员 分工 李林峰 把握小组全局工作，完成项目概述，进行产品调研，需求获取，性能需求分析，领域需求分析，其他需求分析，整合全部文档，主要撰写需求规格说明书 马伯乐 完成可行性分析，进行总体设计分析，修改类图、包图、活动图，主要撰写设计规格说明书。 卢茜君 分析性能需求，进行涉众分析，绘制状态图；留言、修改书籍信息、订单管理模块分析；进行网页实现 瞿壮 数据字典、NABCD分析；注册、登录、登记书籍模块分析 苗大林 绘制用例图、数据流图，类图，ER图；查询书籍、购买书籍、咨询模块分析 覃靖文 绘制包图；发布公告、修改公告、用户管理模块分析 来源： https://www.cnblogs.com/SwordArtOnline/p/9194138.html

学习了第八章的需求分析之后，我了解了软件需求的类型、利益相关者；获取用户需求的常用方法和步骤；竞争性需求分析的框架NABCD，四象限方法；项目计划和估计的技术。我们在做产品的时候要明确它所需要满足的各种功能和他的所属类型：杀手功能，外围功能，必要需求，辅助需求。软件项目的时间估计我们可以从自底而上和回溯两个方面来看，从而更好的进行估计。 在学习了第十六章IT行业的创新我了解到的是关于创新，有哪些似是而非的断论；WIIFM；创新者的困境；创新的时机，创新路上的鸿沟；先发优势和后发优势；改良式的创新和颠覆式的创新；效能过剩；NPS,CAC,用户留存率。书中提出的迷思一至七是值得我们去深深思索和探寻的，本章中也有结合第八章所提及的四象限方法，可以一起思考消化。 来源： https://www.cnblogs.com/XLX1/p/5487259.html

本书分为三大部分： 　　第一部分先介绍了一些基本的需求工程定义和一些优秀的需求分析所具有的特性。我希望你与你的重要客户能一起阅读第 2章（关于客户与开发者之间的伙伴关系）；第 3章介绍了许多需求开发和管理的改进熟练程度的好方法（良好的习惯做法）。第 4章有助于计划怎样将新的策略融入小组的开发过程中。方法是基于对附录中当前需求实践自我测试的回答。第 5章则介绍了一些通常与需求相关的项目风险。 　　第二部分介绍了许多关于需求开发的技术。首先是定义项目的业务需求，项目视图(vision)及涉及的范围(scope)。接下来的章节介绍怎样为项目寻找合适的客户代表，获取（elicit）用户需求，编写功能需求文档及质量属性文档。第 10章介绍了一些分析模型，这些模型可用于不同范围的需求分析。第 12章介绍了软件原型的结构和应用。第二部分中的其它章节还探讨了定义需求优先级的方法及验证需求分析是否正确的方法。 　　第三部分的主题是需求管理的原则和策略。这部分还特别介绍了处理需求变更和评价每项变更对项目影响的技术。第 18章介绍了怎样把需求跟踪能力和单个需求相关的内容需求来源到与需求相关的设计、代码等）联系起来。第三部分的内容包括一些商业工具的说明，这些工具能增强你管理项目需求的能力。 　　你一定知道：一个不能让你进行一项基本操作的软件产品是多么令人烦恼。你不会感谢开发者

　　作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上所具有的选择限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能，多角度描述产品对用户和开发人员都极为重要。 　　需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。 　　开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将会最终给系统带来极大损害的部分，而且以后再对它进行修改也极为困难。 　　不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时地完成并在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。第 5章将介绍怎样应用软件风险管理从而防止与需求有关的风险的出现和不适当的需求过程所引起的一些风险。 　　（1

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )