任何的一个软件都不是无中生有，都不是凭空捏造出来而没有任何的价值点及功能，软件生命的最开始的起点便是有一个需求，有一个问题需要用软件来解决，而通常一个需求都是来源于生活中，经济生产中的需求，大多数最开始都是描述的生活或者生产需求，一个软件的需求它最开始是通俗的，是语言化，又或者是场景化的。
需求的来源：
软件需求最开始来源于客户，通过客户的一些描述对软件的基本要求进行定义，这些需求是非专业话的，或者说一般不能直接用于设计软件的，而需要通过一定的分析才能形成软件的初始模型。在最开始的时候，会找到与软件相关的直接参与者，使用着，提出者进行沟通，让他们对这个软件进行描述，对软件的使用场景进行描述，一般有效的方法是要求他们对软件的各个场景讲故事，将软件的外部实现的功能通过每一个故事形成一个一个的场景应用，同时也要注意，需求方一般不能完全知道自己想要什么，后者即便知道自己想要什么，但总是无法表达自己的正确需求，所以在需求讨论会上，一定要注意找到客户的真实目的，而这点就要从客户的角度，找到客户的利益相关点，这样才能更好的了解客户的需求。但总之来说，经过需求的讨论过后，我们能够知道每一个功能的具体描述，从而形成一个一个的用例。
需求用例的分析：
用例的分析主要目的是为了能够更好的对软件产品进行理解，同时对需求建模提供一定的帮助，所以用例的分析会和开发的语言又一定的联系，比如使用c语言开发，就需要分析用例的流程，用面向对象的语言，则需要对对象进行分析，而常见的分析模式有三种。
1.通过场景的需求模型分析。
使用场景主要是站在一定的角度上进行分析，比如一个用户登陆场景，则是站在登陆用户的场景下，分析用户的进行的操作，以及可能发生的情况以及它的处理流程，可以通过画uml活动图或者uml泳道图来更直观的分析该场景下软件系统所经历的过程。基于场景的分析能偶帮助开发人员和需求人员理解整个软件的过程，有助于需求人员快速的找到该分析中可能出现的遗漏点，相比于其他两种分析方式，这种分析模型更容易被需求人员接受，因为它直接反应的是该场景发生的事情，而其他两种，则需要对编程语言又一定的熟悉。
2.通过类的需求模型分析
类的需求分析，主要是通过对前面得到的需求用例进行语义分析，通过对每一个场景中得到的名词描述，大概得到“外部实体，事物，偶发性事件或事件，角色，组织单元，场地，结构”，通过这些定义，将名词进行分类，在通过一定的原则和调整，将一些名词设成程序中的某一个对象，将一些名词设置为对象的属性和行为。
2.1类的划分规则
在一个描述性文档中，需要找到所有的名词，然后在名词中找到满足以下特征的作为类（非完全必须，但可以一开始按照这个原则建立类，后面在具体分析的时候进行增添）：
1，保留信息，类必须要有两个及以上的属性，不然则考虑将此名词作为一个类的属性
2，所需服务，必须有一个操作对类的属性进行修改
3，多个属性
4，公共属性，公共操作，必须操作，类拥有一些公共的操作和属性提供给其他对象，在场景中存在操作引起该名词下的属性发生改变，则可以定义成类。
2.2类的属性
属性定义类的功能范围，一个属性必须规范和反应这个类，同时一个属性必须拥有修改它的方法。
2.3操作
改变或者处理其属性的操作，计算操作，请求操作，监视或者控制某个对象的操作。
通过以上的规则，能够在语义中找到类同时定义类的属性和操作。然后就是如何确定类与类之间的联系，这里用到的一个方法—类-职责-协作者建模，通过找到每个类在场景中的职责，从而找到每个类与其他类之间的关系，同时发现是否存在某个类需要与另外一个类发生交互协作。同时有些类之间又存在关联依赖包含关系。关联和依赖关系，主要是将类之间的非职责性关系，而是内在的联系关联起来，形成一个内部的关联。到了这里，基于类的建模就基本完成，最后可以uml类图反应整个需求建模的模型
3.基于行为和模式
基于行为主要是根据状态进行分析，主要是分析每个事件的前后，文档描述中是否发生了状态改变，从而得到一个关于状态的流程图，该类分析并不常用在软件设计阶段，一般用来对业务进行分析，对单一的行为进行分析和理解，有助于开发人员对流程的理解。同样也可以使用uml工具进行分析展现，这里使用的时序图来反应各个行为后系统的状态改变。基于模式，主要是对分析过程进行模范化，有助于分析同类模式的用例时，复用同一个分析模式，达到快速的完成分析的目的，模式分析，主要的是提取多个场景中的共同点，然后进行概括，形成一个通用的分析模式。一般在同一个领域，分析模式是能够服用的。
建模
当得到软件的需求用例就开始对软件进行建模，建模的作用是形成软件系统的大概模型，为后面的软件设计提供一个直观的资料。是软件生命中较为重要的一个环节，因为它直接联系的是软件的需求和软件的设计开发，是将需求反应到编码的关键步骤。
最后，软件生命周期中的每一个环节只能向前追溯，也就是后面的环节可以向前面的环节提出疑问，而在讨论软件需求的时候或者建模的时候，尽量不要向后考虑，因为所有的后面的操作，都是为了表达它前面的内容，因此只有每个环节关注它前面的内容，尽量完备的得到需求，完整的描述需求和建模，当然如果在一开始就发现有不能实现的需求也是能够节省大量的开销，但那是需要对技术有一定的了解的情况下完成的。
网友评论