我所在的公司是个50几人的小公司。现在我分到一个五人的项目开发组，可事实上，这个项目的开始都已经两个月了，还只有两人在写文档，其它人都有事在忙其它的了，项目由暂由公司的上一层领导。两人中，其中就有我也负责写需求文档，事实上我刚毕业，专业和软件没一点关系，但没办法，没其它人了，我只得也上了。我没学过软件工程，不知道一个项目下来应该具体怎么操作。但我觉得我现在这样，就很有问题。

首先，功能性需求都确定不下来，我想我以我为主先把自己的想法写下来，然后项目组成员一起讨论确定下来，但是这个讨论因为没时间，事实上其它成员也没关注这项目，就一直没有进行。我不能只等着，于是就往下写，然后是写用例，再写活动图了。

可现在麻烦的事，那个间接领导有时间时，会检查一下我的文档，然后他突然有了个想法，要加上什么什么功能，又要去掉什么什么功能，然后我又按他要求修改；下次他检查时，结果又是这样，搞得面目全非，我也形成不了自己的思想体系，只有揣摩他的意思。两月下来了，觉得还在考虑功能部分，真是失败啊。难道这就是RUP 开发的迭代过程。还是我们管理有问题，我的想法有问题，大家指教。

我觉得应该定下功能性需求，然后再根据功能写用例，再从开发角度上细化用例，根据用例写时序图，根据时序图确实类，再画图，组件图什么的。大家觉得应该这个过程是什么样的，是不是我有问题了？

鉴于你的情况，首先我觉得应该抽时间学习一点软件工程的知识，清华大学---张海潘---《软件工程导论》，这本书不错，可以看看。

对于需求分析，一定要了解用户的需求，即，用户想用我们开发的软件来作什么。建议有条件的话，最好和软件的最终用户面对面的谈谈，收集用户的意见和他们最关心的功能，事后形成书面稿；如果是贵公司的开发的面向大众市场的软件，那么你应该和项目的发起人、项目主管等人坐下来，把你事先拟好的需求大纲提交大家讨论，最好作会议记录，一项一项的过一边，会后形成一个一致的意见，再提交一次终稿，得到大家签字后，你再正式的编写你需求分析文档。

在软件的需求分析期，讨论是非常必须要的。

如果你的领导老有新想法，最好和他谈一谈。

这不是根据客户的需要来做的，而是我们自己公司的长线产品。

所以，需求不是人家提，而是自己想。

每一个项目得开发 ，都要预先有个设计框架，然后再一步一步实现每个部分。

面向对象特性就很重要，每一个部分当然会有很多细节，也许在你设计框架阶段考虑不到，但是某一部分的每个细节，

都会有共同得特点。首先在root类中定义这些共有特点，构成基础的对象封装类，然后由此派生出不同的细节子类。

这样会使你的代码很有条理，即使需要删减或增加，也会很容易实现。

一点心得吧 希望用所帮助

这方面我没什么经验，只能谈谈我的一点看法
首先，你需要知道你要做个什么样的程序，即这个程序能够用来干什么，符不符合客户要求。
然后你需要将整个程序分成若干个模块，进行编程，这个我就不说了
最后，很重要的一点，一定要考虑到程序的可升级性，除非那个程序是只用一次就删调的。