今天才发现,之前做需求中脑子里和笔记的一些用户的简单需求,经过美化后,就成为了XP中的用例故事(user story)和CRC卡片了.
所谓的用例故事,其实就是把用户的参与系统的交互活动的经历描述清楚,注意这些都是站在用户的角度上去描述的.user story
一般要经过多次的迭代才行,强调的是简单和清晰.一般的格式为:
用例编号:
用例名称:
事件的描述:
补充备注部分:
用例的优先级:
表现的形式:(这里可以设计表现的形式为什么类型的数据,使用什么样的输入形式,比如"下单日期,需要日期型,需要日历控件")
注意用例的描述要分好层次,不要笼统.比如"管理车辆系统功能",就要细致分为CRUD等再小一点的功能..
还要注意用例中不要设计内部系统!比如不要出现"数据库把返回的数据显示在用户屏幕"这样的语句.
用了用例,还可以估算工作时间,比如可以在上面的用例中，再增加一项"该用例工作时间估算".,则可以较细化地估算用例了。
而XP中的CRC卡片是class ,responsibility和collaboration,即类,职责和交互的意思.在一个卡片里进行表达,因为地方小，
所以这样做的好处是不让一个类有太多的职责,而且这样的方法,简单,轻松, 可以很快看出类与类之间的关系
和职责,一旦设计完成,可以把不同的卡片组合起来,为下一步的类图打下坚实的基础,详细的可以参考这里
http://book.csdn.net/bookfiles/116/1001163602.shtml
所谓的用例故事,其实就是把用户的参与系统的交互活动的经历描述清楚,注意这些都是站在用户的角度上去描述的.user story
一般要经过多次的迭代才行,强调的是简单和清晰.一般的格式为:
用例编号:
用例名称:
事件的描述:
补充备注部分:
用例的优先级:
表现的形式:(这里可以设计表现的形式为什么类型的数据,使用什么样的输入形式,比如"下单日期,需要日期型,需要日历控件")
注意用例的描述要分好层次,不要笼统.比如"管理车辆系统功能",就要细致分为CRUD等再小一点的功能..
还要注意用例中不要设计内部系统!比如不要出现"数据库把返回的数据显示在用户屏幕"这样的语句.
用了用例,还可以估算工作时间,比如可以在上面的用例中，再增加一项"该用例工作时间估算".,则可以较细化地估算用例了。
而XP中的CRC卡片是class ,responsibility和collaboration,即类,职责和交互的意思.在一个卡片里进行表达,因为地方小，
所以这样做的好处是不让一个类有太多的职责,而且这样的方法,简单,轻松, 可以很快看出类与类之间的关系
和职责,一旦设计完成,可以把不同的卡片组合起来,为下一步的类图打下坚实的基础,详细的可以参考这里
http://book.csdn.net/bookfiles/116/1001163602.shtml
