Image for post
Image for post

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.

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.

Image for post
Image for post

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:-

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.

Image for post
Image for post

In Quality Gateway, the right questions to ask are:-

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.

Image for post
Image for post

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.

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

Image for post
Image for post

@aha.io

Developer | Scholar | Computing | Data Governance

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store