Right focus on requirements prevents feature creep

To prevent feature creep, product requirements should satisfy the actual business requirements. Creep can occur when product requirements are detailed but business requirements are too general.

What are some ways to prevent or mitigate feature creep?

Thank you for using the term "feature creep," which actually differs slightly from but usually is more accurate than the more commonly used "requirements creep." In order to reduce feature creep, it might help to define it and understand where it comes from.

Feature creep is the accumulation of small changes to the established feature requirements that can potentially push a project off track. Conventional wisdom says that feature creep is caused by unclear requirements. The testing community says creep comes from requirements which are not testable, usually because they are ambiguous or otherwise unclear. I'm going to disagree and state quite explicitly that most feature creep is caused by requirements that are wrong or overlooked.

What changes is not so much the requirements as the awareness of requirements that could and should have been identified already but were not.

What changes is not so much the requirements as the awareness of requirements that could and should have been identified already but were not. Proposed features keep changing in response to the changed awareness of the requirements. To better understand why I say this, we need to take a look at two very different views of requirements.

A widely held model that is institutionalized in the International Institute of Business Analysis's Business Analysis Body of Knowledge (BABOK) is that high-level objectives decompose into detailed solution requirements features for a product, system or software that when implemented will presumably achieve the objectives. According to this model, the only difference between business and product requirements is the level of detail.

Thus, the BABOK model says high-level vague requirements are business requirements and detailed requirements are product requirements. Conventional business analysis generally assumes that business objectives are easily identified. The bulk of business analysis work focuses on defining the features of the product that are required to meet those objectives. The model further says that design is the engineering or technical detail describing how to construct the product.

I disagree. I find that much of the feature creep I see is created by flaws in the BABOK model. As an alternative, I talk about "REAL business requirements," which I define as business deliverable whats that provide value by achieving objectives when satisfied by product, system or software hows. The whats are observable business deliverables (in the broadest sense -- at work and personal, for profit and not for profit) that when completed achieve the objectives and thereby provide needed value. REAL business requirements are from the perspective of and in the language of the businesses and stakeholders, which includes users and customers.

REAL business requirements usually can be accomplished in many possible different ways. A product, system or software is a high-level design of one of those possible ways how to accomplish the REAL business requirements' whats. In this view, product feature requirements are from the perspective of and in the language of the product. Rather than being a decomposition into different levels of detail, product requirements are qualitatively different from and represent a response to REAL business requirements. As in the BABOK model, engineering and technical design then describe how to construct the product, but unlike the BABOK model, the product is also a design how.

A product and its features only provide value to the extent their implementation satisfies REAL business requirements. My analysis finds that while product requirements' clarity certainly is important, a lot of feature creep comes from product requirements that fail to satisfy REAL business requirements, regardless of how clear they are. Usually the REAL business requirements have not been defined adequately because conventional wisdom mistakenly thinks product requirements are the only requirements.

REAL business requirements are not high-level and vague, but like product requirements, they need to be defined in detail. No matter how far down in detail they are driven, REAL business requirements remain business deliverable whats that provide value when met and never turn into product hows. Defining the REAL business requirements deliverable whats in adequate detail is the secret to designing product requirements hows that do not creep so much.

Next Steps

What is a test case? What is a requirement?

Problem pyramid discovering REAL software requirements

Is a requirements freeze in a software project a bad idea?

Four tips for gathering requirements for the new Business Analyst

This was last published in August 2014

Dig Deeper on Software Requirements Management



Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.
Related Discussions

Robin F. Goldsmith asks:

How does your development team deal with feature creep? Share your ideas with others here.

6  Responses So Far

Join the Discussion



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: