In my view, the most challenging projects are those that exist in a large ecosystem or have a tremendous amount of undocumented business rules. Most analysis methods that we have seen define very odd dimensions for analyzing systems.

For example, UML defines the diagrams below. Yet how do you bound the problem space so you know your analysis is complete? How do you cross section your analysis so you get full coverage? For a time people were only doing use cases. Some people only do process flows. Some people try to use UML.

UML uses the following categorizations: structural modeling, behavioral modeling and architectural modeling with the following diagrams:

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Activity diagram
7. Statechart diagram
8. Deployment diagram
9. Component diagram

These categories are simply not useful for modeling requirements, although the diagrams are necessary but not sufficient for modeling requirements. They are the diagrams a builder might use to construct a building. But what about the diagrams about how people will use the building and why they want the building in the first place. What about the diagrams about how the building will actually look like and the actual finish materials used?

The existing languages for requirements are designed by very technical people so the focus is simply too technical a focus. Either the nomenclature is too technical or the concepts are designed around the architecture of the system are too technical. The language should be defined for the people who will be using the language.

The RML models focus instead on the view of the system from a users’ point of view, and are constructed so that real business analysts have a shot at actually adopting them. RML models form boundaries based on different slices of the system. There are ways to identify all the objectives the sponsors have; all the people who will use the system; all of the systems that exist within an ecosystem; and all the data that needs to be processed. By identifying the bounding models you bound the problem space.

The actual models of UML are fine but not sufficient. The other main issue with UML is that it provides models with no guidance as to how to ensure that your requirements analysis is complete. The focus is on semantics, not solving a problem. For example for many IT systems a company organization chart defines all the users who could possibly use the system. Using an RML Org Chart model you would model them into roles and even the individuals that you will work with. Without something to bound the scope of the users, it is easy to leave out entire stakeholder groups.

Here are the dimensions RML uses to model requirements.

1. The objectives of the system (or program)

a. Why the executives sponsoring the project think they want the system, how are those related to the organizational strategy

b. The problems that exist that are preventing achievement of goals today

c. What features or solutions people think will solve the problem and how those features map to the problems in a quantitative way

2. The people using the system

a. Who are all the people who will use the system?

b. What do they do? What are they trying to do?

3. The systems in the ecosystem

a. What is the topography and link of all logical systems that exist in an ecosystem?

b. What is the nature of communication between the systems, is the information coming from the right place to support the users?

c. What are the screens and other physical manifestations of the system that users experience?

d. What are the automated processes the systems perform that the users care about?

4. The data being processed

a. The business structure of the data (not the technical representation)

b. The details of the data

c. How the data is transformed by and flows through business or system processes

d. Reports or any representation of data that is similar to reports