需求模型

状态机图(State Machine Diagrams)

状态机图将一个对象的动态行为描述为状态集合(a number of states)和在这个状态集合上的转移(transitions)。一个状态表示一个对象值的集合。对于一个具体状态,转移表示随着条件的 发生对象变迁到下一个状态。状态图关注的是当一个对象的外部事件发生时状态之间的转移。

是有限自动机(Finite state machine model)的扩展。

一个状态(state)是由对象的属性满足的条件。转变(transition)表示由事件,条件或时间触发的状态变化。

状态图(statechart)

状态图被D. Harel 定义,是一个具有层次结构和正交性的有限状态机(finite state machines)。

[D. Harel] Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8:231-274,1987

节点既可以是简单的点或者是一个包含其他状态图的复合节点。有一个初始节点。在状态之间可以进行转换,用一条有标记的边来达。e[c]/a。表示:如果事件e发生,并守护条件c保持,这个转换将被选择触发,这将导致采取一个动作a并发生状态改变。

用况图(Use Case diagrams)

从用户的角度来表示系统的功能视图。 他们定义了系统的边界。

Actor: 参与者是与系统交互的外部实体。 参与者的例子包括用户角色(例如,系统管理员,银行客户,银行出纳员)或另一系统(例如,中央数据库,制造线)。 参与者有唯一的名字和描述。

Use case:用例从参与者的角度来描述系统的行为。用例将系统提供的函数描述为一组事件,为参与者提供可见的结果。参与者启动一个用例来访问系统功能。 用例也可以启动其他用例,也可以从参与者中获取更多的信息。

Entry condition: 入口条件(也称为前置条件)描述了启动用例之前需要满足的条件。

Exit condition: 退出条件(也称为后置条伯)描述了用例完成后满足的条件。

Flow of events: 事件流描述了用例的相互作用的序列,这些序列将被编号以供参考。 为了清楚起见,在不同的使用情况下分别描述常见情况(即,用户期望的情况)和例外情况(即,用户意外的情况,例如错误和异常情况)。有的use case将这些不同情况分为场景(scenarios).

用例是用自然语言编写的。 这使得开发人员可以使用它们与通常不具有软件工程符号广泛知识的客户和用户进行通信。 自然语言的使用也使其他学科的参与者能够理解系统的要求。 自然语言的使用使得开发人员可以捕捉不容易在图表中捕捉到的东西,特别是特殊的需求。

scenario:

用例是描述涉及所描述功能的所有可能场景的抽象。 场景是描述一组具体操作的用例的实例。场景被用作说明常见情况的例子; 他们的重点是可理解性。 用例用于描述所有可能的情况; 他们的重点是完整性。

The results in a different use case model, with different Use cases, but describing the same scenario and considering the same actors. The writing style is different.

Both basic and alternative flows have a sequence of action steps, which are "a simple action in which one actor accomplishes a task or passes information to another actor". Each step represents either the request made by the actor or the reply of the system to the actor's request. Furthermore, the steps provide some of the data items involved in the interaction (for instance, that the customer orders a dish), being at a lower abstraction level than the steps of the Use cases in the original experiment)

类图(Class diagrams)

表示系统关于对象的静态结构,描述对象的属性、操作以及关系。

活动图(Activity diagrams)

是用来表示流经一个系统的数据流或控制的流程图

缺陷检测(Detecting Defects)

需求制品中存在的缺陷包括:

  • 省略:omission 一些重要的系统信息被省略。
  • 与事实不符:incorrect fact 与领域知识不一致
  • 不一致:inconsistency 有两处信息描述不一致
  • 模糊:Ambiguity
  • 无关信息:Extraneous Information

为检查需求描述中的缺陷,概念(模型相关)从需求文档(文本描述textual description或use case)中抽取出来。例如,类、对象、关系(继承、多态、聚合、组成。。。)

从构建的模型中,可以发现模型之间的不一致,以及检查模型是否充分的捕捉(capture)到了需求,发现一些条件不能满足而产生的设计缺陷。

需求不一致:包括与领域知识的不一致(领域表达,行业标准)和系统需求内部的不一致。

需求问题和产生的原因

10 Incorrect Requirements Developers make assumptions

11 Ill-defined System Scope Misunderstanding of system

from : An Iterative Approach for Global Requirements Elicitation: A Case Study Analysis

results matching ""

    No results matching ""