精华内容
下载资源
问答
  • 里面详细讲述了怎么写需求分析 并且配有实际的例子说明 是不可多的的好东西
  • 常见软件非功能性需求描述案例

    千次阅读 2019-11-08 10:37:33
    非功能性需求是需求的一个重要组成部分,它影响了系统的架构设计,需要开发人员重点关注。...1、性能需求描述案例: 响应时间: 在95%的情况下,一般时段响应时间不超过1.5秒,高峰时段不超过4...

    非功能性需求是需求的一个重要组成部分,它影响了系统的架构设计,需要开发人员重点关注。但是在工程实践中,往往客户不会提出非功能性需求,需求人员在描述需求时不知道如何描述,在国际的各种标准中,对非功能性需求有定义,但是比较抽象。因此我整理如下常见的非功能性需求的描述案例,供需求人员进行参考。


    1、性能需求描述案例:

    响应时间:

    在95%的情况下,一般时段响应时间不超过1.5秒,高峰时段不超过4秒。

    定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。

    在网络畅通时,拨号连接GPRS网络所需时间不得超过5秒。

    在网络畅通时,电子地图刷新时间不超过10秒。

    在推荐配置环境下:登录响应时间在2秒内,刷新栏目响应时间在2秒内,刷新条目分页列表响应时间2秒内,打开信息条目响应时间1秒内,刷新部门、人员列表响应时间2秒内。

    在非高峰时间根据编号和名称特定条件进行搜索,可以在3秒内得到搜索结果。

    业务量:

    每日最大成交数3000笔业务。

    平均交易并发数为20,最大交易并发数为50。

    估计用户数为1万人,每天登录用户数为3000左右,网络的带宽为100M带宽。

    系统可以同时满足10,000个用户请求,并为25,000个并发用户提供浏览功能。


    系统容量:

    支持3万用户,支持GB级数据。

    数据库表行数不超过100万行,数据库最大容量不超过1000GB,磁盘空间至少需要40G以上。

    精度:

    定位精度误差不超过80米。

    当通过互联网接入系统的时候,期望在编号和名称搜索时最长查询时间<15秒。

    计算的精确性到小数点后7位。

    资源使用率:

    CPU占用率<=50%。

    内存占用率<=50%。

    2、安全需求描述案例:

    严格权限访问控制,用户在经过身份认证后,只能访问其权限范围内的数据,只能进行其权限范围内的操作。

    不同的用户具有不同的身份和权限,需要在用户身份真实可信的前提下,提供可信的授权管理服务,保护数据不被非法/越权访问和篡改,要确保数据的机密性和完整性。

    提供运行日志管理及安全审计功能,可追踪系统的历史使用情况。

    能经受来自互联网的一般性恶意攻击。如病毒(包括木马)攻击、口令猜测攻击、黑客入侵等。

    至少99%的攻击需要在10秒内检测到。

    3、可靠性需求描述案例:

    对输入有提示,数据有检查,防止数据异常。

    系统健壮性强,应该能处理系统运行过程中出现的各种异常情况,如:人为操作错误、输入非法数据、硬件设备失败等,系统应该能正确的处理,恰当的回避。

    因软件系统的失效而造成不能完成业务的概率要小于5‰。

    要求系统7x24小时运行,全年持续运行故障停运时间累计不能超过10小时。

    系统缺陷率每1,000小时最多发生1次故障。

    在1,000,000次交易中,最多出现1次需要重新启动系统的情况。

    4、兼容性需求描述案例:

    系统应支持IOS,Android , windows操作系统;

    系统应支持Oracle, DB2 数据库系统;

    最多只有5%的系统实现需要具体到特定的操作系统。

    替换关系数据库系统的平均时间不超过2小时,并且保证没有数据丢失。

    5、数据保密需求描述案例:

    网络传递数据应经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。业务数据需要在存储时进行加密,确保不可破解。

    6、环境需求描述案例:

     

    硬件

    操作系统及其版本

    应用服务器软件及其版本

    应用软件及其部件

    服务器

    IBM RS6000

    AIX 4.3.3

    IBM HTTP Server、Apache、MS IIS5.0等;

    DB2(7.2 EE以上版本)

    WAS(4.0以上版本)、Web Logic(7.0以上版本)等;

    Oracle EE(9i EE以上版本)

    浏览客户端

    PII 800/64M/2G

    Win98及以上

    IE 5.0以上或Netscape同等版本以上

     

    特殊客户端

    PII 2G/64M/2G

    建议配置Win2000及以上

    IE 5.0以上或Netscape同等版本以上

    MicroStrategy7i客户端

    7、易用性需求描述案例:

    在引入该产品的3个月内,60%的用户应该可以在45秒内用它来完成转账的任务,失败率控制在万分之一以内。

    60%的用户在第一次看见该产品的5秒内,就会意识到这是**银行的网银。

    80%的用户在接受一个2小时的系统介绍培训后,可以在5分钟之内成功预订房间。

    8、可用性需求描述案例:

    有些农村地区网络质量差,带宽小。在网络环境差的条件下保证系统的可用性等。

    在95%的故障中,系统最多需要20秒重启。

    提供数据备份和恢复功能,使得在由于系统的错误或其他原因引起系统的数据丢失或系统的数据被破坏时,能够及时恢复和还原数据(由硬件及第三方软件提供此功能)。

    9 、可测试性需求描述案例:

    一个模块的最大圈复杂度不能超过15。

    交付的系统必须通过单元测试,并且是100%覆盖。

    开发活动必须使用回归测试,并允许在12小时内重新进行完整的测试。

    10、可维护性需求描述案例:

    从接到修改请求后,对于普通修改应在1~2天内完成;对于评估后为重大需求或设计修改应在1周内完成。

    90%的BUG修改时间不超过1个工作日,其他不超过2个工作日。

    代码的圈复杂度必须在10以内。

    任何对象的任何方法都不允许超过200行代码。

    安装新版本必须保持所有的数据库内容和所有个人设置不变。

    产品必须提供可跟踪任何数据库字段的工具。
    ————————————————

    展开全文
  • 教务管理系统的需求描述

    千次阅读 2016-12-05 12:21:04
    教务管理系统问题的需求描述 教务管理是一项需求周密计划、严谨安排的工作,要依据教学任务、学生反馈信息、学生考试成绩、考级报安排等来对教师、学生进行安排课程、考试安排、信息发布等功能。   ...

    教务管理系统问题的需求描述

    教务管理是一项需求周密计划、严谨安排的工作,要依据教学任务、学生反馈信息、学生考试成绩、考级报安排等来对教师、学生进行安排课程、考试安排、信息发布等功能。

     

     实践/工作内容简述:分析人员应该分别对教务管理人员、教师和学生进行访谈,以得到教务管理领域的术语表,建立教务管理的用例图,获得用户的初始需求。

    子任务划分:子任务1——教务管理人员问题的领域术语表建立;

                子任务2——教务管理人员问题的用例图建立;

                子任务3——教务管理人员问题的初始需求建立。

    展开全文
  • 敏捷需求描述:用户故事

    千次阅读 2019-02-12 11:11:38
    用户故事是敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。 什么是用户故事? 用户故事是从希望新功能的人(通常是系统的用户...

    用户故事是敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。

    什么是用户故事?

    用户故事是从希望新功能的人(通常是系统的用户或客户)的角度讲述的功能的简短描述。它们通常遵循一个简单的模板:

    作为<用户类型 (Type of User) >,我想<某个目标 (Some Objective) >以便<某些原因 (Benefit) >。

    As a < type of user >, I want < some goal > so that < some reason >.

    ç¨æ·æäºçåçæå°çµæ

    用户故事通常写在索引卡片或便利贴上,存放在鞋盒中,并安排在墙壁或桌子上,以便于规划和讨论。因此,他们强烈地将重点从撰写有关功能的内容转移到讨论它们。事实上,这些讨论比任何文字都要重要。

    你能展示一些用户故事的例子吗?

    敏捷用户故事的一个好处是它们可以以不同的细节级别编写。我们可以编写用户故事来涵盖大量功能。这些大型用户故事通常被称为史诗。以下是来自桌面备份产品的史诗敏捷用户故事示例:

    • 作为用户,我可以备份整个硬盘。
    • As a user, I can backup my entire hard drive.

    ç¨æ·æäºçåçæå°çµæ

    由于史诗对于敏捷团队来说通常太大而无法在一次迭代中完成,因此在处理之前会将其拆分为多个较小的用户故事。上面的史诗可以分成几十个(或可能是数百个),包括这两个:

    • 作为高级用户,我可以根据文件大小,创建日期和修改日期指定要备份的文件或文件夹。
    • As a power user, I can specify files or folders to backup based on file size, date created and date modified.
    • 作为用户,我可以指示不备份文件夹,以便我的备份驱动器没有填满我不需要保存的内容。
    • As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

    如何将细节添加到用户故事中?

    可以通过两种方式将详细信息添加到用户故事中:

    • 通过将用户故事分成多个较小的用户故事。
    • 通过添加“满意的条件”。

    当一个相对较大的故事被分成多个较小的敏捷用户故事时,很自然地会假设已经添加了细节。毕竟,已经写了更多。

    满意的条件只是一个高级别的验收测试,在敏捷用户故事完成后才会成立。请将以下内容视为另一个敏捷用户故事示例:

    作为营销副总裁,我想在审查过去广告活动的表现时选择一个假日季节,以便我可以识别有利可图的季节。

    通过添加以下满意条件,可以将详细信息添加到该用户故事示例中:

    • 确保它适用于主要的零售假期:圣诞节,复活节,总统日,母亲节,父亲节,劳动节,新年。
    • 支持跨越两个日历年的假期(无跨越三年)。
    • 假日季节可以从一个假期到下一个假期(例如感恩节到圣诞节)。
    • 假日季节可以设定为假期前的几天。

    谁写用户故事?

    product owner user storiesçåçæå°çµæ

    任何人都可以写用户故事。产品所有者 (Product Owner)有责任确保存在敏捷用户故事的产品积压 (Product Backlog),但这并不意味着产品所有者是编写它们的人。在一个好的敏捷项目的过程中,您应该期望每个团队成员编写用户故事示例。

    另外,请注意,撰写用户故事的人远不如参与讨论的人重要。

    什么时候写用户故事?

    用户故事是在整个敏捷项目中编写的。通常在敏捷项目开始时举办故事写作研讨会。团队中的每个人都参与创建产品待办事项的目标,该产品待办事项完整地描述了在项目过程中添加的功能或其中的三到六个月的发布周期。

    其中一些敏捷的用户故事无疑将成为史诗。Epics稍后会被分解成更小的故事,更容易融入到单个迭代中。此外,新故事可以随时由任何人编写并添加到产品待办事项中。

    用户故事是否取代了需求文档?

    敏捷项目,尤其是Scrum项目,使用产品待办事项,这是在产品或服务中开发的功能的优先列表。虽然产品积压项目可以是团队所需的任何内容,但用户故事已成为最佳和最流行的产品积压项目形式。

    虽然产品积压工作可以被视为传统项目需求文档的替代, 但在有关该故事的讨论发生之前, 重要的是要记住, 敏捷用户情景的书面部分 ("作为用户, 我希望......") 是不完整的。

    通常最好将书面部分视为指向实际要求的指针。用户故事可以指向描绘工作流程的图表,显示如何执行计算的电子表格,或产品所有者或团队所需的任何其他工件。

     


    Agile Software Development

    scrum 文章集合

    展开全文
  • 企业管理软件的需求描述方法

    千次阅读 2006-09-20 23:17:00
    企业管理软件的需求描述方法1 构成企业管理信息系统的5个基本要素对企业需求的描述可以从2个方面来进行描述,一个方面是对客户现行系统的描述,一个方面是对系统未来的设想。总的而言,无论是从那个方面来描述,...
    企业管理软件的需求描述方法
    1 构成企业管理信息系统的5个基本要素
    对企业需求的描述可以从 2 个方面来进行描述,一个方面是对客户现行系统的描述,一个方面是对系统未来的设想。总的而言,无论是从那个方面来描述,构成企业信息系统主要包括 5 个基本要素:企业的组织结构、流程、数据、商务规则与功能(性能)。其中从用户的角度主要关注流程,是以流程为核心的,通过流程将其他几个要素贯穿起来,需求分析人员也应该从这个角度来和用户沟通;从开发者的角度主要关注企业的数据、商务规则与功能,以便于系统的实现;从实施者的角度主要关注企业的组织结构与功能,以便于系统的发布与实施。
    1)企业的组织模型
      即企业的组织结构关系,包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法,它可用来搞清各部门之间的领导关系 , 每个部门内部的人员配备情况 职责分工等情况 , 它是划分系统范围 , 进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述,每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体,对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图,是需求获取步骤中的基础工作之一。
    用户环境中的企业岗位或角色,和组织机构一样,也是分析人员理解企业业务的基础,也是分析人员提取对象的基础。
    对用户角色的识别常常遗漏的是计算机系统的系统管理人员,角色识别不全,对以后的功能识别会造成盲区。
    2) 企业的流程模型
    即企业的业务流程,包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图,将企业中各种业务之间的关系描述出来,然后对每种业务进行详细的描述,使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准,大家采用相同的图例来描述,便于管理。
    业务流程图的优点  :
    ■  绘图的过程 , 实际上是作业流程条理化的过程
    表达形象直观 , 易于和用户交流 , 易于项目组内部交流调研的结果 , 需要得到用户的认同 , 这就需要和用户交流调研的结果 , 交流的文档要通俗、易懂 不能采用专业术语。
    可以作为培训实施人员与技术服务人员的文档
    业务流程图的缺点  :
    ■对高层管理人员的实际需求调查的不清楚 . 这一方面是由于用户没有接触过计算机 对采用计算机后的管理会是什么样子 ? 计算机能够完成当前手工操作的哪些内容 ? 能够作哪些现在手工无法完成的工作等等没有清楚的概念 , 因此用户无法将这些问题反应出来 另一方面说明分析人员没有经验 , 对原始材料挖掘不深 , 不能从用户     提供的材料中提炼处来用户的真正需求 , 不能找到当前管理中的问题。
    ■对各种业务之间的总体关系没有表达出来 . 采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来 但是各业务之间的联系却没有表示出来 , 单看一种业务的流程图很清楚 , 但是却不能综合在一起 , 没有整体的概念 , 作为需求分析的文档 , 在这方面表达的不够完整。
    ■在不利用工具的情况下 , 画法烦琐。图形可以将流程描述的很清楚,但是还要附加以一些文字说明,如关于业务发生的频率、意外事故的处理、高峰期的业务频率等,不能在流程图中描述出的内容,需要用文字进行详细描述。
    3)企业的数据模型
    即企业中的信息载体有哪些?以及对这些信息载体的详细刻画,包括企业的各种单据、帐本、报表的描述。在需求报告中,应该将单据的描述格式化,需要描述的内容包括:
    单据的用途,即单据用在什么地方?
    单据的格式:需要明确的画出来,并有实际的有数据的样例,能够具体直观地说明问题;
    单据中的数据项的具体描述:长度、类型、计算生成方法、约束条件等;
    单据的数据项是由哪些不同类型的角色来填写地,包括用计算机可以填那些数据项。
    单据中哪些数据是必填的,哪些是可以不用填的。
    单据流量:平均每天产生多少条记录,高峰期的数量;
    单据的分类:可以从多个角度上进行分类,如:按业务类型来分类(采购 / 销售 / 生产),按生成的方式来分类(手工录入型 / 自动生成型),按格式变化的频繁程度来分类(易变型 / 稳定型),按表现形式来分类(列表型 / 卡片型)等等。
    单据之间的关系:引用关系等等。
    同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。
    4) 企业的商务规则模型
    即企业中的商务规则有哪些 ? 这些规则用在哪些地方 商务规则可以从影响的范围划分为 2 类:一类是局部的规则,如不允许出现负库存,一类是整体的规则,如对所有的物料管理到批次。商务规则一般是隐藏在功能模型或者流程模型中,不需要单独描述,但是有些复杂的商务规则是需要单独抽取出来描述,如企业的各种单据记帐的商务逻辑,
    5)企业的功能模型
    功能需求是用户的最主要的需求,对用户功能需求的描述可以采用文字描述也可以采用语言加图形的描述方式,只要能够将用户的需求描述地完整、准确、易于理解即可。对功能需求比较复杂的系统(如超过 10 个功能项),可以先描述一个概要,对简单的系统可以直接进行详细描述。对于用户的功能需求要进行分类,分类的方法应便于用户理解,如按照用户的部门设置情况,进行描述每个部门的需求,这样也便于组织用户进行评审。以下是分类方法的举例:
    按部门分类:如采购科、销售科、计划科、生产车间、财务科、统计科、总经理等;
    按功能类型分类:如单据录入、单据审核、单据查询、记帐、帐本查询、统计报表、系统维护等。
    对功能需求的分类在不同的层次可以采用不同的方法。
    对每一项功能应有一个功能编号,以便于与功能规格说明书中的章节进行对应。对每一项功能的描述,应指明用户的输入 (input) 、处理方法( process )、系统的输出 (output) 及对此项功能的其他要求。功能需求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明,非特殊要求可以在需求分析规格说明书中详细论述。如用户权限可分级,要有操作日志等。
    功能需求与性能需求是密不可分的,笼统的性能需求没有任何意思,必须具体到某项功能需求上来,这是分析人员在分析系统时容易忽略的一项。
         
    对上述的 5 个基本元素可以将他们描述为一个五元组〈组织,流程,功能,数据,业务逻     辑〉,对于用户来讲,他们习惯于从组织维来看待系统,即某个部门有哪些岗位,每个岗位参与了哪些流程的哪些活动(功能),在某个功能上操作了哪些数据,对这些数据进行了哪些逻辑处理;对于开发人员习惯于从功能维来看待系统,即某个功能操作了哪些数据,对这些数据进行了哪些逻辑处理,这个功能属于哪个流程,可以由哪些岗位来使用;对于设计人员可能习惯于从数据维来看待系统:即系统中有哪些数据,在这些数据上可以做哪些处理,这些处理用 OO 的思想来看即是对数据对象的操作。
      对以上的 5 个基本元素进行描述实际上就是系统建模的过程,为确保模型的可操作性,除了上面的 5 个基本要素外,还需要重点描述的内容有:
    1   新系统对应用模式带来的变化包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。
    2   新系统的界面模型
    用开发工具将用户操作界面快速画出来,使用户心中有数。若时间允许,可将界面原型与数据库表、字段连接起来,真正做出系统雏形,即快速原型法。
    2 阅读需求文档的4类读者
    需求报告的最终目的是给人来阅读的,所以一定要考虑需求报告的读者群,有 4 类角色可能阅读企业管理系统的需求文档:
    客户与用户业务高层;
    用户的中层管理人员与具体人员;
    用户 IT 主管与开发人员,包括设计人员、编码人员、同行的专家;
    项目管理人员:包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等;
    不同的读者对文档的阅读需求是不同的,他们关注的信息是不同的。我见过了很多次需求评审的失败(如果做好需求评审我会另外再撰文描述),总结下来我认为和需求描述没有区分读者群是很有关系的。针对上述的 4 种分类,我们具体的来分析一下每类读者的特点:
    (1) 客户与用户业务高层
      他们关心的企业是系统的目标性需求,关心的是系统总体的功能框架,关心的是系统解决了哪些管理问题,对具体的需求是不关心的,所以给他们阅读的文档应该是从总体上来描述,要高度抽象。由于他们的工作很忙,很难有比较长的时间来读这些材料,所以要简短明了,能够用 1 页纸说明问题的就要不要用 2 页纸,而且一般都要给高层进行需求汇报,需要配上语言说明,因此采用 PowerPiont 片子也就成了一种常用的方法,讲解需求与讨论一般应掌握不要超过 1 小时。需求人员常犯的毛病是过多地关注了企业的细节性需求,而忽略系统的目标性需求,所以在安排需求获取的步骤上、需求报告的编写上往往没有抓住企业高层最关心的问题、没有抓住根本性的问题,在给企业的高层汇报时当然很难通过评审。
    (2)用户的中层管理人员与具体人员
    企业的中层管理人员关注的是企业的局部需求,他们要求对自己的负责的局部系统能够有总体的了解,能够和其他的子系统衔接的很好,业务流程很流畅,覆盖了自己需要的所有业务流程,能够通过系统起到控制作用就行了。具体的操作人员更关心自己的的哪些活动是否在系统中都能处理,软件是否可以很容易地操作,他们关注的焦点更具体,要求更直观。所以对这类的读者可以通过比较详细的文档来描述需求了,当然应该以他们习惯的思维方式来描述,不能从开发人员的角度来描述。我看到过很多几百页的需求文档给用户去阅读、去评审,结果要么用户不置可否,要么直接讲看不懂,为什么呢?一是开发人员在文档中分子系统、分模块、分功能点一层深入下去描述,不符合用户的思维习惯,他们希望能够从业务流程、业务活动的角度来考虑问题,而不是功能;二是太多了,用户也没有时间静下心来去消化、吸收如此多的文档,需求毕竟不是小说,能够那么吸引读者。
    (3)用户IT主管与开发人员
    包括设计人员、编码人员、同行的专家大多数分析人员可能最擅长的就是些写这类的文档了,往往也是那这类的文档给所有的读者看,其问题我们上边都说了,这里我们就不赘述了。需要注意的是在描述需求时候传统的做法是以功能为主线,来展开描述,实际上如果是以数据为主线来描述需求也是一种很好的办法,在我们上面谈到的五元组中,从数据的角度来分析系统可以更容易实现向 OOA OOD 的切换。
    (4) 项目管理人员:
    包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等把拿给开发人员看的需求文档给管理人员看,这也是分析人员常犯的毛病。管理人员实际上最关心的是需求列表。在此基础上项目经理、质量保证人员可以据此来进入项目策划过程,测试人员可据此进入测试策划过程,需求管理员、配置管理员可以识别配置项制定相关的活动计划。没有这张表管理人员就很难高效地开展他们的管理活动,也就谈不到最基本的需求复用了。在上述的表中,需求的优先级是很重要的一列,对项目经理进行项目管理的平衡决策是很重要的,实际上需求的优先级可能比需求本身更重要。
    3 需求描述的表示技巧
    上面我们谈到了,需求文档是人与人之间交互的文档,是不同类型的人之间交互的文档,因此需求文档的可读性是一个很重要的方面,为了提高文档的可读性可以借鉴下面的一些做法:
    在文档的描述中,适当运用链接,增强文档的可读性;
    多用穷举的方式,以便于发现遗漏的需求;
    通过适当的换行来提高可读性 
    采用黑体、斜体、下划线、颜色等多种方式来突出重要内容;
    定义标准的术语,以减少二义性,减少文档的页数;
    在功能需求的描述中,对于类似的、统一的功能可以单独地进行详细描述,其他地方进行引用,或做为术语进行定义,以简化文档,减少重复。如;
    录入功能
    打印功能
    条件查询功能
    排序功能等等
      
    User case用例描述模板
    Table 6.0
    Use Case #
    DATAENTRYPROJECTCUST-1009
    Use Case name
    Maintain Customer
    Description
    This Use Case depicts full maintenance of customer from project "Data Entry".
    Scope and level
    • Data Entry System (Internal)
    • Credit Card System (External)
    Level
    User Goal Level (If this property is not understood, look at the reference for the book Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and technology)
    Primary and secondary actors
    Data Entry operator.
    Stakeholders and interests
     
    Trigger
    Data entry operator clicks on menu: "Add New Customer"
    Preconditions
    • Data entry operator should be logged in.
    • Data entry operator should have access to Internet.
    Assumptions
    Customer information received is entered manually. No automated import routine is in the scope.
    Failed End condition
    • Customer is not added to database and appropriate error message is displayed.
    • Customer code already existing in the customer database.
    • Customer code length limit is exceeded.
    • Customer credit card limit is exceeded.
    • Customer credit card validation failed with the payment gateway.
    Action
    Add new customer
    Main success scenario (or basic Flow):
    1. Data entry operator receives customer information.
    2. Data entry operator enters following information:
      • Customer code
      • Customer name
      • Customer address
      • Customer phone
    3. Customer code is checked if it exists in Customer table.
      • If the customer code is existing then "Duplicate Customer Code" error is raised.
      • If the customer code is more than 8 length, then "Customer code length limit crossed" error is raised.
    4. After step 3 is passed OK. Data entry operator enters credit card information. If the credit card length is more than 10 length, then "Credit card length limit crossed" error is raised.
    5. Credit card information is send to the external payment gateway. Appropriate APIs of the external payment gateway will be used for validity.
    6. External payment gateway returns "OK" if credit card is validated or else will return "NOT VALID" flag.
    7. Data entry operator then adds the customer in database.
    Alternate scenario (Extensions):
    Update Existing Customer
    1. Data entry operator enters customer code to retrieve the customer who has to be updated.
    2. Data entry operator makes appropriate changes to the customer information. All steps and business validation from 1 to 6 of Add new Customer is repeated.
    3. Data Entry operator updates the customer information.
    Alternate scenario (Extensions):
    Delete Existing Customer
    1. Data entry operator enters customer code to retrieve the customer who has to be deleted.
    2. Data entry operator deletes the customer. Data entry operator is alerted "Are you sure you want to delete the Customer?”
      • If the data entry operator clicks "Yes", then the customer is deleted from the database.
      • If the data entry operator clicks "NO", no action is taken.
    Success Guarantee (Post conditions):
    • Customer is added to Customer database.
    • Customer is updated to Customer database.
    • Customer is deleted from Customer database.
    Special Requirements (including business rules):
     
    Technology and Data Variations List:
    If credit card payment gateway API changes, the interaction of the data entry customer module will have to be changed accordingly.
    Frequency of occurrence:
     
    Notes and Open Issues:
     
    展开全文
  • 优惠券需求描述与分析

    千次阅读 2015-12-01 16:29:31
    step1 :生成优惠券 建立一个表: table_name = 优惠券表 字段分析: 优惠券批次名称:name varchar 批次ID: coupon_id 有效期 : valid_date int 用户领取有效期: acquire_start_time date
  • 一、使用场景和业务需求描述

    千次阅读 2019-09-24 05:04:42
    作为小白,业务需求我也不知道, 我就提问:  请问下 ,你们的产品很全,根据我们的业务 会使用到你们那个软件产品 给我的回答:  主要要用到的就是资源服务,用于获取设备资源,还有视频应用,获取预览url。 ...
  • 背景:学院找你做一个“学生毕业论文选题”的软件,将你所获取(事实上是你个人的设想)和整理的需求,用你认为合适的方式描述出来。 一、功能描述管理员添加毕业论文题目,导入教师、学生的信息,生成对应用户名和...
  • 常见非功能性需求描述案例

    万次阅读 多人点赞 2018-01-31 14:05:34
    非功能性需求是需求的一个重要组成部分,它影响了系统的架构设计,需要开发人员重点关注。...1、性能需求描述案例:响应时间:在95%的情况下,一般时段响应时间不超过1.5秒,高峰时段不超过4秒。定位系统从
  • 收录系统测试需求详细描述收录系统测试需求详细描述收录系统测试需求详细描述收录系统测试需求详细描述收录系统测试需求详细描述收录系统测试需求详细描述收录系统测试需求详细描述收录系统测试需求详细描述收录系统...
  • 是一种被广泛使用的用于发现和记录需求 特别是功能需求 的机制 写出用例是一种最好的理解和描述需求的技巧 注意:这个模板列出可以定义用例的典型标题 但应当强调的是 实用上更重要的是专注于写出完整的可理解的...
  • 需求过程中的变更进行进行描述需求过程中的变更进行进行描述
  • 需求评审的过程要点描述,提供有价值的方法参考
  • 在撰写软件需求规格说明书时,要描述功能和非功能需求,其中非功能需求分为10个种类,分别是性能需求,安全性需求,易用性需求,可靠性需求,可扩充性需求,健壮性需求,可移植性需求,可重用性需求和交互性需求。...
  • UML用例需求,如何建立用例图,以及建立用例描述,用例描述建立的格式。UML用例需求,如何建立用例图,以及建立用例描述,用例描述建立的格式。UML用例需求,如何建立用例图,以及建立用例描述,用例描述建立的格式...
  • 需求分析阶段,结合项目实例,运用数据流图准确描述了系统的功能需求,应届毕业生,完成毕业设计的一个非常好的资源,希望下载。
  • 业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market r...
  • 软件需求工程-需求工程概述

    万次阅读 2019-10-21 10:09:43
    清晰的需求描述 合适的规划 现实的客户期望 较小的里程碑 有才能的员工 主权 清晰的愿景和目标 努力的工作和稳定的员工 … 软件项目失败因素: 不完整的需求 缺乏用户的参与 资源不足 不实际的客户期望 缺乏执行层...
  • 业务需求、用户需求和功能需求

    万次阅读 2017-03-06 10:44:42
    我们的软件产品或者项目,其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户... 务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和
  • 企业管理软件需求描述方法

    千次阅读 2006-09-20 12:37:00
    1 构成企业管理信息系统的5个基本要素对企业需求描述可以从2个方面来进行描述,一个方面是对客户现行系统的描述,一个方面是对系统未来的设想。总的而言,无论是从那个方面来描述,构成企业信息系统主要包括5个...
  • 需求分析与需求文档

    万次阅读 2018-04-17 08:58:42
    什么是需求分析呢?需求分析是指对要解决的问题进行详细的分析,弄清楚问题的要求。在网页开发当中的“需求分析”就是确定要计算机做什么,所以...业务需求描述了企业为什么要开发一个网站,也就是希望网站达到的...
  • 功能性需求和非功能性需求

    万次阅读 多人点赞 2018-12-05 14:22:18
    功能需求 (functional requirement规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,...功能需求描述是开发人员需要实现什 么。注意:用户需求不总是被转变成功能需求。产品特性,所谓特性(...
  • 软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。 除此之外,每个系统还有各种非功能需求。...业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围( vision an...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 729,210
精华内容 291,684
关键字:

需求描述