下面的故事发生在一家小公司

第一情节：

有一天，公司来个胖子，据说是省某局领导，谈话如下：

胖子： “随着各个地区信息化建设、…………………………，为方便办公文件传递，欲建立《文件发送系统》，实现省（O局）文件向下属8个地区（A—H局）发放任务。要求该系统以网页形式，可以发送常用影像，办公文件。我们局的管理人员可以通过Internet登录到系统，并提交上述几种文件，下属地区登陆到系统后，可以下载这些文件。基本就这样，上面催的挺急得，抓点紧！”
经理：“好！咱办事你放心！今天是1号，5号吧！向您报告！嘿嘿……”
………………胖子走了………………过了1天…………
经理：“小王呀，过来……你手上的那活先停停…先把这个急活做了………（重复胖子的话）……今2号，你看4号咋样，能做完吧……”
小王犹豫的说：“嗯，差不多吧！……”
经理：“那好！这事就这么定了，赶紧办…………”


（后面的2，3情节待有方案后，给出。）

对上述需求，大家如何设计？以经得起修改、扩展？！

楼主以上谈到
两种系统使用人员：
1.省局管理人员
2.地区局工作人员

四个功能性需求：
1.上载文件
2.浏览文件
3.下载文件
4.登录身份验证

一个设计限制：
1.必须设计为B/S方式的应用；

一个项目约束：
3天时间

分析：
一.用例模型：
主要业务目的是完成文件交换，通过以下三个用例达到；
1.上载文件，主角：省局管理人员
2.浏览文件，主角：省局管理人员，地区局工作人员
3.下载文件，主角：地区局工作人员

为了控制文件交换的过程和方向，需要对使用人身份进行验证，用“登录系统”用例表达；
为了能够验证使用人身份，需要事先把可能的使用人信息输入到系统，用“系统维护”用例表达；

4.登录系统,主角：省局管理人员，地区局工作人员
5.系统维护,主角：省局管理人员

 回复: 怎样实现一个经得起修改、扩展的软件？附真实CASE，欢迎大家讨论
　

---

babituo 已经分析的很清楚了。
那个胖子一开始能把需求将得那么明白已经很不错了，至少能说出他要干什么。只不过对于细节部分很省，政府里的人都这样。其实如果用迭代的方式，一开始能了解这些东西也就可以开始第一次迭代了。

大不了以后胖子再提什么下属也要能够上载文件...省局可以单独对几个区发放，但是其他区看不到 ...省局发放的文件要经过经办人审批，经办人审批完处长审批，处长审批完局长审批...省局可以和区局一起在网上开会...@#@$$%$...
政府里的人都有这些做事的习惯，而且存在很多利益上的冲突，对用户特征进行一些分析，不难想象将来这个软件需要进行怎样的扩展。而且本身软件就是要保证用户的利益得到满足。

项目相关人员
省局管理人员
用户特征：最终典型用户，负责文件的上传操作，熟悉电脑的基本操作
省局领导
用户特征：不熟悉电脑操作，具有官僚作风，不常使用我们的系统
区局领导
用户特征：不熟悉电脑操作，具有官僚作风，不常使用我们的系统
区局管理人员
用户特征：最终典型用户，负责文件的下载操作，熟悉电脑的基本操作
...
不知道项目相关人员分析得对不对，这个还是要根据你的实际情况进行分析的
从项目相关人员可以得到一些将来软件可能发展的方向

对于这个例子，系统特性什么？
掌握系统特性有什么用？
那些人需要了解系统特性?

谢谢大家的回复，我用dataset方式实现了，由于时间关系没有采用OO。好些日子没上网了，我最近在研究工作流，嘿嘿。在这公司已1年了，每有项目，都很急，但总是从头到尾搞一边，觉得很失败，也很没意思，不想干了，学的OO也快忘光了。：(