上 面一步的业务更多的是属于顶层方面的内容，而第二个层面往往会过渡到系统软件需求层面的内容，在这里我们更加强调的是类似面向对象的用例分析和建模的方 法，这包含了业务用例和系统用例分析和建模，是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例，单个具体的用例分析和建模，每 个用例详细的基本流，扩展流，业务规则，参与角色，界面原型，业务对象和对象属性等各个方面内容的描述，要知道我们做用例建模的目的是能够按用例驱动的核 心，平滑的转入到架构设计中去，因此用例分析建模已经不是简单的描述现实世界的问题，已经涉及到业务或用户需求到系统需求的第一层抽象转换。
要 做好需求的第二步的事情，那么单纯的只有业务背景就不足够的，必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开 发，但是只是是做过，通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始，最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑 用例建模，去认识到为何要采用这种方式去用例建模，真正理解用例中每个描述点如何影响到最终业务系统的实现。
没有技术背景很难真正成为一个优秀的软件需求分析师，最多也就是一个业务需求分析师。要 知道，当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉 及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。
这些更加已经是一个完全的系统分析方面的内容，或者 说软件需求已经会兼顾部分软件架构设计的内容，因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要 去了解涉及到UCD，交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入。一个优秀的软件需求人员既不应该因为具备技 术和开发背景而导致在需求分析和建模中的各种程序员思维，也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。
软件需求人员衔接了最终用户和内部的设 计开发，是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧，各种软技能的要求更是必不可少的，在此不再展开去描述。一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题，因为最终真正有用的需求分析的方法论和模式，去理解和熟悉业务和快速形式化描述和建模的方法，有不断的实践总结出来的快速理解业务的能力。
