【IT168 技术文章】

    6 Requirements Elicitation Composites

    6需求捕获的阶段组成

    Onsite Execution

    现场执行（下）

    Challenges Guidelines

    挑战 指导

    Requirements Conflict

    需求冲突

    1、 Business objective not clear to all

    2、 User groups not in sync

    3、 Gaps in requirements taken as assumptions leading to conflicts

    4、 Incorrect groups targeted for requirements

    5、 User group key person not identified for resolutions  1、 Include all stake holders in the onsite kick-off meeting and explain the business objective of the exercise to the group

    2、 Document business objectives and circulate to all stakeholders after validating it with top management

    3、 Conduct conflict resolution meetings and play the role of arbitrator explaining pros& cons

    4、 Highlight all open issues and assumptions in the requirements document

    5、 Perform stakeholder analysis and confirm with them your understanding of their responsibilities with current system

    6、 Define escalation criterion and use appropriately

    7、 Identify one point contacts from IT & business teams

    1、 并非所有人都清楚商业目标

    2、 用户组不同步

    3、 已取得的需求与期望要求之间的差距导致冲突

    4、捕获需求的目标用户组不正确

    5、 用户组的关键领导人无法解决争议 1、 在现场启动会议上对所有的风险承担人解释商业目标

    2、 与最高管理层确认商业目标后，将商业目标写成文档并传递给所有的风险承担人

    3、 召开冲突解决会议并充当中间人角色，解释冲突两方面的观点

    4、 在需求文档中，重点标示已有问题和假设

    5、 扮演风险承担人的角色，让他们确认你理解他们在目前系统中的责任

    6、 详细说明增加了的业务规则并保证能正确使用

    7、 确定IT工作和商业团队的结合点

    Stakeholder Identification

    风险承担人识别

    1、 Inadequate framework for stakeholder analysis

    2、 Lack of awareness of client structure 1、 Use standard templates and framework for stakeholder identification

    2、 Team shall go through the proposal thoroughly and identify anchors

    3、 Request BM/AM to conduct a team orientation session before onsite start

    4、 Kick-off meeting with client to include stakeholder identification

    5、 Inform all stakeholders of your understanding of their responsibilities with current system and kind of help required from them

    1、 缺乏适当的架构来识别风险承担人

    2、 缺乏对客户结构的认识 1、 使用标准模版和框架来识别风险承担人

    2、 项目团队应检查整个建议的风险承担人，并确定要重点关注的。

    3、 在现场执行前，请商务经理和销售经理(BM/AM)召开技术支援会议

    4、 现场启动会议要包括已识别的风险承担人

    5、 告之所有的风险承担人，你对他们在目前系统中的责任的理解，以及需要他们提供的帮助

    Onsite Reviews

    现场复审

    1、 No onsite reviews

    2、 Lack of interest from customer in reviewing artifacts 1、 Onsite review guidelines to be created

    2、 Include onsite reviews in project metrics

    3、 Prior to going onsite arrange for project team’s training on review mechanisms

    4、 Identify all kind of reviews required depending on the deliverables and assign team members accordingly

    5、 Conduct one round of internal review before a review with customer

    6、 Prepare review plan in advance and obtain customer agreement

    7、 Avoid multiple reviews of same artefact by customer. This will result in lack of interest and improper reviews

    1、 缺少现场复审

    2、 在复审现有提交物时，客户缺乏兴趣 1、 建立现场复审的指导原则

    2、 在项目开发的过程中要包括现场复审

    3、 在进行现场复审前，安排项目团队进行复审机制的培训

    4、 根据提交物的不同确定不同复审方式，并相应安排项目组成员参加复审

    5、 邀请客户参加复审前，先进行一轮内部复审

    6、 提前准备复审计划并得到客户同意

    7、 避免与客户多次复审同一个提交物，这可能导致大家缺少兴趣，产生错误观点

    X-Cultural Issues

    文化交叉问题

    1、 Not keeping the time

    2、 X-cultural aspects ignored

    3、 Uncomfortable with too much openness

    4、 Culture specific info not known

    5、 Interpreter used, essence lost 1、 Chart out do’s & don’ts in the beginning

    2、 Review adherence to the expected behaviour in periodic internal meetings

    3、 Brainstorm all known cross-cultural issues and prepare appropriate guidelines

    4、 Ensure X-cultural sensitivity training for all team members

    5、 Gather culture specific info from people having exposure to same customer or region

    6、 Record sessions involving interpreters to get a second opinion, if required

    7、 Use ABC interpreters trained on RE aspects

    1、 不遵守时间

    2、 有忽视文化交叉的观点

    3、 太开放而感觉不适应

    4、 不知道文化细节信息

    5、 使用翻译后，沟通失掉其本质 1、 在最初列出行为准则

    2、 周期性召开内部会议以鼓舞士气

    3、 集体讨论所有已知的文化差异问题，并提议适当的指导原则

    4、 对所有的项目成员队员进行文化差异敏感性培训

    5、 从了解相同客户和地区的人员那里收集文化细节信息

    6、 如果必要，录下有翻译人员参加的会议，这样可以进行再次分析

    7、 培训翻译员关于需求捕获的需求的知识

    Domain

    问题域

    1、 No BA involved

    2、 Requirements not detailed enough or incomplete

    3、 Access to knowledge assets

    4、 Team not in a position to make process improvement recommendations 1、 Include estimate of domain complexity in scoping

    2、 Arrange for Offsite reviews by domain experts

    3、 Involve business experts from customer’s team and create business process workflows during domain appreciation phase

    1、 缺乏商业分析（BA）人员

    2、 捕获的需求不够详细或不完整

    3、 获取信息的权限不具备

    4、 团队无法对工作过程的改进提出好的建议 1、 在项目范围中考虑问题域的复杂性

    2、 安排领域专家做场外评审

    3、 从客户团队中邀请商务专家在问题域可改进部分，创建新的业务流程

    Technology

    技术

    1、 New technology and no training

    2、 Technical architecture to be developed but no TA involved 1、 Get TA trained and let him train rest of the team

    2、 Include estimate of technical complexity in scoping

    3、 Involve groups like SetLabs for technical support from Offsite

    1、 新技术缺少培训

    2、 缺少技术架构师（TA）但需要开发新的技术架构 1、 寻找受过培训的技术架构师(TA)，让他培训团队中的其他成员

    2、 在项目范围定义时考虑到技术复杂性

    3、 从软件工程技术实验室这样的小组得到场外技术支持

    Miscellaneous

    其他

    1、 Conflict between customer’s business & IT teams

    2、 Conflict between two business groups

    3、 Antipathy towards ABC at client side

    4、 No system in place for interaction with CCD from onsite

    5、 Incorrectly set expectations by sales team

    6、 Not all type of requirements collected e.g. performance requirements 1、 Try to resolve conflict using CBA (Cost Benefit Analysis)

    2、 Define reverse sign-off criteria for artefacts

    3、 Identify escalation criteria and use appropriately

    4、 Obtain a list of CCD contacts for different purposes e.g. procurement, technical feasibility validation, connectivity issues, etc.

    5、 Involve Offsite team to follow-up with CCD

    6、 Expectations set shall flow through to RE team via BDM-AM. Set this as an agenda item for the Offsite team’s orientation meeting

    7、 Use pre-defined templates to collect performance requirements in absolute detail

    8、 Use Influx methodology for performance modeling

    9、 Conduct user activity study for detailed understanding & definition of the performance requirements. Spending a day with the users in their work environment and observing the pattern of their activities will give lot of inputs about workload modeling, user response time, system bottlenecks, system load Vs. time pattern & system response time requirements.

    1、 客户的业务部门和IT部门的冲突

    2、 两个业务部门间的冲突

    3、 对客户而言，讨厌工作变成机械性操作

    4、 联系的计算机和通讯部门（CCD）人员不在场，无法放置系统

    5、 销售团队不适当的期望植

    6、 并非所有类型的需求都收集了，例如性能需求 1、 采用成本利益分析的方法解决冲突

    2、 识别违反标准的提交物需求

    3 、 确认新扩展的业务标准，改标准正常的应用

    4 、 取得计算机和通讯部门（CCD）联系人列表来满足不同的需要，象采购，技术可行性验证以及连接问题等

    5 、 与场外人员联系应遵从计算机和通讯部门（CCD）部门安排

    6 、 产品期望值的设定要依次通过需求获取（RE）小组，商务开发经理（BDM）和销售经理(AM)。在场外的技术支援计划会议上，将设定产品期望值安排为一个议程

    7 、 使用预先定义的模版来收集性能需求

    8、 采用Influx方法来得到性能模式

    9 、 观察用户的活动，详细理解并识别性能需要，花一天时间与用户待在一起，观察他们的工作模式，得到工作量的模型，用户响应时间，系统瓶颈，系统负载与时间模式，以及系统响应时间的需要