谁写过需求说明书？

[yesry]

我现在需要搜集足够的软件需求进行分析，请各位大哥大姐赐稿，报以为分，报以为￥。[e-mail]

[yihua_cai]

一 需求获取的2个基本原则


1 深入浅出


　　对企业的需求调研的要尽可能的全面、细致,调研的需求是个全集，系统真正实现的是个子集。所做的工作可能一时看不到有什么作用,但是这样做可以对应用领域的业务吃得很透,能够避免一些不必要的麻烦，如可以保证系统的灵活性等。调研的细致并不等于在分析时都面面俱到地将调研的内容纳入到新系统中, 而有可能实现的很少,但其中在向细处扩充时将会很容易。也就是讲，当新系统设计出来时,开发人员很清楚新系统与旧系统相符合的程度,还有多大的余地或工作可以做,对用户提出的一些细致的问题都能够在系统中找到解决方法。


2 以流程为主线


　　在与用户交流的过程中，应该用流程将所有的内容串起来，如单据、信息、组织结构、处理规则等，这样便于交流沟通，符合用户的思维习惯。流程的描述既要有宏观，又要有微观。即要强调总体的业务流程、全生命周期的业务流程，又要对流程细化，有分支的业务流程。在分析企业流程并进行优化时，要把握几个方面：


　　●该流程中是否存在不必要的环节？
　　●是否可以将决策的权力下放到作业部门？
　　●流程是否可以简化？
　　●是否可以省略一些环节？
　　●流程中的每个处理环节是否起到了增值的作用？
　　●哪些流程可以并行处理？
　　●与需求并行可提前做的设计工作有哪些？例如：数据库概念模型设计？基础数据字典设计？


二 需求调研的五个步骤


　　第一步：调研用户领域的组织结构、岗位设置、职责定义,从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。


　　第二步: 调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表、帐本等原始资料，分析物流、资金流、信息流三者的关系，以及如何用数据流来表示这三者的关系。


　　第三步: 对调研的内容事先准备,针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。


　　第四步: 对与用户沟通的情况及时总结归纳,整理调研结果,找出新的疑点，初步构成需求基线。


　　第五步: 若基线符合要求，则需求分析完毕。反之返回到第一步或第二或第三步,如此循环多次，直到需要分析使双方满意为止。


三 需求获取的重点


　　在对具体业务进行调研时需把握的重点有以下几个:


(1) 平均频度


　　业务发生的频繁程度,即在单位时间(分钟,天,月,旬,年等)内发生的次数,这个数字可以是一个平均值或统计值。频度越高,数据量越大,对响应时间、易操作性等要求就越高,在数据存储时对大频度的业务或单据也要进行充分的考虑。


(2) 高峰期的频度


　　必须保证系统在高峰期的响应时间, 对系统进行测试时要模拟高峰期的业务频度。


(3) 单据上有哪些数据?每项数据的精度?计算生成方法?取值范围或限定?


　　单据上的内容也即单据的属性,它是进行数据结构设计的最基本的依据,数据的精度是定义数据库中字段长度的依据,计算生成方法是设计算法的依据,取值范围与计算生成方法是数据完整性检测的依据。


(4) 生成每张单据或报表的时间


　　减轻人员的工作量是采用新系统的一个目的,花费时间最多,处理方法最复杂的地方往往是系统最关键的地方,也是用户将来验收时最关心的地方。实际上有很多报表由于工作量相当大,用户没有足够的人力与时间来进行处理,这时他便想到了计算机。


(5) 单据或报表的来源,单据联数,每联用途,送交单位,送交时间


　　对来源与去向的追踪可以调查出各个业务,各个单据,各个报表, 各个部门之间的联系。


(6) 有哪些特殊情况? 在某个作业环节出错时通过何种途径进行弥补?


　　对于特殊情况的处理,体现了系统灵活性,但这其中也隐含着安全危机。用户领域中有很多"合理但不合法,不合理也不合法"的特殊情况,它们出现的机会比较少, 用户往往在调研时遗漏这些问题,需要调研人员挖掘出来,这些特殊情况有时是系统必须处理的。


　　当在某个作业环节用户出现失误时,手工系统有的采用正规的手续进行纠错,有的则相当随便,这些情况出现的概率也很小,但分析员可采用穷举的方法, 假定在每一个环节都出现失误,逐个环节询问用户的处理方法,防止遗漏。这些细节如果不调研清楚,往往会对系统产生深远的影响。


(7) 将来有何变化?


　　将来用户需求的变化是很正常的现象,如果仅仅着眼于现在,而不对将来有所考虑，系统的寿命便不会长久,对用户的投资是一种浪费,同时也会给开发商增加一些麻烦,故此要"防患于未然",将以后可能的变化考虑在内。


四 需求整理与表达的方法


　　采用穷举、归纳、抽象等方法。采用穷举的方法可以避免遗漏, 可通过列出各种情况的排列组合达到穷举的目地。采用归纳的方法可以使问题更加条理化, 可通过对各种情况进行综合分类达到归纳的目地。采用抽象的方法，可以发现问题的实质，抓住问题的主要矛盾，忽略其次要矛盾。


　　在整理时可以多种手段共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述( 对其他描述手段的一种补充)、表格(单据调查表,帐本调查表,业务调查表,报表调查表等)、图形等多种手段。


　　对与需求的描述可以从六方面来描述：


　　●组织结构与岗位定义
　　●业务流程
　　●处理规则
　　●数据项
　　●功能
　　●以及上述5个方面的关系


五 需求获取过程中的注意事项


　　●在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题。


　　在调研过程中要经过多次反复, 用户不一定理解这个过程,调查时要和用户讲清楚。


　　●调查前的准备工作要作好。


　　在每次和用户见面前，要准备好问题单，对问题进行合理的分类,安排提问的次序,并事先提供给用户，便于用户准备，以提高工作效率。减少用户的反感情绪。


　　●发问时以一人为主,其他人注意记录与查找问题。


　　●在用户讲解时,不要中断用户,使对方有充分的演说机会。


　　●对询问的问题要有记录。这样便于整理文档,也便于统计工作量。


　　●调研时可以IPO思想作为总体的主线。


　　在我们同用户接触时,最先也是最易于和用户交流的是他们的业务,即每天他们在干什么?流程基本一样:收到别人传来的单据报表,进行加工处理,再传给其他人。就这样"接受、处理、传出",如此循环,就象车间里的流水生产线。工厂中三个基本的部门:供应科、生产车间、销售科,也反映了"输入(INPUT)、处理(PROCESS)、输出(OUTPUT)"的基本思想，因而在调研时采用这种思想易于同客户交流。


　　● 注意交谈的技巧，并尽可能多的记住用户的姓名、职务、爱好等。


　　要在用户提供的单据中提炼出其中最本质的内容来。在调研开始、结束、中间疲老时可闲侃,拉近和用户的距离，和用户成为朋友。

[ozzzzzz]

我反对任何初学者去浏览51cmm 那里的东西似是而非 荒谬多于真知

首先我来说说我对需要的一些看法
1 需求是用户需要的而不是他们想要的
你一定不能迁就客户 不能把他们的所有要求都认为我们应该满足 你必须对他们的要求进行仔细的鉴别 保留那些你可以实现的而对客户确实有用的
2 你需要了解的是客户在做什么 而不是去了解客户要你做什么
你应该了解的是客户现在工作的方式 而不是他们认为他们应该工作的方式 其实这一点和1是紧密相关的
3 不要过分重视流程
流程这个东西非常重要 重要到我们很难给它一个确定的规范 因为这需要大量的研究和经验 我们没有这种能力 所以你主要应该了解的是流程中会出现的那些角色以及这些角色所作的事情 这样做的原因在于我们所面对的企业管理都在规范的过程中 而且企业发展的速度相当快 我们往往不可能有一个稳定的环境来做一个固定不变的流程
4 不可能会获得所谓完整的需求 去获得那些清晰的需求
需求是复杂的 由于客户对我们的要求更加多 所以我们不可能了解完全他们的想法和做法 我们只能够对他们认为重要的和我们认为可以实现想法和做法的作一个清晰的描述 如果你采取增量开发的方式 还可以逐次了解他们的不同需求 你应该明白 你对一个需求点的清晰分析 可以对你对别的需求点的分析起到促进作用
5 需求的表达必须是客户能够理解的语言 并且要得到客户的认可
你首先应该尽量建立一个名词表 来记录客户的各种名词 这些名词其实就是你分析模型的基础 不要用我们的技术语言去表述那些需求 用客户习惯的语言是必须的
6 不要去关心将来
客户往往会和你说 我们以后会怎么怎么样 并且很可能会把现实和幻想混为一谈 不要被种种假相迷惑 客户的想法很多都不会实现 就像我们的想法一样 多说都是没有意义的空想 没有必要为这些事情浪费我们和他们的时间和金钱 并且这些事情往往就是你项目失败的最主要原因

我在这里只是草草地说说我的一些想法 在实际工作中还有很多技巧 如果你需求我可以提供这方面的咨询 但是我希望你不要去看那些似是而非的文章 有百害而无一益

[free_card]

朋友：给你推荐个网站，会对你有帮助：http://www.sawin.com.cn/satech.asp?class=SA

[yesry]

老大，我要的是“需求”，不是“需求文档”！也不是“需求理论”！拜托拜托！

[termite]

www.21cmm.com