Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Requirements Gathering By Business Analysts
A great user experience is all about enabling the end users to achieve their objective be it a website, a software system or a product. In order to fulfill their needs, we need to understand their work and the context of their work. The first and basic phase of software development life cycle is requirements gathering. They give clear, concise and agreed set of customer requirements that the software should provide. Business analyst and subject experts are responsible for requirement gathering process.
Business customers have a tendency to expect software teams to be mind-readers, and to deliver a solution based on unspoken or unknown requirements. Hence, all of the requirements need to be formally captured in a mammoth document.
Requirements Gathering Process Flow
Soliciting and gathering business requirements is a critical first step for every project. In order to bridge the gap between business and technical requirements, the business analysts must fully understand the business needs within the given context, align these needs with the business objectives, and properly communicate the needs to both the stakeholders and development team. For that, they need to ensure requirements are written in a language that is understandable by both groups.
Requirement Gathering goes through the following Stages
- Project Definition
- Elicitation
- Analysis
- Documentation
- Traceability
- Sign – Off
Project Definition
This stage is to define the business objectives that every project should understand and define so that all efforts can be prioritized against the value that the project is delivering to the business.
Listed below are the activities to be taking place during this stage.
- Clear definition of the requirements development efforts.
- Assumptions, Dependencies and Risks
- Identifying business stakeholders
- Change Management – Define how changes to the requirements will be handled.
- Benefits
- Funding for the project
- Interfaces with other systems
- Success criteria
Elicitation
In this stage, proper information is extracted to prepare to document the requirements. There are many different business analysis techniques to elicit requirements and their priorities, including workshops, facilitated interviews, observations, or prototypes (can be discussed in separate article).
The stakeholder classes will be identified here about the clients who want the product to be built, the customers who will pay for it, end users and other stakeholders who will be impacted. Then the stakeholder classes will be mapped to business goals. Identification of the input required with a degree of involvement and the influence for each identified stakeholder class. The stakeholder representatives and the decision makers will have to be identified.
Analysis
In this stage, the rules will be verified and validated if they are unclear, incomplete, ambiguous, or contradictory. The category of the requirement functional or non-functional will have to be figured and prioritized.
Documenting
Collate, author, and publish requirements to stakeholders. Establish naming conventions and definitions. Trace requirements to sources. Document facts and assumptions.
Traceability
Verification with the stakeholders of the life of a requirement, from its origins, through its development and specification, to its subsequent deployment and use. It ensures that all of that there aren’t any scope ‘holes’ in the developed system due to missed requirements. The activity also ensures that all of the requirements are internally consistent with each other.
Sign Off
This is a secure acceptance of the requirements from the stakeholders. This step is the actual “SIGN OFF” from the users and sets the stage for the configuration work to start.
What are Requirements?
A requirement is a statement about a prospect of what the proposed system must do or adequately for solving the customer’s problem. After the requirements has been raised by the stakeholder, it is the business analyst’s role to further define, analyze, validate and prioritize the requirement statement.
The set of requirements as a whole represents a negotiated agreement among the stakeholders. A collection of requirements is a requirements document. For requirements to be effectively implemented and measured, they must be specific, unambiguous and clear.
Requirements Hierarchy
Business Requirements − High-level statement of enterprise needs goals and objectives. They confirm the scope of the project and identify stakeholders. They usually describe what a system or a solution should do. The business requirements should always be written from the point of view of the client. Although they are high-level broad requirements, the details on ‘what’ are the needs of the organization and ‘why’ these needs should be fulfilled, should be detailed.
Stakeholder Requirements − These are statements that describe the needs or problems of the stakeholders to implement a solution whether related to organizational or operational concerns. Stakeholder requirements act as a connector between business requirements and the other classes of solution requirements. It places the user at the center of focus and makes use of flowcharts, use case diagrams, use-case scenarios, and other process models to describe.
Solution Requirements − They describe a solution of how the stakeholder wants to implement the business and stakeholder requirements. They are often divided into sub-categories:
- Functional Requirements − Functional requirements describe the scope, functionality, behavior of the product, and connection to other systems that the developers must build into the product. They describe exactly what tasks the software must perform. They also define the business rules that the system must conform to.
The Business Analyst will capture and validate the functional requirements by the development of Use Cases (explained below).
- Non-Functional Requirements − Non-functional requirements define the system’s quality characteristics, Constraints or standards that the system must have or comply with. They will describe the look and feel of the system. They decide the visual properties of the system, its usability, and the performance requirements – how big, how fast, etc. They also include the product’s intended operating environment, maintainability, portability, reliability, security etc.
- Transition Requirements − Temporary capabilities to make transition to the new system. They are always temporary in nature and because they cannot be developed until both an existing and new solution are defined.
Use Cases
Use cases describe the behavioral and functional requirements of computer software systems. They provide an easy format for all people to quickly grasp the system’s functionality. Existing System – When working with an existing system, use it to trigger ideas quickly.
They describe the typical sequence of actions that a user performs in order to complete a given task. A use case model consists of — a set of use cases — an optional description or diagram indicating how they are related.
Example of a Use Case Diagram
With a Use Case Diagram, the relationships between the Use Cases are obvious. In the Figure below, the Actor is represented as a stick figure and each Use Case is represented as an oval. The arrows show the relationship between the Actor and Use Cases and between the various Use Cases.
Requirements gathering are quite a lengthy and detailed process. Needless to say, the larger the system, the more complex the process is. A requirements management process will help control cost, avoid requirements creep, and ensure end-to-end traceability. The advantage is that this process will help you gather most requirements in the pre-design stage define and prioritize them, avoid duplication and set criteria that measure the degree to which they have been implemented.
4K+ Views
