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

# # #

Skomentuj

Dodaj komentarz

Dołącz do nas:

Wejdź na naszą stronę i sprawdź aktualne oferty pracy.
Jeśli chcesz zdobyć wiedzę na temat ServiceNow i zostać certyfikowanym specjalistom sprawdź ofertę szkoleń.

W swojej pracy używasz ServiceNow i chcesz podzielić się swoją wiedza? Napisz do nas koniecznie na blog@spoc.pl.