8 software requirements traps to avoid

Lucas Buzzo, Business System Analyst at e-Core, is serious about software requirements when mentoring teams focused on this particular matter. Here are a few examples shared by him that might demonstrate where you’re falling victim to traps and ways to avoid them.

The path to quality software begins with excellent requirements. On the other hand, project’s failure and frustration are common when ignoring best practices for the processes of requirements development and management.

Ambiguous Requirements

The definition of terms and concepts can differ between users. That’s why clear and understandable requirements are the foundation of software projects.

Reviewing requirements with your team will lead you to an important common ground. Creating a glossary with the most used technical terms can be a great way to express both simple and complex concepts. If necessary, enhance them with visuals. LucidChart and Gliffy are great visualization add-ons for Atlassian tools like Confluence.

Inadequate Customer Involvement

User classes that are despised and stakeholders that position themselves as the main users are common situations that happen during requirements analysis.

Identify which users might be responsible for deciding and reviewing the proposed requirements. Establish criteria so that the deliverables are aligned with customer expectation.

Unprioritized Requirements

The requirements priorization is one of the most important steps. This can turn into a complicated task when varied stakeholders might interpret “high” priority differently.

To avoid doubts among developers, it is fundamental to define the priority categories clearly to promote consistent classification related to the system that is being developed.

Functionality No One Uses

Have you ever experienced the frustration of implementing features that users swore they needed, then not seeing anyone use them? You’re not alone.

Be aware of proposed functionality that isn’t clearly related to known user tasks or to achieving your business goals. Have customers rate the value of each proposed feature, based on the relative customer benefit to avoid high costs requirements that provides relatively low value.

Unrealistic Goals

Requirements engineering is a science and neither system is perfect.

Write requirements that reflect system’s reality so that is easier to verify it, consequently simplifying future maintenances and corrections for continuous improvement of the application.

Endless Requirements

Requirements development seems to be endless? Remember that your goal is not to create a perfect requirement but to develop portions to proceed at acceptable risk.

Choose an appropriate development lifecycle that will let you implement pieces of the requirements as they become understandable. Align communication with clients, business analysts, developers and testers and define the risks of starting the development before concluding the requirement.

Bad Requirements Gathering

Decentralized and ineffective communication can lead to discordance on requirement gathering process.

Establish a template for documenting your requirements with sessions, standard copies and diagrams. A standard documentation process helps analysts to be aligned with what needs to be delivered.

Inadequate Change Process

Some people might sidestep the change process by talking directly to software team members to get changes incorporated before they’re approved. The decision maker must validate, establish and communicate the process  to all those affected.

Define a practical change control process for your project and compare priorities with already existent requirements at the backlog. At e-Core, we use an integration between JIRA and Confluence to improve our change management by tracking, collecting and communicating changes.


Finally, Lucas shared some tips to avoid the requirement documentation gaps:

  • Define only one requirement at a time;
  • Avoid exclusion clauses. Example: but, except, if necessary;
  • Each requirement needs to translate a single idea;
  • Don’t speculate about requirements;
  • Understand different requirement types;
  • Build a collaborative relation between system analysts and users;
  • Build a well-trained and seasoned team to gather requirements.

Boost your knowledge in requirement engineering and business analysis: