Eric Protect Earth | 保护地球

软件工程中明确定义了，最为一个软件需求说明书的任务，它是一个沟通客户和程序员的纽带，是一个对于系统将要干什么的详细描述。因此，在这个文件中，必须包含很多内容，最近几天，我一直在阅读一份很奇怪的需求说明书和设计说明书，这两份资料里，不但没有系统流程说明，而且没有概念定义，需求说明书先写系统与其他系统关系，然后是系统菜单，后写菜单内容，最后写设计的表结构，我连软件对应的实体有几个都没弄清。  设计说明

话说小P刚刚加入到一个项目组里面，项目经理安排他做需求分析，小P一听需求分析就有点不乐意，心里嘀咕：“需求有什么分析的啊？客户要什么给什么呗，简直是浪费我这个人才！” 虽然不乐意，但毕竟工作还是要做，很快小P接到了的第一个需求，客户打电话来说“我要一只羊”，小P一听就觉得太简单了，简单的写了一下需求“XXX客户需要一只羊”，然后就交给同样是新手的小Q去处理，小Q也觉得很简单，直接抓了一只羊就送过

讨论软件需求的文章有很多，对于需求的标准也不尽相同，但是在思想上是相同，都是为了保证项目的顺利进行。 这里我总结一些比较通用的标准，可能并不完善，但你只要能保证做到这几点，你的项目就不容易失败：明确(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪、可修改等等。        明确：目前大多数的需求分析采用的仍然是自