系统需求建模和分析

1.****（10%）说明你目前研究的系统的问题描述(参考附件第11页)

研究的系统是公共区域自动售水系统。该系统的工作流程是，首先用户在数字键盘上输入产品的代码去选择购买的水的种类，然后根据提示完成线下支付。如果支付成功，自动售水机会将选中产品弹出，若找零钱，也会将余额弹出。用户取回产品和零钱即可。

该系统在软件开发过程中需要使用正规的需求工程方法，可以使用KAOS建模方法。

2.****（30%）给出该系统的目标模型（参考附件第3.2节，并说明你采用了哪些目标模式）

首先画出自动售水机的功能性需求和非功能性需求。并根据不同的策略将目标分解为子目标。这里用的是案例驱动分解，所有枚举的子目标必须完全覆盖父目标。例如，功能性需求和非功能性需求就需求覆盖到所有的需求。

图1中的叶子结点可进一步分解为子目标。

                               图1 一般目标模式

分析图1中的叶子结点“Cheap System”（图2）。该模式采用时间点驱动分解，首先需要建立系统，然后需要运行和维护系统。这个模式中说明了节省系统成本和系统的稳定性和可靠性是矛盾的。

                          图2 Cheap System目标模式

                          图3 Safe System目标模式

                        图4 Efficient System目标模式

图3和图4分别是对于“Safe System”和“EfficientSystem”的目标建模。对于“Safe System”，是要保证系统的健壮和可靠，然后还要保障系统的安全，其中涉及到安全支付以及防止其他人通过网络对该设备进行入侵。

“EfficientSystem”也需要保证系统的健壮和可靠，如果在顾客购买过程中饮料机出现问题需要重启，那么对造成顾客时间的浪费，用户体验就会降低。“Efficient System”同时需要基础服务程序的快速运行以及较快的饮料弹出时间。

whole

                        图4.1系统整体目标模式

考虑自动饮料贩卖机的一个具体问题，满足顾客购买饮料需求的场景。

                        图5 服务响应目标模式

图5中，为了实现响应用户需求的目标，首先需要提供用户接口，例如在屏幕上显示饮料的种类，付款方式等，用户可以通过点击屏幕进行选择，这项任务的责任人是系统设计者。在用户选择饮料完成付款开始弹出之后，系统不希望用户取消这个请求。在用户进行操作后，系统要捕获到这些请求并且通知用户请求现在正在处理的状态。

请求的状态分为以下四类：

(1)开始时，屏幕上要列出可以选择的饮料的种类，用户通过点击相应的选项进行选择。

(2)用户选择了饮料后，屏幕上出现付款方式，根据不同的饮料种类收取不同的费用。支付通过网上支付完成。

(3)用户完成付款后，屏幕上出现弹出饮料的提示，给用户一个反馈。

(4)饮料弹出完成后，界面上提示用户现在可以取出饮料。

采用的目标模式：

(1)．完成型目标：要求系统最终满足的性质。本系统要求最终能给顾客提供其所选择的饮料。

(2)．终止型目标：要求系统最终不再满足的性质。

(3)．维持性目标：要求系统始终满足的性质。本系统需要具有健壮性和稳定性，要保持其能正常工作。

(4)．避免型目标：要求系统从不满足的性质。避免系统出现宕机不工作的情况。

3.（10%）给出该系统的责任模型之一（参考附件第3.3节）

责任模型描述的是对于每一个agent,他需要负责的需求或者是对他的期望，也可以是分配给他的任务。

                    图6 饮料自动贩卖机公司的责任模型

图6中列出了饮料自动贩卖机公司需要负责则的任务需求。包括贩卖机机身的设计，提供内置程序及用户接口，对用户支付安全性的担保，机器出现问题时的解决方案，日常的更新和维护等。

4.****（10%）给出该系统的对象模型之一（参考附件第3.4节）

对象模型是用来定义和记录应用领域中相关的概念，提出概念间的静态约束从而满足设计需求。在对象模型中有三种对象共存，分别是实体、agent和关联。图7中显示，饮料自动贩卖机由屏幕、饮料弹出设备、控制器、电源组成，其中控制器由逻辑控制器（PLC）和计时器组成。

            图7 饮料自动贩卖机公司的对象模型

5.****（10%）给出该系统中主要对象的操作过程模型（参考附件第3.5节）

Kaos的操作过程模型描述的是agent需要满足的需求。

图8描述了自动饮料机的操作过程模型。为了节约能耗，当没有顾客的时候，饮料机是处在休眠的状态。当饮料机接收到顾客的触屏点击事件时，它被唤醒并且记录下顾客所选择的饮料种类。然后将用户选择的饮料信息传递给记录的实体“Guest chosen beverage record”。接着根据这一信息触发付款方式界面的显示这一事件，随即产生一个进程等待顾客付款，这个进程将顾客付款的状态传给“Guest payment record”实体记录。并且根据记录，如果顾客付款成功，可以触发弹出饮料的指令，产生弹出饮料这一具体操作。当饮料弹出完成后，产生“弹出完成”这一事件，并且通过这一事件触发通知顾客取饮料的操作，这一操作完成后，说明整个购买流程结束，产生“购买完成”事件。

                  图8 饮料自动贩卖机的操作过程模型

6.****（10%）给出该系统的目标实现的潜在障碍（参考附件3.6节）

障碍是指违反目标、期望或需求的情况。对于一个安全性的系统，处理潜在的障碍很重要，这使得分析员能在需求工程阶段解决可能发生的特殊情况，而不是在系统运行时出问题才来解决，从而保证系统的健壮性。

考虑到饮料自动贩卖机会如下潜在障碍：

(1)购买过程中发生停电的情况，贩卖机无法工作。

(2)顾客通过网上支付方式进行支付后，贩卖机出现网络问题，无法获取到支付状态信息。

(3)有人通过网络对贩卖机进行攻击，或是通过某些手段不付款就取得饮料。

(4)机器故障

其中网络故障又可以根据时间点具体划分：

• 顾客付款前网络故障，无法进行支付，不能完成交易

• 顾客向网上支付平台付款完成后，付款平台将支付状态反馈给贩卖机前发生网络故障。顾客已经支付，但是机器没有获取消息，支付状态不一致，不能完成交易。

• 贩卖机在收到顾客付款信息后网络出现问题，不影响本次交易。

根据上述的四点潜在故障，可以设计相应的解决措施。图9中显示的是不同潜在故障对应的解决措施。

• 对于停电的问题，可以提供备用电源。

• 对于网络故障，因为涉及到网络运营商，网络线路等方面，没有可以彻底解决这个问题的方案。但是可以通过保证支付状态的一致性来避免顾客的经济损失。

• 对于黑客的问题，可以提供系统安全性保障来防止系统被黑。

• 对于机器故障的问题，可以从两个方面考虑：首先是软件维护，经常更新系统，保证软件的运行；其次是要对自动饮料贩卖机的组件定期进行检查更换。

                    图9 构建稳定可靠的自动饮料贩卖机的解决方案

7. (20%)****参照IEEE标准模板撰写该系统的需求说明文档 （参考附件3.7节）

1. Introduction

1.1 Purpose

本系统的需求文档是为了更为清晰明确的阐述饮料自动贩卖机的需求，该文档可供系统设计开发人员使用。

1.2 Scope

该系统的目的是为顾客提供自动购买饮料的服务。使用的软件需要能控制饮料机硬件自动弹出饮料，并且能完成从顾客选择饮料，支付确认，弹出饮料，完成制作整个流程。

1.3 Definitions, acronyms, and abbreviations

1.4 References

李福丽,杨巧慧,赵莹莹.校园自动售货机投放的可行性研究报告[J].金融经济,2018,(18):52-53.

郝卓楠.一种自动饮料机的设计与实现[J].计算机与数字工程,2016,44(06):1190-1193.

1.5 Overview

本需求文档将分别从以下几个方面进行介绍。需求文档的第二部分先进行总体介绍：首先是对产品的整体描述，包括外部组件的交互，接口的定义以及产品整体结构的设计。其次介绍产品的主要功能，接着会介绍本产品的使用者的一些特征，包括他们的教育程度、社会经历和技术知识。之后会说明对本次产品的开发者的约束和一些其他因素限制。最后会说明在下一个版本出来时带的附加需求和对于软件开发人员和测试人员的具体需求。在第三部分对需求的细节进行描述。

2. Overall description

2.1 Product perspective

本产品的设计需要通过软硬件交互。首先软件控制整个饮料购买过程的工作流，包括顾客选择饮料的类型，顾客支付，产生指令传递给硬件开始弹出饮料，接收硬件传回的饮料弹出完成的指令，提醒顾客取饮料这几项功能。

硬件方面，首先需要的是能弹出饮料的一套硬件设备，并且提供可编程接口。其次需要提供与用户交互的显示屏，能提供触屏操作。

最后需要设计整个机箱来装载所有设备。

2.2 Product functions

本产品的主要功能是为用户提供自动饮料贩卖服务。即客户选择一款饮料付款后即可通过自动化操作来弹出饮料。

2.3 User characteristics

本产品面向的人群特征主要是中青年人群，首先用户要有购买饮料的需求，能接受自动化的饮料弹出方式，其次需要用户能使用如支付宝等网上支付方式。这类人群主要以学生和上班人群为主。

2.4 Constraints

对开发人员的限制，饮料机的软件系统需在单片机上进行嵌入式编程，这样可以降低硬件成本。

2.5 Assumptions and dependencies

开发人员需要考虑该产品的能耗问题，尽量降低能耗。同时也需要考虑支付安全的问题。

2.6 Apportioning of requirements

在之后的版本中，可能会添加饮料类型、支付方式等，所以需要软件设计有可扩展性。

3. Specific requirements

这一部分描述具体需求细节，本产品共有以下需求：

(1)没有用户时进入待机状态，降低能耗；

(2)有用户时能及时并正确地响应用户操作；

(3)根据用户的饮料类型选择能计算出付款金额，并有相应的用户付款界面；

(4)能判断用户支付是否成功，将支付状态反馈给用户，如果成功的话开始自动弹出饮料；

(5)在饮料弹出后提示用户取出饮料。