系统边界，即系统包含的功能与系统不包含的功能之间的界限。一般在系统分析阶段定义，只有明确了系统边界，才能继续进行下面的分析、设计等工作。
不论这个系统是产品还是项目。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交互。"这，是一个黑色的立方体，长45厘米，宽23厘米，高3厘米，盒子的每个角都不尖锐，上方平坦，并有柔软质感；下方在四角之处都有凹进去的螺丝口，可以接杆子，以作凳子用。"
这就是仅仅对其功用的描述，其目标是作凳子用。这可以看作是功能性需求，当然如果还有一些约束，例如"此立方体可以承受300斤胖人之重"，这就可以看作是非功能性需求。但同样还是在描述边界。而对于其内部构造如何，在需求中不要描述，例如盒子是空心的还是实心的，材质用钢板还是木头，这都不是需求，而是已经在设计了。
因此，在描述需求的时候，重要的就是界定系统的内外。看过很多的需求，自己也写过很多的需求，界定内外不是容易的事情。有几个原因，一是没有内外的概念，不知道需求描述的是什么；二是知道内外，然而对于边界的定义，没有足够的词语描述清楚，只能用对系统内部设计来代替。这样的结果是，一份需求书，你搞不清楚它是需求还是设计。
譬如有的需求书，它描述了系统内部模块划分，三层结构，数据存储、中间逻辑等等。比如专题分析的需求中，包含了对挖掘变量的描述，嗬，将上百个变量列在文档中确实能够让页数增加。然而这恐怕不是阅读对象关心的，也不符合分离变化与不变的原则。需求书的阅读对象关心的是系统是什么，而非如何实现。系统是什么是相对不变的，而实现方式却是相对变化的。例如上面盒子的例子，用它作凳子是不变的，而至于用木头或是钢材，是后面考虑，可能会反复变化的。对于专题分析也是如此，这个分析针对的业务问题，诸如哪些客户最有可能离网，这个目标是相对固定的。而你是考虑使用呼转次数或是话费突降的角度来考虑，这是变化的。因此，在需求中，绝对不要将设计的东西加入进去（除非你是想便于说明问题），因为那种东西不能够作为一种"规格"，用于验收、测试的标准。
当然，有时候根据客户在作要求的时候，并非完全从系统边界上考虑，而真的会从系统内部提要求。譬如说，这个凳子，你就得用钢板，不能用木板，至于为什么，可能这仅仅是他的喜好。软件系统也是如此，有时候他会提出要求，你就得用某种产品，你就得用分类模型或者是神经元算法来实现。面对这样的要求，我也不知道该如何在需求书中表述，难道写上一堆系统约束——必须用叉叉产品，不得在系统中出现任何英文字母…？
转自：http://blog.163.com/ysd-spring/blog/static/13430106720102263928311/