需求文档 BUC UC

刚启动一个项目,需要大家帮忙!!!Help me!!!


浏览:1586 2007-11-29 12:28 来自 斧头帮少帮主      :

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

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

 

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

 

 

 

 

收藏 楼主
  1年前  电机拖动      :
如果直接从UC上画出类图来,要么系统巨简单,要么÷画出来的类图不会在后面的编码工作中起到任何作用(仅仅是让文档上有了东西)

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

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

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

PS:你的所谓大功能是啥意思?大的菜单项?
5楼  
  1年前  斧头帮少帮主      :
@坚持信念
自产自销,,,,我们即是客户也管开发...

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

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

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

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

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

13楼  
  1年前  电机拖动      :
to lz

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

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

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

然后如你所说,再在Activity Diagram中细化.
15楼  
  1年前  电机拖动      :
UC就失去了其本来的作用(总览项目)
~~~~~~~~~~~~~~~~~~~~~

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

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

你可能感兴趣的:(编程,工作,活动,Class,文档,UML)