精华内容
下载资源
问答
  • 如何在需求中确定实体
    千次阅读
    2019-01-16 16:15:00

     

    • 需求文档
      • 功能性需求还可以进一步分为功能性需求和数据需求
      1. 文档模板
        1. 项目准备、
          1. 项目的目的和范围
          2. 业务环境
          3. 利益相关者stackholders
          4. 多种解决方案
          5. 文档综述
        2. 系统服务(功能需求)——占总篇幅的一半及以上
          1. 系统范围(环境图来建模)
          2. 功能性需求(业务用例图)
          3. 数据需求(没有属性方法的类图即业务类图)
        3. 系统约束(非功能性需求)
          • 接口需求 是系统约束
          1. 界面需求,大概画出来界面长啥样,给一个界面原型
          2. 性能需求,如响应时间、可靠性、吞吐量,用可测量可衡量的数据表示
          3. 安全性需求,访问权限
          4. 操作性需求,决定系统运行的软硬件环境
          5. 政策法律需求
          6. 其他约束
        4. 项目其他问题
          1. 开放问题
          2. 初步安排
            • 可以使用项目管理软件工具制作标准规划图,如PRET或Gantt图
          3. 初步预算——初步安排的直接结果
        5. 附录
          1. 词汇表
            1. 术语
            2. 简写词
          2. 业务文档和表格
          3. 参考文献
    • 业务词汇表,实际是业务词典
      1. 一般包含项目陈述中的名词
    • 业务类模型,和实体类模型差不多,它的抽象级别更高
      • 业务类模型是UML类模型,是标识系统中业务对象的主要类型。
      • 业务类可以通过3个UML关系连接到模型中,这三个关系是关联association、泛化generalization、聚合aggregation。关联和聚合标识类的实例(对象)之间的语义关系,泛化是类(对象类型)之间的关系。
    • 需求引导——最不需要技术,但最需要技巧的环节
      1. 功能性需求——由系统期望的服务(服务陈述),侧重功能性需求
        1. 分为几组:
          1. 系统的范围
          2. 必要的业务功能
          3. 数据结构
        2. 功能性需求需要从客户处获得
        3. 收集到的需求需要仔细的分析以消除重叠和矛盾,这个过程总会导致需求评审和与客户的再次协商。
      2. 非功能性需求(补充需求)——系统必须遵守的约束(约束陈述),如性能、安全性
        1. 分为以下几种:
          1. usability可用性:定义使用系统的容易程度,如适当的提示,错误处理,文档帮助
          2. reusability可复用性:在新系统开发中,重复使用之前软件系统构件的容易程度
          3. reliablity可靠性:系统失败的频率和严重性以及系统从失效中恢复的程度有关
          4. performance性能:通过系统响应时间、事务处理时间、资源开销、并发等级
          5. efficiency效率:考虑时间效率和成本效率
          6. supportability适应性(可支持性):可理解性、可维护性、可扩展性
          7. 其他约束:政策法律约束,便捷性或可交互性等要求
      3. 需求引导方法
        1. 传统方法——适用于目标明确,低风险的项目
          1. 面谈(发现事实和聚集信息的基本技术)
            1. 结构化访谈——需要提前准备,有一个明确的日程,预先确定问题
              1. 开放问题,客户的答案无法估计
              2. 封闭问题,客户从提供的答案简单回答是或否
              • 需要非结构化面谈进行补充
            2. 非结构化(非正式)访谈:没有预定的问题和预计目的,鼓励客户说出自己的想法,如街头采访
          2. 调查表questionnaires(向客户收集信息的有效方法),一般用来作为面谈的补充形式,而非替代
            1. 调查表设计应该使回答问题变得更容易,应该尽量避免开放式问题,封闭式问题的如下三种形式:多项选择multiple-choice、评价rating questions(完全同意、反对)、排序问题ranking question
            2. 当需要调查许多人的观点而他们又地理分散的时候,调查表特别有用和经济。
          3. 观察(有效的发现事实的技术,获取面谈与调查表之外的获取不到的信息)
            1. 被动观察passive,业务分析员观察业务活动而不直接打扰或干预,比如安装摄像机
            2. 主动观察active,业务分析员参与到活动中,称为团队的一部分
            3. 解释观察explanatory,工作时,用户向观察者说明他进行的活动
          4. 研究业务文档(发现用例需求和领域知识需求的宝贵技术)
        2. 现代方法——适用于风险高的项目
          1. 原型法(最常使用的现代需求引导方法)quick and dirty solution to obtain feedback
            1. 丢弃原型throw away,当需求引导完成时该原型将被丢弃,主要集中在理解的最少的需求上
            2. 进化原型evolutionary,在需求引导过程之后仍被保留并用来产生最终产品。进化原型将产品发布的速度作为目标,主要集中在理解的很好的需求上
          2. 头脑风暴(通过放下一系列约束来产生新思想或发现专业问题解决方案的一种会议技术)
            • 头脑风暴通过触发式问题的想法发挥作用,其他需求引导方法都不是
            1. 调解人facilitator为将产生的新想法界定问题/机会领域,这被称作问题机会陈述“probortunity
            2. 会议最后一部,投票表决想法的优先顺序
          3. 联合应用开发(joint application development,JAD)
            1. 类似于头脑风暴技术,一次会议可能需要几小时、几天或几周,参与人数25-30人
            2. 参加者:领导leader、文书scribe、客户customer(用户和经理)、开发人员developer
            3. JAD利用了群体动力优势
          4. 快速应用开发(rapid application development,RAD)
            1. 不仅是一种需求引导方法,还是将软件开发作为一种过程的方法
            2. 目标时快速交付系统解决方案,技术精良程度次要
            3. 带来相应问题:
              1. 不一致的GUI设计
              2. 支持软件复用的专业解决方案,非通用解决方案
              3. 不足的文档
              4. 难以维护和扩展的软件
            • 5种技术:
              1. Evolutionary prototyping
              2. Case tools
              3. SWAT,拥有先进工具的专业人员
              4. Interactive JAD
              5. Timeboxing
    • 需求协商negotiation与确认validation
      • 获取的需求可能是overlap or conflict重叠的或者矛盾的,或者是ambiguous or unrealistic模棱两可或者不实际的,还可能undiscovered,out of scope,因此需要需求协商与确认
      • 需求协商与确认与需求引导同步进行
      • 需求协商以文档的草稿为基础,需求确认需要更加完整的文档确认版本
      1. 超出范围的需求
        • 为了确定任何特定需求再系统范围之内还是之外,需要对照参考模型才能决定。
        • 历史上的参考模型以关联图的形式提供——数据流图DFD,一种流行的结构化建模技术顶层图。虽然DFD在UML中已被用例图代替,关联图仍然是建立系统边界的很好方法。
      2. 需求依赖矩阵或交互矩阵N*N,表示N个需求
        • 按一种分类顺序分别再行和列的表头上列出需求标识符
        • 矩阵的↗部分没有使用,剩下的单元格表示任何两个需求是否重叠、矛盾或独立。矛盾的需求应该与用户讨论,也可能要重新陈述这个需求以避免矛盾(矛盾记录保留,对后续开发可见)。重叠的需求也要重新陈述以消除重叠
        • 当需求数目较少,需求依赖矩阵是一种发现需求矛盾和重叠的简单有效的技术。
      3. 需求风险和优先级
        • 解决完需求中的矛盾和重叠后,就产生了一组修正后的需求,需要对这些需求进行风险分析并排列优先级
        1. 需求决定了项目的feasibility可行性,需要对风险进行优先级排序
        2. 风险分类
          1. 技术风险,需求在技术上难以实现
          2. 性能风险,需求实现后,会延长系统的响应时间
          3. 安全风险,需求实现后,会破坏系统的安全性
          4. 数据库完整性风险,需求不容易验证,并且可能导致数据的不一致性
          5. 开发过程风险,需求要求开发人员采用不熟悉的非常规开发方法,如形式化规格说明方法
          6. 政治风险,由于内部的政治原因,很难实现需求
          7. 法律风险,需求可能触犯现行法规或者假定了法律的变更
          8. 易变性风险Volatility risk,需求很可能再开发过程中不断变化或进化
    • 需求管理
      1. 需求标识与分类
        1. 自然语言描述需求
        2. 几种对需求进行标识分类的技术
          1. 唯一标识符,由手工方式或者CASE工具的数据库生成
          2. 文档层次的序列编号,考虑在需求文档中的位置的编号,如2.4.7
          3. 需求分类中的顺序编号,加上一些帮助记忆的标识需求种类的名字赋值,需求种类可以实共轭能行需求、数据需求、性能需求、安全需求或其他需求
          • 每种标识方法都有赞成者与反对者。最灵活和最不易出错的方法是数据库生成唯一标识符
      2. 需求层次——需求可按父子关系建立层次化结构,父级需求由子级需求组成,子集需求是父级需求有效的子需求。
      3. 变更管理
        1. 需要变更管理的原因:需求是变更的,在软件开发生命周期的任何阶段,需求都可能变更,可能删除已有需求或者增加新的需求。变更本身并不会导致困难,但没有管理的变更会更麻烦。开发越往前走,需求变更的开销越大。
        2. 需要强有力的政策来建立变更请求的文档,估计变更的影响并实现变更
        3. 运用的工具:需求的变更应由软件配置管理工具存储和跟踪
      4. 需求可跟踪性——变更管理的一部分,或者说重要部分
    • 需求业务模型,不属于UML,是高层可视化模型
      • 需求确定阶段:完成所收集需求的高层可视化表示(称之为业务需求建模)
      • 需求规格说明阶段:UML进行形式化的需求建模
      1. 系统范围模型
        • 需求变更会引起系统范围蠕变,当需求中的某些变更不可避免的时候,我们必须确保请求不会超出项目可接受的范围。
        • 我们需要知道系统运行的环境。我们需要知道外部实体——期望从我们这里得到服务或为我们提供服务的其他系统、组织、人员、机器等。在业务系统中,这些服务转换成信息——数据流。
        • 因此,系统范围可以通过识别外部实体以及在外部实体和我们系统之间的输入/输出数据流来确定。
        1. UML不提供定义系统范围的好的可视化模型。因此用老式的DFD环境图context diagram表示系统范围
      2. 业务用例模型——高抽象级别的用例模型
        • 业务用例模型标识高层业务进程——业务用例。这样的用例是以某种方式定义一个过程,这个过程完全是从它的实现中抽象出来的。
        1. 业务用例图,获取的是业务需求含有手工业务,即系统可能实现不了的业务服务,与用例图区分开。(整个模型代表商业观点,强调组织活动和工作任务,计算机系统不必对此提供支持)
        2. 实际上构造业务用例模型是为了使业务过程被开发中的信息系统支持。业务用例与所谓的系统特征相对应(系统特征在视觉文档中标识。如果存在视觉文档,那么它可以代替业务用例模型)
        3. 业务用例图的焦点是业务过程的体系结构,业务用例模型不足以向开发人员确切的表达系统应该做什么
        4. 在需求规格说明阶段,业务用例被转换成用例。就是在此阶段标识详细的用例;
        5. 业务用例图中的业务参与者有时可以标识环境图的外部实体。这种参与者也被称为次要参与者,它们对于用例是被动的,为了和用例通信,它们需要联合主要参与者。主要参与者是系统的中心,能够与用例主动通信。主要业务参与者通过发送事件来触发用例。
        6. 业务用例模型中重要的关系是关联关系,除了关联,一般不鼓励在业务用例之间使用UML关系
    • 解决方案构想solution envisioning
      • 是一个业务价值驱动方法,以提供解决当前业务问题和促进将来业务创新的IT服务。它在业务和IT利益相关者之间建立了紧密的联系,并且整合了业务战略方法和软件开发能力。
      1. 关注点:
        1. 有效effectiveness
        2. 效率efficiency
        3. 边界edge
      2. 构想过程阶段
        1. 业务能力探索
          1. 这里的业务能力可理解为为企业的IT解决方案提交具体成果的能力
          2. 该阶段描述一个能力案例(确定一项功能商业价值的建模元素),即提供了解决方案思路,为每个能力生成一个业务案例
        2. 解决方案能力构想
          1. 该阶段将能力用例发展成解决方案概念,确保利益相关者对这个方案的意见一致。解决方案概念将业务环境作为输入,产生的未来新工作方法的构想作为输出。
        3. 软件能力设计——软件建模过程
          1. 该阶段开发软件能力体系结构,也是建模输出产品
      3. 实现策略和能力体系结构
        1. 三种实现策略:
          1. 常规开发——手工、单机、从0开发软件
          2. 基于包的开发——定制先前存在的软件包
          3. 基于构件的开发(搭积木)——通过集成多个软件构件
    • 连接对象connector
      • 消息流在连接对象中,注意选择题
    • 泳池pool(泳道swimlanes)——描述单一的参与者(实体)的活动
      1. 水平的,竖直的,选择哪一种取决于作图的方便程度
    • 人工制品
      1. 如数据对象,表示活动需要的数据或者活动产生的数据。对于过程的消息流或者序列流,他们不会产生任何直接影响,但会提供额外的关于活动的信息。
      2. 组,目的是文档或分析
      3. 注释,为读者提供附加的文本信息。
    • 业务过程建模BPMN——描述过程内部细节,目的是为业务人员和IT人士提供一种共同的沟通语言。
      1. 4种基本建模元素
        1. 流对象——BPMN的核心元素
          1. events事件
          2. activity活动
            • 一个子过程在圆角矩形的下边界上有一个+,表示其为一个复合活动。复合活动可分解为一组子活动,他被看作展开的子活动。其他符号决定了其他属性:循环或者多实例执行。
          3. gateway路由(网关)
    • 从业务过程到解决方案的构想
      1. 过程层次建模Process hierarchy modeling
        • BPMN中,过程可能包含其他过程(子过程),将过程中的原子活动称为任务
        1. 业务过程模型:多个不同大小的过程来定义,从全企业范围的过程到单独一个人完成的过程。
          1. 过去用数据流图作为一种复杂的功能分解技术
          2. 现在用过程层次图——不是BPMN的一部分
            • 定义了业务过程模型的静态数据结构。它显示过程的层次结构,将顶层业务过程分解为子过程。
        2. 过程和过程分解
          1. 一个 业务过程能被看作手工操作的活动或者自动化服务
          2. 一个过程至少一个输入流和一个输出流
          3. 一个过程可以是原子的和复合的
    • 本章及后续章节从软件生命周期的阶段分布讲解,本章讲解需求分析阶段(包括需求确定+需求规格说明)中的需求确定阶段
    更多相关内容
  • 商城需求分析

    java web商城项目教程,教程结尾有商城源码下载。

    商城需求与实体分析

    • 主要需求分析
    • 实体关系分析

    商城主要需求

    1)需求描述

    对商城项目要求提供以下服务:

    1. 用户
      a. 注册登录操作
      b. 个人信息管理
      c. 商品操作(购物车,订单等…)
    2. 后台管理
      a. 用户管理
      b. 商品管理
      c. 分类管理
      d. 订单管理

    2)需求分析

    在每一个模块开始时进行讲解


    实体关系分析

    1)商城中的实体

    实体是客观存在并可相互区别的事物。就数据库而言,实体往往指某类事物的集合。把每一类数据对象的个体称为实体。
    

    ① 用户:用户实体,对应user用户表
    ② 商品:商品实体,对应product商品表
    ③ 订单:订单实体,对应orders订单表
    ④ 分类:类别实体,对应category分类表

    2)实体关系

    ①一对多关系:在“多”的一方表中添加一个“一”的一方的主键作为外键。
    ②多对多关系:新建一个关联表,在关联表中创建两个两张表的主键作为外键,分解为两个一对多的表关系。

    一个用户可以拥有多个订单,所以user用户表对orders订单表为一对多
    一个类别中可以有多个商品,所以category分类表对product商品表为一对多
    一个订单中可以有多个商品,同时这个商品可以被加入多个订单,所以orders订单表对product商品表为多对多,新建一个orderitem订单项表作为关联表。
    具体关系如下:
    在这里插入图片描述

    展开全文
  • 目录写最前一、 强实体与弱实体的定义1. 强实体2. 弱实体百度百科的解释《数据库系统课程》的解释总结起来 写最前 数据库设计是困难的,其原因之一就在于我们很难去完全把握实体的定义。是不是实体、该不该...

    写在最前

    数据库设计是困难的,其原因之一就在于我们很难去完全把握实体的定义。是不是实体、该不该定义实体是一直困扰数据库初学者的问题,强实体、弱实体的概念同样难以理解。
    我一直深受强实体、弱实体概念的困扰,百度百科中的定义不能很好地解决我的困惑,一路学习过来,自己对强实体、弱实体的理解越来越深入,因此写下这篇文章与大家分享自己对强实体与弱实体的一些体会。如果觉得有帮助,请点赞鼓励!

    一、 强实体与弱实体的定义

    1. 强实体

    其实例的存在不依赖于任何其他实体类型的实例;有自己独立的主键,唯一性地标识它的每个实例。

    2. 弱实体

    百度百科中的解释

    一个实体对于另一个实体(一般为强实体,也可以是依赖于其他强实体的弱实体)具有很强的依赖联系,而且该实体主键的一部分或全部从其强实体(或者对应的弱实体依赖的强实体)中获得,则称该实体为弱实体。

    《数据库系统课程》中的解释

    其实例的存在依赖于其它实体类型的实例;其主键包括它所依赖的实体类型的主键。

    总结起来

    百度百科中的解释和课程中的解释都是在强调两点:
    第一点:依赖,弱实体应该依赖于强实体;
    第二点:主键,弱实体的主键应该是组合主键(其他实体的主键组成的)。

    二、 关于定义的几个疑惑

    但定义中有几个地方令我不解,我相信初学者多少也会遇到同样的问题。我总结了四点:

    什么叫“依赖”?

    以教务系统数据库为例,如果没有学校,那么学院不再是学院,学生不再是学生,课程更将不复存在,所以这些实体都依赖于其他实体,因此这些都是弱实体?但我们知道,学院、学生一般都作为强实体。因此,定义中的“依赖”指的是什么呢?

    先有鸡还是先有蛋?

    是因为一个实体的主键包括其他实体的主键而使该实体成为了弱实体,还是因为一个实体是弱实体,所以它的主键必须包括其他实体的主键?
    这是一个先鸡(弱实体)还是先蛋(组合主键)的问题。

    为什么要定义弱实体?

    我们知道,弱实体对于另一个实体具有很强的依赖联系,似乎并不是“真实”存在的事物,那么为什么我们还会有弱实体的概念,而不是直接认为实体就是强实体呢?

    什么时候需要定义弱实体?

    有时候弱实体就是需求中的实体,只是它依赖于其他实体,有时候关系也可以认为是弱实体,有时候出于设计的需要我们也会定义弱实体,那么何时需要定义弱实体?

    总结起来,以上四个问题其实是一个问题:

    怎样正确地理解强实体与弱实体的含义?

    三、 唯有实践,方出真知

    有很多事情是很难想明白的,但经过几次数据库设计实战,我发现自己或多或少地定义了一些弱实体。我选取了三个典型的例子:

    教务系统数据库设计(一)

    之后我会专门写一篇博客介绍教务系统数据库的设计过程,这里选取其中一个比较典型的部分。业务需求是这样的:

    一周有七天,每一天有11节。

    上面这句话中涉及到了几个实体?很简单吧,三个实体:周、天、节。那么它们是强实体还是弱实体呢?不好说,但是我们可以确定,概念数据模型的设计应该是这个样子:
    在这里插入图片描述
    需要勾选“Dependent”。首先回答一个问题:为什么不能是下面这个样子?
    在这里插入图片描述
    Day的主键应该是dayOfWeek,如果不用“Dependent”将Day的主键改为weekNum+dayOfWeek,我们的Day表格中只能有七行记录,也就是说对于某一个星期一,我们无法区分这是第几周的星期一!同样的道理,如果Section的主键仅仅为sectionNum,那么我们根本无法区分这一节课是哪一天的课!教务系统要有排课、选课功能,只知道第1节,但不知道是哪一天的第一节,这肯定是不可以的。

    因此,当我们想要找到某一节时,需要同时指定那一周、星期几、哪一节。比方说我可以把《数据库设计》这门课安排在第一周星期一三四节。

    在这个例子中,三个实体都是需求中明明白白告诉我们的实体,但我们将Day与Section都作为了弱实体,因为强实体的Day与Section根本无法满足需求。

    培训公司数据库设计

    业务需求是这样的:

    每位学生每期只能参加一门课程。

    言外之意,公司有很多课程。我们只分析“每位学生每期只能参加一门课程”这一需求,发现涉及到两个实体:学生、课程。所以我们或许会想当然地这样去设计数据库:
    在这里插入图片描述
    一个课程可以由多个学生选择,一个学生只可以选择一门课程。发现问题了吗?业务需求里不是说一个学生只能参加一门课程,而是说一个学生在一期只能参加一门课程!这么设计数据库是在断人家财路。因此,我们必须考虑“每期课程”这个概念:在这里插入图片描述
    看样子似乎是没问题了,但是数据库设计是不可能这么容易就没问题的。我们把每期课程都作为一个记录,那么对于课程的信息,比方说课程名称、价格、介绍,每开一期课就要向数据库中存一行记录,因此我们的数据库会出现大量冗余(也就是说不满足数据库第二范式)。因此,我们应该这样去设计数据库:
    在这里插入图片描述
    看到了吗?这里的“Record”是一个弱实体,它的主键是“学期主键+学生主键”,代表学生参加课程这一行为,抽象成为了弱实体。为什么要用学期表的主键和学生表的主键呢?因为一个学生、一个学期,那么就只能参加一门课程了,所以根据主键唯一标识每行记录的原则,应该这样去选取。课程表的主键成为了Record表的外键,课程表与Record表之间存在一对多关系。

    在这个例子中,学生、课程是业务需求描述中显而易见的实体,“期”也可以认为是比较明显的实体,但“参加”这个动词在我们的数据库中便成为了“参加记录” ,也就是Record实体。

    教务系统数据库设计(二)

    这一部分的业务需求是这样的:

    老师授课。

    似乎业务需求很简单,但事实上,多位老师可以独立上同一门课,也可以共同上同一门课。一位老师可以参与多门课的授课。真实的教务系统的确是这个样子的。一般,像马原、高数等课程是多位老师独立授课,专业核心课大多是多位老师共同为同一班级授课。那么数据库要怎样设计呢?
    在这里插入图片描述
    像这样吗?老师、课程之间建立多对多关系?不难发现,这样的多对多联系无法区分上面所说的两种授课情况。也就是说,我们必须引入第三个表,才有可能实现业务需求,两张表格是行不通的。我是这样设计的:
    在这里插入图片描述
    在课程表与老师表之间,引入了新的一张表格——排课表。一个课程可以安排多次排课,一个排课就对应一个独立的授课安排,可以由一位老师完成,也可以由多位老师完成。那么像马原授课这种多位老师独立授课的情况该如何解决呢?在排课表中,认为不同老师的马原课是同一课程(引用Course表中同一记录的主键作为外键),但是它们是不同的排课(ArangeNo不同,可能一个是1,另一个是2)。也正因如此,排课表的主键是组合主键(课程编号+排课编号,如CS163、1)。

    这个例子中,需求中并没有提“排课”这一实体,这个实体完全是我们为了满足需求而定义的,甚至它和课程表在概念上还有点关系。注意到了吗,这里的“关系”就是弱实体概念中所说的“依赖”!

    四、 对强实体与弱实体的总结

    1. 区别弱实体与强实体的关键在于主键,“依赖”的实质是主键之间的关系。所以归根到底,就一个主键之间是否有关系、主键是否是组合主键的问题。

    2. 弱实体与强实体可以相互转换,没有绝对意义上的强与弱。既然区别弱实体与强实体的关键在于主键,那么一个同样意义的表,当我给它一个编号作为主键,那么它就不是弱实体,而如果我令它的主键是组合主键,它就是弱实体。就像刚刚,我们说排课表的主键是组合主键(课程编号+排课编号,如CS163、1),所以它是弱实体,那么如果我定义排课编号是“CS16301”,而不再是“1”,那么它的主键(排课编号)就不再需要课程编号,它就成为了强实体。

    3. 弱实体也可以依赖于弱实体。就像第一个例子中的Session,它依赖于Day,Day就是一个弱实体。

    4. 弱实体与它所依赖的实体之间的关系只能是1:1或n:1。也就是说,一个弱实体实例不可能依赖于同一实体的多个实例。这个其实很好理解,因为如果弱实体实例A依赖于实例B,那么A的主键要包括B的主键,所以A当然不可以依赖于很多个B。

    5. 业务需求决定弱实体的定义,分三种情况:

      情况一、 业务需求中明确的弱实体
      情况二、 业务需求中隐含的弱实体
      情况三、 业务需求中无、但为实现业务需求不得不定义的弱实体

      如果觉得这篇文章对你有帮助,请给博主点个赞!

    展开全文
  • 需求分析就是先分解、再提炼,这个过程消除矛盾。 1.需求分析做些什么 分解 a.业务流程为主线索的分解结构 按“事”的角度进行分解。对于联机事务处理系统、管理信息系统非常适用。 目标系统——>主题域的...

    C6需求分析与建模

    一、要点

    需求分析实际上是业务分析,也就是选择一种业务导向的线索将零散的需求串起来,形成一个体系完整、内容清晰的框架爱,以指导后续的设计、开发工作。
    需求分析就是先分解、再提炼,在这个过程中消除矛盾。
    1.需求分析做些什么

    • 分解

    a.业务流程为主线索的分解结构
    在这里插入图片描述按“事”的角度进行分解。对于联机事务处理系统、管理信息系统非常适用。
    目标系统——>主题域的分解依据的是“目标决定范围”
    主题域——>业务事件、报表类型所做的是理清脉络
    业务事件——>业务活动、报表类型——>报表所做的是填充细节

    b.程序结构为主线索的分解结构
    在这里插入图片描述适用于问题域不复杂,或者系统与问题域关联性不强的情况下,例如工具软件等
    c.基于场景的分解结构
    对于决策支持系统,决策场景、使用场景就是主要线索。向上可以总结成一类相似的集合,在总结成一系列的关注点或功能域。向下可以分解成具体的决策步骤或操作任务。
    在这里插入图片描述d.基于数据结构的分解结构
    以数据为主线的分解,诸如数据仓库之类的数据类项目
    在这里插入图片描述
    小结:在选择了何时的分解结构后,就可以吧需求规格说明书的大纲确定闲下来,知道应该捕获什么信息

    • 提炼
      抽取共性的部分,建立针对整个系统的全局领域模型

    • 消除矛盾

    2.建模的目的与要点
    目的:帮助我们按照实际情况或按我们需要的样式对系统进行可视化;提供一种详细说明系统的结构或行为的方法;给出一个知道系统构造的模板;对我们所周的决策进行文档化。
    模型是用来沟通的。
    3.建模工具的选择
    UML统一建模语言
    UML图的选择
    在这里插入图片描述

    二、周期一:理清框架和脉络

    输入:需求定义阶段产生的业务事件列表和报表类型
    输出:领域模型和用例模型
    结束的标志:标识除了绝大部分的用例,生成了领域模型
    任务:
    业务流程分析:每个业务事件的过程
    业务实体分析:了解业务术语间的关系
    用例分析:确定不同角色的任务
    1.业务流程分析
    业务流程分析主要信息来源是负责该业务流程的中层管理人员,因此访谈的对象就是这类人员。
    具体来说就是,针对每一个业务事件,,分析并识别现有业务活动,确定业务活动之间的关系;了解这些业务活动需要接收哪些信息,又将会产生哪些数据(表单),确定数据传送的路线;同时标识处业务活动是由那些部门、岗位负责等信息。
    1)流程是有层次的
    流程有组织机构、部门级、岗位级三个层次。其中部门级是需求分析的主线索,岗位级是需求细节填充时的工作内容,组织级是对部门级流程的抽象概括。
    2)流程是由类型的
    生产性流程
    管理性流程
    支持性流程
    3)流程分析的产物
    跨职责流程图——工具:Visio
    活动图——工具Rose、Together
    数据流图——工具:Visio

    书上的建模例子挺不错的,也很助于理解。尤其是数据流图
    我觉得在数据流部分的0层图和1层图的划分有点小问题,0层图我认为应该是只有中间一个系统的,当把系统功能细化后应该就是1层图了吧。阿不,它是对的。中间只有一个系统的是顶层图,往下依次为0层图,1层图…

    2.业务实体分析
    业务实体(或称业务数据、业务术语)。识别业务实体及其之间的关系的过程就是所谓的领域建模、概念建模
    针对每一个业务事件、每一类报表进行领域类图片的绘制时,主要步骤有三:

    识别出业务实体
    确定实体之间的关系(语义关系和数量关系)
    定义实体的关键属性
    

    业务实体分析产物有两种可选类型:
    类图
    E/R图
    书上有类图和E/R图的例子,由于我再复习软件设计师的时候认真学过了就快速浏览了一遍
    类图应用基础
    在需求建模时,可以大胆使用中文命名建模的类名和类的属性,易于理解
    E-R图应用基础
    描述业务实体之间的关系除开使用类图外,也可以使用传统的E-R模型。他的优势在于能够很好地与后续的数据库设计结合,缺点在于语义相对弱一点,同时对买向对象开发的指导作用相对差一些。
    1)数据建模过程
    在这里插入图片描述2)主要元素
    基本元素:实体、属性、关键属性(键值)、关系
    元素之间的关系:1:1,1:n.n:m

    3.角色与使用场景分析
    使用用例图分析,可以更好的完成以“人”的视角梳理需求
    1、用例图
    系统边界:方框内是系统,系统外的都是方框外,例如人、参与者都是系统外的
    参与者与用例的关系:用一根带箭头的线表示两者之间可以进行通信。
    用例之间的关系 :包含、扩展、泛化。
    4.周期一的产物
    1)工作任务说明
    在需求分析的第一阶段,核心任务就是结合业务流程、报表的需求,梳理出结构框架(领域模型)和行为 脉络(流程图——>用例模型),为第二阶段的需求分析工作指出方向。
    2)业务事件分析
    业务流程分析——可以使用泳道流程图
    业务实体分析——类图
    角色-使用场景分析
    3)报表分析
    1.why目标
    2.what内容
    相关业务实体分析
    报表项分析
    数据项及计算方法分析
    4)抽象与整理
    1)抽象用例模型
    2)抽象类模型
    5)填充需求规格说明书

    三、周期二:确定需求细节

    阶段任务:对用例模型、邻域模型标识处用例、领域类的细节进行填充。
    填充组织行为需求用例的事件流
    填充组织数据(结构)需求的领域类的字段和格式

    四、其他需求

    接口需求
    非功能需求的跟踪

    C7需求描述

    需求描述的风格与格式

    1.常见的描述风格与格式
    1)自然语言
    2)图形化语言
    3)形式化规格描述
    4)建议:
    自然语言为主,辅之以图形化模型——最常见,绝大多数IS系统、软件产品
    图形化模型为主,辅之以自然语言作为补充——RUP所推荐的方法
    以形式化规格语言为主,辅之以图形化模型,以自然语言为补充——适用于以质量要求很高的邻域,例如航天、军工项目。
    2.典型软件需求规格说明书解析
    3.自定义模板的技巧
    示例:
    SERU需求规格说明书模板

    1.文档概述
    	1.1 编写的目的
    	1.2 背景
    	1.3 定义
    	1.4 参考资料
    2.任务概述
    	2.1 业务需求
    	2.2 Stakenholder利益分析
    	2.3 用户特点分析
    	2.4 相关事实与假定
    3.需求概述
    	3.1 系统概述【主题域划分,用构件图表示】
    	3.2 主题域1
    		3.2.1 概述【用上下文关系表表示该主题域的范围】
    		3.2.2 业务事件
    			3.2.2.1业务事件1【包括流程分析、领域类分析、用例分析】
    			......
    			3.2.2.n 业务事件n
    		3.2.3 报表
    			3.3.4.1 Report1
    			【用领域类图片表示涉及数据,用用例图标识具体的报表项】
    			......
    			3.2.3.n Reportn
    	3.3 主题域n
    4.具体需求
    	4.1主题域1
    		4.1.1用例模型
    			4.1.1.1UC_B_xx(B类)
    				(1)概述【编号、名称、概述、相关Stakenholder】
    				(2)事件流描述【前、后置条件,基本、扩展、子事件流】
    				(3)相关需求与功能点
    				(4)界面原型【交互过程与界面详解】
    				 (5)规约与约束
    			4.1.1.2UC_R_xx(R类)
    				(1)概述【名称、用户部门与职位、业务意图、相关场景】
    				(2)报表内容【领域类图、数据项】
    				(3)输入、输出格式
    				(4)其他
    			4.1.1.3UC_I_xx(I类)
    				(1)使用者【名称、业务目的、时机、频率】
    				(2)内容与格式【交互过程、数据包说明】
    				(3)设计与实现约束【诸如协议格式要求、性能要求等】
    				.......
    		4.1.2.领域模型
    			4.1.2.1xx领域类
    				(1)概述【类名称、别名】
    				(2)数据窗口分析
    				(3)数据组成与格式
    				(4)其他
    	4.n主题域n
    5.补充规约
    	5.1 设计约束
    		5.1.1 技术选择的限制条件
    		5.1.2运行环境[建议用部署图表示]
    		5.1.3预期的使用环境
    	5.2质量属性【本部分建议直接分解成需要开发的技术功能点】
    		5.2.1安全性要求
    			5.2.1.1访问安全性要求
    			5.2.1.2数据安全性要求
    			5.2.1.3通信安全性要求
    			5.2.1.4.其他安全性要求
    		5.2.2可靠性要求
    			5.2.2.1容错性要求
    			5.2.2.2可恢复性要求
    			5.2.2.3其他可靠性要求
    		5.2.3易用性要求
    		5.2.4性能要求
    		5.2.5可维护性要求
    		5.2.6可移植性要求
    		5.2.7其他质量属性要求
    	5.3其他需求
    		
    

    C8需求验证

    结束。

    展开全文
  • 知识图谱实体定义

    千次阅读 2020-07-18 22:56:25
    前一篇博文《Neo4j构建目标知识图谱》提到知识图谱的构建中实体及关系的定义是个难点,本篇试图总结经验。 2.知识图谱是什么 知识图谱本质上是一种语义网络,用图的形式描述客观事物,这里的图指的是数据...
  • 项目一 数据库管理系统中需求分析.pdf项目一 数据库管理系统中需求分析.pdf项目一 数据库管理系统中需求分析.pdf项目一 数据库管理系统中需求分析.pdf项目一 数据库管理系统中需求分析.pdf项目一 数据库管理系统...
  • 数据库实体联系模型与关系模型

    千次阅读 2020-03-02 19:11:33
    数据库设计是指根据用户的需求某一具体的数据库管理系统上,设计数据库的结构和建立数据库的过程。例如,编程微课是在线编程教育项目,该项目涉及到课程、学生、老师、学习资料等数据,这些数据都要被存储下来,...
  • 可行性分析的基础上,进一步了解确定用户需求。准确地回答 “系统必须做什么?” 的问题。 BOEHM对软件需求的定义:  研究一种无二义性的表达工具,它能为用户和软件人员双方都接受并能够把“需求”严格地、...
  • 企业安全的用户与实体行为分析

    千次阅读 2021-11-16 09:30:53
    企业安全的用户与实体行为分析 期刊/会议:2016 IEEE International Conference on Big Data (Big Data) 级别:CCF C 1.背景 本文概述了我们网络安全领域构建的一个用于解决威胁搜索和事件调查用例的情报平台。...
  • 命名实体识别难哪?

    千次阅读 2020-06-18 21:03:12
    亚里士多德《形而上学》认为,对于存在,最重要的问题,就是给世间万物的存在基于语言来分层和分类。从神说要有光起,到基友给你取了个外号叫狗蛋。你会发现,创造与命名,历史往往等同。名字...
  • 实体-联系模型

    千次阅读 2020-12-20 22:08:32
    实体-联系(Entity-Relationship, E-R)模型(以下简称E-R模型)的提出旨在方便数据库的设计,它是通过允许定义代表数据全局...建模汇中,我们通常抽象地使用术语“实体集”,而不是指某个个别实体的特别集合。 实体
  • 命名实体识别主要方法

    千次阅读 2022-03-26 16:52:31
    命名实体识别主要方法 命名实体识别(Named Entity ...NER系统就是从非结构化的输入文本抽取出上述实体,并且可以按照业务需求识别出更多类别的实体,比如产品名称、型号、价格等。因此实体这个概念可以很广,只要
  • Android Room 数据实体类详解

    千次阅读 2021-06-04 21:31:31
    使用 Room 库的过程,定义数据实体类来表示需要存储的数据对象,每一个数据实体类与关联的数据库的表相对应,数据实体类的每一个字段对应表的列,每一个数据实体类对象都对应表的一行数据。 Room,...
  • 软件需求管理

    千次阅读 2021-04-02 19:17:54
    软件需求
  • 华为需求分析及设计模板(全套含ppt)

    千次下载 热门讨论 2018-02-12 09:22:42
    压缩包里有整套的华为开发资料,有很大参考价值,和IBM的也很...1、华为需求设计需求分析写作培训.ppt(培训如何去写优秀的需求文档、设计文档) 2、软件需求规格说明书模板、概要设计模板、详细设计模板、接口设计模板
  • 软件系统经常使用各种长期保存的信息,这些信息通常以一定方式组织并存储数据库或文件,为减少数据冗余,避免出现插入异常或删除异常,简化修改数据的过程,通常需要把数据结构规范化。 通常用“范式(normal ...
  • 阅读综述性论文是一种能够快速了解某一领域的方法,接下来通过今年的一篇...电子病历的文本内容是医务人员按照《病历书写基本规范》和《电子病历基本规范(试行)》相关书写规定,围绕患者医疗需求与服务活动而记录
  • 需求工程规格说明、需求验证、需求管理

    千次阅读 多人点赞 2020-04-24 18:52:14
    需求工程的面谈和原型(8、9章) 需求获取方法之观察与文档审查(10章) 第十一章 需求规格说明 需求获取:目标是得到用户需求——收集需求信息 需求分析:目标是更深刻的理解用户需求——界定能够让用户满意的...
  • 软件需求工程复习

    千次阅读 多人点赞 2020-04-22 09:52:17
    1.软件生产产生需求问题的最大原因在于对应用软件的(模拟性)理解不透彻或应用不坚决。 2.需求分析的目的是保证需求的(完整性和一致性)。 3.系统需求开发的结果最终会写入(系统需求规格说明)。 4.传统的需求...
  • 作为一个软件项目经理,项目开发进行,你是否遇到过这样的问题:客户的一个电话,就推翻了之前你与客户、与你自己的开发团队,经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新...
  • 前面的课程,我们了解了什么是事件?事件是可以描述的、值得记录的某一特定时间和地点发生的事情,当事件发生时,系统要做出响应。系统可能会响应外部发生的事件,也可能会响应系统内部发生的事件,也可能...
  • 知识图谱-实体识别

    千次阅读 2022-03-19 12:34:01
    知识图谱中实体识别相关内容
  • 知识抽取实现方案——实体抽取

    千次阅读 2021-12-02 16:47:32
    知识抽取涉及的“知识”通常是清楚的、事实性的信息,这些信息来自不同的来源和结构,而对不同数据源进行的知识抽取的方法各有不同,从结构化数据获取知识用D2R,其难点在于复杂表数据的处理,包括嵌套...实体抽取:
  • 实体关系图 (ERD) 指南

    千次阅读 2021-12-23 16:08:00
    本指南了解有关实体关系图 (ERD)、它们的用途、如何理解它们、如何创建它们等的所有信息。 实体关系图 (ERD) 是一种图表,可让您查看不同实体(例如人员、客户或其他对象)应用程序或数据库如何相互关联。 ...
  • 来自:python遇见NLP 阅读综述性论文是一种能够快速了解某一领域的方法,接下来通过今年的一篇综述性论文来了解一下近五年来中文电子病历的命名实体识别研究进展。基本的,我...
  • SE_01 需求分析

    千次阅读 2021-10-31 19:51:49
    1. 需求分析介绍 1.1 需求分析主要涵盖哪些问题 为什么要设计该系统?系统由谁使用?系统要做什么?系统涉及哪些信息?对解决方案有何额外限制?如何使用该系统?质量需达到何种程度? 1.2 需求分析分类 1.2.1 按...
  • 需求分析说明书和需求规格说明书

    千次阅读 2021-11-30 15:57:11
    一、需求分析说明书和需求规格说明书的区别 两者区别 需求分析说明书:一般是对某个市场或者是客户群来讲的,类似于调研报告,重点 是体现出产品要满足哪些功能,哪些是重点、热点。 需求规格说明书:是从业务规则...
  • 【命名实体识别(NER)】(1):命名实体识别综述

    万次阅读 多人点赞 2019-03-23 09:41:44
    命名实体识别综述 什么是命名实体识别? 命名实体识别(Named Entity Recognition,简称NER),又称作**“专名识别”,是自然语言处理的一项基础...确定实体的类型(人名、地名、机构名或其他) NER系统就是从...
  • 需求收集与分析(Requirements Collection and Analysis) 概念设计(Conceptual Design) —— 设计实体关系模型 (ER Model) 逻辑设计(Logical Design)—— 实现从 ER 模型到关系模式(Relation Schemas)的...
  • (2)E-R图,包含(D)等基本成分。 A.数据、对象、实体 C.实体、关系、控制 B.控制、关系、对象 D.实体、属性、关系 (3)软件规格说明书的内容不应该包括(B)。 A.对重要功能的描述 B.对算法的详细描述 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 122,519
精华内容 49,007
关键字:

如何在需求中确定实体

友情链接: hai-V7.8.zip