"FireShot" For Screen Capture

Fireshot is a godsend add-on (for BAs) for FireFox. With FireShot, the page displayed in the screen can be easily captured, edited (add comment, crop the page, highlight some portion of page). Then this edited image shall be used to explain requirements. You need not open MS Paint anymore.

Accepting requirements gap

While explaining requirements to teammates, if a gap is found, humbly accept it without losing focus / mood / temper. People will point out the gap infront of every team member in the requirements walkthrough meeting. Take it in a positive spirit. Note down the gap and incorporate in the document. Its ok, BAs are also humans and they tend to do mistakes.

Include screenshots wherever possible

While writing requirements, try to include a screenshot (if you are documenting an existing functionality) of the functionalities. If there are no screenshots and only text explains a requirement, chances are that the functionality might be broken in the current project and you will have a tough time proving that the current project broke it. Teammates might just point that the BA have documented wrongly. So, a screenshot of whatever you write always helps.

Reciprocate (like a spring) on clarifications

When a clarification is raised on a requirement from the team and you await clarification from the customer end, make sure the clarification is obtained from the concerned person ON-TIME. If the clarification is not cleared even after 2 days, make sure you follow up with the customer daily to get it clarified.

Bottom line: Developers, testers should always have a clear, unambiguous and unquestionable requirement in mind ALWAYS.

Explain every term in FDD in the FDD itself

Every term you use in the FDD, make sure that the term is explained to its maximum detail possible in the FDD itself.
Example: "The user of this application will be Billing Consultant". The FDD should talk details about who is a Billing Consultant, what is the scope of the user, what all role privileges the user has.

If a term is not explained in the FDD, then it will be logged as a requirement defect. Then, again you will have to update the FDD with the explanation for the term.

Prevention is better any day.

BA role boundary

A golden rule: Mind your work :) to be specific, mind your role.

Even if you posses knowledge on the development language of the project (Java, .Net, C++ etc.,) or you have the brain of a QA person or you have some of the PM's capabilities, maintain limits on the tasks that do not fall under the "BA's Bucket". If you are pitching in their (DEV, QA, PM, Module Lead etc) task, then it might impose a bad impression on you. Though some people will welcome the help that you offer for them, not all will take it in the right spirit. To play the game safe, better mind your role :)

"Lighthouse" Application

Lighthouse - an application for Requirements Management, Project Management, Create and maintain Test Cases, Test Scenarios, Uploading DEV + QA docs, logging defects, defect management, maintaining timesheets. You can integrate all these components, meaning - you can map a requirement to a particular test scenario etc.

I explored the requirements management component and found it a little difficult to use. Not impressed with the user interface and usability.

You may try the Lighhouse application HERE.

Screenshots: Attention to detail

While including screenshots in the requirement document, make sure that all its related screenshots are in sync in terms of data, user interface fields.

Screen A reporting a value of 10 USD. Screen B reporting a value 20 USD. In Screen C, if the requirement is to sum the values of Screen A and B, at this point if the value is displayed as 40 USD in Screen C, then its a clear problem. Agreed that its just a sample screenshot to let the DEV and QA members know about the UI fields properties. But, at a later point of time in the project, when somebody looks at Screen C alone without reading the documentation of it, they will get confused on the calculation of Screen C value. Whether Screen C calculation is wrong / value present in Screen A is wrong / B is wrong? Confusions. If the computation logic is complex (as in Finance / Invoicing etc), then its a much bigger problem.

Golden rule: Screenshots should depict correct values in it, all its related screenshot should also be in synch with it.

Knowledge Transfer (KT) at one shot in the start

Lets assume there are 5 iterations in your project. If the project team (DEV + QA) asks for knowledge transfer (KT) of every iteration at different phase of the project, do not agree for it at any cost. Meaning - if the KT of the iteration's usecases has to start only when the iteration is about to be developed, then its a huge risk that you are taking voluntarily.

• Iteration 1: Development start date is June 1
• Iteration 2: Development start date is July 1
• Iteration 3: Development start date is August 1
• Iteration 4: Development start date is September 1
• Iteration 5: Development start date is October 1

Why?

If you explain the Iteration 1 usecases on June 1 and Iteration 2 usecases on July 1, then many problems would arise. Both the devvelopement and quality assurance team would not have a big picture of the project. They can only see few meters of the road, they cannot see the entire road ahead of them. This might lead to gap in understanding requirements. Rewrite of codes once the other Iteration usecases are discovered during KT. Possible change to database design altogether. Rewrite of test cases, test scenarios for the QA team.

You would also be put in a situation to give multiple rounds of KT. Its not that both the development and QA task of Iteration 1 will end on June 1. What if QA tasks (writing test cases, scenarios) are completed by June 20 itself? Then for the next 10 days, QA team would have to sit idle. In order to avoid this, you will have to do a seperate round of Iteration 2 KT for QA team and another round (repeat work) of Iteration 2 KT for development team on July 1.

To avoid all these, its really better to give KT of the all the Iterations at the start of the project itself.

NO database details in Functional Requirement Document

While writing requirement document, do not even include the database designs - description on database tables, columns etc. Even if you are an expert in DB design, do not describe DB details in a functional requirement document. As BAs, we aren't supposed to include technical details in requirement docs.

Problems with DB design details in functional requirements doc:

• You are a BA. Not a DBA. What's the guarantee that what you had written is correct?
• If the details are wrong, then while implementing the functionality, development team will figure it out and the change in database design will be called as a Change Request. This is unwanted cost for the customer, extra work for the BA to change the requirement document, confusion for the development team as well.
• Lets say a Usecase ABC is using a column "Test_Column_Name" in a table called "Test_Table_Name". In the later course of the project, if this usecase has to be descoped for whatever reason it is, then there are two problems.

- You will have to remove the dependent columns (of that removed usecase) from the requirement document. More importantly, what you are doing should be correct.
- If you forget to remove the dependent columns (of that removed usecase), then the development team will create this column in database. At later point of time in project, this column need to be removed from the table. Unwanted chaos.

Considering all this, the golden rule is: Never bring in technical details into functional requirements document. Technical team is there to figure out technical details.