需求工程成果物之一的《需求规格说明书》就是后续环节建设的依据，因此，准确地定义项目的系统功能需求就成为需求工程的另一个主要目标。......
2023-11-17
确定业务目标-软件需求工程
【摘要】：业务目标又称为业务前景，是对要建设的系统的展望。业务目标非常重要，在定义边界一章中会看到，边界正是基于业务目标来定义的。投资构建系统的原因，以及这样做利益相关者会从业务中得到什么，这些都可帮助确定业务目标。业务目标不仅仅是要解决问题，还要提供业务上的效益。业务目标大部分情况下是由客户提出，当然也可以由开发方整理得出。在初步了解业务目标以后，接下来的工作就是找出项目范围内的利益相关者。
业务目标又称为业务前景，是对要建设的系统的展望。客户立项准备开发一个软件系统，一定会对这个系统有明确的展望，即建设系统的目的是什么、准备用来做什么。业务目标非常重要，在定义边界一章中会看到，边界正是基于业务目标来定义的。
投资构建系统的原因，以及这样做利益相关者会从业务中得到什么，这些都可帮助确定业务目标。对于业务目标，首先应该知道的是，关于业务的所有决定都由这个目标驱动，因此，可将业务目标作为最高层次的需求，且所有后续收集的详细需求必须为实现该目标做出积极贡献。
在项目启动阶段，这个目标应该用清晰、无歧义和可度量的方式记录下来，将项目的效益量化。这种量化让目标可测试。
怎样才能清晰地说明目标，这要从一份用户问题或项目背景的描述开始。项目启动小组必须熟悉掌握项目的业务问题，这样才能从中发现需求，并为问题的解决做出最大贡献。上一小节已经简单介绍了“薪酬管理项目”的背景信息，这些信息就是理解和分析业务问题的基础。
一旦清晰地理解了业务问题，就知道该如何解决问题，即找出业务目标。从“目标、效益、标准”三方面寻找合适的项目目标。
目标：问题是手工整理薪资表容易出错，且效率较低。这个问题的一个解决方案是不再采用手工整理文件的管理方式，将薪资信息共享化，缩短文档整理时间。因此，业务目标可以写成：“利用薪酬管理软件系统平台，下载/上传考勤记录、审批月度薪资表等。”
业务目标不仅仅是要解决问题，还要提供业务上的效益。如果存在这种效益，就必须能够被度量。
效益：缩短文档整理时间。
标准：这个效益是否可度量？答案是“是”。系统的成功可通过文档整理时间的减少来度量。
因此，度量标准可以这样写：“使用系统后，文档整理时间差要大于5天。”
该目标是否可行？让关键利益相关者参加需求调研的一个原因就是回答诸如此类的问题。有一个利益相关者是综合管理部的办事员。综合管理部办事员证明了文档整理时间是可以缩短的，期望的结果是切实可行的。
该目标是否能达到？代表系统设计者、构建者的技术专家的利益相关者让项目启动会议的参加者相信，技术是可获得或可建造的。
但是，如果不能清楚地知道系统打算做什么，不知道怎样度量系统的成功，就不可能构造出正确的系统。(www.chuimin.cn)
一般都会根据对业务概况的了解来整理业务目标。业务目标大部分情况下是由客户提出，在招标书里一般都有相关的描述。当然也可以由开发方整理得出。了解薪酬管理的业务流程和项目背景后，就能勾勒出这样一个薪酬管理软件系统：
员工可以查看自己的考勤记录以及薪资单；能够在考勤或薪资出现异常的时候进行申诉。上级领导可以查看下级的薪资情况。部门经理可以审核下属员工的考勤和薪资申诉。总经理和董事长可以查看各部门薪资汇总情况；可以对月度薪资表进行审核。财务部可以审核月度薪资表；能够在月度薪资表审核完成后发放薪资。综合管理部可以审核考勤和薪资申诉；可以修改考勤记录及薪资表；可以维护员工信息及薪资等级表等相关表单等。
业务目标大部分情况下是由客户提出，当然也可以由开发方整理得出。在薪酬管理案例中可得到一些业务目标：
（1）实现工资管理业务信息化。
（2）规范工资管理。
在很多项目里业务目标仅在项目启动的过程中使用，最多在分析业务范围时起一点参考作用，很少有人用业务范围来进行设计分析。在这本书所介绍方法里，业务目标是进行分析的第一步，从需求开始，所有的工作都由业务目标开始推导。（实现了信息系统对接，企业可以随时了解原配件到厂的时间）和较低的废品率。
案例&知识：
老余是某生产企业的信息主管，有一次他们的老总到国外考察归来之后给他下了一个任务：全面提升企业的信息化水平，达到国内领先水平。并且承诺是要人给人、要钱给钱。
面对这样的目标，老余是一筹莫展。在一次朋友的闲聊中笔者给他了一个建议：你应该先问问你们老总这次考察的见闻。
几天之后老余又找到了我，兴奋地告诉我说他找到目标了。原来他们老总在这次考察的企业中，有两件事给他留下了深刻的印象：该企业通过信息系统实现了原配件采购的透明化
有了这样的信息之后，老余就可以聚焦于这两个问题，对它进行分析就可以找到适合的范围了。
在初步了解业务目标以后，接下来的工作就是找出项目范围内的利益相关者。
有关软件需求工程的文章
- 详细阅读
-
了解业务概况-软件需求工程详细阅读
为了真正理解客户的需求并给出满足这些需求的解决方案，必须理解真实世界中的问题。这些工作包括业务背景调查、业务前景分析、业务可行性分析、技术可行性分析等。在统一过程中，以上内容汇集到被称为《前景》的文档中。业务前景和客户期望所描述的内容与UML分析技术关系密切，严格来说，这些正是UML分析的开始。这几部分基本囊括了薪酬管理系统的主要业务范围，读者可稍作了解。......
2023-11-17
-
软件需求工程：获取薪酬业务对象详细阅读
图3-4薪酬表表头图3-5薪酬业务对象在上述业务对象的获取中，首先将薪酬表转换为业务对象，当然RA人员在获取原始表的同时，需要初步了解表内元素的基本含义，在转换为业务对象时，在相应的备注信息栏中予以说明。......
2023-11-17
-
软件需求工程：获取业务用例！详细阅读
业务用例视图是表达客户业务执行的静态视图，是实现某关联业务目标的具体体现。业务用例可以从需求调研收集的岗位手册、业务流程指南、职务说明中获得，也可以从涉众期望中获取，当然与客户的会议、访谈及其他形式的沟通都是获取业务用例的方法。当然在2.2.2节提及获取业务用例的时候，要时刻记着业务用例的完整性，避免将步骤作为用例，业务用例是一项完整业务汇集的过程。......
2023-11-17
-
软件需求工程：业务角色分析与交流详细阅读
业务角色主要用于分析业务，而业务分析的结果是要与客户交流并达成共识，因此业务角色应当能够映射到现实业务中的工作岗位设置、工作职责说明等，并且最好使用客户习惯的业务术语命名。在方法论中业务角色具体用来获取业务用例，分析和完成业务情景建模过程。业务角色的分析和业务用例其实并无先后顺序，它们之间是相互补充、相互依存、相互协助、相互验证的关系，可以经过多次迭代逐步修改和完善。......
2023-11-17
-
业务角色演化实例-软件需求工程成果详细阅读
综合管理部和综合管理部主管为代理（泛化）关系。虽然业务角色不能够逾越或改变涉众期望，但是能够自行决定实现涉众期望的过程。反之，综合管理部主管参与薪资表的审批等系统操作，故综合管理部主管可以转化为系统用户。......
2023-11-17
-
业务用例获取实例：软件需求工程详细阅读
此视图描述了薪酬管理中各业务角色在根据业务目标“实现工资管理业务信息化”划分的边界内各自要做的事情，每件事即为一个业务用例。我们从以下两点对业务用例做进一步讨论：讨论一：划分业务用例的难点在于对用例粒度的把握。而其具体步骤为：图5-6薪酬管理业务用例视图总经理审核薪资表是否通过，不通过则打回到综合管理部主管处。......
2023-11-17
-
软件需求工程定义-软件需求工程详细阅读
要给一个名词下定义，是一件很严肃和严谨的事情，因此，要给出需求工程准确的定义是不太现实的。本书从方法论推进和实施的角度出发，提出了本书对需求工程的理解和定义。需求工程是面向业务全局、系统顶层的一种着眼于软件过程全过程的工程，是将客户业务作为内部研究对象、将软件工程实施作为外部研究对象的工程。之后，书中提到的需求工程即以此定义为准。......
2023-11-17
相关推荐