最近做需求规格说明书时，发现系统边界这一块很是有问题，觉得系统边界与参与者，用例关系相当于‘鸡生蛋，蛋生鸡’，无论是先写边界后描述参与者与用例，还是反过来想，总觉得矛盾重重，因此，如何做出一个成型的软件，就很有讨论价值了。
软件工程中，有三种开发方式比较容易混淆。
1.原型法
即先快速做一个原型，原型不论对错，很多时候原型都是一个文档，一句话，一副图片，然后在这个原型上进行批判性修改，错了没有关系，说出错的理由，然后往正确的方向上偏移，慢慢的原型就会稳定下来。
2.迭代式
当原型稳定时，就会出现一个框架性的内容，根据需求上的优先级，对内容进行模块分割，然后逐渐增加模块数量和解决现有模块问题，确定版本号，一版一版的进行更新。
3.瀑布模型
迭代式开发中的每个模块版本，都需要经过瀑布模型的历程，从需求分析到软件测试。
因此，这三种模型应该是互相嵌套使用，而不是独立可成体系的。
话题转回系统边界的问题。
从描述上来看，系统边界是最难以描述的内容，因此参阅了《thinking in UML 大象》边界章节。
举一个数学例子：
2X+4Y = 10 对于此二元一次方程，X,Y可能存在N多解。
但当我们知道X=1时，便已经确定下来Y=2。
当X=3时，也知道Y=1。
由此可见，万物守恒，总有其归宿。
我们可以把参与者与用例设为式中的X，系统边界设想为Y，这时候就得出以下结论：
参与者与用例 <=>系统边界。他们之间的关系为互相推导关系。
当然系统边界实际过程中不是一个Y可以替代，参与者与用例也不是一个X可以替代。本文主要是论述系统边界与参与者，用例的关系。
如有不正之处，还望指点。