软件需求规格说明书的编写
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件需求规格说明书的编写
一、实验要求与任务
1、要求:完成软件需求规格说明书编写:
(1)基于获取的需求信息以及相关的参考文档,采用基于OMT的需求建模方法构建软件系统的需求模型;
(2)基于给定的软件需求规格说明模板编写软件需求规格说明书。
其中,软件系统的需求模型应包括类图表示的对象模型,序列图和状态转换
图表示的动态模型,以及分层的数据流图表示的功能模型。每一种图形化需求
模型应采用工具描述,类图、序列图和状态转换图采用Rational Rose或starUML软件描述,数据流图可采用visio软件描述。
2、具体任务:为“自动取款机(ATM)系统”开发编写需求规格说明书。
关于ATM系统的需求陈述如下:
1)某银行拟开发一个自动取款机系统,它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总
行拥有多台ATM,分别设在全市主要街道上。分行负责提供分行计算机和柜员终端,柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。
2)银行柜员使用柜员终端处理储户提交的储蓄事务。柜员负责把储户提交的
存款或取款事务输进柜员终端,接收储户交来的现金或支票,或付给储户现金。柜员终端与相应的分行计算机通信,分行计算机具体处理针对某个账户的事务并且维护账户。
3)储户可以用现金或支票开设新账户。储户也可以从自己的账户存款或取款。通常,一个储户可能拥有多个账户。拥有银行账户的储户有权申请领取银行卡。使用银行卡可以通过ATM访问自己的账户、提取现金,存储现金或查询有关自己账户的信息。
4)银行卡是一张特制的磁卡,上面有分行代码和卡号。分行代码唯一标识总
行下属的一个分行,卡号确定可以访问哪些账户。每张银行卡仅属于一个储户,但同一张卡可能由多个副本。因此,必须考虑同时在若干台ATM上使用同样的银行卡的可能性。也就是说,系统应该能够处理并发的访问。
5)当用户把银行卡插入ATM之后,ATM就与用户交互,获取有关这次事务的
信息,并与中央计算机交换有关事务的信息。首先,ATM要求用户输入密码,接
下来ATM把读到的信息以及用户输入的密码传给中央计算机,请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系,委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的,ATM就要求用户选择用户选择事务类型(取款、存款、查询等)。当用户
选择取款时,ATM请求用户输入取款项。最后,ATM从现金出口吐出现金,打印
出账单交给用户。
参考上述应用场景,通过调查完善用户需求,按照需求的内容进行分析,
按照模板要求撰写完整的软件需求规格说明书。
3、需提交的材料:
(1)基于模板定义的需求规格说明书的电子版及纸质版,正文前须有封面(见附录1)和目录;
(2)基于软件绘制的各模型的电子版;
(3) 各组成员的贡献以百分比的形式呈现.
其中电子版发送至邮箱:*****************.cn,纸质版由班长收齐交至勤
学楼4121。
截止时间:1月13日16:00。过期视为“不及格”。
禁止从别处抄袭或相互抄袭,否则0分。
二、软件需求规格说明模板
1.引言
引言提出了对软件需求规格说明的概况,有助于读者理解该需求规格说明是如何编写的,应如何阅读和理解。
1.1 目的
目的是说明软件需求规格说明的主要目标,描述软件规格说明所定义的产品或某些产品部分。
1.2 文档约定
描述编写文档时所采用的标准或排版约定,包括正文风格、提示区或中药符号。例如,说明高层需求的优先级是否可以被所有细化的需求所继承,或者每个需求陈述是否都有自身的优先级。
1.3 预期的读者和阅读建议
列举软件需求规格说明所针对的不同读者,例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述文档中剩余部分的内容及其组织结构。提出最适合于每一类型读者阅读文档的建议。
1.4 产品的范围
提供对指定的软件及其目的的简短描述,包括利益和目标。把软件与企业目标或业务策略相联系。
1.5 参考文献
列举编写软件需求规格说明时所参考的资料或其他资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档,或相关产品的软件需求规格说明。在这里应该给出详细的信息,包括标题名称、作者、版本号、日期、出版单位或资料来源,以方便读者查阅这些文献。
2.综合描述
这一部分概述正在定义的产品和所运行的环境、使用产品的用户以及已知的限制、假设和依赖。
2.1 产品的前景
描述软件需求规格说明中所定义的产品的背景和起源,说明该产品是否是产品系列中的下一成员、是否是成熟产品改进的下一代产品、是否是现有应用程序的替代品,或者是否是一个新型的、扩充型产品。如果软件需求规格说明定义了大系统的一个组成部分,那么就要说明这部分软件是怎样与整个系统相关联的,并且要定义两者之间的接口。
2.2 产品的功能
概述产品所具有的主要功能,其详细内容将在4中描述,在此只需要概括地总结,例如用列表的方法给出。很好地组织产品的功能,可使每个读者都易于理解。
2.3 用户类和特征
确定可能使用产品的不同用户类并描述相关的特征。有一些需求可能只与特定的用户类相关。将该产品的重要用户与不太重要的用户类区分开。
2.4 运行环境
描述软件的运行环境,包括硬件平台、操作系统和版本,还有其他的软件组成或与其共存的应用程序。
2.5 设计和实现的限制
确定影响开发人员自由选择的问题,并说明这些问题为什么成为一种限制。可能的限制包括如下内容:
●必须使用或者避免的特定技术、工具、编程语言和数据库。
●所要求的开发规范或标准(例如,如果由客户的公司负责软件维护,就
必须定义开发者所使用的设计符号表示和编码标准)。
●企业策略、政府法规或工业标准。
●硬件限制,例如定时需求或存储器限制。
●数据转换格式标准。
2.6 假设和依赖
列举出软件需求规格说明中影响需求陈述的假设因素(与已知因素相对立)。这可能包括你打算用的商业组件、有关开发或运行环境的问题。你可能认
为产品将符合一个特殊的用户界面设计约定,但是另一个读者可能不这样认为。
如果这些假设不正确、不一致或被更改,就会使项目受到影响。
此外,确定项目对外部因素存在的依赖。例如,如果打算把其他项目开发
的组件集成到系统中,那么就要依赖那个项目按时提供正确的操作组件。如果这
些依赖已经记录到其他文挡(例如项目计划)中了,那么在此就可以参考其他文档。
3.外部接口需求
确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象
的外部接口。需要把对接口数据和控制组件的详细描述写入数据词典中。如果产
品的不同部分有不同的外部接口,那么应把这些外部接口的详细需求并入到这一
部分的实例中。
3.1 用户界面
陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下
是可能包括的一些特征:
●将要采用的图形用户界面(GUI)标准或产品系列的风格。
●屏幕布局或解决方案的限制。
●将出现在每个屏幕的标准按钮、功能或导航连接(例如一个帮助按钮)。
●快捷键。
●错误信息显示标准。
对于用户界面的细节,例如特定对话框的布局,应该写入一个独立的用户
界面规格说明中,而不能写入软件需求规格说明中。
3.2 硬件接口
描述系统中软件和硬件每一个接口的特征。这种描述可以包括支持的硬件
类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。