阅读笔记：需求分析与系统设计（一）

那到这本书，看到415页的页码，瞬间感到崩溃无比，啊！又是一本大厚书啊，但想想所触及所学，前面的一丝抱怨也就淡了不少。

在书中常见到作者提起些软件开发的不变事实，比如：一些重要的软件特因素的影响，这些特性在所有的软件项目中都保持不变，并需要在项目中得到承认。软件开发的任务是确保不变事实不会失去控制，并且不要对项目施加任何过多的负面影响，和软件本身就是复杂的，在现代软件系统中，复杂性不过是软件规模的函数，以及组成软件产品的构件之间相互依存关系的函数。而我认为软件的复杂性随着软件的应用领域的性质不同而不同。通常情况下，计算密集型应用领域的软件系统比数据密集型应用领域的软件系统复杂性要低。因为系统处理大量的数据和业务规则，而这些数据和业务规则往往是不一致或不明确的，构建能够容纳所有业务数据、规则和特殊情况的软件一贯是困难的。

软件是开发出来的，而不是成批制造出来的；正如《软件需求分析十步走》书中一文道：没有业务的软件，就不算是软件，需求分析就是给软件的开发划定一个范围，在这个范围内进行开发设计，软件才会开花结果，我们不能否认，虽然软件工程的发展为开发实践引入了更多的准确性，但是并不能保证软件项目的成功。这可以与传统的工程分支相对比，如土木工程或机械工程。在传统的工程中，产品（人工制造）是以数学般的精确来设计，然后利用机械和生产线来制造的。这便是软件不变的事实，也可以称作软件的“墨守成规”。

关于利益相关者，是在软件项目中存在利益相利害关系的人，课上也不少学习有关的利益相关者。任何受到系统影响或对系统开发产生影响的人，都算是利益相关者的范畴，大多的利益相关者为客户和开发者，而在一般交流中，术语“用户”通常是指“客户”。我们不能否认这样的事实：术语“客户”能够更好地反映期望的含义。首先，客户是为开发付款并负责决策的人。其次，即使客户并不总是正确的，开发者也不能随意改变或拒绝客户的需求--对于任何冲突的、不可行的或非法的需求，都必须与客户再次协商。

在不知道框架之前对框架抱有几分神秘的色彩，每当听到这个项目需要某某框架就感到这个项目非常的高大上。而对框架itil框架从业务角度来看，软件是一种正在快速成为商品的基础架构服务。it对早期采纳者来说，仍然是竞争优势的主导来源，但是这种优势的时间跨度比以往缩短了很多。原因有很多，包括开源软件的存在、商业软件的免费教育许可、迭代和增量软件开发周期缩短等。

下一个步骤建模：利益相关者和过程是成功三要是软件素中的两个，第三个要素步骤就是软件建模--即软件开发活动，这些活动被看做是软件人工制品的建模。模型是来自现实的抽象

，是现实的抽象表示。被现实和运作的系统也是现实的模型。凡是用户计划都需要进行建模，一个可视化的模型，往往比自己千言万语都来得实惠，因为用户不喜欢看那些长篇大论，

有一个现成的模型摆在自己眼前，比看什么来的不快！体现出建模的重要性，而对人工制品建模必须进行沟通和文档化。开发者需要一种语言来创建可视化模型和其他模型，并与客户和同事进行讨论。而语言则应该允许在不同抽象层面上构建模型，在不同的细节层面上来表现所提出的解决方案。按照“一张图片胜过千言万语”的说法，语言应当具有强大的可视化构件，还应当具有强大的说明性语义--也就是说，它应当允许在“说明性的”语句中捕获“程序上的”含义。我们应该能通过说明需要做些什么，而不是需要“如何”去做，来进行沟通。开发者还需要工具，或者更适合的说法是，为软件开发过程提供的先进的、基于计算机的环境。