范文一:IT项目需求分析注意事项研究
IT项目需求分析注意事项研究
研究表明,要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现,在需求开发阶段发现的一个错误,平均仅需要花30分钟修复,
但若在系统测试时发现则需要5到17个小时来修复。因此我们不难发现,需求分析在IT项目中具有十分重要的作用。所谓需求分析是指通过对问题域的研究,获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并有文档的说明。
本文结合作者在实际项目管理工作中的经验,就IT项目中需求分析时应注意的主要问题进行了研究分析。
1 与用户沟通前应进行充
通常,与用户沟通前的准备时间要远远大于正式会面沟通的时间。一般情况下,用户在和你连续交谈两个小时之后,就会失去热情和耐心,这是大部分人的共同特点。所以充分的准备工作至关重要。
准备工作包括对项目整体环境熟悉的准备工作和对具体业务进行调研前的准备工作。项目整体环境的熟悉工作需要了解:项目的背景、项目的目的、项目的利益相关方等信息,以便对当前项目的鹰钵情况有一定了解。
对具体业务调研前的准备工作包括:需求调研问题的准备、需求调研模板的设计、需求调研时间安排等内容。要充分珍视用户的时间,尽量避免由于准备工
作不足而反复约见用户,给用户造成效率低下的印象。一旦发生这样的错误,以后可能就会很难约见到用户。
2 主动积极了解客户业务和相关知识
在计算机技术方面我们可能非常专业,但对于具体的用户业务可能并不十分清楚。这个项目对用户是否有帮助、某一系统功能是否有用、某一流程处理是否合理,在不了解用户业务的情况下,我们将很难做出判断。
因此只有在了解业务的基础上,我们才和用户有共同的沟通语言和业务理解,才能真正理解系统应具有哪些功能。笔者曾在经销商管理系统调研过程中,由于财务方面的知识有限,使得在对经销商财务部门的调研中对部分问题不是特别的理解。
当时,笔者向用户虚心进行请教,并在调研结束后及时对自己的财务知识进行了补充。应用领域的知识是无边无际的,在各种项目的调研过程中,肯定会出现由于需求分析者缺乏某一领域的知识而影响需求分析工作的准确、顺利进行。
遇到此类问题时,需求分析者应虚心向用户请教,同时应及时补充应用领域的知识。最好能够在调研前做好充分的准备。
3 对用户进行正确分类
组织中的用户在很多方面存在差异,例如:使用系统的频度和程度、计算机系统知识、所进行的业务过程以及个人的素质和喜好等。根据用户的特点,可对
用户进行一定的分类。将用户分类并归纳各自特点,详细描述他们的个性特点及任务状况,将有助于需求的获取和分析。
不同的问题需要询问不同的人,对于操作细节的问题,要和实际负责操作的用户进行沟通,而对于关乎全局的问题,则要和相应的管理层用户进行沟通。如通过组织架构图得知仓库部门有三种角色:仓库主管、发货理货员、系统操作员。
我们发现仓库主管是对全盘业务相当熟悉的人,他负责协调本部门的全局事务;而发货理货员是部门的主要业务执行人;系统操作员则是仓库管理系统的直接操作者。若我们调研的目的是搞清该部门的整体性流程,我们会很自然地选择仓库主管作为访谈的对象。
4 引导用户,使用户充分表达自己的想法
在与用户交谈中,如何引导用户说出他们的需求是非常关键的。恰当的提问,会使用户滔滔不绝,充分发表自己的意见和建议。而不恰当的提问,可能会导致用户无法回答或敷衍了事地进行回答。提问可分为封闭式提问和开放式提问。
封闭式提问目的明确。如:现在你们的送货单是手工填写还是电脑打印?但过多使用封闭式提问,会导致谈话枯燥,让用户感觉自己好像在接受审问。开放式提问是请对方对某一事物做进一步的解释,可使谈话达到一定的深度和广度。
如:你认为目前的工作中存在哪些可以改进的地方?开放式提问缺点是容易使谈话内容偏离主题。因此在谈话过程中,应采用封闭式和开放式提问相结合的
方式。以简单问题开始、从用户熟悉的内容开始。每次只提一个问题、集中一个重点,宁问勿猜。
并尽量避免使用IT相关的一些术语,以便用户能够很好地理解我们的表达。
5 应实地了解用户工作流程
实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据,并怎样使用这些数据,业务处理 过程中需要处理哪些单据,需要和哪些角色的用户发生关联等。这都将有助于明确产品的功能需求。
经验证明,与人们面谈关于他们如何完成任务时会有许多限制和不准确性,而这是任务观察可以直接解决的。特别是对于某些组织中普遍接受的规则和方法,用户认为你也应理所当然知道,而不曾提起时。
近年来,由于人机交互的复杂性惊人地增加,人机交互的观察和记录已引起人们的广泛注意。观察是一个主观的领域,很大程度上依赖于需求分析者的经验。在经销商管理系统的需求分析中,
通过观察发现:某些客户要求送货单中的商品价格为含税价格,而有些客户则要求送货单上的商品价格为不含税价格;有些商品的税率为13%,而有的商品税率为17%;
有些客户要求送货单上的金额小数点后保留四位,有的客户又要求送货单上必须提供自己公司的商品编码等。而这些都是在调研中,用户不曾提起的内容。
6 分析需求可行性
柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选,这样的事也不干。”
柳传志为联想集团的决策确立了上述准则,同时也为可以行性分析指明了重点。可行性分析主要是针对某一需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。
很多时候,用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想,将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。如在笔者曾经负责的一个项目中,用户要求新的管理系统应实现和用友、金蝶等管理系统的数据接口,以方便这些系统中的数据导人新的管理系统。
许诺提供与用友、金蝶等系统的数据接口,将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间,开发与它们的接口也需要时间,而且用友、金蝶等这些系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。
人的方面主要考虑目标用户是否具有相应的素质和能力。在实际项目中,笔者曾对快速消费品行业经销商批次管理的可行性进行了分析。首先,批次管理将涉及到所有产品的出入库操作,并存在一个产品有多个批次的情况,因此批次管理对操作人员的能力和素质要求比较高。
其次,快速消费品行业的特点决定了产品的出入库操作极为频繁,因此,操作人员的工作强度比较大。再次,大部分经销商的仓库所在地都距离城镇比较远,因此工作人员的文化水平普遍不高。在综合考虑后,将批次管理的可行性定义为低。
对于复杂的项目,还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。
7 确定需求的优先级别
当客户的期望很高、开发时间很短且资源有限时,设定需求的相对优先级将有助于项目管理人员解决冲突、安排阶段性交付并做出必要的取舍。建立每个需求的重要性有助于规划软件的构造,以最少的费用提供产品的最大功能。
特别是对渐进式的项目,优先级的设定就显得更为重要,因为在这些开发中,项目时间安排极为紧迫并且交付日期不可改变,一些低优先级的需求就需要推迟到后续版本中进行实现或直接取消。
当众多用户因期望不同而就某些需求优先级的设定难以达成一致意见时,需求分析者可指出每一需求所需的费用、难度、技术风险或其他特定的与权衡需求有关的指标,来客观评价每一需求的优先级。
8 正确理解需求分析文档确认
需求分析是一项繁琐枯燥的工作,需要和用户不断的商讨、确认和反复。但大部分用户并不只做这项工作,特别当他被很多其他的事情缠身的时候,而无心在笔者曾负责的经销商管理系统中,经销商认为,库存过高将占用企业运转资金,增加企业负担;
库存过低则无法满足客户订单,从而导致交货周期延长,降低企业市场竞争力。由于经销商对当前可用库存十分关注,因此可用库存的优先级被定义为:高优先级。仔细考虑或回答你的问题。这很容易使你错误地认为用户已经真正地了解并认可了你的分析文档。
在需求分析文档上签字确认,通常被认为是用户同意需求分析内容的标志行为。而实际操作中,签字确认工作并未得到用户的充分重视。“他们要求我在需求文档上签名,于是我就签了,否则开发人员不开始编码。”用户的这种态度将可能给项目带来潜在的风险,如不断地进行需求变更等。
对于需要用户确认的需求分析文档,最好在用户确认前,就文档内容对用户进行一定的讲解,以确保用户完全理解并认可文档中的内容。若用户对文档中的内容存在修改意见,则修改后再与用户进行确认,直至用户完全认可文档中的内容为止。
通常为对项目有一个整体、准确的理解,需求分析所包含的内容通常大于项目范围所包含的内容。因此,应让用户理解对于某些功能的讨论并不意味着即将在系统中实现它。应使用户明白对需求分析文档的签字确认是建立一个需求的基线,进一步的变更可在此基线上通过项目定义的变更过程来进行。
需求确认将给初步的需求开发工作画上了双方都明确的句号,并有助于形成一个持续良好的用户与需求分析人员的关系,为项目的成功奠定坚实的基础。
9 结语
将知识从一个地方传送到另一个地方并不是一件简单的事情,而且原始的需求通常是以不完整的形式呈现的。它也许只是在某个现有系统的用户脑中,甚至有时用户都没有意识到他们知道什么。本文从引导用户、需求确认等方面对需求分析中应注意的主要问题进行了研究分析。
同时需求分析工作者也应在日常工作中加强学习,不断总结,使自己的需求分析能力得到不断的提升。
范文二:用例需求分析注意事项
1、用例的分析
1.1流程的定义
主要流程:这是用例叙述最核心的部分,记载了整个用例正常的执行过程。 替代流程:一个用例叙述里,通常会包含一段主要流程,同时可以包含数段替代流程。
例外流程:例外流程跟替代流程不同,替代流程这条小路径的尽头会接回主要流程,可是一旦进入了例外流程之后,系统将不会继续执行完剩下的主要流程。也就是说,例外流程这条小路径的尽头不会接回主要流程。
1.2寻找替代流程或例外流程
如何寻找替代流程或例外流程?可以通过回答如下问题查找: 1. 在这个流程步骤上头,是否还有其他替代的操作? 2. 在这个流程步骤上头,是否会发生什么样的错误?
3. 在整个用例执行过程中,是否随时可能发生其他未记录在叙述中的操作? 4. 参与者输入数据时,是否会提供错误的数据,需要特别检查的? 5. 参与者输入数据时,是否会提供不完整的数据,需要重新补上的? 6. 参与者是否会在操作期间,临时中断流程?
7. 参与者是否会在用例执行期间,随时取消交互? 8. 参与者是否会想要挑选其他执行方法?
9. 参与者在流程执行过程中,会不会有需要协助的地方? 10. 系统发生宕机时,是否需要特殊的处臵?
11. 系统响应时间过长时,是否需要特殊的应对方法? 寻找到的流程,如果回到主要流程,则为替代流程,如果不回则为例外流程,这是区分替代流程和例外流程的充分和必要条件。比如用例执行失败、异常、错误、网络异常导致系统执行超时等为典型的例外流程。
对于替代/例外流程需做务实的评估、可行性分析(避免钻“牛角尖”)
1.3非功能性需求
非功能性需求一般是在需求文档的整体部分叙述,但是如果本用例有特殊的非功能性需求,则需要在用例中进行具体的描述,所以该部分在用例中是一个可选项。
对于替代/例外流程需做务实的评估、可行性分析(避免钻“牛角尖”)
1.4前置条件
前臵条件:执行用例执行之前系统必须要处于的状态,或者要满足的条件。它必须是软件系统可以识别到的状态,如用例“入库”的前臵条件是“仓库管理员已成功登录”,而不能是“仓库管理员已打开电脑”,因为是否“打开电脑”库存管理系统不能识别到;
1.5后置条件
后臵条件:用例执行之后系统应该具备的状态,它也必须是系统能够识别到的,如用例“入库”的后臵条件是“系统保存入库信息,更新相关商品的库存量”,而不能是“用户退出系统”,因为“用户退出系统”不是“入库”操作所达到的系统状态。
1.6优先级
用例优先级分成三个:关键、一般、NTH ,其中关键、一般的用例是必须实现的,NTH 是可实现可不实现,具体是否实现在需求评审会议时决定。
1.7流程图
在用例中这是一个可选项,如果该用例的流程比较复杂,则必须绘制用例的流程图,以具体说明该用例如何执行。
2、可变性分析
以快销平台的订单提交举例,订单提报活动时依据类型、方式和收货方有三种可变性。如下:订单提报时,提报可变性如下
变化,并且可以再次细化。
认证方式:1)自我认证;2)委托认证
实现方式:1)手机端实现(手机端实现需要考虑性能、暖存等变量) 2)WEB 实现
范文三:[整理]项目需求分析注意事项
项目需求分析模板
项目实施严格按软件工程的思想来进行,
软件工程之需求分析
需求工程分为需求开发和需求管理两个阶段:下面就以这两个阶段说明:
一,需求开发
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤,当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。
1( 需求获取:
1)确定需求开发过程:确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤,并将它编写成文档。对重要的步骤要给予一定指导,这将有助于分析人员的工作,而且也使收集需求活动的安排和进度计划更容易进行。
2)编写项目视图和范围文档:项目视图和范围文档应该包括高层的产品业务目标,所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
1 2 3 4 5 6
客户或市提供给客户业务背景 业务机遇 业务目标 A 业务需求 场需求 的价值 风险
项目视图假设和依B 项目视图的解决主要特性 方案 陈述 赖环境
首次发行随后发行局限性和C 范围和局限性 的范围 的范围 专用性
项目优先客户概貌 D 业务环境 级
E 产品成功的因素
表1 项目视图和范围文档的模板
a . 1 背景 在这一部分,总结新产品的理论基础,并提供关于产品开发的历史背景或形势的一般性描述。
a.2 业务机遇 描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案,并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。
a.3 业务目标 用一个定量和可测量的合理方法总结产品所带来的重要商业利润,把重点放在给业务的价值上。
a.4 客户或市场需求 描述一些典型客户的需求,包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能(或不可能)出现的阐述,提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。
a.5 提供给客户的价值 确曲 定产品给客户带来的价值,并指明产品怎样满足客户的需要。
a.6 业务风险 总结开发(或不开发)该产品有关的主要业务风险,例如市场竞争、时间问题、用户的
接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性,指明你所能采取的减轻风险的措施。
b.1 项目视图陈述 编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化,但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。
b.2 主要特性 包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。
b.3 假设和依赖环境 在构思项目和编写项目视图和范围文档时,要记录所作出的任何假设。通常一方所持的假设应与另一方不同。
c.1 首次发行的范围 总结首次发行的产品所具有的性能。描述了产品的质量特性,这些特性使产品可以为不同的客户群提供预期的成果。
c.2 随后发行的范围 如果你想象一个周期性的产品演变过程,就要指明哪一个主要特性的开发将被延期,并期待随后版本发行的日期。
c.3 局限性和专用性 明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。
d.1 客户概貌 客户概述明确了这一产品的不同类型客户的一些本质的特点,以及目标市场部门和在这些部门中的不同客户的特征。
d.2 项目的优先级 一旦明确建立项目的优先级,风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面:性能、质量、计划、成本和人员。
e. 产品成功的因素 明确产品的成功是如何定义和测量的,并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务,还要包括外部因素。如果可能,可建立测量的标准用于评价是否达到业务目标.
3)用户群分类:产品的用户在很多方面存在着差异,例如:用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异,你可以把这些不同的用户分成小组。用户类不一定都指人,你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口,可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况,要将可能使都有所差异。详细描述出它们的个性特点及任务状况,将有助于产品设计。
4)选择产品代表:择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的,因为此时,用户就是身边的职员。而对于商业开发,就得在主要的客户或测试者中建立起良好的合作关系,并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一个产品代表者代表了一个特定的用户类,并在那个用户类和开发者之间充当主要的接口。
5)建立核心队伍:建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来,从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用,因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于,核心队伍成员通常没有决定权。
6)确定使用实例:让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例,讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版,在使用实例基础上可得到功能需求。
7)召开应用程序开发联系会议:召开应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会,也是分析人员与客户代表之间一种很好的合作办法,并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。
8)分析用户工作流程:分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图(最好用数据流图)来描绘出用户什么时候获得什么数据,并怎样使用这些数据。编制业务过程流程文档将有助
于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。
9)确定质量属性:确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点,这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性,这是一种非功能需求。听取那些描述合理特性的意见:快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义。
10)检查问题报告:通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法,负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
11)需求重用:跨项目重用需求如果客户要求的功能与已有的产品很相似,则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
2( 需求分析
1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
2)创建开发原型:创建用户接口原型当开发人员或用户不能确定需求时,开发一个用户接口原型,这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
3)分析可行性:分析需求可行性在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
4)确定需求优先级:确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。
5)为需求建立模型:为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6)编写数据字典:创建数据字典数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
7)应用质量功能调配:使用质量功能调配质量功能调配是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备。
3( 编写规格说明书
项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制,软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。
1)采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意,其目的并非是创建一种全新的模板,而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的,但有时要根据项目特点进行适当的改动。
1 2 3 4 5 6
预期的读者和产品的目的 文档约定 参考文献 A引言 阅读建议 范围
产品的产品的功运行环设计和实现假设和依用户类和特征 B综合描述 前景 能 境 上的限制 赖附录
用户界通信接C外部接口硬件接口 软件接口 需求附录 面附录 口
说明和激励/响功能需求 D系统特性 优先级 应序列
性能需安全设施软件质E 其它非功安全性需求 业务规则 用户文档 能需求 求 需求 量属性
F其它需求
待确定问题的词汇表 分析模型 G附件 列表
表2 需求规格说明模板
a. 引言
引言提出了对软件需求规格说明的纵览,这有助于读者理解文档如何编写并且如何阅读和解释。
a . 1 目的
对产品进行定义,在该文档中详尽说明了这个产品的软件需求,包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系,那么就只定义文档中说明的部分或子系统。
a.2 文档约定
描述编写文档时所采用的标准或排版约定,包括正文风格、提示区或重要符号。
a.3 预期的读者和阅读建议
列举了软件需求规格说明所针对的不同读者,例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。
a.4 产品的范围
提供了对指定的软件及其目的的简短描述,包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。
a.5 参考文献
列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档,或相关产品的软件需求规格说明。
b. 综合描述
这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。
b.1 产品的前景
描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员,是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品,或者是否是一个新型的、自含型产品。
b.2 产品的功能
概述了产品所具有的主要功能。其详细内容将在d 中描述,所以在此只需要概略地总结。很好地组
织产品的功能,使每个读者都易于理解。
b.3 用户类和特征
确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。
b.4 运行环境
描述了软件的运行环境,包括硬件平台、操作系统和版本,还有其它的软件组件或与其共存的应用程序。
b.5 设计和实现上的限制
确定影响开发人员自由选择的问题,并说明这些问题为什么成为一种限制。
b.6 假设和依赖
列举出在对软件需求规格说明中影响需求陈述的假设因素(与已知因素相对立)。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定,但是另一个S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更改,就会使项目受到影响。
此外,确定项目对外部因素存在的依赖。例如,如果你打算把其它项目开发的组件集成到系统中,那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了,那么在此就可以参考其它文档。
c. 外部接口需求
利用本节来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口,那么应把这些外部接口的详细需求并入到这一部分的实例中。
c.1 用户界面
陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节,例如特定对话框的布局,应该写入一个独立的用户界面规格说明中,而不能写入软件需求规格说明中。
c.2 硬件接口
描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。
c.3 软件接口
描述该产品与其它外部组件(由名字和版本识别)的连接,包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。
c.4 通信接口
描述与产品所使用的通信功能相关的需求,包括电子邮件、We b 浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。
d. 系统特性
d.1 说明和优先级
提出了对该系统特性的简短说明并指出该特性的优先级是高、中,还是低。或者你还可以包括对特定优先级部分的评价,例如利益、损失、费用和风险,其相对优先等级可以从1(低)到9 (高)。
d.2 激励/响应序列
列出输入激励(用户动作、来自外部设备的信号或其它触发器)和定义这一特性行为的系统响应序列。这些序列将与使用实例相关的对话元素相对应。
d.3 功能需求
详列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能,使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输入或动作。就像本章开头所描述的那样,你必须唯一地标识每个需求。
e. 其它非功能需求
这部分列举出了所有非功能需求,如产品的易用程度如何,执行速度如何,可靠性如何,当发生异常情况时,系统如何处理,而不是外部接口需求和限制。
e.1 性能需求
阐述了不同的应用领域对产品性能的需求,并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。你还可以在这里定义容量需求,例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求,而不是把它们都集中在一起陈述。
e.2 安全设施需求
详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作,还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。
e.3 安全性需求
详尽陈述与系统安全性、完整性或与私人问题相关的需求,这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。
e.4 软件质量属性
详尽陈述与客户或开发人员至关重要的其它产品质量特性。这些特性必须是确定、定量的并在可能时是可验证的。至少应指明不同属性的相对侧重点,例如易用程度优于易学程度,或者可移植性优于有效性。
e.5 业务规则
列举出有关产品的所有操作规则,例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求,但它们可以暗示某些功能需求执行这些规则。
e.6 用户文档
列举出将与软件一同发行的用户文档部分,例如,用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。
f. 其它需求
定义在软件需求规格说明的其它部分未出现的需求,例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错,以及登录和监控操作等方面的需求。
附录A :词汇表
定义所有必要的术语,以便读者可以正确地解释软件需求规格说明,包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表,并且只包括特定于单一项目的软件需求规格说明中的术语。
附录B :分析模型
这个可选部分包括或涉及到相关的分析模型的位置,例如数据流程图、类图、状态转换图或实体-关系图。
附录C :待确定问题的列表
编辑一张在软件需求规格说明中待确定问题的列表,其中每一表项都是编上号的,以便于跟踪调查。
2)指明需求来源:指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求,要都能追溯每项需求的来源,这可能是一种使用实例或其它客户要求,也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
3)为每项需求注上标号:为了满足软件需求规格说明的可跟踪性和可修改性的质量标准,必须唯一确定每个软件需求。为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全,允许增加、删除和修改。作了标号的需求使得需求能被跟踪,记录需求变更并为需求状态和变更活动建立度量。需求标识方法有序列号;层次化编码;使用"待确定"(to be determined, TBD )符号等。
4)记录业务规范:是指关于产品的操作原则,比如谁能在什么情况下采取什么动作。将这些编写成需求规格说明书中的一个独立部分,或一独立的业务规范文档。某些业务规范将引出相应的功能需求;当然这些需求也应能追溯相应业务规范。
5)创建需求跟踪能力矩阵:建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵,而不要等到最后才去补建。
这里我们还要介绍需求规格说明书中设计阶段,用到的图形模型--数据字典、数据流图、数据流图、状态转换图、对话图和类图。
数据字典:一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。数据字典的维护独立于软件需求规格说明,并且在产品的开发和维护的任何阶段,各个风险承担者都可以访问数据字典。它定义了原数据元素、组成结构体的复杂数据元素、重复的数据项、一个数据项的枚举值以及可选的数据项。
数据流图:是结构化系统分析的基本工具。一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集(存储),还有过程、存储、外部世界之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上,这种方法很适用于事务处理系统和其它功能密集型应用程序。
数据流图:描绘了系统的数据关系。分析实体联系图有助于对业务或系统数据组成的理解和交互,并暗示产品将有必要包含一个数据库。相反,当你在系统设计阶段建立实体联系图时,通常要定义系统数据库的物理结构。
状态转换图:实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时,状态就会发生改变,例如在特定条件下,接收到一个特定的输入激励。这样的系统是有限状态机的例子。大多数软件系统需要一些状态建模或分析,就像大多数系统涉及到转换过程、数据实体和业务对象。
对话图:在许多应用程序中,用户界面可以看作是一个有限状态机。在任何情况下仅有一个对话元素(例如一个菜单,工作区,行提示符或对话框)对用户输入是可用的。在激活的输入区中,用户根据他所采取的活动,可以导航到有限个其它对话元素。因此,许多用户界面可以用状态转换图中的一种称为对话图来建模。对话图描绘了系统中的对话元素和它们之间的导航连接,但它没有揭示具体的屏幕设计。
类图:面向对象的软件开发优于结构化分析和设计,并且它运用于许多项目的设计中,从而产生了面向对象分析、设计和编程的域。类图是用图形方式叙述面向对象分析所确定的类以及它们之间的关系
4. 需求验证
1)审查需求文档:对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表(如分析人员,客户,设计人员,测试人员)组成的小组,对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。
2)依据需求编写测试用例:根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽,并且确保所有测试结果与测试用例相一致。同时,要使用测试用例来验证需求模型的正确性,如对话框图和原型等。
3)编写用户手册:在需求开发早期即可起草一份用户手册,用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。
4)确定合格的标准:确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。 二、需求管理
需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准,这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功
能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁,需求管理包括在工程进展
过程中维持需求约定集成性和精确性的所有活动。
范文四:项目需求分析注意事项
项目需求分析模板
项目实施严格按软件工程的思想来进行,
软件工程之需求分析
需求工程分为需求开发和需求管理两个阶段:下面就以这两个阶段说明:
一, 需求开发
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤,当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。
1. 需求获取:
1)确定需求开发过程:确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤,并将它编写成文档。对重要的步骤要给予一定指导,这将有助于分析人员的工作,而且也使收集需求活动的安排和进度计划更容易进行。
2)编写项目视图和范围文档:项目视图和范围文档应该包括高层的产品业务目标,所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
表1 项目视图和范围文档的模板
a . 1 背景 在这一部分,总结新产品的理论基础,并提供关于产品开发的历史背景或形势的一般性描述。
a.2 业务机遇 描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案,并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。
a.3 业务目标 用一个定量和可测量的合理方法总结产品所带来的重要商业利润, 把重点放在给业务的价值上。
a.4 客户或市场需求 描述一些典型客户的需求,包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能(或不可能)出现的阐述,提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。
a.5 提供给客户的价值 确曲 定产品给客户带来的价值,并指明产品怎样满足客户的需要。
a.6 业务风险 总结开发(或不开发)该产品有关的主要业务风险,例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性,指明你所能采取的减轻风险的措施。
b.1 项目视图陈述 编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述
将考虑权衡有不同需求客户的看法。它可能有点理想化,但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。
b.2 主要特性 包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。
b.3 假设和依赖环境 在构思项目和编写项目视图和范围文档时,要记录所作出的任何假设。通常一方所持的假设应与另一方不同。
c.1 首次发行的范围 总结首次发行的产品所具有的性能。描述了产品的质量特性,这些特性使产品可以为不同的客户群提供预期的成果。
c.2 随后发行的范围 如果你想象一个周期性的产品演变过程,就要指明哪一个主要特性的开发将被延期,并期待随后版本发行的日期。
c.3 局限性和专用性 明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。
d.1 客户概貌 客户概述明确了这一产品的不同类型客户的一些本质的特点,以及目标市场部门和在这些部门中的不同客户的特征。
d.2 项目的优先级 一旦明确建立项目的优先级,风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面:性能、质量、计划、成本和人员。 e. 产品成功的因素 明确产品的成功是如何定义和测量的,并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务,还要包括外部因素。如果可能,可建立测量的标准用于评价是否达到业务目标.
3)用户群分类:产品的用户在很多方面存在着差异,例如:用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异,你可以把这些不同的用户分成小组。用户类不一定都指人,你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口,可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况,要将可能使都有所差异。详细描述出它们的个性特点及任务状况,将有助于产品设计。
4)选择产品代表:择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的,因为此时,用户就是身边的职员。而对于商业开发,就得在主要的客户或测试者中建立起良好的合作关系,并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一个产品代表者代表了一个特定的用户类,并在那个用户类和开发者之间充当主要的接口。
5)建立核心队伍:建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来,从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用,因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于,核心队伍成员通常没有决定权。
6)确定使用实例:让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例,讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版,在使用实例基础上可得到功能需求。
7)召开应用程序开发联系会议:召开应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会,也是分析人员与客户代表之间一种很好的合作办法,并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。
8)分析用户工作流程:分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图(最好用数据流图)来描绘出用户什么时候获得什么数据,并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。
9)确定质量属性:确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点,这
会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性,这是一种非功能需求。听取那些描述合理特性的意见:快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义。
10)检查问题报告:通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法,负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
11)需求重用:跨项目重用需求如果客户要求的功能与已有的产品很相似,则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
2. 需求分析
1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
2)创建开发原型:创建用户接口原型当开发人员或用户不能确定需求时,开发一个用户接口原型,这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
3)分析可行性:分析需求可行性在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
4)确定需求优先级:确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。
5)为需求建立模型:为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6)编写数据字典:创建数据字典数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
7)应用质量功能调配:使用质量功能调配质量功能调配是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备。
3. 编写规格说明书
项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件, 它不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制,软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。
1)采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意,其目的并非是创建一种全新的模板,而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE 标准830-1998(IEEE 1998) 描述的需求规格说明书模板。要相信模板是很有用的,但有时要根据项目特点进行适当的改动。
表2 需求规格说明模板
a. 引言
引言提出了对软件需求规格说明的纵览,这有助于读者理解文档如何编写并且如何阅读和解释。 a . 1 目的
对产品进行定义,在该文档中详尽说明了这个产品的软件需求,包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系,那么就只定义文档中说明的部分或子系统。
a.2 文档约定
描述编写文档时所采用的标准或排版约定,包括正文风格、提示区或重要符号。
a.3 预期的读者和阅读建议
列举了软件需求规格说明所针对的不同读者,例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。
a.4 产品的范围
提供了对指定的软件及其目的的简短描述,包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。
a.5 参考文献
列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档,或相关产品的软件需求规格说明。
b. 综合描述
这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。 b.1 产品的前景
描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员,是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品,或者是否是一个新型的、自含型产品。
b.2 产品的功能
概述了产品所具有的主要功能。其详细内容将在d 中描述,所以在此只需要概略地总结。很好地组织产品的功能,使每个读者都易于理解。
b.3 用户类和特征
确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。
b.4 运行环境
描述了软件的运行环境,包括硬件平台、操作系统和版本,还有其它的软件组件或与其共存的应用程序。
b.5 设计和实现上的限制
确定影响开发人员自由选择的问题,并说明这些问题为什么成为一种限制。
b.6 假设和依赖
列举出在对软件需求规格说明中影响需求陈述的假设因素(与已知因素相对立)。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定,但是另一个S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更改,就会使项目受到影响。 此外,确定项目对外部因素存在的依赖。例如,如果你打算把其它项目开发的组件集成到系统中,那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划) 中了,那么在此就可以参考其它文档。
c. 外部接口需求
利用本节来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口,那么应把这些外部接口的详细需求并入到这一部分的实例中。
c.1 用户界面
陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节,例如特定对话框的布局,应该写入一个独立的用户界面规格说明中,而不能写入软件需求规格说明中。 c.2 硬件接口
描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。
c.3 软件接口
描述该产品与其它外部组件(由名字和版本识别)的连接,包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。
c.4 通信接口
描述与产品所使用的通信功能相关的需求,包括电子邮件、We b 浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。 d. 系统特性
d.1 说明和优先级
提出了对该系统特性的简短说明并指出该特性的优先级是高、中,还是低。或者你还可以包括对特定优先级部分的评价,例如利益、损失、费用和风险,其相对优先等级可以从1(低)到9 (高)。 d.2 激励/响应序列
列出输入激励(用户动作、来自外部设备的信号或其它触发器)和定义这一特性行为的系统响应序列。这些序列将与使用实例相关的对话元素相对应。
d.3 功能需求
详列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能,使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输入或动作。就像本章开头所描述的那样,你必须唯一地标识每个需求。
e. 其它非功能需求
这部分列举出了所有非功能需求,如产品的易用程度如何,执行速度如何,可靠性如何,当发生异常情况时,系统如何处理,而不是外部接口需求和限制。
e.1 性能需求
阐述了不同的应用领域对产品性能的需求,并解释它们的原理以帮助开发人员作出合理的设计选择。
确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。你还可以在这里定义容量需求,例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求,而不是把它们都集中在一起陈述。
e.2 安全设施需求
详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作,还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。
e.3 安全性需求
详尽陈述与系统安全性、完整性或与私人问题相关的需求,这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。 e.4 软件质量属性
详尽陈述与客户或开发人员至关重要的其它产品质量特性。这些特性必须是确定、定量的并在可能时是可验证的。至少应指明不同属性的相对侧重点,例如易用程度优于易学程度,或者可移植性优于有效性。
e.5 业务规则
列举出有关产品的所有操作规则,例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求,但它们可以暗示某些功能需求执行这些规则。
e.6 用户文档
列举出将与软件一同发行的用户文档部分,例如,用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。
f. 其它需求
定义在软件需求规格说明的其它部分未出现的需求,例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错,以及登录和监控操作等方面的需求。
附录A :词汇表
定义所有必要的术语,以便读者可以正确地解释软件需求规格说明,包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表,并且只包括特定于单一项目的软件需求规格说明中的术语。 附录B :分析模型
这个可选部分包括或涉及到相关的分析模型的位置,例如数据流程图、类图、状态转换图或实体-关系图。
附录C :待确定问题的列表
编辑一张在软件需求规格说明中待确定问题的列表,其中每一表项都是编上号的,以便于跟踪调查。
2)指明需求来源:指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求,要都能追溯每项需求的来源,这可能是一种使用实例或其它客户要求,也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
3)为每项需求注上标号:为了满足软件需求规格说明的可跟踪性和可修改性的质量标准,必须唯一确定每个软件需求。为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全,允许增加、删除和修改。作了标号的需求使得需求能被跟踪,记录需求变更并为需求状态和变更活动建立度量。需求标识方法有序列号; 层次化编码; 使用" 待确定" (to be determined, TBD )符号等。
4)记录业务规范:是指关于产品的操作原则,比如谁能在什么情况下采取什么动作。将这些编写成需求规格说明书中的一个独立部分,或一独立的业务规范文档。某些业务规范将引出相应的功能需求;当然这些需求也应能追溯相应业务规范。
5)创建需求跟踪能力矩阵:建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这
个矩阵,而不要等到最后才去补建。
这里我们还要介绍需求规格说明书中设计阶段,用到的图形模型--数据字典、数据流图、数据流图、状态转换图、对话图和类图。
数据字典:一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。数据字典的维护独立于软件需求规格说明,并且在产品的开发和维护的任何阶段,各个风险承担者都可以访问数据字典。它定义了原数据元素、组成结构体的复杂数据元素、重复的数据项、一个数据项的枚举值以及可选的数据项。
数据流图:是结构化系统分析的基本工具。一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集(存储),还有过程、存储、外部世界之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上,这种方法很适用于事务处理系统和其它功能密集型应用程序。
数据流图:描绘了系统的数据关系。分析实体联系图有助于对业务或系统数据组成的理解和交互,并暗示产品将有必要包含一个数据库。相反,当你在系统设计阶段建立实体联系图时,通常要定义系统数据库的物理结构。
状态转换图:实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时,状态就会发生改变,例如在特定条件下,接收到一个特定的输入激励。这样的系统是有限状态机的例子。大多数软件系统需要一些状态建模或分析,就像大多数系统涉及到转换过程、数据实体和业务对象。
对话图:在许多应用程序中,用户界面可以看作是一个有限状态机。在任何情况下仅有一个对话元素(例如一个菜单,工作区,行提示符或对话框)对用户输入是可用的。在激活的输入区中,用户根据他所采取的活动,可以导航到有限个其它对话元素。因此,许多用户界面可以用状态转换图中的一种称为对话图来建模。对话图描绘了系统中的对话元素和它们之间的导航连接,但它没有揭示具体的屏幕设计。 类图:面向对象的软件开发优于结构化分析和设计,并且它运用于许多项目的设计中,从而产生了面向对象分析、设计和编程的域。类图是用图形方式叙述面向对象分析所确定的类以及它们之间的关系
4. 需求验证
1)审查需求文档:对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表(如分析人员,客户,设计人员,测试人员)组成的小组,对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。
2)依据需求编写测试用例:根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽,并且确保所有测试结果与测试用例相一致。同时,要使用测试用例来验证需求模型的正确性,如对话框图和原型等。
3)编写用户手册:在需求开发早期即可起草一份用户手册,用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。
4)确定合格的标准:确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。
二、需求管理
需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准,这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁,需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。
1.确定需求变更控制过程,确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程,商业化的问题跟踪工具都能支持变更控制过程。
2.建立变更控制委员会,组织一个由项目风险承担者组成的小组作为变更控制委员会,由他们来确定进行哪些需求变更,此变更是否在项目范围内,估价它们,并对此评估作出决策以确定选择哪些,放弃哪
些,并设置实现的优先顺序,制定目标版本。
3.进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的准确理解,帮助做出信息量充分的变更批准决策。通过对变更内容的检验,确定对现有的系统做出是修改或抛弃的决定,或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。
4.跟踪所有受需求变更影响的工作产品当进行某项需求变更时,参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例,这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会,这种变更在变更需求的情况下是必须进行的。
5.建立需求基准版本和需求控制版本文档确定一个需求基准,这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。
6.维护需求变更的历史记录记录变更需求文档版本的日期以及所做的变更、原因,还包括由谁负责更新和更新的新版本号等。版本控制工具能自动完成这些任务。版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本,必须清楚地将变更写成文档,并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传,应仅允许指定的人来更新需求。这些策略适用于所有关键项目文档。
7.跟踪每项需求的状态建立一个数据库,其中每一条记录保存一项功能需求。保存每项功能需求的重要属性,它包括状态(如已推荐的,已通过的,已实施的,或已验证的),这样在任何时候都能得到每个状态类的需求数量。
8.衡量需求稳定性记录基准需求的数量和每周或每月的变更(添加、修改、删除)数量。过多的需求变更" 是一个报警信号" ,意味着问题并未真正弄清楚,项目范围并未很好地确定下来或是政策变化较大。
9.使用需求管理工具商业化的需求管理工具能帮助你在数据库中存储不同类型的需求,为每项需求确定属性,可跟踪其状态,并在需求与其它软件开发工作产品间建立跟踪能力联系链。
范文五:用例需求分析注意事项
1、用例的分析
用例名称 下达订单 优先级 关键 用例编号 DUC001
销售业务员和门店店长通过PDA手持设备或登录快销平台WEB下用例简述 达订单。
下达订单用例
查询活动信息
新增订单销售业务员 平台操作员查询产品信息查询门店信息 订单确认门店店长 主要流程 替代流程 例外流程 非功能性系统响应时间不能超过3秒 需求 前臵条件 后臵条件 1,订单编号:用户ID+日期+流水号 2,订单状态:待提交、已提交,待审核,、审核中、已审核 业务规则 3,门店店长身份:6位数字 4,订单钱款=订单货物单价*订单货物数量*订单货物活动折扣 流程图 1.1流程的定义 主要流程:这是用例叙述最核心的部分,记载了整个用例正常的执行过程。 替代流程:一个用例叙述里,通常会包含一段主要流程,同时可以包含数段替代流程。 例外流程:例外流程跟替代流程不同,替代流程这条小路径的尽头会接回主要流程,可是一旦进入了例外流程之后,系统将不会继续执行完剩下的主要流程。也就是说,例外流程这条小路径的尽头不会接回主要流程。 1.2寻找替代流程或例外流程 如何寻找替代流程或例外流程,可以通过回答如下问题查找: 1.在这个流程步骤上头,是否还有其他替代的操作, 2.在这个流程步骤上头,是否会发生什么样的错误, 3.在整个用例执行过程中,是否随时可能发生其他未记录在叙述中的操作, 4.参与者输入数据时,是否会提供错误的数据,需要特别检查的, 5.参与者输入数据时,是否会提供不完整的数据,需要重新补上的, 6.参与者是否会在操作期间,临时中断流程, 7.参与者是否会在用例执行期间,随时取消交互, 8.参与者是否会想要挑选其他执行方法, 9.参与者在流程执行过程中,会不会有需要协助的地方, 10.系统发生宕机时,是否需要特殊的处臵, 11.系统响应时间过长时,是否需要特殊的应对方法, 寻找到的流程,如果回到主要流程,则为替代流程,如果不回则为例外流程,这是区分替代流程和例外流程的充分和必要条件。比如用例执行失败、异常、错误、网络异常导致系统执行超时等为典型的例外流程。 对于替代/例外流程需做务实的评估、可行性分析,避免钻“牛角尖”, 1.3非功能性需求 非功能性需求一般是在需求文档的整体部分叙述,但是如果本用例有特殊的非功能性需求,则需要在用例中进行具体的描述,所以该部分在用例中是一个可选项。 对于替代/例外流程需做务实的评估、可行性分析,避免钻“牛角尖”, 1.4前置条件 前臵条件:执行用例执行之前系统必须要处于的状态,或者要满足的条件。它必须是软件系统可以识别到的状态,如用例“入库”的前臵条件是“仓库管理员已成功登录”,而不能是“仓库管理员已打开电脑”,因为是否“打开电脑”库存管理系统不能识别到, 1.5后置条件 后臵条件:用例执行之后系统应该具备的状态,它也必须是系统能够识别到的,如用例“入库”的后臵条件是“系统保存入库信息,更新相关商品的库存量”,而不能是“用户退出系统”,因为“用户退出系统”不是“入库”操作所达到的系统状态。 1.6优先级 用例优先级分成三个:关键、一般、NTH,其中关键、一般的用例是必须实现的,NTH是可实现可不实现,具体是否实现在需求评审会议时决定。 1.7流程图 在用例中这是一个可选项,如果该用例的流程比较复杂,则必须绘制用例的流程图,以具体说明该用例如何执行。 2、可变性分析 以快销平台的订单提交举例,订单提报活动时依据类型、方式和收货方有三种可变性。如下:订单提报时,提报可变性如下 变化点 提交方式 变化点说明 有3种提交方式:手持终端、WEB端、客服。 手持终端的主要流程是:认证+实现方式的一般流程 WEB端的主要流程是:认证+实现方式的一般流程 客服端的主要流程是:认证+委托认证+实现方式的一般 流程 变量1 认证方式: 1,自我认证 2,委托认证 变量1依赖 强制:认证 属性分析 理由:系统的流程必须要经过认证 可选&可不选:委托认证 理由:只有客服方式下订单才要求委托认证 可选&必须至少选一:无 变量1绑定策略 部署绑定。 变量1绑定策略理开发量:小 由 使用度:频繁 灵活度/变化可能性,二次开发是否是今后问题,:小 管理方,售后服务,:开发公司 制约条件:委托认证需要客服支持 变量1策略使用建因为委托认证需要客服系统支持,所以开发公司可以开议 发出两种认证方式。通常是由开发公司在给客户部署时决 定,根据客户有无客服系统来进行绑定。 变量2 实现方式: 1,手机端实现,手机端实现需要考虑性能、暖存等变 量, 2,WEB实现 变量2依赖 强制:无 属性分析 可选&可不选:无 可选&必须至少选一:手机端实现、WEB实现 理由:两者选一即可走流程,但必须选一 变量2绑定策略 部署绑定。 变量2绑定策略理开发量:大 由 使用度:频繁 灵活度/变化可能性,二次开发是否是今后问题,:中 管理方,售后服务,开发公司 制约条件:需要手持PDA客户端支持 变量2策略使用建因为实现方式需要手持PDA客户端支持,所以开发公议 司可以开发出两种实现方式。通常是由开发公司在给客户部 署时决定,根据客户有无使用手持PDA的需求来进行绑定。 分析说明:订单提报分析是两个变化认证方式和实现方式,这是两个维度的变化,并且可以再次细化。 认证方式:1,自我认证,2,委托认证 实现方式:1,手机端实现,手机端实现需要考虑性能、暖存等变量, 2,WEB实现 转载请注明出处范文大全网 » IT项目需求分析注意事项研究