夫唯域名网如何进行网站建设的可行性探讨
网站建设可行性研究报告
一网站概述
二网站市场调研
三网站建设及维护成本
四网站效益评估
五风险评估与防范
六市场推广策略
七网站内容与板块规划
八网站建设技术选型
九建站进度安排
一网站概述
1建设何种类型的网站
2建立网站的目标、价值与作用是什么
3网站的长期与短期目标是什么
二网站市场调研
1网站的定位（提供何种服务，面向哪类客户等）
2该类型网站的现状与未来趋势
3本网站的特色等
三网站建设及维护成本
1网站建设成本（分为自主建设和外包）：
（1）自主建设网站（包括人员薪资、设备损耗、场地租赁、水电费等）
（2）网站建设外包
2网站维护成本
3市场推广费用（广告、活动等）
四网站效益评估
1可能产生的经济效益
2可能产生的社会效益
五风险评估与防范
1可能存在的市场风险、竞争对手的竞争
2如何规避风险
六网站市场推广
1利用搜索引擎。选择知名搜索引擎，让用户能通过多种搜索引擎找到该网站。
2通过网络链接和广告推广
3线下媒体宣传和推广活动策划，通过传统媒体进行网站宣传
4其他
七网站内容与板块规划
1网站的内容（包括企业邮箱、BBS、留言板、网站流量分析系统、网上调查、友情链接等）
2板块设置
设置哪些板块
板块的层次结构图
信息内容的来源与组织
八网站建设技术
1采用哪些技术和开发工具
2技术方案
九建站进度安排
网站建设所需时间
如何进行网站开发项目需求分析
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
原因
需求分析就是分析软件用户的需求是什么。如果投入大量的人力、物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的（相信大家都有体会）。比如：用户需要一个适用于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、尊重开发人员采用的需求分析方法
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析师采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析师为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析师身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
