写软件开发需求你必须掌握的规格

 需求规格

      为设计过程中的需要而撰写的需求规格说明书是三种文体中要求最高的一种，因为它的用途在于为设计实现提供一个可以用来作为参照的基本约束。在有些情况下，它可能会包括需求报告的全部内容，并在此基础上进行扩充。
      在这里有一个职责上的划分，原则上来说，需求分析只对用户需求的真实性负责，并不需要考虑数据设计与功能框架，后续工作会由专职的数据库工程师与架构设计师来完成。这种说法只有在具备规模的软件企业中才有可能做得到，对于中小企业的有限投资这并不是一个能够付诸实现的操作过程。从需求到实现设计到代码实现大约是这类项目的基本过程，有些项目干脆就是从需求直接到设计实现。
      基于这种客观的项目状况，要求需求分析能够提供数据体系构思与系统框构构思应当是转换价值最高、实现途径最短的方式，在这种情况下，需求方案对系统成败及效益好坏能够起到决定性的作用，但困难是需求分析人员必须具备相对丰富的项目经验与编程经验。
1.4.3.1  功能描述
      在用户功能向设计实现的转化过程中需要遵循的总体原则，对于系统框图、局部框图、重要构思框图不仅要给出业务层面的描述，还要有说明这些公司方案在设计实现上的大体原则，尤其是通过功能抽象得到的设计模式、关键性的数据关系都需要尽量详细的图示与说明。
1.4.3.2  数据描述
      对于需求规格来说，数据体系的构造是必需的。对于物理表结构的设计只是最肤浅的层面，更重要的是要解决数据流的产生、变化及流转过程。数据是承载业务的基石，构思的重点不是到底有哪些数据需要存储，而是数据之间的关系应当如何建立并有效保证。业务流与数据流之间在关键业务、关键部位上的相互作用与配合关系。健全的数据机制是有效实现的保证，巧妙的数据构思是简化编程的重要途径。用户在适应性方面所表现出来的很多问题如果仅仅基于代码的层面上解决将会非常困难，如果通过恰当的数据构思往往可以得到化复杂为神奇的效果。
      不要试图让程序员理解业务，这是一种资源的浪费。对于程序员来说，永远是对哪个物理表的数据按什么样的规则进行装载，在业务过程中需要对数据进行哪些处理，然后按什么样的规则把数据保存到哪个表中。这是一种能够让程序员快速进入角色并能准确把握设计实现的描述方式。
1.4.3.3  重要的业务逻辑
      这是个难以一概而论的命题，可以给几个示例来体会一下所要表述的内容。
      • 对于商务系统是采取进价核算还是采取售价核算，或是要求两者并行实现。
      • 对于物资管理体系来说，是采取实际成本还是计划成本，或是两者兼顾实现。
      • 对于生产系统来说，是按流程模式还是分布、聚集模式，是节点通用模式还是节点个性化模式，或是通用节点与专用节点相结合的模式等。
      • 对于质量管理来说，是以结论意见为控制目标还是以关键数据为控制目标。
      诸如此类的业务目标都是属于重要业务逻辑的范畴，这是系统实现之前必须界定清晰并且给出实现指导方案的命题。如果在需求中对此不能明确，实现过程的价值就会大打折扣。
1.4.3.4  对象的原型
      面向对象理念的普及对开发过程的影响巨大，由此导致了“需求驱动”开发模式，该模式强调“事物”的真实性，强调需求与事物之间在客观上的对应关系，以完整的事物单元作为基本“对象”实现封装，再通过对象组合来实现业务体系。面向过程与面向对象的差别应当从需求分析开始，而不是从编程设计开始。理解这种改变很重要。需求分析的重点不仅是业务内容，还要对业务过程中的事物单元有所判别与界定。如果能够从对象的角度实现业务过程描述，不仅使需求的思路更加清晰明确，也为后续开发奠定了良好的基础。
      这种理念与模式的变化会影响“需求规格”说明书中的构思与撰写方式：
      1．通过需求素材分析确定应用系统的功能框架；
      2．通过模式分析得到系统中的各种“对象”单元；
      3．通过对象对业务过程进行描述。
      对于需求分析（严格地说是架构设计）过程来说，正确提炼“对象”的原型应当是整个过程中的难点与重点。
提示：对于中小规模的项目来说，好的需求构思与详细设计之间只是一步之遥。