软件开发的需求分析样例

需求分析样例

完整系统的需求分析太庞大了，很难说清楚。我们不妨从中找出一个节点，目的是说明在需求判别研究的过程中大体应当怎样对待各种管理目标的演变。限于篇幅我们只能以命题框架的构造为基点讨论问题，而不可深入到应用功能的内部细节。
我们可以设想一个用户提供的《设备故障维修单》。它必然要包括设备名称、维修内容、维修人员、时间、地点、结果等基本信息，就简单管理过程而言不过如此。在不使用信息系统的情况下，这种管理手段只是一种责任性的记录，很难发挥更大的信息应用价值。
在这些数据被纳入系统之后，立刻会衍生一系列全新的应用课题。反过来对原始数据的采集过程又会带来一系列的变化与影响。我们给出与该业务相关的各种管理成分，然后再来讨论其相关性与变化过程。
在图1-1所描述的功能中包括了简单管理模式、复杂应用模式、高级应用模式三个层次，我们可以尝试地分析一下这几种模式在实现过程中的差别。
1.3.4.1 简单模式
• 数据采集：采集到满足简单需求的数据集合。
• 维修历程：对每个设备的维修历程是可以被追溯的，一般是通过报表方式实现。
• 维修责任：从责任人的视角对维修记录进行分组筛选，形成专题报告。
对于简单的应用，大约可以到此为止了。如果用户的管理目标不仅于此，那么问题就会变得复杂起来。比如：用户需要进一步深化管理目标将会导致一系列问题的产生。如果用户需要管理工时数与原材料的消耗，可能会通过相对简单的参数表满足要求，如果用户确实要实现“成本核算”，则会带来一系列的新问题。
1.3.4.2 复杂模式
1．需要其他数据体系支撑：在此处引用的数据可能并不复杂，但要保证这些数据的有效性与完备性，并不是一个数据项那么简单，而是需要一个子系统的概念才有可能实现。
• 工时工种：需要一个简单的子系统支持，定义专用的物理表及服务程序，用于解决工种定义及计价标准等一系列问题，必要时还会与人员表建立关联。
• 备件耗材：需要一个物资管理体系的支持，包括物资、库存、出入库、计价核算等功能组成的完整体系。
2．增加数据采集范围：为了后续管理目标的实现，需要在维修单录入的过程中增加有关的数据项，实现更加全面的数据描述。
3．建立数据之间的关联：在一个维修单生成的过程中，必须要有效获取工种工时与备件耗材的相关数据，并为后续的核算建立起各种视角所需要的关联。
4．成本核算：根据维修单上的数据关联到各种参数表，获取有效的核算数据并完成核算，形成成本核算的票据并实现存储，必要时支持各种视角的成本查询报告。
这只是一种相对简单的说法，在实际应用中，得到一个即时数据并不难，更复杂的问题会体现在数据的实效性方面。工时计价体系会随时改变，备件耗材的成本也会随时改变，随时能够得到最精确的有效数据一般不会像想象的那么简单。尽管这种模式有些复杂，但只要思路清晰，实现起来还算容易。
在需求素材上体现的不过是“成本核算”四个字，但由此所产生的变化非同小可。准确评估用户需求所产生的工作量及其复杂程度，是需求分析人员必须准确把握的目标。在这方面的经验基本上来源于项目过程的历练，是得益于项目抽象、规律领悟的基础之上。
1.3.4.3 高级模式
设备维修对产能的影响是个更加抽象的价值评估、评测，它在在很大程度上取决于历史过程中所能采集到的原始数据。对于历史过程的总体评价或对今后发展趋势的预测是历史上的客观结果与主观判断有机结合的产物，这个知识体系并非是结构化数据所能描述的命题。此时，我们可以领悟到它在实现上的难度，不再继续深入地讨论其具体的实现。
我们还可以从图1-1来分析原始数据对后续应用带来那些影响。在系统的复杂性增加之后，分析过程中容易产生遗漏或偏差。假设我们在构造原始的数据采集过程中，事先没有穷尽后续应用的数据元素，在后续设计中发现了数据缺陷之后再反过头来修改原始设计，这种返工将会影响到一系列的相关功能，这是需求缺陷对实现周期的重要影响。如果这种缺陷在应用过程中被发现，那会带来更多的麻烦，同时也会消耗更多的时间。在关键的功能节点出现返工对项目进程影响重大，如果返工影响的范围较大或多次出现，项目交付的时间表必然难以兑现。
提示：在项目过程中如何强调整体目标、体系性与完整性都不过分，因为经常出现的返工往往就是因为对这些问题的重视程度、认知程度不够所造成的。所以，我们绝对不能在某个节点上采取就事论事的态度。要想避免重复的返工，就需要在任何一个节点上都始终保持纵览全局的设计思路。到此为止我们再来评价原始素材的作用就会发现它在整个需求分析的过程中所占的比例必然也只能是一个相对较小的一部分。