从需求分析看软件开发的挑战

需求阶段需要完成的任务

回顾一下需求分析阶段的过程，在需求分析阶段我们需要进行：

1. 绘制用例图以完成系统的功能建模。用例图由参与者，用例，系统边界以及箭头组成。在绘制用例图时需要识别系统的使用者，以及系统需要完成的功能。由于用例是对一组动作序列的描述，为了准确表达用例发生的条件和后果以及用例发生时系统产生的一系列动作，需要对用例进行准确性建模，即RUCM模型。为了确认和丰富用例图的一个使用情境的逻辑，进行顺序图的绘制。
2. 绘制类图对系统进行结构性建模。每个系统可能涉及很多角色、业务以及物品，这些事物之间有很多关系。类图能够帮我们识别出这些角色、业务、物品以及理清他们之间的关系。对于一个复杂的类，可能涉及很多不同的状态以及引起这些状态之间相互转换的原因，使用状态图能够清晰地描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。
3. 绘制业务场景活动图对系统进行行为建模。使用泳道图明确各个活动的使用角色，梳理用户场景时得到具体业务事件，在活动图中对业务过程的活动进行明确。

需求分析阶段的挑战

    领域分析偏差

        在领域分析阶段未能进行充分详细的讨论和调研，没有搞懂系统的领域定位，对系统开发的目标迷惑不解。由于领域分析的不完整和偏差导致后续的需求分析没法继续进行。存在这种偏差的原因我想是因为我们对特定的领域知识欠缺，在未科学的进行分析和调研之前，盲目的采取了经验或固有的认知。每个领域都有复杂庞大的知识体系，我们的时间和精力是有限的，如何在短时间内快速对某领域进行大致的了解？

 

    任务分配与协调

      在对系统进行功能建模、结构建模以及行为建模等的过程中，系统开发人员之间如何有效的协调和沟通以及任务分配，这对于经验不足的新手来说无疑是一个的挑战。按照任务类型分配还是按照业务分配将会是一个难题。如何能以最大效率和最高的符合度完成分配的任务以及任务之间的有效沟通也是一个难题。

 

    对业务的准确理解

     对于特定问题的业务可能是繁冗复杂的，所谓的隔行如隔山。如何准确的理解业务活动往往是一个艰难甚至反复的过程。业务不懂开发，而开发不懂业务，这之间的沟通成本是巨大的。为了使一项业务能够满足客户的需要，需求模型可能一改再改，甚至在开发完成后，也没能满足客户的需要，这对于双方来说都是一个沉重的打击。