Question

what are the characteristics of a business systems analyst? How can a business systems analyst plan for requirements gathering?

Answer 1

ANS. The characteristics of a business systems analyst are:-

Great customer interface.

The great business analyst is a critical liaison between the project manager and the technical team. This person is often the driving force behind the accurate, complete, and detailed documentation of the final project requirements. Why? Because the organizational to tech cross-over ability and skills that many project managers will lack must be handled in this role. And they help the tech lead interpret those functional design ideas into technical design specifications for the design and development work on complex technical solutions.

Subject matter expert.

The skilled business analyst is vital in their project team role as a subject matter expert. This helps them to work with the client to document accurate business processes that are then used to create detailed, complete, and accurate project requirements.

The business analyst's technical knowledge coupled with his understanding of the design process and the likely end solution makes him an invaluable resource for the project manager the project team and the project client.

Good technical cross-over.

The very valuable business analyst has a diverse amount of technical knowledge. Not necessarily tech lead or developer knowledge, though that is a plus, but rather a very good technical acumen that gels with the project management-type organizational skills and knowledge they also likely possess.

Can project manage it when needed.

The indispensable business analyst can and often acts in the role of project manager, both when the project manager may be tied up on another project and also when interfacing with the team and client and a decision needs to be made if the project manager isn't currently available.

Critical attention to detail.

Detail-oriented focus is needed by the business analyst on the project for a variety of reasons: to assist the project manager and fill in there as needed, to work closely with the customer sponsor and team and the project team to define and document requirements, and to help track and resolve issues throughout the engagement.

Skilled communicator.

I've often said that communication is Job One for the project manager. However, communication skills are possibly the most important characteristic of the awesome business analyst if for no other reason than the vast responsibilities this position has on the project and with the team and customer.

Miscommunication can lead to so many problems on the project.

The awesome business analyst ends up interfacing with all stakeholders, making accurate and thorough communication necessary.

Facilitation skills.

The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings and formal project status meetings for the project manager and then requirements meetings with the customer as well as design sessions with the technical project team.

Skilled with PM and organizational tools.

The business analyst needs to have a good command of the use of various project management related tools such as project scheduling software, basic tools like Word, Excel and PowerPoint, and others that might be needed such as task management software, bug tracking software, risk management software, file management software, and even modeling tools like Visio, etc.

Conflict resolution.

From time to time conflicts can arise. I'm not talking about fisticuffs...at least I hope not. But disagreements among technical team members or with members of the customer's staff can arise. The skilled BA will recognize this quickly and work with both sides to come to a mutual agreement. Patience is also a virtue because any conflict resolution requires patience and understanding. And good listening skills.

Requirements Gathering Process followed by business analyst:-

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.