需求工程
2016-07-20 15:31:12 0 举报
图书馆活动图
作者其他创作
大纲/内容
AC220
public final int output = 220;public int outputAC() { return output; }
需求分析与评审
ConcreteTarget
public void request() { System.out.println(\"concreteTarget目标方法\"); }
需求开发是主线、目标,需求管理师辅助、支持与保障
问题识别
处理需求变更
“查询商品信息”和“维护商品信息”是扩展( extend )的关系,“更新商品信息”和“维护商品信息”是包含( include )的关系。请记住,扩展关系是指对于被扩展方(在这里指“维护商品信息”),扩展方(在这里指“查询商品信息”)是非必要实现的,也即没有“查询商品信息”,一样可以叫做“维护商品信息”。但是相对包含关系就不一样,“更新商品信息”对于“维护商品信息”来说是必须实现的一个用例,如果没有“更新商品信息”就没有“维护商品信息”了。此外,对于扩展关系,还有一个条件,就是扩展方应该在被扩展方用例实现的基础上进行的扩展。因此对于上图,若要表达的更清晰,则可以这样画:这样的结果,告诉了看这个用例的人一个这样的信息:更新商品信息后可以查询其他商品信息。请再看一个例子:这个用例图告诉了我们这样的信息:Step-1商品管理员首先要提取商品信息Step-2在提取商品信息的同时,需要获取商品单价,这是必须完成的Step-3提取商品信息后可以更新商品信息和打印商品信息Step-4对于打印商品信息而言合计商品总量是必须完成的一个工作
电压适配器
定义需求基线
必须划分别描述信息、功能、和行为模型
interface Target
+ void request();
需求规格说明书
ChinaPowerAdapter
public static final int voltage = 220;public boolean support(AC ac) { return (voltage == ac.outputAC()); }public int outputDC5V(AC ac) { int adapterInput = ac.outputAC(); //变压器... int adapterOutput = adapterInput / 44; System.out.println(\"使用ChinaPowerAdapter变压适配器,输入AC:\" + adapterInput + \"V\" + \",输出DC:\" + adapterOutput + \"V\"); return adapterOutput; }
必须按照自顶向下分析问题不断细化
需求分析阶段的工作(一):业务用例和系统用例
1.需求开发
对象适配器
interface AC
int outputAC();
Adapter
private Adaptee adaptee = new Adaptee();public void request() { //...一些操作... adaptee.adapteeRequest(); //...一些操作... }
需求获取调查问卷,小组会议,文档考古,现场观摩等
JapanPowerAdapter
public static final int voltage = 110;public boolean support(AC ac) { return (voltage == ac.outputAC()); }public int outputDC5V(AC ac) { int adapterInput = ac.outputAC(); //变压器... int adapterOutput = adapterInput / 22; System.out.println(\"使用JapanPowerAdapter变压适配器,输入AC:\" + adapterInput + \"V\" + \",输出DC:\" + adapterOutput + \"V\"); return adapterOutput; }
需求开发的原则
必须表示软件的行为
Adaptee
+ adapteeRequest()
2.需求管理
必须表达和理解问题的信息域和功能域
需求定义(编写需求规格说明书)
AC110
public final int output = 110;public int outputAC() { return output; }
需求跟踪
在这里要申明的是逻辑模型并不能完全算需求分析阶段的工作,因为它包含了设计模型的概念,但是我又把它归纳了一块到需求分析阶段,原因在于逻辑模型中存在了业务对象模型和分析模型的概念。言归正传,先来看用例模型。用例模型 用例模型包含了两部分:业务用例模型和系统用例模型。从字面的意义来看,确实很难分清两者究竟在做些什么工作。因此我们要重点解释一下。业务用例模型的目的在于:1. 描述企业的内部组织结构2. 描述企业各部门的业务3. 关注于角色和系统的交互界面系统用例模型的目的在于:1. 关注于演示对系统的需求2. 抛弃部门的功能,更加细化3. 系统用例模型应该划分子系统以对应不同的功能这二者最大不同点在于:业务用例模型仅关注于企业部门的业务,而系统用例模型则关注于系统本身实现后的互动。图素 业务用例模型和系统用例模型有共同的图素,但是在意义上是完全不同的角色:业务用例模型系统用例模型 对于角色来说,业务用例模型有两种角色的变体,分别是业务角色和业务员工。系统用例模型则没有业务员工,只有业务角色。而它们的含义又是不同的。 在业务用例模型中,业务角色代表企业外的角色,业务员工代表企业内的角色。例如对于商店来说顾客就是它的业务角色,而售货员就是它的业务员工。 在系统用例模型中,业务角色代表系统外的角色。例如对于销售管理系统来说,任何一个操作员都是业务角色,因为它不属于系统内。用例:业务用例模型系统用例模型 对于用例来说,业务用例模型因为需要描述部门的业务,因此它将使用一般用例的变体:业务用例。而系统用例模型则只需要使用用例的本体就可以了。二者的区别在于,业务用例的粒度很粗,它只描述部门的总体业务;用例的粒度很细,需要描述到系统中业务场景的工作。 业务用例模型工作流程Step-1 :创建业务用例对象模型的包 使用包的变体“ Business Use Case Model ”:Step-2 :创建用例对象的角色 创建业务员工和业务角色。Step-3 :创建组织结构图 制作业务用例模型时,需要通过扩展的关系来将各个业务员工和业务角色组织起来,形成组织结构图。(说明:需要通过抽象将业务员工的组织关系描述得清晰一些,而业务角色可能没有阶层的关系)组织结构图的包应该使用包的变体“ organization Unit ”:Step4 :创建业务用例 使用业务用例和业务员工、业务角色来粗略的描述部门的业务工作。 系统用例模型工作流程Step-1 :创建系统用例对象模型的包 直接创建包就可以了:Step-2 :创建用例对象的角色 创建业务角色Step-3 :创建系统用例 使用业务角色和系统用例来详细描述系统的工作,业务角色对用例的关系应该设置为“ use ”,系统用例之间的关系将使用“extend ”、“ include ”来描述。 系统用例的名字很重要,因为它将直接影响关系的描述。(在任何一个项目开展时都要对名字本身进行约束,动宾结构,还是主动结构) 比如:有一个系统用例,名为“维护商品信息”,显然如果有一个业务角色为“商品管理员”,那这个业务角色对“维护商品信息”的信息就应该是: 而“维护商品信息”这个用例的粒度太粗,因此还需要细化它,假使,“查询商品信息”和“更新商品信息”都和“维护商品信息”是有关系的,那么它们之间的关系就应该使用“ extend ”、“ include ”来描述。请先看下图: “查询商品信息”和“维护商品信息”是扩展( extend )的关系,“更新商品信息”和“维护商品信息”是包含( include )的关系。 这样的图示说明了什么?请记住,扩展关系是指对于被扩展方(在这里指“维护商品信息”),扩展方(在这里指“查询商品信息”)是非必要实现的,也即没有“查询商品信息”,一样可以叫做“维护商品信息”。但是相对包含关系就不一样,“更新商品信息”对于“维护商品信息”来说是必须实现的一个用例,如果没有“更新商品信息”就没有“维护商品信息”了。此外,对于扩展关系,还有一个条件,就是扩展方应该在被扩展方用例实现的基础上进行的扩展。因此对于上图,若要表达的更清晰,则可以这样画:这样的结果,告诉了看这个用例的人一个这样的信息:更新商品信息后可以查询其他商品信息。请再看一个例子:这个用例图告诉了我们这样的信息:Step-1商品管理员首先要提取商品信息Step-2在提取商品信息的同时,需要获取商品单价,这是必须完成的Step-3提取商品信息后可以更新商品信息和打印商品信息Step-4对于打印商品信息而言合计商品总量是必须完成的一个工作
需求验证与客户确认签字
public void request() { //...一些操作... super.adapteeRequest(); //...一些操作... }
interface DC5Adapter
boolean support(AC ac);int outputDC5V(AC ac);
类适配器
需求分析业务需求分析成开发需求
要给出系统的逻辑和物理视图
分析与综合
分析过程应该从要素到细节实现
0 条评论
下一页