September 4th, 2014
by inflectra
It is a month till release, and the CEO comes out of the office and says we need a new feature for the release. A week later he modifies the new feature. The developer works hard to please him and delivers, but he doesn't like it. The requirement changes again and now we are a few days from release. how are we going to debug, test, and verify for release if things keep changing?
I believe we have all been in this situation, sure it may not be the CEO, it might be a top tier customer or anyone else who happens to occupy the bully pulpit at the time. The question is: what should you do? how do you say no? how does QA/development manage the requirements?
Requirements Can Change
Requirements are not cast in stone. Requesters and stakeholders are developing ideas, insights, and more knowledge of what they really want over time. it is an evolution to the end goal, and it can change. sometimes the change is for the better, other times it seems like a rabbit hole. It may seem that requirements can change at any time in the process, but with a little forethought and process, requirements can be managed such that late changes are not nearly as devastating to a release or QA cycle.
Managing requirements can be compared to herding cats. About the time that you get one in line, another goes awry. The only way to address the management of requirements is to follow a systematized approach. The team needs to track time, activities, effects, and the priority of each and every task associated with each requirement. Not only must everything be tracked, but a strong link of communication must be in place to deliver the results of this tracking to the stakeholders. In this way the stakeholders are “in the loop” as to the effect on budget, schedule, release, and daily routine their changes make. This is what helps you keep the cats in line.
The SDLC requires requirements, after all you need to know what is being developed and tested. From the QA arena, we truly need to know the intent, not just a one line statement. We need to know how and why a requirement exists so that we can design meaningful test cases to prove or disprove a requirements state.
Some Requirements Management Tips
A few tips for managing requirements, not a complete best practices, but a good start:
- Tie a requirement to a planned release: framing a requirement in time by tying to a release provides the first step in determining order of execution.
- Select an importance level: importance provides an order to those items within a release
- Set the type : is this a new feature, a user story, a critical element. Can assist in setting priority
- Componentize your requirements : by creating logical groupings around major components and features allow for appropriate assignment. This also provides structure to the requirements that makes them easier to read and understand.
- Set regular reviews : Create a specific date for reviewing requirements and make assignments to the stakeholders to get sign-off, this is critical in insuring that communication is delivered constantly
- Do a baseline : by getting baseline Sign-off on requirements, you can more easily track changes to the system that may affect schedule and costs.
- As changes are made, provide an impact meeting : showing the difference between base-lined requirements and updated or changed requirements will greatly reveal the true cost of changes.
- Traceability, you need it : without traceability the true impact of defects, cases, and changes will not be known. Providing traceability allows you to provide empirical data behind the delta.
- Versioning is critical : requirements management also implies that you are versioning your requirements. Arbitrary changes to requirements breaks the chain of being able to trace change, and it will bite you if there is a rollback.
- Be verbose : attaching documents to a requirement may seem like overkill, but the full documentation of a requirement is a good way of documenting intent. Also, no one word comments please, write all that is necessary to fully explain your position, it will avoid questions and mistakes later.
We are not discouraging changes, but it is important to understand the scheduling and cost challenges that come with them. Changes should be thoughtful and well planned.
Of course, all of these elements can be completed in a text editor, by hand, or spreadsheet. We recommend making your life easier and trying out SpiraTeam to see how easy it is to facilitate communications in requirements management.
requirements management
SpiraTest
SpiraTeam
SpiraPlan
RemoteLaunch
Rapise
KronoDesk
TaraVault
SpiraCapture
Cloud Services