需求阶段是软件工程中的一个重要阶段,里面涉及到需求收集分析,需求管理,需求开发,系统工程,易用性和交互设计,界面,业务领域知识,非功能性需求等多方面的内容。在面向对象的需求分析中我们通常采用用例分析的方法进行,在RUP核心三要素中第一位的就是用例驱动。
在《Use Case Modeling》一书中的定义是,用例代表了系统为其用角(Actors)所做的有价值的事情。用例不是功能(functions),也不是特性(features),它们不能被分解。每个用例都有一个名字和一段简述。用例的详细描述本质上是一些叙述(stories),说明了用户如何使用系统来完成他们认为重要的事情,以及系统做了些什么来满足这些需要。
张洵对用例的定义是一种粒度刚刚好,反映了用户的真实目的(目标),并记录了为达到此目的(目标),用户与系统或多个干系者之间如何开展协作,从事了哪些动态交互行为的软件需求(表现形式)。
首先用例是描述功能性需求,而在描述过程中所涉及到的三要素就是人(Actor)和系统边界,交互和动态行为。在需求分析中我们另外强调了输入输出,而在用例中对输入输出的描述是融入在基本流和扩展流的描述中。在敏捷方法中我们一般采用用户故事卡(User Story Card),用户故事卡对交互过程的描述可能并不会很详细,但是更加强调了用户驱动,强调了用户场景,而这也是用例偏弱的地方。我们做任何需求都必须要清楚的知道是什么样的用户和业务场景下驱动出了该需求。
什么是软件需求,什么是功能需求?——论需求的三个层次和三个方面(2)
我们的软件产品或者项目,其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求(Business requirement)表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求(behavīoral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意:用户需求不总是被转变成功能需求。产品特性,所谓特性(feature),是指一组逻辑上相关的功能需求,它们为用户提供某项功能,使业务目标得以满足。对商业软件而言,特性则是一组能被客户识别,并帮助他决定是否购买的需求,也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例,每个用例又要求实现多项功能需求,以便用户能够执行某项任务。系统需求(system requirement)用于描述包含有多个子系统的产品(即系统)的顶级需求。系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。人也可以是系统的一部分,因此某些系统功能可能要由人来承担。业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。然而,业务规则常常会限制谁能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。有时,功能中特定的质量属性(通过功能实现)也源于业务规则。所以,对某些功能需求进行追溯时,会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明(SRS)中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档,其实,SRS还可以是包含需求信息的数据库或电子表格;或者是存储在商业需求管理工具中的信息;而对于小型项目,甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。 除此之外,对于需求层次,我们还有其它的分法: 组织级需求->业务需求->用户需求->功能需求(有时也叫行为需求)。 组织级需求:一般代表着组织的愿景和目标。对于大的公司,一般是通过资深的咨询顾问和咨询公司得出的,呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型的组织级的需求是:降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。 业务需求:是要完组织的使命,达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。 用户需求:用户级的需求,是在业务级的需求下,各个岗位协作完成业务而具有的需求。我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。 功能需求:同样,它代表着产品或者软件需求具备的能力。 一般是管理人员或者产品的市场部门人员负责定义软件的业务需求,以提高公司的运营效率(对信息系统而言)或产品的市场竞争力(对商业软件而言)。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案,在约束条件的限制范围内实现必需的功能,并达到规定的质量和性能指标。当一项新的特性、用例或功能需求被提出时,需求分析员必须思考一个问题:“它在范围内吗?”。如果答案是肯定的,则该需求属于需求规格说明,反之则不属于。但答案也许是“不在,但应该在”,这时必须由业务需求的负责人或投资管理人来决定:是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。 二、需求的三个方面 除了功能需求外,SRS中还包含非功能需求,包括性能指标和对质量属性的描述。质量属性(quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。还有一项称为可用性(usability)的质量属性,它规定了业务需求中“有效”(efficiently)一词的含义。约束(constraint)限制了开发人员设计和构建系统时的选择范围。约束,在产品的架构设计中,是需要被首先考虑的问题。 如果说产品的功能代表了产品的能力,那么产品的质量属性代表了产品的品质,产品的约束代表了产品必须去满足的或者适应的条件!用人说“用户体验”是产品的灵魂,对于个人级的软件这么说或许很恰当,当对于企业级甚至是行业级的产品,其灵魂有两个:一个是产品带个用户的价值,另一个是产品的品质,简单的说,就是价值和品质。但其成为一个产品的前提应该是满足约束,否则就不应该设计、开发、进入市场而成为一个垃圾。
软件工程的软件需求
软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。
除此之外,每个系统还有各种非功能需求。
业务需求(Business requirement)表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围( vision and scope )文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求( project charter 或 market requirement )文档。
用户需求(user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求( behavioral requirement ),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
系统需求(system requirement)用于描述包含多个子系统的产品(即系统)的顶级需求。系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。人也可以是系统的一部分,因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。然而,业务规则常常会限制谁能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。有时,功能中特定的质量属性(通过功能实现)也源于业务规则。所以,对某些功能需求进行追溯时,会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求说明书( SRS )中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档,其实, SRS 还可以是包含需求信息的数据库或电子表格;或者是存储在商业需求管理工具中的信息;而对于小型项目,甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外, SRS 中还包含非功能需求,包括性能指标和对质量属性的描述。
质量属性(quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。
约束(constraint)限制了开发人员设计和构建系统时的选择范围。
行业需求:企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质,而对学历、年龄、性别、工作经验等的要求较低,相对于IT行业其他职位而言,软件测试的入行更加容易。
软件需求规格说明书最重要的是
是 正确性,有些是 无歧义性
为什么需要编写软件测试用例?
1、编写测试用例,可以避免测试点的遗漏
2、测试用例也是为了更好的进行测试,可以提高测试效率
3、测试用例是根据需求来的,开发也是根据需求做的,测试用例完成后,要进行用例评审,还可以减少开发和测试对需求的不同理解造成的缺陷
4、有时候需求是一点点来的,不是很系统,测试用例及时更新,可以作为系统的需求
软件需求规格说明书的作用是什么
作用在
1.于便于用户、开发人员进行理解和交流
2.反映出用户问题的结构
3.可以作为软件开发工作的基础和依据,并作为确认测试和验收的依据
转载请注明出处51数据库 » 软件需求用例 软件需求工程什么是用例和场景