Implicit and Implied Requirements

What separates out a long-term successful IT project, is how the implicit, or implied requirements are understood and met. This can be from the levels of security that are expected such as MFA being a feature of the platform, through to nuanced things such as the names of buttons and actions within the system. Being aware of the greater context will allow you to make better assumptions, and work within more complete constraints.

Understanding Implicit and Implied Requirements

Implicit requirements are those that are not explicitly stated but are expected by users and stakeholders. These can include:

Usability: Users expect the system to be intuitive and easy to navigate. But this is specific to the users and understanding how they will interact with the system. For one user it may be intuitive because they have a background of dealing with this type of system, but for another it is illogical, and terrible.
Performance: The system should perform efficiently under expected load conditions. This is specific to the historical context of the system, and a user’s expectations of how long something should take, and how variable that process may be.
Security: Adequate security measures should be in place to protect user data. There are certain levels of security that are in today’s world, are expected. But then there are the additional security constrains that are implied by the risk profile of the organisation.
Maintainability: The long-term use of this system, and how it may need to adapt to future changes from internal and external stakeholders. How does this system need to be maintained.

Implied requirements, on the other hand, are those that are inferred from the explicit requirements. For example, if a system is required to handle personally identifiable data, it is implied that robust security frameworks should be used as part of a Secure Software Development Life Cycle.

The Importance of Context

Understanding the context of the problem to be solved is crucial for identifying both implicit and implied requirements. Without this understanding, projects are more likely to fail or result in poorer outcomes. some reasons include:

Misalignment with User Expectations: Without understanding the context, the project may not align with what users actually need or expectations, leading to dissatisfaction.
Overlooking Critical Requirements: Important requirements may be overlooked if the context is not fully understood, resulting in gaps in functionality or security.
Inefficient Solutions: Solutions may be developed that are not optimal for the problem at hand, leading to inefficiencies and increased costs.
Rework Emerging Requirements: There are often obvious requirements that if considered at the start have little to no impact on the overall project costs or time, but realised too late they will have significant impacts and cost significantly more to implement.

Examples of Implicit and Implied Requirements

To illustrate the importance of implicit and implied requirements, consider the following examples.

Implicit Requirements

A financial or insurance application is expected to have a high level of security, even if not explicitly stated. Users assume their financial and PII data will be protected.
An e-commerce platform is expected to have a user-friendly interface and seamless checkout process. Users assume they will be able to easily navigate the site, find products, and complete their purchases without any hassle.
A healthcare application is expected to maintain patient confidentiality and comply with regulations like The Privacy Act 1988 (Cth), or Health Records Information Privacy Act 2002 (NSW). Users assume their medical records and personal health information will be kept private and secure.
A defence contractor’s software is expected to have rigorous security measures and comply with government regulations. Users assume that the software will protect sensitive military data and adhere to strict cybersecurity protocols.
A physical retailer’s app is expected to provide a seamless integration with in-store experiences. Users assume they will be able to check product availability, receive personalized offers, and use the app for contactless payments and loyalty rewards without any issues.

Implied Requirements

If a system is required to support multiple languages, it is implied that the user interface should be designed to accommodate different text lengths and character sets.
If a system or set of systems is required to have very high availability, it may be implied that the design of the overall system should allow for outages of core systems and “catch up” once services resume. This means implementing redundancy, failover mechanisms, and data synchronization processes to ensure continuous operation and data integrity.
If a mobile application is required to work offline, it is implied that the app should have local storage capabilities to save data and sync with the server once the connection is restored.
If a customer support system is required to provide 24/7 support, it is implied that the system should have automated responses and self-service options to handle queries outside of business hours.
If a data analytics platform is required to generate real-time reports, it is implied that the platform should have efficient data processing and low-latency data retrieval mechanisms.
If a collaboration tool is required to support remote teams, it is implied that the tool should have features like video conferencing, file sharing, and real-time collaboration to facilitate effective communication and teamwork.

Strategies for Identifying Implicit and Implied Requirements

To ensure that implicit and implied requirements are identified and met, consider the following strategies:

Stakeholder Interviews: Engage with stakeholders to understand their expectations and uncover any implicit requirements. Ensuring that all stakeholders are present and engaged with, not just the one paying the bills.
Contextual Inquiry: Observe users in their natural environment to gain insights into their needs and expectations.
Requirement Workshops: Conduct workshops with stakeholders to discuss and identify both explicit and implicit requirements.
Validate Assumptions and Constraints: The difference between an assumption and a constraint can be the difference between making the right choice and making the wrong one.
Prototyping: create thin mocks and prototypes and get stakeholders to verbalise their thoughts as they use the prototypes.
Explore the environment: Understand the micro-, meso-, and macro- environments using tools such as PESTLE analysis¹, or Porters Five Forces².
Context expansion: review newsletters, regulator announcements, magazines and other publications for topics that impact and inform requirements of the project.