For many software development projects the end result can disappoint its users and key stakeholders. The cause of the software not meeting expectation and supporting a business process can in many cases be traced back to poorly written requirements.

There is a simple way to avoid a project being labelled unsuccessful and that is to gather requirements that describe the software you are building and why you are building it.

At Rokk we understand how critical this step in a software project is and work closely with our clients to ensure that project goals and objectives are established as early as possible.

What are requirements?

A clear, unambiguous representation of the business need of an organisation, describing what is required, but not dwelling on how the need is delivered.

Why gather requirements?


So that the development team are able to interpret the needs of the business in clear, unambiguous language, describing the uses to which the requirement will be used, and the expected outcome of the operation.

What happens if requirements are not gathered?

If a set of requirements are not available, but instead the business needs are passed to the development team to expect each individual to interpret the need themselves, then differences in interpretation are likely to lead to scope-creep, extended development time and awkward status meetings.

How are requirements gathered?

There are a number of techniques to elicit requirements from users, customers, sponsors and other persons with an interest in the development. One of the following techniques, or more usually a combination, are used:

  • Brainstorming
  • Document Analysis
  • Focus Group
  • Interface Analysis
  • Interview
  • Observation of users
  • Prototyping
  • Requirements Workshop
  • Reverse Engineering
  • Survey

Who should be involved in requirements gathering?

Anyone with a significant interest in the need that is to be developed into a software solution. Not only the business sponsor, the account manager or the expert, but also the target users who will have daily interaction with the delivered service. In this way a complete cross-section of user requirements can be gathered, and any conflicts addressed ahead of development.

When should requirements be gathered?

Ideally, requirements gathering should start as early as possible in the development workflow. If possible, this should predate any agreed contract. Top level business requirements should be understood as part of the contract negotiation.

During the development project, requirements can be gathered ahead of development starting as part of the discovery phase. This allows a complete picture of the business needs can be captured before development commencing, but this method can constrain development and reduce flexibility. An alternative is to capture requirements in the form of user stories just ahead of development of those requirements occurring. This means that requirements gathering continues throughout the project, and the development team can react to changing business needs such as priority product features.

Where are requirements stored?

There is no fixed way of capturing and recording requirements. Any method should encourage collaboration between the requirements analyst, the customer and the development team.

Need help gathering requirements for a software project?

Arrange a business focused discussion with our business analysts and engineers

Does your business have a Requirements gathering challenge? We'd love to hear about it...

Contact us