11 Requirements（需求）

香蕉你个吧啦

11 Requirements（需求）

已收录至专栏
​
已完成章节索引 00《软件工程-面向对象和传统方法》笔记索引
声明

本文为以下图书的学习笔记，图书中的内容更为丰富，并且各章课后参考文献列表丰富，案例丰富。如对内容感兴趣，请至出版社网站购买。
<hr/>软件工程：面向对象和传统的方法（原书第8版）
作者：韩松
ISBN：978-7-111-36273-9
所属丛书：计算机科学丛书
<hr/>需求工作流的目标是回答如下问题：
产品必须能做什么？

The Aim of the Requirements Workflow To answer the question:
What must the product be able to do?

11.1 Determining What the Client Needs（确定客户需要什么）

• 误解:我们必须确定客户想要什么
  
• “我知道你相信你理解了我说的话，但我不确定你是否意识到你听到的不是我的意思”（你以为你以为的就是你以为的？）。
  
• 我们必须确定客户需要什么?
  
• Misconception: We must determine what the client wants.
  
• “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”
  
• We must determine what the client needs
  

<hr/>

• 对系统分析师来说，很难将软件产品及其功能可视化。这个问题对（不是软件专家的）客户来说，就更为严重。
  
• 从客户那里获取适当的信息，需要一个经验丰富的系统分析员。
  
• 客户是这些信息的唯一来源。
  
• It is hard for a systems analyst to visualize a software product and its functionality. The problem is far worse for the client.
  
• A skilled systems analyst is needed to elicit the appropriate information from the client.
  
• The client is the only source of this information.
  

<hr/>

• 解决方案：
  
  
  
  • 从客户那里获取初始信息
    
  • 使用这些初始信息作为统一过程的输入
    
  • 遵循统一过程的步骤，确定客户的真实需求
    
  
  
• The solution:
  
  
  
  • Obtain initial information from the client
    
  • Use this initial information as input to the Unified Process
    
  • Follow the steps of the Unified Process to determine the client’s real needs
    
  
  

11.2 Overview of the Requirements Workflow（需求工作流概述）

• 首先，了解应用程序域(简称域)。域是目标产品运行的特定环境。
  
• 第二步，建立业务模型。为客户的业务流程建模。
  
• 第三步，使用业务模型来确定客户的需求。 迭代上述步骤
  
• First, gain an understanding of the application domain (or domain, for short). The specific environment in which the target product is to operate
  
• Second, build a business model. Model the client’s business processes.
  
• Third, use the business model to determine the client’s requirements. Iterate the above steps
  

<hr/>

• 定义：
  
  
  
  • 需求获取(或需求捕获)
    
    
    
    • 发现客户需求的过程
      
    • 方法包括访谈和调查
      
    
    
  • 需求分析
    
    
    
    • 细化和扩展初始需求
      
    
    
  
  
• Definitions:
  
  
  
  • Requirements elicitation (or requirements capture)
    
    
    
    • Discovering the client’s requirements
      
    • Methods include interviews and surveys
      
    
    
  • Requirements analysis
    
    
    
    • Refining and extending the initial requirements
      
    
    
  
  

11.3 Understanding the Domain（理解域）

• 开发团队的每个成员都必须完全熟悉应用领域
  
• 正确的术语是必不可少的
  
• 构造一个术语/词汇表
  
• 在该领域中使用的技术术语的列表，和它们的含义
  
• Every member of the development team must become fully familiar with the application domain
  
• Correct terminology is essential
  
• Construct a glossary
  
• A list of technical words used in the domain, and their meanings
  

11.4 The Business Model（业务模型）

• 业务模型是对一个组织业务流程的描述
  
• 业务模型从整体上理解客户的业务
  
• 这些知识对于向客户提供计算机化方面的建议是必不可少的（具体哪部分业务应该计算机化）
  
• 系统分析师需要对各种业务流程有详细的了解
  
• 使用不同的技巧，主要是访谈
  
• A business model is a description of the business processes of an organization
  
• The business model gives an understanding of the client’s business as a whole
  
• This knowledge is essential for advising the client regarding computerization
  
• The systems analyst needs to obtain a detailed understanding of the various business processes
  
• Different techniques are used, primarily interviewing
  

11.4.1 Interviewing（访谈）

需求团队与客户和用户会面，以提取所有相关信息。

The requirements team meet with the client and users to extract all relevant information

<hr/>

• 有两种类型的问题
  
  
  
  • 封闭式问题，需要一个具体的答案
    
  • 开放式问题，是为了鼓励被采访的人畅所欲言
    
  
  
• 有两种类型的访谈
  
  
  
  • 在程式化的访谈（按预定流程进行）中，会问一些预先计划好的具体问题，通常都是封闭式的问题
    
  • 在非程式化访谈（没有预定流程，相对随意）中，问题是根据所收到的答案而提出的，通常是开放式的问题
    
  
  
• There are two types of questions
  
  
  
  • Close-ended questions require a specific answer
    
  • Open-ended questions are posed to encourage the person being interviewed to speak out
    
  
  
• There are two types of interviews
  
  
  
  • In a structured interview, specific preplanned questions are asked, frequently close-ended
    
  • In an unstructured interview, questions are posed in response to the answers received, frequently open-ended
    
  
  

<hr/>

• 访谈并不容易
  
  
  
  • 过于非程式化的访谈不会提供太多相关信息
    
  • 访谈者必须完全熟悉应用领域
    
  • 访谈者必须始终保持开放的心态（要倾听客户，不要抱有成见）
    
  
  
• 访谈结束后，访谈者必须准备一份书面报告
  
  
  
  • 强烈建议给被访谈的人一份报告的副本（防止遗漏或者误解）
    
  
  
• Interviewing is not easy
  
  
  
  • An interview that is too unstructured will not yield much relevant information
    
  • The interviewer must be fully familiar with the application domain
    
  • The interviewer must remain open-minded at all times
    
  
  
• After the interview, the interviewer must prepare a written report
  
  
  
  • It is strongly advisable to give a copy of the report to the person who was interviewed
    
  
  

11.4.2 Other Techniques（其他技术）

• 访谈是主要的技术
  
• 当需要确定上百个人的意见时，调查问卷是一个有用的技术
  
• （通过）对业务表格的检查，（也可以）显示客户当前是如何开展业务的
  
• 在员工进行日常工作时直接观察也是有用的技术
  
  
  
  • 安装摄像机是这种技术的一种现代版本（用机器代替了人力的观察）
    
  • 但是，分析录像带会占用很长时间
    
  • 员工可能会认为摄像头是对隐私的无理侵犯
    
  
  
• Interviewing is the primary technique
  
• A questionnaire is useful when the opinions of hundreds of individuals need to be determined
  
• Examination of business forms shows how the client currently does business
  
• Direct observation of the employees while they perform their duties can be useful
  
  
  
  • Videotape cameras are a modern version of this technique
    
  • But, it can take a long time to analyze the tapes
    
  • Employees may view the cameras as an unwarranted invasion of privacy
    
  
  

11.4.3 Use Cases（用例）

用例对软件产品本身和该软件产品的用户（参与者）之间的交互进行建模

A use case models an interaction between the software product itself and the users of that software product (actors)

如图1101所示，这是一个银行的软件产品，参与者是“客户”和银行的“出纳”，发生的交互是“取款”。（“取款”这个用例是图中的椭圆部分）



1101 The Withdraw Money use case of the banking software product

• 参与者是软件产品（边界）之外的成员
  
• 通常很容易识别参与者
  
  
  
  • 参与者通常是软件产品的用户
    
  
  
• 通常参与者在软件产品中扮演与产品有关的某种角色。这个角色是
  
  
  
  • 作为用户； 或者
    
  • 作为用例发起人；或者
    
  • 作为在用例中扮演关键角色的人
    
  
  
• An actor is a member of the world outside the software product
  
• It is usually easy to identify an actor
  
  
  
  • An actor is frequently a user of the software product
    
  
  
• In general, an actor plays a role with regard to the software product. This role is
  
  
  
  • As a user; or
    
  • As an initiator; or
    
  • As someone who plays a critical part in the use case
    
  
  

<hr/>系统中的一个用户可以同时扮演多个角色 例如：银行的客户可以是从银行借款的人，也可以是通过银行将钱贷出的人（存款可视为将钱经由银行放出）

A user of the system can play more than one role Example: A customer of the bank can be A Borrower or A Lender

<hr/>

• 相反，一个参与者可以是多个用例的参与者
  
• 例子：一个“借款人”可能是一个参与者
  
  
  
  • “借钱”用例;
    
  • “贷款付息”用例;和
    
  • “偿还贷款本金”用例
    
  
  
• 此外，参与者“借款人”可能代表成千上万的银行客户
  
• Conversely, one actor can be a participant in multiple use cases
  
• Example: A Borrower may be an actor in
  
  
  
  • The "Borrow Money" use case;
    
  • The "Pay Interest on Loan" use case; and
    
  • The "Repay Loan Principal" use case
    
  
  
• Also, the actor Borrower may stand for many thousands of bank customers
  

<hr/>

• 参与者也不不一定非得是人
  
• 例如：
  
• 一个电子商务信息系统必须与信用卡公司的信息系统进行交互
  
• 从电子商务信息系统的角度来看，信用卡公司信息系统是一个参与者
  
• 从信用卡公司信息系统的角度来看，电子商务信息系统是一个参与者
  
• An actor need not be a human being
  
• Example:
  
  
  
  • An e-commerce information system has to interact with the credit card company information system
    
  • The credit card company information system is an actor from the viewpoint of the e-commerce information system
    
  • The e-commerce information system is an actor from the viewpoint of the credit card company information system
    
  
  

<hr/>

• 识别参与者时的潜在问题
  
  
  
  • 参与者角色重叠
    
  
  
• 例如：在一个医院软件产品中
  
  
  
  • 一个用例有参与者“护士”
    
  • 一个不同的用例有参与者“医务人员”
    
  • 更好的参与者:“医生”和“护士”（注：因为“护士”也是“医务人员”，但是“医务人员”又不全是“护士”，所以需要明确）
    
  • 另一种备选的方案是：将参与者“医务人员”细分/泛化成两个参与者：“医生”和“护士”（如图1102所示，“医生”和“护士”都继承自“医务人员”）
    
  
  
• A potential problem when identifying actors
  
  
  
  • Overlapping actors
    
  
  
• Example: Hospital software product
  
  
  
  • One use case has actor Nurse
    
  • A different use case has actor Medical Staff
    
  • Better:Actors: Physician and Nurse
    
  • Alternatively: Actor Medical Staff with two specializations: Physician and Nurse
    
  
  

1102 Generalization of medical staff

11.5 Initial Requirements（初始需求）

• 初始需求基于初始业务模型
  
• 然后它们被细化
  
• 需求是动态的——经常会有变化
  
  
  
  • 维护一个可能的需求列表，以及客户批准的需求用例
    
  
  
• The initial requirements are based on the initial business model
  
• Then they are refined
  
• The requirements are dynamic — there are frequent changes
  
  
  
  • Maintain a list of likely requirements, together with use cases of requirements approved by the client
    
  
  

<hr/>

• 有两类要求
  
  
  
  • 功能需求指定软件产品必须能够执行的操作
    
    
    
    • 通常用输入和输出来表示
      
    
    
  • 非功能性需求指定软件产品本身的属性，例如
    
    
    
    • 平台约束
      
    • 响应时间
      
    • 可靠性
      
    
    
  
  
• There are two categories of requirements
  
  
  
  • A functional requirement specifies an action that the software product must be able to perform
    
    
    
    • Often expressed in terms of inputs and outputs
      
    
    
  • A nonfunctional requirement specifies properties of the software product itself, such as
    
    
    
    • Platform constraints
      
    • Response times
      
    • Reliability
      
    
    
  
  

<hr/>

• 功能需求作为需求和分析工作流的一部分进行处理
  
• 一些非功能需求必须等到设计工作流完成
  
  
  
  • 在完成需求和分析工作流之前，一些非功能性需求的详细信息是不可得的
    
  
  
• Functional requirements are handled as part of the requirements and analysis workflows
  
• Some nonfunctional requirements have to wait until the design workflow
  
  
  
  • The detailed information for some nonfunctional requirements is not available until the requirements and analysis workflows have been completed
    
  
  

11.6 Initial Understanding of the Domain: The MSG Foundation Case Study

MSG基金案例分析的具体过程略
11.7 Initial Business Model: The MSG Foundation Case Study

MSG基金案例分析的具体过程略
11.8 Initial Requirements: The MSG Foundation Case Study

MSG基金案例分析的具体过程略
11.9 Continuing the Requirements Workflow: The MSG Foundation Case Study

MSG基金案例分析的具体过程略
11.10 Revising the Requirements: The MSG Foundation Case Study

MSG基金案例分析的具体过程略
11.11 The Test Workflow: The MSG Foundation Case Study

MSG基金案例分析的具体过程略 知乎 @ 王斐
11.12 The Classical Requirements Phase（传统需求阶段）

一方面，并没有像“面向对象的需求”这种事儿 （因为）需求工作流与如何构建产品没有任何关系

There is no such thing as “object-oriented requirements” The requirements workflow has nothing to do with how the product is to be built

然而，前面MSG案例里是面向模型，因此实质也是面向对象的

However, the approach presented in this chapter is Model oriented, and therefore Object oriented

建模并不是传统范型的一部分

• 传统的需求方法
  
  
  
  • 需求启发
    
  • 需求分析
    
  • 构建快速原型
    
  • 客户和将来的用户评估快速原型
    
  
  
• The classical approach to requirements
  
  
  
  • Requirements elicitation
    
  • Requirements analysis
    
  • Construction of a rapid prototype
    
  • Client and future users experiment with the rapid prototype
    
  
  

11.13 Rapid Prototyping（快速原型）

• 匆忙构建(“快速”)
  
  
  
  • 有缺陷也可以忽略
    
  
  
• 仅展示关键功能
  
• 只强调客户所看到的部分
  
  
  
  • 错误检查、文件更新可以忽略
    
  
  
• 目的:为客户提供对产品的理解
  
• Hastily built (“rapid”)
  
  
  
  • Imperfections can be ignored
    
  
  
• Exhibits only key functionality
  
• Emphasis on only what the client sees
  
  
  
  • Error checking, file updating can be ignored
    
  
  
• Aim: To provide the client with an understanding of the product
  

<hr/>

• 快速原型是为变化而构建的
  
• 用于快速原型设计的语言包括第4代语言和解释型语言
  
• A rapid prototype is built for change
  
• Languages for rapid prototyping include 4GLs and interpreted languages
  

11.14 Human Factors（人的因素）

（产品对用户来说必须友好，易于使用）

• 客户和预期用户必须与用户界面进行交互
  
• 人机界面(HCI)
  
  
  
  • 菜单，不是命令行（菜单式的交互方式比命令行方式更友好）
    
  • “点击”（单击、双击、拖拽）
    
  • 窗口、图标、下拉菜单（窗体式的界面、友好美观的图标，多级下拉菜单可供选择）
    
  
  
• The client and intended users must interact with the user interface
  
• Human-computer interface (HCI)
  
  
  
  • Menu, not command line
    
  • “Point and click”
    
  • Windows, icons, pull-down menus
    
  
  

<hr/>

• 必须考虑人的因素
  
  
  
  • 避免冗长的菜单序列（列表）
    
  • 允许不同级别的用户定制自己的交互界面（例如普通用户和专家级别的用户可以有各自不同的界面，专家级别的界面可以自主设置更多的参数，而普通用户选择默认的一套设置）
    
  • 外观的一致性很重要
    
  • 高级心理学 vs 常识?（构建一个对用户友好的人机界面应该成为常识）
    
  
  
• 每个产品的人机交互的快速原型是必须的
  
• Human factors must be taken into account
  
  
  
  • Avoid a lengthy sequence of menus
    
  • Allow the expertise level of an interface to be modified
    
  • Uniformity of appearance is important
    
  • Advanced psychology vs. common sense?
    
  
  
• Rapid prototype of the HCI of every product is obligatory
  

11.15 Reusing the Rapid Prototype（重用快速原型）

• 重用快速原型本质上等同于编码-修补模型
  
• 都是对已经建立的可工作的产品做修改
  
  
  
  • 这是代价非常昂贵的方式
    
  
  
• 由于没有规格说明和设计文档，维护起来非常困难
  
• 实时系统通常需要满足各种约束，这种重用快速原型的方式通常都很难满足实时系统的约束条件
  
• Reusing a rapid prototype is essentially code-and-fix
  
• Changes are made to a working product
  
  
  
  • Expensive
    
  
  
• Maintenance is hard without specification and design documents
  
• Real-time constraints are hard to meet
  

<hr/>

• 确保快速原型被丢弃的一个方法是
  
  
  
  • 用和实现目标产品的语言不同的语言实现快速原型（这样即使想重用快速原型也没办法）
    
  
  
• （用报表生成器或者屏幕生成器之类工具）生成的代码可以重用
  
• 我们可以安全地保留或者部分保留一个快速原型，假如这个快速原型是
  
  
  
  • 预先已经决定重用此快速原型（或快速原型的一部分）
    
  • 已经通过了SQA审查的部分
    
  • 但是，这就不是“传统的”快速原型了
    
  
  
• One way to ensure that the rapid prototype is discarded
  
  
  
  • Implement it in a different language from that of the target product
    
  
  
• Generated code can be reused
  
• We can safely retain (parts of) a rapid prototype if
  
  
  
  • This is prearranged
    
  • Those parts pass SQA inspections
    
  • However, this is not “classical” rapid prototyping
    
  
  

11.16 CASE Tools for the Requirements Workflow（需求工作流的CASE工具）

• 我们需要图形化的工具去绘制UML图
  
• 优点
  
  
  
  • 这样更容易修改UML图
    
  • 文档存储在工具里，因此总是可用的
    
  
  
• 缺点
  
  
  
  • 这类工具有时很难用（学习曲线陡峭，有一定学习难度）
    
  • 图可能需要相当大的“调整”（用工具绘制的图无法像手绘的图那样完整、准确、美观地表达想法）
    
  • 很多CASE工具很昂贵
    
  
  
• 总之，有点还是大约缺点
  

• We need graphical tools for UML diagrams
  
• strengths
  
  
  
  • To make it easy to change UML diagrams
    
  • The documentation is stored in the tool and therefore is always available
    
  
  
• weaknesses
  
  
  
  • Such tools are sometimes hard to use
    
  • The diagrams may need considerable “tweaking”
    
  • Many CASE tools are expensive
    
  
  
• Overall, the strengths outweigh the weaknesses
  

11.17 Metrics for the Requirements Workflow（需求工作流的度量）

• 需求变更率和趋同速度是一个很好的度量，可以度量确定客户需求的速度
  

Requirements volatility and speed of convergence are measures of how rapidly the client’s needs are determined

<hr/>

• （另一个度量是）在后续阶段所做的更改数量
  
  
  
  • （如果）由开发人员发起的更改
    
    
    
    • （那么）太多的变化可能意味着需求流程有缺陷
      
    
    
  • （如果）由客户发起的更改
    
    
    
    • （那么要小心）需求变更问题
      
    
    
  
  

• The number of changes made during subsequent phases
  
  
  
  • Changes initiated by the developers
    
    
    
    • Too many changes can mean the process is flawed
      
    
    
  • Changes initiated by the client
    
    
    
    • Moving target problem
      
    
    
  
  

11.18 Challenges of the Requirements Workflow（需求工作流的挑战）

• 客户组织的员工经常感到受到计算机化的威胁（害怕被取代）
  
• 需求团队成员必须由协商能力
  
  
  
  • 客户的需求可能需要缩小（降低客户的心理预期）
    
  
  
• 客户组织的关键员工可能没有时间进行必要的深入讨论（此种情况要重视，没有足够的信息，项目必定失败，不如不做）
  
• 灵活性和客观性是必不可少的（在做需求时不要做预设，要学会倾听）
  

• Employees of the client organization often feel threatened by computerization
  
• The requirements team members must be able to negotiate
  
  
  
  • The client’s needs may have to be scaled down
    
  
  
• Key employees of the client organization may not have the time for essential in-depth discussions
  
• Flexibility and objectivity are essential