Requirement Analysis Part 3: Requirement Organization

In the previous article, we talked about requirement prioritization. This article will cover requirement organization.

The main goal of requirement organization is to create a set of requirements that are comprehensive, complete, and available to all stakeholders for their reviews and feedback. This should basically define the scope of work and should lead to an agreement between all stakeholders.

The main aim of this task is to understand which models to choose for business domain and the solution and the relationships and dependencies between them.

Some of the techniques that can be used for the same are as mentioned below:

Business Rules Analysis: According to BABOK, this is one of the 16 fundamental knowledge areas that a BA should be well versed in. Listing down all business rules allows you to identify the impact of any change in business requirement and scope creep. It also allows you to identify what business rules or policies need to be changed as a part of your work. Defining and documenting these business rules is also necessary to prevent scope creep.

Data Flow Diagrams: A data flow diagram includes the data, processes, stores, and external entities of system represented in a graphical form. Note that a data flow diagram is very different from process flow diagram. It is not sequential, does not consider users interacting with the system, follows only one path of flow and not multiple paths of flow. and does not answer procedural questions.

Data Modeling: The model is in the form of a diagram, supported by texts. This is supported by data dictionaries and analysis of business rules. There are two types of data models

1. ER Diagrams (Entity Relationships) - This is a relational diagram.
2. Class diagram - This is an object orientation diagram.

Functional Decomposition: This involves breakdown of functional areas into sub-parts that can be analysed independently. It allows for breaking bigger problems into smaller problems ultimately allowing the project to be broke down into phases, releases, or deliveries. The functional areas can be broken down such that

High Level function --> Sub Function --> Processes --> Activity

This is done till the function cannot be broken anymore.

Organization Modelling: Organization modelling allows you to determine the org structure of a company, the various roles and responsibilities and chain in the organization. It defines the various formal relationships within an organization, roles and interfaces. It could also comprise of markets (customer, sectors), matrix (different managers based on functional areas), grouping people based on skills, etc.

Process Modelling: This depicts how work is done in the various departments within an organization and how the roles interplay in the completion of a process. This normally involves activities, decisions, events, sequential flow as well as endpoints. This is normally drawn using UML (Unified Modelling Language) or Business Process Model and Notation (BPMN).

Scenarios and use cases: A use case diagram provides a very high level description of what your solution can do and who are the users who will interact with the solution and in what way. It is normally used to describe functional requirements.

User Stories: User stories are the functionalities and features broken down into their minimum workable unit. This captures the feature from an end user perspective. They are generally of the type As a < type of user >, I want <some goal> , so that <some reason>. The more we say about this, the lesser it is. Keep looking out for an additional article on the user stories.

Which of these methods have you used more often for requirement organization. Would love to hear your thoughts.