张鹏 | 2021软件代码开发技术作业三 | 综合系统开发----需求分析

综合系统开发----需求分析

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/2021Softwarecodedevelopmenttechnology
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/2021Softwarecodedevelopmenttechnology/homework/11968
这个作业的目标	1. 更好的学会软件需求规格说明书的攥写
	2. 掌握统一建模语言（UML）的使用
	3. 掌握领域驱动模型设计分析以及应用
	4. 掌握对 Git 的使用，对整个项目采用增量式更新

ServiceRentalSystem - Github Repo

领域驱动设计模型 - 对需求分析的引导

领域驱动设计（Domain-Driven Design, DDD），其研发过程大致如下：

需求分析 ➣ 领域分析 ➣ 领域模型 ➣ 核心业务逻辑 ➣ 技术细节

领域驱动设计的前提是：

• 把项目的主要重点放在核心领域（core domain）和领域逻辑

• 以领域中的模型为基础，进行复杂的设计

• 让技术人员以及领域专家合作，以迭代方式来完善特定领域问题的概念模型

对本案例的建模分析过程

1.1 定义概念类（领域对象）

首先寻找概念类，得到：

1. 自由职业者：SUPPLYER

2. 客户：USER

3. 服务项目：PROJECT

4. 时间表：SCHEDULE

1.2 定于领域对象的属性以及关联关系

需求规格说明书

一、引言

1.1 定位与目标

计算机技术高度发达的今天，利用信息技术对大量复杂的信息进行有效的管理成为一种普遍而实用的手段。一方面，这极大的减少了簿记和人力的开销，另一方面，现代计算机强大的计算能力和网络的普遍部署，大大简化了大量信息的处理和流动。服务出租系统是一个基于web开发的系统解决方案，可以为自由职业者以及自身员工有效管理客户（自由职业者）及其时间表等；本系统有效解决Excel解决方案无法很好的进行扩展的问题，有效应对多用户的使用场景，提供安全和审计日志。

1.2 对象

本系统的预期读者有：

• 服务出租平台开发经理
• 技术部经理
• 项目组所有成员
• 测试组人员
• SQA 人员
• 开发公司授权调阅本文档的其他成员

1.3 软件需求分析理论

软件需求分析是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求， 建立可确认的、可验证的一个基本依据。软件需求分析是一个项目的开端， 也是项目实施最重要的关键点。 据有关的机构分析结果表明， 设计的软件产品存在不完整性、 不正确性等问题 80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。

1.4 软件需求分析目标

对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需求。了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准。

为软件管理人员进行软件成本计价和编制软件开发计划书提供依据。

软件需求分析应尽量提供软件实现功能需求的全部信息， 使得软件设计人员和软件测试人员不再需要需求方的接触。 这就要求软件需求分析内容应正确、 完整、一致和可验证。此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。

二、需求概述

2.1 项目背景

本项目开发的软件平台名称为《服务出租平台》，项目提出者为广东工业大学计算机学院软件工程专业2018届在读本科生张鹏，该系统独立于其他系统，自成一个完整的系统，应用方便。

2.2 需求概述

问题描述：一家公司提供服务出租，公司自身有一些员工，另外还有很多自由职业者作为服务商存在。公司目前使用Excel工作表来管理他们的客户（自由职业者），时间表等。Excel解决方案无法很好地进行扩展。它无法应对多用户使用的场景，也不提供安全和审计日志。因此他们决定构建一个新的基于Web的解决方案，通过出租服务管理系统实现公司出租服务相关信息的管理以及提供公司信息的安全性。

下面对服务出租平台的设计进行需求分析。

首先，服务是面向特定的某些对象的，比如自由职业者等，因此用户进入系统首先要进行身份验证。用户进入服务出租平台系统后，应该根据自己的需求选择不同的服务进行出租或者接受，所以服务还应该可以被其他人所接受服务。为了区分不同人提供的不同服务，服务在发布的时候应该按照列表进行细分，同时也允许用户根据所需要的不同条件进行筛查。服务应该有实现限制，当某服务长期不被接受时，应该提高其搜索结果权重；到了限定时间后将会被撤销，防止大量死服务，同时也应该允许发布服务出租的人删除自己的服务。

2.3 系统结构

三、系统功能需求

3.1 系统功能预览

3.2 数据流分析

• 0 层图

  

• 1 层图

  

3.3 数据字典

字段 1	默认值	是否为空	数据类型	备注
SID		否	INT(8)	供应商 ID
UID		否	VARCHAR(20)	客户 ID
PID		否	VARCHAR(20)	项目 ID
TimeInfo	1970-01-01	否	DATETIME	时间信息

3.4 实体联系模型

1. 实体及其属性

   实体	属性
   自由职业者	供应商ID，姓名，电话，邮箱，微信号，地址
   客户	客户ID，客户姓名，电话，邮箱，微信号，地址
   服务项目	服务编号，服务类型，发布时间，服务内容
   时间表	时间表编号，自由职业者ID，客户ID，开始时间，结束时间，对应薪酬

2. 实体间联系

   • 自由职业者 与 时间表 1 对 1；

   • 自由职业者 与 客户 n 对 m；

   • 自由职业者 与 服务项目 1 对 n；

   • 客户 与 服务项目 1 对 n;

   • 客户 与 时间表 1 对 m;

   • 服务项目 与 时间表 n 对 m；

3. E-R 图

   

3.5 操作流程图

四、软硬件及外部系统接口需求

4.1 运行环境

1. 本系统对于用户端则是基于 WEB 端，后端提供 HTML 页面以及数据即可。

2. 系统使用 Diango v3.2 快速部署。

3. 后端系统使用较为稳定的 CentOS 7。

4. 数据使用 MySQL v8.0.24。

4.2 硬件需求

硬件	备注
CPU	Intel Xeon Processer
RAM	256GB TLC Memory
DISK	20TB * 2
Proxy	Nginx for reversing local proxy
Ethernet	10GB/s (For syncing data and network resources)

五、可靠性与可用性需求

5.1 性能需求

1. 预期用户峰值为 1000 人次，网络带宽要求 5MB/s * 1000 ≈ 5GB/s

2. 预期前期数据量不大，考虑到用户需要上传图片用于服务说明，需要提供 20TB 存储空间用于存储用户数据。

3. 考虑到本系统不需要过快响应的网络，因此不考虑分布式部署，单服务器前期可以应对网络需求。

5.2 安全性需求

1. 硬盘需要更多冗余，防止单硬盘损坏导致数据丢失；故服务器采用 ZFS RAID Z0 用于存储数据。

2. 单服务器仍不能很好的保存数据，因此数据应该采用异地容灾备份，定时收到数据都通过 rsync 进行增量同步到数据容灾保存服务器。

3. 服务器要防止 DDOS、CSRF 等网络攻击，预防服务器宕机。

4. 用户数据采用 RSA 加密算法，防止用户数据被盗产生不良后果。

六、参考

Domain-driven design - Wikipedia

GB/T9385-2008 《计算机软件需求说明编制指南》

截图

• Github ISSUE

  

  

• cnblogs