| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10769 |
| 这个作业的目标 | 完善好分析模型，思路设计 |
| 作业正文 | 如下 |
| 其他参考文献 | 百度 |
《可可爱爱没有脑袋》 项目需求分析模型
成员介绍
| 学号 | 姓名 | 博客地址 |
| 20177703 | 罗剪梅 | https://www.cnblogs.com/sweetsecret |
| 20177697 | 许思慧 | https://www.cnblogs.com/mao-liu/ |
| 20177730 | 袁瑞 | https://www.cnblogs.com/Iwannseeyouagain |
| 20177702 | 周海涛 | https://www.cnblogs.com/zht6 |
| 20177704 | 陈怡涛 | https://www.cnblogs.com/chenyitao/ |
| 20177657 | 刘智鑫 | https://www.cnblogs.com/liuzhixin599445/ |
一、非功能性需求
非功能性需求：指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。一般不会在用户的业务需求中进行明确的提出，需要分析人员根据实际业务需要进行调研归纳。
非功能性需求：是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性
（针对我们所需要完成的软件进行了非功能需求分析）
（1）性能需求
用户数：用户数要考虑用户数的增长情况，有以下指标：总用户数、峰值在线用户数、峰值并发用户数、平均在线用户数、平均并发用户数。
吞吐量：系统交易量的估算。
数据存储量：每年的数据存储容量及未来几年该数量的预期（增长）值。指标包括累计存储容量、年增长。
用户可以拥有约拍、私聊、分享自己的照片成果、发布朋友圈动态、接单等功能完成性能需求
（2）可靠性需求
用户在软件失效的频率、资源约束、外部接口等方面的要求或期望，包括：用户在软件响应速度、数据库保存约束。
用户对软件质量属性、运行环境，以及故障可预测性等方面的要求。
（3）易用性需求
易理解性：与用户为人质逻辑概念即其应用范围所花的努力有关的软件属性。
易学习性：与用户为学习软件应用所花的努力有关的软件属性。
易操作性：与用户为操作和运行控制所花的努力有关的软件属性。如带首字母筛选功能的下拉列表等。
界面简单明了。共有三个大界面，浏览页面，个人资料界面，聊天界面。
操作简单，功能明了。浏览主页面，查看摄影师的资料和他发出的摄影作品，之后与心仪的摄影师发起私聊，聊天界面会显示聊天对象和里面的内容。下单之后可在个人资料界面看订单
这样可以使得用户使用更加容易轻松。
（4）可保障性（supportable）需求
运行环境约束、严重程度、易恢复性、私密性等方面的要求、美观性。
（5）安全性需求
一般用户进行身份验证，需要填写手机号码。
摄影师进行身份验证，需要身份证信息和手机号码。
本软件需要手机打开权限，包括位置信息存储空间等权限。
在软件中用户的订单，身份真实信息，聊天内容等为私密内容，除本人账 号外无法得知。
用户在身份认证、授权控制、用户权限、动态口令、数据库字段加密等
（6）可移植性
适应性、 易安装性、 遵循性、 可替换性等
二、功能性需求（以图文结合的方式进行描述，不能只有图片没有文字说明）
第一次团队作业：https://www.cnblogs.com/Iwannseeyouagain/p/12727968.html
项目描述
一个关于摄影的App.
我们对于这 款软件的最初设想就是，让一些摄影技术好的用户来帮助需求者 拍照。而不仅仅限于那些专业的摄影师。让需求者下单，可以满足需求者的人呢接单，然后完成一次合作。像那些摄影技术好，但是又不是专业摄影师，他们可以用满足一下自己的爱好，同时获得报酬。而需求者呢，得到美美的照片。这是一个双赢的过程。比如在我们学校里。拍照技术好的同学就可以把摄影作为副业，赚取一点自己的生活费。想拍照的同学呢，可以不用花那么多钱，也可以拍的好看的照片。这是我们对于软件的一个基本功能的设想。如果能力达到的话，还会有分享图片，学习摄影等等其他功能的实现。
我们想做这个项目的原因呢，就是根据我们平常在校生活时的感受，像朋友生日、参加活动，聚会时等等，自己拍照技术不行，又想留下美美的照片纪念的时候，就特别想有拍照技术好的人来帮我们拍照。因为我们大多数的大学生的经济条件还是很有限的，家庭条件好的只是少数。有很多同学都是平时做兼职来维持生活。 像您说的那些平台上面的商家，请他们来帮忙摄影对我们学生来说，费用还是比较昂贵的，我们平时也不舍得花这么多钱来拍照。有的店铺还会有一些隐形的费用，所以平常联系摄影师还是很不方便的。这款软件就是用来解决于需求者与摄影师之间联系困难的问题。
改进过后的：
1、需求说明
我们团队是想开发一个针对我校学生摄影约拍的一款软件。
随着现在物质生活的饱满，人们越来越追求精神需求。尤其是刚刚成年，喜欢新奇事物的大学生们，他们追求精神上的满足远大于其他年龄段。
摄影，其实在大学生中是个很吃香的技术。人人都追求美，而摄影就是一门发现美的技术。所以很多大学生都很希望，自己会摄影，又或者身边有会摄影的小伙伴，从而来拍摄很多美美的照片。然后并不是所有人都会专业的摄影，身边也有技术很强的摄影小伙伴的。此时就需要一款摄影约拍的软件，帮你找专业又或者技术很强的摄影师。
对于我们这款软件，主要的用户大致分为两种：摄影师和一般用户（包括想要找心仪的摄影师下单约拍的顾客和体验APP的游客）。
摄影师的需求：1、想从摄影中赚取工资
2、锻炼自己的摄影能力但平时没有模特
一般用户的需求：1、没有强的摄影能力，寻找摄影师拍摄大片
2、经济不足，请不起摄影室的摄影室。
3、集体活动，需要有摄影室跟拍
第二次团队作业：https://www.cnblogs.com/mao-liu/p/12780324.html
改进了增加用例描述和用例图的改进：
（只提出了部分用例描述和用例图）
第三：顺序图和分析类图
1、查询信息资料：
1、用户成功登录系统
2、进入个人或他人信息页面
3、浏览页面
用户通过边界类（用户资料界面）发出查询信息请求到控制类（资料查询服务）控制查询请求通过实体类实现操作并返回。
2、修改信息资料：
1、用户成功登录系统
2、进入信息资料修改页面
3、修改个人资料
4、点击确定，修改完成
用户通过边界类（用户资料界面）发出修改资料请求到控制类（资料修改服务）进行控修改资料后通过实体类返回结果。
3、导出资料：
1、管理员登录系统后台页面
2、查询相关用户的平台信息资料
3、成功找到相关用户并导出用户资料
管理员打开边界类（系统后台界面）发出导出资料到控制类（信息维护服务）进行控制导出资料通过实体类返回结果。
查询信息：
1、管理员登录系统后台页面
2、查询相关用户的平台信息资料
3、显示相关用户的平台信息资料
管理员打开边界类（维护后台信息界面）打出查询用户信息请求到控制类（资料查询）进去控制查询请求到实体类查询返回结果
注销用户资料：
1、管理员登录系统后台页面
2、寻找相关用户的账号资料
3、注销相关用户的账号
4、保存后关闭后台页面
管理员打开边界类（后台维护信息窗口）发出注销用户资料请求到控制类（用户资料注销）控制注销请求到实体类进行注销返回结果
动态删除：
1、 管理员登录后台数据库
2、 管理员删除不正当或违规行为动态
3、 点击确定完成管理员用户的删除，数据库进行保存
4、 删除成功后退出数据库
管理员打开边界类（后台维护信息窗口）打出删除动态请求到控制类（删除动态）控制删除请求到实体类实现请求删除动态返回结果。
查看动态：
1、一般用户登录个人账户
2、进入动态页面
3、查看摄影师所发布的动态内容
用户打开边界类（动态显示界面）发出查询请求到控制类（查询动态）控制查询请求到实体类实现查询返回结果
点赞动态：
1、一般用户登录个人账户
2、进入动态页面
3、在摄影师已发布的动态下面点赞
用户打开边界类（动态显示窗口）发出点赞请求到控制类（动态点赞）控制点赞请求实体类实现操作并返回结果
评论动态：
1、一般用户登录个人账户
2、进入动态页面
3、在摄影师已发布的动态下面评论
用户打开边界类（动态显示窗口）发出发布请求到控制类（发布动态）控制发布请求到实体类实现操作并返回结果。
私聊摄影师：
1、一般用户登录个人账户
2、进入动态页面或个人资料页面
3、点击私聊与摄影师聊天
用户打开边界类（摄影师平台窗口）发出私聊请求到控制类（信息平台服务）控制私聊请求到实体类操作创建一个新的对象更新交流信息。
发布动态、修改动态、删除动态
发布动态：
1.摄影师登录系统
2. 进入个人主页
3.发布动态
摄影师打开边界类（动态维护窗口）发出发布动态请求到控制类（动态发布）控制动态发布请求到实体类完成操作并返回结果
修改动态：
1. 进入个人主页
2.找到已的发布动态
3.修改动态。
摄影师打开边界类（动态维护窗口）发出修改动态请求到控制类（修改动态）控制修改动态请求带实体类进行实现操作并返回结果。
删除动态：
1. 进入个人主页
2.找到已的发布动态
3.修改动态。
摄影师打开边界类（动态维护窗口）发出删除动态请求到控制类（ 动态删除）控制删除动态请求到实体类实现操作并返回结果
订单查询：资料修改：取消订单：
订单查询：
1.用户打开搜索
2.打入搜索所需条件和要求信息
3.点击确定，完成搜索
4.得到订单信息进行浏览
用户打开边界类（订单窗口）发出查询订单请求到控制类（订单维护服务）控制查询订单请求到实体类完成操作并返回
资料修改：
1.用户打开订单信息
2.打入所需修改条件
3.点击确定，完成修改
4.修改订单信息后进行浏览
用户打开边界类（订单窗口）发出修改订单信息请求到控制类（订单维护服务）控制修改订单请求到实体类实现操作并返回结果
取消订单：
1.用户打开订单信息
2.点击取消订单信息
3.点击确定，完成取消
4.取消订单信息进行浏览
用户打开边界类（订单窗口）发出取消订单信息请求到控制类（订单维护服务）控制取消请求到实体类实现操作并返回
资料删除：
1.管理员登录系统后台页面
2.搜索过期的资料信息并点击删除
3.点击确定，完成删除
4.删除资料信息并查看是否在该资料库存在
管理员打开边界类（维护资料窗口）发出查询订单资料请求到控制类（订单查询）控制订单查询请求到实体类实现操作并返回边界类发出删除订单信息请求到控制类（订单删除）控制删除订单请求到实体类实现操作并返回
查询注册用户信息：
1.管理员登录系统后台页面
2.点击查询订单
3.点击查询订单双方资料
管理员打开边界类（维护信息窗口）发出查询注册用户信息请求到控制类（注册用户信息查询）控制注册用户信息查询请求到实体类完成操作并返回结果
查询订单信息：
1.管理员登录系统后台页面
2.搜索订单信息并点击查看
3.点击确定，完成查看
4.浏览该订单信息
管理员打开边界类（维护订单信息窗口）发出查询订单信息请求到控制类（后台订单信息查询）控制订单信息查询请求到实体类实现操作并返回结果
导出信息：
1.管理员登录系统后台页面
2.搜索订单信息并点击导出
3.点击确定，完成导出
4.浏览该订单信息导出
管理员打开边界类（维护订单信息窗口）发出查询导出订单信息请求到控制类（订单平台服务）控制查询导出订单信息请求到实体类实现操作到辅助类查看返回控制类（订单平台服务）控制导出订单信息请求到实体类实现操作导出订单信息返回结果。
分析类图
