信息系统开发—需求获取

需求获取是在问题及其最终解决方案之间架设桥梁的第一步,其实质是理解项目中描述的客户需求。一旦理解了需求,分析者、开发者和客户就能探索出描述这些需求的多种解决方案。需求获取主要涉及系统分析员，他们同系统用户和所有者一起工作，在系统开发的早期阶段确定对信息系统的业务需求的详细理解。需求获取是一个需要高度合作的活动，只有通过有效的客户—开发者的合作才能成功。

Demand acquisition is the first step to build a bridge between the problem and its final solution, and its essence is to understand the customer needs described in the project. Once the requirements are understood, analysts, developers, and customers can explore multiple solutions that describe these requirements. Requirements acquisition mainly involves system analysts who work with system users and owners to determine a detailed understanding of the business requirements of the information system in the early stages of system development. Demand acquisition is an activity that requires a high degree of cooperation. Only through effective customer-developer cooperation can it succeed.

系统需求可以从两方面理解,即用户角度(系统的外部行为)和开发者角度(系统内部特性)。从用户视角来看,系统需求是指解决用户问题或者达到用户目标所需的条件和能力。从开发者视角来看,系统需求是指满足合同、标准、规范或其他正式文档所需具有的条件或者能力。需求包含三个层次:业务需求、用户需求、功能需求(及非功能需求)。

业务需求反映了组织机构或客户对系统、产品的高层次目标要求,可以在项目视图利口范围文档中进行说明。用户需求文档描述了用户使用产品必须完成的任务,在用例文档或者应用场景中予以说明。功能需求定义了系统必须实现的软件功能,使得用户可以完成他们的任务,从而满足业务需求。

功能需求是指系统能够实现的基本功能和完成的任务。

非功能需求是指衡量系统能否良好运行的定性指标。因此,非功能需求也是非常重要的。但是在实际收集需求信息时,开发人员往往注重于功能性需求。而容易忽略非功能需求。这是因为非功能需求很难定义,也很含糊,如可靠性、易使用性、用户界面友好等问题上是软件系统应具备什么样的可靠性?易使用到什么程度?什么样的用户界面才算是友好？这些问题由于缺乏定量指标,因此很难根据这些需求来评价软件系统，这也是开发出来的软件系统与用户所要的软件系统之间存在差异的主要因素。

System requirements can be understood from two aspects, namely, the user's perspective (the external behavior of the system) and the developer's perspective (the internal characteristics of the system). From the perspective of users, system requirements refer to the conditions and capabilities needed to solve user problems or achieve user goals. From the developer's perspective, system requirements refer to the conditions or capabilities required to meet contracts, standards, specifications or other formal documents. Requirements include three levels: business requirements, user requirements, functional requirements (and non-functional requirements).

Business requirements reflect the high-level target requirements of the organization or customers for the system and products, which can be described in the project view scope document. The user requirements document describes the tasks that the user must complete to use the product, and it is explained in the use case document or application scenario. Functional requirements define the software functions that the system must implement so that users can complete their tasks to meet business needs.

Functional requirements refer to the basic functions and tasks that the system can achieve.

Non-functional requirements refer to qualitative indicators that measure whether the system can perform well. Therefore, non-functional requirements are also very important. But when actually collecting requirement information, developers often focus on functional requirements. It is easy to ignore non-functional requirements. This is because non-functional requirements are difficult to define and very vague, such as reliability, ease of use, user-friendly interface and other issues, what kind of reliability should the software system have? How easy to use? What kind of user interface Is it friendly? Due to the lack of quantitative indicators for these problems, it is difficult to evaluate the software system according to these requirements. This is also the main factor for the difference between the developed software system and the software system required by the user.

参考资料：百度百科、《信息系统开发—方法、案例与实验》

翻译：谷歌翻译

本文由LearningYard新学苑原创，部分图片来源于他处，如有侵权，请联系删除。