浏览：6542007-11-29 12:28   来自斧头帮少帮主      :

昨天刚刚开始一个项目(公司内部用),有了基本的需求,这两天让我们补充需求.

基本需求文档有了,我就自己画了一个Use Case,发现有一些跟需求有出入,也增加了点需求.
现在的问题:
在提需求或者说需求整理阶段,有必要画UC吗?
(如果只读需求文档,看的头都大了,没有UC直观,但是UC是从总体上显示的,没有细节.但文档上有细节.)
答(总结的回复):想画就画,目的是有效沟通.

 

假设需求文档都写好了(抛开了第一个问题)【意味着需求调研结束】
问题:
UC只能从总体上描述系统吗?我可以再画更细的UC吗?就是模块化某个大的功能.还是直接从一个总体的UC就开始画类图?

 

 

 

 

楼主
  5个月前   坚持信念      :
如果直接从UC上画出类图来，要么系统巨简单，要么÷画出来的类图不会在后面的编码工作中起到任何作用（仅仅是让文档上有了东西）

此外，没有看懂你具体想问什么。是想问如何做需求调研呢？还是想知道需求分析阶段要画什么图？或是别的什么东西？

PS：UML不只有Use Case Diagram和Class Diagram；另外，最好不要把需求调研跟需求分析混为一谈……
回复  1楼 回到顶楼 
  5个月前   潜水游      :
@坚持信念
说的是呀，我现在也启动了一个项目，很小，正在做前期的需求分析。
回复  2楼 回到顶楼 
  5个月前   斧头帮少帮主      :
@坚持信念
现在是需求调研阶段,你的意思是不画UML图先?

回复  3楼 回到顶楼 
  5个月前   坚持信念      :
不是说需求调研阶段不用画图，至少不要急着画
最好是先弄明白客户给的那些需求再说（客户总会给点东西出来的吧？）
然后抓住需求中那些不明白的问题猛问
然后就是画BUC了，差不多也可以UC了，当然这些都是一些比较主干的，这个阶段需要画的图至少还要有Active Diagram或Sequence Diagram，毕竟我们所做的系统不可能一点流程没有吧？这些东西加起来就差不多齐活了（不要随便画，人们说这些东西是拿来沟通的，而我看更重要的是拿来理清思路的，有没有什么遗漏的需求，画一画就明白了）
然后根据这些东西跟客户稍微确认一下
然后就是需求分析，分析的时候主要还是分析各种业务流程，什么分支啊、异常啊，能上的都给它上了，再辅以先前画的那些图，就差不多算完活了
回复  4楼 回到顶楼 
  5个月前   坚持信念      :
针对你的【问题】：
UC本身就是用来描述系统功能的，不是用来说明流程的，不过鉴于人们的习惯，可以在排版上弄得有点先后顺序，看起来也比较舒服
UC本身是没有子UC的，但是你自己可以画啊，标识一下就可以了，反正是用来方便理解的，又不是什么法律。不过话说回来了，UC虽然描述了系统的功能，但是并没有说这就一定要是系统的功能组织结构，这个要弄清楚。

PS：你的所谓大功能是啥意思？大的菜单项？
回复  5楼 回到顶楼 
  5个月前   斧头帮少帮主      :
@坚持信念
自产自销,,,,我们即是客户也管开发...

@你的PS
大的功能比如图书馆有借书功能,然后可以根据流程模块化成 【借普通书|借带光盘的书|老师借书(应该跟学生不一样吧)|预约借书】

我画UC图只画一个Use case:借书,,,
一般也都是让UC尽量从总体上把握系统,从而避免陷入细节当中.

现在我把UC图(很粗的总体图)画好了,接下来要怎么细化?就是下一步我要做什么?针对每一个Case做Sequence Diagram?
回复  6楼 回到顶楼 
  5个月前   volnet（可以叫我大V）      :
文档化的基本准则是交流，如果你的项目小到不需要文档，没有也不是不可以的。
如果你的项目大到什么都要，那么什么就都要。
如果你的项目适中，并且你的文档足够详细，并且还能够利于交流，则可以不用Uc
如果你的项目文档太细没法用于说明问题，那么你可以Uc一下，最终要做到的结果是你是否能让它利于你的工作。如果只是为了画图而画图，意义就不在了。
回复  7楼 回到顶楼 
  5个月前   Justin      :
需求阶段做好业务建模就可以了,主要精力应该在跟客户一起画表示业务的活动图吧，离开始写用例还有一段距离。
回复  8楼 回到顶楼 
  5个月前   Justin      :
http://www.cnblogs.com/Files/justinw/umlchina业务建模.pdf

刚上传了个PPT，帮主先研究一下吧！记住业务建模跟具体技术没有任何关系，目标就是梳理业务，这份PPT里说的非常清楚了，等你搞明白这些再说下一步吧！
回复  9楼 回到顶楼 
  5个月前   斧头帮少帮主      :
@Justin
收到,简单浏览了一遍,有点感觉,,,需要再仔细读一遍.

【报告项目进展】
Step 1:
项目需求已定,完整商业需求文档(BRD)已完成...
回复  10楼 回到顶楼 
  5个月前   bluebird      :
实用第一 ，画图是帮助你你理解需求和分析的，用笔画一画也是一样的，形式主义害人不浅。UML在走向衰落，哈哈。
回复  11楼 回到顶楼 
  5个月前   bluebird      :
我们开发系统是一般是每个人都全程参入的，设计分析、编程都做，所以没有必要按照UML那种模式去做，如果是设计、分析、编程各司其职，细致一些是很必要的。
回复  12楼 回到顶楼 
  5个月前   坚持信念      :
@bluebird
你说的“实用第一”那是自然，不过“UML在走向衰落”就不大妥当了
不要说多么复杂的系统，就是一个流程多一些、长一些的系统，不画图都会很郁闷的，开始可能不会觉得，如果项目时间稍微拖一点，就知道倒大霉了

回复  13楼 回到顶楼 
  5个月前   坚持信念      :
to lz

我画UC图只画一个Use case:借书,,,
一般也都是让UC尽量从总体上把握系统,从而避免陷入细节当中.
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

这个本身就说明图没有画对头。如果只是“借书”，那么该业务的参与者你准备怎么弄？是弄一个“相关人员”呢？还是“老师”、“学生”……之类的一大堆然后全部指向这个UC？

当然了，你也真的是可以那么做，毕竟UC是用来划分功能的，BUC才是正儿八经的业务，如果你真的用一堆人指向“借书”，那么就把Activity Diagram画详细一些就是了，这样，你的系统在后面开发出来也应当是只有一个“借书”功能……
回复  14楼 回到顶楼 
  5个月前   斧头帮少帮主      :
@坚持信念
In my opinion:
老师|学生----->都是最终用户End User,就用一个表示,然后跟借书联起来.
谁看了都很清楚,这个UC是做什么的.如果在UC上过早陷入细节,UC就失去了其本来的作用(总览项目)

然后如你所说,再在Activity Diagram中细化.
回复  15楼 回到顶楼 
  5个月前   坚持信念      :
UC就失去了其本来的作用(总览项目)
～～～～～～～～～～～～～～～～～～～～～

不是很同意这个看法，不然BUC拿来干什么的？
回复  16楼 回到顶楼 
  5个月前   bluebird      :
我认为不管是 uc 还是 ad，这些的应用应该是对于项目中比较复杂的，很容易出问题的时候用，其他的尽量是少用为好，否则你的工作很多时候都花在这些信息的同步修改上，得不偿失
回复  17楼 回到顶楼 
  5个月前   坚持信念      :
难不成系统不用维护了？

这个等你经历过一些异常郁闷的事情之后，兴许就会明白了
回复  18楼 回到顶楼 
  5个月前   Justin      :
to bluebird:
你可以保持自己的意见，但是建议你在没有对UML真正理解之前不要随意发布结论性的言论。
回复  19楼 回到顶楼 
  4个月前   大 兵      :
在项目启动前期,文档很重要.而Uml只是一种快速沟通的工具.
回复  20楼 回到顶楼 

你还不是小组成员，加入小组以后才能发布新主题！
> 返回“OOAD&UML”


其他话题

1 16728