This content is part of the Essential Guide: Gathering and managing software project requirements
Manage Learn to apply best practices and optimize your operations.

Software lifecycle: Rethinking requirements - and the tester's role

When specifying requirements at the outset of software lifecycle, maybe "less is more"-- and testers should step up to fill in the gaps.

It may be the most widely held belief about the software lifecycle: Getting requirements right sets the course for software that does what it's meant to do. Getting requirements wrong begins a path to project failure.

Jennifer LentJennifer Lent

For software testers, requirements have always been about wanting more. The more requirements are defined up front, the more thoroughly testers can verify the application's range of functions. More is also better when it comes to the level of detail defined within individual requirement specs. But as QA pros have long lamented, key details are often missing, which leads to vague requirements that are difficult to test.

For software testers, the idea that more is better, when talking about requirements, is deeply held. Recently I've seen signs that may turn this conventional wisdom on its head. A new truth is emerging: Maybe less is more when it comes to specifying requirements at the outset of the software lifecycle.

Is this is just a case of bowing to a reality QA pros have had to live with for a long time? Or is there more going on here?

I think it's something bigger. Yes, software teams are rethinking what makes sense for requirements. But more momentous is how the very role of testers is being redefined, making them more important players in the software lifecycle. In this edition of Quality Time, I explore this change.

Requirements: Is less more?

Scanning the agenda for the StarEAST conference, scheduled for May 4 - 9 2014 in Orlando FL, I came across this description for a tutorial led by software test expert Lloyd Roden:

"Requirements are essential for the success of projects ― or are they? As testers, we often demand concrete requirements, specified and documented in minute detail. However, does the business really know what they want early in the project?"

In his course description, Lloyd Roden, who heads a UK-based consultancy of the same name, goes on to say that "detailed requirements can damage and hinder the progress of testing."

Really? Detailed requirements hinder testing? That's an about face for software pros, who believe that the more detail a requirement includes the better it is.

Then I came across a recent article published on that concurs with Roden's point. In an article on the advantages of using fewer user stories, Mary Gorman and Ellen Gottesdiener, co-principals of EBG Consulting, make the case that too many user stories (essentially "requirements" in Agile development) impede the progress of software projects. "It's not a contest to see how many user stories you can write. Not everything needs to be a user story," they say.

So maybe, when it comes to managing requirements in the software lifecycle, less is more?

Testers take a leading role

Here's what I think is happening. If the role of the software tester is simply to validate requirements, the "more" mindset is the right mindset. The more requirements software testers validate, the harder they are working. And the more detail a requirement includes, the easier it is for the tester to validate.

But all testers know that this perception of their role is outmoded, that delivering great software takes more than just verifying that the requirements work.

What does the software tester's role entail today? Test expert Lisa Crispin, a regular contributor to our pages, said it best when she described the tester's role as helping business people figure out the right things to deliver. "The truth is that business stakeholders may be wrong about what features [an application needs]." Testers have to take a leadership role in those decisions, she said.

Don't just do what they say

All QA pros know, testing the requirements as they are specified, no less and no more – will not result in the best possible software. It will simply result in well-tested requirements. In this scenario, the "more" mentality around requirements makes sense.

Simply testing requirements is far easier than what's being asked of software testers today. But it's also less interesting, less creative and less ambitious. It requires rote skills, not insightful thinking. It's sort of like working the assembly line instead of helping design the best car.

In my next column, I'll talk about what skills it takes to deliver top quality software today. Let me know what you think.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Thanks, @ellengott, for pointing me to this! Jennifer, I agree with several of your points and am thinking differently about others. The purpose of testing per James Bach is to understand how the system responds under specified circumstances; functionally as well as performance, load, etc. - the ilities/NFRs. I think overall we are losing sight of the importance of design and software engineering, and expecting those writing reqs to write detailed "specifications" before system or UI design is done and before understanding what constraints there might be on design alternatives. Another trend that concerns me is the use of the terms QA and testing as though they are interchangeable. Unless a tester can change the code, they can't do much to assure the qualtiy of the code, so to call them QA is either wishful thinking or uptitling! I look at QA as what is done to prevent problems, testing is the effort to detect them. QA has a process focus; Testing has a product focus. Both skill sets are important but they are not the same. As long as counts - of reqs, stories, tests or process steps - are the measure, we will produce what is count-able, not valuable. And lots of it!

Terry Wiegmann, CSQE, CBAP, PSPO
The word "too less" or "too many" is subjective and differs from project to project. I personally do not really worry about whether the requirements are detailed or minimal. As a tester I only care about this - Are the requirements making sense to me? Can I relate the requirements with the bigger picture (in terms of the product, project and business goal). As long as I have answer to these two questions, I am happy! I can always raise a bug or suggest for a feature enhancement as a tester BUT without knowing what the bigger picture is, I will never be a happy tester.