完整版CMMI3需求人员访谈加标准答案Word文件下载.docx

完整版CMMI3需求人员访谈加标准答案Word文件下载.docx

《完整版CMMI3需求人员访谈加标准答案Word文件下载.docx》由会员分享，可在线阅读，更多相关《完整版CMMI3需求人员访谈加标准答案Word文件下载.docx（12页珍藏版）》请在冰点文库上搜索。

同时要事先计划，才能有利的帮助你设计正确的题目从而得到你想要的结果。

●在设计问卷调查表时，应该尽可能的简单明了

简单明了的调查表有利于提高调查效率，不会使被访者那么容易失去兴趣。

●设计问题时，应该注意围绕调查目的

切忌问一些无关问卷调查目的的问题，以免让受访者反感。

问题的描述应该清楚，明了，尽量避免晦涩的术语。

●在整个调查表中保持评分选择题的一致性

评分选择题，是衡量和对比变量的一种有效手段。

如果你使用1-5评分选择，请一定在调查表中使用同样的评分选择；

不同的评分选择，会给受访者带来混淆，由此会影响调查结果。

●尽量使用选择题，但是也需要提供开放问题

我们提供了单项选择，多项选择，矩阵选择，评分选择，排序选择等多种题型，选择题有助于分析结果。

使用开放问题，可以让受访者有一个公平表达意见的机会，而不是被动的选择设好的选项。

●调查表的逻辑顺序

通常在调查表的欢迎页面对该调查表做一个简短的介绍，比如，“请填写下面的调查表，以提高我们产品的质量，从而更好地为用户服务”整个调查表的逻辑顺序，应该是从整体到细节，比如，你可以先问“你对我们产品的整体感觉怎样？

”，然后，在从产品的各项特征，来询问受访者的感受。

同时设计问卷调查表要满足4个要求

a）问卷能否提供决策的信息

b）虑到应答者

c）编辑和数据处理的需要

d）问卷服务于许多管理者

3.如何分析客户需求的？

由需求开发人员根据上一步需求调研的访谈成果，对用户的原始需求进行分析整理，提取需求的精华，对用户需求进行归纳总结，把相同的需求进行归类，并划分分析出的需求优先级（包括必须，可暂缓）,把文档尽可能的用容易理解的语言撰写。

按照归纳总结的用户需求点，需求开发人员开始编写《用户需求说明书》。

《用户需求调查单》作为《用户需求说明书》的附件，《用户需求说明书》需要通过用户签字确认、评审会议评审通过方可生效。

评审过程参照《同行评审过程》，从而进一步确认用户需求的优先集、合理性、约束条件和处理意见。

用户需求确认的两种方式：

1）用户直接参与评审2）给用户介绍需求请用户确认。

同行评审由项目经理邀请相关干系人参加，要对《用户需求说明书》中的内容逐条逐项进行验证，如果发现存在问题，则由需求开发人员继续调研，加以修改，直至评审通过。

4.用户需求书包含什么内容？

用户需求说明书是对用户需求的整理结果，由需求开发人员根据上一步需求调研的访谈成果，对用户的原始需求进行分析整理，提取需求的精华，对用户需求进行归纳总结，把相同的需求进行归类，并划分分析出的需求优先级（包括必须，可暂缓）,把文档尽可能的用容易理解的语言撰写。

包含用户提出的需求编号、用户需求描述、需求提出的岗位、人员、重要程度、以及需求之间的关系。

重要程度分为关键、重要、一般，关键需求为必须提供的需求，不提供客户不会付款的需求，重要的需求为不提供则客户不满意的需求，一般为可有更好的需求。

5.如何建立产品和产品组件需求？

●由需求工程师、系统架构师细化并分析用户需求

在这个阶段将从计算机实现的技术需要，针对用户需求将《久远银海公司用户需求分析报告》细化转换并映射为产品开发和设计、体系结构的技术实现的要求。

1）需求工程师、系统架构师、设计工程师对《久远银海公司用户需求分析报告》进行细化，描述用户群体的特征。

2）设计工程师经过分析确定：

n确定产品非功能性要求：

界面要求、软硬件环境等需求；

n确定产品的功能性能需求；

n分析每项需求实施的可行性，明确每项需求实现相联系的风险。

3）需求工程师与设计工程师识别需求组件的接口需求。

4）需求工程师与设计工程师识进行数据分析.

●分析和确认产品需求

1）项目经理邀请同行专家和用户（包括最终用户）对完成的《软件需求分析报告》（又称为《需求规格说明书》）进行评审，尽最大努力使《软件需求分析报告》（又称为《需求规格说明书》）能够正确无误的反映用户的真实意愿；

2）同行专家和用户对已完成的《软件需求分析报告》（又称为《需求规格说明书》）进行评审，确定产品需求实现的技术可行性、开发运行环境、费用、时间以及是否满足用户期望的产品运行环境分析技术解决方案；

3）对产品需求确认可以采用多种方式，如果参加评审的用户代表不能参加评审活动，可以通过邮件、书面表达的评审意见。

4）如评审结论为不通过，依据评审意见进行修改、再评审。

5）评审通过，开发方和用户方的责任人对《软件需求分析报告》（又称为《需求规格说明书》）做书面承诺。

6）将《软件需求分析报告》（又称为《需求规格说明书》）提交配置管理库中

6.如何分配产品需求的？

功能规划，根据之前任务中得到的业务需求信息对产品的功能及性能进行规划，划分出每次迭代版本将要实现的功能及功能优先级，以及对产品性能的要求。

当前迭代的功能点必须是明确的，相对而言，后续迭代的功能可以不那么明确，在每次迭代开始前进行重新整理和明确。

功能组件抽取，从业务无关的功能角度对产品功能进行分层次抽取和划分，提取可复用的功能组件。

需求小组根据《用户需求说明书》为客户需求建立产品构件。

界定功能需求和非功能需求，并规格化描述非功能需求、模块化描述功能需求。

需求小组对通过技术转化的需求建立相应的需求与产品构件的对应关系表，比如要实现客户要求的“100万条记录/秒”的查询速度，那么就需要前台查询模块和后台处理程序各承担一定的处理能力。

7.如何识别和定义接口需求的？

需求小组对接口需求进行分析，分别确定产品内部的产品构件之间、产品与外部产品之间的接口需求，记录到《需求规格说明书》中。

在项目中有XXXX接口（根据自己的项目表述）。

8.如何建立操作场景和操作概念的？

需求分析人员应采用自然语言（和应用域术语）来表达用户需求，相对于软件产品需求分析而言比较粗略，不够详细。

主要完成以下内容：

✧分离技术需求和非技术需求；

✧系统需求分析，根据情况，采用面向对象的分析方法或结构化分析方法，并辅与相应的图形化分析方法。

✧抽象系统需求，并要求能够覆盖所有的业务需求；

✧确定系统需求的范围；

✧从软件工程师的角度，确定每个系统需求用例的IPO，并逐一进行分析。

以下给出建议方法：

⏹集中讨论，列出用例的执行人/角色

⏹集中讨论，尽可能列出用例的所有用户目标

⏹考虑业务需求，编写概要用例，增加、减少或合并用户目标

⏹确定系统需求之间的前后置关系、包含关系和扩展关系

⏹选择一个用例进行扩展

⏹确定相关人员和利益、前提条件、最小保证和成功保证

⏹编写主成功场景

⏹集中讨论，尽可能列出所有的扩展条件

⏹编写扩展处理的步骤

⏹重复5－9，对所有用例进行扩展

⏹抽取复杂的处理流程作为子用例；

合并琐碎的子用例

⏹重新调整用例集；

进行必要的增加、减少和合并

✧确定系统需求的优先级；

✧从程序员（软件工程师）的角度，定义非功能性需求，包括性能需求、输入输出需求、数据管理能力要求、故障处理要求；

⏹系统架构师针对项目关注的质量属性要求，验证系统需求点符合要求。

✧用户业务基本需求分析的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。

⏹分析基本需求分析中的用例；

⏹划分系统模块；

⏹细化用例，发掘系统的功能点（也称为特性）；

⏹归纳、提炼、定义获得的功能点；

⏹验证功能点，确保获得的功能点是：

明确、完整、一致和无歧义、可验证；

⏹重复前5个步骤，直至能够合理描述系统的功能点。

⏹对功能点进行唯一性标识和优先级定义。

使用“必须的”、“重要的”和“可选的”的方式确定需求级别。

⏹定义系统的非功能需求。

9.如何定义功能性需求的？

功能性需求是说有具体的完成内容的需求。

例如：

比如客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。

在我们的项目包括XXX功能性需求（根据自己的项目表述）

10.如何定义性能需求的？

非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。

性能要求：

要求系统能满足100个人同时使用，页面反应时间不能超过6秒；

可靠性：

系统能7×

24小时连续运行，年非计划宕机时间不能高于8小时。

要求能快速的部署，特别是在系统出现故障时，能够快速的切换到备用机。

在我们的项目包括XXX非功能性需求（根据自己的项目表述）

11.如何对需求进行评审的？

按照公司的《评审规程》对《需求规格说明书》进行正式评审，评审组成员可以包括：

项目经理、系统架构师、测试工程师、软件工程师、部门经理、高级经理；

评审通过后由部门经理签发/批准《基线申请表》。

项目经理将部门经理签发/批准的《需求规格说明书》纳入到项目前期的配置库中。

12.如何对需求进行客户进行沟通的？

1）项目经理邀请同行专家和用户（包括最终用户）对完成的《需求规格说明书》进行评审，尽最大努力使《需求规格说明书》能够正确无误的反映用户的真实意愿；

2）同行专家和用户对已完成的《需求规格说明书》进行评审，确定产品需求实现的技术可行性、开发运行环境、费用、时间以及是否满足用户期望的产品运行环境分析技术解决方案；

3）对产品需求确认可以采用多种方式，如果参加评审的用户代表、销售代表不能参加评审活动，可以通过邮件、书面表达的评审意见。

3）如评审结论为不通过，依据评审意见进行修改、再评审。

4）评审通过，开发方和用户方的责任人对《公司产品需求分析报告》（或《公司面向对象产品需求分析报告》）做书面承诺

13.如何确认需求的？

14.如何保持所有人对需求一致理解的？

在获取需求后，有两种手段来保证所有人对客户提出需求的一致理解，第一种首先是沟通，所有人员定期的进行沟通，以确保需求的理解一致，在需求规格说明书完成后，由所有项目组人员参与并进行评审，在评审中对需求理解达成一致，对评审中发现的问题进行沟通，另外一种就是由需求人员进行讲解，讲解采用非正式的方式，针对提出疑问的人进行针对性讲解。

15.如何获取所有人员对需求的承诺的？

在所有人员都理解需求后，并且与客户达成一致理解后，所有人员包含客户需要对需求的范围、需求的功能、以及需求的实现先后顺序做出承诺，承诺尊重约定进行执行，如果过程中不能遵照约定时，如有突发事件发生时，则需要约定何等级别来对应处理相应的变化。

16.如何管理需求变更的？

变更分类：

根据变更的严重程度可以将变更分为主要变更和次要变更，变更会造成项目工作量增加2%以上或者会造成延期的定为主要变更，否则为次要变更。

项目经理根据变更申请表要求执行的变更事项、本质特征界定变更申请是否需要提交CCB讨论。

CCB审核次要变更，主要变更的审批需要CCB与部门经理一起进行。

变更申请人填写需求《变更申请书》将变更理由及变更的影响范围进行详细描述。

经项目经理确认后，如果属于主要变更，则提交CCB。

如果CCB同意了该变更申请，则由项目经理通知相关受影响的组和个人，组织项目组成员和需求开发人员进行需求变更工作，即重新进行需求开发、需求确认，更新《用户需求说明书》和《软件需求规格说明书》，需求开发人员及时更新《需求跟踪矩阵》。

如果变更申请被拒绝，CCB则需要在变更申请中说明理由，项目则继续按原计划进行。

配置管理人员根据配置项变更控制规程中基线变更的流程进行需求基线的变更控制。

次要变更只需提交需求《变更记录》。

17.如何跟踪需求执行的？

当《用户需求说明书》编写完成后，需求开发人员创建《需求跟踪矩阵》，需要填写具体功能编号，当前状态等，和概要设计、详细设计章节对应。

根据各项需求目前被完成的具体情况更新《需求跟踪矩阵》。

负责更新需求跟踪矩阵的人员可以是项目经理也可以是项目经理指定的人员，由他统一更新需求跟踪矩阵。

需求跟踪矩阵创建完成后，需求开发人员需要在以下时机成熟时更新该矩阵：

当新的基线创建发布后，将该基线下的工作产品与《需求跟踪矩阵》中的功能标题做出映射。

需求开发人员在每周例会上根据本周完成的需求或与此需求相关的工作产品完成情况更新《需求跟踪矩阵》。

在项目进入每个里程碑阶段（单元测试、系统测试、预结项目等）时，也要及时进行更新。

需求开发人员更改所有相关需求文档，以及相应的工作产品，使得每一个软件的需求均能够与后续工作成果保持一致。

当需求发生变更时，项目变更或者需求开发人员发现需求与项目实施过程存在不符合项时，也要及时更新《需求跟踪矩阵》。

18.如何确保需求与其他工作产品一致性的？

需求开发人员要周期性地检查需求文档与后续工作成果之间的变更不一致之处，检查工作可以从以下几个方面入手：

1）后续工作成果是否实现了需求文档中的需求；

2）后续工作成果是否实现了需求文档中不存在的需求；

3）后续工作成果是否正确实现了需求文档中的需求。

当需求开发人员发现了变更不一致问题时，需要将此变更问题记录在《需求跟踪矩阵》的“项目跟踪记录日志”中，并填写此问题检查人和检查结果。

如果该问题的检查结果出现“不一致”状况，采取措施消除不一致问题。

相关责任人在得到需求开发人员的通知后，需要根据问题的实际情况给出消除“不一致问题”的解决措施，需求开发人员则将该措施记录在《需求跟踪矩阵》的“不一致问题报告”中。

直到该问题得到切实的解决后，需求开发人员将问题的“跟踪检查结果”回填到此表格中。

19.公司对需求人员做需求有什么要求，或指导方针，原则等？

公司对于需求要求精确、所有涉众受益、确认后方可执行。

20.在做需求时有哪些计划需要遵循，以及计划的内容是什么？

遵循需求开发计划，需求开发计划包括在项目总体计划中《项目计划书》，是《项目计划书》的子计划，需求人员在评审完需求的可行性后做出了承诺，按照计划执行。

21.在做需求时，需要哪些资源？

需要参考资料，包括其他一些成熟产品，法律法规，软硬件工具等。

22.是否参加过需求方面的培训，具体培训内容是什么？

在做需求前，进行过需求过程和需求工具AXURE的培训。

23.如何管理需求产出物或需求工作产品的？

通过SVN进行提交，配置管理员定期发布基线。

24.如何汇报自己工作的，向谁汇报？

通过周报进行回报，周报主要包括进展，工作量，问题，风险，完成百分比。

25.QA如何检查需求人员工作的？

检查哪些内容？

QA通过检查单（《过程检查单》和《产品检查单》）来检查工作，发现工作中不依据规范执行的情况，记录到《不符合项跟踪表》中。

主要包括是否进行了需求调研，是否准备了调查问卷等。

26.需求过程中是否有裁剪？

无裁剪。