Archive for November 6, 2009

It’s always good idea to separate needs from requirements

November 6, 2009 4 comments

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.