第一篇：软件需求书的写作要求
引言
1.1 编写目的【阐明编写需求说明书的目的，指明读者对象。（本文档的编写目的，阐述用户需求，完成用户功能模型的分析，为设计奠定开发基础。）】
1.2 项目背景
【应包括
● 项目的委托单位、开心单位和主管部门；
● 该软件系统与其他系统的关系。】
1.3 定义
【列出文档中所用到的专门术语的定义和缩写词的原文。】
1.4 参考资料
【可包括
● 项目经核准的计划任务书、合同或上级机关的批文
● 文档所引用的资料、规范等
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源】 2 任务概述
2.1 目标
【阐述系统目标（做系统分析前的目标），用户希望达到的目标，描述系统需求条目。做一个简单的功能结构图，将用户需求条目归类到功能分类中】
2.2 运行环境
2.3 条件与限制
【系统运行前置条件，主要是系统运行对其它系统的依赖】数据描述
3.1 表态数据
【表态数据主要是描述实体对象和关系对象，表结构数据存储的描述】
3.2 动态数据
【系统模块之间的数据交流，包括输入数据和输出数据。】
3.3 数据库描述
【给出使用数据库的名称和类型。】
3.4 数据词典
实体数据的词条
业务流程的词条
【进行数据词典分析，对词条进行详细描述】
3.5 数据采集
【需要采集的数据包括为系统运行之前需要准备的数据，系统初始化数据】 4 功能需求
使用用例分析来分析功能
4.1用例分析
对功能进行描述，分析功能，形成用例图
【进行系统功能结构分析】
4.2用例描述
1、用例1
n目标
n事件流（业务处理流程）
n特殊需求
n前置条件
n后置条件
【根据需求条目，使用用例图分析用户需求，进行用例描述】性能需求
5.1 数据精确度
【对实时、高敏度系统必须】
5.2 时间特性
【如响应时间、更新处理时间、数据转换与传输时间、运行时间等。】
5.3 适应性
【在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。】运行需求
6.1 用户界面
【提出主要功能的界面设计方案，功能的界面流程，界面元素的定义。如屏幕格式、报表格式、菜单格式、输入输出时间等。】
1、用例1对应的功能
1)界面步骤1
输入元素
输出元素
显示元素
2)界面步骤2
6.2 硬件接口
6.3 软件接口
【软硬件接口指系统与外部系统之间的接口，接口定义的是函数名和参数列表的定义】
6.4 故障处理其他需求
【如可使用性、安全保密、可维护性、可移植性等。】
第二篇：软件需求说明[范文]
软件需求说明
某公司总部设在北京，在上海、广州、成都和西安有分支机构，公司员工接近700名。由于公司业务和员工团队的迅速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理方式。
报账系统将支持员工记录（或预见）日常业务活动的开销，并自动结算每个月应该返还员工的补偿金额，补偿额会直接存入员工的工资帐户中。
报账系统应具有基于先进技术的图形化界面，员工可以输入业务活动的种类和简短描述，活动开销的类别，选择不同的支付方式，并可以生成灵活的报表。
报账系统应该有能力根据员工提供的信息和要求返还补偿额，同时保存全部员工的报账信息。员工可以通过他们自己的电脑来使用报账系统。由于牵涉到财务信息，报账系统必须提供可信的安全机制。
公司现有一套基于MicroSoft SQL Server的人事管理数据库系统，记录员工共的基本信息和团队的组织结构。报账系统将和现有人事管理数据库系统协同工作，需要引用人事管理数据库系统中的部分信息，但不会更新其内容。
通过报账系统，员工能够在出差前（提前2天）按照规定的额度向公司申请借款，相关的经理人员能够通过报账系统批复或拒绝。报账系统应在相关负责人批复之后通知该员工提取现金或确认相应款项已经划入指定信用卡（根据员工的要求）；员工可以通过保账系统报销合理的业务活动经费。
财务部门将指定一位报账系统管理员监督拟建系统中的信息，负责初始设置和维护特定的分类额度准则，并能够定期或随机地向部门负责人提交报账系统情况的统计报告。
报账系统在每月的25日对通过审批的报账申请自动作一次结算，并以电子邮件的方式通知应该得到补偿的员工，同时生成一份统计报告传送给财务部门的系统监管人员。
具体的局部功能需求-----“提交报销申请”的Use Case
简介：
员工通过报账系统填写报销申请，输入相关活动产生的费用，在一次或者多次填写后提交，经验证之后，以电子邮件的方式通知相应经理批复。
事件流（Flow of Events）
基本事件序列(Basic Flow)1.打开报销单
[员工]：员工选择进入“报销申请”功能。
[系统]：该员工当月报销单存在，系统将取出相应信息并展示给员工；如果该员工的当月报销单不存在，则转至A1备选事件序列。2.添加报销记录
[员工]：员工要求添加一条报销记录。[系统]：系统显示一条空白的报销记录。3.填写报销记录单
[员工]：员工开始填写报销记录，每条报销记录包括的信息有：业务活动发生的时间、为了让员工方便而准确地输入相关信息，除了客户名称、业务活动原因和金额之外，其他信息域提供相应的下拉式选择列表。并记录员工输入的信息。
（重复以上针对每一条报销记录的活动），直至所有记录填写完毕。）4.验证报销单
[员工]：员工填写完毕所有报销记录之后，要求系统验证这些记录的合理性。[系统]：报销记录的初始状态为“未验证”，每当一条报销记录被验证为合理，系统将该报销记录的状态设置为“已验证”，系统在验证所有报销记录（为“已验证”）之后提示用户可以提交本月的报销单。验证为合理的记录必须满足集中条件：第一，不同种类的费用不超过相应得限额；第二，报销费用的类型要和员工的职能匹配。对于未通过的验证的报销记录，转至A5备选事件序列 5.提交报销单
[员工]：所有报销记录经过验证之后，员工提交当月的报销单。
[系统]：系统保存这张报销单，将报销单的状态设置为“已提交”并记录提交日期，同时这张报销单被设为“只读”。系统要从人事管理数据库中获知该员工及其经理（负担该员工当月开销者）的电子邮件地址。如果此时人事管理数据库不可用，转至A6备选事件序列。
为了及时通知相关人员，系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱中。当邮件成功发送后，员工得到一个确认信息。如果此时邮件系统未能将邮件及时发送，转至备选事件序列A7。
备选事件序列组（Alternative Flows）
A1 创建当月报销单
[起始位置]：基本事件序列中，员工进入报销申请程序并准备打开当月报销单。
[触发条件]：系统没有发现和该员工对应的当月报销单。
[具体内容]：系统为员工创建一张当月报销单。
[返回位置]：基本事件序列中的“打开报销单” 步骤。
A2 删除报销记录
[起始位置]：在提交报销单之前任意时间点。
[触发条件]：员工希望删除某一条报销记录。
[具体内容]：系统删除有员工指定的某一条报销记录。[返回位置]：同“起始位置”。
A3 更新报销记录
[起始位置]：在提交报销单之前任意时间点。
[触发条件]：员工希望更新某一条报销单。
[具体内容]：系统根据员工输入的内容更新相应的一条报销记录。[返回位置]：同“起始位置”。
A4 保存当月报销单
[起始位置]：该Use Case 允许员工在事件流中的任意时间点保存当月的报销单。
[触发条件]：员工希望将已经录入的报销记录保存在报账系统中。
[具体内容]：系统保存该员工当月报销单，并给出确认信息。员工可以在保存当月报销单之后直接退出系统。
[返回位置]：同“起始位置”。
A5 报销记录不合理
[起始位置]：基本事件序列中，“验证报销单”步骤中对每一条报销记录验证结束之后。
[触发条件]：包销记录不满足某一条适用的准则。有两种情形：第一，某报销记录的金额超出了其对应类型费用的上限，已知有三种：请客户用餐人均超过300元，出差时每天住宿费超过800元，移动电话费再无特殊说明情况下超过800元；第二，报销费用的类型和员工所处部门及职能不匹配，已知的情形是业务部门的员工申请加班补助。
[具体内容]：系统告知员工不合理的报销记录编号，以及未通过验证的原因。[返回位置]：即本事件序列中的“填写报销单”步骤，目的是更正有问题的报销记录。
A6 人事管理数据库不可用
[起始位置]：即本事件序列中，提交报销单步骤结尾
[触发条件]：当报账系统向人事管理数据库索取信息而该数据库没有正常的响应。
[具体内容]：以对话框形式告知员工“人事管理数据库不可用，报账但没有提交成功”。
[返回位置]：Use Case 执行结束。
A7 邮件未即时发出
[起始位置]：基本事件序列中，“提交报销单”步骤的结尾，成功地从人事管理数据库获得相关信息后。
[触发条件]：报账系统要求发送相关邮件时，邮件系统没有及时的响应。
[具体内容]：系统将以提示信息的方式告知员工“邮件没有及时发出，但是报销单在系统内已经提交成功，待邮件系统恢复后，相关邮件会自动发出”。[返回位置]：Use Case 执行结束。
特殊需求列表（专属于该Use Case）
暂无
启动条件
员工成功登录系统，通过身份验证。被系统提示进入“报销申请”或“借款申请”功能。
结束状态(组)如果该Use Case 顺利执行，员工得报销申请记录将被建立，更新、保存或者保存并提交；否则，系统地状态应该保持和该Use Case 执行之前相同。
辅助图示(活动图)
“补充规约”要点 1.RDBMS数据库访问 2.分布式处理
词汇表 要点
员工。公司的正式雇员
经理。负责审批某员工当月开销的管理者，是较高级别的员工。
报销纪录。与业务有关的某一项具体的花费，包括业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。 报销单。员工在一个（自然）月内的所有报销纪录的集合。
工资户头。公司将员工用于日常业务活动开销的补偿金额返还至员工的银行账户，该帐户的基本功能是供员工接受工资。
人事管理数据库。该数据库纪录了有关人事管理的相关信息，与报帐系统有关的是公司的组织机构(“员工”和“经理”的关系)。
内部邮件系统。该邮件系统负责收发与公司业务有关的电子邮件信息。
“提交报销申请”[控制，SubmitClaim]的Use Case
简介：
员工通过报账系统填写报销申请，输入相关活动产生的费用，在一次或者多次填写后提交，经验证之后，以电子邮件的方式通知相应经理批复。
事件流（Flow of Events）
基本事件序列(Basic Flow)打开报销单
[员工]：员工[实体，关键抽象，Employee]选择进入“报销申请”[边界，SubmitClaimForm]功能。
[系统]：如果该员工当月报销单[实体，关键抽象，ClaimReport]存在，系统将取出相应信息并展示给员工；如果该员工的当月报销单不存在，则转至A1备选事件序列。添加报销记录
[员工]：员工要求添加一条报销记录。[系统]：系统显示一条空白的报销记录。填写报销记录单
[员工]：员工开始填写报销记录[实体，关键抽象，ClaimRecord]，每条报销记录包括的信息有：业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。
[系统]：系统显示并记录员工输入的信息。为了让员工方便而准确地输入相关信息，除了客户名称、业务活动原因和金额之外，其他信息域提供相应的下拉式选择列表。
（重复以上针对每一条报销记录的活动），直至所有记录填写完毕。）验证报销单
[员工]：员工填写完毕所有报销记录之后，要求系统验证这些记录的合理性[实体，ValidRule]。
[系统]：包销记录的初始状态为“未验证”，每当一条报销记录被验证为合理，系统监该报销记录的状态设置为“已验证”，系统在验证所有报销记录（为“已验证”）之后提示用户可以提交本月的报销单。验证为合理的记录必须满足集中条件：第一，不同种类的费用不超过相应得限额；第二，报销费用的类型要和员工的职能匹配。对于未通过的验证的报销记录，转至A5备选事件序列 提交报销单
[员工]：所有报销记录经过验证之后，员工提交当月的报销单。
[系统]：系统保存这张报销单，将报销单的状态设置为“以提交”并记录提交日期，同时这张报销单被设为“只读”。系统要从人事管理数据库[边界，HRDatabase]中获知该员工及其经理（负担该员工当月开销者）的电子邮件地址。如果此时人事管理数据库不可用，转至A6备选事件序列。
为了及时通知相关人员，系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱中。当邮件成功发送后，员工得到一个确认信息。如果此时邮件系统[边界，MailSystem]未能将邮件及时发送，转至备选事件序列A7。
第三篇：软件需求-案例分析
1、问题描述
许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。
2、情景描述的主要成分
2.1、该系统所涉及的用户
本系统的用户包含患者、医生以及管理员三类。而且该三类用户各自的特征和所要面对的情景也是截然不同的。
对于患者来说，他们在年龄、计算机使用能力等方面存在较大差异，但面对的情景都一样，就是要预约挂号，挂号成功过后就诊。
对于医生来说，普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。所面对的情景有查看挂号信息，确定要就诊的病人。
对于管理员来说，他们负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。
不同的用户，对系统的要求也不相同。患者希望通过完成注册和登录后能够进行挂号预约，查询医生的出诊信息和个人预约信息，并且能够在规定的时间内完成挂号预约或者取消已有的预约；医生则希望能够在登录系统后可以查看病人的预约情况；而管理员希望可以修改出诊信息和调整预约挂号。这些都是功能性的需求。
同时对于所有用户都希望该系统是易用的，而且能够对自己的信息起到保护即系统安全性的要求，还有比如说系统的性能比较高效，能够及时处理自己的预约申请。当然开发系统的成本如果也能较低就更好了。这些都是非功能需求。
2.2、情景描述的主要成分
目标和关键成功因素
预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。关键成功因素，要保证系统能够24小时正常稳定的运行，系统里的信息要是实时变化的，即可以预约的医生要和实际在值班的医生要匹配，不能出现挂上号了却没有医生就诊的情况。
物理上下文和逻辑上下文 物理上下文：医院用于挂号的计算机可以正常的使用，情景中的可以被预约的医生应该是在医院值班的；而对于患者可以选择在医院进行预约，也可选择在家中进行预约，只要在预约时间内能到达医院就可。逻辑上下文：事件发生的条件是患者在系统中进行了预约，然后管理员会根据现有的资源（可以预约的医生）对预约进行处理，如果同意，下一步就是医生就诊；如果没有可以预约的医生或合适的时间，患者的预约就不成功，患者需要重新选择医生或时间进行预约。
组成情景的主要事件和活动 主要事件：患者预约挂号，管理员对预约挂号的处理，医生就诊。主要活动：患者注册、登录系统，患者在系统中查询可以预约的医生和时间，患者取消已有预约，患者进行就诊；管理员接受或拒绝预约，管理员分配医生；医生查询预约信息。
涉及的执行者和其他参与者
执行者：医院的医生，预约挂号系统的管理员。其他参与者：医院的相关人员，比如患者，前台咨询员等。
要使用的信息和资源 要使用的信息和资源包括，可以预约的医生数量，所在科室等，医院中的设备，病房等。 要考虑的约束条件和要使用的规则 约束条件：同一医生同一时间段内只能接受一名患者的预约，根据医疗设备的属性决定是否要排他性的使用。
3、情景需求分析的步骤
需求规格说明输入过程需求目标列表1.目标分析系统模型目标,目的使用情景用户问题实例2.输入事件分析初始系统模型用户,环境事件情景脚本4.输出需求分析3.刻画系统输出情景结构模型系统输出类型信息需求5.社会影响分析Agent目标6.涉众分析需求规格说明
3.1 目标分析
在第2部分情景描述的主要成分中已经对目标进行了分析，即：预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。3.2 输入事件分析
对于该系统的输入事件可能会包括如下情况：初始使用该系统的用户需要先注册，而对于已经注册的用户在使用系统预约挂号时首先要登录系统。这是最基本的两个输入事件。3.3 刻画系统输出
对于系统输出我们要考虑系统输出的形式，比如消息显示，对话框等形式。不如用户在登录系统是输入的用户名和密码不匹配的时候要给出对应的提示信息，比如用户名未注册或密码不对等。在提交预约挂号申请后系统也应给出预约成功与否的提示。3.4输出需求分析
对于输出需求要根据用户的输入给出对应的输出。比如用户输入查询请求，那么系统应该能够给出详细的信息。系统只给出对应的输出还不够，同时要考虑输出的信息是否合适。比如用户要查询眼科医生的资料，系统的输出就应该只是眼科医生的信息，而没有必要把所有医生的信息都输出。3.5 社会影响分析
在进行社会影响分析时要同时考虑到积极和消极两个方面的问题。系统是否可以提高效率，减少人员的工作量。同时也要考虑过多的自动化是否会削弱人对整个系统的意识，导致人对意外处理的能力降低，比如系统临时出现问题，是否有一套应急措施使医院日常工作能够正常的进行。
4、需求说明文档
基于之前构建的模型，并参照IEEE 830-1998标准模板，撰写的系统需求说明文档如下。
4.1 引言
引言部分将对本文档的编写目的、系统的开发目的、名词定义以及参考资料进行说明，并对文档的后续内容进行概述。4.1.1 编写目的
网上预约挂号系统是基于Web开发技术完成的网站。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。因此，基于之前构建的各类模型，撰写系统的需求说明文档，并将其作为后续项目设计、项目开发和项目测试的指导。
本文档连同之前构建的模型，可用来与客户进一步明确需求，同时可供项目经理、设计人员、开发人员参考。4.1.2 系统目的
许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。4.1.3 名词定义 患者预约系统
网上预约挂号系统的子系统，主要用于为患者提供预约挂号、信息查询等功能。 医生工作查询系统
网上预约挂号系统的子系统，主要用于为医生提供各时段预约患者的信息。 医务管理系统
网上预约挂号系统的子系统，主要用于为管理员提供出诊信息修改、预约挂号调整等功能。 账号控制系统
网上预约挂号系统的子系统，主要用于用户账号的注册及登录控制。 安全保障系统
网上预约挂号系统的子系统，主要用于保障系统的程序、网络及数据库安全。4.1.4 参考资料
[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吴双兵,刘伟.网上预约挂号系统设计与实现[J].医学信息学杂志, 2015, 36(1):36-39.4.1.5 文档概述
需求说明文档主要分为三个部分。本节属于引言部分，主要用于对文档本身进行定义和描述。文档的第二部分为系统的整体描述，包括系统的预期目标、限制条件以及用户的需求、特征。文档的第三部分是需求说明，包含对系统需求的明确定义。
4.2 整体描述
本节将对系统预期、用户需求、用户特征、条件与限制、假定与依赖以及需求分配进行说明。
4.2.1 系统预期
为了方便用户在不需安装任何软件的情况下使用系统，本系统整体采用B/S结构，用户可以通过浏览器对其进行访问。4.2.2 用户需求
参照之前完成的目标模型，对用户的需求进行整理和定义。由于系统整体较为复杂，因此本小节只包含已构建目标模型的功能性需求和非功能性需求。 功能性需求
1.患者进行预约选择
为了实现患者进行预约选择的目标，系统应完成的需求如下。（1）系统拥有患者预约页面以及预约按钮：
系统的预约页面可以显示未来1至3天的出诊医生及其所有可被预约的出诊时段。其中，尚未被预约的时段拥有预约按钮；已被预约的时段无法被其他患者预约，因此无预约按钮。（2）系统接收到预约请求：
当患者点击预约按钮，系统可以接收到预约请求。（3）患者被告知预约选择结果：
系统可以对患者是否预约成功进行判定，如果成功则跳转至信息确认页面，否则弹出对话框给予患者相应提示。2.患者确认预约信息
为了实现患者确认预约信息的目标，系统应完成的需求如下。（1）系统拥有预约信息确认页面以及预约提交按钮：
系统的预约信息确认页面会显示预约的医生和时段，患者的个人信息，以及预约提交按钮，患者可以在提交预约前核对这些信息。（2）系统接收到预约提交请求：
当患者点击提交按钮，系统可以接收到预约提交请求。（3）患者被告知预约提交结果：
系统可以对预约是否提交成功进行判定，并弹出对话框给予患者相应提示。 非功能性需求 1.安全的系统
为了保证预约挂号系统的安全性，系统应完成的需求如下。（1）用户程序安全：
系统应明确区分不同类别用户的权限。并且在用户登录时，输入的密码不可见、不可复制。（2）系统网络安全：
系统应采取安全的网络传输协议，网络数据在被传输前应进行加密。（3）数据库安全：
数据库中存储的数据应具备完整性，且密码应在加密后被存储到数据库中。此外，数据库中的数据应该可以被备份和恢复。2.低成本的系统 为了保证预约挂号系统的低成本，系统应完成的需求如下。（1）系统开发成本低：
开发团队应具备合理的项目管理，且在开发前应尽可能明确系统的需求。（2）系统运营成本低：
系统在运行过程中，应该尽可能少的占用资源。（3）系统维护成本低：
系统应该健壮可靠，出现问题后应该易于修复，且系统的功能应该易于扩展。考虑到系统健壮可靠与系统开发成本低存在一定的冲突，因此需要进行一定的权衡。4.2.3 用户特征
本系统的用户包含患者、医生以及管理员三类，其特征如下。 患者
个体间在年龄、计算机使用能力等方面存在较大差异。 医生
普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。 管理员
负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。4.2.4 条件与限制
为了保证系统的可移植性和可扩展性，本系统应使用Java语言进行开发。4.2.5 假定与依赖
本系统假定提供的大、中、小三种字体大小可以满足不同患者的需求，并且患者可以在系统的引导和提示下正常使用系统。4.2.6 需求分配
由于文档中并未列出系统的全部需求，因此无法对所有需求进行优先级排序。但已经列出的均为系统较为核心的功能性需求和非功能性需求，应具有高优先级。
4.3 需求说明
需求说明部分将参照之前完成的模型，对系统结构、对象模型以及操作过程模型进行详细描述。
4.3.1 系统结构
本部分将主要参照图 3-1所示的责任模型，根据主体对需求进行划分。考虑到系统较为复杂，因此只列出主体“患者预约系统”的相关需求。 患者预约系统
系统拥有患者预约页面以及预约按钮。
系统接收到预约请求。
患者被告知预约选择结果。
系统拥有预约信息确认页面及预约提交按钮。
系统接收到预约提交请求。
患者被告知预约提交的结果。4.3.2 对象模型
本部分将主要对图 4-1所示的对象模型的结构进行解释。
网上预约挂号系统可以被详细划分为患者预约系统、医生工作查询系统、医务管理系统、账号控制系统、安全保障系统等五个子系统。患者预约系统、医生工作查询系统、医务管理系统的使用者分别为患者、医生和管理员，这些用户通过系统提供的页面与系统进行交互。
对象模型中所涉及的名词在4.1.3小节中有具体解释。4.3.3 操作过程模型
本部分将主要对图 5-1，图 5-3和图 5-4所示的操作过程模型进行说明，并以表格的形式列出各操作过程的参与主体及对应需求。 患者进行预约选择
患者点击预约按钮后，患者预约系统会收到患者的预约请求，并触发预约验证操作，得到预约验证结果。接下来，患者预约系统会以得出的预约结果为基础，进行预约结果判定，进而执行页面跳转或消息框弹出操作。 患者确认预约信息
患者点击提交按钮后，患者预约系统会收到患者的预约提交请求，并触发预约提交操作。接下来，患者预约系统会根据提交结果弹出包含相应信息的提示框。
以上部分涉及到的操作过程及与之对应的主体、需求如下表所示。
以上部分涉及到的操作过程及与之对应的主体、需求如表 4-1所示。
操作 预约验证 参与主体
对应需求
患者预约系统 系统接收到预约请求，患者被告知预约选择结果
预约结果判定 患者预约系统 患者被告知预约选择结果 预约提交 患者预约系统 系统接收到预约提交请求，患者被告知预约提交结果
第四篇：软件项目需求建议书
篇一：软件需求建议书
医院门诊管理系统需求建议书
2012年3月26日
有关公司：
现需一个医院门诊管理系统，要求具有相关项目经验的软件公司参与竞标，要求能对该系统进行合理的编写，保证系统能够稳定运行，并且在预定时间内交付我院使用。
项目目标：
系统分为5个子系统，即（a）挂号管理系统(b)病历管理系统(c)药品库存管理系统(d)内部资料管理系统(f)财务管理系统。并且需要保证系统运行稳定准确。
1.工作表述
承包商应执行以下工作任务，及工作要求：
(1)系统应使用本院的局域网，win98、win2000、winxp、win7等环境
下，可进行稳定准确的查询，修改、处理功能。
(2)数据录入功能：其中包括在挂号时的患者信息录入，病历管理的录
入处方和内部资料管理中的医师信息的添加。
(3)数据的修改和删除功能：其中包括改号、退号和内部资料管理中的
患者、医师信息的修改和删除功能。
(4)数据查询功能：包括在诊室管理中的药品的模糊查询，对库存不足
的药品报警，内部资料管理中的医师、患者信息的查询中包括单项查询和组合查询。
(5)统计报表功能，财务报表：统计每天患者交款报表和挂号员每天的
交款单。统计患者总人数和总费用。
(6)按处方类别和拼音码分别统计药品的总数和库存剩容量。
(7)按科室名称和是否专家级别分别统计医师总人数信息。日报表：打
印每天的患者人数、就诊科室等，以及医师每天的出诊数，检验、检查、手术每天的执行次数，以及这些项目的总金额。
(8)合计费用功能：患者凭挂号单到交款处交款，系统根据门诊号码自 动调用患者信息，显示患者的单项费用和总费用，自动找零。
(9)系统管理功能：其中包括用户和内部人员的修改密码功能，根据权
限添加用户和管理员。数据备份功能。
(10)帮助功能：包含医院简介和系统主要实现功能简介。
2交付实物
（1）必须准备一份详细的系统设计报告，以及所用到的技术，用以监测产品
质量。
（2）有关项目进程的书面报告必须在每15天交给本院。报告应简明，并且
重点放在与承约商的原计划和时间表相对应的进程上。报告应涉及到各项活动、取得的进展、接下来15天的计划、花费的时间与金钱。对于落后进度计划进程的工作项目，应当提供一份计划，使项目能在原进度计划和预算内完成。
（3）在合同预期内，交付我院一个能够运行正常稳定的完整的系统。并且在
后期一定时间内提供免费维护。
3其他要求
（4）本院会向承包商提供本院的一些业务流程。
（5）承约商必须在执行工作前，获得本院对最终计划的认同。
（6）合同必须以一个商定的价格，给提供满足需求建议书要求工作的承约商
付款。
（7）承约商必须最迟在2012年5月1日以前提供给本院两份建议书备份。
（8）本院希望在2012年6月1日前选中一家承约商。这个工程需要完成的
期限是十二个月，从2012年7月1日至2013年7月1日，所有交付物必须不迟于2013年10月1日提供给本院。
（9）本院将按照下面的时间表付款给承约商：当项目完成了1/3时付总额的
1/3；当项目完成了2/3时付总额的2/3；当本人已经满意于项目的100%，并且承约商已履行了全部契约义务时再付出总额的最后1/3。
申请内容
(1)承约商能清晰理解需求建议书，理解什么是被期望达到的要求。承约商应有对每个任务和任务如何完成的详细描述。
(2)承约商将要提供的每一份交付物的描述。
(3)列出条形图或网络图表，列明每周要执行的详细任务的时间表，以便在要求的项目完成日期内能够完成项目。
(4)叙述一下承约商最近已经执行过的相似项目，包括已完成的子系统，以及其他子系统的完成进度。
(5)列出工程具体人员的姓名和详细简历，以及他在类似工程的精彩的经历。
(6)必须说明项目所需要的人月，并通过一份详细的工作时间分解和每个被指派于工程的员工的小时成本费用来验证。此外，所有直接费用逐条列表也必须包括进来。
(7)承包商需列出贵公司的软件能力成熟度(cmmi)等级。
(8)本院将按照以下的标准评价所有承约商的申请书：
a．设计方案(30%)。设计的实用及涉及技术。
b．经验(30%)。被指定工程的承约商和工作人员执行类似工程的经验。
c．成本(30%)。承约商申请中的所列的固定成本。
d．进度计划(10%)。为了在要求的项目完成日期内或在此日期之前完成项目，承约商应提出进度计划的详细而全面的连续说明。
篇二：软件系统项目建议书完全版
****系统项目建议书
2014年5月
目录
概述....................................................................1 1.1 文档编写目的...........................................................................................................1 1.2 系统建设目标与内容...............................................................................................1 1.2.1 系统建设目标...................................................................................................1 1.2.2 系统建设的主要内容.......................................................................................1 2 系统设计方案.............................................................1 2.1 总体架构设计...........................................................................................................1 2.1.1 系统总体业务架构...........................................................................................1 2.1.2 系统总体软件架构...........................................................................................1 2.1.3 系统总体技术架构...........................................................................................1 2.2 系统组成...................................................................................................................1 2.3 系统数据流...............................................................................................................1 2.4 系统功能...................................................................................................................3 3 系统部署方案.............................................................3 3.1 系统部署架构...........................................................................................................3 3.2 系统环境...................................................................................................................3 3.2.1 软件环境...........................................................................................................4 3.2.2 硬件环境...........................................................................................................4 4 系统界面设计.............................................................4 5 主要技术指标.............................................................4 6 交付成果................................................................6 7 验收策略................................................................6 7.1 系统验收测试的原则...............................................................................................6 7.2 验收测试的具体内容...............................................................................................7 7.3 验收测试的步骤.......................................................................................................7 8 质量保证................................................................8 8.1 软件研制一般要求...................................................................................................8 8.2 软件评审要求...........................................................................................................9 8.3 软件配置管理要求.................................................................................................10 9 售后服务...............................................................10 9.1 培训.........................................................................................................................10 9.2 维护与升级.............................................................................................................10 9.3 质量保证期内的服务.............................................................................................10 9.4 寿命期内维修服务.................................................................................................11 10 开发进度计划............................................................11 11 项目报价...............................................................12 1 概述
1.1 文档编写目的 1.2 系统建设目标与内容
1.2.1 系统建设目标 1.2.2 系统建设的主要内容
系统设计方案 2.1 总体架构设计
2.1.1 系统总体业务架构 2.1.2 系统总体软件架构 2.1.3 系统总体技术架构
2.2 系统组成
2.3 系统数据流
系统详细数据流如下图所示。
2.4 系统功能
系统部署方案 3.1 系统部署架构
表1各子系统部署架构
3.2 系统环境 篇三：需求建议书
题目：
假设你在嘉州新城购买了一套二室二厅一厨一卫，面积大约90平方的新房，先装修入住，请你根据自己的需求对这个房屋装修项目编写项目需求建议书。
项目：房屋装修
需求建议书：
（1）承约商要执行的任务：装修材料的购买、家用设备的安装、装修工程。
① 代购装修材料，如：地砖、涂料等等
② 厨房器具、淋浴设备等的代购
（2）承约商根据国家标准装修，提供装修计划、施工方案，最后装修符合标准的房
子。
（3）本人向承约商提供装修方案。
要求：
①、卧室的颜色以暖色调为主
②、装修后简单、宽敞、采光效果良好
③、卫生间隔成两部分，分为盥洗间和浴室
（4）和承约商签订一个商定的价格，以及满足需求建议书的工作承约商付款合同。
（5）当装修工程完成1／2时付总额的1／2；当装修工程100%完成时，获得本人的
满意后，并且承约商已经全部履行契约义务时再付总额的最后1／2。
（6）希望这个项目在两个月内完成，从5月15日到7月15日，所有的可交付成果 必须不迟于7月15日提供给本人。
（7）承约商必须最迟于4月30日以前向本人提交两份申请书备份。承约商的申请书
至少包括以下内容： 1）承约商能清晰的理解需求建议书，要详细描述承约商的实施装修项目的方法，以及使用的装修材料的具体规格。
2）承约商要提供可交付成果的详细描述。
3）在6月15日向本人反映项目进行的进度。
4）叙述承约商最近实施的项目，包括客户的姓名、地址和电话号码，以备核实。
5）列出将被指定为项目主要负责人的姓名和联系方式，以及工作经验。
（8）申请书的评价标准
1）承约商提出的建设方案（30%）
2）被指定为执行此项目主要负责人的姓名和联系方式，以及类似的工作经验（30%）
3）承约商申请书所列的固定成本（30%）
4）承约商提供的施工计划（10%）
组员：岳红 117 王华 213 周燕飞 126 赵涵玉 223 曾志锦 203 篇四：需求建议书
需求建议书（request for proposal，rfp）
什么是需求建议书[1] 需求建议书是指从客户角度出发，全面、详细地向服务商陈述、表达为了满足其已识别需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出的用来说明如何满足其已识别需求的建议书，是客户与服务商建立正式联系的第一份书面文件，又称招标书。需求建议书一般由客户起草，主要描述客户的需求、条件及对项目任务的具体要求。一份完整的需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然，并非在所有情况下都需要准备一份正式的需求建议书，当某一企业的需求由内部开发项目予以满足时，这一过程似乎变得简单多了，此时更多需要的是口头上的交流和信息传递，而不是把宝贵的时间耽搁在仅仅起到信息传递作用的需求建议书上。例如，某一软件开发公司感到公司原来的财务分析系统已经远远不能适应日益增加的业务需要时，便可直接要求软件开发小组进行开发，这时只需口头把相关的要求传达给软件开发小组即可。
[编辑] 需求建议书的主要内容[2] 需求建议书一般包含以下主要内容：
客户必须搜集大量相关资料准备需求建议书，因为it项目实施者需要按照rfp来准备他们的项目技术方案，并以此参与竞标。rfp中包括项目的目标，也就是用户的期望，也包括客户要求项目的进度计划；对实施商申请书的表格和内容的规定；客户希望潜在的实施商提交投标申请书的最后期限；评价申请书的标准等。一份好的rfp应该包括以下一些内容。
1．工作表述
工作表述就是说明项目的工作范围，概括客户要求开发商或项目团队执行的任务或工作单元，说明项目所涉及的各种事情，哪些必须由开发商或项目团队去完成，哪些由客户自己去做。例如，一个办公自动化软件系统的具体目标。又如建设一个网站，所需设备的采购任务，是由客户自己完成，还是由开发商去完成；企业网站上的页面文字，是客户自己撰写，还是由开发商撰写等。2．任务要求
需求建议书必须要具体规定开发商需要完成任务的规格和特征，如要求涉及大小、数量、颜色、重量、速度和其他开发商提出的解决方案中，所必须满足的物理参数和操作参数。例如，建立一个企业网站，可能要求在1 000人同时访问的情况下不会产生堵塞的感觉，网
站的浏览页面不低于多少；建立一个自动结账和收款系统，可能要求每天能办理12 000次交易的功能和其他特定的功能，如在开出了发票的30天内没有收到账款，就会自动产生催款通知。具体的任务要求，可能会成为将来的验收标准。
3．交付物
交付物就是开发商所提供的实体内容，这在需求建议书中应该说明。例如，对于自动结账和收款系统来说，客户可能要求开发商提供硬件(计算机)、软件(磁盘和一些印刷品)、操作手册和培训课程。交付物也可能包括客户要求开发商提供定期进度报告或终期报告。
4．客户供应条款
需求建议书还应该列出客户的供应条款。例如，客户需要建立一个网j站，可能需要向开发商提供企业内部的组织结构及各部门之间业务关系的详]细说明，包括信息流程的类型、信息流量和发生频率等。5．表述客户对需求的确认
需求建议书不是对客户需求的最后确认。最后的确认应该在对开发商提出的方案进行评估之后。例如印刷宣传手册，可能在开印之前要经过客户审定；局域网的建设，在购买材料和设备之前，客户必须审定开发商的技术方案。这一点在需求建议书中必须向开发商说明。
6．期望的合同类型(1)合同可以按固定价格订立。这样，开发商实际上就是费用包干。客户只给固定的价钱，不管开发商实际工作花费多少。开发商必须保证功能的实现和质量要求，超支的风险由开发商负担。
(2)合同也可以规定开发商不承担风险，即在时间、原材料限制的条件下，不论实际成本多少，都会给开发商特定的报酬，也就是所谓包工不包料。在我国现阶段的条件下，由于质量检验和资信度水平不高，这种合同比]较普遍。在需求建议书中，最好说明客户是希望采用那种类型的合同。7．期望的付款方式
付款方式可以分为一次性付款和分阶段付款；在开始前付款和结束后付款。一般依项目的性质来定付款方式。如网页制作，往往在项目末期付款；而架设局域网，一般在方案确认后，付款30％以便开发商采购，工程结束验收后付满90％，留10％等到使用一段时间以后确认无问题时付清。具体付款方式需要合同双方协商，但在需求建议书中，客户应该先提出自己的期望付款方式。8．要求的进度计划
进度计划的要求可能很粗，如要求在6个月内完成；也可以详细一些，如多长时间内完成方案设计和审定，多长时间内完成硬件选购与安装，多长时间内完成软件研制、测试与安装，最后开发商在系统安装调试后，在多长时间内提交所有的系统文件和操作培训。9．申请书的格式和内容提示
为了便于在几个开发商之间进行比较和评价，申请书应该在形式上采取同一个格式，内容的结构也应该一致。这样对不同的申请者来说比较公平，也能减轻客户在评审时的工作量。客户在需求建议书中可以限定申请书的每一部分采用的文字数量或页数。
10．提交申请书的最后期限
申请书受理的截止日期是必须要交代清楚的。例如，要求开发商在接到需求建议书后多少个工作口之内(如l周之内、1个月之内等)提交申请书，或大家一律在某月某日之前提交申请书。这样做的目的是便于同时对众多的申请者进行比较、评估，也是为了保持公正，不给某些开发商以额外的时间和机会。
11．对申请书的评价标准
要告诉开发商客户将根据哪些准则来评价他提交的申请书。这样做的目的，是指导开发商写好申请书。一般评价标准包括4个方面的内容：
(1)开发商在类似项目中的经验。如他们近期是否在预算内按期完成了类似的项目，客户对他们是否满意?(2)开发商提出的技术方案是否合适。如采用哪种类型的计算机软件?数据库的设计、方法是什么?用来建立管理信息系统的是哪种语言?采用哪些供应商的设备?等等。
(3)进度计划。开发商是否能按照所要求的进度完成项目计划?(4)成本。如开发商的报价是否合理?成本预算中有无漏算的条款?将来在执行时有没有可能出现超支，或有无可能因过于节约而导致质量不能保证?有的申请人为了争取合同，在报价上压低成本，到了执行阶段，或偷工减料，或增加成本，结果导致所建系统的缺陷很多，或使最终成本大大超出原始的估算。对此需要引起注意。
12．资金总量
开发商总是希望了解客户有多少资金可以用于发展拟议中的真t项目，但客户在需求建议书中，往往不愿意透露这个信息。其实，客户暗示大约的数字，告诉开发商他打算花多少钱来办这件事是有好处的，这样可以使开发商能够提交与资金水平相适应的申请书，提高在项目准备阶段的工作效率。
[编辑] 需求建议书的必要性[2] 需求建议书(rfp)是项目客户与开发商建立正式联系的第一份书面文件，也叫招标书。一般由项目的客户自己起草，主要描述客户的需求、条件以及对项目任务的具体要求，向可能的开发商发送。
需求建议书是客户为确保供应商理解项目的需求，并在此基础上提供项目建议书而编制的需求规范。虽然它不能确保客户据此就能获得理想的解决方案，但却可以帮助客户发现那些尽可能接近自身需求的系统准备。其
目的是从客户自身的角度出发，通过全面、详细地陈述，使开发商或项目团队理解客户所希望的是什么，以可行的价格满足客户的已识别的需求。
对于一些预算较少的客户，开发商往往不愿意花精力准备正式的方案建议书，这种情况下，客户的需求建议书就变得很重要。事实上，项目无论大小，都需要编写需求建议书。第一，需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是客户进一步明确自己的目标与需求的过程，并以此建立起客户与供应商进行深人沟通的桥梁。即使因为各种原因使得供应商看不到或不愿响应需求建议书，这种努力也是值得付出的。
第二，需求建议书可节省选型的时间，并使得对各供应商之间的比较变得更容易。客户提供给所有竞标供应商的信息都是一样的，避免了跟各开发商的重复沟通，同时，有需求建议书作为基准，客户可以约束各开发商以一致的格式提交方案建议书，以提高各供应商之间的可比性。
第三，需求建议书可以避免一些潜在的疏漏。在准备需求建议书时，客户往往会因为太过关注具体细节而忽略了一些重要的因素。收到需求建议书后，有的供应商可能会主动对这样的疏漏提出质疑以提醒客户。还有些开发商为了使自己的方案建议书更具有吸引力，甚至会提出一些需求建议书没有涉及的好想法来拓展客户的思路。
[编辑] 编写需求建议书的一般原则[2] 需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做[到。所以，很多时候都是由用户与项目小组共同编写。编写项目需求说明的j过程也是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求[建议书没有公式化的方法，需要大量的实践经验。以下是编写需求建议书需要把握的几个原则：
(1)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确，需要用户的代表来参与确认，由他们检查、决定用户需[求的正确性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说：“这不是我们要的东西”；“你没明白我们的意思”，等等。
(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环境)下是可实现的。为了避免需求的不可行性，在需求分析阶段应该有核心技术人员参与，检查在技术上什么能做、什么不能做，哪些需要额外的付出等。
(3)需求内容应该是必要的。需求建议书中的每个需求都应该有相应[的出处，即说明什么是客户确实需要的，什么要顺应于外部的需求、接口或标准。如果不能标识出处，则可能这个需求不是真正需要的。
(4)需求内容应该有优先权。优先权是由客户或其代理及项目小组共同商讨后建立的。如果所有的需求都被视为同等重要，那么在开发中遇到预t算削减、计划超时或组员的离开而导致新的需求时，项目经理将无所适从。一般优先权有以下三个级别。
1)高优先权，表明需求必须体现在本阶段项目的成果中或这个产品的版本中。
2)中优先权，表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中。
3)低优先权，表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。
(5)需求内容应该是明确的。需求不该有歧义，要避免使用一些对于拟订项目需求建议书的人很清楚，但对于其他人模糊不清的词汇。如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁、直观地采用用户熟知的语言，而不要采用计算机术语。
[编辑] 需求建议书例子[2] 例：某企业项目管理软件开发项目需求建议书
有关单位：某企业(甲方)由于业务发展的需要，决定采用项目管理的方式进行管理，为了更有效地对项目的执行过程进行控制，该企业决定开发一套项目管理软件以满足这一需要。
1．工作表述
开发商将执行下面任务：开发项目管理软件。
开发项目管理软件的主要功能包括项目及工作信息的录入、项目网络计划图的绘制、项目时间计划的安排、甘特图计划的制定、项目执行信息的录入与分析及各种计划报表的输出等功能。2．要求
开发商应根据国家有关标准，提供开发计划和实施方案。篇五：软件项目管理项目建议书
湖南文理学院实验报告
时间： 2013 年 11 月 18 日
课程名称： 软件项目管理
实验名称：撰写毕业生就业信息管理系统项目建议书
班级： 姓名： 同组人： 无
指导教师评定： 签名：
一、实验目的掌握项目建议书的格式和写作要求，会结合具体项目写作项目建议书。
二、实验要求
1、结合模拟项目—毕业生就业信息管理系统项目写出项目建议书。
2、提交毕业生就业信息管理系统项目建议书（报告）一份。
三、实验环境 1．硬件：计算机 2．操作系统：windows平台。
3．相关软件：microsoft office软件。
四、实验步骤
1、背景介绍
随着internet的迅猛发展和普及，我国高等院校纷纷建立自己的校园网，使高校的办公，教学和管理工作发生了巨大的变化，并具有了新的特点，对教学管理工作提出了新的要求，也使得基于网络的高校毕业生就业招聘成为可能。通过internet，用人单位和就业者利用网络的便利，不直接见面，采用网络交互地就业联系、就业面试，以及就业意向和合同的签订等工作。我国部分高校目前正在尝试通过网络进行毕业生的就业分配工作，但目前使用的就业网站的开发应用，大多功能相对单一，多局限于就业信息的发布，就业信息的静态统计结果的公布及简单的就业信息查询，其实用性和互动性已经不能满足高校就业形势的需要。随着高校毕业生就业体制改革进程的不断深化和毕业生就业市场的逐步建立，高校毕业生在各种就业活动中求职面窄、择业率低、特别是信息量小的问题越来越突出。如何解决这一问题是摆在各级就业主管部门面前的严峻任务。正是在这种情形下，国务院对做好高校毕业生就业工作做出重要指示，即“要充分利用毕业生就业信息网络，沟通行业间、地区间、学校与用人单位间的信息，在毕业生和用人单位之间牵线搭桥。同时，通过信息反馈，优化高等教育结构，合理
利用有效资源，促进高等教育的健康发展”高校就业系统以招聘和求职系统为核心，以用人单位需求和服务为目标。明确了系统的定位，有利于构建优化网上就业服务体系，有利于不断激活毕业生就业市场，有利于网络资源的充分利用，有利于网上动态管理、杜绝虚假信息、拓宽网上就业服务功能。
2、项目的意义和必要性
毕业生就业信息系统和就业服务体系不完善，毕业生就业主要由学校、人才市场举办招聘会等方式获得信息，与需求方见面，信息渠道比较窄。毕业生的就业指导工作极为薄弱，就业指导教师水平参差不齐，专业的、高素质的就业指导教师太少；缺少优质的就业指导教材。所以，必须加强学生择业的政策咨询和信息服务，逐步建立起信息服务网络，建立毕业生就业网络系统，为实行网上求职择业创造条件和提供服务。目前，建设好大学生的就业网站，不仅仅是政府部门应该关心的问题，作为培养大学生的湖南文理学院也有同样的需求。
解决目前高校就业信息管理中存在的一些问题，如信息传递不方便、不快捷，数据分析及就业指导不及时，学生签约必须到不同部门领表、上交等繁琐的操作等。通过本系统可以使湖南文理学院毕业生就业信息管理工作更加合理化、科学化，提高工作的效率，从根本上改变就业管理工作的方式，通过internet，各院系和学生利用网络的便利，可以直接查询和提交就业信息。在这种系统平台下，可以快速、有效、全面的反映最新的用人单位信息、毕业生基本信息和就业趋势，及时提供高校学生工作管理人员对历届用人单位需求信息的分析统计，及时有效地调查分析大学毕业生的择业趋势和引发的心理问题并进行及时有效的就业指导。可以做到信息的规范管理、科学统计和快速查询，从而减少管理方面的工作量。
3、项目产品或服务的市场预测
（由于这个系统不是学院的直接收益产品，这里不做分析。）
4、项目的规模和期限
基于学院的实际情况，这个毕业生就业信息可以初步分为三个阶段来完成。
第一阶段，着重处理学院现有的问题，把系统运行起来，重点放在用户管理方面，分为用户注册、用户审核和用户登录验证三部分。
第二阶段，注重完成学校的就业信息发布，用户在通过系统注册后，可以查询各种信息。
第三阶段，系统管理，管理可以对学生用户和站内信息进行管理。
5、投资估算
具体相信的投资预算，由专业人员进行。这里只能给出对比其他同类学校信息系统的估算，3个阶段全部完成，大概需要5万人民币。这个估算不包括硬件设备的预算。
6、市场前景及经济效益初步分析
这个系统虽然不是学院的直接收益产品，但其带来的间接效益是毋庸置疑。具体可以表现为：
（1）管理决策的科学化。
传统的决策指示凭经验的大致的估算，无法采集到大量的数据，也无法对采集到的数据进行精确的分析，而毕业生就业管理系统通过internet，各院系和学生利用网络的便利，可以直接查询和提交就业信息，比较全面、及时地采集信息数据、并选定合适的管理模式，做出科学的决策，减少决策失误。
（2）管理工作的高效化。
在这种系统平台下，可以快速、有效、全面的反映最新的用人单位信息、毕业生基本信息和就业趋势，及时提供高校学生工作管理人员对历届用人单位需求信息的分析统计，及时有效地调查分析大学毕业生的择业趋势和引发的心理问题并进行及时有效的就业指导。
（3）网上就业服务体系的优化。
毕业生的就业指导工作极为薄弱，就业指导教师水平参差不齐，专业的、高素质的就业指导教师太少；缺少优质的就业指导教材。而毕业生就业网络系统加强了学生择业的政策咨询和信息服务，逐步建立起信息服务网络，为实行网上求职择业创造条件和提供服务。
（4）网络资源的充分利用。
指导老师可以开辟“求职顾问”，“就业指导”的板块，告诉毕业生就业过程中应该注意的问题，帮助学生完善职业形象；了解劳动关系法规；增强自身的保护意识；提高大学生竞争就业意识和能力。
大学生可以利用就业网络内容丰富、全面的就业信息，最新的国家就业政策和规范，了解国家就业形势，更新就业观念，树立正确职业观和就业观。同时，制作个人简历，实现网上的自荐求职，查询自己感兴趣用人单位的资料，来了解用人单位的情况。
用人单位可以浏览学生所在学校的网站来了解学校的概况及专业设置情况，了解学生专业知识结构和综合素质，并且通过学校就业网站来核对电子简历的诚信度。
（5）毕业生与用人单位的良好沟通
大学生通过查询自己感兴趣用人单位的资料，来了解用人单位的情况。对中意的单位可以投递电子简历。用人单位通过浏览学生所在学校的网站，了解毕业生的信息。有意向的双方可以通过网上面试的方式来进行进一步的沟通，提高学生和用人单位接触频率，促进就业工作开展。为企业和学生提供一个交流平台及更为人性化、个性化的服务。
另外需要注意的是，毕业生就业管理系统的效益一般是无形的，只有经过长期运行后的分析统计才能计算其收益，往往越成熟、科学、优秀的毕业生就业管理系统，带给我们的效益就越大。毕业生就业水平提高了，学校知名度也会随之提高，学校的生源也会越来越好。
综上所述，校方认为建立一个毕业生就业管理系统是非常必要的，请上级领导批示。
7、其他需要说明的问题
随着计算机科学与技术学院学院人数不断增加，毕业生的人数也会逐步增长，毕业生就业管理的难度也在不断加大，所有我们认为建立一个计算机科学与技术学院毕业生就业管理系统是在将来的影响和效益是不可估量。
第五篇：软件需求分析报告
软件需求分析
软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。
需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。事实上，需求文档在开发过程中一直起指导作用。需求的类型
下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反
映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。
点击咨询 