软件工程：分析人员与用户的合作合理性

深入实际是一项能了解社会和机构需求的观察技术，分析人员把自己放在待建系统的工作环境中，观察、记录参与者的实际任务。深入实际的价值是它能帮助发现隐性的系统需求，这些需求是实际存在的，但却是非规范化的过程。

优秀的软件产品是建立在优秀的需求基础之上的，而高质量的需求来源于客户与开发人员之间有效的交流与合作。通常，开发人员与客户间的关系反而会成为一种对立关系，双方的管理者都只想自己的利益而搁置用户提供的需求，从而产生摩擦。在这种情况下，不会给双方带来一点益处。

由于项目压力与日渐增，所有风险承担者有着一个共同的目标，这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使开发者感到满足的优秀软件产品。只有当双方参与者都明白要成功自己需要什么，同时也知道要成功使用方需要什么时，才能建立起一种合作关系。

下面列出9条在项目需求工程实施中，客户与分析人员、开发人员交流时的合法要求。

（1）要求分析人员使用符合客户语言习惯的表达。需求讨论集中于业务需要和任务，故要使用业务术语，客户可将其教给分析人员，不应要求客户一定要懂得计算机的行业术语。

（2）要求分析人员了解客户的业务及目标。通过与用户交流来获取用户需求，分析人员才能更好地了解客户的业务任务，以及使产品更好地满足客户需要的方法。开发人员和分析人员可以亲自去观察客户是怎样工作的。如果新开发系统是用来替代已有的系统，那么开发人员应使用一下目前的系统，这将有利于他们明白目前系统是怎样工作的，系统工作流程及可供改进之处。

（3）要求分析人员编写软件需求规约。分析人员要把从客户那里获得的所有信息进行整理，区分开业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析就能得到一份软件需求规约。要评审编写出的规约，确保它们准确而完整地表达了客户的需求。一份高质量的软件需求规约有助于开发人员开发出真正需要的产品。

（4）要求得到需求工作结果的解释说明。分析人员可能采用了多种图表作为文字性软件需求规约的补充，客户很可能对此并不熟悉，可以要求分析人员解释说明每张图表的作用或其他的需求开发工作结果和符号的意义，及怎样检查图表有无错误和不一致等。

（5）要求开发人员尊重客户的意见。如果用户与开发人员之间不能相互理解，关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们，并珍惜他们为项目成功所付出的时间。同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重与感激。

（6）要求开发人员对需求及产品实施提供建议，拿出主意。通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。在彻底弄清业务领域内的事情后，分析人员有时就能提出相当好的改进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性。

（7）描述产品易使用的特性。客户可以要求分析人员在实现功能需求的同时还要注重软件的易用性，因为这些易用特性或质量属性能使用户更准确、高效地完成任务。例如，客户有时要求产品要“友好”“健壮”“高效率”，但这对于开发人员来说，太主观且并无实用价值。正确的特性应是：分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性。

（8）调整需求，允许重用已有的软件构件。需求通常要有一定的灵活性。分析人员可能发现已有的某个软件构件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择，以便开发人员能够在新系统开发中重用一些已有的软件。如果有可重用的机会出现，同时客户又能调整自己的需求说明，那就能降低成本和节省时间，而不必严格按原有的需求说明开发。

（9）获得满足客户功能和质量要求的系统。每个人都希望项目获得成功，但这不仅要求客户要清楚地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制。一定要明确说明客户的假设和潜在的期望，否则开发人员开发出的产品很可能无法让客户满意。(www.xing528.com)

同时，在软件需求获取过程中客户有下列义务。

（1）给分析人员讲解自己的业务。分析人员要依靠客户讲解的业务概念及术语，但不要指望分析人员会成为该领域的专家。不要期望分析人员能把握业务的细微与潜在之处，他们很可能并不知道那些对于客户来说理所当然的“常识”。

（2）抽出时间清楚地说明并完善需求。客户很忙，经常在最忙的时候还得参与需求开发。但无论如何，客户有义务抽出时间参与“头脑风暴”会议的讨论，接受采访或其他获取需求的活动。有时分析人员可能自以为明白了客户的观点，而过后发现还需要客户的讲解，这时，请耐心一些对待需求和需求的精化工作过程中的反复，因为它是人们交流中的很自然的现象，何况这对软件产品的成功极为重要。

（3）准确而详细地说明需求。编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且又耗时，故很容易留下模糊不清的需求。但是，在开发过程中，必须得解决这种模糊性和不准确性，而客户恰是解决这些问题的最佳人选，不然的话，就只好靠开发人员去猜测了。在需求规约中暂时加上待定（To Be Determined，TBD，也可采用汉语拼音略写为DQD，即待确定）标志是个不错的办法，用该标志可指明那些需要进一步探讨、分析或增加信息的地方。不过，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志。尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将其写在软件需求规约中。

（4）及时地作出决定。正如一位建筑师修建房屋，分析人员将会要求客户做出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折中方案等。有权做出决定的客户必须积极地对待这一切，尽快做处理、做决定，因为开发人员通常只有等客户作出了决定才能行动，而这种等待会延误项目的进展。

（5）尊重开发人员的需求可行性及成本评估。所有的软件功能都有其成本价格，开发人员最适合预算这些成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极为高昂的代价。而某些需求试图在操作环境中要求达到不可能实现的性能或试图得到一些根本得不到的数据，开发人员会对此做出负面的证明或提出实现上便宜的需求。例如，要求某个行为在“瞬间”发生是不可行的，但考虑另一种更具体的时间需求说法（如在50 ms以内），这就可以实现了。

（6）划分需求优先级别。大多数项目没有足够的时间或资源来实现功能性的每个细节。决定哪些特性是必要的，哪些是得要的，哪些是好的，是需求开发的主要部分，只能由客户来负责设定需求优先级，因为开发者并不可能完全按照客户的观点决定需求优先级。开发者可为客户确定优先级提供有关每个需求的花费和风险的信息，在时间和资源限制下，关于所需特性能否完成或完成多少应该尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对这种现实的。业务决策有时不得不依据优先级来缩小项目范围、延长工期、增加资源或在质量上寻找折中。

（7）评审需求文档和原型。无论是正式的还是非正式的方式，对需求文档进行评审都会对软件质量提高有所帮助。让客户参与评审才能真正鉴别需求文档是否完整、正确地说明了期望的必要特性。评审也给客户代表提供一个机会，给需求分析人员带来反馈信息以改进他们的工作。如果客户认为编写的需求文档不够准确，就有义务尽早告诉分析人员并为改进提供建议。通过阅读需求规约，很难想象实际的软件是什么样子的。更好的方法是先为产品开发一个原型，这样客户就能提供更有价值的反馈信息给开发人员，帮助他们更好地理解需求。

（8）需求出现变更要马上联系。不断的需求变更会给在预订计划内完成高质量产品带来严重的负面影响。变更是不可避免的，但在开发周期中变更出现越晚，其影响越大。变更不仅会导致代价极高的返工，而且工期也会被迫延误，特别是在大体结构已完成后又需要增加新特性时。因此一旦发现需要变更需求时，请一定立即通知分析人员。

（9）应遵照开发组织处理需求变更的过程。为了将变更带来的负面影响减少到最低限度，所有的参与者必须遵照项目的变更控制过程。这要求不放弃所有提出的变更，并对每项变更进行分析、综合考虑，最后做出合适的决策，确定将哪些变更引入项目中。

（10）尊重开发人员采用的需求工程过程。软件开发中最具挑战性的莫过于收集需求并确定其正确性。分析人员采用的方法有其合理性，也许客户认为需求过程不太划算，但请相信花在需求开发上的时间是“很有价值”的。如果能理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

（11）系统分析人员在开发过程中可能会遇到这样的问题，一些很忙的客户可能不愿意积极参与需求过程，而缺少客户参与将很可能导致不理想的产品，故一定要确保需求开发中的主要参与者都了解并履行他们的义务。如果遇到分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦。