Software requirements and the decisions made relating to them, carry through from the point of conception till the product is working in the live environment. One of the key decisions that need to made during software projects is the priority of 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
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.
As professionals, we typically make decisions based on logic and information that is available to us. For example, Business Analysts typically make decisions on which techniques to apply when solving business problems and assist stakeholders in making decisions on which solutions to adopt. Cognitive biases can lead to bad decisions and errors in judgment and as such, BAs should be aware of them.
As discussed in the previous article, Solving Complex Business Problems: An Introduction to Soft Systems Methodology, the steps of SSM can be applied in any particular order and the analyst may choose to skip or apply steps depending on what is needed to understand the problem situation. The steps of SSM that will be applied in this article include:
Some business problems are by their nature, complex to handle. Due to their complexity and the non-suitability of traditional problem solving methods, Soft Systems Methodology (SSM) can be used as the methodology for arriving at recommendations for action and positive change. This recommendation for action can range from making minute changes to a process to introducing a new information system.
This list of requirements prioritization techniques provides an overview of common techniques that can be used in prioritizing requirements.
Selecting a Requirements Management Software should be done with as much care as when selecting any other software. You should identify which features are required for your project beforehand and assess if the tools currently available to you do not already meet your needs before hunting for requirements management solutions with all the bells and whistles you don't need.
Although it can be challenging to keep the glossary up-to-date and for stakeholders to agree on every single definition contained in the glossary. The effort spent is well worth the benefit of developing accurate requirements due to a shared understanding of business terms.
Managing change requests is particularly important in ensuring that the business does not spend its limited resources on changes that offer no real value at the expense of projects that can deliver real value and lasting benefits.
The Business Analysis: building better stakeholder relations through prototyping article, published on Justinmind blog, discusses 6 tactics that can help Business Analysts create good stakeholder relationships throughout the software development lifecycle. One of them is incorporating excitement requirements to increase stakeholder satisfaction.