编写软件需求注意要点

1、看起来一个明显的问题是你们开发小组与客户的沟通、开发小组与老板的沟通不够充分、 有效。由于软件开发的专业性，客户与老板都不懂得开发过程的复杂性，不懂得一项变动对 项目的成本、时间及其它方面有什么样的影响，不懂得项目后期的变动与前期的变动对项目 影响的差异有多大。要靠客户或老板单方面去理解这些是很困难的，所以开发小组必须能提 供足够的信息，帮助他们去判断。如果开发小组自己也是懵懵懂懂的，就别希望客户在项目 前期就能确认，别希望老板能做出正确的决策再就你提到的几个具体的问题说说个人的看法：我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来， 怎么让他们签啊？首先就个人经

2、验而言，让客户在需求说明书（或类似的文档）上签字是很难的。就算是双方 对需求的理解已经高度一致了，客户仍然会对未完成的东东心存疑虑，毕竟一份需求说明书 不能列举所有的细节。此外如果客户签署了需求说明书，万一项目失败了，签字的那个人很 可能成为项目失败的责任人。没有人愿意承担这样的危险（注意是危险，不是风险）我们对于需求沟通的最基本的做法就是反复沟通和迭代开发。其实这并没有什么神奇的地方， 道理也象白开水一样简单：反复沟通是一个从粗略到精细的过程。每次沟通都能减少开发小组与客户对需求的理解的差 异，或者修正以前错误的理解，或者比上一次讨论的更深入、更全面迭代开发使得开发小组能比较快地提交新功能，

3、对需求变更也能快速响应。而每次交付给客 户试用的软件能让客户有更直观的感受，能更有针对性地提出问题，双方沟通的效率也可能 提高实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的我觉得开发小组可能需要更深入地理解需求，尽可能在项目前期就搞准确。这可能也需要你 们学习更多的行业知识，了解更多的行业习惯。如果不这样，就很可能出现你开发的一个功 能你觉得很爽、很酷，但用户却觉得很搞笑、很花哨.老板或客户不懂得如何评估一项功能或变动会对系统产生多大的影响。比如是否会导致架构 方面的改动、改动的范围或程度如何？是否导致返工、返工的工作量如何？（其实个人觉得 更应该关注返工对于开发小组士气的影响如

4、何）。所以你们应该在项目前期考虑各种可能的 实现，在一定程度内做得灵活一点（留有变更或扩展的余地），而且，应该迭代开发还有一点，开发小组要学会评估工作量和工期。面对一项功能或变动，如果开发小组说不清 楚要干些什么，要多久（更妥当地说，多久是一个时间范围），怎么能希望老板能正确地评 估收益和代价呢？怎么能正确地决定做还是不做呢?说到底，客户不能在需求说明书上签字，老板在开发工作完成了才提出变更，最根本的原因 是他们对开发小组在项目前期对需求的把握没有信心。他们不知道开发小组对需求理解到什 么程度？开发小组的理解与他们的理解是否一致？开发小组到底要花多少时间才能把项目 做好（不仅仅是做出来）？如果

5、开发小组能打消他们的疑虑，或许开发过程会顺利许多需求注意2开发初期，我们最好让客户介入到我们的需求分析中来，认真听取客户的意见，在这一 方面不要同客户有争执，当然了也可以提建议。我们要把客户当作业务方面的专家，我们就 是小学生，要向专家们学习业务知识。客户既然是我们的上帝，如果我们在开发前期不尊重 上帝，那么开发后期就会受到上帝的惩罚！下面总结一下自己的看法：总结公司以前相同软件的得失；根据以前的经验制定出一套自己的需求说明根据这套需求展开讨论，分析不足之处以及较好的地方，重新设计客户介入，请客户提建议，以及客户的要求和可能的需求如果客户没有问题就执行下一步，否则回到2根据需求说明制定出一套功

6、能要求说明书，一定要详细客户介入，听取客户的意见，重新探讨，重新更改功能要求说明书美工介入，根据制定出的功能要求说明书，迅速画出一套相应的图形界面，注意是画而 不是做客户介入，根据这套画面重新进行功能需求讨论如果没问题执行下一步，有问题回到6根据画面设计表结构，不求最灵活，但求实现完整的功能客户介入，根据制定的表结构，向客户描述能实现的功能，请用户提建议如果没问题执行下一步，有问题回到8根据制定的表结构和美工作的画面设计功能函数，同时美工开始真正作业分配工作任务，开始施工。当客户介入时一定要求客户签名留档，提示客户如有其它重大改动，其要负重大责任， 这是为了避免某些客户敷衍应付之举，因为我们的项目一旦实施，用户的需求更改会很大的 影响我们的项目进度。在功能设计上尽可能做到灵活，意思是：我们可以根据我们的需要随意去掉某些功能， 这样我们面对不同的客户将有更多的选择。就好比冰箱，客户的价钱不同享受到的功能也应 有所不同。文档一定要详细，并且保证与项目同步更新。要有规范的项目开发规范，确保大家遵守。项目经理要随时了解项目的进度，以便及时处理一些异常情况（算了，这些还是