软件中，问题空间和解空间是环环相扣的，一个问题的解空间会导致新的问题空间出现，找不到源头的问题和解可能包含错误，且难以理解

软件的开发过程是一系列的问题和问题的解的发现过程。

 

最初的问题来自动于用户的业务目标（痛点）。软件的功能设计即为此问题的解。

而功能设计本身又构成了软件实现设计的问题空间，软件的实现设计即为对应的解空间。

 

软件内部是由模块构成的，我这里的模块是范指，一个模块是一个独立的功能块，可大可小，大的比如：软件的某个界面功能部份、某个WebService提供者、业务逻辑组件等；小的可是一个类。一个模块对外提供的服务是某个问题需要的解；而这服务的解对其它的模块所产生的需要又构成了其它模块的问题空间。

 

问题空间代表的就是需求，解空间代表的就是设计。从上面的论述可以看出，需求和设计是个相对的概念，存在于软件开发的各个阶段。

 

处于不同位置的需求和设计本质上是相同的。因此，用于需求分析的手段和概念也是通用的。比如：领域模型可以用来描述用户的业务领域；也可以用来描述界面上的相关概念。用例可以用来描述用户的功能需求，也可以用来描述一个模块对另一个模块的功能需求。

 

然而，在软件开发的整体过程中，对于功能设计以下的实现设计工作，通常不再进行需求和设计的区分。这是因为，功能需求和业务及用户有直接的关系，但又不是直接可以得出的，因此需要把软件的功能本身作为研究对象。（这里注意：应该由用户提供的是业务目标和领域知识，功能设计要由工程师把握，常常用户凭直觉说出的设计方案，会对工程师带来误导。比如有一个用户要我读windows补丁信息，让我直接从填加删除窗口抓取；而后来发现直接从注册表是可以获得的。但是用户所想到的解决方案并不是没有用处，一方面这个也可能是一个解决方案，另一方面它反应了问题本身的细节。）

 

当软件的功能需求确定后（包括功能的界面），功能就成了软件实现的问题域了。而恰当的解是比较容易导出的。在设计过程中用UML顺序图来刻划模块间的环环相扣的关系是非常恰当的。

 

通过以上论述，可以得出以下结论：

软件可以认为是从用户的业务目标一步步推导出来的。

 

软件的开发过程常常出现如下问题：

问题域的认知常常需要一个过程。因此软件做出来后，可能对用户的问题域还有未知的部份，这时将导致软件的改进。要做到对用户的问题域有充分的认识，行业经验是一个关键因素。

 

 对于较复杂的解的认知也需要一个过程，因此实现的方法，可能和最初的设计有很大的偏差。软件设计经验对得出恰当的解有很大帮助。