这周接着阅读《软件需求十步走》，主要是重新解读软件需求，新一代软件需求强调软件需求分析工作是在一个全息的业务背景和一个信息系统的宏观设计的基础上展开的用户需求和系统需求分析。
需求规划工作是面向“全业务、全信息、全系统”，业务是事项，也是事项的实作行为，也是对所做事项的总称。业务的法理依据是业务研究中的关键，业务研究的目的是要认识业务的要素、结构、层次、规律、范围、目标，给应用建模提供依据，即为改造业务提供依据。业务研究从资料研究开始，资料研究从资料收集开始。业务组织的梳理对于找到系统关联性很有帮助，一个组织一定会有其上级、下级和横向协同的相关组织。找出主体和对象间物理、能量、信息的交互物与交互行为是业务梳理的关键。
学习了uml工具，对其中的各类也有了比较简单的了解，在如今王辉老师的软件设计课上，各种软件的设计模式对应着相应的类图，而能不能分析好画好这些类图，之前学习的uml起到了至关重要的作用，学习真是一环扣一环！而在用例的描述中，用例描述完整性和准确性不够这是uml的一项缺点，还有项目的范围和目标的定义是在用例工作开始前需要先完成的工作，uml并不支持，需要我们进行切入的探讨与分析，在项目开始之前，如果不能找到一个确定的范围，就好像有方枯地上打井，打到地也不一定能打出水来。
大家都知道软件需求是从业务需求经用户需求最终到系统需求的，所以业务需求是软件需求的源头，而业务需求又是从客户业务中来的，客户有问题且需要解决的业务才是业务需求，换句话说就是有问题需解决的客户业务叫业务需求。只有保证业务需求的“完整性、准确性、一致性”，才能保证软件需求的“完整性、准确性、一致性”，而“完整性、准确性、一致性”此三性都属于形式逻辑要解决的问题，完整性是从一般到个别的演绎法要解决的，准确性是推理要解决的，而一致性是论证要解决的，所以形式逻辑的演绎法、推理法、论证法是解决业务需求的“完整性、准确性、无二义性”的方法。
阅读了这些，深刻地体会到需求工程中的缺陷将给项目成功带来极大风险，“成功”是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望，这样才能真正的实现软件需求分析的内在要求。