一、 软件过程开发的需求工程
这里，软件过程开发的需求工程，完全可以借鉴软件开发中的需求工程，包括需求捕获、需求分析、编写需求文档和需求评审。
1. 需求捕获
首先明确项目环境，然后向项目所有涉及人员收集信息。项目环境包括软件类型、软件规模、软件重要程度、开发人员素质、合作单位素质等，这些因素都会影响到将来软件过程的制定。项目涉及的人员包括用户、开发人员、合同确定者和投标者等，从他们那里收集对软件过程的要求。
2. 需求分析
研究采集到的要求，形成有条理的需求表述。
3. 编写需求文档
将有条理的需求表述文档化。
4. 需求评审
组织由上级领导、开发人员及其他人员参加的评审。若评审未获通过，根据具体情况从上面三步的其中一步开始回溯，直至评审通过。
二、 软件过程开发的正向工程
采用“五步法”。一方面，五步法保留了RUP的优秀概念，如阶段、迭代、工作流、工件和角色等。另一方面，五步法采用了一些旨在降低RUP剪裁复杂性的策略，在后面“五步法的几点说明”中有讲述。
1. 确定本项目的软件过程需要哪些工作流
根据项目规模的大小不同，RUP的九大工作流并不总是需要的；另外嵌入式软件项目一般不需要业务建模工作流。虽然工作流中可以包含并行执行的活动，但本阶段并不关心这些，而是仅把工作流看成黑盒，也就是说工作流退化成了活动。
2. 确定每个工作流产出哪些工件
因为很多开发单位还是评审传统形式的文档，因此，可以规定工作流产出某传统文档。
3. 确定阶段间演进
RUP将开发过程分为四个阶段（初始阶段、细化阶段、构造阶段和移交阶段）是控制风险的很好的方法，确定阶段间演进就是要以风险控制为原则，决定每个阶段要执行哪几个工作流，每个工作流执行到什么程度，产出的工件有哪些，每个工件完成到什么程度。
4. 确定阶段内的迭代计划
迭代是RUP非常强调的一个概念，可以进一步降低开发风险，在RUP的四大阶段（在后三个阶段进行迭代更常见）中，决定是否采用迭代开发，每次迭代开发的内容有哪些。
5. 规划工作流内部结构
工作流不是活动的简单堆积，工作流涉及到角色、活动和工件，并且工作流的复杂程度和项目规模及角色多少等有很大关系。因此，我们应首先决定本软件过程要设立哪些角色；如果第二步中引入了传统文档，还要将传统文档映射到RUP工件；最后，规划工作流内部的结构，通常用活动图的形式给出。
若想通过对RUP剪裁得到比较复杂的软件过程，无疑这一步是剪裁的难点。
三、 五步法的几点说明
1. 确定软件过程的时机
在实际中，确定软件过程的时机不是一成不变的。比如，如果新项目和该项目组以前开发过的某个项目很相似，就可以在软件开发开始之前确定将采用的软件过程；如果是不熟悉的项目，就可能在初始阶段完成后才能确定或修改要采用的软件过程；如果项目有很多未知因素，迭代计划推迟到阶段开始前比较好，工作流规划也同样推迟。
2. 五步法为何前瘦后胖
五步法中的五步，让人感觉前三步很“瘦”，而后两步比较“胖”，这是为什么呢？其实，将迭代计划和角色设立都往后推迟，是为了使软件过程开发简单化。软件过程开发主要有两种流派：以活动为中心和以角色为中心。而RUP的工作流这个核心概念是角色和活动并重的，通过适当推迟规划工作流，可以使RUP剪裁简单化。五步法正是这样一种RUP剪裁过程：它以活动为中心的，它的第一步就是确定活动；并且它把角色的设立推迟到了最后，既降低了RUP剪裁的复杂性，又保留了工作流的优点。
3. 传统文档和RUP工件的对应关系
传统文档和RUP工件之间，有时存在一定的对应关系，而且往往是一对多的关系。因此五步法的第二步可以用传统文档，不仅是符合习惯的，也减少了软件过程开发先期阶段的细节，降低了RUP定制的复杂性。到了第五步，再将传统文档分解成RUP工件，以利用RUP的工作流方面的指南。传统的《软件定义文档》可以分解为RUP的scope、vision和features；传统的《软件需求规格说明书》的非功能需求部分要包括RUP的business rules；等等。
