我现在开始要写"详细设计"文档了，项目很急,现在连业务都不是很了解，该怎么写呀?唉,烦.....

[kangaroo]

大家来说说看?这种情况该怎么处理，上面根本不给时间了解业务,只是直接要你写.有点乱,感觉.

另外详细设计文档有什么格式呀?多谢了

[samsungcsdn]

同意楼上，
原型或许是个办法

[futuredreams]

谢谢，个人也支持原型。

[whfred]

公司一般做事是这样的，特别是做项目的公司，做产品的公司就好多了。当项目来的时候也不等人，因为老总要去打开业务和市场，也是可以理解的。最好的方法就是从网上搜集大量的资料和类似的系统试用版本。通读一遍资料，有演示版就一定要把它操作熟练，了解流程。有了一个大致的框架以后，再找一些这个行业的数据定义标准，便于数据物理建模。就快速的依样画一个，能让老板在外面勉强吹出去就可以了，真正上系统的时候，在由自己把握这套的流程，重设计，重CODING就可以了。

[kangaroo]

whfred(后学) ,

谢谢你的跟帖,

我们是做项目的!没有那么简单的,业务又复杂，而且没有一个人说完全懂整套业务流程!

[wawalong]

这样的上司是不是昏头了，有点常识没，老兄另谋高就吧！

[kangaroo]

wujiantao() ,

你说的有点对，现在好象就是这样的，不过收不收得了尾那就不知道了!!


总之感觉无法继续下去了,

最可恨的是，我们不能够去直接跟客户沟通来了解业务。而我们之前是做另外一个项目的，直接就把我们来过来了，然后就要求我们要力马跟上这个新项目,这怎么可能?

好象大家都很懂业务了，直接就可以详细设计了!舍不得花时间培训我们业务,唉!

大家说该怎么办?

[victor97]

项目是有过程的，至于怎么裁减也是需要进行评估，说服老板吧！说会说“不”。

[futuredreams]

...现在很多项目都是这样，换工作也很可能遇到同样的情形，建议慎重。如果有机会还是要每天自己学点东西充实一下自己。业务流程尽可能简化将细节下放到下面每一个人处理“封装”可以使流程更清晰也降低了风险。

[kangaroo]

futuredreams(鱼儿),

你说的有道理

"业务流程尽可能简化将细节下放到下面每一个人处理“封装”可以使流程更清晰也降低了风险。"

不过怎么来简化细节，现在详细设计就要很细化了!

[futuredreams]

详细设计是由程序员完成的，概要设计（整体设计）不涉及细节而是更多的考虑框架，规范和统一接口等，简单，明确，详细的描述可以使每个人明白整体结构和接口规范，最后出现问题也比较容易分析，大都是在单元测试（模块内部）的问题，在测试前期就能将绝大多数问题解决因此降低了风险。

[dingding0662]

最快的学习方法,去找竞争对手的产品来看看,你就知道该怎么写了,而且设计出来的产品比别人的还要好

[redguardtoo]

抄抄竞争对手的在线帮助.
这是软件工程的标准做法,也是常识.

[carrotmin]

知道项目是怎么失败的吗？
就是这么做失败的

[futuredreams]

呵呵，可以参考对手的信息和功能点，优缺点比较来确定一些设计，但是自己的设计一定要有自己的特色。我们以前光是看对手的功能点比较就有几十页的表格，头都大了，最后也没怎么用。还是看具体情况来定。

[simonzone]

搞清楚系统的主要用例.多跟客户交流.
只有你清楚地知道业务.才会做出符合用户的东西.
有时用户不太清楚表达他的需求,建议做个原型,

如果你现在做出详细设计,我想等你搞清楚业务后,
你会发现,你现在做的根本不是用户想的那样.
你说这样的软件他能用吗?

[DragonBill]

估计这项目没戏。

[fat8888]

这很正常。我就刚碰到类似的情况。
作为企业，赢利是第一位的。

老板可以给你时间了解业务，但是客户可不会给你的老板时间。

这样的项目才有挑战性，是发挥你的聪明才智的时候了。

让那些教科书里的软件工程理论见鬼去吧！！！！！！！！！

[erist]

分解系统，每个系统派人去细化，

可以画一些原型界面

数据库表现业务实体，可以设置一些。

这样从界面或从底下就有了一些东西了，中间的业务逻辑可以慢慢添

也许能有些用。

[erist]

而且需求是分优先级的，可以找一些核心的功能先完成

一些次要的可以放在后边接着干。

[erist]

建议先将实体管理起来，流程可以后面作。