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.
Friday, December 18, 2009
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...
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...
Subscribe to:
Posts (Atom)