功能规格说明书 -TEAM LESS ERROR-CSDN博客

本文链接：https://blog.csdn.net/czl_yt/article/details/124237887

项目	内容
这个作业属于哪个课程	课程社区的链接
这个作业的要求在哪里	作业要求的链接
课程任务	制定团队软件工程功能规格说明书

功能规格说明书

纵览

说明问题

本说明书将说明如下几个大问题：

- 讨论的范畴及界限
- 用户和典型场景
- 该说明书中涉及到的术语
- 边界条件及软件功能的应变方式
- 系统的各种功能
- 产品目标
- 软件发布后的数据采集问题

范畴及界限

本说明书讨论的范畴仅限于对产品相应的规划，界限在产品规划内容与非产品规划的内容之间。

术语

本部分将以字典序解释出现在说明书中的术语

简写	英文全称	中文	含义解释
α	alpha	阿尔法	希腊字母中的第一个小写字母，在本说明书中alpha版本指第一代版本
app	application	应用程序	可以帮助用户完成某些功能的软件
β	Beta	贝塔	希腊字母中的第二个小写字母，在本说明书中Beta版本指第二代版本
无	chrome	谷歌	chrome中文意义是铬合金，但在本说明书中指代为谷歌浏览器
无	default	默认	在本说明书中即为默认的意思
DDL	deadline	截止时间	规定时间恰好用尽的时刻即为截止时间
EP	Event-based Plan	计划	基于某项事务来进行安排的规划，如工作日的工作安排
无	GitHub	无	GitHub是一个面向开源及私有软件项目的托管平台，因为只支持Git作为唯一的版本库格式进行托管，故名GitHub。
PPT	PowerPoint	幻灯片	分页展示的文档，可以图文并茂，有一定的视觉效果，能更好地表达出创建者想表达的意思
QM	Quick Memo	速记	迅速记录下某项事务
QT	Quick TODO	无	迅速记录下某项待做事务，与QM一致
无	Robust	鲁棒性	鲁棒是Robust的音译，也就是健壮和强壮的意思。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓"鲁棒性"，是指控制系统在一定(结构，大小)的参数摄动下，维持其它某些性能的特性。
list	todo list	无	一款用于记录管理代办事项的应用程序
无	to-do list	无	待做事项列表
无	web	网	web的本意是蜘蛛网和网的意思，在网页设计中称为网页的意思。现广泛译作网络、互联网等技术领域。表现为三种形式，即超文本(hypertext)、超媒体(hypermedia)、超文本传输协议(HTTP)等。

用户和典型场景

该产品的用户是什么样的？

用户分为哪几类？

每一类用户

分别具备什么样的特征（注意是用户本身的特征）？例如年龄、性别、职业、目标或其他特征等
潜在总量（即确有需求使用本产品的用户总量，但请注意，潜在用户未必实际上使用本产品）分别有多少？占总潜在用户量的多大比例？
使用习惯是怎样的？例如会在什么时间，什么地点，什么样的方式，什么样的频率，使用哪些功能等
对产品的期望是怎样的？希望本产品可以帮助用户达到怎样的效果？
愿意为产品付出多少代价？例如是否愿意为一些功能付钱，可以接受以什么样的方式（买断、月付、年付、按量付等）付多少钱等

	特征	潜在总量(万)	使用习惯	期望	接受代价
A	大学生	260*30%以上	每周，每天学习计划	管理学习任务	接受主体功能免费，会员功能平均每月不超过5元；接受10元内的买断
B	在职	240以上	每日工作/生活计划	管理生活/项目	主体功能免费，会员功能平均每月不超过15元；接受30元内的买断

该产品的典型应用场景是什么？
1. 应用场景分为哪几类？
  
  学习/工作计划
  
  生活安排
  
  杂事提醒
2. 每一类应用场景下
  1. 分别会包含哪一类或几类用户？
    
    A,B都会涉及所有功能
  2. 系统以什么样的方式为各类用户提供服务？
    
    服务：
    - 速记 Quick Memo：迅速记录待办事件，如突然接到的通知
    - 计划 Event-based Plan：针对某个事项的待办，如针对某一科的作业、考研的具体复习任务等
    方式（视图）：
    - 总视图：以天为单位显示两个功能下在这一天的所有任务
    - Quick Memo 速记视图：所有速记待办事件
    - Event-based 计划视图：事项列表，每一个事项列表下可以有n个常规计划和速记待办事件，可选按照DDL或优先度排序或智能排序或时间块排序
  3. 系统所提供的业务会让用户与用户之间产生什么样的关系？
    
    考虑在Belta版增加一个社区分享或者打榜的的功能。用户之间可以互相督促鼓励打卡计划等，也可以分享自己的计划安排。
  4. 可以给置身其中的各类用户带来什么样的好处？产生什么样的感受？
    
    用户对事项定时提醒或标注，防止遗忘；合理分配对自己代办事件的处理时间；直观了解自己处理事项的进度；软件提供了丰富的计划样式，可供用户自由选择及使用，让用户充分发挥自己的想象；同时，我们提供扫描识别图书目录自动导入并生成计划表来服务与一些特定群体。当然，也有其他好用的功能供用户探索。
3. 为了更加直观，在详细阐述应用场景细节的基础上，可以考虑用类似“讲故事”的方式进行应用场景的叙述
  
  小p是个大学生，正在准备12月的考研。这天早上，小p去图书馆打算进行一天考研的复习，他带着各科的书本，但没有想好应该先复习哪科，就随便挑了一本书看了起来；然后，他发现忘记自己昨天看到哪一页了，只好翻查自己的笔记开始回忆；下午，有同学问他，要不要一起去做核酸，他才想起自己预约了今天的核酸，差点没有错过；他又急忙打开微信群，翻找几天之前的聊天记录，看相关的注意事项；回来后，他发现自己看这一个学科看的太久，没有合理地安排其他学科的复习。
  晚上，小p复盘起这一天的生活，觉得自己安排的十分混乱，好像自己的时间并没有掌握在自己的手里，他突然想起同学说的todo list app就想要下载试用一下，他在睡觉前先用一点时间在app上拍照上传了考研复习书的目录，规划了第二天的复习计划。
  第二天，小p按照自己之前的计划进行复习，到了指定的时间，app提醒他应该进行下一个学科的复习了。中午，微信群里又有信息，要进行xx竞赛的报名，小p赶紧打开app，将此事记录在临时事项中。
  进行完一天的学习，小p将临时事项转到日程安排中，并在旁边附上了相关附件；他又根据今天的学习进展将进度条增加了一点，看着进度的推进，非常有成就感。
  
  小w是个打工人，就要年终了，小w依旧差点迟到。来到办公室，整理下桌面，打开水杯，起身前去茶水间，这时候碰到了同事，跟小w吐槽了很久最近年终不停的加班，小w猛然想起今天的总结还没开头，于是回到了工位，端着杯子坐下压了一口水，顺手打开了朋友圈，哦，同事们也在写总结呢，再检查回复下邮箱吧…终于开始写总结了，想了一小时，同事过来问小w中午打算吃啥，写到哪里了，一起去接个水吧…回来后老板突然叫小w去汇报进度，并让他下午送个资料过来，小w也不能说明自己清楚到底做了多少还差多少，老板面色阴沉…回到工位，距离吃饭还有十来分钟，又还能做什么呢…一个早上被白白浪费。下班了，小w顺路随便买了点东西回家。终于是属于自己的时间了，便开始刷视频看热搜…不知不觉夜深了，小w突然懊悔自己还是应该多看书锻炼一下而不是玩手机，哎算了还是太晚了去洗漱休息了吧，啊，忘了买牙膏！第二天因为睡得太迟了错过了闹钟，又因为昨天老板实在觉得小w汇报得莫名其妙，让他送的东西也没送过来，于是把小w大骂一通。
  
  痛定思痛，小w决定用todo list管理时间。划分了自己工作的总体内容以及子任务，写下来自己想要在休闲时间阅读锻炼的计划，近期需要购置的物资…同事想找自己聊天，小w的手机界面提醒自己这会儿是该写哪部分总结了，DDL是多久，于是小w马上结束对话，高效利用了上班时间。中午吃饭的时候主任让小w明天帮他检查一遍PPT，他立刻把PPT记录在了list附件中，回到家中，todo list提醒自己是时候看看书锻炼培养自己的兴趣爱好了。完成了一整天的安排，打开周计划和月计划总视图，小w看着自己各项任务的进度条，打卡计划完成情况，满满的成就感~

边界条件限制

用户数量

我们的待办事项软件主要的功能是偏向单机的，所以在这方面，用户数量不应该对软件运行造成任何负面影响。云同步的功能，随着用户数量的增长可能会出现问题。对于用户数量而言，我们计期待用户数量为n，则不妨设置最大的用户数为2n。如果超过限制，我们会限制用户的登录，并进行警告信息的弹窗设置。

集中度限制

本产品的业务高峰应该在于多用户的同时登陆、同步。本产品预估的业务高峰限制应该为300-500，在超过承受范围时导致的同步错误等，应该反馈给用户相关的警告信息，提醒用户注意待办事项的录入。

web页面相关

我们的软件本身不涉及web层的应用。在发布界面也许会再设计一个web提供下载，并主要支持chrome。在编码时注意default信息的填写，对于不支持的浏览器显示default信息。

其他

当下总的quick memo和待办事项录入不建议超过500.在超过信息边界时，可能会提供警告信息，并且限制用户无限制地录入待办事项的行为。

系统功能

核心功能

Quick Memo

此功能对用户提供一个即时记录事项的功能，可以用来记录突然接到的通知或安排、作业等，可以认为是一个备忘录，也可以转成一个待办事项。

对应应用场景：生活安排

Event-based plan

以事件主题为基准的待办事件列表。用户录入的待办事项可以以核心事件为基准进行分类梳理，如某一科的作业可以以该科为核心事件，收录在以此为主题的清单下；考研的任务可以以“考研”为核心事件，收录在“考研”清单中等。

对应应用场景：学习/工作计划

总视图

以天为单位对当前所录入的所有任务进行整理，并给出视图，我们成为“总视图”。它可以为用户直观地展示当天有何规划内容。

对应应用场景：

辅助功能

排序

在对待办事件的排序上，我们有截止日期和优先级两种基本的基准。-以截止日期为基准，则按照事件距离截止日期的时间从小到大排序；以优先度为基准，则需要根据用户提前设定的事件的优先级，按照优先级从高到低排列。如果优先级相同则把等级相同的事件按字母序排序。根据这两个基准，我们还可以给出一种智能排序，对截止日期和优先级两个基准进行权重赋值，给出对事件在该权重下计算出的排序。

对于quick memo的事件来说，排序应该根据该事件录入的时间排序，越新录入的越排在上方，强调“备忘录”属性。

图像识别录入

如果技术可以实现，我们会提供图像识别模块，可以让用户通过上传照片供本软件识别，比如书籍的目录，从而不用再让用户手动输入。录入目录的功能对于考研的同学来说具有一定的便捷性，因为同学很有可能需要对一本书的内容进行规划，而以目录为导向进行复习规划是比较合适的。

提醒

通过用户对于事项的定时提醒或者标记，实现提醒操作，防止用户遗忘。

功能之间的关系

quick memo <-> event-based plan

quick memo的事项可以经过一定的处理（如标记优先级等）转入event-based plan。根据实用性判断，我们不提供event-based plan的事项转至quick memo的功能。

event-based plan & quick memo <-> 排序

该视图下的事项展示顺序依赖于上述提到的辅助功能——排序。

event-based plan <-> 图像识别录入

图像识别录入的功能主要依附在待办事件模块上实现。图像识别录入的结果作为待办事件新建清单的输入，他们之间应该保持一致性。

event-based plan <-> 提醒

在这个视图下的事项应该具有提醒的开关。提醒功能依赖于每个事项的提醒开关属性以及提醒种类数据，对用户进行提醒操作。

event-based plan <-> quick memo <-> 总视图

总视图的数据就是 event-based plan 和 quick memo的总和。即总视图的数据依赖于这两个分视图的数据，他们之间应该保持一致性。

可能存在的问题/副作用

初始界面

目前我们应该默认总视图是打开app的默认界面。而用户对于初始界面的选择有一定的需求。我们也许会增加初始界面的选择功能。不过这一功能是否实现可能需要经过alpha版本的反馈。

“智能排序”的实用性

智能排序给予了用户赋予权重的自由度，这可以说是一个亮点。但是这个功能是否会具有足够的吸引力，我们还是需要经过用户的反馈才能得到。

图像识别录入的鲁棒性

我们可能不会自行设计出图像识别的算法，而是使用开源的识别代码。这一功能可以算是一个亮点，但是通过利用开源代码，对于测试和修改来说都可能有一定的难度。我们会通过争取多地搜索好的开源接口，并加以团队对于图像识别相关知识的学习，尽可能实现好这个功能。

UI设计

从左到右依次是总视图、QuickMemo视图和Event-Based视图

期望目标

实现功能和效果

我们要做成的是一种to-do list的待办事项簿，主要的功能分为速记和计划。

速记 Quick TODO

紧急的任务，突然收到的通知以及一些突发事件的记录
计划 Event-based Plan

对针对性的事项划分出一个任务集，在这个任务集里面可以创建，修改，删除任务，当所有任务都完成时该计划也就结束了。如期末时对考试做出的一系列复习任务等。
设置

用户可以对速记事项或者计划中的任务进行基本设置。如添加开始和截止时间、修改当前任务的优先级、填写参与人、地点等基本信息。

为了给用户更好的体验，我们给用户提供了多种视图查看方式以及一些辅助功能。