Home > Product Management, Software Engineering > It’s always good idea to separate needs from requirements

It’s always good idea to separate needs from requirements

Anyone who spent enough time building complex software products will probably agree that – when it comes to design – hindsight is truly 20/20.

There are many definitions of a good software design.  Regardless of the definition …

– Good software design always tries to balance known as well as potential requirements

– Good software design creates a stable platform to accommodate multiple major releases without the need to significantly change the underlying architecture

Why is it important to separate needs from requirements when evaluating essential elements of a good design?   Perhaps needs and requirements are the same?  They are not – and it’s good to introduce very basic definitions for both.

– Needs are specific business outcomes the customer needs to achieve in the business by using your software.  Needs are “ability to pay invoices online”, “ability to accept credit cards online”, etc.

– Requirements are – simply put – the functionality in the software product that must exist to support customer needs.

There is a very important cycle that cannot be ignored when designing software products.

Needs -> influence -> requirements -> influence -> design

Let’s illustrate why this so important.

– The customer expresses a need to have invoices paid online.  The requirements can include: supporting 100,000 users vs supporting 1,000 users, downloading invoices, viewing invoices on one or more mobile device types, different security / authentication mechanisms … and the list goes on.    By exploring & validating requirements as they match customer need, only then one can begin to accumulate raw materials for subsequent design consideration.

– Some customers will want to see all requirements mentioned above

– Good, anticipatory design will accommodate these requirements (in future product release over time) while preventing unplanned refactoring efforts.

Refactoring is a very costly effort which carries many risks, including higher defect rates and delayed software releases.  In a highly competitive market, unsuccessful refactoring efforts can have significant negative effect on the bottom line of the software company.

  1. Artem Dramaradskyy
    November 10, 2009 at 1:56 pm

    I agree with you, however, I would prefer to name things according to standards.
    1) We already have a term “Business Requirements” and I don’t see any reason for employing such alternative.
    2) According to methodology (independent on which exactly) we: gather Business Requirements so that understand stakeholder’s high level needs, then we rank Business requirements according to priorities and lastly we extract some of Business Requirements to System Requirements. In this case we have both: comprehensive set of needs specified in terms of Business Requirements + those that should be implemented and delivered within some particular project iteration specified in terms of System Requirements. We could also declare our “hidden” needs as following types of Nonfunctional Requirements: Integration, Extensibility, Scalability…

    • November 10, 2009 at 5:00 pm

      Artem,

      Thanks for your comments. You are right. “Hidden” or non-functional requirements are just as important and if – sufficient attention is not paid to these requirements – the design will not be what one wants.

  2. David Andrews
    November 10, 2009 at 7:15 pm

    Nice post… couldn’t have written it better myself.

  3. Rose Walker
    November 15, 2009 at 11:13 pm

    Leon,

    I agree. I think key to success on any project starts with clarifying the business requirements, prioritizing, and getting stakeholder agreement. From the “as is” to the “to be,” it needs to be clearly spelled out what will be delivered. I’ve also learned the hard way, the importance of clarifying what’s not included in the requirements phase, otherwise there’s more scoop creep.

    Rose

  1. No trackbacks yet.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: