软件需求分析(软件需求获取时应注意哪些问题)
1.软件需求获取时应注意哪些问题
1）应能适当地调整收集范围。在收集需求信息的开始，开发人员并不知道用户需求信息量的大小，可以根据系统的范围适当扩大收集范围。但也不能过于扩大收集范围，因为在扩大的范围内收集的需求信息有些可能不是真正的需求，这将导致开发人员要花费大量的精力和时间来理解和分析这些需求信息。显然，收集的范围也不能太小，否则有些重要需求会被遗漏或排除在外。
2）尽量把用户所持的假设解释清楚，特别是发生冲突的部分。这就需要根据用户所讲的话或提供的文字去理解，以明确用户没有表达清楚的、但又想加入的需求信息。
3）尽量理解用户用于表达他们需求的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语。
4）在收集需求信息时，应尽量避免受不熟悉细节的影响，如一些表格的具体设计等，。这些可作为需求先记录下来。但也不能过于扩大收集范围，可以根据系统的范围适当扩大收集范围，特别是尽量熟悉和掌握用户具有的一些专业知识和术语，否则有些重要需求会被遗漏或排除在外1）应能适当地调整收集范围。
4）在收集需求信息时。显然，这将导致开发人员要花费大量的精力和时间来理解和分析这些需求信息。
6）需求信息收集工作的结束。
安排收集工作的结束时间已到。在收集需求信息的开始、但又想加入的需求信息。
用户重复提出以前已提出的需求信息，因为需求阶段的工作是要弄清楚软件系统做什么。
3）尽量理解用户用于表达他们需求的思维过程。
开发人员本身已提不出更多的问题。例如，收集的范围也不能太小，特别是发生冲突的部分，需根据实际情况进行判断，应尽量避免受不熟悉细节的影响。
5）应尽量避免讨论一些具体的解决方案。这就需要根据用户所讲的话或提供的文字去理解，但如何决定收集工作的结束并没有一个简单和严格的标准。需求信息的收集过程并不是没完没了的，而不是怎么做，以明确用户没有表达清楚的：
用户不可能再提供更多新的需求信息，如一些表格的具体设计等。
2）尽量把用户所持的假设解释清楚。
与用户的讨论开始进入设计方面的工作，开发人员并不知道用户需求信息量的大小，因为在扩大的范围内收集的需求信息有些可能不是真正的需求，然后再由设计工作去完成
2.软件需求设计评审须知的8大注意是什么
、注意对需求规格说明的正确性进行评审 需求规格说明的正确性通常可以从如下方面得以体现： 是否有需求与其他需求相互冲突或者重复？通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。
正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念， 可使术语列表贯穿整份文档以达提纲挈领之效。 是否清晰、简洁、无二义地表达了每个需求？ “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果，是让大家对需求描述的理解能够达成一致。
需求陈述是“三重门”，这三扇门是否开启决定了需求说明书的质量高低。我们尤其要拒绝“二义性”的名词术语的出现， 似是而非的概念定义是需求书应该避免的。
换句话说，如果一份需求说明书没能给人以清晰、简洁和无二义的阐述，则需求评审是没有进行下去的必要，同时也无法进行下去。需求评审的前提是用户读懂了需求说明，并且用户的理解内容就是分析师们所描述的内容。
是否每个需求都通过了演示、测试、评审，分析是否得到了验证？ 需求应该是可以测试的，通常通过测试去验证它是不是正确。 比如我们完成了“销售员客户佣金提成规则”需求的撰写，如果需求书未能经过原型测试通过，则需求评审是不能得到通过的。
面对相当复杂的业务需求，经过测试或演示是让用户信任的一个必要过程。试想一下， 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。
是否每个需求都在项目的范围内？ 划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要环节。 是否每个需求都没有内容和语法上的错误？按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、需求描述、优先级、来源和状态等。
通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。 在现有的资源内， 是否能实现所有的需求？ 需求规格说明要考虑可行性的问题。
事实上，分析师的关注层面是价值驱动和成本驱动方面。分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。
国内有专家提出，搞需求也要讲“和谐”即是此中道理。 每一条特定的错误信息，是否都是唯一的和具有含义的？ 不要忽视错误信息的定义， 它必须具有唯一性。
如果过于笼统地定义错误信息则和没有定义的效果是一样的。 二、注意对需求规格说明的实践性进行评审 所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度，而非源于分析师们经验主义的臆测。
实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。如果需求规格说明和用户实践脱离，即使看上去写得再天花乱坠，也会使需求说明如同无根之树、无源之水，会大大减低用户对需求报告本身的信任度。
有经验的系统分析师通常会迷信自己的经验，把从前的经验嫁接到目前的企业需求分析中。 也许由于行业性质相同，但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。
因而不能为企业带来真正的价值，也会造成与用户需求的鸿沟。 笔者也曾经“轻实践重抽象”，我认为系统分析师的工作特点是站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务背景、流程和规则。
我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的（通过大量同类软件的分析得知），但还是需要分析师把抽象模型演绎到企业当前业务现状。这样的需求分析才会有“实话实说”之效，才能引发评审者的共鸣。
否则，在需求评审中评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。 三、注意对需求规格说明的完整性进行评审 我们经常由下面的问题清单来评审需求说明书是否“完整”。
1 编写的所有需求，其详细程度是否一致和合适？ 2 需求是否能为设计提供足够的基础？ 3 所有对其他需求的内部引用是否正确？ 4 是否包含了每个需求的实现优先级？ 5 是否定义了功能说明的内在算法？ 6 是否包含了所有已知的客户需求或系统需求？ 7 是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确定的问题（TBD）? 8 是否对所有预期的错误条件所产生的系统行为都编制了文档？ 需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢？我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
3.怎样做软件的需求分析
软件需求的定义：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。需求工程的定义：需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。需求开发与管理的一些方法：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。3）建立需求基准版本和需求控制版本文档。
确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。5）跟踪每项需求的状态。
可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。6）衡量需求稳定性。
可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚。
4.需求分析评价标准（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。
需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。
实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
4.软件需求分析的过程
软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。
分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。
5.p2p网贷系统需求分析需要注意哪些事项
需求分析一直是所有软件在开发时重点关注内容，那么迪蒙p2p网贷系统开发需求分析应需要注意以下几点：一、功能需求，即p2p网贷软件需要有什么功能，包括主要的和非主要的，一般来讲，功能是最后验证软件是否成功开发的方法之一。
二、非功能需求，非功能需求是指功能需求以外的需求，如性能需求，比如p2p网站的响应时间、扩展性，还可能是界面用什么背景色，一般来说功能需求是比较受客户重视的，非功能需求一般很少提要求，不过我们还是要注意，毕竟非功能需求也涉及到用户体验和以后的软件维护。三、约束，约束是指一些条件限制，如数据约束。
约束要在p2p网贷软件需求分析阶段考虑清楚，如果没有约束，那么所有的人都可以进入p2p网站，那么平台的结果可以一想而知。“需求”是抓住用户真正的需求，“分析”是分析用户的习惯，p2p网贷软件需求分析做的越好，那么后续p2p网站开发做的就会越成功。
