Thinking about Software Requirements

Is your organization getting ready to think about its software requirements? Sometimes when organizations approach us about their software needs, we are struck by how poorly they have thought out what it is they are looking for. We cannot even guess from their few pages of notes what major pieces of functionality they are seeking, or why they are seeking a new system. Other times we find ourselves staring in dismay at a 100 page Software Requirements Statement detailing field lengths and report structures, to which we are expected to respond in detail. These guys have gone to a lot of effort. But both of these documents are nearly useless in the context where they are usually handed to us - where an organization's staff and ours are trying to decide if we are a good match for their critical software needs. It's not a problem of having to much or not enough of a requirements statement. The problem is misunderstanding what requirements are, and what they are for. Following a link in a sidebar of an article in the current issue of Dr Dobbs Magazine, a venerable developers journal, I found a great piece by Karl Wiegers - 10 Requirements Traps to Avoid -that should be a great help to anyone trying to write a requirements statement. Trap 1 is as far as we are going today. It involves failure to recognize the type of requirements you are setting down. Wiegers identifies three distinct levels of requirements. Business Requirements lay out the needs from the standpoint of organizational problems and goals. From this standpoint there is one actor - the org - with one set of needs. User Requirements look at the information system from points of view of the different staff roles within the organization, and specify what tasks each actor demands of the the software in order to meet the Business Requirements. Finally there are Functional Requirements - detailed descriptions of individual functions the software is going to perform in meeting each user requirement. For software selection, keep your focus on your organization, not on the application's buttons, checkboxes, and fields. If the task at hand is to distinguish between vendors, the statement of functional requirements is the wrong tool. Instead your starting point ought to be how the vendor and its software will help you address your key business requirements. Ask the vendor how their tools and their approach will help you meet your organization's articulated information systems business requirements, rather than have them check-off whether or not they have certain sorting abilities in a certain report you may not really need. A focus on the micro level can give you the feeling you are doing your due dilligence, but really you are taking your eyes off the prize, which is selecting the software that best supports your mission.