需求分析与定义
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
顺序图以图形化的方式强调消息的顺序，而非协作对象间的顺序。他和协作图统称为交互图。
状态图：是一种用以显示对象在生命周期和转换期情况的图
2.需求调查与问题定义：
在做需求调查时需要做到两W一H即What、Where、How
1)、What-----应该收集什么信息
2)、Where----从什么地方收集
3)、How-------用什么机制或技术来收集
3.需求分析
需求分析通常包括六个方面：
1)、绘制系统上下文范围关系图：主要用于定义系统与系统外部实体间的界限和接口的简单模型，他可以为需求确定一个范围。其实就是DFD的0层图。
需求分析与定义
1.软件需求：
软件需求分为三大部分：
1)、功能需求：指系统需要完成那些事情，即向用户提供那些功能。
2)、非功能需求：指产品所具备的品质和属性，比如可靠性、扩展性、响应时间、性能等等。。。
3)、设计约束：也称条件约束、补充规则。比如用户要安装该产品他需要有什么样的必备条件。（系统对操作系统的要求、硬件环境的要求等等…..）
5.面向对象需求分析（OOA）
面向对象这个概念很简单但也很复杂我在这里不做深入探讨。我将从实际出发来和大家一起探讨下在实际开发中我们应该怎么做。
OOA的精髓在于世间万物均为对象采用OOA方法在整个过程中包括2个工作任务：建立一个反应问题域静态关系的概念模型，就是我们通常所说的类图；另一个反应系统行为的动态模型，即用例模型那么我们在实际开发中到底怎么做呢？
简要说明
事件流：是该用例要完成的工作步骤
非功能需求
前置条件
后置条件
扩展点
ቤተ መጻሕፍቲ ባይዱ优先级别
3）要想做好需求分析光上面的用例是不够的还有写建模技术也要有如：协作图、顺序图和状态图
协作图：是一种用以显示对象如何被协调在一起执行用例的图，用来识别协作完成给定业务的对象。
顺序图：是一种用以显示用例对象之间消息顺序的图，他与协作图表达的信息是一样的知识显示的方式有差别。
3)、面向对象分析方法（Object Oriented Analysis，OOA）：这也是我下文想讲的分析方法
4)、面向问题域的分析（Problem Domain Oriented Analysis,PDOA）：OOA也存在着很多不足，但PDOA现在正在研究中所以未被广泛应用。这里需要注意的是：在软件开发中有很多需求分析方法他们没有好坏之分只要你运用得当照样可以做出一个很好的系统，依据个人对某个方法的理解用自己最擅长的方法是最明智的选择。
4)、确定需求的优先级：可采用满意度/不满意度指标来说明（满意度1-5表示当需求被实现时用户的满意程度；不满意度取值同理）
5)、为需求建立模型：这里可以用UML创建用例图或是E-R图再加上少量的文字描述。
6)、使用质量功能调配（QFD）：这里我的理解是分析员根据需求的理解发现隐藏需求而这些需求是用户也没有想到的需求，系统实现后会给用户一个惊喜，而没实现用户也不会有抱怨。
4.需求分析方法
现在比较流行的软件需求分析方法有4种，其中3种理论比较成熟。
1)、结构化分析方法（Struetured Analysis,SA）：这个大家想必很熟悉了不在复述。
2)、软系统方法：这只是过度性的方法论他的出现只是证明结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决“不确定性”时显得十分无力。
域模型的详细度：这里不做太多要求可以写的很详细也可以写的简单写，可以把握好一个原则：只要能有利于团队更好的开发就是好模型。
2）建立用例模型
什么是用例：
用例实例是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的价值结果。（用例实例就是常说的“使用场景“）一个用例定义一组用例实例。
识别参与者：
用例主要是为了让客户直观的理解需求那么这里参与者是必不可少的这样才能形象的勾画出系统某个特定场景下的流程。
注意参与者不仅可以是人也可以是其他的事物如（其他系统、硬件设备、时钟等等）
合并需求获得的用例
绘制用例图（如果对用例图不清楚请参考UML相关文章）
细化用例描述
用例描述可以包括以下几个部分：
用例名称
1）建立域模型
寻找类：在寻找类时有多种方法典型的是根据需求文档用“名词动词法”来寻找，找出备选类后再从中寻找出真正的类。（注意在用此方法时切记不要咬文嚼字专牛角尖在这里花费很长的时间）
确定类之间的关联：这个过程是迭代的我们需要理清楚这些类之间的关系如关联、继承、聚合等然后通过UML记录下来。类之间的关系不是一下子就能确定下来的是要慢慢完善的为类添加职责：这里就可以理解成为类添加所需要的属性和方法。
2)、创建用户接口原型：这里我们可以把他看成是用户操作的一个雏形，什么意思呢就是我们通常所说的界面用户通过一系列的操作完成他想达到的效果的接口。
3)、分析需求的可行性：这个需求我们应该用什么技术解决，他实现后的性能怎么样，是否与其他需求相重合或是矛盾，这里一定要注意不要把系统的这个需求怎么用代码实现想进去。在需求分析时应多注意需求本身是否有用不必考虑怎么实现。
状态图：是一种用以显示对象在生命周期和转换期情况的图
2.需求调查与问题定义：
在做需求调查时需要做到两W一H即What、Where、How
1)、What-----应该收集什么信息
2)、Where----从什么地方收集
3)、How-------用什么机制或技术来收集
3.需求分析
需求分析通常包括六个方面：
1)、绘制系统上下文范围关系图：主要用于定义系统与系统外部实体间的界限和接口的简单模型，他可以为需求确定一个范围。其实就是DFD的0层图。
需求分析与定义
1.软件需求：
软件需求分为三大部分：
1)、功能需求：指系统需要完成那些事情，即向用户提供那些功能。
2)、非功能需求：指产品所具备的品质和属性，比如可靠性、扩展性、响应时间、性能等等。。。
3)、设计约束：也称条件约束、补充规则。比如用户要安装该产品他需要有什么样的必备条件。（系统对操作系统的要求、硬件环境的要求等等…..）
5.面向对象需求分析（OOA）
面向对象这个概念很简单但也很复杂我在这里不做深入探讨。我将从实际出发来和大家一起探讨下在实际开发中我们应该怎么做。
OOA的精髓在于世间万物均为对象采用OOA方法在整个过程中包括2个工作任务：建立一个反应问题域静态关系的概念模型，就是我们通常所说的类图；另一个反应系统行为的动态模型，即用例模型那么我们在实际开发中到底怎么做呢？
简要说明
事件流：是该用例要完成的工作步骤
非功能需求
前置条件
后置条件
扩展点
ቤተ መጻሕፍቲ ባይዱ优先级别
3）要想做好需求分析光上面的用例是不够的还有写建模技术也要有如：协作图、顺序图和状态图
协作图：是一种用以显示对象如何被协调在一起执行用例的图，用来识别协作完成给定业务的对象。
顺序图：是一种用以显示用例对象之间消息顺序的图，他与协作图表达的信息是一样的知识显示的方式有差别。
3)、面向对象分析方法（Object Oriented Analysis，OOA）：这也是我下文想讲的分析方法
4)、面向问题域的分析（Problem Domain Oriented Analysis,PDOA）：OOA也存在着很多不足，但PDOA现在正在研究中所以未被广泛应用。这里需要注意的是：在软件开发中有很多需求分析方法他们没有好坏之分只要你运用得当照样可以做出一个很好的系统，依据个人对某个方法的理解用自己最擅长的方法是最明智的选择。
4)、确定需求的优先级：可采用满意度/不满意度指标来说明（满意度1-5表示当需求被实现时用户的满意程度；不满意度取值同理）
5)、为需求建立模型：这里可以用UML创建用例图或是E-R图再加上少量的文字描述。
6)、使用质量功能调配（QFD）：这里我的理解是分析员根据需求的理解发现隐藏需求而这些需求是用户也没有想到的需求，系统实现后会给用户一个惊喜，而没实现用户也不会有抱怨。
4.需求分析方法
现在比较流行的软件需求分析方法有4种，其中3种理论比较成熟。
1)、结构化分析方法（Struetured Analysis,SA）：这个大家想必很熟悉了不在复述。
2)、软系统方法：这只是过度性的方法论他的出现只是证明结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决“不确定性”时显得十分无力。
域模型的详细度：这里不做太多要求可以写的很详细也可以写的简单写，可以把握好一个原则：只要能有利于团队更好的开发就是好模型。
2）建立用例模型
什么是用例：
用例实例是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的价值结果。（用例实例就是常说的“使用场景“）一个用例定义一组用例实例。
识别参与者：
用例主要是为了让客户直观的理解需求那么这里参与者是必不可少的这样才能形象的勾画出系统某个特定场景下的流程。
注意参与者不仅可以是人也可以是其他的事物如（其他系统、硬件设备、时钟等等）
合并需求获得的用例
绘制用例图（如果对用例图不清楚请参考UML相关文章）
细化用例描述
用例描述可以包括以下几个部分：
用例名称
1）建立域模型
寻找类：在寻找类时有多种方法典型的是根据需求文档用“名词动词法”来寻找，找出备选类后再从中寻找出真正的类。（注意在用此方法时切记不要咬文嚼字专牛角尖在这里花费很长的时间）
确定类之间的关联：这个过程是迭代的我们需要理清楚这些类之间的关系如关联、继承、聚合等然后通过UML记录下来。类之间的关系不是一下子就能确定下来的是要慢慢完善的为类添加职责：这里就可以理解成为类添加所需要的属性和方法。
2)、创建用户接口原型：这里我们可以把他看成是用户操作的一个雏形，什么意思呢就是我们通常所说的界面用户通过一系列的操作完成他想达到的效果的接口。
3)、分析需求的可行性：这个需求我们应该用什么技术解决，他实现后的性能怎么样，是否与其他需求相重合或是矛盾，这里一定要注意不要把系统的这个需求怎么用代码实现想进去。在需求分析时应多注意需求本身是否有用不必考虑怎么实现。