迷迷糊糊,跌跌撞撞,也要向前冲

发布新日志

  • telelogic doors 需求管理工具

    2008-06-23 16:23:39

         随着学习测试的深入,越来越觉得需求的重要。可是公司写的需求文档相当的混乱。也没有专人写,你不可能从需求那里了解输入输出。问开发,他们会跟我说,你看代码去,或者是说,你自己试下就好了。很是郁闷的呢。觉得忍无可忍,就上网查询如何写需求了,o(∩_∩)o...,看来不上梁山是不行了

        在一个论坛找到了Telelogic Doors的介绍,觉得似乎不错,就去找了地址下下来。可惜资料不多,就下了个入门的,但是也不错了。工具不是最重要的,重要是要自己知道怎么写需求。呵呵求爷爷告奶奶的,终于有个网友给我一个范本,豁然开朗。照猫画虎,拿公司的论坛下手,写了客户需求,详细需求分析文档。呵呵,同事看了,觉得清晰了不少。心理得意不少。

        简单说下,telelogic doors 是多人协作的软件,可以进行用户权限设置,方便需求管理,可以快速了解需求的变化,以后需求的历史版本最终。还有个重要功能,可以方便了解需求的覆盖情况。不错,满足我们的需要了,o(∩_∩)o...

        恩,对客户需求,我根据公司情况,把功能简单描述,然后加上用例图和流程图。详细分析的就要求写的更加详细,有用例编号,详细说明,前置条件,后置条件,主要用户,事件流,界面设计以及说明,特殊需求等。写下来,需求会更加清晰,开发和设计的一看,就一下就明白要做的东西的是什么样子了。

       只是,写需求期间,公司高层叫程序自己做测试。也许是自己的沟通不到位,但是也没办法。比较的失望,哎。不过还是学习到不少东西,给我自己的测试道路又前进了一步。

      

  • DOORS常见的问题

    2008-06-11 17:44:22

       前几天,在看需求,觉得需求是个很重要的事情,下了一些相关的书籍来看,查了资料,下了teleloginc DOORS,安装了以后写了需求,几经曲折,遇到不少事情。这里总结下来,希望以后有跟我一样遇到问题的朋友能避免下下。

    首先谈第一个:注册表丢失

       DOORS是讲究合作的,不支持离线编辑,这点让我蛮受伤的。因为我兴冲冲写了两天,结果,公司的网管要调整网络,断了几次网。每次断网,就提示我保存不了。这些之前没保存的信息就没了。郁闷啊,这个还不算什么,断了三次以后,居然提示连接不上服务器了。我是难过啊,自己找了很多网站资料,可是,DOORS本来就是重量级的,用的就少,差不到什么。我倒,后来终于在个论坛上看了下,说是可能是注册表的信息丢失。开始是看了下,心想,不可能吧。然后尝试了,PING服务器,可以PING通,36677端口是开着的。问题在哪里呢?我看不行了,把安装的软件文件夹备份下。就开始重装了,可是,重新装完,抱着满心的希望去试,还是链接不上服务器,我哭。不信,再装,再试,还是老问题。实在不行了,监听了端口,发现36677没有动静。查看事件查看器,发现报告是数据库路径找不到,端口未知。心理明白大半,赶紧的,去看了注册表。发现原来的POrtNumber的值为空,立马改回来,36677,serverdata也为空了。改为数据库安装的地址。重新试了下,可以链接上了。卖糕的,真是不容易!很想批评DOORS,真是的,居然有这样的BUG,后来尝试恢复自己的数据库,可惜,提示文件损坏,好郁闷,好重新写。

    第二个:无自动备份功能

       习惯了用微软的软件,都有自动备份的功能,要不也有自己备份菜单。可是,可是,我就是在DOORS里,找了半天,没找到,查找资料,没有。这个时候,我很想骂人,真是太讨厌了!但是没办法哦,谁叫我跟主管说它好呢,恨不得打自己嘴巴下下。想换都不行了,没办法。自己琢磨吧。

       安装文件夹半天,觉得那个VBDATA比较可疑,觉得应该数据库,于是压缩下。到服务器上覆盖,果然可以哦。原来可以这样备份哦,觉得,有点BT,嘿嘿。

    第三个:链接多个服务器

        恩,我本来是在自己的机子做试验,可是后来需要用的人多了,需要给领导装个,本着协同工作的思想,跟主管弄个服务器的空间装上去。发现自己怎么也链接不服务器那服务端,查了资料,应该是冲突。哎,真是郁闷,一点也不爽,都什么年代,看看TD多好哦,居然要我改注册表。哎,没办法了

    我用的是8.0版的,连接不同的服务器,是通过修改注册表的一个键值,
    分支:\HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS\8.0\Config\
    键名:Data
    键值:指定服务器开启的端口 @ 指定服务器的IP地址

    如果连接本地默认安装的服务器,键值应是:36677@127.0.0.1

       哦,就那么多了,下班了,以后有时间接着写吧。第一篇原创的哦,(*^__^*) 嘻嘻……。给自己鼓励下下

     

     

     

      

     

  • [转][DOORS需求管理工具的其他资料

    2008-06-09 11:59:31

    【来自】http://space.itpub.net/?uid-12639375-action-viewspace-itemid-149110

    DOORS 的独特之处:
    特色: 文档与属性可以在单一视图中显示
    特色: 支持电子签名
    特色: 在文档中可以看到可疑的链接
    特色: 可以同时打开多个项目文件
    特色 : 文件管理方式浏览数据库– 文件夹,目录树,不限制层次。
    特色 : 并行项目管理
    特色 : 可定制的视图,包括 :联接指针, 跟踪, 表格计算,变更工具条, 筛选,排序对需求管理工具的需求
    评估矩阵
    DOORS 其它Telelogic 注释
    1 用户界面
    工具提供智能导航来完成重复或复杂的工作吗?
    是 DOORS 提供很多智能导航:项目设置与配置导航,图形导航,可跟踪性与影响分析导航。
    2 文档处理
    用户是否能够像WORD 一样直接输入需求而无需在不同的屏幕与属性状态来回切换?
    是 对于熟悉文档处理工具的用户,这一点很重要。许多基于数据库的工具需要在独立的表格中输入单个的需求,而DOOR 可以直接连续地捕获需求。
    3 需求特定的功能
    用户能够在单一视图中浏览需求的上下文与属性及相关跟踪信息吗?
    是 DOORS 的强项在于其独特的文档与报表组合视图。通过提供在同一视图中浏览需求属性与跟踪链接可以大大提高效率。
    4 图片与表格
    图片能够作为需求并被链接吗?
    是 DOORS 能够嵌入OLE 对象,支持许多种图形,并把它们作为需求对象。
    5 配置管理
    用户能够恢复在历史列表中的变更吗?
    是 DOORS 能够恢复任何历史变更。它提供了强大的恢复功能。
    用户能够获得两个基线的比较报告吗?
    是 通过报告你可以很容易地发现需求的变更。
    6 管理变更
    用户能够找到变更依据吗?
    是 通过建立变更触发开关,可以通知用户变更信息。
    被批准的变更可以自动加入到文档中吗?
    是 通过变更流程,得到批准的变更可以直接被加入到文档中。
    7 输入方法
    用户能够手工与自动地输入信息吗?
    是 DOORS 可以从WORD 中直接导入文档,你也可以直接在DOORS 中创建文档。
    8 输出格式
    输出格式有那些?
    DOORS 支持许多输入与输出格式。其中包括WORD,PowerPoint 与Excel。
    9 打印
    能够直接打印高质量的文件吗?
    是 DOORS 可以直接打印报告而无需依赖其它工具。
    10 报告生成
    需求工具有智能向导来帮助用户生成报告吗?
    是 DOORS 提供智能向导来帮助新用户来完成各种任务,使用户能够轻易地输出各种格式的报告。
    11 属性与数据类型
    用户能够选择需要显示的属性吗?
    是 DOORS 可以通过视图显示不同的属性组合。
    工具允许用户一次设置一组属性吗?
    是 DOORS 可以一次设置一组属性
    12 查询, 排序与过滤
    用户能够快速找到任何一组子需求吗?
    是 任何项目一般都有大量的需求.对需求过滤可以快速找到所需的内容.
    用户能够根据属性来过滤需求吗?
    是 DOORS 可以在文档与需求属性中过滤出关键词。
    13 链接与跟踪性
    用户能够在不同文档间建立链接并直接看到这种链接吗?
    是 链接功能是需求管理工具的最重要功能,DOORS 可以直接查看链接而无需打开另一个窗口。
    用户能够通过拖放来建立链接吗?
    是 DOORS 提供多种链接方式。但是通过拖拉方式来建立是最直接的。用户也可以通过拖拉来COPY 与移动需求。
    用户能够快速看到变更对系统其它部分的影响吗?
    是 影响需要通过非直接的链接才能评估。一个需求的变更也许会影响到几个层次甚至到测试部分。你需要确保变更影响的分析不能只是下一个层次。
    14 生命周期的覆盖
    用户能够计算与显示各阶段的状态吗?
    是 需求的属性可以跨层次链接,能够显示每个阶段的实际工作。
    15 对测试的支持
    用户能够利用工具来生成测试用例来验证需求吗?
    是 你无需测试工具来跟踪从需求到测试的链接。一个好的需求工具将支持生成测试用例。
    16 与其它工具的接口需求工具与软件与系统工程工具的接口如何?
    是 DOORS 与绝大多数的软件与系统开发工具都有接口。
    17 对团队的支持
    需求工具支持团队功能吗?
    是 支持团队的需求与变更管理
    18 权限控制
    工具提供对任何信息的权限控制吗?
    是 对不同的人员有不同的权限
    19 分布式数据
    数据库可以在远端被操作吗?
    是 大型项目需要数据库分区功能,分区后可以重新归并到主数据库中。
    21 标准与模板
    用户能够快速生成主文档然后用它生成其它文档吗?
    是 DOORS 支持创建主文档,它被设为只读方式,可以用
    于创建其它文档。
    22 帮助与文档
    有在线教程与相关文档吗?
    是 DOORS 有快速入门的在线教程与相关文档。
    23 定制
    用户能够创建自己的界面或表格来输入或读取特定信息吗?
    是 DOORS 的扩展语言可以帮助实现这些功能。
    24 性能与扩展能力
    工具可以支持超过100,000 个需求及相关链接的大型项目吗?
    是 扩展性需要从两方面来看. 第一,数据库要能够装下大量的数据,第二,用户界面可以帮助用户浏览与管理大量的数据。
    25 平台
    用户能够同时工作在PC 与UNIX 平台上吗?
    是 DOORS 可以在UNIX 与Windows 同时共享数据。
    26 培训
    供应商提供需求方法论方面的培训吗?
    是 Telelogic 提供不同层次的方法论培训。
    27 安装与管理
    工具是否具有大量的成功客户?
    是 作为需求管理工具的市场领先者,DOORS 比其它工具拥有更多的成功客户。

  • 【转】Telelogic DOORS 8.1安装

    2008-06-04 16:23:32

    Telelogic DOORS 8.1安装

     

    我先安装的DOORS DATABASE SERVER,然后才安装的Doors Client

     

    1. Doors Database Server 8.1的安装步骤:

    (1)点击Doors Database Server 8.0 安装文件server_setup.exe 文件。

    (2)进入欢迎窗口,点击Next

    (3)进入License Agreement窗口选择“I accept the terms of the license agreement”选项,点击Next

    (4)进入Setup Type页面,保持系统默认选项,点击Next

    (5)进入Database setting页面,并在Port文本框中输入36677(好像是程序默认的),在Data文本框中通过Browse按钮选择本机的一个目录,例如(C:\doors),如下图所示:

    (6)按照系统提示,点击Next按钮,直到最后点击Finish按钮就实现了Doors Database Server在本机上的安装,然后接下来安装Doors Client

     

    2.Doors Client 8.0的安装步骤:

    (1)       点击Doors Client 8.0 安装文件client_setup.exe 文件。

    (2)       进入欢迎窗口,点击Next

    (3)       进入License Agreement窗口选择“I accept the terms of the license agreement”选项,点击Next

    (4)       进入Choose Destination Location窗口,如果选择系统默认的安装目录,直接点击Next,否则选择安装目录,然后点击Next

    5)进入License Information窗口,如图1所示,选择第二个选项,并填写19353@10.6.183.63 ,点击Next

    6)进入DOORS database settings 窗口,如下图所示。在Port项中填写36677,在Host项中填写本机的IP地址,点击Next

    7)进入Strat Copying Files窗口,点击Next,进入安装页面。

    8)等安装完毕,进入安装完成页面,如果选择了窗口上的 Creat a shortcut to Doors on the desktop选项,将在桌面上创建一个Doors的快捷方式,如下图所示,点击Finish按钮,Doors的安装完毕。

  • 【转】Telelogic Doors 8.0使用手记

    2008-06-04 16:18:46

        首先说明,当前TeleLogic已经发布了 Doors的最新版本为8.3,配套发布了Doors的Web服务端,但是申请试用非常麻烦,我这里所说的版本是8.0版本,这个版本在网上能够找到,鉴于版权问题,我不做更多的说明。

        Doors分成服务器端和客户端两个部分,服务器端安装的时候不需要License,但是客户端运行的时候需要License,在安装的时候可以使用Flexlm配套作为License管理,我安装的时候直接使用的是License文件,没有使用配套LM服务器。

       安装服务器非常简单,注意两个地方,第一个是端口号码,默认的是36677,然后需要指定需求文件数据库的存放路径,这里我设置了一个单独的盘路径来保存需求,我的目录为D:\Tools\Telelogic Doors。安装完成服务器端之后,这个目录还是空的,证明数据库还没有建立。

    然后安装Doors客户端,在客户端输入文件路径的授权,输入服务器的地址和端口号。完成安装。

    点击Doors8.0的菜单

    初次打开DOORS Client会出现如下提示

    这里是提示你马上是为超级用户设置口令并让你记得建立一个新的用户来登录,而默认的Administrator用户作为应急。

    点击确定进入下一步。我们可以看到,Doors服务器端的目录下建立和一系列的文件和目录。这些文件和目录是可以做备份并恢复的,这也是我一再强调这个目录的原因,我尝试关闭Doors客户端之后删除这些目录和文件,则导致Doors下次进入的时候自动重新初始化。

    OK,我们输入Administrator的新密码,然后进入Doors客户端的主界面,在菜单上点击用户管理,弹出用户管理窗口并开始建立一个新用户。

    输入我们的用户名和其他信息,为了省事,我选择的角色为 Database Manager,这个权限是很大的。

    然后退出,我们使用新建的这个用户重新登录到Doors客户端。开始准备新建一个项目。(注意啊,Doors的用户名和密码是大小写敏感的)

    我们点击新建项目的向导,向导给我们做了很多工作,我们可以使用现有的向导和模板创建我们的项目,

    输入必要的信息

    点击下一步,然后一步一步往下,完成这个项目的安装和设置。

    这样,一个完整的项目就完成了。

    我们来测试一下用法,双击Requirements,打开需求列表窗口

    建立一个新的用户需求

    然后打开设计Design模块,输入这个需求的设计内容。

    点击右键,开始建立设计和需求的关联

    然后在需求上点击右键

    建立完整的链接,这样,需求到设计的链接建立完成。

    基本功能就这些,呵呵,等着我慢慢研究慢慢折腾吧,Doors还是比较优秀的,但是钱钱太贵了,郁闷啊。

  • [转]软件项目的需求开发与管理

    2008-06-04 11:38:52

    软件项目的需求开发与管理

    blueski推荐 [2006-7-30]
    出处:CSDN
    作者:不详







    需求开发与管理是软件项目中一项十分重要的工作,据调查显示在众多失败的软件项目中,由于需求原因导致的约占到45%,因此,需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此,在项目开发工作中,很多人对需求的认识还远远不够,从本人参与或接触到的一些项目来看,小到几十万元,大到上亿元的软件项目的需求都或多多少的存在问题,有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因,以上种种原因都表明做好软件需求开发是一项系统工作,而不是简单的技术工作,只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识,并在实践中加以应用,才能真正做好需求的开发和管理工作。

    本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验,帮助读者了解软件需求,学习需求开发的一些基本方法,避免因需求原因而导致的项目失败。

    1.什么是软件需求和需求工程

    1.1 软件需求的定义

    在IEEE软件工程标准词汇表(1997年)中定义软件需求为:

    (1)用户解决问题或达到目标所需的条件或能力。

    (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。

    (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲,“需求”就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。

    1.2 需求工程的定义

    需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动,分为四个阶段:情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的,他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动,它包括:变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

    2.需求分析的风险

    由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点,因此,需求分析工作往往面临着一些潜在的风险。这些风险主要表现在:

    (1)用户不能正确表达自身的需求。在实际开发过程中,常常碰到用户对自己真正的需求并不是十分明确的情况,他们认为计算机是万能的,只要简单的说说自己想干什么就是把需求说明白了,而对业务的规则、工作流程却不愿多谈,也讲不清楚。这种情况往往会增加需求分析工作难度,分析人员需要花费更多的时间和精力与用户交流,帮助他们梳理思路,搞清用户的真实需求。

    (2)业务人员配合力度不够。有的用户日常工作繁忙,他们不愿意付出更多的时间和精力向分析人员讲解业务,这样会加大分析人员的工作难度和工作量,也可能导致因业务需求不足而使系统无法使用。

    (3)用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因,需求在项目的整个生命周期都可能发生变化,因此,我们要认识到,软件开发的过程实际上是同变化做斗争的过程,需求变化是每个开发人员、项目管理人员都会遇到的问题,也是最头痛的问题,一旦发生了需求变化,就不得不修改设计、重写代码、修改测试用例、调整项目计划等等,需求的变化就像是万恶之源,为项目的正常的进展带来不尽的麻烦。



    (4)需求的完整程度。需求如何做到没有遗漏?这是一个大问题,大的系统要想穷举需求几乎是不可能的,即使小的系统,新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来,这会导致开发人员在项目进展中去不断完善需求,先建立系统结构再完成需求说明,造成返工的可能性很大,会给开发人员带来挫折感,降低他们完成项目的信心。

    (5)需求的细化程度。需求到底描述到多细,才算可以结束了?虽然国家标准有需求说明的编写规范,但具体到某一个需求上,很难给出一个具体的指标,可谓仁者见仁,智者见智,并没有定论。需求越细,周期越长,可能的变化越多,对设计的限制越严格,对需求的共性提取要求也越高,相反,需求越粗,开发人员在技术设计时不清楚的地方就越多,影响技术设计。

    (6)需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解;另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和开发人员等项目参与者产生不同的期望,也会使开发、测试人员为不同的理解而浪费时间,带来不可避免的后果便是返工重做。

    (7)忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点,系统是由不同的人使用其不同的特性,使用频繁程度有所差异,使用者受教育程度和经验水平不尽相同。如果忽略这些的话,将会导致有的用户对产品感到失望。

    (8)需求开发的时间保障。为了确保需求的正确性和完整性,项目负责人往往坚持要在需求阶段花费较多的时间,但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑,他们往往会强迫项目尽快往前推进,需求开发人员也会被需求的复杂和善变折腾的筋疲力尽,他们也希望尽快结束需求阶段。

    3.如何做好需求工作

    需求分析是软件项目开发中最困难的一项工作,它不仅要求分析人员具有丰富的需求分析经验和良好的专业素质,还要求分析人员具有良好的学习能力、公关能力、语言能力和组织能力。在实际工作中分析人员要面对不同的单位、不同的部门、不同的人员、不同的文化、不同的关系、不同的管理水平等等不同的情况,面对如此纷繁复杂的环境,如何做好需求分析工作?首先需要建立一个有效的工作机制,只有建立了工作机制,才能保证需求工作按照既定方案执行,需求开发和管理的参与者才会在一种有序的状态下工作。其次才是充分运用工作机制和个人能力去获取问题、分析问题、编写需求文档和进行需求管理。

    3.1 建立需求分析工作机制需考虑的几个因素

    (1)抓住决策者最迫切和最关心的问题,引起重视。用户方决策者对项目的关心重视程度是项目能否顺利开展的关键,决策者的真实意图也是用户方的最终需求,因此,在开发过程中要利用一切机会了解决策者关心的问题,同时也要让他们了解项目的情况。在诸如谈判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的问题,引导他们了解和重视项目的开发,当决策者认识到项目的重要性时,需求分析工作在人力、物力、时间上就有了保障。



    (2)建立组织保障,明确的责任分工。项目开发一般都会成立相应的项目组或工程组,目前,常见的组织形式是:产品管理组、质量与测试组、程序开发组、用户代表组和后勤保障组,各组的主要分工是:产品管理组负责确定和设置项目目标,根据需求的优先级确定功能规范,向相关人员通报项目进展。程序管理组负责系统分析,根据软件开发标准协调日常开发工作确保及时交付开发任务,控制项目进度。程序开发组负责按照功能规范要求交付软件系统。质量与测试组负责保证系统符合功能规范的要求,测试工作与开发工作是独立并行的。用户代表组负责代表用户方提出需求,负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。

    (3)建立良好的沟通环境和氛围。分析人员与用户沟通的程度关系到需求分析的质量,因此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要,一般情况,用户作为投资方会有一些心理优势,希望他们的意见得到足够的重视,分析人员应该充分的认识到这一点,做好心理准备,尽量避免与他们发生争执,因为我们的目的是帮助用户说出他们的最终需要。在沟通时分析人员应注意以下几个方面:

    1)态度上要尊重对方,但不谦恭。谦恭可能会让用户一时感到满意,但对长期合作并没有好处,尤其是在发生冲突的时候,用户会习惯性地感到自己的优势,而忽略分析人员地意见。

    2)分析人员要努力适应不同用户的语言表达方式。每个人都有自己的表达方式,所以优秀的分析人员应该是一个优秀的“倾听者”,他们能很快的适应用户的语言风格,理解他们的意思。

    3)善于表达自己,善于提问。分析人员在开口前应该先让对方充分表达他的意思,在领会了后,自己再说,尽量不要抢话。

    4)工作外的交流有助于增进理解,加强沟通。

    (4)需求质量控制要制度化需求的变化是软件项目不可避免的事实,因此需求质量控制是一项艰苦的工作,要保证该项工作的顺利实施,就必须有制度保证,这个制度可以在项目质量控制方案中制定,该方案主要是具体化、定量化的描述用户要求,形成全面、一致、规范的软件需求分析规格说明书,明确需求分析规格说明书的工作程序和要素,规范开发活动,为后续软件设计、实现、测试、评审及验收提供依据。在方案中要明确项目组各部门关于需求质量控制的职责,制定需求分析的工作程序,包括编制需求分析工作计划、编制《需求分析说明书》、《需求分析规格说明书》的评审和确认、《需求分析规格说明书》修改控制、确定需求质量控制的质量记录文档规范等内容。



    3.2 需求开发与管理的一些方法

    需求开发是一项复杂的工作,使用的方法也很多,不同的开发方式有不同的方法,这里简单介绍一些相关的方法:

    (1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。

    (2)可行性分析:在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。

    (3)需求优先级:确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。

    (4)系统原型:当用户自身对有的需求不十分清楚时,我们可以建立一个系统原型,用户通过评价原型更好地理解所要解决的问题。。

    (5)图形分析模型:绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

    (6)数据字典:数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。

    (7)质量功能调配:质量功能调配是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。它将需求分为三类:期望需求、普通需求、兴奋需求。

    需求管理的目的就是要控制和维持需求事先约定,保证项目开发过程的一致性,使用户得到他们最终想要得产品。需求管理的方法主要包括以下一些方面:

    1)确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此过程。

    2)进行需求变更影响分析。评估每项需求变更,以确定它对项目计划安排和其它需求的影响,明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

    3)建立需求基准版本和需求控制版本文档。确定需求基准,这是项目各方对需求达成一致认识时刻的一个快照,之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。

    4)维护需求变更的历史记录。将需求变更情况写成文档,记录变更日期、原因、负责人、版本号等内容,及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传,应指定专人来负责更新需求。

    5)跟踪每项需求的状态。可以把每一项需求的状态属性(如已推荐的,已通过的,已实施的,或已验证的)保存在数据库中,这样可以在任何时候得到每个状态类的需求数量。

    6)衡量需求稳定性。可以定期把需求数量和需求变更(添加、修改、删除)数量进行比较。过多的需求变更"是一个报警信号",意味着问题并未真正弄清楚。

    4.需求分析评价标准

    如何判断需求规格说明的好坏,不同的软件工程规范都有自己的一套标准,这里向大家介绍一个比较常见的NASA SEL推荐方法,它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一,它对软件需求过程的评价标准是:清晰、完整、一致、可测试。

    (1)清晰:目前大多数的需求分析采用的仍然是自然语言,自然语言对需求分析最大的弊病就是它的二义性,所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。需求分析中的描述一定要简单,千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外,注意不要使用行话,就是计算机术语。需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。

    (2)完整:需求的完整性是非常重要的,如果有遗漏需求,则不得不返工,在软件开发过程中,最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是,需求的遗漏是常发生的事情,这不仅仅是开发人员的问题,更多发生在用户那里。要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各个方面,贯穿整个过程,从最初的需求计划制定到最后的需求评审。

    (3)一致:一致性是指用户需求必须和业务需求一致,功能需求必须和用户需求一致。在需求过程中,开发人员需要把一致性关系进行细化,比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

    (4)可测试:一个项目的测试从什么时候开始呢?有人说是从编码完成后开始,有人说是编码的时候同时进行单元测试,编码完成后进行系统测试,这些结论都不完全正确。实际上,测试是从需求分析过程就开始了,因为需求是测试计划的输入和参照。这就要求需求分析是可测试的,只有系统的所有需求都是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。
Open Toolbar