|
当软件已经开发完成，通过了测试验证以及各种试验的考核，进入了定型交付的阶段，就在这个时候，系统方突然要求软件增加新的需求，这对于软件开发人员来说，无异于一个晴天霹雳，就好像你本来想去度假，结果却让你必须加班，怎一个难受了得？ 软件开发人员曾经质问系统方，“之前你不是都已经对软件进行了验收，怎么现在还会增加需求？”系统方还振振有词的说：这个需求一直都在用户给我们的需求当中的。既然早就在系统需求当中，那你为什么不把它分解到软件需求当中？ 这样的事情，其实在一些组织当中可能是司空见惯的事情。产生这样的结果，就是因为GJB5000A中需求开发过程没有做好，这一方面有软件开发方的原因，另一方面也有系统方的原因。 站在软件开发方的角度来说，按照GJB5000标准的规定，需求开发包括开发用户需求和开发产品需求两方面的内容。但是对于一些组织来说，由于这个用户需求是由系统方来提供，所以软件开发方主要的精力都只放在了产品需求的开发上面，忽略了用户需求的开发。因为在这些组织里，从职责上来说，用户需求开发是系统方的责任，应当由系统方来负责用户需求的完整性、准确性。这样一来，软件开发方很少去参与用户需求完整性、正确性的讨论，很少会根据系统的业务需求进行需求挖掘。软件的业务需求是否能够真正覆盖由系统分解给软件的功能，这个只能由系统方自己来保证。这样就有可能导致用户需求遗留了一些潜在的缺陷。 造成这个结果的另一方面原因就是由系统方造成的。系统方的能力不够，进行系统需求分解的时候，把软件的功能需求分解的不完整，部分软件功能需求有遗漏，这都将给后面的开发带来巨大的影响。 要解决这个问题，也要从开发方和系统方两方面考虑。 一方面开发方要做好用户需求的开发。这就要求开发方在进行需求开发时不仅停留在和系统方讨论任务书这个层面。他应该把系统方使用的系统方案、组件方案、接口控制文档等都拿来进行需求分析，并且把它们作为软件功能基线的一部分进行管理。 另一方面，系统方要做好需求分析、设计和分配，可以借鉴一些适航标准中机载系统的开发经验： 对于系统设计师要进行需求定义：
由于需求是动态变化的，所以需求捕获和需求管理，都要在开发的全过程进行；
广告 机载电子产品适航工程方法作者：田莉蓉 当当
同时，系统设计师还要学习项目管理中WBS（工作分解结构）分解的知识，在进行产品WBS编写时，要能够确保分解的每一个层次，所有的功能的集合是一个完整的产品的功能，确保产品（或系统）功能不要有遗漏。 只有我们的系统需求分析的工作做好了，软件的功能划分清楚了，软件开发的范围确定了，才不会直到软件行将交付的时候，发现还有需求遗漏，从而导致软件延期交付的情况发生。 | 
