Friday, December 18, 2009

Components of a good traceability matrix

This article is a guest post from one of my good friend and highly skilled BA Yaaqub Mohamed

Traceability matrix is one of the key artifacts in establishing a conduit from requirements to the finished software. Assuming that a Business Analyst has captured all the requirements effectively from the relevant stakeholders, a traceability matrix ensures that all requirements get traced to the corresponding software functionality. The key word here is: "Corresponding".

What is a traceability Matrix?

A traceability matrix consists of mapping data. How a particular information is mapped into another. In most cases it is an effective means of establishing validity and connectivity of various project artifacts. Each organization has its unique way of creating and maintaing traceability matrices. An example would be, the requirements traceability matrix - mapping the business requirements to say system requirements, test cases, design document, etc.

Components of a good traceability matrix:

Accounts every requirement: A good traceability matrix accounts each and every enterprise requirement to a specific or a set of business requirements. If an organization creates system requirements, then the matrix also ensures that every system requirement is mapped to some business requirement. The most important functionality is of course the ability to connect every requirement to some test case. This ensures that the requirements proposed were captured in the right language, and were testable in nature.
Has an ID system for absolute tracing: It is considered a best practice for a business analyst to ID every requirement with some agreed upon convention. Carrying this forward, system requirements, and test cases are also given unique IDs. A good traceability matrix uses the unique IDs of various requirement specs, and test cases to establish the connection.
Spans across multi dimensions: Multi dimensional in this case means, across various parameters. A good traceability matrix establishes connectivity across different project artifacts if required. (Between design documents, process flows, etc)
Has alert formatting: Another trick a business analyst can use while setting up a traceability matrix is to conditionally format a requirement spec cell (if a spreadsheet is being used to capture requirements) if it is not traceable to a test case or vice versa. This concept of alert formatting can be applied for other types of traceability as well. This can act as a foolproof method of validation and ensures that there are no "orphan requirements".

In conclusion, a good traceability matrix enhances the effectiveness of requirements capturing, and testing activities of a project. It ensures that other team members understand the requirements well enough to trace their own artifacts. So make sure to devote some extra time in your requirements capturing activity for establishing a solid traceability matrix.

Wednesday, December 16, 2009

Note taking skills

As a Business Analyst, a basic part of our daily routine is note taking. Many a times people underestimate this but this is a skill which comes very handy.

So what is note taking... What are the best practices... When should you take notes..? Let's see...

It is a best practice to always have a note & pen with you, better yet carry a file with the most essential items. Generally your file should contain a notepad, a pen, a calculator, a highlighter and some markers at a minimum. You may also carry other things which are very specific to a particular meeting for session.

Ideally it is best for a Business Analyst to record everything that is spoken in a meeting. Sometimes this may get very difficult so probably short hand skills may be helpful :-) But it is always good to have short notations for specific words which help you jot down the points faster. It is also good to diagrammatically represent things like for instance when a process / application flow is being discussed. It is sometimes necessary to capture who said what if it is a meeting where many of the primary stakeholders are meeting to make decisions.

Sometimes it will be best to record a meeting and play it later to make meeting notes. But this option may not be allowed in all organizations.

Also a common dilemma faced by every Business Analyst is should I capture what is being said as-is or the hidden meaning behind it? For instance, there may be a feature which is being discussed in the meeting and one of the stakeholders may say that this feature will not be entertained in this project. But at the same time the BA and the stakeholder know that the feature will be implemented in one of the future projects. So should the BA clarify this in the notes? There will be plenty of situations like this where the BA will have to make a decision based on how much information needs to be clarified to the readers of the meeting minutes.

Also sometimes the BA may not be able to capture everything that is said either due to the number of people speaking at the same time or due to the size of the room or if one of the stakeholders is speaking soft. In such cases, it is always a good practice to make sure that another BA is attending the meeting to capture the notes. At the end of the session the notes can be shared by the two BAs and a consolidated minutes can be made. If it is is not feasible to ask another BA to attend the meeting then it would be a good practice to mail the stakeholder asking any points which they made to be clarified. Sometimes the BA can make meeting notes in the conference room itself with it being projected for everybody to see. In such cases it will be easier for the stakeholders to clarify their points as needed.

Another nagging question is to what depth should the notes be scribed? Is it necessary to just highlight the primary points or is it essential to document every little statement that was made? Again this depends on the meeting and who the audience of the meeting notes would be. The BA may also have to create two different versions of the notes, one for senior management and the other for the rest of the SMEs.

If any presentations, diagrams or process flows are presented in the meeting, it is always a good practice to link them from the meeting notes. Also list the people who were invited versus who attended the meeting.

Apart from taking notes in meetings, several times a BA will come across other stakeholders either in the lobby or near the water fountain. They may start a topic which might be of relevance to the project or they may clarify some of the questions asked by the BA. So it would sometimes be essential to capture their points. So as previously mentioned always have a note and pen handy for such impromptu sessions.

It is also a good practice to highlight important points by making text bold or italicizing them to draw attention to them.

In addition to it while taking notes, the BA might have jotted down several references which serve a helpful purpose either while scribing the detailed notes on the PC or for future reference. So it is always a good habit to file all the notes and archive it. You never know when you might to need to refer back to it.

I guess these are some of the best practices when it comes to note taking...I hope you have noted them... :-) Please do let me know if I have missed something from these notes...

Wednesday, November 25, 2009

Keyword Based Reading...what's that again?

I am republishing this post which already appeared on one of my other blogs. I think as Business Analyst's we have to think on our toes and many a times we have to be able to grasp a new domain or knowledge base in a short span of time...so the below technique might be helpful to many of the BAs out there...I hope! :-)

You must have all heard about ‘Keyword based Searching’, ‘Keyword based Testing’ etc. ‘Keyword based Reading’ is a new phrase coined by Moi…This is a technique which will help you to read up on stuff and get specialized in a orderly way and also harnesses the power of the Internet as you all know we are not living in the age where we just had to depend on the neighborhood library for our daily dose of knowledge. You can use this technique if you are currently working on building your skill-set for the job market or even if you just want to build up your knowledge in a particular field. This technique uses the power of the Internet to sharpen your skills. It is something which everybody already does but I am just putting it in a package...and this is something which works for me…atleast… J


So the process goes like this. Say you want to learn more about the field of Testing.


So as a first step do a research on the set of all the keywords related to the field...in this case System Testing, Unit Testing, Black-box testing, Functional Testing, Regression Testing...etc. So once you have gathered a good set to start from proceed to the next step. Keep this set at a high level and do not have words which are very specific to a sub-field within…


The next step would be to take each keyword and research on the Internet. So document each keyword and the relevant links associated to each of them. It is always good to have a mix of the below for each keyword:


- General info sites like wikis

- Sites with people who have blogged/discussed on the topics

- Sites with podcasts, videos on topics like Youtube, ...

- Sites with white papers

- Sites with online books (good to have a subscription with sites like 24 X 7, Safari)


As a third step, if you are parts of some networking sites like LinkedIn, Facebook you might also get additional information related to these topics like webinars, discussion topics etc. Go ahead and attend and be part of these. You can also post questions at different forums to get answers from the expert community. You can also subscribe to RSS feeds of the topic that interests you.


Also to top-off read off-beat things related to the topic like jokes, cartoons etc...if there are any available


So once you have gathered this information go ahead and read and gather as much information as you can. It would be good to first read at a high level and then go deeper in whichever topic appeals to you.


Then finally to ensure that you remember all that you have read, blog about the main points on your personal blog and share with all. If it is something related to a tool or programming language go ahead and download the free trial of the tool if one is available or start cooking…ahem..I meant coding!

Enjoy building your skill-set!

UGKV2PV9RG45

Wednesday, November 18, 2009

BA Role - A must or just an add-on?

Recently I came across this cartoon on one of the BA related sites. This set me thinking...I have experienced that in many of the projects a BA's role is considered to be just an add-on for the sake of project planning. That is sometimes the general attitude towards BA's in, I would say many of the organizations. But is the BA shoes really something in which anybody could fit in?

The question can be answered from a few different perspectives. A BA's role generally gains importance based on what phase of the project they are working on. Also an experienced BA is always a very valuable addition to any project team as they bring lot of insights by doing in-depth analysis and research. Also if the BA is proficient on the technical side then there is nothing like it. They can help in many more areas outside of the defined 'BA Zone'.

Like I discussed in my previous post, a Business Analyst generally has to perform more roles than one, then why is the BA role itself considered to be complimentary? In my experience myself including some of the other BAs I have worked with have performed valuable tasks which were of great value to the project like:
- In-depth analysis and representation of existing system logic
- Additional research in other lines of business to draw out functionalities that might have been missed
- Providing excellent end user training which saves a lot of Training dollars (as there is no need for a separate Training team to do the same)
- Digging into the features of any new tools adapted and then training the rest of the team on it
- Playing a very valuable role during the System Testing and Production testing phases where BA's perform tasks like documentation of system test cases, testing and reporting of bugs, set up of test data and also providing suggestions to the IT team on fixing the bugs
- Coming up with highly intuitive 'diagrams' of various Systems and Business processes
- Creation valuable documentation which are the go-to assets even months / years later for getting knowledge on any of the application / system

The above are some of the ways in which a Business Analyst adds value and I can vouch that there are many more.

So in conclusion, I would like to state that a BA role is not just an add-on. It just depends on the project manager / coordinator on how well they can utilize a BA and not just limit them.

Basically a BA role has no limits defined!

Monday, November 2, 2009

Travails of a Business Analyst...


This blog is the first in my new blog roll related to Business Analysis...I am starting off on a slightly negative note there...but it is only because I am a Business Analyst ... :-)

I will keep this post short and discuss why I have used the word 'Travails'...

Actually as a Business analyst you have to don multiple roles in addition to your daily defined job...A Data Analyst, A Data Modeler, A Tester, A Project Manager and sometimes a coder too...

You should always be on your toes and keep yourself abreast of the latest technologies and work on improving your skill-set since you never know which role you have to don...

So you need to be well-versed with Test Director as much as you are with RequisitePro...you need to know thoroughly the Agile methodology as much as you know the RUP methodology...

So...this blog will throw some light on the daily life of a typical Business Analyst...some blacks...some whites and the rest of the VIBGYOR....

Watch out for more...