最课程阶段大作业02：实现自己的利息计算器

上文描述了版本控制后，此篇才真正到了作业本身。我们第一次大作业要完成的是一个利息计算器。

利息计算器或者说融资计算器有自己的图形化版本，每一个学习的同学如果想要直观的了解下功能，可以管自己的老师要或者加文末的QQ群向老师索取。不过我们今天要实现的是非图形化的界面，是CS版本的，简而言之就是你要利用自己在SE阶段学到的知识，实现一个在console下的利息计算器。当然，按照我们最课程的造性，肯定还要带点超纲题。

在强调要做作业之前，我们先来看一下作业是怎么被描述来送到你手里的。

一：需求的地位

作业是什么？你是一个程序员，你的作业就是完成一个软件的功能。功能是什么？功能就是需求。在整个软件开发体系（在我们这里，被描述为SPP：精简并行过程）中，它占据重要的一环。我们先来回顾下SPP模型：

看到没，它处在整个项目研发过程的第一环。同时，在项目管理过程中，它也占据了一个重要的过程：需求管理。

有一点需要强调，任何质量管理体系，评判是否完善的一个重要标志是：是否留下了一套完整的资产（软件领域中所谓资产，可以是代码、文档、数据库等等）。那么，涉及到需求的文档资产，就包括如下几个：

而今天，我们的作业，就要以产品需求规格的形式被描述出来。

二：需求该怎么被描述

不存在具体的“需求改怎么被描述”的形式，每个公司甚至于每个项目组都可以有自己习惯的方式去描述需求，在我们的SPP模型中，一份完整的需求包括大概包含如下部分：

而具体描述功能需求的是一个个的用例（即“用户故事”，Use Case），它大致长这样。

用例名称

除了用例本身的描述以外，初学者不容易把握的另一个地方是，功能点应该细化到何种程度才能被归为一个“用例”？

注意，一种简单粗暴但不是非常正确的做法是：一个页面就是一个用例。比如说，用户注册常常是一个页面，同时它也被称之为一个用例。但是，过于复杂的用户注册页面（或者说功能），可能就会是多个用例。比如，我们在注册用户的时候需要验证用户的手机号是否正确，那就需要获取手机验证码，那这里就会包含一个发送手机验证码的用例。

一个典型的包含当前迭代全部用例的故事墙：