How do you model requirements ?

Requirements are modeled to analyze, integrate, and process the requirements.

When there is a business need that requires a solution, the requirements are gathered from the right stakeholders.

Once these requirements have been gathered, they have to be analyzed and documented to fully understand them.

This is where the requirements modeling comes in, it helps the stakeholders understand the business process in order to identify problems such as bottlenecks and find solutions to those problems.

There are four elements that are used in the requirements modeling process and they are:

1.Model Requirements: Models are a visual representation of information, they are used to communicate information to a specific audience.

They are also used to confirm information, identify information gaps and prevent the duplication of information.

There are two methods which are used by business analysts to model information and they are:

i. Matrices: In mathematics, a matrix is a rectangular array of numbers, symbols, or expressions, arranged in rows and columns. Matrices are used by business analysts to model requirements which are complex but uniform in structure.

These complex requirements are broken down into simple requirements which are inputted into a matrix. Matrices are used in data dictionaries, gap analysis and requirements traceability.

ii. Diagrams : a diagram is a pictorial representation of a set of requirements. It is used to represent complex requirements such as organizational charts, components of an object and hierarchy.

Models can be used to simplify numerous complex categories such as:

a. People and Roles: organizations are made up of people and representing these people and how they fit in the organization can be a complex task. Models can simplify this task by representing these people, their roles in the organization and their relationship to the solution.

Organizational modelling is known by numerous names such as roles and permissions matrix and stakeholder list, map, or personas.

b. Rationale: these are used to understand why the change is needed. Examples of rationale models include: decision modelling, scope modelling, business model canvas, root cause analysis, and business rules analysis.

c. Activity Flow: these are used to represent the order of actions or events. Examples of activity model include : process modeling, use cases and scenarios, and user stories.

d. Capability: these are used to model the features or functions of an organization or a solution. Examples of capability modelling include : business capability analysis, functional decomposition, and prototyping.

e. Data and Information: these are used to represent the exchange of information in an organization or a solution. Examples of a data and information model include data dictionary, data flow diagrams, data modelling, glossary, state modelling and interface analysis.

2. Analyze Requirements: requirements can be complex so they need to be broken up into simpler requirements to be understood.

Requirements can be broken down for the following reasons:

i. Changes that must in the organization be made to fulfill the need.

ii. What must not change in the organization while the need is being fulfilled.

iii. Unnecessary parts or features of the solution.

iv. Constraints or assumptions that might affect parts of the solution.

3. Represent Requirements and Attributes: requirements should be detailed enough so that the characteristics of the requirements and the quality of the designs are fully understood.

The attributes of each requirement should be specified in such a way that they can be classified according to the Requirements Classification Schema. The Requirements Classification Schema splits requirements into business, stakeholder, solution and transition requirements.

4. Implement the Appropriate Levels of Abstraction : the level of details in a requirement varies depending on the type of requirements and the target audience for those requirements.

The business analyst might need to produce different versions of the same requirements for different stakeholders.