[软件工程]L3 AGILE DEVELOPMENT L4 REQUIREMENTS ENGINEERING

2021年5月7日 0 条评论 21 次阅读 0 人点赞

术语

User Story用户故事

用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

  1. 角色:谁要使用这个功能。
  2. 活动:需要完成什么样的功能或目标。

  3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

    用户故事通常按照如下的格式来表达:
    As a (Who wants to accomplish something)

    I want to (What)

    so that (Why)

Stakeholder 利益关系人

  • 一个可能影响、被一个项目的决定、活动或结果所影响或认为自己受其影响的个人、团体或组织。

  • 涉众是任何与系统的成功有利害关系的人:客户、最终用户、开发人员、项目经理、维护人员,甚至是那些推销系统的人。

Domain Requirements 领域需求

  • Domain requirements are derived from the application domain of the system rather than from the specific needs of system users.

L3

基本概念

Xtreme Programming (XP)极限编程

“XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork

Principles原则

  1. Humanity
  2. Economics
  3. Mutual Benefit 互惠互利
  4. Self-Similarity 自相似性
  5. Improvement
  6. Diversity
  7. Reflection
  8. Flow
  9. Opportunity
  10. Redundancy
  11. Failure
  12. Quality
  13. . Baby Step
  14. Accepted Responsibility

XP Workflow XP的工作流

  1. 在项目开发的初期,产品经理和用户编写故事(程序员也可能参与)
  2. 程序员估计故事和任务。如果故事太大,产品经理或用户将故事分割;如果程序员不理解主题,标记“Spike”。
  3. 产品经理和/或用户决定“主题”(大局)的季度周期。
  4. 产品经理、用户和或程序员为每个周期选择合理数量的用户故事循环并添加一些Slacks会议沟通

XP – Planning the Release 计划发布流程

Scrum敏捷开发

是用于开发、交付和维持错综复杂产品 (complex products) 的敏捷框架 (framework) [1] 。最初着重于软件开发,之后已被用应用于其他领域,包括研究、销售、营销和其他先进技术领域。 一个 Scrum 团队建议为十名成员的团队而设计的,他们以迭代[2] (iterative) 与增量[3] (incremental) 式的方式交付工作,每个迭代称作 Sprint。一个 Sprint 的时间不超过一个月,通常是两星期。Scrum 团队在每个 Sprint 都专注在唯一一个共同的目标 (Sprint Goal),每天的 Daily Scrum 团队中的开发人员 (Developers) 都检视朝向这共同目标的进度,和调适当下的计划。在 Sprint 结束时,团队会进行 Sprint 审查 (Sprint Review) 跟利害关系人 (Stakeholders) 一起检视当下的结果与调适计划,这是互相资讯交流的机会。最后,团队会进行 Sprint 回顾 (Sprint Retrospective) 来持续改善。

Product Backlog 产品代办项

Product backlog)是整个专案的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要生产什么样的产品。产品订单是开放的,每个人都可以编辑。产品订单包括粗略的估算,通常以天为单位。估算将帮助产品负责人衡量时程表和优先级(例如,如果"增加拼写检查"特性的估计需要花3天或3个月,将影响产品负责人对该特性的渴望)。

L4

The Requirements Engineering Processes 需求工程

需求工程是一个迭代过程

activities are interleaved • requirements documents are produced for project stakeholders

• Three key activities: 1. Elicitation and analysis: interact with stakeholders, discovering the user and system requirements. 2. Specification: convert requirements into standard form 3. Validation: assess feasibility of the project; building prototype if needed; review requirements

Requirements Elicitation and Analysis 需求抽取和分析

需求类型

User Requirements 用户需求

  • 通常用自然语言和图表编写
  • 系统应该提供的服务或系统约束的高级抽象声明

  • 通常为非技术人员编写

System Requirements 系统需求

  • 软件系统服务和操作约束的详细描述

  • 准确定义要实现的内容

  • 它可能是系统投资者和软件开发人员之间合同的一部分

  • 通常为技术人员编写

Functional Requirements 功能性需求

  • 使用自然语言编写功能性需求,系统应提供的服务的说明
  • 功能需求传统上关注于系统应该做什么
  • 根据要开发的系统的性质,焦点可能会转移到系统的其他方面

  • 系统应该如何对特定的输入作出反应,系统在特定情况下应该如何表现

示例1:用户故事索引卡管理系统应提供导出功能,允许用户将所有索引卡保存为PDF文件

示例2:数据科学家和分析人员应能够通过类似sql的查询执行特别的数据分析,以找到特定的数据模式和关联,以改善基础设施容量规划

Non-functional Requirements 非功能性需求

  • 对服务的约束,例如时间约束、资源约束、标准强加的约束
  • 指定系统作为一个整体的特征
  • 非功能性需求比单个功能性需求更为关键
  • 非功能性需求往往很难实现,因为实现非功能性需求可能会影响系统的整体架构。may affect the overall architecture of the system

示例1:当系统处于峰值负载时,不丢弃从移动客户端收到的紧急消息,缓存的消息尽快处理,并组播到预先选择的接收方,不再延迟。

示例2:系统将从大约300个web服务器收集多达15,000偶数/秒的数据。

Utility Tree 效用树

  • 实用工具树的根是一个占位符节点,标记为“utility”。
  • 树的第二层包含广泛的质量属性类别。

  • 树的第三层细化了这些类别。

  • 叶子为需求被捕获为场景。

  • 每个场景都由系统买家和架构师进行评级,等级为Low(L),中(M)或高(H)。

Requirements Specification 需求说明

  • 要求以标准形式或模板的自然语言编写 written in natural language in standard form or template
  • 图形符号Graphical notations
    • Unified Modeling Language (UML) diagrams
  • 数学规范 Mathematical specification
    • 使用基于数学概念的符号,例如使用有限状态机Finite State Machine

UML Use Case Diagram 用例图(图形表示)

是用户与系统交互的最简表示形式,展现了用户和与他相关的用例之间的关系。通过用例图,人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

Requirements Validation 需求验证

  • 有效性检查Validity checks
    • 需求是否反映了系统用户的真实需求
  • 一致性检查Consistency checks
    • 识别冲突和混乱的需求
  • 完整性检查Completeness checks
    • 文件化的需求是否定义了所有的功能和约束
  • 现实检查Realism checks
    • 软件系统能否在预算范围内实施或由现有技术支持
  • 可验证性Verifiability
    • 功能和质量属性是否可验证

Validation Methods 校验方法

  • Review 复审
  • Test-case 测试用例
  • Prototyping 原型:开发系统的可执行模型
Master

Master

这个人太懒什么东西都没留下

文章评论(0)