Internal users: Employees of the organization who use the database to perform their jobs.
External users: Customers, suppliers, and other stakeholders who use the database to interact with the organization.
Needs of Different Database Users
The needs of database users vary depending on their role and responsibilities. Some common needs of database users include:
Access to data: Database users need to be able to access the data they need to perform their jobs. This may include the ability to read, write, and update data.
Data integrity: Database users need to be able to trust that the data in the database is accurate and complete.
Data security: Database users need to be able to be confident that their data is protected from unauthorized access and modification.
Performance: Database users need to be able to access and use data quickly and efficiently.
Ease of use: Database users need to be able to use the database easily and efficiently, even if they are not technical experts.
Internal Database Users
Internal database users typically have the following needs:
Access to data for operational tasks: Internal database users need to be able to access the data they need to perform their daily tasks, such as processing orders, managing inventory, and tracking customer interactions.
Data for reporting and analysis: Internal database users need to be able to access the data they need to generate reports and conduct analysis. This may include reports on sales, inventory levels, and customer satisfaction.
Data for decision-making: Internal database users need to be able to access the data they need to make informed decisions. This may include data on market trends, competitor activity, and customer feedback.
External Database Users
External database users typically have the following needs:
Access to information about products and services: External database users need to be able to access information about the products and services offered by the organization. This may include product descriptions, pricing information, and availability information.
Ability to place orders and manage accounts: External database users need to be able to place orders and manage their accounts online. This may include the ability to view order history, track shipments, and update account information.
Access to customer support: External database users need to be able to access customer support information. This may include a knowledge base, FAQ section, and contact information.
Identifying Database User Needs
The first step in designing and developing a database is to identify the needs of the users. This can be done through interviews, surveys, and focus groups. Once the needs of the users have been identified, the database can be designed to meet those needs.
Here are some tips for identifying database user needs:
Talk to the users: The best way to identify user needs is to talk to the people who will be using the database. Ask them what kind of data they need to access, what kind of reports they need to generate, and what kind of decisions they need to make.
Observe the users: Another way to identify user needs is to observe the users performing their jobs. This can help you to understand how they currently use data and what their pain points are.
Analyse user workflows: Analysing user workflows can help you to identify the data and functionality that users need at each stage of their work.
Use user surveys and questionnaires: User surveys and questionnaires can be used to collect quantitative data on user needs. This data can be used to prioritize user needs and to make decisions about the design of the database.
Hardware Specifications
Hardware specifications are the technical requirements for the computer hardware that is needed to run a software application or database system. Hardware specifications typically include information about the following:
CPU: The central processing unit (CPU) is the brain of the computer and is responsible for processing instructions and data. The CPU speed and number of cores are important factors to consider when choosing hardware for a database system.
Memory: Memory, also known as RAM, is used to store data and instructions that are being actively processed by the CPU. The amount of memory required for a database system will depend on the size and complexity of the database.
Storage: Storage is used to store data that is not being actively processed by the CPU. Storage options include hard disk drives (HDDs), solid-state drives (SSDs), and network attached storage (NAS) devices.
Networking: Networking hardware is required if the database system will be accessed by multiple users or if it will be used to store data in the cloud. Networking hardware includes routers, switches, and firewalls.
Computer Hardware
Computer hardware is the physical components of a computer system. Computer hardware can be divided into two main categories:
Input devices: Input devices are used to provide input to the computer, such as keyboards, mice, and scanners.
Output devices: Output devices are used to display or print output from the computer, such as monitors, printers, and speakers.
Different Types of Storage
The two main types of storage are:
Primary storage: Primary storage is volatile, meaning that it loses its contents when the computer is turned off. Primary storage includes RAM and CPU cache.
Secondary storage: Secondary storage is non-volatile, meaning that it retains its contents even when the computer is turned off. Secondary storage options include HDDs, SSDs, and NAS devices.
Evaluating Hardware Requirements for Database System
When evaluating hardware requirements for a database system, the following factors should be considered:
Size of the database: The size of the database is a major factor in determining the hardware requirements. Larger databases will require more powerful hardware.
Number of users: The number of users who will be accessing the database is another important factor to consider. More users will require more powerful hardware.
Type of database transactions: The type of database transactions that will be performed will also affect the hardware requirements. For example, online transaction processing (OLTP) systems require more powerful hardware than data warehousing systems.
Availability requirements: The availability requirements for the database system will also affect the hardware requirements. For example, a database system that needs to be available 24/7 will require more powerful hardware than a database system that is only used during business hours.
Once the hardware requirements for the database system have been evaluated, the appropriate hardware can be selected.
Here are some examples of how hardware specifications are used to ensure the performance and reliability of database systems:
A large online retailer might use a database system with high-performance CPUs and large amounts of memory to handle the high volume of transactions that it processes each day.
A financial services company might use a database system with high-availability hardware, such as redundant servers and storage devices, to ensure that the database system is always available to its users.
A healthcare provider might use a database system with secure hardware to protect the privacy of patient data.
Example of a Specifications Document
Product Name: Database System
Version: 1.0
Date: 2023-11-02
1. Objective
The objective of this document is to define the specifications for a database system. The database system should be able to store and manage large amounts of data efficiently and reliably. It should also be able to support a variety of database operations, such as:
Inserting
Updating
Querying
Deleting data
2. Scope
This document covers the following aspects of the database system:
Functional requirements
Non-functional requirements
System architecture
Security requirements
Testing requirements
3. Functional Requirements
The database system should support the following functional requirements:
Data storage and management: The database system should be able to store and manage large amounts of data in a variety of formats.
Database operations: The database system should support a variety of database operations, such as inserting, updating, querying, and deleting data.
Transactions: The database system should support ACID transactions (atomicity, consistency, isolation, and durability).
Concurrency control: The database system should support concurrency control to prevent multiple users from modifying the same data at the same time.
Backup and recovery: The database system should support backup and recovery to prevent data loss.
4. Non-Functional Requirements
The database system should meet the following non-functional requirements:
Performance: The database system should be able to handle a high volume of transactions efficiently.
Scalability: The database system should be able to scale to accommodate larger amounts of data and more users.
Availability: The database system should be highly available, meaning that it should be up and running most of the time.
Security: The database system should be secure to protect data from unauthorized access, modification, or destruction.
5. System Architecture
The database system should be a three-tier architecture, consisting of the following layers:
Presentation layer: Responsible for displaying the user interface and interacting with the user.
Application layer: Responsible for processing business logic and interacting with the database layer.
Database layer: Responsible for storing and managing data.
6. Security Requirements
The database system should implement the following security requirements:
Authentication: The database system should authenticate users to ensure that only authorized users can access the system.
Authorization: The database system should authorize users to perform only the operations that they are allowed to perform.
Data encryption: The database system should encrypt sensitive data to protect it from unauthorized access.
Audit logging: The database system should log all user activity to allow for auditing and troubleshooting.
7. Testing Requirements
The database system should be thoroughly tested to ensure that it meets all of the requirements. The following tests should be performed:
Unit testing: To test each individual component of the database system.
Integration testing: To test how the different components of the database system work together.
System testing: To test the entire database system as a whole.
Acceptance testing: To be performed by users to ensure that the database system meets their needs.
8. Conclusion
This document has defined the specifications for a database system. The database system should meet all of the functional and non-functional requirements specified in this document. It should also be implemented using a three-tier architecture and implement all of the security requirements. The database system should also be thoroughly tested to ensure that it meets all of the requirements.
Here is a table that distinguishes user requirements and system requirements:
Characteristic
User Requirements
System Requirements
Definition
Statements about what the user needs the system to do to solve a specific problem or meet a specific need.
Specifications for how the system should be built to meet the user requirements.
Focus
On the user's needs and wants.
On the technical aspects of the system.
Audience
Business users, stakeholders, and other people who will use the system.
Software developers and other technical professionals.
Examples
"The system should allow me to search for products by name or category."
"The system must be able to handle 100 concurrent users."
1. Focus
User requirements focus on the user's needs and wants, while system requirements focus on the technical aspects of the system.
2. Audience
User requirements are typically written for business users, stakeholders, and other people who will use the system, while system requirements are typically written for software developers and other technical professionals.
3. Language
User requirements are typically written in natural language, while system requirements are typically written in technical language.
4. Level of detail
User requirements are typically more abstract and high-level, while system requirements are typically more detailed and specific.
5. Focus on outcome vs. implementation
User requirements focus on the desired outcome or functionality of the system, while system requirements focus on how the system will achieve that outcome or functionality.
6. Subjectivity vs. objectivity
User requirements are subjective, meaning that they reflect the needs and wants of the user, while system requirements are objective, meaning that they can be verified or falsified.
7. Changeability vs. stability
User requirements can change frequently as the user's needs change, while system requirements are more stable and should not change frequently.
8. Verifiability vs. non-verifiability
User requirements can be verified by observing how the user interacts with the system, while system requirements can be verified by testing the system.
9. Usefulness for developers vs. usefulness for users
System requirements are more useful for developers, who need to know how to implement the system, while user requirements are more useful for users, who need to know what the system can do for them.
10. Usefulness for communication vs. usefulness for planning
User requirements are more useful for communication between the user and the developer, while system requirements are more useful for planning the development of the system.
SYSTEM REQUIREMENTS
Security
Security requirements are designed to protect the system from unauthorized access, use, disclosure, disruption, modification, or destruction. Some common security requirements include:
Authentication: The system must authenticate users to ensure that only authorized users can access the system.
Authorization: The system must authorize users to perform only the operations that they are allowed to perform.
Data encryption: The system must encrypt sensitive data to protect it from unauthorized access.
Audit logging: The system must log all user activity to allow for auditing and troubleshooting.
Performance
Performance requirements define the desired performance of the system, such as the response time for a given operation or the throughput of the system. Some common performance requirements include:
Response time: The system must respond to user requests within a certain amount of time.
Throughput: The system must be able to handle a certain number of requests per unit of time.
Availability: The system must be available to users a certain percentage of the time.
Throughput
Throughput is the rate at which the system can process data. It is typically measured in transactions per second (TPS). Throughput requirements are important for systems that need to handle a high volume of transactions, such as online transaction processing (OLTP) systems.
Storage space usage
Storage space usage requirements define the amount of storage space that the system will need. This includes the storage space required for the system software, the data, and any backup or recovery data. Storage space requirements are important for systems that store large amounts of data, such as data warehouses and big data systems.
Access speed
Access speed is the time it takes to retrieve data from storage. It is typically measured in milliseconds (Ms). Access speed requirements are important for systems that need to access data quickly, such as real-time systems and online transaction processing (OLTP) systems.
Example
Here is an example of a system requirement for each of the five categories:
Security: The system must encrypt all sensitive data using the AES-256 encryption algorithm.
Performance: The system must be able to handle 100 concurrent users and must respond to user requests within 1 second.
Throughput: The system must be able to process 10,000 transactions per second.
Storage space usage: The system must have at least 1 terabyte of storage space.
Access speed: The system must be able to retrieve data from storage within 10 milliseconds.
Structure of a requirements specification document
A requirements specification document (RSD) is a document that describes the requirements of a system. It is used to communicate the requirements to the stakeholders and to ensure that the system is developed to meet the requirements.
The structure of a RSD typically includes the following sections:
Introduction: This section provides an overview of the RSD, including its purpose, scope, and audience.
System overview: This section describes the system, including its purpose, features, and architecture.
Requirements: This section lists the functional and non-functional requirements of the system.
Use cases: This section describes the use cases of the system, which are scenarios that describe how users will interact with the system.
Verification and validation: This section describes how the requirements will be verified and validated.
Appendices: This section includes any supporting documentation, such as data models, user stories, and test cases.
The following is a more detailed outline of each section of a RSD:
Introduction
Purpose of the RSD
Scope of the RSD
Audience for the RSD
Definitions and acronyms
System overview
Purpose of the system
Features of the system
Architecture of the system
Assumptions and constraints
Requirements
Functional requirements: These requirements describe the behaviour of the system and what it should do.
Non-functional requirements: These requirements describe the performance, reliability, security, and other non-functional characteristics of the system.
Use cases
Use case ID
Use case name
Actors
Primary flow
Alternate flows
Post conditions
Verification and validation
Verification methods: How will the requirements be verified?
Validation methods: How will the system be validated to ensure that it meets the requirements?
Appendices
Data models
User stories
Test cases
Other supporting documentation
The RSD should be written in a clear and concise manner. It should be easy to read and understand for all stakeholders. The RSD should also be kept up to date as the requirements of the system change.
