需求文档 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只是一种快速沟通的工具.