Roberto Blanche

I believe there is no right or wrong as each company has their own procedures, but I will share my experience.
First of all, you need to have a very good document about what the client wants; which is, good gathering of information, clear objectives, scope well defined, etc. This is what is called the Business Case. Also, you have to collect the business requirements and rules; and have a clear understanding of the end-product/ deliverable, all documented in the Business Requirements Definition (BRD). If you as a BSA have participated in the processes I just mentioned, then you are in a good shape for doing the translation.
One big error is when the BSA responsible of doing the translation wasn’t involved in the processes mentioned above and he is going to start asking more questions answer he is not going to be involve in the subject.

Tip Involve the BSA in the business requirements gathering process and the definition of what needs to be done; also let the BSA to do the translation as he is the one with technical knowledge (instead of a BA). Involve people with knowledge of the system you are going to update early in the process. If the BSA is new, then give him a good and extensive training of the current application (this is another big an usual mistake).

Cameron Chong

One common mistake I notice is users (BSA’s) not considering the future state or considering that client needs may possibly evolve in the future. My tip is to continuously think of where your product/system is headed within the industry in order to get ahead of the client requirements, and to be ready for what is to come. If you are constantly prepared for the future and getting ahead of potential client requirements, there are less surprises down the road!

Sudhakar Vemuri

Common Mistakes I’ve observed:
1. Making assumptions – Business Requirements are essentially high-level requirements provided by the business and mostly consists of what they want to resolve – ‘Business Problem’. I have seen Business Analysts assuming many details while translating the Business Requirements, to avoid asking the client the finer aspects related to functional specifications and elements of design of the proposed software solution. This should be avoided at all costs as if you assume incorrectly – the entire solution development process could be affected and efforts wasted.
2. System Specifications should be Implementation Neutral – meaning it should be free of design details unless the design has been already finalized. I have seen Business Analysts describing the design of each element on the application screen in the system specifications. This restricts the development team and the Design (UX/UI) team from designing the application as per Industry standards and might result in improperly designed systems which are not intuitive at all.

How to avoid these mistakes:
1. Do not make assumptions about requirements and functionalities expected. Always discuss this upfront with the stakeholders. The Business Analyst should prepare all interview questions before the requirement gathering session, based on experience and also should inform the stakeholders about getting back to them at a later point of time with more questions specific to functionalities and features.
2. A Business Analyst should document system specifications in a design and implementation neutral way, by avoid specifying any design or implementation logic in the requirements.

Dmitry Morozov

1 common mistake I find with especially new to the project process stakeholders is that they would, when asked about their requirements, start to give the technical solutions in the forms of the steps of a software they already have been using previously. The easiest remedy to get on track quickly is to ask them what the project doesn’t need to be doing after a quick brainstorming session to start transforming the “not to do list” into the valid requirements.
1 tip for translating business requirements to system specifications from me would be to try the describing of the business goals into the user stories, which are small and very concise statements of functionality needed to deliver a very specific value to a particular stakeholder.

Rahul Kumar

A couple of things that I have seen that are not ideal for creating a system specification document are:

1. The business requirement is used as the system requirement as well. Though this means there is one less document but it can cause problems as both documents are intended for different audiences and need different levels of detail.

2. System specification are sometimes created by someone who hasn’t interacted with the client directly, like a system architect or a BSA. It can happen that the non-functional requirements requested by the client may get missed; or, the document can be prepared by the BA who prepares the business requirements, but he might not have the same level of expertise as a system architect.
So, there needs to be a sign-off between the system and business requirement.

3. Quality of system requirements document – the system requirements can be inconsistent in their conversion or copy-pastes of the business requirement documents.

Veera Murrale

One common mistake I see when translating the Business Requirement document to System Requirements is talking about only functional requirements and missing nonfunctional and hardware-software parts. One other big one is Load Testing or performance Tuning of the application.

Ashok Gandotra

I have noticed a lot of times that a Business Analyst does not provide enough detail in the functional requirements. BAs often forget that the functional requirements are to be used by developers and they are not business persons. A BA must remember the type of audience who will use the functional requirements.
Another problem often noticed is that the functional requirement document does not provide cross reference to the Business requirement of the same item. This happens primarily due to bulk of changes keep happening on the BRD. Close monitoring of the problem will help provide a clear reference between the two documents.

Ragini Janarthanan

Mistake: Requirements are not gathered from all key stakeholders and thus there is always a missing piece of information in the requirement.
Tip for Translating: Deep understanding of the database is always better to translate business requirements to system specifications as it helps to validate the accuracy of requirement

Rutu Amin

As per my experience, the common mistakes that a BA make is – not elaborating the requirements while scripting it. E.g. writing one liner descriptions in the user stories and not mentioning the minor details. One more mistake that BA’s make is impact analysis. Accepting the requirement without knowing the impact can break the system.
One solution for precise scripting of the requirements is to create a standard SOP for the basic requirements. E.g. requirement is for which region or which flows are getting impacted and so on. There will be less chances of missing out any details while scripting the user story.