毕业设计系统需求分析-“大楼要有高低层、单双号电梯，要抗7级地震”-04

有一座建筑，主楼88层，高度达到了420米，一共有79台电梯，能抗7级地震，88层观光厅对外开放，游客可以体验“云中漫步”。想一想这是那座建筑？

我来说答案吧：

它就是入选2019上海新十大地标的“金茂大厦”，到这里你可能有疑问了，作者啊，你是不是写错主题了，毕业设计的文字，你跟我们讲建筑物。其实，这里是为了说明“金茂大厦”在建设之初的需求，这赫赫有名的金茂大厦，它的高度、抗震级别等等，这些可以量化的指标，就是建设它之前的需求。

再举一个例子，最近电商业务非常火爆，你的老板也想做一个电商系统，商家可以通过营业执照，创建商铺，加入你们的电商系统中。在这里，这个电商系统要实现的功能，就是需求，准确来说是功能需求。

闲话少叙，回到我们的毕业设计，那毕设中的系统的需求分析怎么写呢？

其实，毕业设计中的系统需求分析相比软件工程中的需求分析，简单多了，只需要从一个简单维度，写一写“功能需求分析”和“非功能需求分析即可。但作为撰写毕业设计的你，可能有点难，别急，下面我会手把手教你写！

安装软件

相信你已经看到了上面的局部脑图，所谓“工欲善其事必先利其器”，这里我列举了四款软件，只需要会用一款就够了。挑一款你熟悉，如果都不熟悉，我推荐使用VScode+draw.io插件，因为免费！具体如何使用，我会在后续的“毕业设计实战视频教程”中详细说明。

功能需求分析

所谓功能需求，就是你的课题要实现哪些功能，在论文中一定要详细描述。

举个例子：大部分系统都有用户登录和注册功能，这个没错吧。注册的时候，我们可以手机短信验证码直接注册，还可以账号密码的形式进行注册，也可以通过微信、微博、QQ等第三方认证的方式进行登录与注册，这也是近几年网站流行的登录并注册的方式，拿微信扫码登录来说，第一次微信扫码，后台其实是注册+登录，之后的扫码只是登录。

对于我们毕业设计，只写账号密码注册、账号密码登录就足够了，也只能用种方式。因为手机验证码、微信等第三方登录，需要企业资质才可以申请，个人无法申请。

那要详细描述账户密码注册与登录，怎么展开呢？告诉你个套路，你可以去一些大的网站，比如某宝、某东，实际注册试试，你在注册它们网站的时候，有什么体会，然后把它们的功能大概写一写，融入到自己的毕设中。我举个例子，好多网站要求用户名，必须6位以上的数字或字母，同时要求在20位以内，密码要求有数字、大写字母、小写字母、特殊字符，少一样都不行。

其实这就是详细的功能需求分析，将用户的注册和登录功能进行详细描述。“我们要将用户的注册和登录功能做成这样...”。

“一图胜千言”，论文里面很多地方少不了图，文字+图的形式，更为丰富了你的论文。那需求分析适合用什么图呢？

在软件工程-面向对象需求分析-用例分析中，用例用来描述系统的功能，UML中的用例图是以图示的形式描述用例，那我们的需求分析，用例图来展示，最好不过了。有的毕业设计将用例图放在了设计、实现中，更甚至有的放在了测试中，我觉得是不恰当的做法。

我之前遇到了这样的情况，当时给一位研究生做毕设指导，他将用例图也放在了系统需求分析中，按道理来说是没问题的，但是他的导师说用例图要放在系统设计中，这同学就找上我了。我跟他这么解释：“面向对象的分析、设计、实现，其实是没有明显界限的，你导师这么要求，本质上来说没错，但最好不这么做，既然他要求你这么做，你听导师的。”

通过这个例子，我也顺便提一句，我们写毕业论文，是为了毕业，不要跟导师争论谁对谁错，按导师要求来，即使你认为导师的说法不够恰当。

那用例图怎么画呢？

首先明确下用例图的概念，软件工程中，对用例图的解释为“用例图描述一组用例、参与者及它们之间的关系。”，参与者，可以是人、事物等等。

在上一小节中，我们已经安装了软件，这里展示一下，我在某毕设需求分析中画的用例图。这里我使用的软件是“宇宙第一编辑器” VS Code + 插件draw.io，软件和插件都是免费的。

这里画图没什么难的，根据你的课题功能或者需求分析，甚至你的毕业设计来自已有的系统，将系统的功能一个个画上就可以了。

细心的同学，你可能看到了，两个用例之间有的用了<<include>>，有的用了<<extend>>，这里解释一下。

用例之间的关系有包含关系、扩展关系、泛化关系，它们的概念都比较抽象，我就不罗列概念了，举两个例子吧。

我们知道，现在很多网站支持用户名注册、手机号注册两种方式，那么我们就可以将“用户注册”抽象出来， “用户名注册”和“手机号注册”都是“用户注册”的子用例，用例图怎么表示呢？

什么是包含关系呢？

想象这样一个场景，你刚入职一家公司，那你是没有这个公司的OA账号的，是不是要提交申请啊？管理员给你添加了账户，你才能登录OA，然后看OA系统上的员工手册之类的。

所以在“登录”用例中，增加一个申请OA账户的用例（申请连接），填写个人信息后，发起申请，等待管理员批准。

扩展关系最好理解，你登录OA系统后，可以退出登录，也可以不退出登录，这个用例不是必须的，可以理解为“扩展”功能。

包含和扩展的关系的用例图如下（注意箭头方向哦，这两者的箭头方向是有区别的）：

软件工程中的需求分析，不仅仅是以上内容，这里只是冰山一角，仅仅适用于毕业设计。在软件工程中，需求分析有很多细分的维度，以至于软件工程中有一个专门的分析工程叫“需求工程”，这个以后大家参加工作了，会有体会。

讲完了功能需求，接下来就是非功能需求了，我这里列一下非功能需求“字典”表，之所以称之为字典，是因为我这里列出的非功能需求非常全面。

非功能需求分析

非功能需求，其实就是架构设计中的“质量属性”，听起来比较懵，对不？没错，软件工程中的很多专业术语，如果第一次听、甚至听了很多次，你可能都理解不了，这个真的需要项目中实际体会，项目中应用才真正的领悟。其实在职场中，很多自认为是架构师，自称架构师，或者被公司聘为架构师的，绝大部分人不知道架构中有“质量属性”这一说法，他只知道，系统设计关注性能、可靠性、安全性之类的指标，其实这些指标就是架构中的“质量属性”。

闲话少说，字典呈上！

性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。

可用性是系统能够正常运行的时间比例

安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又分为机密性、完整性、不可否认性以及可控性等特性。

可修改性是指能够快速地以较高的性价比对系统进行变更的能力。通常以具体的变更为基准、通过考察这些变更的代价衡量可修改性。

易用性，其关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。使用某个系统的容易程度，系统的学习成本低。

可测试性，软件可测试性是指通过测试揭示软件缺陷的容易程度。

可靠性，指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力

互操作性，是指系统与外界或系统与系统之间的相互作用能力。作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用，为了支持互操作性软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题

可测试性，在一定的时间和成本前提下，进行测试设计、测试执行的能力。

功能性是系统所能完成所期望的工作的能力，一项任务的完成需要系统中许多或多数构件的相互协作。

可变性指体系结构经扩充或变更而成为新体系结构的能力，这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构，当要将某个体系结构作为一系列相关产品(例如,软件产品线)的基础时,可变性是很重要的

健壮性是指在处理或环境中，系统能够承受压力或变更的能力。

易用性是衡量用户使用一个软件产品完成指定任务的难易程度。

可维护性，这主要体现在问题的修复上：在错误发生后“修复”软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。

可移植性，可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。

可扩展性，这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。

TIPS

你在写非功能需求这一模块时，选取以上你觉得重要的4-5个属性，分别解释一下这几个属性，然后将你的课题与这几个“质量属性”融合描述一下，自由发挥即可。

举例：我在OA系统的毕设中是这样描述的