Building custom solution for a customer is challenging. The most challenging part in building custom solution is change requirements. We already know, there is no stable requirements. Every requirement that customer said can be replaced, changed, or added. In requirements engineering, a way to make requirements stable is by doing requirements managements. In this article, we will discuss what requirements management is and how to make sure it can be worked in the requirements that we already developed.
Requirements Management
Requirement management is part of requirement engineering. As we know, requirement management consists of two components. The first one is requirement development as a technique to obtain requirements. The second one is requirement management a way to make sure the requirements can fulfill expectation without sacrificing the development teams. The detail of requirement management can be read here What is Requirements Management | IBM
Although the principle is similar, requirement management can be different in Agile environment. In Agile environment, the requirement management is not structured as in the formal one. The product owner or product manager should handle the requirements management in daily basis. There are several principles that will be adopted in Agile environment.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
There is always 'version zero'. The user story should have version zero. Initial version that will be modified and changes. The team should discuss with the customer for the initial version of user story.
There should be regular meeting with the customer on each iteration. The regular meeting should be happened at least weekly.
There should be a proof of concept (POC). The POC can be viewed by the customer to validate the requirements. Ideally the POC should be sent after a week of regular meeting. The customer can say go or not go based on the POC.
There should be acceptance test that can be tested based the tester or customer to validate the requirements.
There should be unit test for the user story that 'complex' enough to validate and can be done automatically.
There should be a versioning of the user story. This is to make sure changes is documented and logged.
Requirements Changes does not mean it should change!
In agile environment, it is said that the requirements will be changed, and you should manage it. I recommend you to read Agile Requirements Change Management (agilemodeling.com). And here are the quick tips.
When changes happen, do a discussion with the team. What the impact of the changes.
When there is an impact, there will be additional work of solution. On this stage, choose which solution that can be done by the team with two considerations.
Perfection of offered solution.
Least of work solution
The development team chooses which offer that will be given to the customer.
The product owner / product manager will tell the customer about the changes and the 'additional' work and budget.
If the customer agrees, the product owner will add the changes of the user story into the next iteration / sprint.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";