What Skills and Approaches Are Essential for Analyzing Requirements?

🙋 Questions
1

Here are three questions we’d like to know the answer to:

  1. What skills do you need to analyze requirements? A
  2. Do you follow a structure when raising questions, or do you just follow your gut?
  3. When, where, and with whom do you analyze requirements?

Sharing your experiences and best practices in requirements analysis can help us develop our Junior Software Tester curriculum

1 Like
2

First is obviously being critical. Read things multiple times, take them literally, and does it make sense, or apply them literally as written. Avoid the brain filling in spaces if you can. Do let your knowledge of something affect the interpretation of the requirements

Real example I saw the other day actually, I read a requirement for an Api and it used the terminology “… and return a true or false response…”.

What was actually delivered used a “Y” or “N” response.

I took the stance that as true/false is quite specific in the boolean sense then the requirement wasn’t met. The actual intent of the requirement was that the response be “positive or negative”, so we reworded it to say this instead (after confirming it was indeed acceptable) and then the Y/N response was considered acceptable.

3

Good skills to develop to analyse requirements:

  • Listening with intent during early team meetings about the project so I’m able to ask the right questions when requirements are formed.
  • Being able to identify instances where team members have different understandings of requirements and not realise this themselves.
  • Strong critical thinking skills, and specifically using those skills to identify gaps in requirements.
  • Verbal and written communication skills to do all the above effectively. :slight_smile:

I suppose if I had to sum it up then a tester’s goal for requirements analysis would be: Verifying that requirements are fit for purpose (for the project), clear (for everyone who needs to use them), and robust (covering the necessary cases).

I don’t have a specific structure for analysing requirements, mostly just asking myself questions. I would consider the purpose of the project/feature and the functionality involved to think of cases which the requirements need to cover, and if the requirements do cover them.

I’d start analysing requirements as soon as they’re discussed in any early project meetings, just verbally at that point, to aid in forming the requirements. The real bulk of the analysis is done on the Jira tickets where most information about tickets is stored.

Requirements will be added to Jira tickets by the Product Owner and I’ll add any questions in response to the requirements back onto the ticket and make the necessary people (product owner, stakeholders, developers) aware so we can investigate further. We also have refinement meetings where requirements can be challenged with the whole team present.

2 Likes
4

I would try to understand the context of ‘Requirements’. This would lead me to understand a mission where I might use these ‘requirements’.

  • Implicit or explicit?
  • When explicit, are they written or oral?
  • What type are they - business, software, user?
  • For whom or what are they meant - my role(how I should be doing testing), project(organizational), product, team(logistics, structure, process)?
  • When do I get to interact with them? how about with the people that require things? how about with others in the team who interpret them?
  • Do I get to know original requirements or translations of them in the form of specifications, solution designs, user stories, product manager ‘requirements’?
  • Who’s giving the requirements and for what purpose(is it a dev, a lead, a CEO, a client, or a colleague from another department)?
  • Is there a versioning of them? Do I receive timely updates?
  • How are they transmitted and expressed?
  • With what purpose would I be analyzing them and at what stages?
1 Like