摘要：谁能描述下软件测试的软件需求分析使用的工具呢？ 1）原型设计模型工具交互原型设计软件 Axue RP Po 5 Axue RP 能帮助网站需求设计者，快捷而简便的创建 基于目录组织的原型文档、功能说明...

谁能描述下软件测试的软件需求分析使用的工具呢？

1）原型设计模型工具交互原型设计软件 Axue RP Po 5 Axue RP 能帮助网站需求设计者，快捷而简便的创建 基于目录组织的原型文档、功能说明、交互界面以及带注释的wiefame网页，并可自动生成用于演示的网页文件和wod文档，以提供演示与开发。

Axue RP 的特点是：快速创建带注释的wiefame文件，并可根据所设置的时间周期，软件自动保存文档，确保文件安全。

在不写任何一条html与javascīpt语句的情况下，考试，大提示通过创建的文档以及相关条件和注释，一键生成html pototype演示。

根据设计稿，一键生成一致而专业的wod版本的原型设计文档。

2)StaUML工具 可绘制9款UML图：用例图、类图、序列图、状态图、活动图、通信图、模块图、部署图以及复合结构图等。

完全免费：StaUML是一套开放源码的软件，不仅免费自由下载，连代码都免费开放。

多种格式影像文件：可导出JPG、JPEG、BMP、EMF和WMF等格式的影像文件。

语法检验：StaUML遵守UML的语法规则，不支持违反语法的动作。

正反向工程：StaUML可以依据类图的内容生成Java、C++、C#代码，也能够读取Java、C++、C#代码反向生成类图。

转载请保留：本文出自qaachitech的51Testing软件测试博客：http:www.51testing.com?170805 3)Visio 工具 Micosoft visio 可以建立流程图、组织图、时间表、营销图和其它更多图表，把特定的图表加入文件，让商业沟通变得更加清晰，令演示更加有趣。

4)FeeMind 工具 思维导图软件 Feemind是一实用的开源思维导图心智（MindMap）软件.它可用来作为管理项目（包括子任务的管理，子任务的状态，时间记录，资源链接管理），笔记或知识库，文章写作或者头脑风暴，结构化的存储小型数据库，绘制思维导图，整理软件流程思路。

什么是需求领导让我做软件需求。

怎么弄呀

软件需求的定义 IEEE软件工程标准词汇表（1997年）中定义需求为： （1）用户解决问题或达到目标所需的条件或权能（Capability）。

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

（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。

需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。

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

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

用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。

功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

软件需求各组成部分之间的关系如图所示。

作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

所谓约束是指对开发人员在软件产品设计和构造上的限制。

质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。

多角度描述产品对用户和开发人员都极为重要。

软件需求工程师应聘需要哪些知识？

应该了解软件工程的过程，软件需求的获取、分析、编写需求说明书（SPECIFICATION）和验证的关系及其迭代过程。

还应该了解用例（USE CASE）、类图、ER图等。

你可以买几本有关软件需求的书看看，如徐锋的《软件需求最佳实践——SERU过程框架原理与应用》等，供参考。

软件需求模式有哪些分类？

需求可以按多种方式分类（例如，按功能和非功能分类）。

使用需求模式有一个优点，如果对模式分类，自动就对使用这些模式的需求分类。

分类告诉我们一些使用模式的需求的本性。

使用这些分类的其他方式是按照分类找到需求以及统计需求。

人们喜欢统计（至少有一些人，通常他们是高级行政人员，我们应该让他们高兴）。

对系统的需求的统计可以在很多方面有用。

可以帮助大概了解系统的复杂性和规模。

为了这个目标，需要对每个需求标记所需统计的数值。

（需求管理工具通常定义一些额外的需求属性，然后对每个需求输入属性的数值，这是个乏味的工作。

）使用需求模式可以节省这方面的工作，因为使用模式产生的所有需求有共同的属性。

它们只需要在模式编写的时候定义一次。

这个信息记录在每个模式的“模式分类”部分。

一旦需求以这种方式标记，就可能搜索分类查找到符合条件的所有需求。

如何把模式中的分类信息传送给需求取决于如何保存需求。

（这留给读者练习）一个直接的办法就是把需求拷贝到excel中，添加一列确定需求使用的需求模式，对每一个分类添加一列。

（按模式名排序可以更容易一次处理多个分类数值。

） 本书中的需求模式只包含了少量的基本分类方式，定义在下面。

你可以定义自己额外的分类方式，并用它们对模式分类。

如果是这样的话，按照下面的方式编写合适的定义，然后把它们放在引用它们的需求模式的地方。

分类可以帮助使用需求的任何人，包括开发人员。

因此，不必要所有人都理解每一个分类。

基于这个原因，每一个分类要有一个主要读者，并且明确的陈述。

如果你不属于这部分读者，不要担心不能理解它的目的或者对它不感兴趣。

需求模式的分类需要合适和精确的定义，否则基于分类的统计就不可能可靠。

每个分类需要定义以下内容： 名称：分类的唯一的，明显的名称读者：关于谁可能对这个分类感兴趣的解释：目标是谁。

目的：描述分类使用的意图是什么。

允许值：定义在模式中这个分类可以有的值，解释它们的含义。

最通常的方法是定义数值列表。

数字的或者文字的或者任何其他数值都可以使用，只要读者了解这些数值的含义。

缺省值：如果在模式中的分类没有定义（明确陈述），这就是采用的数值。

这样可以不必在模式中明确的定义分类，如果这个分类只对相对少量的模式有意义（换句话说，就是只对少量模式重要）。

本书中用到三个需求模式分类，下面使用这种格式描述。

“功能”分类 名称：功能读者：对挑选系统功能感兴趣的任何人，或者对功能数量感兴趣的人。

目的：指出这种类型的需求是否定义了系统必须提供的功能允许值：是每一个这种类型的需求是功能需求。

可能是有些这种类型的需求是功能需求；有些不是。

编写一个模式时，小心使用这个值。

确定模式是否定义清楚了；可能应该分成两个，一个是功能部分一个是非功能部分。

否这种类型的需求不是功能需求缺省值：否 “普遍性”分类 名称：普遍性读者：软件开发人员目的：指出这种类型的需求是否是普遍性的（也就是说，适用整个系统）。

它的目的是提醒开发人员注意，不管他们正在开发系统的那一部分，这个需求都影响他们。

允许值：是这种类型的需求是普遍性需求。

可能是有些这种类型的需求是普遍性的，有些不是。

否这种类型的需求不是普遍性需求缺省值：否 “影响数据库”分类 名称：影响数据库读者：数据库管理员（以及软件开发人员）目的：指出这种类型的需求是否会影响系统数据库的设计。

它的目的提醒负责设计数据库的人员关注这些需求允许值：是这种类型的需求影响数据库。

可能是有些这种类型的需求影响数据库，有些不影响。

否这种类型的需求不直接影响数据库。

软件需求工程有哪些过程？

一、 开始 1. 项目经理根据项目特点，指定对过程表格的具体要求； 2. 项目经理制订项目的标准，包括：DTS（缺陷类型）、TRA（风险类型）、TRS（需求类型）等，在过程表格中按标准引用. 二、 计划 1. 计划经理估算需求开发时间； 2. 计划经理完成：SPT（进度计划）、TPT（任务计划），将计划数据录入PDS（项目计划摘要）. 三、 需求获取 1. 软件需求工程师搜集系统概要信息，填写REQ（需求获取概貌）； 2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA（需求获取分析）、RES（需求获取情节）、UIR（用户交互需求）； 3. 检查需求获取过程，并填写REC（需求获取检查）； 4. 如果检查不通过，从1.重头开始过程； 5. 软件需求工程师填写TRL（时间记录日志）、PIP（过程改进建议）； 6. 计划经理整理本阶段数据，录入SPT、TPT. 四、 需求分析 1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成REA（分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）； 2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR; 3. 检查需求分析，完成RAC（需求分析检查）； 4. 如果检查不通过，从1重头开始过程； 5. 软件需求工程师填写TRL、PIP; 6. 计划经理整理数据，录入TPT、SPT. 五、 协商 1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入NCR; 2. 软件需求工程师根据决议，修改REA等相关文档； 3. 如果有新的需求引入，需要重新进行需求分析阶段； 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT. 六、 需求评审 1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表； 2. 评审员各自评审分派的内容，将发现的问题录入DRL（缺陷记录日志）； 3. 评审小组负责人组织评审会议，各小组成员提交DRL并讨论； 4. 评审小组以IRF形式提交检查报表； 5. 软件需求工程师根据IRF修订相关文档； 6. 计划经理整理数据，录入TPT、SPT。

七、 需求文档编写 1. 软件需求工程师综合考虑功能需求和非功能需求，编写《软件需求说明书》 《软件需求说明书》的编写格式与要求，请参见具体的作业指导书。

2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行； 3. 如果检查不通过，从1重头开始过程； 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT。

八、 需求确认 1. 评审小组，对需求进行确认： l 确认每一个需求及相互关系； l 需求的总体质量达到标准。

将结果写到RVC。

2. 软件需求工程师根据RVC，修订需求文档，并最终通过； 3. 软件工程师为每一个需求设计测试用例，并录入TRF; 4. 相关人员填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT。

九、 配置管理 1. RD（需求文档）成为基线后，即纳入到配置管理； 2. 如果需要对基线RD（需求文档）进行修改，填写CCP; 3. 配置管理人员征求需求开发小组和其他相关人员（风险承担者）关于CCP的意见； 4. 如果所有人员通过CCP，则将需求文档的配置管理取出，并填写CCF； 如果否决需求，则填写RRF; 5. 软件需求工程师修改RD以适应新的需求 （可能包括REA等）； 6. 评审小组对修改的RD执行第八步； 7. 相关人员填写TRL、DRL. 十、 事后分析 1. 计划经理将DRL、TRL、需求增长率，整理到PPS; 2. 小组分析SREP过程，找出需要改进的地方，填写PIP，并提交质量经理； 3. 小组建立未来过程的改进目标.

会计从业资格考试软件需要著作权证书吗

、 注意对需求规格说明的正确性进行评审 需求规格说明的正确性通常可以从如下方面得以体现： 是否有需求与其他需求相互冲突或者重复？通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。

正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念， 可使术语列表贯穿整份文档以达提纲挈领之效。

是否清晰、简洁、无二义地表达了每个需求？ “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果，是让大家对需求描述的理解能够达成一致。

需求陈述是“三重门”，这三扇门是否开启决定了需求说明书的质量高低。

我们尤其要拒绝“二义性”的名词术语的出现， 似是而非的概念定义是需求书应该避免的。

换句话说，如果一份需求说明书没能给人以清晰、简洁和无二义的阐述，则需求评审是没有进行下去的必要，同时也无法进行下去。

需求评审的前提是用户读懂了需求说明，并且用户的理解内容就是分析师们所描述的内容。

是否每个需求都通过了演示、测试、评审，分析是否得到了验证？ 需求应该是可以测试的，通常通过测试去验证它是不是正确。

比如我们完成了“销售员客户佣金提成规则”需求的撰写，如果需求书未能经过原型测试通过，则需求评审是不能得到通过的。

面对相当复杂的业务需求，经过测试或演示是让用户信任的一个必要过程。

试想一下， 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。

是否每个需求都在项目的范围内？ 划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要环节。

是否每个需求都没有内容和语法上的错误？按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、 需求描述、优先级、来源和状态等。

通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。

在现有的资源内， 是否能实现所有的需求？ 需求规格说明要考虑可行性的问题。

事实上，分析师的关注层面是价值驱动和成本驱动方面。

分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。

国内有专家提出，搞需求也要讲“和谐”即是此中道理。

每一条特定的错误信息，是否都是唯一的和具有含义的？ 不要忽视错误信息的定义， 它必须具有唯一性。

如果过于笼统地定义错误信息则和没有定义的效果是一样的。

二、 注意对需求规格说明的实践性进行评审 所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度，而非源于分析师们经验主义的臆测。

实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。

如果需求规格说明和用户实践脱离，即使看上去写得再天花乱坠，也会使需求说明如同无根之树、无源之水，会大大减低用户对需求报告本身的信任度。

有经验的系统分析师通常会迷信自己的经验，把从前的经验嫁接到目前的企业需求分析中。

也许由于行业性质相同，但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。

因而不能为企业带来真正的价值，也会造成与用户需求的鸿沟。

笔者也曾经“轻实践重抽象”，我认为系统分析师的工作特点是站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务背景、流程和规则。

我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的（通过大量同类软件的分析得知），但还是需要分析师把抽象模型演绎到企业当前业务现状。

这样的需求分析才会有“实话实说”之效，才能引发评审者的共鸣。

否则，在需求评审中评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。

三、 注意对需求规格说明的完整性进行评审 我们经常由下面的问题清单来评审需求说明书是否“完整”。

1 编写的所有需求，其详细程度是否一致和合适？ 2 需求是否能为设计提供足够的基础？ 3 所有对其他需求的内部引用是否正确？ 4 是否包含了每个需求的实现优先级？ 5 是否定义了功能说明的内在算法？ 6 是否包含了所有已知的客户需求或系统需求？ 7 是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确定的问题（TBD）? 8 是否对所有预期的错误条件所产生的系统行为都编制了文档？ 需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢？我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

软件测试需要考什么证

软件评测师（国家软考认证）软件评测师考试属于全国计算机技术与软件专业技术资格考试（简称计算机软件资格考试）中的一个中级考试，是软件测试行业认可度比较高的一个证书。

软考属于专业水平的国家品牌考试，试题注重岗位知识和技能，综合性和灵活性强，创意多，如果有实际的工作经验，通过率会比较高，涉及考试的点还是很广的。

ISTQB（国际软件测试资格认证）有这个证书的话，进外企之类的一般比较有用，在国内，考这个证书的人数还是没有软件评测师高，而且考整个证书的花费很大。

ISTQB作为国际性的软件测试工程师认证，社会认可度还是挺高的。

越来越多的跨国公司和从事软件外测试外包的公司要求软件测试人员需要获得ISTQB认证。

PMP（美国项目管理协会项目经理认证）PMP(Project Management Professional)指项目管理专业人员资格认证。

它是由美国项目管理协会Project Management Institute(PMI)发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。

要想获得PMP专业认证，考生须达到美国项目管理协会（PMI）规定，对项目管理专业知识的掌握程度及其相应的工作经验和要求；另一方面，获得PMP证书的专业人员应继续从事项目工作，以不断适应项目管理发展的要求！总之，考这个证书的话，需要先进行一定的培训，总之，花费也是比较大的。

CSTE(QAI旗下的软件测试认证)CSTE全称Certified Software Tester，是QAI(Quality Assurance Institute)旗下的重要认证。

该全球范围的测试认证已经在美国、印度等颇为普及，成为很多公司对于测试从业人员的要求之一。

但是在中国，考这个证书的人只占了少部分。

CSTE的考试主要涉及了测试人员的基本知识和流程，考试全英文，包括四个部分，两个部分理论两个部分实践。

全英文试卷，对于软件测试的很多人来说，都会望而却步的。

关于计算机专业考试

资格考试要有一定的资质例如工作经验或者文凭等才能考，水平考试任何人都能考，不需要资质的支持。

网络管理员和程序员都是属于初级。

考下来并不代表能找到级别高的工作和拿到高月薪。

这需要看用人单位的人力资源管理办法。

详细请看：www.bjpta.gov.cn现在已经改为一年考两次，分别为5月的最后一个周日和10月的第1个周日

软件需求模式组特性是什么？

当几个需求模式有共同的特性，可以建立一个需求模式组，用于描述它们共同的方面，而不必在每个模式中重复。

一个需求模式组不是一个需求模式：不能建立这种类型的需求。

但是一个组可以包含下列出现在需求模式定义中的任何部分：“额外需求”，“开发考虑”，和“测试考虑”。

包括哪一部分而省略其他部分的原则是是否有一些事情值得说。

任何时候如果某一部分出现在了需求模式组里，模式的相应的部分应该包含一个注释，提醒参考需求模式组。

领域和需求模式组的区别在于领域中的模式共有一个主题，而在模式组中的模式有共同的细节特性。

一个组中的模式不一定属于同样的领域。

（对于熟悉Java编程的人，需求模式与领域的关系类似于类与包之间的关系：每个类属于一个包，就像每个模式属于一个领域。

同样，需求模式可以在属于不同领域的模式基础上开发，就像Java类可以继承自不同包的类。