软件需求分析工作内容

软件开发的前期准备工作1、前期准备：前期准备包括：明辨软件类型、明确软件需求、明确软件架构、明确项目中存在的风险。1)有时候用户在一开始并不完全确定自己想要的是什么，因此值得花费比理想情况下更多的力气，找出客户真正想要的东西；这比“先做一个错误的东西出来，然后扔掉并从头来过”的成本要低很多；2)问题定义：对系统需要解决的问题做出清楚的陈述。问题定义只定义了“问题是什么？”而不涉及任何可能的解决方案。问题定义在具体的需求分析工作之前，而需求分析是对定义问题的深入调查；问题定义应该用客户语言来书写，而且应该从客户的角度来描述问题。如果没有明确的问题定义，那有可能再构建期间解决错误的问题。3)构建活动的准备工作的根本目标在于降低风险，要确认准备活动是在降低风险，而非增加风险。4)如果想要开发高质量的软件，软件开发过程必须由始至终关注质量。在项目初期关注质量，对产品质量的正面影响比项目末期关注质量的影响更大。2、前期准备的CheckList：你是否辨明了自己所从事的软件的类型，并对所用的开发方法做出了相应的剪裁？是否充分明确地定义了需求？而且需求足够稳定了，能够开始构建了？是否充分明确地定义了架构，以便开始构建？是否已经指出你的（当前）项目中独有的风险（以避免构建活动面临不必要的风险）3、需求的CheckList：本需求检查表包含了一系列的问题，通过这些问题，问问自己项目的需求工作做的如何。再开始构建之前，用本检查表做一次“心智健全”检查，看看自己的地基到底有多坚固——用“需求里氏震级”来衡量。并不是核对表中所有的问题都适用于你的项目。如果你做的是一个非正式项目，那么你会发现有些东西根本不需要考虑；你还会发现有一些问题你需要考虑，但不需要做出正式的回答。如果你在做一个大型的、正式的项目，你也许就要逐条的考虑了。针对功能需求：（输入、输出、格式、硬件接口、通信接口）是否详细定义了系统的全部输入？包括其来源、精度、取值范围、出现频率等？是否详细定义了系统的全部输出？包括目的地、精度、取值范围、出现频率、格式等？是否详细定义了所有输出格式？包括WEB页面、报表等等？是否详细定义了所有硬件和软件的外部接口？是否详细定义了全部通信接口？包括握手协议、纠错协议、通信协议等。是否列出了用户想要做的全部事情？是否详细定义了每个任务所用的数据，以及每个任务所得到的数据？针对非功能需求（质量需求）用户体验、安全、可靠、占用空间是否为全部必要的操作，从用户的视角，详细描述了期望响应时间？是否详细描述了其它与计时有关的考虑，例如处理时间、数据传输率、系统吞吐量？是否详细定义了安全级别？是否详细定义了可靠性？包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复策略等。是否详细定义了机器内存和剩余磁盘空间的最小值？是否详细定义了系统的可维护性？包括适应特定功能的变更、操作环境的变更、与其它软件的接口的变更能力？是否包含对“成功”的定义？“失败”的定义呢？需求的质量（需求本身的质量）需求使用用户的语言书写的吗？用户也这么认为吗？每条需求都不与其它需求冲突吗？是否详细定义了相互竞争的特性之间的权衡？例如健壮性与正确性之间的权衡？是否避免在需求中规定设计（方案）？需求是否在详细程度上保持相当一致的水平？有些需求应该更详细的描述吗？需求是否足够清晰？即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？每个条款都与待解决的问题及其解决方案相关吗？能从每个条款上溯到他在问题域中对应的根源吗？是否每条需求都是可测试的？是否可能进行独立的测试，已检验满不满足各项需求？是否详细描述了所有可能的对需求的改动？包括各项改动的可能性？需求的完备性对于在开始开发之前无法获得的信息，是否详细描述了信息不完全的区域？需求的完备度是否能达到这种程度：如果产品满足所有需求，那么它就是可接受的？你对全部需求都感到很舒服吗？你是否已经去掉了哪些不可能实现的需求？那些只是为了安抚客户和老板的东西？4、架构CheckList优秀的架构应该关注下面CheckList中的这些问题，本CheckList是作为一种实用的评估手段，用来评估软件食物链到了程序员这一头还有多少营养。针对各个架构主题：（模块的独立性和高内聚低耦合）程序性的整体组织结构是否清晰？是否包含了一个良好的架构全局观（及其理由）？是否明确定义了主要的构造块（包括每个构造块的职责范围及与其他构造块的接口）？是否明显涵盖了“需求”中列出的所有功能（每个功能对应的构造块不太多也不太少）？是否描述并论证了那些最关键的类？是否描述并论证了数据设计？是否详细定义了数据库的组织结构和内容？是否指出了所用关键的业务规则，并描述其对系统的影响？是否描述了用户界面设计的策略？是否将用户界面模块化？是界面的变更不会影响程序的其余部分？是否描述并论证了处理IO的策略？是否估算了稀缺资源（如线程、数据库连接、句柄、网络带宽等）的使用量，是否描述并论证了资源管理的策略？是否描述了架构的安全需求？架构是否为每个类，每个子系统，或者每个功能域提出空间和时间预算？架构是否描述了如何达到可伸缩性？架构是否关注互操作性？是否描述了国际化/本地化的策略？是否提供了一套内聚的错误处理策略？是否规定了容错的方法（如果需要）？是否正式了系统各个部分的技术可行性？是否详细描述了过度工程的方法？是否包含了必要的“买VS造”的决策？架构是否描述了如何加工被复用的代码，使之符合其他架构目标？是否将架构设计的能够适应很可能出现的变更？架构的总体质量架构是否解决了全部需求？有没有哪个部分是“过度架构OverArchitected”或“欠架构UnderArchitected”？是否明确宣布了在这个方面的预期指标？整个架构是否在概念上协调一致？顶层设计是否独立于用作实现它的机器语言？是否说明了所有主要决策的动机？你，作为一名实现该程序的程序员，是否对这个架构感觉良好？