软件需求管理思考

软件需求管理思考（精选十篇）

软件需求管理思考 篇1

一般可以从用户角度 (即系统的外部行为) 和从开发者角度 (即系统的内部特性) 两个方面来阐述软件需求的定义。

从用户角度一般认为软件需求是“指明系统必须实现什么的规格说明”。它描述了系统的行为、特性或属性, 是在开发过程中对系统的约束。

从开发者角度可以认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。有些需求分析专家拓展了这个概念:“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。

从上面这些不同形式的定义不难发现:这些定义都强调产品是什么样的, 而并非产品是怎样设计和构造的。很难给软件需求一个准确的定义, 真正的“需求”实际上在客户的脑海里, 但一般情况下, 用户并不能描述自己的需要, 只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。

2 软件需求的类型

软件需求包括三个不同的层次:业务需求、用户需求和功能需求 (也包括非功能需求) 。

业务需求:反映了组织机构或客户对系统、产品高层次的目标要求, 它们在项目视图与范围文档中予以说明。

用户需求:文档描述了用户使用产品必须要完成的任务, 这在使用实例文档或方案脚本说明中予以说明。

功能需求和非功能需求:功能需求定义了开发人员必须实现的软件功能, 使得用户能完成他们的任务, 从而满足了业务需求。作为功能需求的补充, 软件需求规格说明还应包括非功能需求, 它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述, 从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

下面通过与文字处理系统相关的部分需求来说明需求的分类。业务需求是:“用户能有效地纠正文档中的拼写错误”, 该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时, 该拼写检查器还有许多功能需求, 如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换。

3 需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出软件需求规格说明, 所谓软件需求规格说明是软件应满足的全部需求, 并可以用文档的方式完整和精确地陈述这些需求, 包括所有面向用户、面向机器和其它软件系统的接口。这项工作非常关键, 一旦做错, 将最终会给系统带来极大损害, 并且以后再对它进行修改也极为困难。一个质量较高的软件需求规格说明通常应具备完整性、正确性、可行性、无二义性等基本特征。

4 需求分析过程

可把整个软件需求工程研究领域划分为需求开发和需求管理两部分。需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面:确定产品所期望的用户类别;获取每个用户类的需求;了解实际用户任务和目标以及这些任务所支持的业务需求;分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息;将系统级的需求分为几个子系统, 并将需求中的一部份分配给软件组件;了解相关质量属性的重要性;与客户商讨实施优先级的划分;将所收集的用户需求编写成文档和模型;评审需求规格说明, 确保对用户需求达到共同的理解与认识, 并在整个开发小组接受说明之前将问题都弄清楚。

需求管理需要建立并维护在软件工程中同客户达成的合同。这种合同都包含在编写的需求文档与模型中, 客户的接受仅是需求成功的一半, 开发人员也必须能够接受他们, 并真正把需求应用到产品中。通常的需求管理活动包括:定义需求基线 (迅速制定需求文档的主体) ;评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它;以某种可控制的方式将需求变更融入到项目中;使当前的项目计划与需求一致;估计变更需求所产生影响并在此基础上协商新的承诺, 并体现在项目解决方案上;让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪;在整个项目过程中跟踪需求状态及其变更情况。

以上几点说明是根据国内外的一些系统实施的相关成功经验, 进行了总结。

5 需求分析的过程中应注意的若干问题

不重视需求分析过程将会给项目的开发带来失败的风险, 为尽量减少项目风险, 在需求分析的过程中应注意以下几个问题带来的风险。

5.1 无足够用户参与

在实施项目时, 若无足够的用户参与, 系统人员获得的需求是片面的, 不完整的, 这样系统在需求之初就埋下风险。应让具有代表性的用户在项目早期直接参与到开发队伍中, 并一同经历整个开发过程。客户和开发人员应积极合作, 共同开发项目需求。有时开发人员觉得已经明白用户的需求了, 但是在某些情况下, 而客户并不太明白自己的真正需求。

5.2 用户需求的不断增加

在开发中若不断地补充需求, 项目就越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致, 这使得问题更难解决。实际上, 问题根源在于用户需求的改变和开发者对新需求所作的修改。

要想把需求变更范围控制到最小, 必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明, 并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程, 有助于所有风险承担者明白业务决策的合理性, 即为何进行某些变更, 相应消耗的时间、资源或特性上的折衷。

5.3 模棱两可的需求

模棱两可是需求规格说明中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明。

模棱两可的需求会使不同的风险承担者产生不同的期望, 它会使开发人员为错误问题而浪费时间, 并且使测试者与开发者所期望的不一致。处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释, 但每个评审人员都真正了解需求文档, 这样二义性就不会直到项目后期才被发现, 那时再发现的话会使得更正代价很大。

5.4 过于精简的规格说明

有时, 客户所作的规格说明过于精简, 仅涉及了产品概念上的内容, 然后让开发人员在项目进展中去完善, 结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。但在大多数情况下, 这会使开发人员在不正确的前提和有限的指导下工作, 也会使客户无法得到他们所设想的产品。

参考文献

企业管理软件的需求获取方法 篇2

任甲林

在需求工程中，需求获取阶段是和用户交往最多的一段时间, 而绝大部分用户是不懂得需求分析方法的，他们不知道怎样全面而又准确无误地表达自己的需求，因而对于需求分析人员来讲，需要掌握很好的方法与技巧，恰当地启发引导用户表达自己的需求，以便为项目的成功提供一个很好的基石。

一 需求获取的2个基本原则深入浅出

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

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

●该流程中是否存在不必要的环节？

●是否可以将决策的权力下放到作业部门？

●流程是否可以简化？

●是否可以省略一些环节？

●流程中的每个处理环节是否起到了增值的作用？

●哪些流程可以并行处理？

●与需求并行可提前做的设计工作有哪些？例如：数据库概念模型设计？基础数据字典设计？

二 需求调研的五个步骤

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

第二步: 调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表、帐本等原始资料，分析物流、资金流、信息流三者的关系，以及如何用数据流来表示这三者的关系。第三步: 对调研的内容事先准备,针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。

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

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

三 需求获取的重点

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

(1)平均频度

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

(2)高峰期的频度

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

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

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

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

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

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

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

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

对于特殊情况的处理,体现了系统灵活性,但这其中也隐含着安全危机。用户领域中有很多“合理但不合法,不合理也不合法”的特殊情况,它们出现的机会比较少, 用户往往在调研时遗漏这些问题,需要调研人员挖掘出来,这些特殊情况有时是系统必须处理的。当在某个作业环节用户出现失误时,手工系统有的采用正规的手续进行纠错,有的则相当随便,这些情况出现的概率也很小,但分析员可采用穷举的方法, 假定在每一个环节都出现失误,逐个环节询问用户的处理方法,防止遗漏。这些细节如果不调研清楚,往往会对系统产生深远的影响。

(7)将来有何变化?

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

四 需求整理与表达的方法

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

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

●业务流程

●处理规则

●数据项

●功能

●以及上述5个方面的关系

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

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

在调研过程中要经过多次反复, 用户不一定理解这个过程,调查时要和用户讲清楚。●调查前的准备工作要作好。

在每次和用户见面前，要准备好问题单，对问题进行合理的分类,安排提问的次序,并事先提供给用户，便于用户准备，以提高工作效率。减少用户的反感情绪。●发问时以一人为主,其他人注意记录与查找问题。

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

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

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

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

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

软件需求管理思考 篇3

【关键词】计算机 软件项目 需求分析

【中图分类号】TP311.52 【文献标识码】A 【文章编号】1672-5158（2013）04-0008-01

一、计算机软件项目管理涵义

项目是一件事情、一项独一无二的任务，也可以理解为是在一定的时间和一定的预算内所要达到的预期目的。具有明确的目标性、资源成本的约束性、项目实施的一次性、结果的不可逆转性以及创新性。

项目管理是指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。其对象是软件工程项目，和其他的项目管理相比有相当的特殊性。在计算机软件项目管理过程域中，主要包括：项目规划、立项管理、需求管理、项目监控、风险管理和结项管理等。

二、计算机软件项目管理中的需求分析内容

软件需求工程是计算机软件项目开发工作的一个重要源头，涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型；需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。

软件需求分析特别重要，在软件开发的过程中具有举足轻重的地位，但是我们常常会忽视两点：一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。

三、计算机软件项目管理中的需求分析目标

在计算机软件项目管理的实际工作中，管理者必须在每一项工作中，全面分析问题，正确评估任务，制定详细的计划表，从而实现既定目标。软件需求分析的主要实现目标包括：

1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整

性，促使用户在软件设计启动之前周密地、全面地思考软件需求；

2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；

3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据。

四、计算机软件项目管理中的需求分析的步骤方法

（一）获取用户需求。这是该阶段的一个最重要的任务，可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。首先，了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。其次对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。再次，需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：（1）对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；（2）将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”，（3）分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。最后，需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：（1）明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项），（2）使需求符合系统的整体目标；（3）保证需求项之间的一致性，解决需求项之间可能存在的冲突。

（二）分析用户需求。在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。可以通过审查业务流程、Demo界面和UML图，征求反馈意见。评审对软件系统运行时所处环境的要求。例如硬件、数据通信接口等等，在软件方面，采用什么支持系统软件运行（如操作系统、网络软件、数据库管理系统等）。从工作流程和数据流出发，逐步细化软件功能，找出系统各模块之间的联系、接口特性和客观限制，分析它们是否满足功能要求。针对可靠性、安全l生和扩展性评审，TCMS系统涉及公司内部最高机密，聘请第三方机构进行需求分析评审。

（三）文档编写。需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致。为此，我们还必须编写软件需求说明书，进一步理解业务需求，用户需求，功能需求，为设计、开发和测试以及产品相关人员的提供参考。软件需求说明书采用什么样的形式能够把功能描述清楚，如何让使用人员尽快了解产品的功能，采用什么样的编写方式，是软件需求分析人员需要考虑的问题。经过最近的摸索和积累，个人觉得编写需求文档不一定要长篇大论，要多用表格和流程图，并且至少包括以下内容：（1）目的。即使用场景描述，先用几句话简要概括做该软件是用来解决什么问题。不要一开始就描述功能，至少让设计人员大致了解该功能的使用目的。（2）涉众。软件是让谁来使用，列举所有可能使用到此功能的用户或者角色。（3）功能列表。菜单树，展示具体包含的子功能和上下级关系。由于不同类型用户关注的重点可能不同，所以最好应给出各子功能中对应的默认用户权限。（4）数据字典。列表描述功能涉及的字段名称、数据类型、取值范围、默认值、备注信息等。（5）流程图。描述用户使用的正常流程和异常流程，如果涉及到状态转换最好给出状态迁移图。（6）UI。展示所涉及界面布局和原型，不必描述具体提示内容信息，可以在字符串资源表中去定义。（7）相关影响。该功能对其他相关模块的影响，还有其他相关模块对此功能的影响。

（四）需求验证。与客户经过沟通或验证，会产生两种结果：一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。包括以下内容：（1）审查需求文档：对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。（2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。（3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。（4）确定合格的标准：确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。

参考文献：

[1]吴艳艳：周长伦：姜家轩：王春梅：许自国：：软件项目管理中的需求管理[J]：信息技术与信息化：2008年02期

[2]孙莉：：软件项目管理中的需求管理[J]：信息系统工程：2011年04期

基于软件开发的需求开发及需求管理 篇4

关键词：需求工程,需求开发,需求分析,需求管理

1 概述

需求工程在软件开发中是一个首当其冲的问题。如果没有一个清晰、完善的需求分析, 项目队伍或开发人员将为此付出不可估量的代价。有资料表明, 许多问题都是由于收集、编写、协商、修改软件需求过程中的失误而产生的, 诸如信息收集不全、交流不充分、文档不完善、需求不断变更等, 且有40%～60%的问题都是在需求阶段埋下的隐患。在软件规模不断扩大、应用领域不断拓展的今天, 软件开发的前期工作变得越来越重要。当然, 软件需求分析作为软件开发的第一步, 也是决定性的一步, 也就理所当然的左右了一个软件项目的成功与否。

2 需求工程一般模型

在讨论需求工程的一般模型时, 先来看下什么是需求工程。一般来讲, 需求工程就是指应用已证实有效的技术、方法进行需求分析, 确定客户需求, 帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科;它通过合适的工具和记号系统的描述待开发系统及其行为特征和相关约束, 形成需求文档, 并对用户不断变化的需求演进给予支持。需求工程可分为系统需求工程和软件需求工程。本文所要讨论的软件需求工程是一门分析并记录软件需求的学科, 整个软件需求工程研究领域可划分为需求开发和需求管理两部分, 如图1。

2.1 需求开发

需求开发一般包括需求获取、分析、编写文档、验证等阶段。

2.1.1 需求获取

需求获取是软件开发的第一步, 是通过调研, 获得清晰、准确的客户需求。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求, 分析者、开发者和客户就能探索出描述这些需求的多种解决方案。

需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境, 而这些问题与产品有关。对需求问题要进行全面考察, 不仅要考虑问题的功能需求方面, 也要考虑其非功能需求方面。所以, 需求获取是一个高度合作的活动, 并不是客户需求的简单拷贝。同时, 当进行需求获取时, 也应尽量避免受不成熟细节的影响。只有当这些细节被排除时, 才会使随后的设计过程畅通无阻。

2.1.2 需求分析

(1) 需求分析任务。

由于需求分析是软件开发的一个奠基性工作, 所以我们必须对它进行认真审视。需求分析阶段要完成具体明确的任务及就是最终形成一份开发方和用户认可或达成共识的需求规格说明书, 这也是软件开发中最为困难的部分—-即准确说明开发什么、系统必须做什么。当然, 最为困难的概念性工作便是编写出详细的技术需求, 这包括所有面向用户、面向机器和其它软件系统的接口。如果一旦做错, 将最终会给系统带来极大损害, 且以后再对它进行修改也非常困难。可以说需求文档在开发过程中起着指导作用。

(2) 需求分析过程。

需求分析的过程就是将收集到的调研信息加以处理并理解他们。

把调研信息分成不同的类型, 同时将客户需求同可能的软件需求相联系。然后将客户信息结构化, 编写成文档和示意图, 作为提交给让客户代表评审并纠正存在错误的一个书面文档。重复详述需求, 以确定用户目标和任务, 并把它作为使用实例。进行深入收集和分析, 消除任何冲突或不一致性, 拟定出详细的使用实例, 使其融合到必要的功能需求, 为编制测试用例作准备。

进行需求分析时, 尽量理解用户用于表述他们需求的思维过程, 充分研究用户执行任务时做出决策的过程, 并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。避免使用用户提供的需求细节, 因为会给随后的设计过程带来不不要的限制, 用周期性地检查需求获取, 以确保用户参与者将注意力集中在今天所讨论的话题适合的抽象层上。此外, 不可忽视非工程需求的描述, 它表明了系统的限制和用户对质量的期望。

为了更好和用户交流, 最初的屏幕构思有助于描述开发人员对需求的理解, 可以利用Visio来设计界面。如果项目开发周期允许, 可以开发原型来交流和确认。随后针对用户的需求说明细化用户界面设计, 有助于对需求达成共识, 为以后的设计工作带来便利。

(3) 需求分析方法。

通常的软件需求分析方法有三种:面向功能分析、面向对象分析、面向数据分析。

面向功能分析是最早的分析方法, 它将软件需求当做一颗倒栽的功能树, 从上到下, 功能由粗到细。其功能分析体现了自顶向下、逐步求精的思想, 适合于结构化分析、结构化设计、结构化编程等传统式软件工程思想。

面向对象分析, 也从系统的基本功能入手, 每一个功能对应一个对象, 然后将对象上升为类, 再用对象总线或对象框架将类组装起来, 用以表示用户需求。CASE工具Rational Rose用Use case来进行需求分析, 所有Use case的集合, 就是系统的需求。

面向数据分析, 就是面向元数据和中间数据分析, 对开发人员来讲, 就是要将这两类数据及其之间的关系弄透。

2.1.3 编写文档

需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议。协议综合了业务需求、用户需求和软件功能需求。开发人员必须编写从使用实例派生出的功能需求文档, 还要编写产品的非功能需求文档, 包括质量属性和外部接口需求。

一般可以用好的结构化和自然语言、建立图形化模型、编写形式化规格说明等方法编写文档。文档不仅是系统测试和用户文档的基础, 也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。而且作为产品需求的最终成果必须具有综合性:必须包括所有需求。开发者和客户不能作任何假设。

2.1.4 需求验证

再完成文档的编写后, 并不能说已经完成了需求开发阶段的工作。只有以结构化和可读性方式编写这些文档, 并由项目的风险承担者评审通过后, 各方面人员才能确信他们所赞同的需求是可靠的。其验证的手段主要有软件评审和软件测试, 在文档编写后, 必须对需求进行评审以验其质量。软件测试也是对需求的第二次验证。

需求验证主要围绕编写文档的质量特性展开, 这些质量特性包括正确性、无二义性、完整性、可验证性、一致性、可修改性和可跟踪性等。

2.1.5 需求分析原则

有资料表明:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求文档和不完善的需求分析是导致需求过程中软件成本估计极不准确的主要因素。所以, 开发人员一般应当遵循以下一些原则。

(1) 有足够用户参与 。

在实施项目时, 若无足够的用户参与, 系统人员获得的需求是片面的, 不完整的, 这样系统在需求之初就埋下风险。

(2) 控制需求变更范围 。

在开发中若不断地补充需求, 项目就越变越庞大以致超过其计划及预算范围。所以, 必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明, 并将此说明作为评价需求变更和新特性的参照框架, 以达到把需求变更范围控制到最小, 有利于减少因变更导致软件质量的下降。

(3) 确认需求。

模棱两可是需求规格说明中最为可怕的问题。模棱两可的需求会使不同的风险承担者产生不同的期望, 它会使开发人员为错误问题而浪费时间, 并且使测试者与开发者所期望的不一致。如果这种不一致性直到项目后期才被发现, 那时付出的代价将会很惨重。所以, 需求的确认非常重要。

(4) 不要画蛇添足。

指开发人员增加自己觉得一些用户欣赏但需求规格说明中并未涉及的新功能, 但往往这并不能获得用户的认可。开发人员应努力使功能简单易用, 而不要未经客户同意, 擅自脱离客户要求, 自作主张。

当然除了以上提到的, 还包括不要过于精简规格说明、不要忽略用户分类、要准确的调研、分析、计划等。

2.2 需求管理

软件需求的最大问题就是需求不断的变更, 同时也是软件开发之所以困难的主要根源, 因此有效的管理需求是项目成功的基础。而且, 管理问题是贯穿于整个软件开发周期中的。

需求管理是在工作进程中维持需求约定集成性和精确性的所有活动。一方面, 需求管理要保持软件需求与客户需求之间的一致性, 要保持软件开发过程中的其它系统元素以及活动与软件需求的一致性。另一方面, 软件需求是受控的, 也就是说在给定时间使用工作产品的版本是已知的 (版本控制) , 并且以受控的方式引进改革 (变更控制) 。需求管理的任务是分析变更影响并控制变更过程, 主要包括变更控制、版本控制和需求跟踪等活动。

2.2.1 需求变更控制

对大多数项目来说, 需求的改进是合理的且是不可避免的。新的开发技术和项目目标的调整等都可能产生需求的变更, 但是如果不对需求变更的范围加以控制, 将会使项目陷入混乱, 甚至导致软件开发的失败。Capers Jones曾在报告中声称需求变更对80%的管理信息系统和70%的军事软件项目造成风险, 因为迟到的需求变更会对已进行的工作有较大影响。

(1) 需求变更的影响分析。

需求变更贯穿于软件开发的全过程中, 不处理好需求变更, 将会障碍软件的开发。它包括影响软件质量及开发进度、影响文档和代码的一致性、影响开发者和用户的合作关系等。

(2) 处理需求变更的原则。

要正确的处理需求变更, 必须采用规范的变更管理过程。如下面提到的, 必须建立需求变更控制机制;增强系统对需求变更的应变能力;选择合适的客户经理;提高用户的认识水平;采用先进的需求管理工具等。

(3) 需求变更解决方案。

引起需求变化的主要原因有:未受控制的需求变更、遗漏的需求、与用户交流不够、编写文档考虑不周、低效的需求分析等。针对以上问题, 可以采用如图2的方案进行解决。

2.2.2 需求文档版本控制

版本控制是管理需求的一个必要方面, 它保证在需求文档中记录和反映所有的需求变化。需求文档的每一个版本都必须统一确定, 组内每个成员必须能够得到需求的当前版本, 需求变更应该及时通知到项目开发所涉及的人员。每一个公布的需求文档应该包括一个修正版本的历史状况, 即变更内容、变更日期、变更人姓名、变更原因等。

本文建议在经过每一次需求变更及确认后, 项目管理者可以给每一次变更的需求设定一个统一的版本号。每一次变更后, 版本就升级。这样可以方便、快速、有效的进行软件开发, 同时也随时可以查到客户新增的哪些功能。

2.2.3 需求跟踪

需求跟踪就是将需求与系统设计元素、编码、测试等阶段的工作成果与需求文档进行比较, 建立与维护“需求文档—设计文档—代码—测试用列”之间的一致性, 确保产品依据需求文档进行开发, 图3表示软件开发过程中需求的跟踪关系。当需求发生变化时, 使用需求跟踪可以确保不忽略每个受到影响的系统元素, 需求变更的准确实施可以降低由此带给项目的风险。

一个管理系统的需求跟踪通常应该满足:

①能够完整地定义需求之间的各种关系, 并提供可视化表示方式;

②在需求变更时, 系统能够按照所定义的需求跟踪链, 跟踪到所有受影响的需求。同时, 管理人员也需要进行需求状态跟踪, 以了解项目工程进行到了何种程度, 从而对项目进度进行控制。

2.2.4 需求管理工具

当然, 需求管理人员不可能用手工来管理软件开发, 还必须得用到一些管理工具。因为采用需求管理工具, 可以提高需求管理工作流程的自动化程度, 使需求管理可以在项目实施过程中得到有效的排行。

目前, 需求管理工具还是比较多的。例如, CA公司的CA-Super Project & Project Software、Development公司的Qwiknet Professional、Rational公司的Analyst Studio需求工作包等。需求跟踪工具有, LMSC公司的ARTS (The automated Requirement Traceability System) 、TOOR (Traceability of Object-Oriented Requirement) 、Remap系统、RETH和Radix工具等。

3 总结

软件开发人员应充分认识到需求工程在软件开发过程中的作用。如果没有一个准确、清晰的软件需求工程工作, 将给项目队伍或软件公司带来不可估量的损失。本文从需求工程的过程各阶段的作用来叙述, 讨论了以后研究的重点还应放在需求分析、需求管理问题的研究上。当然, 必须理论联系实际, 需求工程现状中另一明显的不足是理论解决方案通常是在对实际问题简化的基础上得到的, 理论研究和实践脱节。要获取需求突破, 改善需求工程的开发效率和质量, 主要的一点就是探索有效的解决途径, 缩小理论与应用之间的鸿沟, 使开发出的系统与应用领域相匹配。

参考文献

[1]曹伟.如何进行软件需求分析, 中国系统分析员, 2002 (3)

[2]Wiegers K E.陆丽娜, 王忠民, 王志敏等译, 北京:机械工业出版社, 2000

[3]黄怡强.浅谈软件开发需求阶段的主要任务, 中山大学学报论从, 2002, 22 (1)

[4]姬晓鹏等, 需求管理的一个系统解决方案[A].计算机工程, 2003.

[5]卢梅, 李明树等.软将需求工程—方法及工具评述[A].计算机研究与发展, 1999, 36 (11)

[6]刘小波等.软件系统需求变更影响分析及解决方案[A].华南理工大学学报 (自然科学版) , 2002, 30 (4)

软件工程项目需求管理研究论文 篇5

摘要:我国社会经济发展的同时，让信息系统也逐渐开始大范围使用，而软件研发是目前社会专业人士所积极研究的一个热点，但是，软件项目研究是有多种因素在其中进行影响的，需求管理在其中处于主导地位。基于此，本篇文章对软件工程项目的需求管理进行分析研究，依照软件工程项目的概念为根本，以笔者多年的实践经验为基础，对软件的需求开发以及需求管理这亮点进行分析概述，其本意就是通过此次论述，让同行能有一定的启发，从而更好的进行需求沟通，更好的进行软件项目开发，减少风险因素的发生。

关键词:需求工程;需求开发;需求管理;软件项目

一、软件项目需求管理的概念

软件项目的开发团队对客户的需要进行深度挖掘，采集，就是软件项目工程的根本，而对这些需要进行系统的跟踪管理，从而让这些需求得以实现，达到客户的预期目标就是整个需求管理的过程。软件需求的来源，就是所需客户的期望和需要，如果这些需要被逐渐的理清，详细的分析，最终形成一个合理的文档，能对软件产品要求进行阐述。

二、软件项目需求工程与管理

(一)软件需求的层次与组成

软件项目需求工程属于系统工程的一种，在进行开发的过程中，一般需求有四个层次需要。第一，原始问题。用户提出需要解决的问题(其中包括书面提出以及口头提出)，而这也是软件需求的根本。第二，用户需求。负责开发的团队使用图标、自然语言等方式所提出的，软件系统会提出相应的服务以及操作。第三，系统需求:这也是用户需求的另一种体现方式，可以按照软件原型给用户一个更好的直观体验，并且基于此继续进行下一步动作，一般情况下，软件都会选择水平原型，而需要相对复杂的则需要运用垂直原型。第四，软件设计描述:经过以上三个层次，就可以明白应当做什么，而这点就是需要告诉应当如何进行，这也是软件进行设计以及实现的根本所在。当上述的四个层次全部截止后，就可以进行下一步，就是对软件需求工程组成进行理解，对需求进行管理以及开发。

(二)需求分析

在进行需求开发的过程中需要对需求信息进行详细的分析，对其中的不足之处以及错误操作进行改善，并且将问题的要求确定，保证需求文档所反映出来的条件是用户所提出的条件，而这就叫做需求分析，一般情况下，需求分析的方法有很多，但是原型化方法最为常用，其他方法还有如动态分析法以及结构化方法等。一般情况下都是使用原型化方法，这种方法也是常识性的方法，这种方法操作简便，使用方便。(三)需求规格说明书在对用户的需求以及系统需求进行描述的过程中，就是需要需求规格说明书的参与。SRS不光是要对用户的真正需求进行反映，还需要尽量简洁，用简单的问题描绘出来，并且尽量使用基本词汇表当中的.语言，除此之外，还应当尽量保证其中的整体性，操作性以及验证性，只有如此，才能保证需求说明书的标准，才能让需求管理更加科学，更加合理。

(四)需求验证

为了可以保证SRS的准确性，需要进行需求验证，以便让质量特点能完美呈现，在此过程中，客户方面的决策，以及技术人员和业务人员共同进行，其主要目的有两点:第一保证了用户能明确的了解，SRS是否能够完全描述出他们的需求;第二是按照相关的文档，可以对提出相关需求的人员以及需求分析人员和测试人员等众多相关人员达成一个共识，并且让需求能固化，作为根本，控制用户在一般的需求方面也需要变更，验证的内容一般有:审查SRS，测试覆盖，产品验收标准等众多方面是否与用户需求相同，完善。

(五)需求捕获

对于需求工程来讲，需求捕获十分重要，是其中的主要部分，这对于开发工程团队来讲，可以通过需求捕获来了解用户通过软件系统需要完成的任务，经过整改之后可以对用户提出的相关问题以及要求进行改善，逐渐达到用户使用软件的目的，并且在此过程中逐渐运用相关的方式以及工具来满足用户提出的实际要求。实施需求捕获的前提要保证能确定好用户的类型，再寻找每一类型用户的交接决策人员，需求捕获的方式有多种，其中需要对用户单位的组织架构进行了解，及时与用户进行沟通，即使向用户发放调查问卷，对用户工作流转的文件等进行分析，并召开相关会议等。一般来讲，在需求捕获前期，需要管理人员制定基本词汇表，包括对流程的概括，这样既可以让用户有一个好的体验，让用户认可，对企业放心，另一方面还可以让用户更乐于交谈，并且帮助项目开发团队领略用户相关人员的意图。

三、需求管理

(一)变更管理

项目在进行实施的过程中，会一直有用户需求的存在，但是客户的需求不一定是绝对的，用户需求需要进行适量的变更、控制、进行正确的管理。而如何进行需求变更管理是需要考虑的一项问题。一方面需要进行关键性的变更，这点会影响整个项目的正常交付使用，而这种需求是需要给予满足的。另一方面，需要进行改良变更，这点不会影响系统的交付，但是，如果有不满意会让整个项目工作的价值有所改变。

(二)版本控制

在整个跟踪记录软件开发的过程中，版本控制都是一直存在，这包括了软件本身以及相关文档。按照版本控制要求，可以在空间上保证配置项的集中管理，解决相关问题，这点也是可以让版本具有一定的可回溯性，也是保证开发团队进行研发，提高开发效率的根本，同时这也是管理需求变更的一项固有手段。

四、结语

综上可见，本篇文章首先介绍了软件项目需求管理的概念，之后探讨了软件项目需求工程与管理问题，最后对需求管理进行了深入分析，以期能使相关人员更好地开展软件工程项目的需求管理工作。

参考文献:

[1]屠永江.基于项目需求工程理论的软件需求管理探析[J].计算机光盘软件与应用，(2):168.

[2]李虹，闫德恒.基于项目需求工程理论的软件需求管理浅析[J].中国科技信息，(16):92-93.

软件项目需求变更管理研究和实践 篇6

软件项目需求变更频繁,如果控制不好,很容易导致项目失败,本文作者通过一个案例场景对软件项目中遇到的问题进行分析和研究,结合在软件项目管理中的实践和体会,提出有效方法,用以处理软件项目管理过程中因需求变更引起的问题。

案例场景

某公司为一家软件企业,承接了一个电子商务平台项目,该项目组共16人,包括1名项目经理、1名技术经理、1名产品经理、1名项目经理助理、7名开发人员、2名UI人员、3名测试人员。

项目甲方业务发展迅速,需求变更频繁,需求由公司高层和业务部门提出,但所有需求必须由公司高层确认。

项目问题分析

1频繁的需求变更

变更的原因有以下几个:

(1)由于甲方是一家刚刚起步业务发展迅速的公司,随着业务发展电子商务平台需求频繁变更;

(2)甲方需求提出方包括各业务部门和公司高层。各业务部门根据业务发展不断提出需求,但不能确定需求是否开发,必须经过公司高层决定,但业务部门和高层之间沟通信息经常不对称,高层按照自己的理解确定需求,业务部门不敢提出异议,导致最终需求未必符合业务需要;

(3)公司高层提出需求只是框架需求,没有时间细化,产品经理根据自己的理解细化需求后,高层确认时不仔细看,但产品开发出来后又提出很多不同建议,导致开发完的产品需要不断完善。

2甲方和乙方开发周期有分歧

(1)甲方高层主导需求,新的想法非常多,想法出来后希望尽快看到结果,在开发周期上和开发方经常发生分歧,导致气氛逐渐不融洽;

(2)项目经理和甲方公司高层确定需求和开发周期时经常发生冲突,但迫于企业高层关系紧密,且企业高层要求和对方要搞好关系,所以不得不接受甲方高层提出的不合理开发周期,通常用赶工的方式进行长时间疲劳工作,造成项目团队对项目失去信心和积极性。

(3)不合理开发周期导致产品质量下降,甲方高层逐渐对开发团队不满,最后导致双方高层关系恶化。

综合以上分析,该项目具备了很多不健康项目现象,例如:需求不明确;需求变更频繁;进度要求紧;对项目风险管理薄弱等。

项目解决方案分析

针对项目中存在的以上问题,进行了分析和研究,可以判断,项目问题的症结主要在项目变更控制和沟通管理上。

1项目变更控制随意性比较强,变更控制没有流程,项目范围没有确定,需求交付成果评审没有控制。需求变更管理需要完善地方:

(1)对变更需求进行严格审核。对变更需求按照紧急性、影响性进行分类,然后安排处理的先后顺序。

(2)对变更的影响进行评估,并将评估结果和客户进行沟通确认。沟通内容包括变更引起的质量、成本、进度等方面的内容。首先从进度即开发周期上和客户确认,变更一般都会引起开发周期延长;然后从成本上,大的变更不仅影响开发周期,还需要增加人员或通过赶工完成;再就是从质量上,严格讲,如果重新评估开发周期和成本,客户能够接受,质量管理到位,变更不会引起产品质量下降,但如果前两个影响客户不能接受,开发方为了不放弃项目又硬接受不合理的周期和成本,很容易造成质量下降。

2沟通管理上需要从以下几个方面进行改进:

(1)内部沟通要注意方式方法。和甲方沟通过程中的不满不要在开发团队中散布,应该适度表达,以免整个团队对项目失去信心和积极性。

(2)采用对方能接受的沟通方式。由于对方是一个非技术人员,且是一个公司高层,需求容易变化,且为框架需求,所以要多用图和原型形式让对方确认需求。

(3)沟通的升级原则。分析项目的关键干系人,不仅包括甲方高层,还要包括自己公司的高层,所以需求变更及项目情况沟通方式进行如下改进:

(1)先和业务部门沟通变更需求;

(2)再和甲方高层确认性沟通。条件是提前做好充足准备,例如:提前形成基本需求,最好能拿出原型和对方确认;

(3)定期和自己的高层沟通项目需求变更情况;

(4)鉴于企业高层关系,说服自己的高层能和甲方高层定期沟通,促进项目顺利进行;

(5)扫除沟通障碍。沟通障碍包括过多使用行话、结构化思维不强、确认环节做的不细致等。

总结

基于餐饮管理软件的需求分析 篇7

一、功能需求

(一) 、功能划分

在开发的本软件中, 按照模块设置可以划分出如下的功能:

1.公用模块:用来存放整个工程项目中用到的公用的函数, 全局变量等;

2.登陆模块:选择合适的操作员, 在操作员与密码正确后, 根据操作员的权限来操作主界面;

3.营业模块:完成点菜、加菜、结帐工作, 付款方式可采用现金、挂帐等几种方式;

4.商品查询模块:可选择不同的字段查询酒店商品库存信息;

5.员工查询模块:可选择不同的字段查询员工信息;

6.商品入库模块:完成酒店商品入库工作, 付款方式可采用现金、挂帐等几种方式;

7.库存商品查询模块:对库里是否有此商品进行查询;

8.进货查询模块:可以选择任意字段、不同的条件来查询商品的入库信息, 也可按任意设定的时间来查询入库信息;

9.付款单模块:可以实现向供应商付款的功能;

10.应收款查询模块:可以查询某个客户的一段时间的欠款记录;

11.应付款查询模块:用来查询一段时间里欠的某个供应商的钱;

12.营业日统计模块:统计当天的营业信息;

13.营业月统计模块:可以根据需要来统计某月或某一时间段的营业信息;

14.营业年统计模块:可以统计一年来的营信息。

15.商品信息管理模块:可以完成商品信息的录入、保存、修改、删除, 同时还可以查询某一制品的信息;

16.员工信息管理模块:可以完成对公司员工信息的录入、保存、修改、删除, 同时还可以查询某一员工的信息;

17.仓库信息管理模块:可以完成仓库信息的录入、保存、修改、删除;

18.供应商信息管理模块:可以完成与公司有关系的供应商的信息的录入、保存、修改、删除, 同时在需要时还可以查询供应商的信息;

19.单位定义模块:主要输入本公司的基本信息;

20.操作员及密码管理模块:设置操作员的添加、修改、删除;

21.权限设置模块:对每一个操作员设置他的权限, 使他具有操作此套系统某些限制;

22.修改密码模块:设置只能修改本名操作员的密码;23.帮助模块:介绍本套系统的操作功能。

(二) 功能描述

1.外部功能:餐饮管理系统软件具有输入、输出、查找功能。

2.内部功能:该软件集命令、编程、编辑于一体, 完成过滤、定位显示。

3.整体描述如表3-1。

二、系统数据分析与数据描述

1.进货需要记录的详细信息:进货票号, 品种数, 数量, 金额, 折扣, 税率, 应付, 实付, 未付, 经手人, 操作员, 供应商全称, 欠款日期, 还款日期, 付款方式, 是否结清;

2.点菜记录的点单信息:房间编号, 房台类别, 商品编号, 商品名称, 单位, 数量, 单价, 金额, 点单日期, 结帐日期, 服务员编号, 服务员姓名, 状态, 单据号, 是否结帐, 备注。

3.记录的挂帐信息:单据号, 挂帐时间, 还帐时间, 挂帐人, 经手人, 挂帐原因, 挂帐金额, 是否结帐。

4.记录的供应商的相关信息:供应商编号, 供应商全称, 简称, 地址, 所属地区, 邮政编码, 电话, 传真, 联系人, 联系人电话, 开户银行, 银行帐号, 纳税人登记, 网址邮箱。

5.保存库存的信息:商品编号, 商品名称, 单位, 进价, 库存数量, 库存金额, 仓库。

6.用于保存结帐信息:结帐单据号, 房台编号, 日期, 结款金额, 结款人, 结款方式, 结款说明。

7.记录部门信息:部门编号, 部门名称, 负责人, 部门电话, 部门职能。

8.权限设置中设置了所有的用户的权限, 以便有相应的操作;

9.系统开发使用的是SQL Server2000数据库系统, 能有效的保证数据的准确性与安全性。

三、外部接口需求

(一) 、用户界面

采用Windows的通用图形界面, 必须对鼠标和键盘提供支持, 界面的设计应遵循如下规则:

1.界面要具有一致性, 界面规范应遵循MSWindows软件界面的规范;

2.提供简单的错误处理;

3.提供信息反馈, 用多种信息提示用户当前软件运行状态、软件界面元件的功能;

4.操作可逆, 其动作可以是单个的操作, 或者是一个相对独立的操作序列;

5.显示启动画面, 画面简洁明快, 富有现代气息, 不能太过花哨;

6.应遵循国家关于计算机词汇的标准, 用词应当简练准确, 没有歧义, 图形的意义明朗。

(二) 、硬件接口

支持一般计算机、笔记本电脑。

(三) 、软件接口

运行与Windows XP/Me/2008, 且具有WIN32 API的操作系统之上。

(四) 、故障处理

正常使用时不应出错, 若运行时遇到不可恢复的系统错误, 也必须保证数据库完好无损。

四、性能需求

(一) .数据精确度

(1) 查询时应保证常用查询项目即字段都应能查到。

(2) 查询时应保证查准率, 查到的记录应与给定的单项或组合查询条件完全匹配。

(二) .时间特性

一般操作的影响时间应在1-2秒内, 对软磁盘和打印机的操作, 以及数据的导入导出可在接受的时间内完成.

(三) .适应性

满足客户使用的要求。对前面提到的运行环境要求不应存在困难。

五、软件属性需求

1.正确性

要求发布的软件达到用户的预期目标, 运行时基本无错误。

2.可靠性

在一般条件下, 应不出故障。

3.效率

对于浏览、查询、增加、删除、更新和密码设置的一般操作, 要求及时响应, 在1-2秒内。

4.完整性

要求能在发生意外 (如掉电) 的情况下, 保证不丢失数据。

5.易使用性

要求能尽量为用户的使用提供方便, 软件的界面符合目前流行的界面规范。

6.可维护性

要求本软件在运行中发现错误时, 能快速、准确对其进行定位、诊断和修改。

7.可测试性

设计时尽可能减少测试本软件的各项功能所需的工作量。

8.复用性

设计时应采取模块化的方法进行设计, 对系统内各模块接口尽可能达到高内聚、低耦合的程度, 以提高各模块的复用性。

9.安全保密性

要求提供身份验证, 只允许通过身份验证的用户使用本软件。对于三次密码不正确的, 应强行关闭。

10.可理解性

对于本软件提供的各种菜单命令, 各种信息提示, 应易于用户理解。

11.可移植性

要求本软件在将来能易于向Windows CE操作系统上移植, 以用于掌上电脑。

12.互联性

工程档案管理软件需求及设计方法 篇8

一、工程档案管理工作流程图

工程公司的档案管理是由文件收集、整理、归档、验收、整编、入库、管理、利用等几项工作组成。

首先是工程设计文件的收集、积累。工程设计文件分为项目文件和非项目文件两类。项目文件包括项目管理文件与设计文件, 非项目文件是指与项目相关, 但不是在项目活动中产生的文件资料, 如科研、标准及设计参考资料。文档人员在文件收集、积累完成后, 进行整理编目, 交付档案室归档, 档案室在接到归档文件后, 按照档案管理规定检查验收, 然后整编登记, 归入档案库房中相应的柜架进行保管。对库存档案进行管理是档案室的重要工作, 它包括整理档案资料, 编制档案目录和索引工具, 档案的鉴定与销毁, 根据用户的不同的需求提供档案利用服务。

二、系统结构

根据档案管理流程, 可以按照管理过程将档案管理系统划分为文件整理过程, 归档验收过程, 档案管理过程, 档案利用过程, 系统管理工程等几个部分。

(一) 文件整理过程

项目文档管理人员在获得的分配的项目后, 即可进行项目文件的收集整理理工作, 在本人负责的文件完成后即可交付档案部门归档验收。项目文件整理过程包括a、项目立项 (包括项目申请、项目登记、项目计划、项目组成员等) ;b、项目文件的编辑、输入、整理、归档;c、对项目文件的生成、收集、积累、归档过程, 系统监控。d、非项目文件的存档准备。

(二) 归档文件验收过程

档案人员和文档人员归档文件验收过程是靠“归档申请单”和“验收通知单”进行联系的。文档人员在进行文件归档时应向系统发出“归档申请单”, 档案管理员接到“归档申请单”后, 便可根据其中所列目录调阅对应的文件进行检查验收, 验收完成后, 将符合归档要求的文件登记入库, 同时向文档人员发出“验收通过通知”, 否则, 向系统发出“返回修改通知”。

(三) 档案管理过程

档案管理过程包括以下几项工作:a、对库存档案进行整理编排组卷;b、档案目录及检索工具的维护管理;c、定制报表, 生成报表数据;d、档案日常管理数据统计 (包括库房温湿度记录, 库房状况记录等) ;e、档案鉴定, 档案移交;f、档案信息的发布。

(四) 档案利用过程

系统应向用户提供电子档案的查询、阅览、在线档案的分级下载、实物档案的借阅、催还、归还管理, 利用档案的分类统计, 档案的修改与复制, 对外发图管理。

(五) 系统管理过程

系统管理过程主要包括以下工作:a、用户管理;b、数据的导入导出管理;c、制作档案数据光盘;d、定义档案数据类型及数据结构;e、审批过程的管理。

三、档案管理软件软件模块的划分

系统共包括8个模块:项目管理、归档管理、验收管理、档案管理、利用管理、审批管理、统计管理、系统管理。如下图所示:

(一) 项目管理功能模块对应现在文档组采用的项目管理软件, 包括项目的立项、项目配置、项目进度、项目查询这四个功能

(二) 归档管理功能模块包括:文件的输入, 文件修改, 文件导入, 可连接扫描的PDF电子文件, 可发送“归档申请单”, 可查询“存档状态”。

(三) 验收管理功能模块包括:项目验收与归档验收。项目验收主要是验收项目立项是否正确, 数据是否正确齐全。归档验收主要功能是归档数据的验收、入库是否完备齐全, 对验收结果评论, 并发出“出错信息修改单”。

(四) 档案管理功能模块包括:工程档案领号、档案整编管理、档案密级管理、档案鉴定管理、档案库房管理 (包括排位图、库房温湿度记录) 、档案维护管理 (对已有的档案数据增减修改) 。

(五) 档案利用管理

利用管理分为两部分, 1、电子档案的利用:包含电子档案的查询, 电子档案的浏览复制打印管理。2、实体档案的利用:包括利用实体档案审批手续, 实物档案条码管理, 实物档案借阅归还记录。

(六) 审批管理:包含档案利用审批申请, 利用审批查询, 审批权限管理等。

(七) 档案统计管理:统计管理的主要功能是完成各种统计工作, 包括项目统计, 归档统计, 利用统计, 电子档案汇总统计, 实物档案汇总统计等。

(八) 档案系统管理:主要功能是完成系统的全部定制工作及监控系统的运行情况。包含用户管理功能 (建立部门、组、用户, 定义角色、授权) ;在线监控功能:可查询所有登录过系统用户的详细信息, 并禁止特定用户登录) 日志管理功能, 可按日志事件组合条件查询系统的使用日志, 可将日志导入导出。

基础数据维护功能:可对档案系统的基础数据进行编辑, 基础数据包括, 档案分类码, 档案密级、图纸设计阶段, 归档整编数据修正。

数据备份与修复功能, 如遇异常情况数据系统遭到破坏, 可及时恢复系统数据。

工程档案管理系统除以上的基本功能之外, 还需要考虑增加单独的数字化管理接口模块, 随着电子技术的不断发展, 档案管理工具和手段也发生了日新月异的变化。包括扫描仪, 数码相机、打印机、条形码设备在档案部门不断应用, 故在设计工程档案管理软件时必须预留能调用这些数码设备和专业软件的接口。

工程档案管理系统的总体目标是实现图文自动归档, 电子编目、晒图、复用、查询审批、利用统计、工程领号的自动化管理。

随着电子信息的不断发展, 档案管理手段也发生巨大的转变, 从传统的档案管理向数字化档案管理过程已不可逆转。如何在新的形势下, 加强档案信息化管理, 充分开发和应用档案管理软件, 我们必须予以重视。

参考文献

[1]冯惠玲.电子文件管理教程[M].中国人民大学出版社.

软件需求分析中的干系人管理 篇9

关键词：软件项目,需求分析,干系人管理

在过去很长一段时间里,人们一直认为需求分析是软件项目中最简单的一个步骤。随着信息技术的高速发展,软件需求愈来愈复杂,涉及的领域亦愈来愈多。软件需求分析作为软件开发生命周期的第一阶段,作为整个软件产品和软件项目的基础,其重要性愈来愈为人们所重视。一般来说,可以把需求分析活动划分为5个阶段:需求获取、需求分析、需求规格形成、需求验证和需求管理。在需求获取阶段,最主要的任务是通过与项目干系人的交流沟通,了解他们对项目产品的要求与期望。这里提到的是与“项目干系人”沟通而没有仅仅局限于客户,是因为客户只是提供需求信息的主要主体,但并不是唯一主体。软件项目中的其他干系人也可能会提出有效的需求,或者提供有价值的信息,从而影响所采集的需求。这一点在需求分析阶段很容易被忽视或遗漏。

下面,笔者将逐一介绍在软件项目需求分析阶段常用的干系人识别、分析和管理的工具和方法。

1 干系人识别的工具和方法

确定干系人是需求分析阶段需要完成的第一个步骤,也是最基本的步骤。干系人的识别可以采用以下几种方法。

1.1 干系人提名法

干系人提名法是最简单最容易的一种干系人识别方法。在项目初期,最早被识别的干系人是项目出资人。同时,出资人也是项目关键干系人之一。但出资人一般不会参与需求分析这些具体的工作。可以通过与出资人的会谈了解项目的其他主要干系人(如高层管理者),然后再通过这些干系人进一步认识将会为项目提供具体需求的人员。这种方法一般适用于组织结构比较清晰的企业。

提名法操作简单,但是有很大风险。此时的需求来源只是由管理层提名的某个人,这样很容易造成某些重要的信息遗漏,特别是一些可能来源于客户组织外部的需求。

1.2 背景资料分析法

在大量实际案例中,干系人识别并不是那么简单和直接。在干系人识别比较复杂和困难的案例里,研究历史相关项目的项目资料,进行项目背景分析可能会给识别过程带来帮助。在此方法中,可以研究的背景资料包括:历史相关项目的项目资料、客户组织的组织结构图、旧系统的系统结构图等。在历史相关项目的项目资料中,可以找到历史项目的需求分析师、项目经理、客户代表等信息,可以通过他们识别潜在的干系人。历史相关项目的项目资料在背景资料分析法中具有非常重要的参考性。另外,客户组织的组织结构图也具有相当的研究价值。从中,可以找到与本项目相关的部门和部门负责人信息,再通过和对方联系来确认其是否为潜在干系人。此外,旧系统的系统结构图也会为干系人识别提供线索。通过对系统结构的研究,可以识别出哪些子系统可能会被影响,而这些被影响的系统开发团队都是潜在干系人,都可能会影响最终的需求定义。

1.3 会议法

会议法也是常用的干系人识别方法之一。在需求分析开始时,召集相关干系人集中会议,让他们相互介绍、认识。同时,在会议中,通过对项目的讨论还可能会发现其他尚未识别的干系人。

1.4 干系人环

除了以上三种方法外,还有一种更为系统化的干系人识别工具,叫做干系人环(Stakeholder Wheel)(见图1)。在干系人环中,将常见的组织内、外部干系人共分为8类,分别是:

拥有者:视乎组织的运营范围,主要包括股东,信托方,政府部门等;

管理者:主要指组织的中高层管理者;

职员:主要指受雇于组织的一般员工;

监管者:主要指位于组织外部的,对组织负有监管职责的部门;

供应商:主要指为组织提供产品和服务的外部组织或个人;

合伙人:主要指与组织合作提供产品和服务的其他组织;

客户:主要指组织产品或服务的使用者;

竞争者:主要指为相同客户群提供类似产品和服务的其他组织。

关系人环在需求分析阶段最主要的用途是提示在识别干系人时应该考虑的组织和团体类型,避免发生遗漏。在每种类型中,可以再使用前面所提到的提名法和背景资料分析法来进行具体分析。

2 干系人分析的工具和方法

待干系人识别完成后,还需要对干系人进行必要的分析,才可以辨认出哪些是关键干系人,哪些是一般干系人,从而制定不同的干系人管理策略。用做干系人分析的常用工具有权力/利益矩阵、RACI模型和支持度分析模型等。

2.1 权力/利益矩阵

权力/利益矩阵(见图2)通过对干系人权力和利益程度的分析,将众多干系人分成四类。

I类(高权力高利益):这类干系人一般是受项目影响较大的管理者。对于他们应该重点管理,随时报告需求分析的进展情况,同时认真考虑他们提出的建议和意见;

II类(高权力低利益):这类干系人一般是受项目影响较小的管理者。对于他们也应该重视,尽量做到让他们满意;同时鼓励他们多参与需求分析的过程,可以询问他们对需求分析结果的建议和补充;

III类(低权力高利益):这类干系人大多是项目产品的直接使用者,受项目影响较大,但权力较小。对于他们可以多做沟通,获取最直接的需求信息。但是这些信息往往从个人出发,过于片面或局限,应该综合分析后再考虑是否采纳;

IV类(低权力低利益):这类干系人大多受项目影响较小且权力较小。对于他们可以根据需要只做阶段性的信息公布。

干系人的权力和利益分析完成之后,针对每一类干系人的特点制定相应的管理计划,区别对待,有的放矢,使整个需求分析阶段进行得更加顺畅。

要注意的是,干系人的类别并不是一成不变的。随着项目的进行,干系人对项目的认识可能发生改变。例如,在财务系统项目中,销售部经理在需求分析阶段初期被认定属于II类干系人(即高权力、低利益),原因是他认为财务系统的变动对于销售部的业务影响很小,所以兴趣不大,参与度不高。但随着项目的进行,该经理发现财务系统的变动其实很大程度上影响了销售部员工报销、审批和业务绩效确认等活动。于是,该经理变得十分关注此项目的进展,并积极参与需求分析阶段的工作。这时,该经理的类别就发生了改变,由原先的II类(即高权力、低利益)变为I类(即高权力、高利益),从而受到重点管理。

2.2 RACI模型

RACI模型主要用来记录和检查干系人在各项活动中的角色和职责。它把干系人分为以下四类:

负责的(Responsible):这类干系人负责某项任务的具体操作;

批准的(Accountable):这类干系人对某项任务负全责,只有经他批准后,这项任务才算完成;

咨询的(Consulted):这类干系人能对完成某项任务提供有价值的信息,或具备完成某项任务所必需的能力;

通知的(Informed):必须将任务的完成情况通知这类干系人,但是不必向他们询问建议。

在软件项目需求分析阶段,RACI模型主要可以运用在两个方面。一是标示干系人在需求分析阶段的角色和职责。例如,在某项目的需求分析阶段,各项目干系人的角色和职责如表1所示。

RACI模型可以运用的另一方面是记录在某个业务流程中客户组织不同部门或者同一部门不同职位的角色和职责,用以帮助理解该组织业务流程和业务规则,同时也可以帮助分析项目可能产生的影响。

2.3 支持度分析模型

支持度分析模型将干系人对项目的支持程度划分为五个层次,再对干系人逐一进行分析和记录。这五个层次分别是:

未察觉的:对于项目和项目的影响程度毫不关心;

抵抗的:意识到项目及其影响,并拒绝改变;

中立的;意识到项目及其影响,不接受也不拒绝改变;

支持的:意识到项目及其影响,并支持改变;

引领的:意识到项目及其影响,并积极参与以确保项目的成功。

在需求分析阶段,对于“未察觉的”和“抵抗的”干系人,可采取缓和的沟通方式,重要信息进行通知,其他细节不予打扰。对于“中立的”干系人,可采取积极争取的方式,令其明白项目可带来的好处,力争他的支持。对于“支持的”和“引领的”干系人,可采取鼓励支持的方式,积极听取他们的建议和意见,完善需求分析结果。

3 干系人管理的工具和方法

干系人管理就是通过对每个干系人的需要、兴趣以及对项目潜在影响的分析,制定一套清晰、可行的管理策略,以获取每个干系人对项目的最大支持。其中,最常用的方法就是制定干系人管理计划。

3.1 干系人管理计划

干系人管理计划本身是项目管理计划的一部分。在项目初期,该计划可能并不完全。随着需求分析的进行,可以对干系人管理计划近一步完善。干系人管理计划中应包含的主要内容如下:

干系人姓名:记录干系人的姓名和职位;

目前的权力/影响力水平:记录该干系人目前对于项目的影响力水平,其结果可以从干系人权力/利益矩阵中得到;

目前的利益水平:记录该干系人目前在项目中的利益水平,其结果可以从干系人分权力/利益矩阵中得到;

主要关注事项:记录该干系人主要关注的问题,可能的疑虑和感兴趣的方面。如果可以,最好还附上事项的优先顺序,以便重点管理;

目前态度:记录该干系人目前对于项目的支持度,其结果可以从干系人支持度分析模型中得到;

对干系人的期望:记录期望该干系人能在项目中承担的责任、提供的支持和采取的行动等;

注意事项:记录在与该干系人进行交流沟通时应注意的事项;

沟通计划:记录对于该干系人将要采取的管理行动,比如:与关键干系人召开定期会议来进行沟通等。

干系人管理计划记录了与干系人相关的所有重要信息,在需求分析阶段特别是需求获取过程起到十分重要的作用。

干系人的识别、分析和管理是软件项目需求分析阶段的重要基础。如果干系人识别完全,沟通顺利,可以很大程度上减少软件项目因为需求不清晰或者需求遗漏而带来的影响。相反,如果干系人识别不全,或者沟通不顺利甚至产生抵触,这将会给软件项目带来及其负面的影响,甚至导致灾难。

参考文献

[1]Cadle,J.Paul,D.and Turner,P.Business Analysis Techniques-72Essential Tools for Success.Swindon:British Information Society Limited,2010.

[2]Project Management Institute.A Guide to The Project Management Body of Knowledge(Fifth Edition).Pennsylvania:Project Management Institute,Inc,2012.

计量管理软件研发中的需求设计 篇10

1 系统简介

计量业务管理软件是进行计量检测信息化管理的软件。编制该软件的最核心目标是实现对检测工作涉及的各环节进行有效的闭环控制。该软件的主干业务模块有:仪器设备收发管理模块、检测数据证书管理模块、检测费用管理模块、证书业务查询管理模块、检测人员信息管理和标准器信息维护模块等组成。作者结合本单位业务流程特点和管理要点,全程组织设计了本软件的架构和流程框架,现已投入使用,效果良好。

2 软硬件要求

服务器使用现有的服务器或根据需要稍加升级即可满足要求。客户端计算机:主流办公电脑或OfficeStation类型瘦客户机均可,100M网络连接。软件WINDOWS Server 2003/WINDOWS XP,OFFICE2003,SQL2000。

3 系统介绍

3.1 仪器设备收发管理模块

该岗位负责仪器的接收、录入、交接、收款和送检单位信息维护等工作。

3.1.1 送检仪器受理

接待人员在接到仪器后,录入其相关信息,其中送检单位名称、仪器名称、型号规格可通过信息查询并选择确认。然后为仪器分配条码,并将条码联粘贴在仪器上。或者通过条码枪对以前检测过的仪器进行信息录入。或者选择送检单位,点击“历史查询”键,通过历史信息查询界面,调出该送检单位已经检过的仪器信息,通过双击仪器条码,即可实现仪器信息的录入。

3.1.2 仪器提取

实验室人员通过送检仪器查询,到收发室提取仪器。提取时,收发人员通过仪器提取界面,调出相关仪器信息,由提取人通过密码确认后提取仪器。

3.1.3 仪器返还

实验室人员将检测完成的仪器返还到收发室,收发人员通过仪器返还界面,调出相关仪器信息,由返还人通过密码确认,即完成返还。

3.1.4 送检单位信息登记查询管理

送检单位基本信息包括:单位名称、联系人、联系电话、地址、邮编等。具体操作分为增加、删除、修改。

3.2 技术检测管理模块

该模块负责证书填写、核验、审批、送检仪器信息管理、相应证书模板管理。

3.2.1 送检仪器查询

实验室人员通过送检仪器查询界面,到仪器收发室提取仪器。

3.2.2 证书填写

检测前,将条码一联粘贴在相应的原始记录上。检测完成后,检定员通过证书信息录入和费用管理界面,确认仪器相关信息。

3.2.3 核验确认

核验员通过核验管理界面,对记录和证书内容进行核验,无误后进行确认。确认成功的仪器信息将不再显示于该列表中。

3.2.4 证书签发

签发人通过证书签发界面,对记录和证书内容进行审核,同时在相应的折扣范围内确定检定费用,无误后确认,然后点击“打印”键,完成签发。如果打印完成的证书有误,由质保部门负责核验撤消,检定员重新填写,再经核验、签发。

3.2.5 检测模板管理

按照实验室开展的项目,依据规程、规范等要求制作检测模板。

3.2.6 现场检测

现场检测仪器时,实验室人员根据工作量领取条码,检测前,在原始记录粘贴条码一联,在被检仪器上粘贴条码二联。检测后,检定员在本室直接录入仪器信息及条码。证书信息录入和费用管理界面的操作同上。

3.2.7 补填送检仪器信息

通过补填送检仪器信息界面,实验室人员可以将仪器收发人员没有填全的信息补填。

3.3 检测费用管理模块

负责费用收取,在单据背书需要分账的科室及金额。

3.3.1 费用查询

通过仪器条码或登记ID进行费用查询,如果在送检单位全部未结费用前作标记,将列出该单位的全部费用信息。然后点击“生成帐单”键,完成帐单的生成,点击打印帐单键,生成检测费帐单和修理费帐单。

3.3.2 减免电子审批

如需要费用减免时,由具有权限的责任人通过系统电子审批。如果审批内容有误,可点击“撤销审批”键,重新审批。

3.3.3 收费管理

正常收费时,在收费管理界面上选取单位名称,然后点击“确认保存”键。需要减免时,由财务人员持检测费帐单和修理费帐单报请责任人签字、批准,同时在收费管理界面上选取单位名称,在减免金额处填写金额,选添审批责任人,然后点击“确认保存”键,再点击“打印帐单”键,重新生成检测费帐单和修理费帐单。

3.3.4 协议管理

首先通过协议管理界面录入协议信息(协议文件录入需双击协议文件栏),并点击“确认保存”键。需查询协议信息时,点击单位名称,再点击“协议文件”键。

通过协议-仪器信息管理界面添加仪器基本信息,也可以通过该界面进行缴费查询。

3.3.5 催款管理

通过催款管理界面,选择送检单位,列出检测完成但未缴费的仪器列表。

3.4 业务证书查询管理模块

该岗位负责业务审批、证书发放、查询统计和一些具有较高权限的操作.

3.4.1 证书发放电子审批

如需要先取证书,后缴费用时,由具有权限的责任人通过系统电子审批。如果审批内容有误,可点击“审批撤销”键,重新审批。查询与勾选操作同前。

3.4.2 证书发放

实验室检测和现场检测所出具的全部证书,均由业务部门统一发放。业务科通过扫描条码,添加需发放证书。

3.4.3 仪器流程查询

通过仪器流程查询界面,选取仪器条码,点击“查询”键,可查询送检仪器信息录入、费用审批、证书发放等一系列过程的操作信息。

3.4.4 综合信息查询

通过综合信息查询界面,根据需要,设置查询条件,进行送检仪器、检测费用和收入信息等综合信息查询。

3.4.5 保存期外证书删除

业务部门通过保存期外证书删除界面,依据证书保存期限的规定,对保存期外证书删除。

3.4.6 证书撤消统计

通过证书撤消统计界面,可以统计出每个科室相关人员撤消的错误证书数量。

3.4.7 模板操作查询

通过模板操作查询界面,可以查询每个科室相关人员修改证书模板的信息。

3.4.8 核算单位收入查询

通过核算单位收入界面,可以查询各核算单位年初到指定日期的收入。

3.5 系统管理岗位模块

该岗位负责管理系统的基本设置,如:部门科室,人员信息,分组信息,人员权限,证书类型等。

3.5.1 人员管理

通过人员管理界面,添加单位内部人员信息,如姓名,登录名,核算单位等项目。用户初始密码为登录名。同时可以进行设置电子签名的操作。

3.5.2 核算单位管理

通过核算单位管理(科室)和核算单位管理(组)界面,可以使费用分解,核算单位可以按科室、组进行核算。

3.5.3 本单位信息管理

通过本单位信息管理界面,录入本单位的相关信息。

3.5.4 科室字冠设置

系统管理员通过科室字冠设置界面,依据规则设置科室字冠。

3.5.5 权限管理

系统管理员通过权限管理界面,依据管理层决定,设置相应岗位权限。

3.5.6 仪器分类设置管理

系统管理员通过仪器分类设置管理界面,对单位开展项目,按科室进行分类。

3.5.7 书类型管理

系统管理员通过证书类型管理界面,实现证书分类的管理。

3.5.8 码管理

系统管理员按条码规则要求设定号码。

3.6 标准器信息维护模块

计量业务综合管理信息系统将各个科室的计量标准数据录入到系统的数据库中,既方便打印证书时自动选择所使用的计量标准,同时计量标准的到期提醒功能更方便了对计量标准审核日期的掌握,不会因为管理人员的疏忽而耽误了计量标准的审核。超期计量标准的使用将不予通过系统审核。

4 结论

计量业务综合管理系统规范了业务流程,避免了一些人为行为,通过梳理计量业务流程,解决了很多以前组织协调困难、职责混淆不清、影响工作效率的问题。系统在推广过程中,首先统一思想,解决问题,这是系统能得到快速应用的根本。模块化的设计使得业务流程的改变能较容易的反映到系统设计中去。同时前期的需求分析将对系统实施起到决定性作用。

参考文献