案例综合题-系统分析
问卷调查不足：
1，缺乏灵活性。
2，双方未见面。
3，用户不重视。
3，不利于对问题的展开问答。
4，回答的数量往往比预期少。
用例建模描述各种参与者和系统之间的主要交互。
组件建模确定系统的子系统、模块和组件结构。为子系统或模块分配需求和职责。
服务建模提供了通用的应用程序，并将应用程序定义成一组服务接口。
性能建模是对系统的性能进行度量，为没个组件确定性能指标。
通过研究PIECES框架中类别或子类中的内容，可以发现企业中存在的各种问题。PIECES框架的内容如表所示。
类别 |
内容描述 |
性能 |
吞吐量：表示单位时间内处理的工作量 响应时间：完成一项业务或请求所耗费的平均时间 |
信息和数据 |
输出：缺乏任何信息 缺乏必要的信息 缺乏有关的信息 信息过多，即信息过载 提供信息的格式不符合要求 信息是不准确的 信息是很难产生的 信息的产生不是实时的，太慢了 输入： 数据是无法捕捉的 数据是无法及时捕捉的 捕捉到的数据是不准确的，包含了错误 数据的捕捉是非常困难的 捕捉到的数据是冗余的，即某些数据多次捕捉 捕捉到的数据太多了 捕捉到的数据是非法的，即不是通过合法途径捕捉到了数据 已存储的数据： 一个数据在多个文件或数据库中存储 己存储的数据是不准确的 已存储的数据是不安全的，容易遭到无意或恶意的破坏 已存储的数据的组织方式是不合适的 已存储的数据是不灵活的，即这些已存储的数据不容易满足新的信息的需要 己存储的数据是不可访问的 |
经济 |
成本： 成本是未知数 成本是不可跟踪的 成本过高 收益： 新的市场需求已经形成 当前的市场营销方式已经改进了 订单数量提高了 |
控制和安全 |
安全性机制或控制手段太少： 输入的数据是不完整的 数据很容易受到攻击 数据或信息可以轻而易举地被末授权的人使用，道德防线很容易突破 存储在不同的文件或数据库中的冗余数据之间是不一致的 无法保护数据隐私 出现了错误的处理方式（由人、机器、软件等） 出现了决策错误 安全控制手段太多： 复杂的官僚体制降低了系统处理的速度 控制客户或雇员访问系统的方法很不方便 过多的控制引起了处理速度的迟缓 |
效率 |
人或计算机浪费时间： 数据被重复输入或复制 数据被重复处理 信息被重复生成 人、机器或计算机浪费了物料 为了完成任务所付出的努力是多余的 为了完成任务所需要的物料是多余的 |
服务 |
当前系统生成的结果是不准确的 当前系统生成的结果数据是不一致的 当前系统生成的结果是不可靠的 学习当前系统是非常困难的 使用当前系统是非常困难的 当前系统的使用方式是笨拙的 对于新情况，当前系统无法处理 修改当前系统是困难的 当前系统与其他系统是不兼容的 当前系统与其他系统是不协调的 |
如果用底层系统处理处理子系统间的通讯：
1，异类系统间的交互性，如：不同操作系统的字节顺序、数据长度、数据表示方式。
2，通讯的可靠性。
3，通讯的安全性。
4，接口的可用性、易用性。
Linux和Windows相比，主要优缺点如下：
1，优点：系统性能高、网络应用能力强、价格便宜、可靠性高。
2，缺点：用户界面不友好、安装维护困难、售后和培训保障较差、配套应用程序少、第三方支持贫乏。
用例获取的基本步骤：
1，定义该应用系统的边界。
2，识别出改应用系统所有的角色。
3，对识别的每一个角色，分别确定：
a,改角色所参与的每一种业务活动。
b,各种业务活动的完整的事件序列。
c,激发上述每一个事件序列的角色。
4，对3中确定的事件序列进行分析，除掉其中重复的序列。
5，用结构化的自然语言描述4中确定的每一个事件序列，得到初步确定的每一个用例。
6，对5中确定的每一 个用例进行分析和重组，采用包含、扩展、慨括的关系表示用例直接的关系。
金融安全性需求有哪些？
1，验证 2，签名 3，授权 4，完整性 5，机密性 6，审查 7，不可否认性 8，威胁预防
