软件项目需求调研方法及需求规格说明书的编写.ppt

北京科创新苑信息技术有限公司，2014-11-6唐玉林，1，需求开发和需求管理消除软件开发的根本原因，2，报告内容_需求概述，了解客户、最终用户、间接用户、需求级别、用户要求、功能要求(非功能要求)、说明用户使用产品必须完成的任务。定义开发人员必须实现的软件功能，使用户可以执行自己的任务，从而满足业务需求。需求是什么，被动，被动处理需求工程的各种活动，可以少做，可以少做，可以懒做。(本杰明富兰克林，努力)。他们认为需求是用户的工作，不是自己的工作。在开发过程中，随着需求的经常变化，产品会失去方向，中途放弃，或陷入反反射状态。对需求工程的三种态度，花时间了解用户要求，是确保项目成功所需的投入、要求、设计、编码、测试、维护、需求分析人员所需的技能、1、倾听技术2、对话和提问技术3、分析能力4、调整能力5、观察能力6、写作能力7 需求分析6，需求规格指南编写7，需求建模8，需求验证9，优先级划分10，需求管理，需求分析师的工作，9，获得报告内容_需求，需求调查的内容客户想要什么？ 你来这干什么？你为什么这样想？会有不同的想法吗？themelleryisadesigndigitalcontentcontentsmalldevelopedbyguilddesigninc。获取需求，需求调查的目的了解客户的需求逻辑了解客户想要的结果消除开发风险，潜在需求管理，需求调查的内容和目的，对需求的漫画，冰山理论，客户喜欢的100%，客户口中80%，你听到的60%，你理解的40%，开发的20首先，需求分析员必须填写需求调查问题表，并将重点放在问题表上。否则调查毫无防备。第二，需求分析员需要与用户对话，向用户提问等决定需求调查方法。给用户组发送问卷。参观用户的工作过程，观察用户的工作。与同事、专家交谈，听取他们的意见。分析已存在的类似软件产品以提取要求。产业标准，从规则萃取需求。在网上搜索相关资料。最后，需求分析员与答复者联系，确定调查的时间、地点、人员等，并制定需求调查计划。要特别注意，不要错过典型用户。制定准备调查，建议：整理日常问题归集文件，执行调查等日常问题收集习惯，建议：每次研究后填写会议纪要或用户需求调查单，准备完毕后，需求分析人员将根据计划进行调查。在调查过程中随时记录(或保存)要求信息。需求分析员与使用者面谈时，必须注意以下事项：如果与用户有约会，请不要迟到或早退。要注意礼节，尽量赢得用户的好感，为下次的打扰铺复线。需求分析员应事先了解用户的身份和背景，随机应变。需求调查不要像侦探推理那样从老开始，首先要知道宏观问题。双方气氛融洽的话，可以采用灵活的面谈形式，不轻易打断用户的谈话。如果双方在特定问题上的交流以逻辑方式结束，可以继续讨论问题表中的其他问题。尽量避免给用户带来麻烦，但也禁止给用户带来麻烦，减少需求调查的努力。单方面听取某些用户的要求，不要忽略其他用户的要求。16、report content _ requests分析，为了获取用户的钱，企业必须主张用户是神，用户总是对的。谁都知道这不是真的。实际上，需求不明确，需求说错了，或者提出了无法实现的要求。需求分析是需求开发过程中最需要大脑的工作。分析方法主要有两类：问答分析和建模分析。后者写道技术能力比较好，有学术味道，大部分软件工程书籍都有论述。电子只是常识。虽然不能写，但简单易用，具有实用价值。需求分析的基本概念、问题分析方法、问答分析方法：如果获得问题的答案，也将明确分析需求。一个人可以“扪心自问”分析需求，很多人把需求称为“研讨会”。最重要的问题“什么”、“为什么”、“不是什么”进行问答分析。其他常见问题是需求是否有异议。需求文件的内容是否有矛盾？需求齐全吗？需要需求吗？是否可以实现需求？是否可以验证要求？需求的优先级确定了吗？有的时候很难用语言来表达某些问题，有的人认为用图形来说“千言万语”就是这个道理。在需求开发过程中，对于某些类型的信息，以图形方式显示比文本表示更有效。因此，将图形和文本组合在一起描述要求是很自然的方法。需求建模是指用图形符号表示和表征需求。建模分析方法主要有两类：结构分析和面向对象分析。适当使用图形元件：最新的建模工具(如Rose)具有丰富的图形元件和文本标记，可以很好地表达模型的细节。塑型时使用过多的图形符号或文字会使模型表现法变得复杂，使开发人员难以理解，并使图形文件变得更加复杂。涵盖所有内容的图不能完美地描述要求。需求建模不能改写文本说明。在需求文档中，文本说明最重要，建模主要起到分析、解释的作用。建议将模型保存在需求文档的附录中，以便于正文引用。建模，分析，人们有时很难用语言表达某些问题，但有时为了一目了然，使用图形可以说是“千言万语的画”。需求建模是指用图形符号表示和表征需求。建模分析方法有两类：结构分析和面向对象分析。适当使用图形元件：最新的建模工具具有非常丰富的图形元件和文本尺寸，可以很好地表达模型的细节。塑型时使用过多的图形符号或文字会使模型表现法变得复杂，使开发人员难以理解，并使图形文件变得更加复杂。涵盖所有内容的图不能完美地描述要求。需求建模不能改写文本说明。在需求文档中，文本说明最重要，建模主要起到分析、解释的作用。建议将模型和文本有机地组合在一起，以相互补充。需求分析公用要素、完整功能方块图、流程图、使用案例、状态转换图、原型介面图、需求分析公用要素与工具、资料模型图、总统方块图、总统区块图、功能区块、核准流程图、商业流程图、 要求阶段的文件种类、通信时间、地点、与会者、交流的主题等与用户交流的实际记录，以及每个个人的想法、建议、要求、逻辑上不需要严格，注重真实。使用自然语言(和应用程序域术语)来表示用户的需求。内容以规格说明书为准，粗略，不够详细。但是有更完整的逻辑。，细化用户需求手册，更多地使用计算机语言和图形符号来表征需求，是软件系统设计的直接基础。会议纪要或用户需求调查单，用户需求说明书，软件需求规格说明书，产品需求规格说明书，需求规格表格式，1。简介1.1目标1.2料号范围1.3术语与简称2。系统概述2.1产品说明2.2产品功能2.3一般约束3。功能需求分类3.1功能需求分类方法3.2功能说明13.3功能说明2，3.3.1业务要求说明3.3.2用例图(角色说明)3.3.3功能要求1)流程图(批准或业务)2)功能说明3)主要数据元素4)原型接口4。外部介面1.1使用者介面1.2软体介面5。产品非功能要求，实现软件要求的目的，正确的要求规范指南，1正确的要求规范指南必须准确地反映用户的实际意图，“正确”是需求规格说明书最重要的属性。如果“错”只是错别字造成的，可以多检查几下文件，解决问题。真正的困难是开发者和用户自己不理解用户确切的“想要的”和“不想要的”。为了确保要求的正确性，开发人员和用户需要确认产品需求规格说明书。2清晰明确的要求易于阅读和理解。明确的反义词是“难读”、“难理解”。可以反问要求文档是否明确，即文档的结构和段落是否混乱等。上下文不一致吗？文件里的词句模糊吗，劳里？看了半天，还不明白需求究竟是什么吗？3无义性“无义性”意味着每个需求只有唯一的意义。如果一个人说话，另一个人能有不同的理解，这句话就有异议。如果需求有异议，就会误解需求，开发出超出需求的产品。为了不承认需求，写产品需求规格说明书的时候，表达要准确，不含糊。4一致意味着产品需求规格说明书的各个要求之间没有冲突。矛盾往往潜伏在需求文件的背景下。5需要产品需求规格说明书的所有要求对用户都是必需的。可以把“必需”比作“雪中送炭”。意思是“必要”进一步，“画蛇”或“锦上添花”。(。“画蛇”显然是坏事，会使开发者做更多难以讨好的事。因此，在要求规格说明书中，要尽量排除“画蛇添足”的要求。“锦上添花”是一件好事，它能给用户带来超过预期的快乐，但用户不会马上为此付出更多的钱。开发者应首先完成必要的需求，条件允许的话，集中在“锦上添花”的需求上。为了避免第一次和第二次反向，产品需求规格说明书应将此类“锦上添花”的需求设置为低优先级。6完全意味着产品需求规格说明书没有缺少某些必需要求。人们倾向于关注系统的特征功能，忽略其他不起眼的功能，但这是必需的功能。不完整产品需求规格说明书生成可能无法执行用户期望的操作的功能不完整的软件。什么是好的要求规范指南，77必须能够满足产品需求规格说明书的所有要求(Attainable)。“可行”是指技术上可行，并且满足时间、成本、质量等限制。营销人员在和用户谈生意的时候，为了获得“目录”，对用户的要求往往不会“拒绝”。飞牛皮不是非法的，但产品需求规格说明书是白纸黑字啊。双方确认的产品需求规格说明书类似于商业合同，如果开发者无法实现产品需求规格说明书的内容，则可能因违反合同而被罚款。对于合同项目，如果开发人员不能确定特定要求是否可行，应事先与用户协商，得出协议处理意见，避免以后的业务纠纷。8可验证产品需求规格说明书的要求必须全部可验证给用户。如果要求未经验证，用户将不能批准软件，可能会发生业务纠纷。例如，高层建筑的要求之一是“12级台风”。这个要求看起来像皇帝，但如何确认呢？高层建筑竣工验收时，用户不是向导，如何制造12级台风进行实验？该要求是“用计算机模拟12级台风”与实际测试相同的事实，如果双方承认，则是“可验证的”。什么是好的要求规范指南，什么是好的要求规范指南，9确定优先级为什么要确定要求的“优先级”？理论上，软件的所有要求都必须实现。但实际上，项目有“进度、成本、人力资源”等限制。项目刚开始的时候，开发者和客户要更乐观，做什么都行，但是这样做往往会遇到“进度延误、成本超支、人力不足”等问题。人们发现了“取舍选择”方法，从高优先级的要求开始，到低优先级的要求(甚至放弃)，将风险降至最低。需求的优先顺序是需求的优先顺序等级(例如，高、中、低等)。一般来说，需求的优先级由用户和开发人员共同决定。10不要“怎样”，要集中讨论“做什么”和“怎样”的要点。“如何”是系统设计和实施阶段的工作。在很多国内软件公司中，开发人员可能会从头开始开发需求、系统设计、编程等。因此，他们在调查、分析、定义需求时自然地想“怎么办”并没有错。如果在调查和定义要求时想“怎样”，当然要写下来。否则就不会浪费了！关键是，不要把“如何”写在要求规格说明书上，而要写在其他文件上就行了。需求规格缺陷检查表，如何查看签名，项目初期不能明确所有要求。要求肯定会随着时间而变化。签名不仅是意识，建立需求标准也很重要。也就是说，当时的要求是最佳理解时刻。定义需求基准后，将需求置于更改控制之下。以明确的合同结束前期的需求开发活动，帮助客户和开发团队形成合作关系，走上项目成功的道路，41，report content _ demand management，1 demand recognition(审查和承诺)requirements recognition需求确认包含两个重要任务：需求复查和需求承诺。2需求复查中面临的困难需求复查的常见问题之一是“虎头蛇尾”。需求审查实际上很无聊，需要更多的大脑。刚开始审查的时候，大家都比较认真，往后越来越马虎。要求审查可能包括更多的人，让很多人聚集在一起，要有更长的会议时间可能并不容易(例如，有出差的人，也有工作缠身的人)。没有必要把所有的东西都赶在一起。需求开发是一个渐进的过程。需求复查也可能分裂。这样可以缩短每次审阅的时间，参加审阅的人更少，组织会议更容易。举行审查会议时经常出现“订单制”，审查效率低下。话匣子打开后，有时不会关闭，所以大家离得越远，审查会议就变成了聊天会议。主持人应该控制主题，不要讨论与主题无关的事情。召开审查会议时经常发生争议。适当的争论有利于解释问题，不如一致赞成。但是争论变成争吵的时候不好。争吵不仅对审查工作不好，还会无意中伤害同事们的感情。人们可能常常“固执己见”，不知自己是否真的“坚持真理”。(。不妥协或轻易妥协不是好方法。养成好习惯。不要用一根球棒持有异样的观点