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
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.
According to Stephen Ward & Chris Chapman in their piece, Stakeholders and uncertainty management in projects, “Stakeholders are a major source of uncertainty in projects and this uncertainty stems from whom these stakeholders are, their motives, and how they can influence a project.”
It is this uncertainty that constitutes risks to the project. BAs should relate with other project stakeholders to overcome this uncertainty by improving their ability to convince stakeholders to see things their way, thereby influencing the course of the project.
BAs can learn a lot from UXers, that much is certain. But perhaps the most valuable thing the two disciplines can learn from each other is working together. Both roles have the same ultimate aim—to produce a product that has business value and meets users’ needs. The approaches may differ but are far from conflicting: BAs create value by delivering good features and functions, UXers by delivering good experiences. Guest Post by Cassandra Naji
This post is a compilation of websites with resources that can boost your technical skills, and help you become better at work. If yours is one of those organizations that have cut back on training programs; you've been assigned to a new project or perhaps it's just out of pure interest in the world of techies, you’ll certainly find these websites useful.
It’s best to select a small number of key attributes and establish a system that allows us to add more requirements attributes as we go along, depending on the nature of the project and which attributes are deemed necessary.
As development practices change, so do the reasons why we write requirements and the level of detail we go into with Requirements Specification documents. Even seasoned business analysts have at one point or the other asked themselves, “What level of detail is enough?”. The answer to this seemingly simple question is surprisingly complex and is inseparably intertwined with the reason why we write requirements in the first place: so that they can be read, understood, and implemented.
The main goal of all business analysts is to uncover unknown risks and requirements during the requirement discovery phase. But as many business analysts will surely attest to, sooner or later, the problem of scope creep inevitably arises, unless one takes concrete steps to prevent it.
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: