[content] => 
    [params] => Array
            [0] => /forum/index.php?threads/a-little-ot-how-do-your-organizations-address-requirement-bloat.16505/

    [addOns] => Array
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021171
            [XFI] => 1050270

    [wordpress] => /var/www/html

A little OT - How do your organizations address requirement bloat?


Active member
In the division of the company I work for, requirements bloat and creep are sort of an accepted normal, and very few people even bother to properly challenge requirements. Worse yet, while we have processes in place that are designed to stop requirements creep, they are rarely honored. It's fairly normal for PMs and service owners to accept new requirements without considering the short and long term cost implications, or even the full impacts on existing priorities.

Since the complexity and success of the work done in Semiconductor design and manufacturing are clearly influenced by the requirements gathering and related processes -- I was wondering if some of you could share your experiences on what works for trying to address both requirements bloat (initial pass), and creep (post-requirements review). What are your thoughts on quantity vs quality of requirements, did you try something that failed, etc..

Lastly, if anyone is aware of any good references for the increasing cost of requirements over time, I'd love to read that. (For example - if it costs 1x to write a requirement, it might cost 10x to design, 50x to support, and 100x to change/"fix".. )

Thank you!

P.S. When sharing, please let me know if you're discussing abstract requirements (such as a customer asking for a bid on support where they want to see your innovation), or 'concrete' / functional requirements (such as the container must hold 1 liter of water).


Active member
Go on offensive

Often people going under the "requirements manager" are clueless themselves, so tick every checkbox.

People need quite a bit of ego to intrude on client/internal client domain, and tell them "to do this, you need that, and that"

Deeply investigate what they want, focus their attention on a single use case, or as few as possible, make them understand how much nuance there is to ace their most critical requirement.

After that, it becomes possible to steer the client into "doing one thing, and doing it well"


I have recently been re-reading the classic "Parkinson's Law" ("work expands to fill the time available for its completion" - also the related "expenditure rises to meet income").

Whilst these have nothing specific to do with the IC industry, they do apply to most organisations - and the larger the worse it gets.

Based on this, I would prescribe, smaller, over-worked teams. Or risk Brooks' First Law.

Being more serious, I had some experience a few decades ago with Tom Gilb's approach to software development and specifications and found that helpful.


Active member
You will need to manage client's attention.

If you let client weer off too far, or too long, they forget about critical features, and began to think "what if, and that"

You need to make them think that something always threatens the main thing, so they don't even have time to think of anything else.

A lot of times they may not even realise how much nuance there is to the critical functionality.

One trick I learned to keep clients focused is metrics, and comparison to the competitor.

Having them hear "we are still losing 18% on perf per clock for the feature Y to competitor X, but we have done a 5% improvement in prototye Z"

Then they will start asking questions, and it will be a good chance to steer them into doing things which matter, rather than things they want.