第一篇:软件开发需求说明_2015-03-03(大全)
社区人员维护软件开发需求说明表
一、系统设计:
1.该系统平台按照级别和可操作性能,分别设区级、19家社区级、财政和人事,共22个系统端口,主要数据库设在区级平台,财政和人事系统平台只能进行数据查询,不能进行数据修改和更新;如能确保数据安全的前提下,系统最好基于互联网实现信息传送。
2.如能基于互联网平台的话,社区平台要有提交功能,并生成审批表,区级要有审批权限,要把审批过的返还社区平台。
二、模块设计:
该系统应有6类模块:A类模块为体制内人员情况统计,B类模块为封闭式管理人员统计,C类模块为网格社工人员情况统计,D类模块为居委会人员情况统计,退休、辞职人员模块,每类模块内人员信息要用固定编号进行管理,每个人员的照片也能在相应模块上采集,固定编号可由区级平台增减,社区不能任意更改,每个模块都应具有汇总功能和花名册这样的明细功能,具体需求如下:
1.A、B、C、D模块基本人员信息设置(简称基础设置):第一、以固定编号为人员信息的起领,每个固定编号后跟随社区名称、姓名、性别、出生年月、身份证、家庭住址、学历、毕业院校及专业、是否党员、职务、工作部办、分管工作具体负责工作、电话、在岗情况、备注、照片。第二、每个模块有“新进人员”、“退休、辞职人员”功能键。
2.A类模块:除基础设置外,增加保留公务员身份人员/事业编制人员项目。该模块人员减少后固定编号中的“在岗情况”提示空编,新调入人员需附附件,附件为电子文档或图片。A类固定编号,可以变动人员信息。A类人员,在人员类别的下拉菜单选项中,要有“事业、原保留行政身份人员、事业工勤、其他”四个选项,当选择“事业、事业工勤”时,没有任何选项弹出;当选择“原保留行政身份人员”时,要有下拉菜单出现“公务员、机关工勤、其他”。当选“公务员、机关工勤”时,身份类别显示“事业”,并且在身份类别右上角有星号标识出现,然后在身份类别选项下方显示他所选的选项。当选“其他”时,在身份类别显示“其他”,在“其他”后面跳出空白一栏,由操作者自己填内容,并增加一个附件,附件上要有提示,提示为“必须是区级下发的文件为佐证”,并带上传附件功能。
3.B类模块:除基础设置外,B类中的人员信息只减不增,如有人退休或离职,固定编号将自动跟随退离职人员进入,不能有空编情况出现。B类固定编号,只减不增。B类人员身份必须规定,身份选择下拉菜单,只能有“老集体企业职工,退伍安置人员,原农水局分流兽医监督检疫员,原区物资公司分流人员,原新路口电影院分流人员,1992年集体所有制城管队员,2003年城管大队公务员招考落选分流人员,十年以上临聘人员,其他”。当选择“其他”时,系统必须自动弹出一个温馨提示,“必须是区级下发的文件作为佐证”。
4.C类模块:除基础设置外,还增加人员进入网格依据和时间、所获资格证书,在岗情况中要分为“区直部门”、“社区服务中心(x部/办)”、“派入xx居委会xx网格”、“其他”。人员发生空缺时,“其他”项目提示空编;新进人员时,“其他”项目提示“报备人员”。C类人员,如果要进行报备时,在当他固定编号空缺,实际发生缺员时,系统就要进行时间上的自动提示,提示内容为“5个工作日内向区级平台提交缺员申请”。完成缺员申请后,系统必须自动提示,在实际发生缺员后之日起,2个月内完成报备人员申请。在C类人员中,出生年月日要有提示,(含新进报备人员),“南明区网格社工年龄限制为43岁以下”,学历必须是高中以上。
5.D类模块:除基础设置外,还增加“所在居委会”、“进入网格工作情况”,“进入网格工作情况”下设“是否签约进入网格”、“网格内岗位”和“具体工作网格名称”,“是否签约进入网格”下设“是”和“否”两个选项,“网格内岗位”下设“网格员”、“大网格长”、“大网格长助理”。人员发生空缺时,提示“空编”。
6.退休、辞职人员模块:“退休、辞职人员”功能键生成的数据存放在本模块,本模块沿用根据1-4模块的人员信息设置,进入模块的人员设置“原固定编号”项目,显示该人员原先所在的固定编号。
7.考核模块:
考核等级分为:大网格长对自己管辖区域内的网格员进行考核,各社区服务中心对大网格长进行考核,网格员和大网格长的考核由素质、业务和服务组成。区级对各社区服务中心进行考核,考核方式按照各社区的业务表现,由区级灵活掌握,并作为年终目标评优的依据。考核模块以全年百分制计分,分三大模块进行考核: 第一、素质
素质考核以培训为主,由社区对网格员的培训进行汇总,认定培训一次,计4分,系统要有一个培训积分统计表,由社区进行填写,并能生成表格,可以打印出纸质档,电子表还能带提交功能,提交到区级平台,此表还带附件功能,由社区将培训的内容(照片、文档、表格等)上传到系统,区级平台能够随时查看。培训一年不少于5次。第二、业务
业务积分满分为40分。分为考勤35分和加班加分5分。
以网格员的考勤为主,各社区进行打分,系统要根据要求自行累加计分:每个网格员每年考勤总分为35分,每人每天0.14分,社区按照月进行统计,每天出勤一次,只需要勾选对应的日期选项,0.14分就自动累计,到月底进行汇总。加班5分,按照每个网格员的加班实际天数,每月灵活打分,满分为5分,由社区自行操作。第三、服务
服务类的评分共40分,由南明区社工网站、微信平台、群众满意度测评表三大类进行考核。系统上要有南明区社工网站、微信平台的网站链接,通过该链接可以让社区网格社工进行自我测评,并由大网格长进行汇总,汇总后提交到社区进行评分,分值由社区灵活操作。系统上还带有群众满意度测评表,该测评表由大网格长填写,提交到社区,经社区评分后,最后汇总到区级平台。打完分以后的应用: 系统将各社区网格员的评分,自动生成月汇总表和年汇总表。各社区根据年汇总表的网格员排名情况,选出排名前15%的人员,填报评优申请表到区级平台,该评优申请表在系统上进行填报。填报完成提交后,由区级批准同意后,进行年终评优。打分权限:
区级平台可任意查看社区全年打分情况;社区可看本社区管辖范围内的打分情况;大网格长可看本管辖范围内历史打分情况,但不可修改,大网格长只有每个月对考勤、培训、群众满意度的打分权限,每月登记一次,不可修改。本月没统计的积分可在下月统计,跨年度的积分修改,经在社区服务中心修改,一旦有分值修改,必须要有经社区网格管理办公室主任签字的文件作为附件支撑。所有打分的情况,素质评分、业务评分和服务评分的月度、年度积分,均带有生成电子表的功能,打分时间必须有提示,月度打分必须在每月最后一天,年度必须在每年第四季度的第二个月最后一天完成。年度的打分,必须带有汇总功能,汇总后生成排名表,排名前15%的人员,由社区在人员名字前打√,打√的人员要自动生成表格,作为评优人员的推荐信息提交到区级平台。作为评优人员的人,打√以后,要自动显示出一张电子推荐信息表,每人一张,由社区打印出来,盖章交到区级。区级平台经过点击,能够看到所有社区提交的评优人员信息汇总,由区级同意,点√后,评优人员最终产生,产生的人员信息头像(或名字)上有☆表示,这些人员经区级平台评定后,可自动反馈到各社区。
系统还要有个人才信息库,该人才库的人员信息,为连续三年评优的人员自动进入人才库,人才库只在区级平台体现,各社区不可体现也不可查看。各类人员全年分值划分: 居委会的网格员评分分值划分为,素质培训积分40分,业务积分20分,服务积分40分;社区服务中心和其他区职能部门认定的综合协管员评分分值划分为,素质培训积分40分,业务积分60分,60分业务分中,在社区的网格员由社区打,在区职能部门的,由区级网格管理办公室进行考评;区级网格员评分分值划分为,业务积分60分,考勤分20分,委内业务20分,社区评分20分;社区的网格员评分分值划分为,考勤分20分,社区内业务20分,居委会评分20分。考核不合格的惩罚:
如网格社工发生重大违规违纪事件,社区工作者在职期间受到公安司法机关刑事处罚或严重行政处罚社区工作者在职期间参加邪教组织,存在其它应予以终止关系的,永不能进入人才库,并取消他本人的星级评定。
三、表格生成:
1.汇总表:5个模块的汇总表格基本信息为各模块基础设置来提数形成,也可根据需求点击相关基础信息键(如身份证、家庭住址等)来提数形成。
2.花名册:汇总每个模块需列出每个固定编号后详细信息。
3.退休、辞职人员信息要有一个专门的数据库管理,有离职时间,还要显示原有的固定编号;离职、退休人员信息的维护必须与新进人员信息维护一样,并且还要增加一项功能,审批表上增加上传文件的电子档功能,此文件可以是图片、文件、压缩包,都能上传到区级平台;
四、各项指标说明:
1.固定编号:该编号1.2两位必须是每个表格的序号,3.4两位是社区序号,5.6.7.8位是本类表总人数序号,9.10.11位是社区总人数序号。
2.性别:只有男女选项。
3.出生年月:格式必须是1991.01.01。
4.毕业院校及专业:填写时提示xx学校xx专业。
5.是否党员:下设是和否选项。
6.工作部办:下设服务大厅、社会事务部、城市管理部、群众工作部、党政工作部、网格管理办公室选项。
7.在岗情况:只能有在岗、退休、离职、报备人员4个选项;
8.身份证号:填写该项目时提示身份证规范要求(如身份证18位)
9.家庭住址:填写时要求输入数字超过6个,提示家庭住址必须超过6个字。
10.学历:下设选项包括初中、中专、高中、职高、大专、本科、研究生等(请按照规范软件给我们设计)
11.职务:本栏需填两个格子,第一个格子下设“有”、“无”选项,选“有”时第二个格子由填报人自行填写,提示“具体职务”,选“无”选项的,在第二个格子内显示“一般工作人员”选项。
12.分管工作/具体负责工作:填写提示“详细填写分管工作或具体服务工作内容”。
13.电话:填写提示“优先填写手机号”。
14.在岗情况:A、B、D下设“在岗”、“退休”、“辞职”、“借调”、“其他”,如选择其他,必须在备注内填信息,设定相关联的设定。
15.照片:能采集人员照片并上报系统保存。
16.B类人员的身份:必须规范为老集体企业(工业公司、劳服司等)职工、区属干部家属及子女退伍安置人员、原农水局分流兽医监督检疫员、原区物资公司分流人员、原新路口电影院分流人员、1992年集体所有制城管队员、2003年城管大队公务员招考分流人员、10年以上临聘人员,其他(该选项必须上报附件,附件由区级部门或市级部门进行佐证)。17.C类人员的身份:必须规范为综治巡防人员、禁毒专干、社区矫正工作人员、低保工作人员、劳动保障协管员、流动人口协管员、卫生监督协管员、十年以下临聘人员。
第二篇:软件开发计划说明
软件开发计划(SDP)
说明:
1.《软件开发计划》(SDP)描述开发者实施软件开发工作的计划,本文档中“软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其他所有的活动。
2.SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。
3.本计划的某些部分可视实际需要单独编制成册,例如,软件配置管理计划、软件质量保证计划和文档编制计划等。
软件开发计划的正文的格式如下
1引言
本章分为以下几条。
1.1标识
本条应包含本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述
本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的投资方、需方、用户、开发方和支持机构;标识当前和计划的运行现场;列出其他有关的文档。
1.3文档概述
本条应概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。
1.4与其他计划之间的关系
(若有)本条描述本计划和其他项目管理计划的关系。
1.5基线
给出编写本项目开发计划的输入基线,如软件需求规格说明。
2引用文件
本章应列出本文档引用的所有文档的编号、标题、修订版本和日期,本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3交付产品
3.1程序
3.2文档
3.3服务
3.4非移交产品
3.5验收标准
3.6最后交付期限
列出本项目应交付的产品,包括软件产品和文档。其中,软件产品应指明哪些是要开发的,哪些是属于维护性质的;文档是指随软件产品交付给用户的技术文档,例如用户手册、安装手册等。
4所需工作概述
本章根据需要分条对后续章描述的计划作出说明,(若适用)包括以下概述:
a.对所要开发系统、软件的需求和约束;
b.对项目文档编制的需求和约束;
c.该项目在系统生命周期中所处的地位;
d.所选用的计划/采购策略或对它们的需求和约束;
e.项目进度安排及资源的需求和约柬;
f.其他的需求和约束,如:项目的安全性、保密性、私密性、方法、标准、硬件开发和软件开发的相互依赖关系等。
5实施整个软件开发活动的计划
本章分以下几条。不需要的活动的条款用“不适用”注明,如果对项目中不同的开发阶段或不同的软件需要不同的计划,这些不同之处应在此条加以注解。除以下规定的内容外,每条中还应标识可适用的风险和不确定因素,及处理它们的计划。
5.1软件开发过程
本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款,确定已计划的开发阶段(适用的话)、目标和各阶段要执行的软件开发活动。
5.2软件开发总体计划
本条应分以下若干条进行描述。
5.2.1软件开发方法
本条应描述或引用要使用的软件开发方法,包括为支持这些方法所使用的手工、自动工具和过程的描述。该方法应覆盖论及它的所有合同条款。如果这些方法在它们所适用的活动范围有更好的描述,可引用本计划的其他条。
5.2.2软件产品标准
本条应描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准。标准应覆盖合同中论及它的所有条款。如果这些标准在标准所适用的活动范围有更好的描述,可引用本计划中的其他条。对要使用的各种编程语言都应提供编码标准,至少应包括:
a.格式标准(如:缩进、空格、大小写和信息的排序);
b.首部注释标准,例如(要求:代码的名称/标识符,版本标识,修改历史,用途)需求和实现的设计决策,处理的注记(例如:使用的算法、假设、约束、限制和副作用),数据注记(输入、输出、变量和数据结构等);
c.其他注释标准(例如要求的数量和预期的内容);
d.变量、参数、程序包、过程和文档等的命名约定;
e.(若有)编程语言构造或功能的使用限制;
f.代码聚合复杂性的制约。
5.2.3可重用的软件产品
本条应分以下若干条。
5.2.3.1吸纳可重用的软件产品
本条应描述标识、评估和吸纳可重用软件产品要遵循的方法,包括搜寻这些产品的范围和进行评估的准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对已选定的或候选的可重用的软件产品应加以标识和说明,(若适用)同时应给出与使用有关的优点、缺陷和限制。
5.2.3.2开发可重用的软件产品
本条应描述如何标识、评估和报告开发可重用软件产品的机会。描述应覆盖合同中论及它的所有条款。
5.2.4处理关键性需求
本条应分以下若干条描述为处理指定关键性需求应遵循的方法。描述应覆盖合同中论及它的所有条款。
5.2.4.1安全性保证
5.2.4.2保密性保证
5.2.4.3私密性保证
5.2.4.4其他关键性需求保证
5.2.5计算机硬件资源利用
本条应描述分配计算机硬件资源和监控其使用情况要遵循的方法。描述应覆盖合同中论及它的所有条款。
5.2.6记录原理
本条应描述记录原理所遵循的方法,该原理在支持机构对项目作出关键决策时是有用的。应对项目的“关键决策”一词作出解释,并陈述原理记录在什么地方。描述应覆盖合同中论及它的所有条款。
5.2.7需方评审途径
本条应描述为评审软件产品和活动,让需方或授权代表访问开发方和分承包方的一些设施要遵循的方法。描述应遵循合同中论及它的所有条款。
6实施详细软件开发活动的计划
本章分条进行描述。不需要的活动用“不适用”注明,如果项目的不同的开发阶段或不同的软件需要不同的计划,则在本条应指出这些差异。每项活动的论述应包括应用于以下方面的途径(方法/过程/工具):
a.所涉及的分析性任务或其他技术性任务;
b.结果的记录;
c.与交付有关的准备(如果有的话)。
论述还应标识存在的风险和不确定因素,及处理它们的计划。如果适用的方法在5.2.1处描述了的话,可引用它。
6.1项目计划和监督
本条分成若干分条描述项目计划和监督中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.1.1软件开发计划(包括对该计划的更新)
6.1.2CSCI测试计划
6.1.3系统测试计划
6.1.4软件安装计划
6.1.5软件移交计划
6.1.6跟踪和更新计划,包括评审管理的时间间隔
6.2建立软件开发环境
本条分成以下若干分条描述建立、控制、维护软件开发环境所遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.2.1软件工程环境
6.2.2软件测试环境
6.2.3软件开发库
6.2.4软件开发文档
6.2.5非交付软件
6.3系统需求分析
6.3.1用户输入分析
6.3.2运行概念
6.3.3系统需求
6.4系统设计
6.4.1系统级设计决策
6.4.2系统体系结构设计
6.5软件需求分析
本条描述软件需求分析中要遵循的方法。应覆盖合同中论及它的所有条款。
6.6软件设计
本条应分成若干分条描述软件设计中所遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.6.1 CSCI级设计决策
6.6.2 CSCI体系结构设计
6.6.3 CSCI详细设计
6.7软件实现和配置项测试
本条应分成若干分条描述软件实现和配置项测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.7.1软件实现
6.7.2配置项测试准备
6.7.3配置项测试执行
6.7.4修改和再测试
6.7.5配置项测试结果分析与记录
6.8配置项集成和测试
本条应分成若干分条描述配置项集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.8.1配置项集成和测试准备
6.8.2配置项集成和测试执行
6.8.3修改和再测试
6.8.4配置项集成和测试结果分析与记录
6.9 CSCI合格性测试
本条应分成若干分条描述CSCI合格性测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.9.1 CSCI合格性测试的独立性
6.9.2在目标计算机系统(或模拟的环境)上测试
6.9.3 CSCI合格性测试准备
6.9.4 CSCI合格性测试演练
6.9.5 CSCI合格性测试执行
6.9.6修改和再测试
6.9.7 CSCI合格性测试结果分析与记录
6.10 CSCI/HWCI集成和测试
本条应分成若干分条描述CSCI/HWCI集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.10.1 CSCI/HWCI集成和测试准备
6.10.2 CSCI/HWCI集成和测试执行
6.10.3修改和再测试
6.10.4 CSCI/HWCI集成和测试结果分析与记录
6.11系统合格性测试
本条应分成若干分条描述系统合格性测试中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。
6.11.1系统合格性测试的独立性
6.11.2在目标计算机系统(或模拟的环境)上测试
6.11.3系统合格性测试准备
6.11.4系统合格性测试演练
6.11.5系统合格性测试执行
6.11.6修改和再测试
6.11.7系统合格性测试结果分析与记录
6.12软件使用准备
本条应分成若干分条描述软件应用准备中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。
6.12.1可执行软件的准备
6.12.2用户现场的版本说明的准备
6.12.3用户手册的准备
6.12.4在用户现场安装
6.13软件移交准备
本条应分成若干分条描述软件移交准备要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。
6.13.1可执行软件的准备
6.13.2源文件准备
6.13.3支持现场的版本说明的准备
6.13.4“已完成”的CSCI设计和其他的软件支持信息的准备
6.13.5系统设计说明的更新
6.13.6支持手册准备
6.13.7到指定支持现场的移交
6.14软件配置管理
本条应分成若干分条描述软件配置管理中要遵循的方法.各分条的计划应遵循合同中论及它的所有条款。
6.14.1 配置标识
6.14.2配置控制
6.14.3配置状态统计
6.14.4配置审核
6.14.5发行管理和交付
6.15软件产品评估
本条应分成若干分条描述软件产品评估中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.15.1中间阶段的和最终的软件产品评估
6.15.2软件产品评估记录(包括所记录的具体条目)
6.15.3软件产品评估的独立性
6.16软件质量保证
本条应分成若干分条描述软件质量保证中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。
6.16.1软件质量保证评估
6.16.2软件质量保证记录、包括所记录的具体条目
6.16.3软件质量保证的独立性
6.17问题解决过程(更正活动)
本条应分成若干分条描述软件更正活动中要遵循的方法.各分条的计划应覆盖合同中论及它的所有条款。
6.17.1问题/变更报告
它包括要记录的具体条目(可选的条目包括:项目名称,提出者,问题编号,问题名称,受影响的软件元素或文档,发生日期,类别和优先级,描述,指派的该问题的分析者,指派日期,完成日期,分析时间,推荐的解决方案,影响,问题状态,解决方案的批准,随后的动作,更正者,更正日期,被更正的版本.更正时间,已实现的解决方案的描述)。
6.17.2更正活动系统
6.18联合评审(联合技术评审和联合管理评审)
本条应分成若干分条描述进行联合技术评审和联合管理评审要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款.6.18.1联合技术评审包括----组建议的评审
6.18.2联合管理评审包括----组建议的评审
6.19文档编制
本条应分成若干分条描述文档编制要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款.应遵循本标准第5章文档编制过程中的有关文档编制计划的规定执行.6.20其他软件开发活动
本条应分成若干分条描述进行其他软件开发活动要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款.6.20.1风险管理,包括已知的风险和相应的对策
6.20.2软件管理指标,包括要使用的指标
6.20.3保密性和私密性
6.20.4分承包方管理
6.20.5与软件独立验证与确认(IV&V)机构的接口
6.20.6和有关开发方的协调
6.20.7项目过程的改进
6.20.8计划中未提及的其他活动
7进度表和活动网络图
本章应给出:
a.进度表,标识每个开发阶段中的活动,给出每个活动的初始点、提交的草稿和最终结果的可用性、其他的里程碑及每个活动的完成点.b.活动网络图,描述项目活动之间的顺序关系和依赖关系,标出完成项目中有最严格时间限制的活动。
8项目组织和资源
本章应分成若干条描述各阶段要使用的项目组织和资源.8.1项目组织
本条应描述本项目要采用的组织结构,包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。
8.2项目资源
本条应描述适用于本项目的资源。(若适用)应包括:
a.人力资源,包括:
1)估计此项目应投入的人力(人员/时间数);
2)按职责(如:管理,软件工程,软件测试,软件配置管理,软件产品评估,软件质量保证和软件文档编制等)分解所投入的人力;
3)履行每个职责人员的技术级别、地理位置和涉密程度的划分;
b.开发人员要使用的设施,包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其他特性;
c.为满足合同需要,需方应提高的设备、软件、服务、文档、资料及设施,给出一张何时需要上述各项的进度表;
d.其他所需的资源,包括:获得资源的计划、需要的日期和每项资源的可用性.9培训
9.1项目的技术要求
根据客户需求和项目策划结果,确定本项目的技术要求,包括管理技术和开发技术。
9.2培训计划
根据项目的技术要求和项目成员的情况,确定是否需要进行项目培训,并制订培训计划。如不需要培训,应说明理由。
10项目估算
本章应分若干条说明项目估算的结果。
10.1规模估算
10.2工作量估算
10.3成本估算
10.4关键计算机资源估算
10.5管理预留
11风险管理
本章应分析可能存在的风险,所采取的对策和风险管理计划。
12支持条件
12.1计算机系统支持。
12.2需要需方承担的工作和提供的条件。
12.3需要分包商承担的工作和提供的条件。
13注解
本章应包含有助于理解本文档的一般信息(例如原理)。本章应包含为理解本文档需要的术语和定义,所有缩略语和它们在文档中的含义的字母序列表。
附录
附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理,附录可单独装订成册。附录应按字母顺序(A, B等)编排。
第三篇:浅谈软件开发需求分析阶段的主要任务_上传
浅谈软件开发需求分析阶段的主要任务
一、问题识别
首先系统分析人员要研究计划阶段产生的可行性分析报告和软件项目实施计划。主要是从系统的角度理解软件并评审用于产生计划估算的软件范围是否恰当,确定对目标系统的综合要求,即软件的需求;并提出这些需求的实现条件,以及需求应达到的标准,也就是解决要求所开发软件做什么,做到什么程度。这些需求包括:
(1)功能需求:列举出所开发软件在功能上应做什么,这是最主要的需求。
(2)性能需求:给出所开发软件的技术性能指标,包括存储容量限制、运行时间限制、安全、保密性等。
(3)环境需求:这是对软件系统运行时所处环境的要求。例如,在硬件方面,采用什么机型、有什么外部设备、数据通信接口等等;在软件方面,采用什么支持系统运行的系统。
(4)可靠性需求:各种软件在运行时,失效的影响各不相同。在需求分析时,应对所开发软件在投入运行后不发生故障的概率,按实际的运行环境提出要求。对于那些重要的软件,或是运行失效会造成严重后果的软件,应当提出较高的可靠性要求,以期在开发的过程中采取必要的措施,是软件产品能够高度可靠地稳定运行,避免因运行事故而带来的损失。
(5)安全保密工作需求:工作在不同环境的软件对其安全、保密的要求显然是不同的。应当把这方面的需求恰当地作出规定,以便对所开发的软件给予特殊的设计,使其在运行中其安全保密方面的性能能得到必要的保证。
(6)用户界面需求:软件与用户界面的友好性是用户能够方便有效地使用软件的关键之一,从市场角度来看,具有友好用户界面的软件有较强的市场竞争力。因此,必须在需求分析时,为用户界面细致地规定达到的要求。
(7)资源使用需求:这是指所开发软件运行时所需的数据、软件、内存、空间等各项资源。另外,软件开发时所需的人力、支撑软件、开发设备等属于软件开发的资源,需要在需求分析时加以确定。
(8)软件成本消耗与开发进度需求:在软件项目立项后,要根据合同规定,对软件开发的进度和各步骤的费用提出要求,作为开发管理的依据。
(9)预先估计以后系统可能达到的目标。这样,在开发过程中,可对系统将来可能的扩充与修改做准备,一旦需要时,就比较容易进行补充和修改。
功能性需求是人们普遍关注的,但对非功能性需求的分析常常被忽视。其实非功能性需求并不是无关紧要的,它们的主要特点涉及到的方面多而广,却容易被忽略,任何一个软件的非功能性需求都要根据其类型和工作环境来确定。
问题识别的另一项工作是建立分析所需要的通信(沟通)途径,以保证能顺利地对问题进行分析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析员通过这种通信途径与各方面商讨,以便能按照用户的要求去识别问题的基本内容。
此外,如果在进行需求分析之前没有做过可行性分析,那么补充完成这部分工作往往是必要的,从问题定义和调查研究入手,与用户密切联系,详细了解问题提出的背景、弄清要解决什么问题,然后从软件系统特性和用户目标出发,做市场调查和现场考察。仔细收集信息之后进行数据分析和功能分析,建立系统的高层逻辑模型,再进一步做成本/效益分析。最后提交一份可行性分析报告,从技术、经济、社会效应等方面论证可行性,以确认软件开发的目标是否可行。
二、分析与综合需求分析的第二步工作是问题分析和方案的综合。
分析员需从数据流和数据结构出发,逐步细化所有软件功能,找出系统各元素之间的联系、接口特性和设计上的限制,分析它们是否满足功能要求,是否合理。依据功能需求、性能需求和运行环境需求等,剔除其不合理的部分,增加其需要部分。最终综合成系统的解决方案,给出目标系统的详细逻辑模型。
在这个步骤中,分析和综合工作反复地进行。在对现行问题和期望的信息(输入和输出)进行分析的基础上,分析员开始综合出一个或几个解决方案,然后检查它的工作是否符合软件计划中规定的范围等等,再进行修改。总之,对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止
常用的需求分析方法有面向数据流的结构化分析方法(简称SA)、面向数据结构的Jackson方法(简称JSD)、面向对象的分析方法(简称OOA)等,以及用于建立动态模型的状态迁移图或Petri网等。
三、编制需求分析文档
在软件开发的瀑布模型中,每个阶段形成的最终文档是阶段完成的里程碑,因而,需求分析阶段编制文档以备下步评审,也是此阶段的重要任务之一。以上已经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说明书。同时,为了确切表达用户对软件的输入输出要求,还需要制定数据要求说明书及编写初步的用户手册,着重反映被开发软件的用户界面和用户使用的具体要求。此外,根据在需求分析阶段对系统的进一步分析,从目标系统的精细模型出发,可以更准确地估计所开发项目的成本与进度,从而修改、完善与确定软件开发实施计划。
四、需求分析评审
作为需求分析阶段工作的复查手段,在需求分析的最后一步,应该对功能的正确性、完整性和清晰性,以及其他需求给予评价。评审的主要内容是:
(1)系统定义的目标是否与用户的要求一致;
(2)系统需求分析阶段提供的文档资料是否齐全;
(3)文档中的所有描述是否完整、清晰,是否准确地反映用户的要求;
(4)与所有其他系统成分的重要接口是否都已经描述;
(5)所开发项目的数据流与数据结构是否足够、确定;
(6)所有图表是否清楚,在不补充说明时能否理解;
(7)主要功能是否已包括在规定的软件范围之内,是否都能充分说明;
(8)设计的约束条件或限制条件是否符合实际;
(9)开发的技术风险是什么;
(10)是否考虑过软件需求的其他方案;
(11)是否考虑过将来可能会提出的软件要求;
(12)是否详细制定了检验标准,它们能否对系统定义成功地进行确认;
(13)有没有遗漏、重复或不一致的地方;
(14)用户是否审查了初步的用户手册;
(15)软件开发设计计划的估算是否受到了影响等。
第四篇:软件开发需求分析[小编推荐]
网上书店系统包括如下基本功能。
用户注册和登录:为用户提供注册、登录、找回丢失密码、修改个人信
息等功能。
图书信息查询及管理:对信息进行灵活的分类、存储,方便用户迅速从
少则几万,多则几十万甚至上百万种图书中找出自己所需图书。
购物车管理:用语存储用户选择好的图书,完成购物后可以自动生成订
单以供管理者进行管理。
订单管理:为用户提供订单查询功能,同时为管理者提供订单查询功能
及处理功能。
后台管理:为管理者提供用户信息查询和销售情况查询等功能。
第五篇:地勘需求说明
地勘需求说明
请地勘单位根据委托方所提供文件资料,根据建筑物特点提出详细的岩土工程资料和设计所需的岩土技术参数。并对地基作出岩土工程分析评价,为基础设计、基坑设计、地基处理、不良地质现象的防治等提供设计参数及建议。
根据《岩土工程勘察规范》(GB50021-2001)2009年版、《天津市岩土工程勘察规范》(DB/T 29-247-2017)等国家及天津市规范、规程、文件的相关规定,本次勘察具体需求如下:搜集附有坐标的建筑物总平面图,场区的地面整平标高,建筑物的性质等资料;勘察范围内应能够涵盖委托方需求的所有建(构)筑物的区域;查明勘察范围内建(构)筑物范围内岩土层的类型、深度、分布规律、工程特性,分析和评价地基的稳定性、均匀性、承载力;对需进行沉降计算的建(构)筑物提出地基变形计算参数预测建(构)筑物的变形特征;查明勘察范围内埋藏的河道、沟浜、墓穴、防空洞、孤石等对工程不利的埋藏物,查明地下原有管线的分布情况;查明不良地质作用的类型、深度、分布范围、发展趋势和危害程度,提出整治方案的建议;查明软土的分布、埋深、厚度及其工程特性,并评价对工程建设的影响;查明地下水的埋藏条件、地下水类型和赋存状态,查明主要含水层的分布规律,提供区域性气候资料;查明地下水的补给、排泄条件、地表水和地下水的补给关系及其对地下水位的影响;提供勘察时的地下水位、水位变化趋势、水位变化幅度和主要影响因素;提供地层渗透性指标,并为降水设计提出建议;判别水和土对建筑材料的腐蚀性;提供场地土标准冻结深度;论证地下水在施工期间对工程和环境的影响,提出抗浮设计水位、最低水位等;提出勘察场地的抗震设防烈度、设计基本地震加速度和地震分组;确定场地类别,划分对抗震有利、一般、不利或危险地段;判定场地埋深20.00m以上饱和粉(砂)土液化情况;根据设计院提供的柱下反力给出可供选择的桩基方案,建议桩基持力层,提供桩基设计所需的岩土技术参数,并估算各桩型单桩承载力,建议桩型及相关施工工艺;提供各地层承载力特征值,对采用天然地基条件的可能性进行评价;进行地基基础评价、基坑开挖支护及降水方案评价、分析地基基础设计及施工中应注意的问题等;对管道线路工程,勘探点布置应严格遵循《岩土工程勘察规范》(GB50021-2001)2009年版中第4.4.8、4.4.9条的相关规定;勘察内容应包含但不限于上述各项规定,其它未尽事宜按国家及地方相关规范、规程要求进行。