Great Software from Great Requirements: A Software Best Practice

I’m not in love with “requirements”.

There are some who think that “Requirements” are the be-all and end-all for building great software.  They’re not wrong, but they are off by a third of a bubble.

Great software companies come from creating and bringing to market (with a great “go to market” strategy) quality software that solves one or more significant problems for an appropriately chosen target audience – and does so measurably better than alternative solutions.

Software Requirements

How does such successful software happen? Certainly not by accident.

It comes from truly understanding the “target customer” – their needs, their
plans, and their pain, the severity of their pain, their ability and willingness to spend money to fix that pain, and knowing what other alternative solutions exist for
them (and how your proposed solution compares).

And this understanding of target customer needs MUST be done at the earliest stages of product conception to be effective.  Otherwise, it’s like trying to build the foundation for a house after the house is already built.  Not an effective strategy (although it may be a rational one, if you inherit a house that someone else built that lacks a foundation).

This understanding along with the proper people, communication skills and training,
time and effort yields requirements (and priorities, which are embedded and inseparable from requirements by my definition).

It also is critical to the formation of a strong go-to-market strategy.  Depending on how you look at it:

  • Great Software + Great Go-to-Market = Wild Success; or
  • Great Go-to-Market includes Great Software = Wild Success

I’d like to refer users to an outstanding article on SandHill.com by Tony Zingale from Jive Software: “Tips for Thriving in the Software Market“.  It’s about knowing the customer & market and creating great go-to-market strategies.  Tony knows a thing or two about successful software companies.  Jive Software filed its S-1 five days ago for an expected IPO that could raise up to $100 million.  He’s done a pile of other great things too.

This deep understanding is the soil from which all good software things grow.   I
suppose if deep understanding is the soil, then requirements are the manure
that makes the soil fertile.  Although perhaps I’m taking this analogy too far….

Requirements are not a magic solution for every software problem, however.  That’s where “Requirements Evangelists” are off by a third of a bubble.  If you have a weak go-to-market plan, then requirements mean nothing.

Not to mention, lot of things can go wrong in the creation of software “post-requirements”. A fair amount of bad software has been created despite the best of
requirements.

But almost no good software has ever come about in the absence of solid requirements and priorities.  So, those who are Requirements Evangelists, keep on evangelizing – as, solid requirements and priorities are a de-facto prerequisite to the creation of quality software.  By quality I mean both “useful” as well as “minimal defects”.

Yes, some great software has been created without benefit of good requirements, but “luck is not a strategy for success”.

Quality software is what drives the success of software companies.

Quality software is what helps corporations and other organizations run better and
gives them an advantage in the marketplace.

Properly done, requirements are one of the embodiments of true understanding of the
customer.

“Know thy customer” is the first commandment of marketing…and sales…and executive
management…and….

So, from that perspective, yes, I love “requirements”.  It’s clearly a Best Practice  (capital letters intentional).

5 thoughts on “Great Software from Great Requirements: A Software Best Practice

  1. Spot on. It’s always a bit funny to hear pundits talk about taking quality issues upstream by tackling the “requirements issue”. Every IT project I’ve ever seen or been involved in suffers from a requirements definition issue. In fact, the software project manager’s insistence on the spec as the gold standard of what we’re building contributes to an antagonistic relationship with the users and can be counterproductive. I guess this is why the industry invented Agile, so that the business and the software developers can actually work together vs. against each other.

    The fact that requirements are the “golden unicorn”, combined with your earlier post about software health, leads me to the same conclusion. The best thing to do, from a software quality standpoint, is to focus on having healthy code and a nimble architecture. Then, as the project manager or application owner, you can focus on the aspects of software quality that you can actually control and better support the evolving business requirements.

  2. Hollis, as always, I love your sharp Occam’s razor!
    “[R]equirements are one of the embodiments of true understanding of the customer. ‘Know thy customer’ is the first commandment of marketing…and sales…and executive
    management…and….So, from that perspective, yes, I love ‘requirements’. It’s clearly a Best Practice (capital letters intentional).”
    Nice, and oh so true.

    On the Seilevel blog, Jeremy Gorr posted on a similar thread: “IT as a Sales Function”.
    http://requirements.seilevel.com/blog/2011/02/it-as-a-sales-function.html
    Would love to hear your thoughts on it, if you’re in our blog neighborhood.

  3. It is clear you have you passion for “good software” and understand how to position to “know the customer”. In business software the customer has been “IT” as business people over the past 50 years have been “confused” some might think deliberately so to the point of fear of unsettling a function on which over the years they have become more and more reliant. Yet software remains a bit of a “mess” which has resulted in huge cost of failures as is widely reported.

    But change is happening as the innovative tech companies tackle the “interpretation gap” between IT and business and business people are becoming the decision makers on IT spend with informed knowledge.

    There has been a long held ”requirement” to remove the need for coding custom solutions. Indeed it has been the “holy grail” of software articulated by Bill Gates in 2008 “Most code that’s written today is procedural code. And there’s been this holy grail of development forever, which is that you shouldn’t have to write so much [procedural] code,” Gates said. “We’re investing very heavily to say that customization of applications, the dream, the quest, we call it, should take a tenth as much code as it takes today.” “You should be able to do things on a declarative basis,” “We’re not here yet saying that [a declarative language has] happened and you should write a ton less procedural code, but that’s the direction the industry is going,” Gates said. “And, despite the fact that it’s taken longer than people expected, we really believe in it. It’s something that will change software development”

    So we have a “requirement” at the core of building business software application which puts business people in the driving seat. But this is a hugely disruptive step which is real challenge and in the context of your views the customer profile changes as does the traditional approach to requirements? This is the challenge we faced as 20 years ago as UK based Procession set out to fix the “software problem” and has indeed created a new paradigm.

    So where do you (and Dell) sit in accepting reality that business software is long over due for that long held big step change?

    All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. –Arthur Schopenhauer a German philosopher who was among the first to contend that at its core, the universe is not a rational place! It strikes me that your passion evident in many of your plain speaking views could be harnessed to see this movement “take off” as it becomes obvious “why do it any other way”

  4. David,

    My response to your comment got so long, I just turned it into an article. I like (mostly) what you said.

    Just as an aside, I don’t attempt to be the voice of Dell, even though I (as of about a month ago) work for Dell as a software strategist. My opinions and my comments are my own. I’ve given some thought to publishing “official Dell opinions” – but those would never be on my own real estate – they’d be published on a Dell-sponsored site (and would have Dell logos all over the place – just to make sure you know you’re on a Dell site)

    I hope you don’t mind, but I’m going to edit your comment and insert carriage returns in between paragraphs to make what you said a bit more visually manageable. I’m not changing any words or introducing any other changes.

    I’ll publish my response and quote parts of your commentary on one of the sys-con sites, probably SOA World. I’ve submitted it as “Solving Business Problems in IT”. A link to all my sys-con (SOA World, Cloud Journal, etc) articles is http://hollistibbetts.sys-con.com

    “Cheers” – that’s what you guys still say, isn’t it?

    Hollis

  5. Do you have a spam problem on this site; I also am a blogger, and I was wanting to know your situation; many of us have created some nice practices and we are looking to
    swap strategies with other folks, please shoot me an email if interested.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s