Presumably, you are considering acquiring new software to address some business need – this need can be in the form of an opportunity for improvement or a problem that must be solved.  Many times, organizations jump to a technology solution and fail to clearly understand what the business really is.

With respect to technology, a needs assessment is an evaluation of the technical tasks and functions an organization must be capable of performing (that it currently isn't) or the needs that technology must be able to meet (that are not currently being met).  A true needs assessment requires that all possible needs be identified.  Determining whether they are realistic, necessary, and affordable comes at a later point in the planning process.

Requirements are discrete and measurable bits of functionality that must exist in the software to satisfy the need.  For example, an organization may have a need to send out Board reports via email.  However, the discrete software requirement may be that the new software system must print the reports directly to an Adobe .pdf file to insure that the statements cannot be altered.

What are the different kinds of requirements?  Generally speaking, they can be broken down into two groups:  Functional and Technical.

Should all requirements be given the same weighting?  Not all functional areas within the organization are, or should be, considered equal.  Let’s assume for a second that your software evaluation was only considering two functional areas: accounts payable and finance.  And let’s assume that the project sponsor has decided that accounts payable is the major focus of the evaluation while finance is a minor focus.  Wouldn’t it then follow that the individual list of requirements for accounts payable should get a higher weighting than finance?  It would not make sense to give them an equal rating.

This seems like a lot of work.  Is all of this really necessary?  Defining what you require in a software package is, in my opinion and experience, the hardest part of the entire software evaluation effort.  It is very easy to say what you don’t want.  But the effort of defining your requirements is a very intentional and disciplined act.  The degree of probability that you will get the best software match for your organization is directly proportional to the amount of focus and hard work that go into the requirements document.

This is the beginning of the relationship between your organization and the software vendors.  You will make a declaration of need.  The vendors, heart swelling with love and desire, will declare back that they feel your need and will be able to satisfy all of your software desires—and then some.

What is the best method to elicit requirements from my user base?  On smaller projects, the functional area team member may begin compiling the list of desired and required features and adding these to the precompiled list he obtained from other sources.  On larger projects, requirements are typically gathered through an interview process.  Numerous people from a functional area are “interviewed” to determine what their normal processes are and what is important to be included in the requirements document.  These interviews do two things:  one, they gather the desired information, and two, they begin the process of getting buy-in from rank-and-file members of your organization who are not on the project team.  They will more likely support the final decision if they feel that they had some input.

Resources for Software Needs Assessment and Requirements Definition

(Book) Software & Vendors & Requirements, Oh My!  A Project Team's Guide to Evaluating Business Software

Software Requirements Definition: How to Avoid Disasters in Software

(Book) A Practical Guide to Needs Assessment

(Book) Needs Assessment Basics

(Book) Software Requirements

When a software selection project falls out of the sky and onto your plate, you need a strong heart, a sharp brain, and the courage to tackle the task.  This is the book that provides all three, and more.  It is a clear and methodical map through the unclear and needlessly chaotic process of software selection.

Click Here
To Learn More About The Book