需求分析与系统设计总结(三)

二. 需求确定

  • 从业务过程到解决方案构想
    需求分析与系统设计总结(三)_第1张图片
  1. 过程层次建模:
     业务过程模型:可以通过多个不同大小的过程来定义,从全业务范围内的过程到单独一个人完成的过程。
     过程和过程分解:一个过程至少有一个输入流和一个输出流。过程获得控制,主要通过将输入流转变为输出流来完成响应的活动。过程可以是原子过程或者复合过程,原子过程不包含任何子过程。复合过程通过子过程来描述它的行为。
     过程层次图:对过程模型的图形化展示

  2. 业务过程建模:
    1.流对象
    事件:某些“发生”的事物,通常由一个原因(触发器)或者产生一个影响。
    活动:某些必须进行的工作,可能是一项任务或者一个子过程
    路由:用来控制多个序列流的分支和聚合。
    2.连接对象:用来连接流对象。
    序列流:用来表示一个过程中活动完成的序列。
    消息流:用来表示准备发送和接收消息的两个业务实体(过程参与者)之间的消息(数据)
    关联:用来关联两个流对象,或者关联一个人工制品与一个流对象。
    3.泳池:表示一个过程中的业务实体(参与者)。
    4.人工制品:提供附加的建模灵活性,允许我们扩展基本表示法来应对特殊的建模环境。可以预定义3种类型的人工制品:数据对象,组和注释
    数据对象:表示活动需要的数据或者活动产生的数据。
    组:是不影响过程序列流的一组活动
    注释:为业务过程图的读者提供附加的文本信息。

3.解决方案构想
常规开发:手工的,单机的,从零开始的软件开发覆盖了软件开发过程的所有阶段(生命周期)。
基于包开发:通过定制先前存在的软件包来得到解决方案。
基于构件开发:通过集成来自多家销售商或者商业伙伴的软件构件来构件解决方案。

  • 需求引导

1.系统需求:
功能性需求:定义系统期望的服务(服务陈述)和系统必须遵守的约束(约束陈述)。
包括:系统的范围,必要的业务功能和所需的数据结构.

非功能性需求:非功能性需求本质上不是行为的,而是系统开发和实现过程中的约束。
非功能性需求包括:可用性,可复用性,可靠性,性能 ,效率 ,适应性

可用性:定义使用系统的容易程度。当一个系统更容易使用的使用,它就具有更强的可用性。文档和帮助实施,为高效使用提供必要的培训,用户界面的美观和一致性,错误处理等,这些都决定了可用性。
可复用性:定义在新系统的开发中,重复使用之前已实现的软件构件的容易程度。可复用性反映了软件开发团队和作为工业领域的软件工程的成熟度。
可靠性:与系统失效的频率和严重性以及系统从失效中恢复的程度相关。可靠性由系统运行时间内所要求的系统有效性,可接受的失效之间的平均时间,产生结果的正确性等因素决定。一个可靠的系统是可信任,用户能够信任并依赖它的。
性能:通过系统响应时间,事务处理时间,资源开销,可能的并发用户数量等的期望来确定。

2.客户和领域专家面谈:
3种问题避免:固执已见的问题,带偏见的问题,强加的问题
5W原则:what:何事,who:何人,when:何时,where:何地,why:为什么
3.需求引导的方式:(传统方法&现代方法)

1.调查表:作为面谈的补充形式。
2.文档和软件系统的研究:文档和软件系统的研究是发现用例需求和领域知识需求的宝贵技术。用例而需求通过研究已有的企业文档和系3.统表格/报告来发现。对用例需求最有价值的了解方式之一是缺陷的记录和现有系统的变更请求。

1.原型法:是最常使用的需求引导方法。
通常,当使用其他方法很难从客户那里获得需求时,系统原型是一种非常有效的需求引导方法。
给客户演示一个系统,使整个系统或者系统的一部分对用户可视化,以便获得他们的反馈。
2. 丢弃
3. 进化
4. 头脑风暴:通过放下公正、社会禁忌和规则来产生新思想或者发现专业问题解决方案的一种会议技术。通常,头脑风暴不是为了分析问题或者做出决定,而是产生新思想或者可能的解决方案。

  • 需求协商与确定

1.原因:
 来自客户的需求也许是重叠或者矛盾的。
 有些需求可能是模棱两可或者不可实现的。
 有一些需求可能还没有发现。
2.需求协商:通常以文档的草稿为基础。如果有必要,要对文档草稿中列出的需求进行协商和修正,删除错误的需求,增加新发现的需求。
3.需求确认:需要完整的需求文档,所有的需求都要被清楚地标识和分类。
4.需求协商和确认需要解决下面3个问题:
 超出范围的需求:超出体系设计范围的需求。设定设计范围是需求分析阶段的重要课题。
 需求依赖矩阵:梳理标识需求之间的依赖关系。
 需求风险和优先级:对需求进行风险分析和排列优先级。

  • 需求管理

1.需求标识和分类:按某种标识方案对需求进行编号,这个方案可能包含将需求划分为更多的可管理组的需求分类。
2.分类方案:
 唯一标识符
 在文档层次内的顺序编号
 在需求分类中的顺序编号
3.需求层次:需求可以按父子关系建立层次结构。
4.需求变更:在开发生命周期的任何阶段,需求都可能变更,可能删除已有需求或者增加新的需求。

  • 需求文档

1.需求文档主要内容:
 项目准备
 系统服务
 系统约束
 项目其他问题
 附录

你可能感兴趣的:(程序人生,经验分享,程序人生,恰饭,其他)