Requirements Creep In Software Engineering
Requirements Creep is defined as a bad process that lets in a user choose that the specification needs to include certain other requirements that are very near to the current story or specification in the backlog. This happens at a vary early stage of software development process where you need to change your specification in a Requirements Management software and highlight those requirements that are key components in it.
At a very early stage of project or the beginning of development of a feature, a responsible developer asks for all the project interfaces before developing it. A developer who makes decisions based on the project scope, will only develop the key highlighted requirements and build and share a high-fidelity prototype for receiving stakeholder feedback.
In order to prevent requirements creep we need to quantify each requirement and qualitatively analyze every requirement in the requirements pool.
Requirements move from Sprint Backlog to Product Backlog at times, so it is always essential to add the requirements to the Product Backlog. The ownership of the Product Backlog is questionable when there is no dedicated Product Manager (PM). If a PM is available, it is essential to contact the PM to add the requirements to the Product Backlog.
Quality Gateway, Prototyping the requirements, Doing Requirements Retrospective and Taking the Stock of Specification are four key stages that play an important role in preventing requirements creep. Agile Requirements Refinery is a cycle through which requirements get past:-
(1) VISION stage,
(2) CONEPT stage,
(3) THEME to the
(4) REQUIREMENTS DEFINITION stage
By making use of Sprint Planning and Retrospective and going through the Backlogs on a repetitive basis. Traceability on Requirements must be implemented in order for them to be traced from parent to child and vice-versa. They are easily representable by Feature Driven Development (FDD) based Requirements using a Dotted notation and a Title tag. FDD is performed exhaustively on feature by feature basis by building a features list.
In Quality Gateway, the right questions to ask are:-
(1) How much of the requirements are refined,
(2) How much of the requirements are traceable,
(3) Are fit criterion passed for every requirement
Requirements prototyping starts from paper-based to low- fidelity ones which mimic the behavior of original application, and to high-fidelity ones which are convertible to the original application. Prototyping must be done at every stage boundary of the project and they are aligned with the look and feel of the original application.
Prototypes convey essential requirements that cannot be communicated in writing. If a user journey is captured by the prototype, the it is ideal to be monetized upon feedback. Feedback is really important for prototypes as that is the only way to validate the assumptions.
Retrospective is a useful stage to discuss on what went wrong, what went well and what is going to be done. In retrospective, we discuss the rationale for using that requirement. Post processing stage in Agile from retrospective is Sprint Planning. Discussion of non-functional requirements such as Political, cultural, performance, usability, look and feel happen during retrospective. The alignment of goals happen at Sprint Planning which makes the member plan for coming sprint.
When taking the stock of specification, it is essential to understand the client satisfaction and dissatisfaction feedback to be recorded for managing them for the next Sprint.
The status of the satisfied requirement must be addressed at the gateway and the status of the requirement that is under dissatisfied state must be addressed at the deployment. This is to ensure even though the go and no-go decision is cleared, the gateway is checked for the satisfied and we check for the deployment status such as for the code quality when the requirement was in dissatisfied state. This enables us to punish the deviated ones and score the correct ones.
Requirements Creep is also referred to as the wear and tear that happens to a product specification.
A Gantt Chart
