I once was at a lunch with a group of product managers who were kicking around end-result visions of an upcoming Feature.
In reality, their Feature was more of an Epic – they were actually starting with nothing but a good idea, expressed as the Feature’s title. Somehow, they succeeded in justifying the project to gain sign off and budget by the executive steering committee. At some point, there had to be a discussion on the purpose of the Feature, yet no record of what came out of that discussion existed.
Misunderstanding this tenet of the Agile Manifesto: Working software over comprehensive documentation seems to be a common mistake among new agile teams, believing that eliminating documentation altogether adheres to this principle. This couldn’t be further from the truth 'Somewhere, someone needs to document something: requirements, business rules, pre-conditions, use cases or user stories, acceptance criteria, etc'
Although I wasn’t there at lunch in a BA capacity, I couldn’t help but ask questions about what they most wanted to see at the end of development. I asked about integration with other systems. I questioned end user roles. I wanted to know as a peripheral business user, how this new feature would prove to be an improvement over the existing process. The elicitation resulted in more than several would-be requirements written on the back of just as many cocktail napkins.
If I had been the BA, I would have asked for those napkins before leaving the restaurant so they’d not be lost or forgotten. Instead, I reminded them to transcribe their notes directly onto the Feature in the portfolio management tool back at the office.
The requirements they had identified were by no means complete, crafted well, or yet known to be feasible, but once they underwent documentation – they became tangible artifacts of evidence associated with the impending project. At this point, for the project they were discussing, the Requirements Life cycle began right there, at that table of stakeholders who became engaged in the documentation of requirements.
Because requirements are the spine for the development of any application and until the application is Live, the changes are unpredictable. BAs therefore, play a crucial role in managing the project requirements – benefiting both the development team and the business owners. Fixing the issues during development is much easier and less costly to fix as a part of a change request or defect backlog.
Most of us don’t think of a requirement having its own life-cycle. However, as I noted in describing my lunch with the product owners, management of the requirements begins from the moment a customer articulates and provides their need, or from when a product development process starts. It includes managing the definition, elaboration and changing requirements during the development cycle and systems development, e.g. trace-ability.
Did you know the Requirements Management Life-cycle, is a distinct and specific knowledge area of the BABOK©?
Whether or not you plan to attain CBAP certification, improving your understanding and skill set in the area of requirements engineering and management is as important as knowing how to elicit them in the first place.
There’s no doubt that keeping a handle on established requirements that morph or spawn additional requirements can prove challenging. The problem becomes more difficult by a lack of defined process to capture all requirements in the right way. Essentially, Requirements Management is the set of processes in systems and software engineering that interfaces with requirements engineering.
As the requirements undergo analysis and refinement, a good BA knows the importance of control. By identifying and monitoring the needs of the business and the stakeholders, and to apply the most suited and accepted solution, requirements management helps in understanding the effects of the change requests on the current state and also helps in linking the business goals and objectives to the actual solution that is constructed and delivered.
The BABOK® knowledge area of Requirements Life Cycle Management includes the following five distinct Business Analysis tasks:
Requirements Management Status Reports identify the status of the requirements repository.
Status reports typically include traceability coverage
It also helps to ensure that business analysis information is available for future use.
In conclusion the requirements lifecycle:
The definition of weak requirements: incomplete, incorrect, unclear, unnecessary, too broad, misunderstood, or redundant. They are THE number one reason for project failure.
Credit: Phyllis Rieff
Would you like to write better requirements and learn how to manage them more effectively?
Then I highly suggest you enroll for our BA Career Coaching.
Contact us at Jadetan Enterprises Ltd via
Tel: 0844 884 5311