夫唯域名网网站设计需求分析撰写指南
1）绘制关系图：绘制系统关系图是用于界定系统与外部实体间边界及接口的简易模型。同时，它也阐明了通过接口的信息流和物质流。
2）构建开发原型：当开发人员或用户对需求不确定时，构建用户接口原型，使众多概念和潜在事件更加直观易懂。用户通过评估原型，有助于项目参与者更深入地理解需解决的问题。注意识别需求文档与原型间的所有冲突点。
3）评估可行性：在预算、性能要求范围内，评估每项需求的实施可行性，明确与每项需求实现相关的风险，包括与其他需求的冲突、对外部因素的依赖及技术障碍。
4）设定需求优先级：运用分析方法确定软件工程需求的优先级，以确定产品版本应包含的特性或需求类别。当允许需求变更时，在特定版本中纳入每一项变更，并在该版本计划中进行必要的调整。
5）构建需求模型：需求图形分析模型是软件需求规格说明的绝佳补充，它们能提供不同信息和关系，有助于发现不正确、不一致、遗漏和冗余的需求。此类模型包括数据流图、实体关系图、状态转换图、对话框图、对象类及交互图。
6）编制数据字典：编制数据字典，定义系统所使用的所有数据项和结构，确保开发人员使用统一的数据定义。在需求阶段，至少应定义客户数据项，以确保客户与开发团队使用一致的定义和术语。分析和设计工具通常包含数据字典组件。
7）实施质量功能分配：运用质量功能分配，这是一种高级系统技术，将产品特性、属性与客户重要性联系起来。该技术提供了一种分析方法，以明确客户最为关注的特性。它将需求分为三类：期望需求，即客户可能未提及，但缺失会令其不满；常规需求；兴奋需求，即实现会给客户带来惊喜，但未实现也不会受到责备。
如何高效进行网站开发项目需求分析
广义上，需求分析涵盖需求获取、分析、规范、变更、验证、管理等一系列需求工程活动。
狭义上，需求分析指需求的分析和定义过程。
重要性
需求分析即分析软件用户需求。若投入大量人力、物力、财力、时间开发的软件却无人问津，所有投入都将白费。若投入大量精力开发软件，最终却不满足用户需求，需重新开发，这种返工令人痛心疾首。例如：用户需要一个适用于Linux的软件，而你在软件开发初期忽略了软件的运行环境，未向用户询问，想当然地认为是开发适用于Windows的软件。当你费尽心思开发完成后提交给用户时才发现问题，那时你将欲哭无泪，恨不得撞死。
需求分析之所以重要，在于其决策性、方向性和策略性作用，在软件开发过程中具有举足轻重的地位，我们必须高度重视需求分析。在大型软件系统开发中，其作用远大于程序设计。
任务
简而言之，需求分析的任务是解决“做什么”的问题，即全面理解用户的各项要求，并准确表达所接受的用户需求。
过程
需求分析阶段的工作可分为四个方面：问题识别、分析与综合、制定规格说明、评审。
问题识别：从系统角度理解软件，确定对所开发系统的综合要求，提出实现这些需求的条件，以及需求应达到的标准。这些需求包括：功能需求（做什么）、性能需求（达到什么指标）、环境需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求（软件运行所需的内存、CPU等）、软件成本消耗与开发进度需求、预先估计系统可能达到的目标。
分析与综合：逐步细化所有软件功能，找出系统各元素间的联系，接口特性和设计限制，分析其是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。
制定规格说明书：即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审：对功能的正确性、完整性、清晰性及其他需求进行评价。评审通过后方可进行下一阶段工作，否则需重新进行需求分析。
方法
需求分析方法众多，此处仅强调原型化方法，其他方法如结构化方法、动态分析法等未曾使用，故不讨论。
原型化方法至关重要，原型即软件的早期可运行版本，实现了目标系统的某些或全部功能。
原型化方法就是尽可能快速地构建一个粗糙的系统，该系统实现了目标系统的某些或全部功能。但这个系统可能在可靠性、界面友好性或其他方面存在缺陷。构建这样一个系统的目的是为了检验某一方面的可行性，如算法的可行性、技术的可行性或检验是否满足用户需求等。例如：为了检验是否满足用户需求，可以使用某些软件工具快速构建一个原型系统，该系统只是一个界面，然后听取用户意见，改进原型。以后的目标系统将在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
原型主要有三种形态：探究型、试验型、发展型。
探究型：目标在于明确目标系统的需求，确定期望的特性，并探讨多种方案的可行性。
试验型：在大规模开发与实现之前，检验方案是否适宜，规格说明是否可靠。
发展型：目标不在于优化规格说明，而是构建易于变更的系统，在改进原型的过程中，逐步将原型演化为最终系统。
运用原型化方法时存在两种不同的策略：舍弃策略、增补策略。
舍弃策略：首先构建一个功能简单且质量要求不高的模型系统，针对该系统反复进行修改，形成较好的思路，据此设计出较为完整、准确、一致、可靠的最终系统。系统构建完成后，原来的模型系统便不再使用。探究型和试验型属于此类策略。
增补策略：首先构建一个功能简单且质量要求不高的模型系统，作为最终系统的核心，然后通过不断扩充修改，逐步增补新要求，发展成为最终系统。发展型属于此类策略。
需求分析20条原则
客户与开发人员沟通需要有效的方法。以下提供20条原则，客户和开发人员可以通过审查以下内容并达成共识。若遇到分歧，将通过协商达成对各自责任的相互理解，以便减少未来的摩擦（如一方要求而另一方不愿意或无法满足要求）。
1、分析人员应使用符合客户语言习惯的表达
需求讨论集中在业务需求和任务上，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）传授给分析人员，而客户不一定要了解计算机行业的术语。
2、分析人员需了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需求。这将有助于开发人员设计出真正满足客户需求并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用旧系统，有利于他们明白系统是如何运作的，其流程情况以及可供改进之处。
3、分析人员必须编写软件需求文档
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方案和其他信息。通过这些分析，客户就能得到一份“需求分析文档”，此份文档使开发人员和客户之间针对要开发的产品内容达成协议。文档应以一种客户认为易于翻阅和理解的方式组织编写。客户要审查此文档，以确保文档内容准确完整地表达其需求。一份高质量的“需求分析文档”有助于开发人员开发出真正需要的产品。
4、要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析文档”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以文档中各种图表有着极高的价值；尽管它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、要求对变更的代价提供真实可靠的评估
有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
每个人都期待项目取得成效，但这不仅需要客户向开发者明确阐述系统“需实现什么”的详细信息，还要求开发者能通过沟通明确理解取舍与限制，务必清晰地表述您的假设和预期，否则，开发者制作的产品很可能无法满足您的期望。
11、向分析师阐述您的业务
分析师需要依赖客户对业务概念及术语的讲解，但客户不能期望分析师能成为该领域的专家，而只能使他们明白您的问题和目标；不要期待分析师能掌握客户业务的微妙潜在之处，他们可能不了解那些对于客户来说理所当然的“常识”。
12、抽出时间明确阐述并完善需求
客户虽然忙碌，但无论如何客户需要抽出时间参与“头脑风暴会议”的讨论，接受访谈或其他获取需求的活动。有些分析师可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的细化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功至关重要。
13、精确而详尽地阐述需求
编写一份清晰、精确的需求文档是困难的。由于处理细节问题既繁琐又耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只能依靠开发者去正确猜测了。
在需求分析中暂时标注“待定”是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析师能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以与开发者一起反复修改，不断完善需求定义。
14、及时作出决策
分析师会要求客户作出一些选择和决策，这些决策包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决策的客户必须积极地对待这一切，尽快处理，做出决策，因为开发者通常只有等客户做出决策才能行动，而这种等待会延误项目的进展。
15、尊重开发者的需求可行性和成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上不可行，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发者会对此作出负面的评价，客户应该尊重他们的意见。
16、确定需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发者将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发者的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、审查需求文档和原型
客户审查需求文档，是给分析师带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析师并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发者，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发者能将其转化、扩充成功能齐全的系统。
18、需求变更要立即通知
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析师。
19、遵循开发小组处理需求变更的程序
为将变更带来的负面影响减少到最低限度，所有参与者必须遵循项目变更控制程序。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、尊重开发者采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析师采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析师为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发者不开始编码。”
这种态度将带来麻烦，例如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析师身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
同样的问题也可能出现在那些仅将“签字确认”视为任务完成的分析师身上。一旦需求发生变化，他们便会指着“需求分析报告”宣称：“您已经对此需求签字确认，因此这些就是我们开发的。若您需要其他内容，请尽早告知我们。”
这两种做法都是不恰当的。因为在项目初期，我们无法完全掌握所有需求，而且需求变更几乎是必然的。在“需求分析报告”上签字确认是正确结束需求分析流程的方式，因此我们必须清楚签字的含义。
对“需求分析报告”的签署是基于一个需求协议的基础，因此我们应该这样理解签署的意义：“我同意这份需求文档反映了我们对项目软件需求的认知，进一步的变更可以在这一基础上，通过项目规定的变更流程进行。我明白变更可能会引起成本、资源以及项目阶段任务的重新协商。”达成需求分析的一致意见，有助于双方在未来更好地承受因项目改进、需求误差或市场、业务新要求等因素带来的摩擦。
