一个系统从决定开发到正式上线之间的过程，存在两种实现：用户需求实现和代码实现。
用户面对是系统分析人员，用户把业务流程描述给系统分析人员。
1.用户的针对性。
收集需求一定要收集的是真正使用这个系统的使用者对于系统的期望和要求。而不是针对某几个人，或者某方面的人，这不能代表系统中用户的真正角色。也就不能真正划分出用户的权限。
2．用户的业务流程。
用户会把所有的流程一股脑的交给系统分析人员实现。系统分析人员一定要分析这些流程中哪些是不成熟的，哪些是在业务流程中发生矛盾的，哪些是经常变化的。业务流程中没有形成规范的流程绝对不要实现在系统中；简单地说，用户业务流程中经常发生变化的部分也不要实现在系统中。
3.用户需求不一定合理。
系统分析人员要实现的是合理的需求。太多的障碍阻碍了系统分析人员对于用户需求的合理性的判断；但是用户的需求要实现，实现的方法和方式应该交由系统分析人员来决定，用户的提议只是参考。系统分析人员不能追随用户的需求而不断变更系统，否则成为系统会因为用户的需求变更的体无完肤。
4.用户需求实现分为两个阶段：
第一个阶段，用户需求的整体逻辑设计。
完成系统业务流程图、界面设计、数据库设计、系统建模、用户需求文档描述，主要目标系统整体的逻辑可行性、完整性，所有逻辑情况、逻辑分支需要考虑！这个文档作为软件规格外部说明书（缩写PES），这是软件帮助的一个依据和后续技术实现细节的依据。
PES完成后，一定要经过用户确认，这是必须的，确保用户对系统设计阶段同意。
这里是用户需求实现的核心。如果完全按照用户需求实现，系统在很大程度上丧失灵活性、自适应性和自调节性，丧失灵活、自适应、自调节功能的系统，会被用户需求压迫，不断地实现新的用户需求，最终走到死胡同里。用户需求到底实现多少，实现到什么程度？没有答案，只有经验。经验就是你自己经历和体验了。
第二个阶段，用户需求的技术细节设计。
根据第一阶段的文档，用技术实现上述文档，对数据库要有SQL语句；对界面中的每个按钮要有实现的函数名称或者类。这个过程中形成软件设计内部说明书(缩写PIS)。PIS是对PES的细化和再次Review，能够在Coding前发现PES中细节上的不足，可以再次修整PES，做出让步和调整，来对技术本身做出让步。有人说技术可以实现任何内容，其实在一个有限资源和有限范围内，技术力量和实力都是有极限的，有时必须做出让步，不要被技术是无所不能的这句话所迷惑，它的前提是技术力量、人力资源和时间都要无限，那么技术是无所不能的！
PIS完成后，应该由PIS设计人将设计思路讲解给PES设计人员，看实现思路和实现细节是否吻合PES的程度。必须在PIS和PES中达成一致，否则系统仍然不能开发。
这两个阶段不应该是同一个人或者不是同一组人，第二阶段是对第一阶段的技术实现上的分析和考证，也是程序员coding代码的依据。SD根据PES撰写PIS，并将系统分模块或根据类来排人力时间，作为项目正式开发立项。
一点体会，写在这里，备忘是多数，供大家参考也许只是一点点。
本文地址：http://com.8s8s.com/it/it37512.htm