需求分析概述

需求分析概述

在具体的研究需求分析之前，我们先了解一下软件工程这个概念。软件工程分为三个层次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的概念说明）。关键过程区域构成了软件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务：需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则，控制了每一个的关键过程区域。工具层就很好理解了，他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE。

可以看到需求分析的位置，但是事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层，同时也涉及到一些过程层的思想，至于工具层则不再我们的讨论之列，但是会提到一些很适合在需求分析时应用的工具，诸如Word、Excel、Visio等。

方法

需求分析都包括了哪些方法呢？这里列举出在《需求分析》一书中推荐的一些方法，

1. 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。

2. 创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。

3. 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

4. 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

5. 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

6. 创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

7. 使用质量功能调配，（QFD）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类：

期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备（Zultner 1993;Pardee 1996）。

记住一点，不要试图在你的项目中把这些方法都用上去，四个现代化并不是一夜就可以实现的。同样，尝试着使用你认为对你很有帮助的方法，确实收到效果之后，在考虑继续学习方法。因为上面提到的都是需求分析的大方法，事实上还有很多很多的方法可以采用，例如，采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。

业务建模

很多人都没有意识到业务需求阶段应该做些什么事情，实际上业务建模是最重要的一件事情。不要觉得业务建模这个词很深奥，让人模不着头脑。其实所有做过需求分析的人都做过业务建模，比如你了解企业的运作模式就是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。

业务建模的目的在于：

·了解目标组织（将要在其中部署系统的组织）的结构及机制。

·了解目标组织中当前存在的问题并确定改进的可能性。

·确保客户、最终用户和开发人员就目标组织达成共识。

·导出支持目标组织所需的业务需求。

上面的话是不是很抽象呢，其实没有什么复杂的：人和电脑是完全不同的思想（思维方式）。所以，原先适合人的业务流程对于计算机来说可不一定合适的，为了最大限度的利用计算机，必须要了解原先的业务流程并对此加易改造（流程自动化），当然这些动作需要得到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组，但是实际上，不论是部门级的MIS 系统，还是社会级的电子商务系统，都需要对业务流程进行改造，所不同的只是改造的程度。业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象（Common Business Object）（这个词我翻译的不好，如果大家有更好的翻译，请告诉我）。任何企业都有最基础的一些元素，例如银行的CBO就有帐户，制造业的CBO就有订单等。有一次我的一个在企业应用方面研究多年的朋友告诉我一个秘诀，他说，企业的CBO无非是4个：客户、员工、产品和供应商（银行的供应商应该称为同业）。其他的所有CBO都是在这四个CBO的基础上发展起来的。比如说CBO中客户和产品是多对多的关系，根据关系数据的理论，任何多对多的关系都可以拆分成多个一对多或一对一的关系。你就可以在这两个类之间引入订单类，客户和订单之间是一对多，订单和产品之间又是一对多，这样一个多对多的关系就拆分成两个一对多的关系，而新的订单类也就顺理成章的产生了。在订单类产生时，你可能还会加入一个关联类：业务员类。而业务员类又是从员工类继承下来的。所以呢，企业的四种CBO通过不同的组合，不同的关系，能够形成企业运作的许许多多的CBO。

CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业务流程，改进业务流程的定义，设计业务流程实现，改进角色和职责，研究流程自动化，开发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。

需求获取

需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。

需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。

需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着需求分析的整个阶段。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。

需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充（open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。

还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能” ,”当?时，将会发生什么”“你有没有曾经想过” ,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。

有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客户写出业务是如何实现的，客户十有八九无法完成。但是如果你尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会...”。客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。

需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下来，记录的同时还要做一定的整理。如果不这样做，那么你结束会议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。在座谈讨论之后，记下所讨论的条目(item)，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。

尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。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发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。用例和用例文档

《软件需求》一书中提到了几种方法来确定用例：

· 首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定用例而努力。

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

· 以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用例中的执行者，有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致，就应考虑是否真的需要它们。

用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理那里收集需求。用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者

和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。在理论上，用例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。

当使用用例进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为用例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。

建立用例文档。在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。

虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统，并不是一大堆的用例说明。

软件工程—系统需求分析

系统用例图 系统需求分析 1概述 随着社会的发展，学校的规模不断的扩大，日常教学活动中提取相关信息，以反映教学情况。传统的手工操作方式，易发生数据丢失，统计错误，劳动强度高，且速度慢。使用计算机可以高速，快捷地完成以上工作。在计算机联网后，数据在网上传递，可以实现数据共享，避免重复劳动，规范教学管理行为，从而提高了管理效率和水平。学籍管理信息系统以计算机为工具，通过对教务管理所需的信息管理，把管理人员从繁琐的数据计算处理中解脱出来，使其有更多的精力从事教务管理政策的研究实施，教学计划的制定执行和教学质量的监督检查，从而全面提高教学质量。 1.1 系统目标 软件开发的意图为便于学校的管理，方便查看有关学校及学生的情况。 如教务处对学生成绩的修改、删除、查找、添加等。 1.2现行组织机构及业务现状 在学籍管理中，需要从大量的日常教学活动中提取相关信息，以反映教学情况。传统的手工操作方式，易发生数据丢失，统计错误，劳动强度高，且速度慢。2用户需求 2.1 业务需求

1、使用范围 学生学籍管理等相关文件完成本科和专科学生学籍状况的系统管理（本科生用学年学分制，专科生用学年制）。 2、功能要求 基础数据管理：包括班级管理、课程管理、学期管理等功能。 学生管理： 成绩管理： 查询统计：包括成绩一览表、成绩分布图报告等功能。 3开发内容：开发一套学生成绩管理系统软件 采取的研究方法：采用面向对象的编程，结合网络和数据库技术，实现控制和管理。通过系统分析、需求分析、概要设计、详细设计、编写代码、软件测试、软件维护、经验方法总结等一系列实验方案，实验软件的开发。 4具体开发方案： 分六个阶段进行： 第一阶段：系统分析、需求收集和分析 这一阶段首先进行系统分析，分析确定系统的规模和范围，确定软件的总体要求以及所需要的硬件和支撑软件，确定待开发软件与外界的接口，根据用户的情况确定软件对操作的要求，以及待开发软件总体上的约束和限制，完善项目计划。在这之后，这一阶段的大部分时间将被用来进行需求收集和分析。向学校管理人员及学生了解情况，确定软件系统的综合要求，分析软件系统的数据要求，导出系统的逻辑模型，修正项目开发计划。采用结构化分析方法，生成数据流图、数据词典及加工逻辑说明。 第二阶段：概要设计 在这一阶段将确定软件系统的结构，对全局数据结构进行设计，进行模块划分，确定每个模块的功能接口以及模块间的调用关系。采用与结构化方法衔接的结构化设计方法，生成结构图及概念设计说明书。 第三阶段：详细设计 为每个模块设计实现的细节将成为这个阶段的主要任务，还要对局部数据结构进行设计。采用结构化设计方法。采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。使得程序具有良好的结构，增强程序的可读性。生成程序流程图及详细设计说明书。详细设计时，如果不满意，须回到概要设计中重新完善设计。 第四阶段：编写代码 这一阶段用来根据详细设计说明书编写代码。采用计算机语言编写。追求高质量的代码，生成源程序代码、内部文档。 第五阶段：软件测试 这将是一个很重要也将是一个很耗时间和精力的阶段。在这一阶段中将尽可能多地发现软件中的错误和缺陷。如果有错，还将退回到编码阶段进行调试。测试过程分为单元测试、集成测试和确认测试。 第六阶段： 完善各项文档及和报告，从整个开发过程和这些文档中总结经验和教训，罗列各种方法和技巧。

软件需求分析

软件需求分析 目录 1．引言 1.1项目名称 1.2编写目的 1.3开发背景 2．任务概述 2.1目标 2.1.2 应用目标 2.2运行环境 3. 数据描述 4.功能要求 4.1功能划分 4.2功能描述 5.性能要求 5.1数据精确 5.2时间特性 5.3适应性 6.运行需求 6.1用户界面 6.2硬件接口 6.3软件接口

6．4故障处理 7.其他要求 8.实现代码（部分） 9.个人感想 1．引言 1．1项目名称： 制作一个财务管理系统 1．2编写目的： 编写财务管理系统需求分析的目的是明确所开发的软件的功能、性能、界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，方便开发工作和测试工作。现代企业围绕提高经济效益而进行财务管理所要达到的目的，是评价企业财务活动是否合理的标准。国内外关于财务管理目标的观点众多，但影响较广的主要以下几种观点：企业利润最大化、股东财富最大化、投资报酬率最大化，资本配置最优化。 1．3开发背景： 随着现代社会的快速发展，各个企业公司在多方面都不断地创新与提高，财务管理作为整个公司运筹的重要组成部分之一，因此大力发展财务管理很有必要，怎样合理而有效的提高财务管理水平和工作效率--已成为企业亟需解决的问题。 为帮助企业更好的实现信息化管理，各个公司成功地推出了适应现代社会发展的财务管理软件，大大提高了企业的管理水平和工作效率，使企业能够从容面对激烈的市场竟争。

2．任务概述 2．1目标 2. 1.1开发目标 财务系统用于让各地市、厅局等单位或部门等的各项与财务有关的资料的维护，同时提供良好的各项资产的管理。 2. 1.2应用目标 项目的目标是实现对各个部门的财务信息的分层次管理，可以对管理人员设置角色，实现对不同部门，不同操作权限的设置。 2．2运行环境 ?Windows xp操作系统 ?MyEclipse 3．数据描述 共有1个表，分别为通讯录管理系统的数据库，财务上包括姓名、职位、工资等字段 4．功能要求 4．1功能划分 本系统有以下功能模块： 1）登陆模块 2）数据输入功能 3）数据显示功能 4）查询功能 5）修改功能

做好软件需求分析的重要性

做好软件需求分析的重要性 需求开发没有做好会出现什么后果？需求问题的代价？需求分析如何做？为什么要做？ 首先来看下需求问题产生的代价模型： 需求问题的代价 在需求阶段消除问题的代价最小，而如果需求问题等到产品发布出去后才发现的话，那修复的成本就会N倍的增加。 不合格的需求分析： 1、没有足够的用户参与； 2、忽略了用户分类； 3、模棱两可的需求； 4、不必要的特性； 5、自我猜测的需求； 6、过于简单的规格说明； 7、用户需求的不断增加； 不合格的需求很多很多，很难说出所有，但需求分析没有做肯定会有影响。 需求没有做好的后果一般会有下列现象： 1、浪费时间和资源来满足用户并不需要的需求（过度实现一些功能）； 2、开发出来的产品技术上先进，但不满足用户需求； 3、总是需要比较长的时间来达成对产品设计的共识； 4、在产品设计，开发和测试工作中对于用户需求的解释不一致； 5、员工会厌倦因需求不断被重新解释而导致的返工； 6、未说明的或不正确的需求会导致员工与用户间的不满； 7、不稳定的产品，用户的不满意对我们未来的市场造成损失； 8、浪费时间，增加成本，使得在一些投标的项目中不能低价； 从上面2方面可以看出，需求没有做好，对后续产品来说是巨大的灾害，也可以说需求是源头，也是站在统领的位置上，那么如何来做好需求分析这块呢？首先了解下，为什么要做需求分析，什么是需求分析，需求分析有哪些方面。 为什么要做需求分析，从上面2个方面就可以看出做好需求分析的必要性，再具体一点： 1、“决策性”——要不要做这个产品，通过对市场需求的分析来决策项目是否需要立项； 2、“方向性”——良好的需求分析可以对项目人员明确方向，让项目成员知道下面应该如何实施； 3、“策略性”——既然知道了为什么要做需求分析，就需要了解什么是需求分析，及如何做。需求分析并不是简单的对与错，比如说做一个产品，“做技术最先进的软件，还是做最好卖的软件”，这个需求有错吗，没有，只能说需要从不同的地方去考虑，去定位。 “ 需求分析”不代表“用户要求什么就是什么”也不代表“我们能做什么就做什么”，做为需求人员，在进行需求分析的时候，首先应该明白用户的需求，然后再加上自己的分析处理过程，知道哪些我们现在能做，哪些我们做不了，哪些我们咬咬牙齿能做，需求人员在做需求分析的时候不能一味的成为客户的传话筒，要有自己的分析。

软件开发需求分析报告

需求分析报告 1.引言 1.1目的 需求，指的是系统提供的能力必须遵从的条件，一个系统能否达到预期目标，系统需求做的好坏起着决定性作用，因此，他无疑是该平台开发过程中的重要一环。按照传统的软件工程理论，需求分析的目标就是确定要干什么，而不是怎么干，按照统一软件过程的理论（RUP理论），该平台的需求分析就是要致力于高效的正确的开发系统。必须足够详细的描述出系统需求，同时也要详细的描述系统必须达到的条件或实现的功能，使得用户就系统产生的问题一致。 本章将要对”基于教学POI的校园公共服务平台设计与开发”的需求进行分析,再此基础上将会对系统的各个功能进行建模,并且给出模型模型描述的图例序列图等模型。建立系统目标和需要解决的问题。 1.2背景 本设计将对基于教学POI的校园公共服务平台设计与开发进行详细的需求分析；基于教学POI的校园公共服务平台设计在兴趣点软件或APP中属于较为新颖贴近学生生活与教学内容的软件在这方面有大量的资源可循但是并没有与之相关的软件。作为本次软件工程设计的需求总体分析我们需要在POI、教学以及手机软件开发进行基本的融会贯通。 1.3术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 POI信息平台系统的建立,最直接的提供了非常好的查询管理平台,极大的方便了学生的查询教学点\课程等方案的选择,为学生教师等提供了海量的便利教学信息;学生再也不用考虑担心自己找不到有疑问而大费精力. 通过对用户需求分析以及POI流程研究我们应该解决以下问题 在APP中搜索到正确的\合理的POI信息; POI信息的充分展现,包括地图展示并标记POI点的特殊标记;

软件需求分析重点-

软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11） 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14） 从产品的实际用户处收集需求这一过程是不可替代的。（18） 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（19） 要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20）不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。（22） 需求审阅是最有价值的保证软件质量的活动之一。（25） 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。（25） 不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。（26） 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）为每类用户选择代言人（31）

观察用户工作的过程（31） 跨项目重用需求（32） 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37）38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。（38） 第4 章需求分析员 相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。（42） 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44） 需求分析员必须研究可能出错的情形。（44） 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62） 项目伊始就应确定谁来担任问题的决策人。（72） 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75） 需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。 要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。 在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）

软件需求分析报告实例

需求分析说明书 １．引言...................................................................................................... 错误!未定义书签。 １.1 编写目的?错误!未定义书签。 1.2 项目风险 ............................................................................................... 错误!未定义书签。 1.3 预期读者和阅读建议 ........................................................................... 错误!未定义书签。 1.４产品范围.............................................................................................. 错误!未定义书签。 1.5参考文献?5 ２. 系统总体概述?错误!未定义书签。 2．1 目标 .................................................................................................... 错误!未定义书签。 2.2用户类和特性 ..................................................................................... 错误!未定义书签。 ２．3 运行环境?错误!未定义书签。 ２．３.1 硬件环境...................................................................................... 错误!未定义书签。 ２．3．２软件环境?错误!未定义书签。 2.4 设计和实现上的限制?错误!未定义书签。 2.5 假设和约束(依赖）?错误!未定义书签。 ２．5.1 产品的SEＯ排名 .......................................................................... 错误!未定义书签。 2.5.3系统的安全.......................................................................................... 错误!未定义书签。 3. 外部接口需求?错误!未定义书签。 3.１用户界面?错误!未定义书签。 3.2 硬件接口 ............................................................................................... 错误!未定义书签。 ３.3 软件接口.............................................................................................. 错误!未定义书签。 3.4 通讯接口?错误!未定义书签。 ４．系统特性................................................................................................. 错误!未定义书签。 ４.1 说明和优先级...................................................................................... 错误!未定义书签。 ４.2激励／响应序列 (9) 4.3 功能需求?错误!未定义书签。 4.4功能详述 ............................................................................................. 错误!未定义书签。 4.4.１以使用软件的汽车用户为例：?错误!未定义书签。 ５. 其它非功能需求........................................................................................ 错误!未定义书签。 ５.1性能需求?错误!未定义书签。 ５．2 安全措施需求................................................................................... 错误!未定义书签。 ５．3 安全性需求 (12) 5.4 操作需求 ............................................................................................... 错误!未定义书签。 ５．5软件质量属性................................................................................. 错误!未定义书签。 5.6 业务规则?错误!未定义书签。 ５.7 用户文档.............................................................................................. 错误!未定义书签。 6. 词汇表.......................................................................................................... 错误!未定义书签。 6.１ＳＳＨ?错误!未定义书签。

软件工程系统可行性分析和需求分析

个人承担任务 任务说明： 此次软件工程设计，我主要承担以下任务： 需求分析和可行性分析（根据设计题目进行问题定义，探讨可行性，再对系统进行需求分析等）。 任务内容： 1.可行性分析： ⑴问题定义 各高校传统的勤工助学岗位管理管理模式也越来越不能满足现代教育发展的需要。对于一个有着上百号勤工学生的学校来说，用手工管理这些学生信息还有岗位以及津贴，是一项非常繁琐的工作，而相应的岗位人员查询、津贴签领历史记录查询等，其工作量都让人望而生畏，而且还极易出错，同时也浪费纸。所以我们提出了开发高校勤工助学管理系统，将勤工学生基本信息管理、岗位人员管理、津贴统计等功能进行统一管理，为各高校实现勤工助学岗位信息化管理提供有效工具。 ⑵技术可行性 本系统采用B/S模式开发。B/S（Browser/Server，浏览器/服务器）模式又称B/S结构。B/S模式是指在TCP/IP的支持下，以HTTP为传输协议，客户端通过Browser访问Web服务器以及与之相连的后台数据库的技术及体系结构。它由浏览器、Web服务器、应用服务器和数据库服务器组成。客户端的浏览器通过URL 访问Web服务器，Web服务器请求数据库服务器，并将获得的结果以HTML形式返回客户端浏览器。它是随着Internet技术的兴起，对C/S模式应用的扩展。在这种结构下，用户工作界面是通过IE浏览器来实现的。相较于C/S模式的系统升级维护复杂来说，B/S模式最大的好处是运行维护比较简便，能实现不同的

人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据。另外，B/S还便于面向广大未知用户使用，因为只要电脑安装了IE，经过一定的设置，就都可以使用，如建立企业网站发布信息。 ⑶经济可行性 本系统开发成本低，对开发者设备要求不高，数据库采用免费开源的Oracle 数据库。由于是B/S模式，所以对用户软硬件要求要求也很低。 2.需求分析 ⑴系统运行环境硬件要求 硬件设备设计是根据信息系统的设计需求，确定信息系统物理设备方案，所设计的硬件设备方案在能够充分满足信息系统功能需求的前提下，还应满足系统的效率、可靠性、安全性和适应性等性能要求，并具有较高的性价比。根据前面的需求分析，我们得出本系统理想的环境当然是配置较高最好，实际操作中硬件平台如下： 硬件环境(访问者)：建议用户在允许的情况下采用较高配置硬件资源。 硬件环境(开发者)：Intel五代处理器，4G内存，80G磁盘空间。 ⑵系统运行环境软件要求 操作系统是计算机系统中最重要的系统软件，目前在微机上使用的桌面操作系统有Windows XP/7/8/10等，本系统在Windows 10操作系统下进行开发，可向下兼容以运行于前面所列举的各种操作系统，但建议使用Windows XP以上系统。 支撑软件是协助人们开发和维护软件的工具和环境软件，包括编辑程序，数据库系统，集成开发环境等，本系统的支撑软件如下： 1、数据库管理系统（DBMS）：为了对数据库实施集中管理，同时并发的处理多个客户机发来的数据处理要求，我们选用Oracle数据库管理系统。 2、动态网页技术：在这里我们使用JSP(Java Server Pages)来建立系统，编译软件使用myeclipse10。 ⑶系统功能需求 所有学生都可以登录系统申请对外开放的岗位，申请时需要填写相关信息。

需求分析、概要设计、详细设计的标准格式.doc

需求分析，概要设计，详细设计的标准格式 一、开发计划 （一）引言 1、目的 说明编制开发计划的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 （二）概述 1、工作内容 2、主要参加人员 3、成果 列出要提交给用户的程序文件、文档或服务的名称，及非移交 成果的名称。 4、完成的最迟期限 （三）实施计划 1、任务的分解及人员分工 列出各项任务及其负责人和主要参加人员。 2、进度 列出各任务的开始日期和完成日期。 3、关键问题 列出影响整个开发项目的关键问题，技术难度、风险及处理方 案。 （四）支持条件 1、计算机系统支持 2、需要由用户承担 二、需求分析说明书 （一）引言 1、目的 说明编制需求分析说明书的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 （二）概述 1、目标 说明本项软件开发意图、应用目标、作用范围等，以及所开发的软件与其它软件的关系。

2、用户特点 列出使用本软件的用户类型、特点、其教育程度和技术特长。 3、约束和假定 列出本软件开发工作的假定和约束。 （三）需求规定 1、对功能的规定 根据功能模型逐项说明本软件各项功能的详细需求。 列出完成各项功能所需输入，处理，输出及所需控制等。 2、对性能的规定 包括精度、时间特性要求、灵活性。 3、数据要求 数据分为静态数据和动态数据两类。 静态数据是指在程序运行过程中一般不改变的数据； 动态数据是指在运行中发生变化、需要输入输出的数据。 （1）数据描述 （2）数据采集 （3）输入输出要求 （4）其它要求 （四）运行环境规定 （1）硬件 包括处理机、网络、输入输出设备及其它设备。 （2）软件 列出支持软件。 （3）接口 包括必要的硬件接口、软件接口、通讯接口等。 （五）关于不可能实现的用户要求的说明 三、概要设计说明书 （一）引言 1、目的 说明编制概要设计说明书目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 （二）总体设计 1、需求规定 简述本系统的主要功能、性能等要求。 详见需求分析说明书。 2、运行环境 简述本系统的运行环境规定。 详见需求分析说明书。

软件工程需求分析和概要设计SA实验实验报告

软件工程需求分析和概 要设计S A实验实验报 告 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】

需求分析和概要设计实验报告 一．实验目的 1. 理解结构化分析和设计的软件工程范型； 2. 能运用常用的工具建立简单系统的分析模型和设计模型。 二．实验内容 图书管理系统的分析和设计。主要完成借书、还书、图书预定、图书查阅和图书管理等功能。要求建立系统的需求模型：DFD(data flow diagram)。 功能需求描述： 1. 借阅者可以通过网络查询书籍信息和预定书籍。 2. 借阅者能够借阅书籍和还书。 3. 图书管理员能够处理借阅者的借阅和还书请求，以及处理预定图书。三．实验结果 1.图书管理员处理借书第一层 图书管理员处理借书第二层 2.图书管理员处理还书第一层 3.图书管理员处理预定图书第一层 图书管理员处理预定图书第二层 四．实验分析 在本次实验中，我主要画出了图书管理员处理借书、还书以及预定图书的数据流程图。这是一个我们都很熟悉的环境，因此我们分析起来相对的会容易些，思路也会更加的清晰，在这个系统中，通过稍加细致的分析，我们可以了解到：

1. 图书管理员处理借书的时候，其主要过程是，先扫描读者信息，确认读者的合法性。接着，处理读者欲借阅的书。再接着，处理借书过程，同时修改读者和图书的有关信息。最后，系统将有关的信息反馈给我们的读者。 2. 图书管理员处理还书的时候，其过程相对的简单一些，只需直接处理读者欲还的书。同时修改读者和图书的有关信息。最后，系统将有关的信息反馈给我们的读者。 3. 图书管理员处理图书预定的时候，其主要过程是，先扫描读者信息，确认读者的合法性。接着，处理读者欲预定的书。再接着，处理预定图书过程，同时修改读者和图书的有关信息。最后，系统将有关的信息反馈给我们的读者。 在对这样的过程进行了分析后，再画数据流程图也就显得容易很多了。 通过本次的实验，我对数据流程图的重要性有了更加深刻的认识，数据流程图在我们设计系统过程中所扮演的角色是多么的重要，试想，如果一个系统在设计的过程中，不使用图的方式，而是将其用文字语言进行描述，这会是一个怎么样的情景。图的作用就是使我们对知识的理解非常的形象，易懂。一个非常复杂的问题，若是通过图形的方式向我们展示的话，会收到意想不到的结果。

软件开发需求文档

1. 引言 引言是对这份软件系统详细设计报告的概览，是为了帮助阅读者了解这份文档如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件系统详细设计报告是基于哪份软件产品需求分析报告、哪份软件产品概要设计报告和哪份软件产品数据库设计说明书(如果该软件产品需要数据库支持)编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统详细设计报告详尽说明了该软件产品的编码结构，从而对该软件产品的物理组成进行准确的描述。 如果这份软件系统详细设计报告只与整个系统的某一部分有关系，那么只定义软件系统详细设计报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种编写约定。编写约定应该包括：●部件编号方式； ●界面编号方式； ●命名规范： ●等等。 1.4 预期读者和阅读建议 列举本软件系统详细设计报告所针对的各种不同的预期读者，例如，可能的读者包括： ●开发人员； ●项目经理； ●测试人员； ●文档编写人员； ●等等。 描述文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。

1.5 参考资料 列举编写软件系统详细设计报告时所用到的参考文献及资料，可能包括： ●本项目的合同书； ●上级机关有关本项目的批文； ●本项目已经批准的计划任务书； ●用户界面风格指导； ●开发本项目时所要用到的标难； ●系统规格需求说明； ●使用实例文档； ●属于本项目的其它己发表文件； ●本软件系统详细设计报告中所引用的文件、资料； ●相关软件系统详细设计报告； ●等等。 为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：●标题名称； ●作者或者合同签约者； ●文件编号或者版本号； ●发表日期或者签约日期； ●出版单位或者资料来源。 2. 支撑环境 2.1 数据库管理系统 描述数据库管理系统、以及安装配置情况，需要描述的内容可能包括： ●产品名称以及发行厂商 这里的产品名称指的是数据库发行厂商发布产品时公布的正式商品名称，不应该使用别名、简称、研发代号等非正式名称，以免混淆；同样的道理，发行厂商的名称也应该使用正式名称。 ●版本号 数据库管理系统的准确版本号，必须按产品的实际情况描述到最细节的版本号。 ●补丁包版本号 描述实际上将要使用的数据库管理系统补丁包的版本号，必须注意，在某些情况下该版本号不一定是最新的版本号。 ●语言或代码集 对于只支持一种语言或者一个代码集的数据库管理系统来说，该项描述不具意义。对于支持多种语言或者多个代码集的数据库管理系统来说，该项描述指的是实际使用的语言或者代码集。 ●安装位置 描述数据库管理系统的实际安装位置，应该分别对管理系统安缺位置和数据存放位置进行描述，应该指明服务器名和安装卷号(盘号)。对于分布式数据库，必须分别描述每一个数据

需求分析说明书、详细设计说明书、概要设计说明书样例

以下是需求分析说明书、详细设计说明书、概要设计说明书样例 需要详细资料的去 https://www.wendangku.net/doc/4b16415307.html,/BBS/view.asp?ID={CA9329C0-93C5-4417-9170-452FF61E8C DB}&page=1下载 XX系统概要设计说明书 目录 1. 文档介绍1 1.1 文档目的1 1.2 文档范围1 1.3 读者对象1 1.4 参考文献1 1.5 术语与缩写解释1 2. 系统概述2 3. 设计约束2 3.1需求约束2 3.2隐含约束2 4. 设计策略3 4.1扩展策略3

4.2复用策略3 4.3折衷策略3 5．系统总体结构3 5.1、系统总体结构3 5.2、子系统功能及接口4 6. 子系统的结构与功能5 6.1、TERMSERV 5 7. 功能需求追溯5 8. 环境的配置5 9．其它6 附录 6 A、与主机接口6 B、与终端接口6 1. 文档介绍 1.1 文档目的 编写该文档的目的在于从总体设计的角度明确xxxx系统的功能和处理模式，明确与银联的接口，使系

统开发人员和产品管理人员明确产品功能，可以有针对性的进行系统开发、测试、验收等各方面的工作。 1.2 文档范围 1.3 读者对象 该文档的读者为用户代表、软件分析人员、开发管理人员和测试人员。 1.4 参考文献 《xxxx系统需求说明书》 1.5 术语与缩写解释 无 2. 系统概述 XX系统是以触摸屏为主要交互工具，帮助用户以自助方式做业务查询。本系统的主要功能包括：话费 查询、新业务介绍、网点分布查询、自助终端分布查询、电信新闻、交易监控、设备维护和监控等。本系 统的设计目标是保证系统可以7*24小时安全、高效无故障运行；业务人员可以轻松完成设备和交易的监控 、管理工作；报表种类齐全，可以满足业务人员各种帐务需求。 3. 设计约束

需求分析方法主要步骤

1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。

软件需求分析报告(20200623061919)

***** 有限公司 ***软件需求分析报告 文件管理号：PD-000*** 版本号：第1版

目录 1. 概述 (2) 2?需求分析 (2) 2.1功能需求分析 (2) 2.2能力需求 (4) 2.3通讯需求 (4) 2.4接口需求 (5) 2.5用户界面需求 (5) 2.6对人为错误敏感的适用性工程要求和培训 (6) 2.7软件的操作和维护需求 (6) 2.8法规要求 (6) 2.9风险控制措施 (6) 2.10法规要求 (7) 2.11网络安全要求 (7)

1?概述 2?需求分析 2.1功能需求分析 软件分为六大功能模块：患者资料管理模块、状态检测模块、策略建立及管理模块、心理物理数据测量模块、软硬件接口控制模块、软件运行的参数设置模块。下面分别对六大模块进行需求分析。 2.1.1资料管理模块功能需求分析 2.1.2状态检测模块功能需求分析 2.1.3言语处理策略建立及管理模块功能需求分析

2.1.4心理物理数据测量模块功能需求分析 2.1.5软硬件接口控制模块功能需求分析

2.1.6软件运行的参数设置模块功能需求分析 22能力需求 一、物理特征 1）编码语言：C#编程语言 2）运行平台：Win XP/Vista/ 7/8 3）操作系统：Win dows 二、软件运行的计算机环境 1）硬件环境 * 处理器：英特尔1.6GHz及以上 * 硬盘：10GB及以上 * USB接口：USB 2.0及以上 2）存储容量：1GB及以上 3）处理单元：1GB及以上 三、升级软件的兼容性 兼容之前发布的旧软件版本。 2.3通讯需求

2.4接口需求 2.5用户界面需求 本小节包括软件的用户使用界面需要满足的外观指标，内容包括: 1）资料管理模块 2）状态检测模块 3）策略建立及管理模块 4）心理物理数据测量模块 5）软硬件接口控制模块 6）软件运行的参数设置模块 7）外观要求及其他要求 2.5.1资料管理模块要求： 1、患者的输入信息 1）必需：姓，名，出生日期，性别 2）可选：工作电话，手机号码，住址（街道，城市，省份，邮政编码），住宅电话，电子邮件，等。 2、设备信息

软件项目需求分析通用

1. 引言 目的 说明编写这份报告的目的，指出预期的读者。 背景 指出待开发的软件系统的名称；行业情况；本的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业着作、标准以及他们的网址。

术语 列出本报告中用到的专门术语的定义。 2. 任务概述 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。

3. 假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4. 需求规定 软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 对功能的一般性规定 本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。 对性能的一般性规定 精度 说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。时间特性要求 说明对于该系统的时间特性要求。 灵活性

(需求分析+概要设计+详细设计)文档简单范例

软件开发文档 项目名： “通讯录” 版本： α测试版 作者： ccba 编写时间：2001-8-20 文档内容： 1 需求规格说明书 2 概要设计说明书 3 详细设计说明书 文档号IM00101 需求规格说明书 1、引言： 1.1 编写目的 本文档的编写是为了确定待开发软件的功能、性能、数据、界面的需求。 1.2 项目背景 “通讯录”软件是为了提供一种功能完备，易于操作、界面美观的优秀软件。该软件由蔡文亮单独开发完成。 1.3 定义 需求规格说明书采用参考资料②标准 1.4 参考资料 ①薛华成《管理信息系统（第三版）》清华大学出版社1999.5 ②郑人杰、殷人昆、陶永雷《实用软件工程（第二版）》清华大学出版社1997.4 ③周之英《现代软件工程（基本方法篇）》科学出版社 2000.1 2、功能需求 该软件由四个主功能模块和一个扩展功能模块构成，各功能模块中规定的均为软件的基本功能，在开发过程中，开发人员可根据实际情况在满足基本功能需求的前提下增加新功能，但必须详细编写相关文档。 2.1录入、修改功能模块 该功能块主要用于数据库的数据录入和修改，考虑到通讯录的实际需要，可以放松对数据库完整性结束的控制，但从减少数据库的角度来考

虑，不容许有完全相同的纪录出现（考虑的合并，相同的纪录项）。 2.2查询功能块 本功能模块是最重要的功能块，对通讯录的操作最主要部分就是查询操作。 本功能块要求有如下功能： 1）按数据库各个属性查询 2）按数据库各个属性之间的逻辑组合查询 如：查询名称为“鸭子”且年龄为20岁的详细情况 （SQL语句表示）SELECT * FROM MESSAGER WHERE NICKNAME=“鸭子” AND AGE=20 3）按某一属性的数值范围查询及其逻辑组 如：查询年龄在20至35岁间的详细情况 （SQL语句表示）SELECT * FROM MESSAGER WHERE AGE BETWEEN 20 AND 35 4）模糊查询 同时我们要求查询结果可以按用户要求的格式来显示，如：用户能调整显示属性的个数和组合。 2.3系统安全块 通讯录的信息是个人隐私，故在软件中加入必要的安全措施。主要有以下三点： 1）登录帐号和密码的管理 2）帐户权限的控制 3）对部分登录帐号隐藏部分内容 2.4系统设置块 本部分内容主要是对软件使用时一些设置使其更利于软件的使用：主要包括以下四个方面： 1）系统界面背景和色彩设置（模仿WINNAP） 2）闹铃功能开关，即实现朋友生日提醒功能 3）记录内容项（即数据库修改通讯录上的内容项） 4）历史记录，用户可以选择是否记录下何人何时使用过该软件 2.5扩展功能块 1）网络功能：通过OLE/COM接口的调用，实现E-mail软件调用。2）帮助文档的制作（On-line help）

软件需求分析复习要点

Software Engineering ? A discipline for the systematic production and maintenance of software developed by a team, which is ?fault-free, ?delivered on time, ?within budget, and ?satisfies the user’s needs ?GOAL: to produce a good quality software that is useful for people Properties of High quality software Defect free Meet user’s needs In time Within budget ?Communication: ?Project initiation, Requirements gathering ?Planning ?Estimating, Scheduling, Tracking ?Modeling ?Analysis & Specification ?Design ?Construction ?Code, testing ?Deployment ?Delivery, support, maintenance ?Requirements ?Definition 需求明确地规定解决用户问题的方法 ?Their Importance The set of requirements constitute a contract between the client and the software developer It should be written such that all stakeholders can understand what the system will do. It allows developer to map problem domain concepts to solution domain concepts