需求分析模板软件需求说明怎么写

需求分析内容

所谓"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。

可以说，“需求分析”就是确定要计算机“做什么”。

（1）需求分析报告的编写目的 （2）产品背景明细 （3）缩写及缩略语 本工程描述： （1）软件开发的目标： （2）应用范围：

项目需求分析怎么写

项目需求分析的概念　　需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。

（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。

需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；eptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

　　狭义上理解：需求分析指需求的分析、定义过程。

一、为什么要需求分析　　需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 　　需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务　　简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程　　需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 　　问题识别 　　就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标. 　　分析与综合 　　逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型). 　　制订规格说明书 　　即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交. 　　评审 　　对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

四、需求分析的方法　　需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论. 　　原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能. 　　原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发. 　　原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。

　　在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。

　　追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。

进化型属于这种策略.

需求分析实例

回答：海底行 神 10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。

从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。

Gause 和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。

客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。

需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。

一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。

与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。

直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。

尽量理解用户用于表述他们需求的思维过程。

充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。

流程图和决策树是描述这些逻辑决策途径的好方法。

在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。

如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。

如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。

当前的范围太小，以致不能提供一个令人满意的产品。

需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。

正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。

这样说虽然很简洁，但似乎过于简单化。

需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。

你可以使用假设“怎么做”来分类并改善你对用户需求的理解。

在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。

把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。

需求获取讨论会中如果参与者过多，就会减慢进度。

人数大致控制在5到7人是最好的。

这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。

相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。

这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。

最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。

没有一个简单、清楚的信号暗示你什么时候已完成需求获取。

当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。

你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。

1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。

用户总是按其重要性的顺序来确定使用实例的。

2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。

这些新的使用实例可能是你已获取的其它使用实例的可选过程。

3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。

4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。

5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。

以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。

所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。

用例在需求分析中的使用 多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。

Ivar Jacobson（1992）把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。

虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。

而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。

注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。

用例的重要功能是用画用例图的功能来鉴别和划分系统功能。

它把系统分成角色（actor）和用例（用例）。

角色(actor)表示系统用户能扮演的角色（role）。

这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。

它们必须能刺激系统部分并接收返回。

用例描述了当角色给系统特定的刺激时系统的活动。

这些活动被文本描述。

它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。

用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。

这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。

用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。

用例可以: · 用例捕获某些用户可见的需求，实现一个具体的用户目标。

· 用例由角色激活，并提供确切的值给角色。

· 用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。

在UML中，用例表示为一个椭圆。

角色是指用户在系统中所扮演的角色。

其图形化的表示是一个小人。

在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。

一个用户也可以扮演多种角色。

例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。

在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。

我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。

角色触发用例，并与用例进行信息交换。

单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。

对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。

需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。

例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。

一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。

因此，一个用例是相关的用法说明的集合，并且一个说明（scenario）是用例的实例。

这种关系就像是类和对象的关系。

在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基本过程，普通流，或“满意之路” (happy path)。

在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。

当这种交互结束时，执行者也达到了预期的目的。

在用例中的其它说明可以描述为可选过程(alternative coruse)。

可选过程也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。

在交互序列中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。

角色类和角色实例 软件产品最终是给一些用户来使用的，而用户之间的差异是非常大的。

造成差异的原因包括了对计算机的认知程度的不同，使用习惯的不同，在软件目标组织中所处的地位不同，地理位置不同，业务熟练程度不同。

不同的用户都有自己一系列的功能需求和非功能需求。

对电脑熟练程度不同的人可能就会有不同的要求，熟练程度低的用户可能希望有一个友好的界面，熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。

考虑到用户的差异性，将用户分类并研究用户类的行为特征是非常有必要的。

所以在做具体的需求之前，先将用户分局行为和特点进行分类，对于研究、收集用户的需求是非常有帮助的。

可以利用一个简单的表格列出一些原始的分类，然后不断的完善这个表格。

确认你的分类之间没有交集。

并充分描述用户分类的行为，目的，要求等。

在企业分析中，比较常见的分类可能包括，供应商，客户，部门等。

就像C++中的类和对象一样，我们把分析出的用户分类称为“角色类”，把实际的用户称为“角色实例”。

在得到用户分类之后，最重要的就是要选出用户代表，用户代表不仅仅是在需求阶段中参与项目，还必须对项目的全过程负责。

用户代表能够代表用户分类的需求。

抓住用户代表的需求就大致把握住了用户类的需求。

当然，需求分析还是需要在用户中做大规模的调查的，只是要把重点放在用户代表上。

确保和用户直接进行沟通！大家有没有玩过传话的游戏，可能看过。

一群人排成一列，一句话从排头挨个向后传，到最后，那句话已经是面目全非了。

所以，一定要保证项目组能够直接和用户接触。

对于和用户直接沟通这一点，一般的针对特定企业的应用系统当然是不成问题，可是如果是开发行业软件，和用户直接沟通就成为一件几乎是不可能的事情。

在这种情况下，一般有几种解决的办法： 做大规模的市场调查，针对你的目标市场做市场调查，并根据统计学的理论建立你的数学模型。

这部分的工作效果最好，其性质有些象一些游戏公司会发布一些Demo版的游戏。

可是对于一般的企业来说，这项工作费时费力，高昂的成本往往使大家知难而退。

我的意见是，方法是非常好的，但是可以采用折衷的办法，例如选取有代表性的企业，为特定企业制作一个较小的版本并收集反馈意见等。

这涉及到很多市场营销的内容，并不是我的专业所长，这里就不多弄斧了。

聘请行业专家，一个行业专家往往可以在项目需求方面发挥极为重要的作用。

一个行业专家往往都有大量的行业经验和行业的人际关系网络。

在产品的设计方面，这个行业专家提供很多宝贵的意见。

在目前很多的软件的开发过程中都采用了这种方式。

行业专家有两种：一种是在这个行业中有很深的资历，但是对软件技术并不熟悉；第二种是开发过同类软件的软件专家，这种人在开发同类软件过程中已经积累了大量的项目经验，并且具有软件开发的知识。

这种方式是获取需求的最好的方式。

分析对比同类软件，微软在开发Office、Visual Studio的时候，也是参照了Lotus和Borland的成熟产品。

这种方式的特点在于成本很低，比较适合和其他的方式配合使用。

但是，要注意自己有没有触犯专利法。

需求的冲突 有的时候，虽然已经将用户分类并选出了用户代表。

但是需求的来源众多，往往会发生需求之间自相矛盾的事情。

需求从四面八方收集来后，人们难以解决冲突，澄清模糊之处以及协调不一致之处。

某些人还要对不可避免要发生的范围问题单独作出决定。

在项目的早期阶段，你必须决定谁是需求问题的决策者。

如果不清楚谁有权并且有责任来作出决策，或者授权的个人不愿意或不能作出决策，那么决策者的角色将自然而然地落在开发者身上。

这是一个非常糟糕的选择，因为开发者通常没有足够多的信息和观点来作出业务上的决策。

在软件项目中，谁将对需求作出决策的问题并没有统一的正确答案。

分析员有时听从呼声高的或来自最高层人物的最大的需求。

即便使用用户代表这一手段，必须解决来自不同用户类的相冲突的需求。

通常，应尽可能由处于公司底层的人作出决策，因为他们与问题密切相关，并能得到关于这些问题的广泛信息。

如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。

了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于你决定哪一个用户类所占份额最大。

当开发者想象中的产品与客户需求冲突时，通常应该由客户作出决策。

然而，不要陷到“客户总是对的”的陷阱中去，对他们百依百顺。

现实中，客户并不总是对的。

客户总是持有自己的观点，开发者必须理解并尊重这一观点。

用例 在具体的需求过程中，有大的用例（业务用例），也有小的用例。

主要是由于用例的范围决定的。

用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。

它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。

如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和用例。

就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。

直到整个系统可以被清晰的了解为止。

为什么要采用这种分析方法呢？计算机系统除了在与外界系统、人员有一系列的交互，在系统内部也往往存在着复杂的交互。

因此，在系统建模时，除了描述系统与外界的交互，同时还要描述系统内部的交互。

传统的MIS系统中，系统与外界的交互较多。

典型的，如ATM取款机：存在着大量的用户与ATM，ATM与其它系统的交互。

而电信领域的系统，与外界的交互较少。

例如，系统的输入可能仅仅是从交换机上采集信息，然后由系统进行处理。

系统的复杂逻辑包含在系统内部处理的流程上，而非与外部系统的交互。

建模主要任务是表达系统内部的交互。

用例图适于表达交互，之所以上面使用了电信系统，是因为用例最早来自于Ericsson的交换机系统。

当时，还是Ericsson雇员的Jacobson初步建立了用例图的概念，并于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。

用例的概念是精确描述需求的重要武器，比较适合支持商业工程和需求分析。

随着用例的发展，用例被大量的用于对功能进行描述。

每个用例代表了系统与外部ACTOR的交互。

可以采取顺序图来表达用例的具体操作程序。

ACTOR用于确定系统的边界。

ACTOR、用例可以从不同的层次来描述信息。

采用该原则的原因有： 1. 需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。

2. 人的认知往往具有层次的特性。

从粗到细、从一般到特殊。

采用不同的层次来描述，适于认知的过程。

使用用例开发系统的一般过程 在开发过程的初始阶段，可以根据具体的项目特点，制订开发各个视图之间的关联原则，指导规范。

在开发的过程中，视图的组织原则应不断进行维护、更新。

识别ACTOR来识别系统与外界交互的实体。

ACTOR具有特定领域的特征，例如：交换机（采集系统）、97信息系统等。

在系统层次的ACTOR确定了系统的边界。

识别用例。

同ACTOR一样，用例具有不同层次。

对较为概括的USECASE，需要细化。

注：系统开发需要一定的规则来确定，如何来分解用例；可能基于原有系统的经验，或是参考现有资料。

当用例细化到可以被理解的层次。

需要基于用例进行下一步的开发。

如前面提到的，用例主要用来描述交互。

因此，存在交互的实体和交互的细节。

交互的实体采用类图来描述；而交互的细节，采用顺序图来描述。

当系统复杂到一定层次时，类图和顺序图可能不能足以描述其复杂程度。

在该情况下，需要使用状态图来辅助阐述。

状态图和顺序图之间使用事件联结在一起。

它们之间的一致性问题，目前UML和ROSE没有提供解决方案。

相对折衷的方法是使用事件的命名规范强制一致性。

可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。

用例是从用户的角度看待系统，而不是基于程序员的角度。

这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。

用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。

从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。

在Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。

这是立场不同导致的结果。

用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。

对他们来说，更重要的是要达到他的目的。

相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。

所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。

当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。

这个开发过程就是用例驱动的。

用例和用例文档 《软件需求》一书中提到了几种方法来确定用例： · 首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定用例而努力。

· 确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。

· 以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用例中的执行者，有可能从现在的功能需求说明中获得用例。

如果有些需求与用例不一致，就应考虑是否真的需要它们。

用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理那里收集需求。

用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。

分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。

基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。

在理论上，用例的结果集将包括所有合理的系统功能。

在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。

当使用用例进行需求获取时，应避免受不成熟的细节的影响。

在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。

如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。

你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。

向他们保证在开发过程中，将会详尽阐述他们的需求。

在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为用例。

然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。

虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。

建立用例文档。

在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们组织成用例文档。

使用诸如模板的技术能够提高你的速度和需求的复用性。

一个用例文档可以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。

虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大小而定。

把大量的时间花在用例的描述上是没有意义的。

用户需要的是一个软件系统，并不是一大堆的用例说明。

软件需求说明怎么写

如何写需求分析报告（软件需求说明书GB856T-88） 近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。

大概的总结了下，写到这里。

本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。

在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。

这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。

这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。

而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。

否则在项目后期就会比较难过了。

在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。

所以还是看情况来对待文档的深度和标准。

一、目录：?目录要用word的?“引用”—>”目录”，自动生成目录，一般都是要三级目录。

通常这部分基本都不需要改结构，直接更新页码即可。

二、内容部分。

?国家标准软件需求说明书G856T-88下载 1引言 1.1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。

（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。

+S系统的两句话概述。

+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果） 1.2背景 说明： a．??待开发的软件系统的名称； b．??本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； c．??该软件系统同其他系统或其他机构的基本的相互来往关系。

（这部分可以将a,b,c分为2部分，例子如下： 1.2.1项目概况 本需求分析报告所预期开发的软件系统是:S。

S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。

1.2.2任务分配 a.???????任务提出者：xxx b.???????软件开发者：xx c.???????产品使用者：xx d.???????文档编写者：xx e.???????预期产品使用者：xx ） 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

（这部分很简单，就是描述专业词汇，比如 1. XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。

2. Word2,?解释。

。

。

） 1.4参考资料 列出用得着的参考资料，如： a．??本项目的经核准的计划任务书或合同、上级机关的批文； b．??属于本项目的其他已发表的文件； c．??本文件中各处引用的文件、资料、包括所要用到的软件开发标准。

?列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

解释被开发软件与其他有关软件之间的关系。

如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。

如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

| （ 本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。

其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。

具体描述：B1，来完成B11功能；B2，来完成B22功能；?等等。

本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。

图 图1.?该系统的组成同其他各部分的联系和接口 ） 2.2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。

这些是软件设计工作的重要约束 （例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。

可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。

xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。

提供给这部分用户操作手册即可。

预期这部分使用者主要是来简单的xx操作。

维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。

?这部分用户主要是采用了本系统之后的后期工作维护者。

等等 ） 2.3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。

（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。

工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。

） 3需求规定 3.1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。

（例如： INPUT输入 PROCESS处理 OUTPUT输出 LOAD负载量 A 预处理,做怎样的动作， AA CC B BBBB Bb v C CCCC cc v 表一、xx模块IPO表 对IPO表的简单文字描述。

） 3.2对性能的规定 3.2.1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

（例如： Xx目标处理：1Byt–10M，包括左右边界值。

yy精度范围：…. ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。

） 3.2.2时间特性要求 说明对于该软件的时间特性要求，如对： a．??响应时间； b．??更新处理时间； c．??数据的转换和传送时间； d．??解题时间；等的要求。

(这部分只要一一列举就可以： 由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。

其次就是xx转换和存储的开销。

其具体时间特性要求，如下： a．??xx响应时间：xxms左右； b．??yy更新处理时间：yy； c．??zz数据的转换和传送时间：zz； d．??vv解题时间：vv。

等等 ) 3.2.3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．??操作方式上的变化； b．??运行环境的变化； c．??同其他软件的接口的变化； d．??精度和有效时限的变化； e．??计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

（这部分按列举来即可，?由于本模块第一目的是用于xxx，其次则是xxxx。

故本模块的灵活性在于实际应用者的不同。

当需求发生某些变化时，该软件对这些变化的适应能力。

具体情况如下： f．???操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。

g．??运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。

； h．??同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。

但接口的命名规则是统一的； i．???精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。

j．???计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。

等等 ） 3.3输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。

对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

（这部分可以把输入输出分为?3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。

XXX输出 数据名称：XXX输出数据 实际含义：用于XX,表示XXXX 数据类型：Character(字符串) 数据格式：XX 数据约束：由于xxx,，大小在xx以内 ） 3.4数据管理能力要求 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。

（ 根据实际系统要求列举即可 Name名称 Number数量 Size大小 Increase增长 词典xx xx xxxx 并行执行，其大小依据实际xx大文本而增长 ） 3.5故障处理要求 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

（包括软件压力，内存不足，硬件损坏等，这部分可以根据百度到其常见故障。

） 3.6其他专门要求 如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

（例如安全保密性：密钥更换等；?预期扩展：扩展兼容等；OS更换：Slackware转SUSE等 ） 4运行环境规定 4.1设备 列出运行该软件所需要的硬设备。

说明其中的新型设备及其专门功能，包括： a．??处理器型号及内存容量； b．??外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量； c．??输入及输出设备的型号和数量，联机或脱机； d．??数据通信设备的型号和数量； e．??功能键及其他专用硬件 （列举说明即可） 4.2支持软件 列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。

（操作系统和版本：xxxx 支撑环境和版本：xxxx 备用IDE环境和版本：xxxx 与该软件有关的软件组件：xxxx 后续可能扩展环境：xxxx ） 4.3接口 说明该软件同其他软件之间的接口、数据通信协议等。

(例如： a．用户和主程序调用接口(图中接口1)。

这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。

例如以xxxx方式调用DLL文件，以xxxx方式调用函数。

如下图2所示。

图2.软件接口调用图 b.xx接口(图中接口2)。

这里是一个xxx的接口调用过程。

xxxx ) 4.4控制 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

(例如： 下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下： 图3 .控制流程图 图3的具体说明情况如下表所示： Name模块名称 Method运行方式 Signal控制信号 Forward控制去向 主程序模块 运行框架 用户调用或运行 1.???????调用xx模块 2.???????调用xx方法 3.???????调用标准输出模块 xxx模块 xxx xxx调用 Xxx模块 ) 附录：?软件设计文档国家标准(GB8567–88)软件设计文档国家标准(GB8567–88)GB8567——88 操作手册（GB8567——88）.doc 数据库设计说明书（GB8567——88）.doc 测试分析报告（GB8567——88）.doc 数据要求说明书（GB856T——88）.doc 测试计划（GB8567——88）.doc 图1.doc 概要设计说明书（GB8567——88）.doc 文件给制实施规定的实例（GB8567-88）.doc 开发进度月报（GB8567——88）.doc 详细设计说明书（GB8567——88）.doc 可行性研究报告（GB8567——88）.doc 项目开发计划（GB856T——88）.doc 模块开发卷宗（GB8567——88）.doc 项目开发总结报告（GB8567——88）.doc 软件需求说明书（GB856T——88）.doc 用户手册（GB8567——88）.doc