We need to gather the requirements….

What does this mean in relation to a software development project?

Essentially, the idea is to look at what is currently being done, known as the ‘As Is’ and the vision of where the system needs to be, the ‘To Be’.

The area in the middle is going to be filled with the requirements, the needs to fix the existing issues or areas for improvement.

Of course, if this is something new, the ‘As Is’ will be a blank canvas.

The requirements for the system which is to be developed should support the business, people and the processes. In IT, we may consider Incident or Request Fulfilment. For HR, we can look to New Hires, Managing Leave etc..

The Challenge

One of the issues of ‘gathering the requirements’ is that they can sometimes be elusive. A stakeholder can want something, but might not be able to define what it actually is, or how it looks.

Other common problems include –

Perhaps one of the biggest problems is ‘Missing Requirements’. These are usually missing in the sense that they haven’t been considered. Not that someone has accidentally misplaced them 😊

Overall, this means the task of defining the requirements and shaping them into the project deliverables can be tough.
You have to understand the requirements

What do Good Requirements Look Like?

The Tools Available

An analyst can use many techniques and approaches to collect the requirements –

Once the stakeholders have provided their input. Everything must be understood or ‘analysed’ and then validated back to confirm understanding.

These steps are just as important and will help refine the deliverables for the project.

During each phase, the key must be listening and really building an understanding. Ask questions until there is no doubt.

Listening

Not a Waste of Time and Money

An important point is the cost of analysis at the start of the project will nearly always be less expensive than replacing or repairing issues at the end of a project.

However, there seems to be a stigma related to this topic. Often Businesses want to rush through this process.

They don’t see it as value added and almost never want to invest time and resources in the process until a scope has been defined and budgets have been set. In effect, when it’s too late!

A Lasting Note

What do most people refer to when they’re reviewing a project retrospectively? Perhaps –

  1. The failure of benefits not being delivered
  2. How the system didn’t meet the real need of the business

Generally, people won’t refer back to ‘The cost of gathering and defining requirements’ as the standout subject.

Of course, the other end of the spectrum is also undesirable. You don’t want a project never to start because you’re constantly analysing and tweaking every detail.

The requirements gathering and definition process should be built into the project.

Plan it carefully, just as you would with any other aspect; such as budget, delivery dates and project resources.

 

Podziel się tym artykułem

# # #

Add Comment

Leave a Reply

Join us:

Visit our website and check current job offers.
If you want to learn more about ServiceNow and become certified professionals check out the training offer.
Do you use ServiceNow in your work and would like to share your knowledge? Mail us at blog@spoc.pl.