First, what is solution requirements analysis?
Requirements elicitation and analysis is the cornerstone process of analyzing the business requirements and documenting a solution requirement package “also known as SRS or DRD”.
It is iterative work to plan, prepare and execute stakeholder information, to analyze and document the results of that work, and to ultimately define a set of requirements in sufficient detail to permit the definition and selection of the preferred solution. business analysts use a number of analysis models to support the analysis activities.
According to the standards of the PMI “Project Management Institute, requirements must be analyzed, dissected, and elaborated using techniques such as dependency analysis and data and process models to jointly discover and clarify product options and capabilities.
Here are the top ten models:
1) Context diagram: This model is very useful, allowing the business analysts to determine the scope of the solution and avoid working on functions and functions with no added value.
“This allows the business analyst to clearly show the boundary of the system, the users (both human and other systems), and the high-level data provided by and to the system. A context diagram is just a high-level representation, but when supported by detailed data definitions, it is an excellent tool to communicate some of the project scope to stakeholders “… referring to the PMI
2) Ecosystem Map: This model helps business analysts to identify all related systems, making it easier to define the data entities later on and analysts can easily determine transition requirements
3) Process flow: One of the challenges is to understand how work is done to facilitate analysis and to find a detailed requirement related to the work itself.
4) Feature Model: Can you imagine your solution functions built in a hierarchical way, yes that’s the fact. Accordingly, you should group your solution functions into a structure that will help you understand a detailed level of functions, and group them in order to define them later, prioritize them and understand the dependencies of functions.
5) Use Case Diagram: This is a simple model that defines the scope of the functions and is considered a focal point that will translate your function into detailed requirements.
6) Use Case Description: Use cases describe how “actors” interact with a “system” to achieve a business goal or respond to events. Use cases contain “scenarios”, which are primary and alternate paths through the use case to achieve the desired goal. The use case diagram is usually easy to read and understand, and it provides a visual representation of a system by focusing on the actors who will interact with the system and their goals in the interaction.
7) Decision Tree: It is often necessary to identify scenarios, at least when defining interface requirements within the use case description. This model is important to analyze business rules, which represent solution constraints and help business analysts identify related requirements.
8) Entity relationship diagram: It is a method that there is a solution for business analysis without data structure. It is a graphical representation of the entities relevant to a chosen problem domain, the relationships between them and their attributes.
9) Data Flow Diagram: If you have a clear process flow and well-identified data entities, now is the time to determine the data flow within the workflow. DFD “Data Flow Diagram model can stand alone”. It is thus an analysis model that illustrates processes that take place, along with the data flows to and from those processes.
10) Data Dictionary: We can say that this model is the destination in most business analysis initiatives in the analysis phase, most business analysts believe that it is the last step in the life cycle of requirements analysis. It is an analysis model that describes the data structures and attributes that the system needs.
Based on your experience, what is the best order to use those models? Are there any best practice recommendations?