Tuesday, 01 November 2016 14:04

Requirements Are Dead, Long Live the Solution

Written by
Rate this item
(16 votes)

Requirements gathering is one phrase I have learned not to use with stakeholders as I deliver projects.

It appears to have struck fear, cynicism and/or anxiety in many of the user groups I have to engage at the most important stage of the solution – the beginning.

Related Article: Your Job is Not to Elicit and Document Requirements

Many user groups have pre-conceived ideas about what this exercise really is, ranging from
‘Oh great, we get to tell them what we want for the new, super-duper system’ or
‘Just great, we give you all our knowledge about the processes and you go away to work out that’s too expensive and we can only have half of what we need.’

The secret is in the last few words of the previous sentence ‘… what we need.”

The focus must be directed towards the needs of the business so that the benefit of a solution can be seen to be realizable. By using the right words like need, a different reaction is seen. Scope is already being defined; the user groups become SMEs, and a level of respect is gained with a focus on the business value even before the workshop has started.

Elicitation and other animals

The industry then moved on with the terminology, to use the term “elicitation.” To add complexity, there were separate definitions of functional requirements, being different to business requirements, then getting technical and coming up with system requirements.

All of the types of requirements have clouded the understanding by stakeholders, and then time is lost in the defining the terminology before any discussions have begun. A plethora of white papers and authored articles can describe the differences and it’s absolutely clear in some of those esoteric minds.

Stephen Covey’s #2 Habit – Start With the End in Mind

From the book “Seven Habits of Highly Effective People,” this second habit is a fairly simple approach to delivering solutions. Knowing the direction and end-game keeps you focused as you go. It also facilitates a more direct approach to delivering without the time-consuming documentation of a build-up of phases that doesn’t always deliver tangibility or measurable benefits.

This skipping of phases with little value-add has now been conceptualized by the consulting industry into ‘Design Thinking’ whereby initial engagements with user groups will have the design of the solution at the forefront, ensuring that it will always meet the business needs.

Cheese's of Gatherers

Some time ago, the DSDM (Dynamic Systems Development Method) consortium developed the methodology known as the cheese and three pizzas, whereby the cheese represented the business study under a feasibility study. Quite simply, for appropriate projects, conduct a study to make sure of the feasibility, then develop it to make sure it fits the needs of the business opportunity or problem.

A business fitted, feasibility that demonstrates meeting the needs, to those with access to purse strings appears a far greater representation of commitment to deliver a solution.

Today’s project needs are for solutions measured in time-to-market, risk reduction, take-up rates, or better still, what you defined as measurable at the beginning.

Do projects exist anymore that require full blown requirements gathering exercise, if they still do would you call it that?

Read 12210 times
Kevin Venning

Kevin is a Senior Consultant with The Birchman Group Asia Pacific.  He has a career spanning two decades f delivering solutions through programs and projects for companies of varying industries and sizes in England, Europe, America, Africa and Australia, facilitating the selection of projects, their prioritisation and optimal method to provide a digital solution, most importantly running with that selection from conception through to delivery and proving the benefits.  Connect with Kevin via LinkedIn


+4 # Martin Burton 2016-11-03 21:07
Neither a project, nor a solution, would exist were it not for requirements. Requirements are not dead. I would suggest that BA’s might have some options in mind as to what the end might be, but no-one should have decided on one particular solution too quickly. This ignores evaluation of the potential solutions against requirements.
Rachel Davies of the DSDM Consortium published http://www.agilexp.com/presentations/DSDMexplained.pdf in 2004.
Her catchy-named “cheese and three pizza slide” is only one lifecycle diagram in that presentation, as well as multiple slides on requirements e.g. prioritized requirements using MoSCoW rules.
No project gets delivered without requirements being fully or partially met by the solution. The stakeholders need to articulate their outcomes/needs/ requirements in order for a solution to be facilitated.
Research is often done to find applicable market options. Those solution options need to be evaluated against the outcomes/needs/ requirements. If there isn’t a solution in the market, it may need to be built from scratch, hopefully in an agile way. Requirements are then articulated for development and testing, sometimes in User Stories.
So a project can’t jump magically to the right solution without requirements. Requirements in some form are very much alive.
Reply | Reply with quote | Quote
+2 # Barry 2016-11-04 03:24
Completely agree. Misguided approach to doing any solution without understanding the needs of a business area through requirements. Time and time again projects have proven to fail as a result of mismanaged requirements exercises or, more simply put, not capturing the right requirements. Some BA''s agree to a "solution agnostic" way of workingetting, whereby they don't focus on solution at all - certainly until requirement's have been documented and signed off. Personally, believe requirements are a key step in the BA life cycle and will continue to press for them being captured documented, scrutinised and signed off in my BA Team.
Reply | Reply with quote | Quote
0 # JC 2016-11-04 09:14
Don't understand the article. Why use more than one way to describe requirements. They're either functional or non-functional. End of. Sometimes we can involve the end user too much. BAs are the gatherers of requirements. How else is it possible to determine what a new system is to provide?
Reply | Reply with quote | Quote
0 # Paul S 2016-11-04 13:58
Wow, start with the solution in mind before sitting with the user group for requirements. This sounds like a stakeholder idea! Horrendously bad article. Besides the terrible advice, the article also needs editing. Is this a real sentence?

"A business fitted, feasibility that demonstrates meeting the needs, to those with access to purse strings appears a far greater representation of commitment to deliver a solution."
Reply | Reply with quote | Quote
0 # Kevin 2016-11-06 18:48
Quoting Paul S:
Wow, start with the solution in mind before sitting with the user group for requirements. This sounds like a stakeholder idea! "

And where exactly does it say "Before sitting with user group ..." ? I don't believe this is implied at all.
Reply | Reply with quote | Quote
+1 # Vman 2016-11-05 01:48
Poor article, does not offer a viable option, requirements are a long way from being dead!
Reply | Reply with quote | Quote
0 # Philippe Gosselin 2016-11-22 15:51
Articles with any position should always get people to debate and this is what this does. The only thing I will say is that I am an IT Business Analyst and if I were to document the solution, my designers and developers would be extremely unhappy. I think we need to know some of the elements of the solution but we are not documenting the solution in our requirements
Reply | Reply with quote | Quote
+1 # Tony Bresse 2016-12-07 17:48
We would not know what solution to build if the requirements are not defined.

User Stories are the requirements.

Use Cases are the solution that defines the interactions to support the User Stories.

Keep in mind that User Stories can be clear enough to build the solution without defining Use Cases.
Reply | Reply with quote | Quote

Add comment

Security code

search Articles

© BA Times.com 2016

DBC canada 250