Software requirements and the decisions made relating to them, carry through from the point of conception until the product is working in the live environment. One of the key activities that need to be completed during software projects is assigning priorities to requirements. The priorities of critical requirements can be preserved by ensuring these requirements are linked to their test cases as the project evolves from one phase to another.
The importance of requirements traceability becomes more apparent further down the line when defects are identified during the course of software testing. Resolving all software defects discovered during testing can be quite challenging (almost an ideal) given the limited time, funding and other key factors that affect software implementation. Since it may not be possible or even realistic to fix all software defects, it becomes important to prioritise the defects that are to be fixed based on their severity levels (their impact on the system and the business as a whole).
Defect reporting should draw on the priority of individual requirements and not be done in isolation. Testers should also not assign severity levels and priorities to defects until the importance and priorities of underlying requirements are well understood. Requirements traceability can help to ensure that:
- Key requirements are addressed and not left on the table when the product is finally released.
- Severity levels are only assigned after due consideration of the priorities of the requirements to which they are linked and
- Software defects that are potentially out of scope of consideration are identified, for example, those that arise based on a user's unstated expectation of how the system should work, which are of low significance to the business.
Requirements Traceability Matrices (RTMs) are especially useful here and can be used for tracing user requirements and linking them to their test cases. They can be used by testers to ensure that the defects recorded per test case are linked to their originating requirements in order to assist the business in assessing the effects of fixing a defect or postponing the fix till a later release.
Picture Attribution: “Chain” by Salvatore Vuono/Freedigitalphotos.net
This post comprises a list of free training that business analysts can use to gain the knowledge and experience of what to do when practising business analysis within the context of business intelligence.
The list below comprises a list of free business analysis training courses that can help you hit the ground running whenever you practice business analysis within the Agile context. They are as follows:
It's that time of the year again and here is a list of the most popular 2016 posts, as determined by BAL readers. This list is based on the number of page views received by each post.
Here it goes:
We make hundreds if not thousands of decisions every day. Some more important, others less so. With each decision we make, we shape our future and possibly, come closer to the attainment of our goals. One of the most effective ways to increase productivity and make better choices during requirements elicitation is by organizing facilitated sessions among stakeholders.
Documentation of software requirements should not be seen as optional, but a necessity. While the level of detail may vary depending on the approach adopted, be it Agile or Waterfall, it’s important to keep in mind why documentation is needed in the first place, before one goes too far in the wrong direction.
Needs Analysis is similar to business analysis especially in the sense that it is used to determine the needs of the business, and is centred on understanding the issues and opportunities faced by the business with the objective of finding resolutions, defining approaches to resolving issues and exploiting opportunities. In summary, it’s about:
Regardless of size and complexity, the goal of the business case remains the same: to convince decision-makers to approve a proposal. Here are some of the things a business analyst must keep in mind for a winning business case. Guest post by Shuba Kathikeyan
From analysing data and preparing deliverables to supporting stakeholders through other stages of the solution development lifecycle, the role of the BA is certainly key to successful projects. The end of the elicitation event does not signify the end of business analysis activities, but the beginning of the BA’s involvement in other aspects of the project.
A Design Thinking approach enables Business Analysts to solve the wicked business problems they’ve always faced, but from a user-centric standpoint and following an iterative process. Guest Post By Cassandra Naji.
If you understand the sources of your mistakes, you are better able to take the corrective steps that will help you avoid those mistakes in the future, fill the knowledge gaps you have and become a better professional. This article is based on the ideas from Mindset Works.