SVN需求文档的完善

今天下午做了SVN需求文档的完善的工作,重新导入了office的目录,并且完善了软件功能说明,登录注册模块,上传文件模块,下载文件模块,同步服务器下载模块。

软件功能说明加入了图片,介绍了我们的SVN的大概的功能流程。

然后下面是一个个的小模块:

每一个小模块都分为了客户端和服务器两部分。

但是客户端不是我做得,是我的队友做的,我做的是服务器的部分,我就发我做的服务器流程图吧。

登录注册模块,服务器流程图:

下面有一段简述概括的话:客户端访问服务器要先登录注册,注册信息记录到服务器,然后登录验证,等待服务器反馈,验证失败就退出,成功就进入系统。

上传文件模块,服务器端:

服务器上传文件模块:等待客户端的上传请求,发送反馈信息,等待客户端发送文件名,接收文件名后再次发送反馈信息,准备接收客户端文件,接收文件后,更新服务器列表,结束。

下载模块,服务器端:

服务器下载流程图:接收客户端访问请求文件列表,发送服务器列表给客户端,接收服务器的下载请求,发送文件给客户端。

同步服务器下载模块,服务器端:

服务器同步模块:服务器处理下载和上传文件后,对下载文件对象的文件下载数加一,上传文件创建一个文件对象,记录文件信息,然后更新服务器列表内容,发送给客户端,结束。

这些就是我的SVN需求文档的完善,服务器端的。

—————————————————————————

刚刚因为用复制粘贴没上传图片,所以图片没弄上去,现在重新上传了。

时间: 2024-07-31 09:14:27

SVN需求文档的完善的相关文章

小白如何写需求文档

上学期在跟着网站里的学长学姐学了许多东西,假期我们需要自己做一套网站签到OA出来,昨天刚刚把需求文档定下,万事开头难,我把迈出的第一步记录下来,也给第一次写文档的小伙伴一些建议. 第 一次写,难免无从下手,在网上查找了大量的需求文档范例,网上也有模板,不过模板上东西很多,有些我还并不太了解,也不太适用于自己我们要做的OA. 既然是需求文档,那就应该根据项目实际情况去写文档,所以我们在写文档时注重的是我们需不需要,而非和模板是否符合.接下来,是我们写文档的步骤. 1.定框架 首先要把整篇文档需要的

产品需求文档的学习记录(一)

PRD是英文Product Requirement Document的缩写,中文的意思是产品需求文档,具体的名词介绍大家可以询问Google.PRD文档是基于BRD.MRD的延续文档,主要用于产品设计和开发使用,因此阅读这份文档的人群绝大多数是设计与技术人员.在这类人群中,设计师更多依赖于原型进行交互或视觉的设计,因此看这份文档的人就会偏向于技术人员.相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是

产品需求文档(PRD)的写作方法

无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过四篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前四篇文章进行整体的摘要介绍,帮助大家快速了解写作流程. 产品需求文档(PRD)的写作 四篇章:1.写前准备(信息结构图)2.梳理需求(产品结构图和用户流程图)3.原型设计(手绘原型,灰模原型,交互原型)4.撰写文档(PRD文档)5.用例文档(UML用例图.流程图) 1.写前准备(信息结构图):http://tangjie.me/blog/52.h

产品需求文档的学习记录(三)

我们通过思维导图将想法进行了结构化梳理,接下来我们就需要进行方案的可行性推演,验证产品功能是否可行,预估项目要花多少人力物力,因此我们就要通过原型设计进行相关需求的论证.一开始就撰写PRD文档,我们很难对产品进行各方面的评估,也无法得知方案的可行性,并且无法直观细致的考虑产品. 原型设计是帮助我们更细致的思考,并做各项需求的评估,同时也是将自己脑海里的想法进行输出,通过原型设计后,我们就可以进行产品宣讲了.相对于之前抽象的文字描述,原型则更加清晰产品的需求,设计和技术人员或者老板也能够更加直观的

产品需求文档的学习记录(四)

前三篇文章我们逐步梳理了产品的信息结构.框架结构.界面结构(原型),这一步我们就要根据之前完成的工作,开始正式撰写产品需求文档了(PRD文档). 通过之前的准备工作,我们更加清楚了产品的需求,并细致的考虑了方案的可行性,从而减少与避免了撰写文档时容易忽略的细节黑洞. PRD文档没有标准的规范,也没有统一的模板,每个公司都不一样,并且每个人也不一样,这个取决于个人习惯和团队要求.虽然PRD文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录.文档在撰写过程中,我们可以自行不断的修改

从零到一:需求文档

加入一个项目组:开始开发一个全新的模块.对于开发流程,我有一点自己的理解,现在先记录下来,在以后的工作中觉得有什么不妥的地方,就做相应的改进. 第一步:需求文档,每个项目开始都应该有相应的需求文档.需求文档是重中之重,以后所有的工作都是围绕需求文档来的. 需求文档应该由产品经理与客户直接沟通,依据客户的需求整理而成的需求文档(个人觉得能否挖掘出客户潜在的需求或明确客户需求,设计出完全符合客户的需求文档是重中之重,否则就会衍生出一系列需求变更的问题) ------->输出:需求文档(第一阶段的需求

app开发需求文档怎么写

我们在开发app前都会做需求分析,这个app开发需求文档怎么写呢?一般可以从这几点入手:确定APP方案的目标,APP方案的受众分析,APP开发方案功能设计,APP的操作系统说明方案,APP是是否是原生APP,APP方案的视觉设计,APP开发方案中的其他细节.以下是一个app开发需求文档模板,里面写清了app开发需求说明,可以参考 1.引言 1.1目的: · 阐明开发本app的目的:  1.2 项目背景 · 标识待开发app产品的名称.代码:  · 列出本项目的任务提出者.项目负责人.系统分析员.

第一次担任项目经理从零开始架构自己的网站(二) 需求文档定稿,开始建表,建库

今天上午的半天时间,我们开发部一直都在和产品部门开会,扯皮.吐槽.最终砍掉了几个功能.产品的小姑娘对我说,你们第一期就做一个挂号支付的功能,后台就10几个页面,大多数是增删该查,还说22天不够用??听到这话之后我也没有反驳.产品和程序猿的故事说也说不清楚.会议上老板宣布加班没有加班费,纯属义务,说是在项目完成之后可以多发点项目奖金,我听到这话之后只能呵呵了.下图是我们开会的场景.最终定稿的需求文档和原型图我已经上传到了昨天那个地址.有兴趣的朋友可以下载.开完会后我们大家又看了一会需求文档.准备下

需求文档可以不签字吗? 之一

在软件开发中,需求分析和需求管理一直被认为是软件开发成功与否的关键.在CMMI中,需求管理是CMMI2级的过程域,需求开发是CMMI3级的过程域.在瀑布型生命周期当中,安排了需求分析阶段,一般也安排需求分析里程碑评审.瀑布型生命周期存在了很多年,曾经几度写入到软件开发的国际标准.国家标准当中. 由于瀑布型生命周期如瀑布般顺流而下,在设计阶段开始后,根据需求文档的结果来开展工作,要求需求文档的结果比较清晰.稳定.所以对于需求确认,往往地采用签字的方式,希望各方慎重.全面.充分的确定需求. 签字确认