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

1、，2014-11-6，1，消除需求开发和需求管理软件开发百瓶的袁泉，2，报告内容_需求概览，客户，终端用户，间接用户，了解需求级别，定义开发人员必须实现的软件功能，使用户能够执行自己的任务以满足业务需求。以需求、被动、被动的方式对待需求工程的各种活动，少则少，懒则懒。他们认为需求是用户的工作，不是自己的工作。在开发过程中，需求经常发生变化，失去了产品的方向，往往半途而废或陷入半死不活的状态。对需求工程的三种茄子态度、花时间了解用户要求是确保项目成功所需的投资、要求、设计、编码、测试、维护、需求分析师所需的技能、1、听力技能2、对话和提问技术3、分析能力4、曹征能力5需求分析师所需的技能、1你为

2、什么这么想？还有别的想法吗？theme gallery is a design digital content contents mall developed by guild design inc .获取需求，了解需求调查目的了解客户的需求了解需求了解逻辑客户想要的结果消除开发风险，确定潜在需求，需求调查的内容和目的，以及向用户社区发送问卷。访问用户的工作流并观察用户的活动。与同事、专家交谈，听取他们的意见。分析现有类似软件产品以提取要求。产业标准，从规则中提取需求。在网上搜索相关资料。最后，需求分析员与答复者联系，确定调查时间、地点、人员等，并制定需求调查计划。特别要注意的是不要遗漏典型的

3、用户。准备调查，建议：整理日常问题收集文件，进行问卷调查，建议：每次调查后填写会议记录或用户要求调查西餐，准备工作完成后，需求分析师将按计划进行调查。在调查过程中随时记录(或保存)要求信息。需求分析员与使用者面谈时，必须注意以下事项：与用户约定时间时，不要迟到或早退。要注意礼节，尽量赢得用户的好感，下次为了妨碍他们，要系复线。需求分析员为了随机应变，需要事先知道用户的身份和背景。需求调查不要像侦探推理那样从线索开始，首先要掌握宏观问题，然后理解细节问题。如果双方的气氛融洽，可以采取灵活的采访形式，避免轻易打断用户的对话。双方对特定问题的交流逻辑结束后，可以继续讨论问题表中的其他问题。尽可能避免

4、用户的麻烦，但害怕给用户带来麻烦，不能降低需求调查的力量。单方面听取特定用户的要求，避免无视其他用户的要求。16、报告内容_需求分析，为了获取用户的钱，企业必须提倡用户是上帝，用户总是正确的。谁都知道这不是真的。事实上，用户往往不知道需求，说错需求，或提出无法实现的需求。需求分析是需求开发过程中最费脑的事情。分析方法主要有两种茄子：“问答分析方法”和“建模分析方法”。后者技术性比较强，具有学术味道，因此大多数软件工程书籍都有论述。电子只是常识。虽然不能写，但很容易使用，有实用价值。需求分析的基本概念，问题分析方法，问答分析方法一个人可以“自行咨询”分析需求，几个人分析需求被称为“讨论”。问答分

5、析中最重要的问题是“什么”、“为什么”、“什么都不是”。其他常见问题包括：需求有两重性吗？需求文件的内容有矛盾吗？需求齐全吗？需要需求吗？需求能实现吗？可以确认要求吗？需求的优先级确定了吗？人们会觉得有些问题很难用语言来描述，使用图形一眼就能看出来。所谓“一道千言”牙齿就是这个道理。(威廉莎士比亚，温斯顿，语言) (威廉莎士比亚，温斯顿，语言)在需求开发过程中，对于某些类型的信息，以图形方式表达比文本表达更有效。因此，将图形和文本结合起来描述要求是很自然的方法。需求建模是指用图形符号表示和描述需求。建模分析方法有两个茄子主要类别：“结构分析”和“面向对象分析”。正确使用图形符号：现代建模工具(

6、例如rose)具有非常丰富的图形符号和文字标注，可以很好地表达模型的详细信息。需要注意的是，建模时使用太多图案的图形符号或文字意味着模型表达的复杂性，使开发人员难以理解，使图形文档更加复杂。世界上没有包罗万象的画。它能完美地描述需求。需求建模不能替代文字说明。在要求文档中，文字说明是第一重要的，建模主要起到分析和解释的作用。建议将模型保存在需求文档的附录中，以供正文参考。建模分析方法，每个人都有这种感觉。有时用语言描述某个问题特别困难，采用图形的话一眼就能看出来。可以说是“一都川言”。需求建模是指用图形符号表示和描述需求。建模分析方法有两大类：结构分析和面向对象分析。图形符号的适当使用：现代建

7、模工具有很多种，具有非常丰富的图形符号和文字尺寸，可以很好地表达模型的详细信息。需要注意的是，建模时使用太多图案的图形符号或文字意味着模型表达的复杂性，使开发人员难以理解，使图形文档更加复杂。世界上没有包罗万象的画。它能完美地描述需求。需求建模不能替代文字说明。在要求文档中，文字说明是第一重要的，建模主要起到分析和解释的作用。建议将模型和文字有机结合，徐璐补充。需求分析公用元素、完整功能块图表、流程图、使用案例图表、状态切换图表、环形介面图表、需求分析公用元素和工具、数据模型图表、总统功能块图、总统功能块图、功能块图、审批流程图、其内容不比规格说明书粗糙、详细。但是有比较完整的逻辑。，是用户要

8、求手册的精细化，更多地使用电脑语言和图形符号来描述要求是软件系统设计的直接依据。会议记录或用户要求调查表、用户要求手册、软件要求规格表、要求规格表格式、1 .简介1.1目标1.2项目范围1.3术语和缩写2。系统概述2.1产品说明2.2产品功能2.3一般约束3。功能需求分类3。1功能需求分类方法3。2功能说明1 3。3功能说明2，3.3.1业务要求说明3.3.2使用案例(角色说明)3.3.3功能要求1)流程图(批准或业务)2)功能说明3)主要数据元素4)原型介面4。外部介面1.1用户界面1.2软件介面5如果“不准确”只是错别字造成的，再检查几下文件就可以解决问题。真正的困难是开发者和用户自己也不

9、理解用户到底想“想要什么”和“不想要什么”。为了确保要求的正确性，开发人员和用户应检查要求规范手册。2清晰明确的要求易于阅读和理解。明确的反义词是“难读”、“难理解”。你可以用反问的方式判断需求文件是否明确：文件的结构，段落是否杂乱？上下文不一致吗？文件里的句子模糊，劳里唠叨吗？看了半天也不知道需求到底是什么吗？3没有双重性“没有双重性”意味着每个需求只有唯一的意义。如果一个人说的话每个人的理解都不一样，那么牙齿的话就有两重性。如果需求具有两重性，人们就会误解需求，开发出脱离需求的产品。为了无需求性，人们在写产品需求规格说明书的时候，表现要准确，模棱两可才能渡边杏。4一致性“一致性”意味着产品

10、要求规格表中的每个要求之间没有矛盾。矛盾往往潜伏在需求文件的背景下。5必需产品要求规格规格中的每个要求对用户都是必需的。可以把“必需”比作“雪中送炭”。意思是“必要”进一步，“画蛇”或“锦上添花”。(。“画蛇”显然是坏事，会使开发者做更多难以讨好的事。因此，在要求规格说明书中，要尽量排除“画蛇添足”的要求。“锦上添花”是一件好事，它能给用户带来超过预期的快乐，但用户不会马上为此付出更多的钱。开发者应首先完成必要的需求，条件允许的话，集中在“锦上添花”的需求上。为了避免第一次和第二次反转，应将产品要求规范文档中的这些“锦上添花”要求设置为较低的优先级。6完成“完成”意味着产品要求规格表中没有缺少

11、必要的要求。人们往往关注系统的特征功能，但忽略了其他微不足道但必要的功能。(威廉莎士比亚、温斯顿、系统)不完整的产品要求规范会导致不完整的软件，使用户无法完成他们想要的任务。什么是好的要求规格表，77可实现的产品要求规格表的每个要求必须对开发者都是可实现的。“可行”意味着技术上可行，并且满足时间、成本、质量等限制。营销人员和用户谈论生意时，为了获得“目录”，他们经常对用户提出的需求说：“来者不拒”。吹牛不是非法的，但是产品需求规格说明书是白纸黑字。双方确认的产品需求规格表相当于商业合同。开发者如果不能实现产品需求规格表的内容，将会被罚款，成为违约。对于合同项目，如果开发人员不能确定特定要求是否

12、能实现，则应字典与用户协商，同意商定的处理意见，以避免以后的业务纠纷。8可验证的产品要求规格规格中的每个要求都必须对用户可验证。如果需求未经验证，用户将无法验收软件，可能会发生商业纠纷。例如，摩天大楼的需求之一是“12级台风”，牙齿的需求看起来很理直气壮，但如何验证呢？摩天大楼完工后验收时，用户又不是巫婆，他怎么能制造12级台风来试试呢？如果双方都承认“用电脑进行12级台风模拟”牙齿实际测试一样，牙齿需求是“可验证的”。什么是好的需求规格表，什么是好的需求规格表，9优先决定为什么需要决定需求的“优先”。理论上要实现软件的所有要求。但实际上，项目有“进度、费用、人力资源”等限制。项目开始时，开发

13、人员和客户很乐观，所有的事情都要做，但是这样做的话，人们经常面临“进度延误、费用超支、人力不足”等问题。这时乱成一团。人们想出了“取舍”的方法。如果先提出高优先级需求，然后提出低优先级需求或放弃，就可以将风险降至最低。需求的优先级实际上是需求的“轻重缓急”的等级表现。例如，分为“高、中、低”。通常，用户和开发人员共同确定需求的优先级。10不是“做什么”，而是“如何做”产品要求说明书的重点不是“做什么”，而是说明“做什么”。“怎么办”是系统设计和实施阶段的工作。在国内的很多软件公司中，开发者往往兼做多个茄子职位，从开始到结束都可以进行需求开发、系统设计、编程等。所以他们在调查、分析、定义需求时当

14、然会想到“该怎么办”，这不是错的。在调查和定义需求的时候，如果想出“该怎么办”，当然要写下来。否则就不会浪费！关键是不要把“怎么做”写在需求规格说明书上，写在其他文件上就行了。需求规格表缺陷清单，如何查看签名，不可能在项目初期明确所有需求。需求要随着时间而变化。签名不仅是意识，更重要的是建立需求的标准。即使是对当时需求最好的理解时刻。定义需求标准后，需要将需求置于变更控制之下。通过明确的协议，结束前期的需求开发活动，可以帮助客户和开发团队形成伙伴关系，走上项目成功的道路。41、报告内容_需求管理，1需求确认(审查和承诺)需求确认是指开发人员和客户方面共同审查产品需求规格说明书，双方同意需求后做

15、出承诺。需求确认包括两个茄子重要任务：需求复查和需求承诺。2需求审查面临的困难需求审查的通病之一是“龙头蛇美”。需求审查确实乏味，而且多用脑子。刚开始审查的时候，大家都比较认真，越往后越糊涂。需求审查可能涉及更多的人员，有时需要很长时间召集这么多人开会(例如出差，工作缠身)。没有必要把所有的事都凑在一起做。需求开发是一个逐步进行的过程，需求复查也可以分段。这样每次审查的时间比较短，参加审查的人数也比较少，组织会议比较容易。开审查会议的时候经常离题，审查效率很低。有时话匣子一打开就关不上，大家越走越远，最终评委会变成聊天会议。主持人要控制话题，不要讨论与主题无关的事情。在举行审查委员会时，经常发生争议。适当的争论有助于澄清问题，胜过一切一致赞成。但是当争论变成争吵时，会变成坏事。争吵不仅不利于审查工作，还会伤害同事的