Requirement Analysis is a subset of Business Analysis. It is an organized set of activities and tasks carried out to perform the analysis of requirements. As a simple example, sometimes the requirements of a system are too large to handle as a whole and they are divided into sub-systems. These sub systems needs to be defined, integrated and documented and all this becomes the part of the requirement analysis exercise.
Let’s have a round-up of what all is done in the course of Requirement Analysis:
- Comprehend requirement – Requirements are understood, expanded and more details are added to them.
- Model requirement – Requirements are modeled through techniques like data and process modelling.
- Verify and Validate requirement – Requirements are verified and validated against their viability and aptness.
- Manage requirement – Requirements are ever evolving and should be managed for changes and corrections.
We will understand more about each of the above elements by elaborating them.
1. Comprehend requirement
Once the initial set of requirements are gathered, they might not get understood properly and some details/scenarios might be missing. We look into all the missing pieces of the requirements under this part and gather all the required data through meetings and different elicitation techniques.
Also, requirements are classified under different section under this part only. They are:
- Functional requirements – these define what the system shall ‘do’. These requirements specify the results that the system is expected to deliver, its behavior. For e.g. output of a process.
- Non-functional requirements – these define how the system shall ‘be’. These requirements specify the quality and attributes of the system. For e.g. usability and extensibility.
- Performance requirements – the requirements which define how well the system should perform to be considered acceptable. It includes quality, throughput and readiness.
- Design Requirements – these requirements re for more technical solutions where it’s initially defined how the system shall be designed and built.
- Other includes Structural Requirements and Behavioral Requirements.
Additionally, in case of a large set of requirements to be achieved in a limited time-frame and resources, it should be decided which functionalities are to be developed first. This act of striking balance between requirements also happens in the ‘Comprehend requirements’ section only. It involves finding the challenges that might come in fulfilling the requirements and zeroing down the basis of deciding the priority.
2. Model requirement
Requirements contain a lot of information amongst them and this information is highly interrelated with the various other modules of the solution. Also, there are many recipients (business, technical, etc.) of requirements with different level of understanding. Thus, the requirements should be modeled into various views to serve these varied audiences. The aim of modeling is to depict complex information into a simple way for ease of comprehension.
These models help in developing the solution the correct way and also aids in communication. Requirements are modeled using text, diagrams, graphics and matrices. Let’s have a look at the different types of techniques through which requirement modelling is achieved:
- Process Modeling – A task may involve interaction between different people with different roles belonging to different departments. A process model depict this relationship with the flow of events represented in a sequence.
- Data Modeling – Every project/product involves data and data modeling aids the development of a solution by providing the definition, structure and format of the data that is involved in the solution. The two widely used data models are entity-relationship diagram (ERD) and the class diagram, which are used for relational database and object-oriented development respectively.
- Domain Modeling – It’s the process of modeling the complete solution in the form of entities, their attributes and the relationship that exists between then. A domain model is a creative way to look at the scope of the solution and discuss/brainstorm it with other stakeholders of the project.
- Scope Modeling – To avoid any scope creep, is very important to mark the boundaries of the project scope and the scope modeling does exactly that. A scope model, defines and limits the project scope.
- Data flow diagrams (DFD) – DFD is simply a graphical representation of the ‘flow’ of data through a system. It depicts how data is inputted, stored, processed and outputted from the system.
- Sequence Diagrams – They are sometimes called event diagrams and are used to depict the sequence of a functionality in a scenario, through objects and classes.
A BA uses any or a combination of the above modeling techniques to create different representations/views of the solution to be developed. Theses representations are discussed and agreed upon by the key stakeholders and become the part of project documentation.
3. Verify and Validate requirement
It has already seen stressed that the requirements gathered by a business analyst should be correct and unambiguous. Additionally, they must possess the qualities of being SMART i.e. Specific, Measurable, Attainable, Relevant and Testable.
When the requirements are to be verified, the BA makes sure that the documents comprising the requirements are thoroughly checked, up to date and contains all the necessary information in the required formats.
Requirement validation consists of the process of making sure that the requirements contribute to the achievement of the business need/business case. It’s an ongoing process and validates that at all times, the requirements are in sync with the solution for which they are elicited. Requirements are validated through facilitated walkthroughs involving the business analysts, project managers and other key stakeholders. These walkthroughs results in accepted and approved requirements documents which them become the baseline documents for the projects.
4. Manage requirement
Managing requirements is the process of documenting, tracking, collaborating, communicating and archiving the solution requirements. Requirement management is a continuous activity that spans across the complete life-cycle of the project. Let us have a look at each of these aspects –
- Documentation – Requirements are properly captured in different document types like use cases and user stories. Each of these document follow a predetermined template which is decided by the performing organization.
- Tracking – Requirements are evolutionary documents and are constantly changing with the changing requirements of the business. The documents should be able to reflect these changes through versioning. Documents are versioned with metadata like versioning date, versioned by and versioning details. This tracking will allow the project stakeholders to use the most recent document at all times.
- Collaboration – Requirement documents are shared with different stakeholders of the project and sometimes it involves multiple people accessing a document at the same time. Sometimes, document collaboration software are used for easy and effective collaboration.
- Communication – Requirements needs to be informed to the project team, sponsors and other stakeholders and this is more important in the event of a requirement change. Communication should be quick, accurate and with relevant people.
- Change management – In the events of requirement change or modification, the change documentation, its impact, the stakeholders responsible for change and the change approval committee should be properly documented. All the existing project document needs to be modified based on the new changes.
- Archive – All the technical, functional and business requirement should be properly indexed and archived for the use of the future projects.
The combination of all the above activities, taken together, constitute the process of requirement analysis. Requirement analysis is an important and mandatory exercise which should be done for every project to increase the prospects of project success.