软件工程的需求获取

　　需求获取是系统必须具有的特征,是客户可接受的、系统必须满足的约束。需求工程的目标是定义所构造系统应该满足的需求求。一方面,需求工程包括两项主要活动:

　　第一步,需求获取,导出用户可理解的系统规格说明。

　　第二步,分析,其结论是定义开发者可无二义性解释的分析型。

　　在这两个活动中,需求获取更具有挑战性,因为需求获取需要在多个具有不同背景的参与者团队之间进行协作活动。另一方面,客户和用户是其各自领域的专家,对该未来系统应该做成什么样子有了总体考虑,但这些客户和用户通常在软件开发方面所具有的经验甚少。而与此相反,开发者在建构系统方面具有充分的经验,但对用户们的日常工作环境的知识知之甚少。场景和用例是弥补双方代沟的工具。一个场景使用了用户和系统之间进行的一系列交互,描述了一个系统实例。一个用例是描述一类场景的抽象。场景和用例两者均用自然语言描述,这一形式对用户户而言是可理解的。在本章中,我们将注意力放在基于场景的需求获取上。开发者通过观察和与用户的交谈,以获取需求。

　　开发者首先将用户当前的工作流程表示为不作修整的场景,随后开发出抽象的场景,以描述未来系统应该提供的功能。客户和用户通过审查场景和测试开发者提供的小型原型系统,以确认系统描述。当系统定义成熟和稳定后,开发者者和客户共同确认系统的功能性需求、非功能需求、用例和场景在内的需求规格说明。

　　需求获取是关于开发者、客户和用户之间为了定义新系统而进行的沟通。如果沟通的失效,或者如果理解彼此之间各自领域内容在系统中所起作用这一工作失效,将导致系统难以使用,这很容易导致支持用户所进行工作的失效。在需求获取的过程中,对所犯错误进行追踪和纠正,将花费高昂的代价,因为这些错误通常是在开发过程的后期才被发现这常常会造成交付延退。

　　这类错误包括诸如丢失了系统必须支持的功能、不正确的功能描述、引起误导或不可使用的用户界面,以及无用的功能等情况。需求获取方法的目标,在于提高开发者、客户和用户之间的沟通。通过对用户环境的观察,开发者构造了应用系统的领域模型。开发者选择了用户和客户易于理解的表达方式(如场景和用例)。

　　小编结语：其实，我们可以通过构造具有用户界面的简化系统原型,并通过从潜在用户处收集反馈意见,开发者可确认应用系统的领域模型。一个简化原型的实例,是该原型只具有对具有菜单和按钮的用户界面的布局潜在用户能够使用这些菜单和按钮,以感受该未来系统的用法,这日时的按钮对按下的动作并无实际反应,这是因为按钮所对应的功能，但现在并未实现的。