Requirement Gathering
Requirements gathering important part of any project .In simple terms its collecting the requirements or needs that are required for the successful project .A requirement is a need to achieve the business or project goals and collecting of this requirements is called REQUIREMENT GATHERING.Requirement Analysis is the process of capturing user expectations for a new software being built or modified.
There are different ways to gather Requirements.
Stock holder analysis:
Stakeholder Analysis is the process of identifying project stakeholders like they can be SME or quality assurer who can give the required needs or ADD ons for the Modification of the project which must be implemented for the project to be successful
Stake holder can BE SME in process or END users or member of the operational teams
Requirements Elicitations Techniques
Requirements Elicitation is the process of digging out the information from the stakeholders requirements elicitation serves the foundation in documenting the requirements
Brain Storming:
Brainstorming can be done either individually or in a group The ideas then collected to be reviewed or analysed and where relevant included in system requirement. Ideas can come from what the stakeholders have seen (EG Software Exhibition)or experienced elsewhere(eg Before they joined the present organization)
Document analysis:
In This As a BA you can analyse the documents which are readily available of old system as that can help to give the new inputs for the existing project like USER Manuals or any private document of the company
Reverse Engineering:
It is a process to identify the existing system how exactly it worked and to implement the new changes that has to be done to upgrade the product or to get the project successful Reverse engineering is an elicitation technique that can extract implemented requirements from the software code
FOCUS Group
It is a technique that is used to get the Requirements in an interactive group of people.The people in this Group share their needs and ideas for the product to be developed .focus group can be of 6-12 attendees only.
Observation
Observing or by watching the workplace activities can help us to identify needs and opportunities, understand business processes, Observation of activities or job shadowing, is the act of studying a work activity as it is being performed.
Active/noticeable: in this process business analyst will ask the questions to the worker like sitting side by side of the user and asking the questions related to the work or any applications or about the processs
Passive/unnoticeable: in this approach, the business analyst does not interrupt the work while the user is performing the work activity. Any questions would be asked once the observation is over. This allows the a natural flow of events to be observed without interference by the BA.
WORKSHOP
A workshop that is created by Business Analyst and encourages the participation of the key stakeholders to achieve the project Goal.
A workshop can be held for different reasons including planning, analysis, design, scoping, and requirements elicitation and modelling. It may also be used to produce ideas for new features or products, to reach an agreement on a topic, or to analyse requirements or designs.
Throughout the workshop, the facilitator should keep it focused by regularly confirming the session’s activities against the workshop’s purpose and outcomes.
JAD(JOINT Application development )Requirement workshop
JAD is the extended workshop that facilitates by Business analyst where in it brings the Stakeholders and System Analyst to work on the needs and requirements in full focus to achieve the project needs and goals.
Interview:
Interviews of users and stakeholders are important in creating wonderful software. Without knowing the expectations and goal of the stake holders and uses , Your highly unlikely to satiate them, you only have to understand the perspective of every interviewee, in order to properly address and weigh their inputs . Like a good reporter , Listening is a quality that assists an excellent analyst to gain better value through a interview has compared to an average analys.
Prototyping:
Screen mock-ups or prototype means a representation of a computer screen and examples of how the user will interact with the application. Prototyping is a great tool to communicate what a software solution will look like.
Screen mock-ups cannot capture the flow of the system, analyst must accompany screen mock up s with written description as of what happens when certain buttons are clicked or when certain field are entered along with certain drop downs.
Questionnaire:
Questionnaires is a list of quatiosn that aneed to be can be useful for obtaining limited system requirements details from users /stake holders, Who have a minor input or are geographically remote the design of a questionnaire (Whether offline or web based) and types of questions are important and can influences the answers, so care is needed.
SORT Requirements:
It is the process where scattered requirements are put to gather and redundancy is removed .the inter related documents are linked
Prioritize requirements
This technique for queuing the requirements for the development process
Fcators that influence
Importance risk cost benefit tome and strategy
3 main actors:
Customer
developer
business owner
Techniques:
100 Dollar Test
Top 10 requirements
Numerical assignment –Mandatory , very imp, rather imp, not imp, does not matter
MOSCOW Technique:
It is a prioritization technique used in business analysis and soft ware development to reach a common understanding with stake holders on the importance they place on the delivery of each requirement, also know as MOSCOW prioritization or MOSCOW Analysis
The MOSCOW STANDS for:
MUST SHOULD COULD AND WOULD
MUST have the requirements to meet the business need
SHOULD have the requirement if possible, But project success does not rely on it
COULD have this requirement If it does not affect anything else in the project
WOULD would like to have this requirement later, but it won’t be delivered this time
Validation of requirements:
FURPS
It is a acronym representing a model for classifying the software quality attributes (Functional and non functional requirements)
Functionality, Usability, Reliability performance and supportability
To validate means to confirm that the requirements meet the operational and system level needs of a program. Validating Requirements ensures that:
- The set of requirements is correct, complete, and consistent,
- A model can be created that satisfies the requirements, and
- A real-world solution can be built and tested to prove that it satisfies the requirements.
10 Rules for Successful Requirements Gathering
To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:
- Don’t assume you know what the customer wants, ask.
- Involve the users from the start.
- Define and agree the scope of the project.
- Ensure requirements are specific, realistic and measurable.
- Gain clarity if there is any doubt.
- Create a clear, concise and thorough requirements document and share it with the customer.
- Confirm your understanding of the requirements with the customer (play them back).
- Avoid talking technology or solutions until the requirements are fully understood.
- Get the requirements agreed with the stakeholders before the project starts.
- Create a prototype if necessary to confirm or refine the customers’ requirements.