Requirements Gathering

A typical medium-sized business software system will process data for dozens of different business entities (e.g. customers, purchases, suppliers, delivery batches, credit lines, notice documents, monthly statements, etc.)

Systems of this size have a highly complex relationship between all involved data objects. Management and senior-level employees in an organization typically have excellent insight into most of the aspects of the business - most, but not all. Yet, the system has to operate with all this data and make sure that all process relationships are satisfied and all activities carried out in the proper order.

Consider the situation for a minute. On one hand, you organization has accumulated a massive body of know-how, rules on doing business, rules on processing exceptional situations, measures to ensure compliance with the established practices. This know-how is not written down in thick manuals kept in a company safe; instead, most of it is "stored" in the minds of senior-level specialists and of management. These people are typically very busy, and have a certain bias towards their own line of work (e.g. a purchases manager understands the delivery process in great depths, but may not be well acquainted with the credit rating procedure for end customers)

On the other hand, you have a software development or systems integration vendor. As a general rule, these people are not proficient in your specific industry. They have knowledgeable specialists who develop software for a living, and know how to approach that problem.

In real-life situations those gaps are only too real. There are two core activities that inexperienced purchasers of IT often skip: the gathering of requirements, and the writing of a system specification.

The process of requirements gathering can be summarized as all activities related to eliciting, capturing, and validating the capabilities to be delivered by your IT project. There are many approaches to requirements gathering; some of those are very informal and suitable to small projects, others are very costly, time-consuming and formalized but can be used to create very large and extremely large systems.

Delera Systems takes a middle-of-the-road approach that has proved its effectiveness over the years in a number of cases. To us, efficient communication with all involved parties represents 50% of the effort needed to deliver a successful requirements list. We will interview a number of people from your organization to understand how you do things. This will include both junior-level workers involved in day-to-day operations, middle management, and senior executives.

By speaking to all involved parties, we are able to compile a list of needs, issues and recommendations for the problem area. At first glance a simple task, this is in fact a highly complex activity. Our consultants take great care to distance themselves from any particular aspect of the problem, and be independent as possible. This is to ensure that we never fall into the most common trap during requirements gathering: to be able to see the trees but miss the forest.

Using interviews and any documentation the client provides, we will compile a document explaining what the system needs to do. This document is typically not very formal, and is highly structured: dozens to many hundreds of bullet points summarizing system inputs and outputs, charts explaining business processes, and possibly use cases.

At this point the requirements document is quite valuable to the business. Yet, there is one more crucial step involved: using our understanding of new technologies, programming practices and our many years of experience, we will sit down and attempt to prioritize requirements. We do that according to how urgent particular needs are, the expected monetary benefits (ROI) of automating various tasks, and the business and technological risks involved when implementing a given system.

The prioritization of requirements usually requires that we do more hands-on work with senior or middle management in the organization. The specific end result is a draft version of a capability matrix that clearly shows expected deadlines (and intermediate milestones) for a software system.

When the requirements have been gathered and prioritized, managements needs to make an important decision on how to proceed:

• Abort or delay the IT system implementation
• Buy a mass-produced software system and hire a systems integrator to perform the necessary customizations. This can be a simple activity (e.g. automating invoicing and accounting reports in a midsized retailer), or highly complex (procuring a large ERP system to automate most aspects of a medium- to large-sized organization's operations)
• Sign a contract with a software vendor to produce a custom-built system whose capabilities closely match - and follow - the particular requirements of this organization

If the organization opts for custom-developed software, the time comes for the next critical element of the overall solution: describing in more detail what - and how - the software should do. This is the purpose of the Solution Specification.