软件需求阅读笔记

案例:

某大银行的一位银行卡办公室的收账经理Liz遇到了一个问题。她每周都收到一份过期未付款的账户名单。这份报告已经从两年前的250个账户增加到现在的1250个账户。 为了确定那些严重拖欠债务的账户,Liz需要通读这份报告。严重拖欠债务的账户由几个不同的规则确定,每个规则都要求Liz检查客户的一项或几项数据。过去半天的工作量现在增加到了每周三天。即使在确定了严重拖欠债务的账户后,如果没有查阅该账户三年内的历史资料,Liz也不能做出最后的信用决定(例如严厉的催款电话、断绝信用或将这个账户转给一个收账代理)。另外,Liz需要报告所有账户中过期未付款的、拖欠债务的、严重拖欠债务的和呆死账的比例。目前的报告中并没有给她提供这个信息。

如果你为Liz开发问题账户分析系统,你准备如何进行需求分析,第一步要做什么?

第一步先和Liz进行交流。

1》      进一步看看她到底有什么问题

2》      了解她需要什么类型的软件

3》       看看她对软件的大致雏形有什么需求

4》       再了解同类型的用户,了解他们的需求

描述一下拟开发系统的原型(包括哪些功能,数据库如何设计、操作的流程、界面的设计等等)

功能:

1》能够录入每个客户的信息,最近5年的历史数据

2》创建客户信息数据库

3》根据原始数据重新整理并更新

4》能够优先选出每个客户拖欠债务的数据

5》提供提供客户账户基本信息查询和三年历史数据查询

6》可以按照不同的查询条件找到客户的历史数据

7》设定欠账规则,创建问题用户计算过程

8》实时分析各类问题账户所占比例

9》设定不同的规则算法,能够跟进客户的历史数据判断客户的信用度

10》汇出客户的历史数据图线,清楚地看到客户的数据

11》数据的录入,能够语音录入,自动扫描纸质数据。

12》自动追踪客户的数据13》自动的根据客户信用度分类

数据库设计:

所需要的数据库表:

客户信息表,员工信息表,客户账单表,客户信用表,信用表,客户分类表,统计表。

操作的流程:

员工将客户信息录入,将客户的数据录入,跟踪客户的流水数据,查询客户的数据,系统自动审核客户信用度。系统自动统计客户拖款比例,绘制图线。

界面的设计:

登录界面,主界面,操作界面。

原文地址:https://www.cnblogs.com/837634902why/p/8504217.html

时间: 2024-08-29 02:18:27

软件需求阅读笔记的相关文章

软件需求阅读笔记01

建筑往往是根据设计图来完成的,软件也不例外,一个项目的质量和设计规划图有着密不可分的关系.这之间的联系,简单来说,便是用户和工程师的沟通,用户说出自己的需求来让工程师去实现.而需求包括三个不同的层次--业务需求.用户需求和功能需求,需求使问题变得明确,它是一一指明实现说明的规格说明,描述了系统的行为.特性或属性,是在开发过程中的约束. 需求的质量高低对于程序员来说很重要,实行有效的需求工程管理的组织能火得多方面的好处,其中最大的好处是在开发后期和整个维护阶段的重做的工作大大减少了.正确的需求过程

软件需求阅读笔记3

IEEE对需求定义为:①用户为了解决问题或达到某些目标所需要的条件或能力.②系统或系统部件为了满足合同.标准.规范或其他正式文档所规定的要求而需要具备的条件或能力.③对①或②中的一个条件或一种能力的一种文档化表述.通过这个定义了解了需求并不是用户想要的,想实现的,了解了需求本质的内涵. 功能需求是软件系统需求中最常见.最主要和最重要的需求,同时也是最为复杂的需求.功能需求通常体现为三个层次:业务需求.用户需求.系统需求. 业务需求描述了组织为什么要开发系统,满足用户的业务需求.业务需求是用户需要

软件需求阅读笔记02

如果一个项目缺乏明确的规划和良好的信息交流途径,那将是十分糟糕的.如果项目的参与者持有不同的目标和优先权,那么他们只能各抒己见,无心工作.如果项目的风险承担者在产品所能满足的业务需要和产品所能提供的利益问题上不能达成一致的意见,那么需求决不会稳定.一个清晰的项目视图和范围过于分散在多个地方开发,在这样的项目中,地理位置上的分离使项目开发组成员必须天天进行相互沟通才能保证他们之间能进行更有效的合作. 项目视图可以把项目参与者定位到一个共同和明确的方向上.项目视图描述了产品所涉及的各个方面和在一个完

软件需求分析——阅读笔记5

读<需求工程--软件建模与分析> 第四部分 需求的文档化和验证 有感 需求获取活动收集了需求信息,需求分析活动深入地理解了需求信息并建立了能够满足用户需要的软件解决方案.而需求规格说明活动就是将需求及其软件解决方案进行定义和文档化,并传递给开发人员的需求工程活动. 需求规格说明文档是需求规格说明活动的一个核心元素.(1)需求规格说明文档可以成为各方人员之间有关软件系统的协议基准.(2)需求规格说明文档可以成为项目开发活动的一个重要依据.(3)在需求规格说明文档的编写过程中,可以尽早的发现和减少

软件需求分析——阅读笔记6

读<需求工程--软甲建模与分析> 第五部分 需求管理与工程管理有感 在需求开发活动之后,需求基线应该成为后序软件系统开发的工作基础和粘合剂.需求管理在需求开发之后的产品生命周期中保证需求作用的有效发挥.作为需求开发的结果,最终的需求应该被明确和固定,需求基线就是被明确和固定的需求集合,是项目团队需要在,某一特定产品版本中实现的特征和需求集合.需求基线是需求开发过程中的成果总结,他需要在后续的产品生命周期中持续发挥作用.因此,需求基线要以一种持续.恒定和易于项目涉众访问的方式存在,通常的做法是将

软件需求分析阅读笔记

今天读了关于如何做需求分析的博文,学习了软件需求与分析需要掌握的一些内容,下面就做一些总结. 首先要认识到深入地去理解客户的业务,进而想到客户的心坎儿上去,最后做出来的东西必然是客户满意的.第一个举出来东软的例子,东软在做这个项目的时候,整个过程经历了10多次结构性的大变更,局部性的调整更是不计其数.百处程序进行修改.最后这个项目导致的结果是,整个这个项目组的所有成员都离开了东软,常常会听到抱怨客户总是对需求改来改去,那是因为我们对客户的需求没有真正理解清楚时,我们做出来的东西客户必然不满意.不

软件方法阅读笔记(一)

<软件方法>讲的是用UML语言来辅助我们进行软件的从0到1的过程.这个过程的结果并不是最终运行在电脑屏幕上的那个界面,而是一堆图纸,可视化的图纸.是的,确实是图纸.建筑行业有设计和施工图纸,电工行业有设计和实施图纸,城市规划有图纸··· ···任何你看得到的工程都有图纸,你要写的软件居然没有.“图纸在我脑子里呢”,我也曾经说过.直到看到这本书.这本书的直接受众应该有两类人:1.程序员这类人一般的工作思路就是提功能的人说要做什么,嗯嗯哦哦之后,迫不及待的打开编辑器开始写代码,调试,然后发现做完的

林锐——软件思想阅读笔记2

本章作者给我们讲述了可行性分析和需求分析的重要性和其中的一些问题.可行性分析就是要知道这件事情能不能做成功,而需求分析讲的是我们该做什么不该做什么.一般影响可行性分析的因素有经济,技术,社会环境和人 . 经济方面我们首先要考虑成本和收益问题,在考虑这个问题时我们要把成本算仔细,不管是前期还是后期维护我们都要考虑清楚,要不会给你带来很大的麻烦,然后就是短期利益和长期利益的关系了,我们都想短期利益和长期利益兼得,但是鱼和熊掌大部分时间是不能兼得的,所以作为一个有远见的人我们要能为了长期利益而放弃短期

03实例化需求阅读笔记之三

这本书给出了做到实例化需求的关键过程模式: 从目标中获取范围--协作定制需求说明--举例说明--提炼需求说明--不需要修改需求说明的自动化验证--频繁验证--演化出一个文档系统. 从目标中获取范围:交付团队不应该指望用户直接给出范围或者解决方案,因为客户大部分时候并不具备提供良好需求的专业能力,且团队拥有的项目知识可能也被浪费了.因此需要帮助用户找出真正的目标,并通过协作共同界定项目范围. 分工是这样:用户提供需要的 功能以及开发软件的目的,团队根据用户给出的信息提出解决方案. 协作制定需求说明