Q

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

PRO+

Content

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.

Join the conversation

7 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How does your development team deal with feature creep? Share your ideas with others here.
Cancel
Feature creep can be a bad thing, but it can also be a good thing. It depends on how well the dev team is communicating with their users. The trick, I think, is to get some sort of model in front of users right away and let their feedback direct the evolution of the project. Your end result might not look anything like the requirements you initially started out with, but that could be A-OK. Better to match the customers' needs and not your original idea than to match your original idea but provide no real value, right?
Cancel
I agree with what you're saying in general about letting users tell you what's needed in a solution. However, you have to make sure you're asking the right users (and only the right users), and that you carefully consider each recommendation and its purpose. The "why" is as important as the "what". Developers shouldn't dictate the end product (nor should any one group), but they are well-positioned to manage the requirements and not let things get out of hand. 
Cancel
Good point. It's definitely important to get the right feedback from the right people. Getting bad direction is worse than getting no direction. Also, developers should have user feedback as one of their guides when designing the application, not as the final design. I suggest presenting a model or prototype to users early as a way to test assumptions. Hopefully, developers and engineers are making the right assumptions. But if not, we want to find out ASAP.
Cancel
Everyone wants to tell you what features to build. However, I’ll reiterate that premature focusing on features is the main reason those features seem to creep. James is right that feature creep can be good in that the changes are moving from the wrong place hopefully closer to the right place. The problem is that feature creep is actually a form of trial and error, successive guesses until finally one chances onto a reasonable set of features. It is usually much quicker and cheaper (in money, aggravation, and reputation) to focus first instead not just on identifying the REAL objectives (which ironically often are not as accurate as presumed) but more importantly on the REAL business requirements deliverable _whats_ that provide value by achieving the REAL objectives. Then and only then is it productive to focus on defining the requirements/features of a product/system/software _how_ to satisfy the REAL business requirements deliverable _whats_. Indeed it is critical to involve all the relevant stakeholders, many of whom often are overlooked. Many of the creeping features turn out to be addressing the REAL business requirements of overlooked stakeholders, again in a typically inefficient manner. When asked appropriately, people generally are much better at defining their needs than designing products/systems/software to meet them, especially when their needs remain vague.
Cancel
Probably this is unavoidable for any development project. The size of creep might vary. Agile takes care of it in a better way to avoid larger chunk of creep getting accumulated by running the things in sprints - shorter ones - and ensuring to carry the customer along the journey.
Cancel
I agree with much of the other replies.  The key to success on an R&D project is to clearly identify the REAL business requirements before proceeding very far into developing its features.  Many programs fail to get inputs from all of the stakeholders, often focusing on higher ranking external and internal stakeholders.  Additional inputs from personnel implementing the features and actual users often occur late in the process (if at all), which definitely adds to feature (scope) creep.
Cancel

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close