IRNID

December 2008

Define the system, then build it. Seems simple enough. Don’t ask a programmer to build software when its expected behavior is not clearly described. But in most software development organizations, a strange pathology exists that severely hampers this process and adds cost. We call it the “It’s a requirement! No, it’s design!” syndrome (IRNID for short). How do you know if you have IRNID? A typical example can be seen when the business analyst describes the data that the user is expected to enter on a screen, for example, the customer’s first and last name and phone number. Someone then asks what the edit rules are for these fields. Can the first name be blank? Can the phone number have dashes in it? If the answer is “Oh, that’s not a requirement; it’s design,” you have IRNID syndrome.

IRNID defines a strange division of IT labor whereby the responsibility for defining how the system will interact with the user is arbitrarily split between business stakeholders and software developers. IRNID is very expensive from a quality viewpoint:

• “It’s design” usually translates into functionality being decided as the code is built, with little or no feedback to the business stakeholder.  When the business disagrees with the results, expensive change control and rework is needed.
• “It’s design” also means that the test team is stuck with “discovering” functionality when the code is delivered for testing rather than planning for it and designing test cases accordingly. Test costs go up and coverage goes down.
• Delaying functional decisions into the development phase lengthens the total project effort and throws the project off schedule. Costs go up even more.
• Most importantly, IRNID discourages early collaboration among key stakeholders in defining the best software solution. Without this collaboration, software quality issues get resolved through testing, change requests, and rework. This “quality through rework” approach is a major cost driver in many software development organizations.

Removing the IRNID syndrome from software development requires acknowledging that requirements and design are not separable. Any “pure” business requirement typically has several software implementation solutions.  But each solution, in turn, creates additional business requirements that need resolution. Most of these issues occur at a detailed functional level. For example, the business wants to display a large amount of customer data in a customer service application. But technical constraints dictate that not all the data can fit on one screen. The multi-screen design now creates a new set of business requirements to define how best to organize the data across multiple screens so that the service reps can perform their duties efficiently.

If your organizational structure and software lifecycle processes promote the IRNID syndrome, it is time to change. Ensure that business analysts and software designers work together to specify a complete description of intended software behavior before turning it over to developers for construction. Save the cost of change requests and rework by truly describing how the software is supposed to behave before you build it.

Got feedback?
We’d love to hear from you. Send us a note if you would like further information on a specific topic or if you have any questions.

Past Issues
Why IT Budgets are Like Government Entitlements

Stop Scratching at the Surface of Software Quality

The Elephant in the Room

Guess the Project Cost

Is "IT" really this difficult?

Manage the project, not MS Project

The Mythical 4-Month Project

AGILE, INCREMENTAL, WATERFALL: Is there a quality difference?

Automating Test Execution: What You Need to Know.

Check out our videos
Webinar: Why are IT projects so hard (and what can I do about it)?

TMX Product Family Video

TMX 3-Minute Overview