How to Define System Requirements?

System requirements are the foundation of any successful software or hardware project. They define the necessary conditions, capabilities, and constraints that a system must meet to function effectively. Clear and well-documented system requirements help ensure that all stakeholders, from developers to end-users, have a shared understanding of what the system must accomplish.

At their core, system requirements are specifications that outline the functional and non-functional expectations of a system. These requirements provide guidelines for designing, developing, and testing a system to ensure it meets business objectives, user needs, and technical constraints. Poorly defined requirements can lead to project delays, cost overruns, and system failures, making their proper definition a critical step in the development process.

In this article, we will explore the process of defining system requirements, discuss different types of requirements, and provide best practices to ensure clarity and completeness.

Gathering Functional Requirements

Defining system requirements begins with identifying the key functions of the application and understanding who will use it and how. In professional terms, this process is known as gathering functional requirements.

The entities interacting with the system are called actors. These can be end-users like customers, administrators managing the system, or even external applications that integrate with the system. The functions the system must perform are simply referred to as functions, while the way actors interact with these functions is described through user stories.

To structure this information effectively, it is often represented using Unified Modeling Language (UML) diagrams.

Use Case Diagrams: These diagrams depict the relationships between users (actors) and the various functions (use cases) they perform within the system. They provide a high-level overview of system functionality from the user's perspective.

Activity Diagrams: These diagrams model the workflow or sequence of activities within a system. They illustrate the dynamic aspects, showing the flow from one activity to another, including decision points and parallel processes.

Sequence Diagrams: These diagrams detail how objects interact in a particular sequence, focusing on the order of messages exchanged between objects to accomplish a specific task or process.

User Story Mapping: This visual tool arranges user stories into a structured map, outlining the user's journey through the system. It helps in understanding the functionality from the user's perspective and prioritizing development tasks.

These diagrams help visualize the relationships between actors and system functions, making it easier to analyze, refine, and validate the functional scope.

Once the required functionality is well-documented, we can move on to the next step in defining system requirements.

Defining Non-Functional Requirements

After defining the functional aspects of the system, the next step is to establish non-functional requirements (NFRs). These requirements define the system's quality attributes, which impact performance, reliability, scalability, security, and other operational aspects. Unlike functional requirements that specify what a system should do, non-functional requirements define how well the system should perform under different conditions.

Below are some of the key non-functional attributes to consider:

1. Availability

Availability refers to the amount of time the application must remain operational and accessible to users. Key questions to ask include:

Key Questions:

• What uptime percentage is required (e.g., 99.9%, 99.99%)?
• Can the system have scheduled downtime for maintenance? If so, when?
• How critical is real-time availability for the users?
• What happens if the system goes down? Is there a failover plan?
• Should the system be available 24/7, or only during specific hours?

Examples:

• A banking application must have an uptime of 99.99%, meaning the system should not be down for more than 52.56 minutes per year.
• An internal HR system used only during working hours may have scheduled maintenance every night from 12:00 AM to 6:00 AM.
• An e-commerce website must remain available 24/7, except for brief maintenance periods announced in advance.

2. Scalability

Scalability defines how well the system can handle increasing workloads while maintaining performance. It also considers resource optimization during low-demand periods.

Key Questions:

• How many users or requests per second should the system support?
• What is the expected growth rate (e.g., number of users in 6 months, 1 year)?
• Should the system scale horizontally (adding more machines) or vertically (upgrading hardware)?
• What are the peak load periods? Are there seasonal spikes?
• How does the system handle sudden traffic surges?

Examples:

• A streaming service must scale horizontally by adding more servers during peak hours (6 PM - 12 AM) when user activity is high.
• A cloud-based SaaS product must support up to 100,000 concurrent users and automatically scale its database resources based on query volume.
• A retail website experiences seasonal spikes during Black Friday sales and should be able to handle 10x the usual traffic.

3. Performance

Performance measures how efficiently the system processes requests and handles data. It defines the acceptable limits for response times and processing capabilities. Important considerations include:

Key Questions:

• What is the maximum response time for different operations? (e.g., API should return data within 500ms)
• What is the throughput requirement? (e.g., how many transactions per second?)
• How does performance change under high load?
• How should performance be monitored and optimized?
• Are there specific latency-sensitive operations?

Examples:

• A search engine must return results within 200 milliseconds for 95% of queries.
• A financial trading system must process at least 1,000 transactions per second to support real-time trading.
• An API endpoint must respond within 500ms under normal load and degrade gracefully if load exceeds 10,000 requests per second.

4. Durability

Durability ensures that data remains intact and safe even during failures or unexpected shutdowns.

Key Questions:

• How long must data be retained?
• What happens in case of a server crash? How quickly must data be restored?
• How often should backups be made? Where are they stored?
• What level of redundancy is needed? (e.g., multiple copies in different regions)
• Can any data loss be tolerated? If yes, under what conditions?

Examples:

• A document management system should store all files with triple redundancy to ensure that no data is lost in case of a server failure.
• A hospital's medical record system must ensure that no patient data is lost even in case of a full system failure.
• An e-commerce platform must perform hourly database backups, with the ability to restore lost data from the past 24 hours.

5. Consistency

Consistency ensures that data remains synchronized and accurate across the system. Some applications, such as banking systems, require strong consistency to prevent discrepancies, while others prioritize speed over immediate synchronization.

• Strong consistency: Data updates must be immediately reflected across all parts of the system (e.g., financial transactions).
• Eventual consistency: Data synchronization occurs asynchronously, which may cause slight delays (e.g., social media feeds).

Key Questions:

• Is strong consistency required, or is eventual consistency acceptable?
• How soon must data updates be reflected across all system components?
• What happens if a user sees outdated data due to eventual consistency?
• Should transactions be atomic (either fully completed or fully rolled back)?
• How should the system handle data conflicts?

Examples:

• A banking application requires strong consistency—if a user transfers money, the balance must immediately reflect across all services.
• A social media platform uses eventual consistency, where a "like" on a post may take a few seconds to update on another user's feed.
• A warehouse inventory system ensures strong consistency so that stock availability is always up-to-date before processing orders.

6. Maintainability

Maintainability reflects how easily the system can be monitored, tested, and updated. It includes:

• How quickly incidents can be detected and resolved.
• The complexity of debugging and updating the codebase.
• Automated testing and monitoring practices.

Key Questions:

• How often do we expect to update or patch the system?
• Should updates be zero-downtime deployments?
• How will errors and incidents be tracked and resolved?
• What logging and monitoring solutions should be in place?
• How easy is it to add new features or modify existing ones?

Examples:

• A web application should have automated error logging and monitoring, allowing engineers to detect issues within 5 minutes.
• The codebase should follow modular design principles, making it easier to replace or upgrade individual components.
• A SaaS product should support zero-downtime deployments, ensuring that updates can be rolled out without interrupting user activity.

7. Security

Security defines rules for protecting data and system access.

Key Questions:

• What authentication and authorization mechanisms should be used?
• What sensitive data needs to be encrypted?
• What are the compliance requirements (e.g., GDPR, HIPAA)?
• How should the system defend against cyber threats (e.g., DDoS)?
• Who should have access to different parts of the system?

Examples:

• A corporate email system requires two-factor authentication (2FA) to prevent unauthorized access.
• All user passwords should be stored using bcrypt hashing with a minimum work factor of 12 to prevent brute-force attacks.
• A government database must implement end-to-end encryption for all sensitive data to comply with GDPR and HIPAA regulations.

8. Cost

Cost refers to the expenses associated with system implementation, operation, and maintenance.

Key Questions:

• What is the budget for infrastructure and maintenance?
• Can we optimize costs by using serverless or cloud auto-scaling solutions?
• What are the long-term costs (e.g., licenses, storage, operational support)?
• Are there cheaper alternatives for specific components without sacrificing quality?
• How do we balance performance vs cost?

Examples:

• A startup chooses to host its backend on AWS Lambda to reduce server costs, paying only for execution time.
• A company estimates that running a high-availability cloud database will cost $5,000 per month, and must evaluate whether it can be optimized.
• A retail business plans to use auto-scaling cloud services, keeping costs low during off-peak hours while ensuring resources are available during peak times.

Documenting System Requirements

Once we have gathered all the necessary functional and non-functional requirements, the next step is to properly document them. A well-structured requirements document ensures clarity, minimizes misunderstandings, and serves as a reference for all stakeholders, including developers, testers, project managers, and business analysts.

Well-defined requirements are the foundation of a successful project. Investing time in gathering and documenting them properly will save time, money, and effort in the long run.

References:

IEEE 830-1998 – Recommended Practice for Software Requirements Specifications

ISO/IEC 25002:2024 - Systems and software engineering

The Agile Manifesto