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
It’s common knowledge that people tend to resist change as much as they can. However, without change, there can’t be progress and BAs would certainly not have that much to do. When working on large projects, change requests from stakeholders are to be expected. Successful project managers and analysts know how to manage them without bringing the project to a standstill.
How can BAs ensure requirements are practical, achievable and in line with the strategy and capabilities of the business?
The Business Architecture offers a starting point.
While there’s nothing like having some experience under your belt, Business Process Management (BPM) certifications can aid analysts in some key ways: they serve as concrete evidence of business process management knowledge; offer the opportunity to learn new concepts /best practices; and benefit from the experience of trainers/mentors.
When elicitation focuses on identifying exceptions and failure points, it’s a form of risk management. The idea is to find potential solutions to these questions and include them as part of requirements to reduce the probability of missing out on critical requirements.
The relentless pace of technological progress drives businesses to work on increasingly more complex projects. With this increased complexity comes new challenges and roadblocks that business analysts must learn to overcome.
Business Analysts play a pertinent role in determining what functionality a system should or should not have. If you can ask these questions of every requirement, the implemented solution will have a higher possibility of acceptance:
Are you having a hard time influencing management or selling your business recommendations to the powers that be?
This article outlines 8 approaches to get management’s approval for just about any project:
Governance seems to be one of those frightening words that threaten to stop an Agile transformation effort dead in its tracks. I’ve been hearing it whispered, and even screamed once or twice, quite a lot recently. There’s no big surprise here. As the big corporations and Government agencies get increasingly fascinated by frameworks like Scrum, they are mandating their IT departments to “Go agile” and then, sooner or later…governance!
In preparing a business case, the business analyst is often required to conduct some measure of cost analysis. When highlighting the benefits associated with an initiative, it is extremely important to also indicate the costs that will go along with implementing the initiative. Information regarding costs is particularly important in making go or no-go decisions when deciding which projects to implement. The business analyst should work with the project manager to identify these costs and arrive at realistic estimates.
Managing stakeholder expectations is essential to business projects' success. If you know ahead what stakeholders “expect” the system to do, you can advise them of this well ahead of time to avoid disappointments further down the road.