[软件需求]没事看看，说不定就过了

目录

part1.基础知识区
求求你了好歹看完基础区吧

1.软件生存期模型

2.需求工程

3.UML

part2.细分进阶区

4.需求获取
a. 愿景
b. 涉众

5.业务建模
a. 业务单元

X.常识

软件生存期模型模型

其基本定义

• 软件开发的一种过程性框架
• 在生存期模型中定义$过程$非常重要
• 在软件生产过程$不存在绝对正确$的过程形式,不同的软件开发项目应当采用不同的软件开发过程。
• 软件生存期模型的特点：
  • 描述了开发的主要阶段
  • 定义了每一个阶段要完成的主要过程和活动。
  • 规范了每一个阶段的输入和输出（可验证的）

主要的四个有瀑布模型，V模型，原型模型，增量式模型。
需要特别掌握的是瀑布式模型。

• 需求分析
  • 设计
    • 编码与单元测试
    • 集成测试与系统测试
      • 运行与维护

可以清晰地看到这5层的层层递进关系。也能明确的发现这种模式的缺点：
$不够灵活$ 和 $直到最后才能看到完整的软件实体$。
其中，不够灵活体现在这一步一步的，如果底层的需求错了，就需要整个打断重来。而关于第二点，你看到单元测试可能觉得不对。这大约就是数块木板+几根钢板+几个螺丝钉组成一张床的事儿吧。
所以，该模型只适合，需求十分明确，并且解决方案也很明确的项目。
不然就得打断，回退，甚至是重来，这是所有项目开发都不希望看见的。

同样的，你也能看到一些特点。

• $定义清晰$

• $每一步骤结束都有一个里程碑来标志$
  * 里程碑定义了一组文档集合

• $只有文档被大家认可后下阶段才能启动$

• $活动都有输入和输出，阶段之间的接口定义清晰$

• $可以定义开发者的不同角色$
  * 在真实的项目团队中,有需求分析师、架构师、程序员、测试员等。

嗯我是抄的PPT。其中第二第三应当是强调内部的阶段性，第四表示连接程度，第五倒是从策划角度来看了。

回目录

需求工程

考试也许不会问你什么是需求（目前就有两种以上的定义）
但是可能会问你什么是需求工程。

    一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项
    目团队对不断变更的系统需求达成并保持一致的过程。

那很显然的。一个项目的需求显然就应该有3层。分别来自1.甲方发现需求并向他人要求者 2.秃头开发 3.韭菜用户
正经点。
1.业务需求（甲方）
*反应组织、机构或客户对系统、产品的高层次的目标要求。
*范围文件（）
2.用户需求
*用户使用产品必须完成的任务。
*用例描述（饼说明书）
3.功能需求
*定义开发人员必须实现的软件功能（与业务需求的1对应）
*软件需求规格说明SRS

这张图很好的说明了我们程序员到底要迎合多少需求才能完成我们的软件
但有些时候，我们的甲方并不知道为什么这个程序有那么多他没有要求的（非功能性需求）
甚至有的时候程序本身也不知道。
程序大约是知道为什么有这么个约束条件的。

该图中所有的方框性目标都是需求文档的范围
这张图也许帮助我们了解了他的层次，但是，我们仍需要了解，其内容应当包括什么。

对于SRS软件需求规格说明书。

该项说明书应当包含概述（包括特点，约束，目的，背景等），对整体项目的说明（以上为饼）。
数据描述，需求说明：功能说明与性能说明。运行环境规定，限制（deadline等）（以上为开发者视角）等。
用户大约是不会拿到这个文档的。
//参考百度百科

对于项目视图与范围文档。

1.描述业务需求，简述该项业务被提出的原因（市场方面），以及计算该项业务可能的利润
2.项目视图的解决方案。 该项表述对该业务需求的解决方案。（还未触及代码层，还是正常人能够看得到的层次。）
但是，该项的假设和环境依赖是需要开发去思考的。（假设的意思大约就是说假设怎么做吧）
3.范围和局限性。范围其实就是目标客户是谁。局限性是该项目不能做什么。
（局限性举例，不能要求一个安保系统顺便完成员工上下班打卡）。
4.业务环境。包括客户概貌和项目优先级。
    看上去就像是这个环境内部的层次和对外的接口一样。
    客户概貌，包括各类客户对该项目的观感，收益等。
    项目优先级则是内部优先级的设置
5.产品成功的因素。鬼扯，天辩。

详情可$参考道客88$的文档，写的很细，自己百度吧

对于用例文档。（你写过）

可直接参考老师发的作业，里面有个叫用例模板.doc的东西。那个就是最后的成品。
这是三方都能拿到的东西。

需求的质量特性：

• 需求说明的特征(也即需求文档的要求)
  • 完整性
  • 正确性
  • 可行性
  • 必要性
  • 区分优先级
  • 无二义性
  • 可验证性

$也就是：讲完全，合需求，能完成，不多于，有先后，没语病，能验证。$

$这里对可验证性作出说明：$
$指任意一项需求的实现都可以被观测到。不能用主观臆断的方式来确定一项需求的实现。$

$需求的正确性的参考，来源于用户提出的需求，这就是为什么正确性指向了"合需求"。$

• 规格说明的要求
  • 完整性
  • 一致性
  • 可修改性
  • 可跟踪性

回目录

uml

UML(Unified Modeling Language)统一建模语言，一种基于面向对象的可视化的通用建模语言。
模型->一个系统的完整的抽象(人能看懂，计算机还是看不懂）

希望小伙伴能够联想到数据库的某些概念

UML包括多种图，来完成建模。(标红的部分是有超链接的)

• $用例图$
• $类图$
• 对象图
• $状态图$
• $顺序图（序列图/时序图）$
• 交互图
• $活动图$
• 构件图
• 配置图

用例图

由$Jocobson$提出,广受IT界欢迎。
用于描述系统的$功能需求$,主要由$执行者（Actor）$、$用例（UseCase）$、$执行者和用例的关系$和$用例与用例的关系组成$。

执行者（Actor）

执行者（Actor）作为用例的启动者，虽然在UML图中用人形来表示，但现实生活中并不一定是人，也可以是某个外界系统。
$比方说对于路由器中传输数据的用例,它的执行者就是终端或者其他路由器。$
$但是对于重新设定路由器，他的执行者就应当是人$

用例（Use case)

用例是$系统$执行的一系列动作，在用例图中用椭圆来表示它。本质上，一个用例是用户与系统之间的一次交互作用。

• 用例捕获某些用户可见的需求，实现一个具体的用户目标。
• 用例由执行者激活，并将结果值反馈给执行者。
• 用例必须具有功能上的完整描述。

所以，用例是直接和用户相关的那一个小圆，内部的活动不是用例。
$即：用例是一个非void类型的函数（或方法），且用户拥有包含该函数的JDK。$

不过这个JDK长这个样子。

执行者与用例的关系

实际上已经在用例当中讲到，用例与用户之间是关联关系，又称通信关系。[1]

用例间的关系

• 1.泛化
  泛化表示用例之间的一般与特殊关系。
  在用例图中，被空心三角形+实线指向的目标是父类。
  $我倾向于认为泛化关系是一种接口，或者说是拥有一个父类。$

  $泛化是一种关系，不是一个动词。请不要想着谁是谁的泛化。$

  $用户之间也是存在泛化关系的,该知识来源百度，尚未向老师证明$

• 2.使用
  表示一个用例使用另一个用例。
  在用例图中，使用虚线+实心箭头+“<<include>>”表示该关系。
  被指向者是源用例可以使用的用例。

• 3.扩展
  通过向被扩展的用例添加动作来扩展用例。
  在用例图中，使用虚线+实心箭头+“<<extends>>”表示拓展关系。
  被指向者表示是源用例可以做的下一个用例。

$这三个关系本身都是可以多对多的。公司董事可以是投资方也可以是员工。$

$总觉得这个写的不好，欢迎提出更改建议$

建立用例的步骤

1. 确定谁会$直接$使用该系统，即执行者（Actor）。

   • 谁使用系统的主要功能（主执行者）？
   • 谁需要从系统获得对日常工作的支持和服务？
   • 需要谁维护管理系统的日常运行（副执行者）？
   • 公司的那个部门使用系统？
   • 系统需要与其他那些系统交互？
   • 谁需要使用系统产生的结果（值）？

2. 确定每一个执行者所期望的功能，并把这些功能命名为用例。

   • 与系统实现有关的主要问题是什么？
   • 系统需要那些输入/输出？这些输入/输出从何而来？到哪里去？
   • 执行者需要系统提供哪些功能？
   • 执行者是否需要对系统中的信息进行读、创建、修改、删除、或存储（RCUDS->read，create，update，delete，save）

3. 绘制出用例图，明确执行者与用例，用例与用例之间的关系。

4. 对每一个用例进行描述。可以使用状态图、活动图，也可以用文本型的用例文档。

5. 优化用例图。如解决用例间重复与冲突问题，对复杂的用例图可划分出不同的层次。

$感觉不是很重要，为了方便记忆$
$从运维，正常使用，服务提供者三方面出发$
$思考他们需要什么，或者需要他们做什么，而得到初步的用例图$
$然后描述每一个用例，最后做一次优化$

类图//能画就画画吧

类图（Class Diagram）包含了一组类以及他们之间的关系，是一种静态图。
类就是属性+方法的集合体。类比java即可。
这里类的关系包括关联（association）、聚集（aggregation）、泛化（generalization）、依赖（dependency）。

关联（Association）

该关系表示两个类或多个类之间的对应关系。用java的视野来看，就是一方的类的属性中含有对方的类的引用。
在类图中，使用Ax———>yB表示关联，说明A拥有B的引用。
这里的x，y表示个数，表示这一端的一个实例可以拥有多少个另一端实例。
xy可以在1，2，“n…m”，*这几种格式中转换。
“n…m”这种格式表示可以拥有[n,m]个实例。*表示任意个，包括0。

聚集（aggregation）

聚集表示整体和部分的关系，分共享聚集和组合聚集。

共享聚集使用A1———◇*B表示，表示A由B组成，但是就算没有A，B也能够存在。

组合聚集使用A1———◆*B表示，也表示A由B组成，但是如果没有了A，B不能够存在。
$无论是那种聚集，都是一对多的$

依赖（dependency）

表示两个或多个类之间的调用关系。
用A—>B表示A依赖B。也就是A会去使用B的一部分。可能是A的属性中有B的一部分，也可能是A的方法中把B当做了对象，也可以是调用了B类中的静态方法。

泛化（generation）

与用例图中的泛化相同，都表示其拥有共同父类。

建立类图的步骤

1. 研究分析问题领域，确定系统的需求
2. 发现问题领域中的对象和对象类，明确它们的含义和责任，以确定属性和操作。
3. 发现类之间的静态关系。着重分析找出类之间的一般和特殊关系，部分与整体关系，研究类的继承性和多态性，把类之间的静态联系用关联、泛化、聚合、依赖等关系表达出来
4. 设计类与关系。调整和精化已得到的类和类之间的关系，解决诸如命名冲突、功能重复等问题。
5. 绘制类图并编制相应的说明。

$相比起用例图，类图更加侧重于开发视角。$

状态图//建议画一下

状态图（State Diagram）用于描述一个特定对象的所有可能的状态及其硬气状态转移的事件。
状态 所有对象都具有状态，状态是对象执行了一系列活动的结果。当某个事件发生后，对象的状态将发生变化。状态图中定义的状态有：

• 初态–状态图的起始点。一个状态图必须有且只有一个初态。
• 终态–状态图的终点。一个状态图一般有多个终态
• 中间状态–可包括两个区域：名字域与活动域。
• 复合状态–可以进一步细化的状态称作复合状态。

状态迁移-- A————>B,中间这个箭头，表示状态迁移。
在状态图中，该箭头多附加一个事件在上面，表示该事件造成了状态的迁移。如果没有标明，则表示在源状态执行完了内部活动后自动触发了状态转移。

虽然在状态图中没有表示，（至少我没写过）但是状态图是自带几个活动的。
entry/exit活动表示进入/离开该状态必须要做的事情。
do活动知名在该状态可以做的事情。（不包括entry和exit）

建立状态图的步骤

1. 选择初始状态和终结状态。
2. 发现对象的各种状态。注意应当仔细找出对问题有意义的对象状态属性，这些属性具有少量的值，且该属性的值的转换受限制。状态属性值的组合，结合行为有关的事件和动作，就可以确定具有特定的行为特征的状态。
3. 确定状态可能发生的转移。注意一个状态可能转移到哪些桩体，对象的哪些行为可引起状态的转移并找出出发状态转移的时间。
4. 把必要的动作加到状态或转移上。
5. 分析状态的并发和同步情况。
6. 绘制状态图。
   

活动图

活动图（Activity Diagram）的应用非常广泛，他既可以用来描述操作的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行过程。
活动图是由状态图变化而来的，他们各自用于不同的目的。活动图描述了系统中$各种活动的执行的顺序$。刻画一个方法中所要进行的各项活动的执行流程。
而状态图表示个体的状态的变迁。

活动图的模型元素有：活动、转移、对象流、泳道等。

活动

在活动图中用圆角方框表示，也是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移。
在解释活动时，需要从相应的角度出发来解释。在解释概念时，活动表示要完成的任务；在说明实现时，活动则是类中的方法。

转移

即各活动之间的关系，描述由于隐含事件引起的活动变迁。使用———>表示
可以标注执行转移的条件，不标注则为顺序执行。

分支与合并。
分支，即一个活动转移出了两个活动。
合并，即两个活动转移向了同一个活动。

泳道

泳道进一步描述完成活动的对象，并聚合一组活动。也是一种分组机制。

在该图中，泳道就是三个方框，置于其上的则是泳道的对象。
$在starUMI工具中，建议先生成泳道以防出现未知的bug$

对象流

活动图中可以出现一个临时的对象（泳道本身也是一个对象，只是在其内部还有方法序列），该对象可以作为活动的输入与输出。并且还有一个分支与一个合并。

在该图中，获取订单时获取了一个对象，并将该对象传给了操作者让其开始填写订单活动。操作者填写完订单后将对象传给了销售让其交付订单。
—　—＞用于指向对象流和从对象流指出，表示该对象的产生和传输方向。

建立活动图的步骤

1. 找出负责实现工作流的业务对象。这些对象可以是现实业务领域中的实体，也可以是一种抽象的概念或事物。为每一个重要的业务对象建立一条泳道。
2. 确定工作流的初始状态和终结状态，明确工作流程的边界。
3. 从初始状态开始，找出随时间而发生的活动，把他们表示成活动状态。
4. 对于复杂的动作或多次重复出现的一组动作，可以把他们组成一个活动状态，并且用另外一个活动图来展开表示。
5. 给出连接活动的转移。首先处理顺序活动流，然后处理条件分支。最后处理分叉和接合。
6. 在活动图中给出与工作流程有关的重要对象，并用虚箭线把他们与活动状态相连接。

顺序图

顺序图(Sequence Diagram)用来描述对象之间动态的交互行为,着重体现对象间消息传递的时间顺序。
顺序图存在两个轴:水平轴表示一组对象,垂直轴表示时间。
顺序图中的对象用一个带有垂直虚线的矩形框表示, 并标有对象名和类名。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。
对象间的通信通过在对象的生命线之间消息来表示，消息的箭头类型指明消息的类型。

对象

对象用矩形框图表示，它们代表参与交互的对象。
"name: ClassName"来标记

生命线

生命线表示对象存在的时间，在顺序图中生命线表示从对象图标向下延伸的一条虚线。生命线从对象创建时开始到对象消亡时终止，对象存在的时间有多长，说明对象的生命线的虚线就有多长。

激活

激活是过程的执行的时间，包括它等待嵌套过程执行的时间。当一个对象在激活期时，该对象处于激活状态，能够响应或发送消息，执行动作或活动。当一个对象不在激活期时，该对象处于休眠状态，什么事都不做，但它仍然存在，等待新的消息来激活它。

消息

在面向对象技术中，对象间的交互是通过对象间消息的传递来完成的。在UML的所有动态图（活动图、状态图、顺序图和协作图）中，消息作为对象间的一种通信方式来表示。

• 简单消息(Simple Message)：表示简单的控制流。用于描述控制如何在对象间进行传递，而不考虑通信的细节。
• 同步消息(Synchronous Message)：表示调用的控制流。操作的调用是一种典型的同步消息。调用者发出消息后必须等待消息返回，只有当处理消息的操作执行完毕后，调用者才可继续执行自己的操作。
• 异步消息(Asynchronous Message)：表示异步控制流。当调用者发出消息后不用等待消息的返回即可继续执行自己的操作。异步消息主要用于描述实时系统中的并发行为。
• 返回消息(Return Message)：将一个简单消息和一个同步消息合并成一个消息，即操作调用一旦完成就立即返回。

建立顺序图的步骤

1. 确定交互的上下文。
2. 找出参与交互的对象类角色，把他们横向排列在顺序图的顶部，最重要的对象安置在最左边，交互密切的对象尽可能相邻。在交互中创建的对象在垂直方向应安置在其被创建的时间点处。
3. 对每一个对象设置一条垂直的向下的生命线。
4. 从初始化交互的信息开始，自顶向下在对象的生命线之间安置信息。注意用箭头的形式区别同步消息和异步消息。给出消息标签的内容。
5. 在生命线上绘出对象的激活期。
6. 根据消息之间的关系，确定循环结构及循环参数和出口条件。

包图//PPT就俩张咱也不懂,也不是特别重要的部分

表示包之间的关系的图。一个包可能是一个用例，或者一个系统。参考java的包。
主要是依赖关系（数据库第6章关系的依赖），包图中—>，箭头指向即被决定者。

回目录

恭喜你看到这里啦！距离60分就差一点点了加油啊！

需求获取

愿景

定义：向往的前景，愿景是为整个软件开发的组织服务，对于软件项目，愿景通常也是由关键性客户或公司的重要管理者提出。软件项目的愿景来源于不只一个人。
同一个项目在不同的角度来观察，这个项目的意义是不一样的。（包括用户，开发，客户）。
那么在这里必须确定权重，也就是谁最重要，谁是最有权力的涉众，必须满足的来源。即：老大。（一般属于客户，也一般不会在系统中看到老大存在）
在“老大”看来：为什么要开发这个项目。就成为了愿景，这份愿景就是整个项目的核心价值目标。
要完成一个价值目标，就应该有多份指标来确定项目的完成度。这里的指标，也就是度量指标，它不应当是某样事物本身（比如建立什么系统，拥有什么功能，这种看上去像目标的）。他应当是减少什么时间，提高效率，一切能够被计算出效果的东西。（笔试情况下请认准“加速”，“提质”，“有无”等字眼，这些对标度量指标）
$实际情况下，度量指标是被量化的，也就是可以被计算，也不是加速，提质这种还是略显空的字眼$

$愿景来源于老大，且必须有度量指标（愿景的两个要点）$

涉众

客户：最大的涉众
用户：越是一线用户，往往排位越低。资本往往不会在意韭菜的想法
用户甚至不是涉众的必须项。有些系统开发出来是为其他系统服务的。

涉众存在的意义：项目是为了完成某个目的而存在的，但是完成目的的方式是多样的。但是业务需求（涉众利益）是稳定，不易变的。
没人在意你用printf还是println完成输出

回目录

业务建模

目的：描述显示，帮助发现软件需求。
UML用两种模型描述显示：业务用例模型和业务对象模型。

业务单元

在讲这个概念之前，我们要先讲业务实体——也就是这个业务的直接指向。而业务单元则稍稍细一些——指向我们需要修改的对象。就比方说看病，看的肯定是人（业务实体），但具体要看的实际上是你的病变器官（业务单元）。$自己的理解$
可能太生动了,我们用另一个例子。当一个公司打算做贯标工作时，需要开发系统来管理文档。那么此时的业务单元就是贯标工作小组（不知道啥是贯标的请移驾百度），业务实体就是整个公司。
业务单元是一个组织或者是人群，不一定是整个目标。

业务执行者

在$业务之外$和业务交互的人或组织。

<span id="Business_worker>业务工人

在业务之内承担服务的人。

业务实体

$待补充,我会问老师业务实体和业务单元的区别的！！！$

业务用例

业务用例，也就是我们的用例图中的重点，用例。两者其实是一样的，其本质仍是：用户与系统之间的一次交互。也是将用户所需的信息输出返还。
所以依着这个本质，系统内部的活动不是业务用例。
在描述时，用业务语言而不是技术语言。
同时，在描述时，使用动宾结构，且使用清晰地表达。
$不要使用服务,数据等较为笼统的说法。$
$先确定这是一个业务！使用笼统的说法可能会导致这变成一个功能。$

$用例的粒度,我还不知道是什么。大致上就是讲一个用例的细分程度？$
$过细的用例容易被视为是CRUD（创造，读取，更新，删除），过粗又趋向功能$
当然，也可以使用.用例图.活动图.顺序图方式来描述用例的地位和实现。
$用例是系统做的事情，除非是智能化，这个系统是不能处理数据的$

业务对象模型

业务对象模型（领域模型）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象，注重业务中承担的角色及其当前职责。
官话讲完，说人话。业务对象模型就是从各个角色出发来观看一个业务是怎么创生又是经过了谁的手做了什么事。
再简单一点，谁对什么东西做了什么事。
比如我今天去找银行办银行卡。显然这在用例图（业务用例模型）中就是一个人后面拉条先再画个圆里边写个办理银行卡。
那在业务对象模型呢。那就有这么几个对象：申请者，前台，申请单，银行卡。好了我想你已经能get我的点了。谁还没办过银行卡啊？

一些常识收录

经过我校高层管理人员的不懈努力，已经和百度在网络技术(北京)有限公司达成战略合作，以后凡是本校学生，将可以使用
www.baidu.com在上面搜索任何问题，无需询问同学各种学术问题，将极大程度的提高学生自己的获取知识的能力。
爽
本篇文章已更新至：基础知识，需求获取。
目前正在更新：需求分析。
还剩：未知。

本文档中，$红字，表示一般的重点项$
$紫色，表示对某些人物的尊敬$
$蓝色，是我个人认为的难点$
$绿色，表示一些自己添加的注释$
带删除的字样一般表示玩乐性质的注释

$需求分析是一切软件开发的基础$
$也是软件开发过程中“最关键性的和最易出问题的地方$

本门课程最核心的理论需求能用一个图简单的反应出来

最为困难的概念性工作便是编写出详细技术需求

探索系统需求就是探索涉众利益的平衡点。

$写在最后，给我自己,如果图片显示不出来了一定要记得把路径写对啊！！！$
$写在最后，给我自己,记得去问老师业务实体和业务单元的区别啊！！！$
$写在最后，给我自己,记得去问老师用例的粒度是什么啊！！！$
回目录