Org Requirements

Org. Requirements

Summary

Most organizational requirements are functional or business-related.

However, for a variety of reasons (such as below), they can include systems design architecture elements.

Types of Organizational Requirements

Non-Technical Factors Impacting Tech Requirements

These are some of the most likely types of requirements encountered:

1. Contractual
   • Existing contracts may stipulate certain device/cloud/hardware/software vendors or SLAs. Therefore you may be constrained from using certain technologies.
   • There may be special requirements audit, data collection, or dedicated hardware for sensitive or hardware/software licenses/agreements.
   • May require license or key renewals on a certain date or certain data collection for contract auditing.
2. Dependency preference
   • Your Technology organization may hire and prefer certain technologies/vendors.
     • For example a particular cloud provider such as AWS, GCP or Azure may be required for all solutions.
   • Marketing may have an ad technology preference that should be used.
   • Analytics that should be used.
3. Cloud Governance
   • Larger orgs may have to approve new cloud environments, services
   • Governance board may have allow/deny lists of service types and services.
4. API (canonical)
   • Certain API contracts may exist that you have to adhere to in your solution.
   • Certain existing APIs may be preferential to use over newly created ones.
5. Compliance
   • Terms and Conditions
   • Contractual commitments
   • City, State, Federal laws and regulations
   • Privacy laws.
   • HIPPA, PCI
6. Accounting
   • Budget limits
   • Auditability
   • Tax requirements
   • Payment identification
7. Internationalization
   • Localization

• See below for Technical requirements such as: Performance, Scalability, Security, etc.

Priority

"Priority level" (low-high) is important when determining which non-functional items here are must-have organization requirements and/or targets

• Given free reign, a stakeholder may say they all are priorities.
• Be prepared to convey high priority may significantly increase costs, time and resources required.
• Trade-offs must be made with priority-level and resources spent to achieve it.
• Also, stakeholders must be made aware that very hight requirements can cause delays.

Performance requirements and/or Targets

(e.g. response time, throughput)

• SLA:
  • Service Level Agreements - contract between a service provider and a customer that specifies the level of service that the customer can expect from the service provider.
• SLO:
  • A Service Level Objective (SLO) is a measurable performance goal that a service provider strives to achieve in order to meet the requirements of an SLA
• KPI (Key Performance Indicator):
  • a metric used to measure the performance of a service against an SLA or SLO
• RTO (Recovery Time Objective):
  • the maximum amount of time that a service can be unavailable before it has a significant impact on the business
• RPO (Recovery Point Objective):
  • the maximum amount of data that can be lost due to a service failure before it has a significant impact on the business
• Response time:
  • The amount of time it takes for the system to respond to a user request. This could include requirements for specific actions, such as how quickly a search query must return results, or overall system response time.
• Throughput:
  • The number of requests the system can handle within a given period of time. This could include requirements for how many transactions per second the system must be able to process, or how many concurrent users the system must support
• Resource usage:
  • The amount of resources (e.g. memory, CPU) the system must use to perform its functions.
  • This could include requirements for maximum or minimum resource usage, or for the system to use resources efficiently.
• Latency:
  • The delay between a request being made and the start of the processing of the request.
• Error rate:
  • The number of errors that occur during system operation. This could include requirements for maximum allowable error rate, or for the system to have robust error handling capabilities.
• Load time:
  • The amount of time it takes for the system to start up and be ready for use.
• Concurrency:
  • The ability of the system to handle multiple requests and actions at the same time.
• Reliability and availability:
  • The ability of the system to function correctly and remain operational over a specified period of time.
• Scalability:
  • The ability of the system to handle an increasing number of users or transactions without a decrease in performance.
• Performance testing:
  • The requirement to test the system to ensure that it meets the specified performance requirements

Scalability requirements (e.g. ability to handle an increasing number of users or transactions)

• Horizontal scalability:
  • The ability of the system to handle an increasing number of users or transactions by adding more servers or other resources to the system.
• Vertical scalability:
  • The ability of the system to handle an increasing number of users or transactions by upgrading the resources of a single server, such as by adding more memory or CPU.
• Auto-scaling:
  • The ability of the system to automatically adjust its resources based on usage patterns or other factors.
• Cloud scalability:
  • The ability of the system to be deployed and scaled on a cloud-based infrastructure.
• Multi-tenancy:
  • The ability of the system to support multiple independent tenants or customers, each with their own set of resources and data.
  • This type of scalability allows a single instance of the system to be shared among multiple organizations or users, rather than having to deploy a separate instance for each one.

Availability requirements (e.g. percentage of time the system must be operational)

• Uptime:
  • A requirement for the system to be operational and available for a specified percentage of time, often expressed as a percentage (e.g. 99.9% uptime).
• Disaster recovery:
  • A requirement for the system to have robust disaster recovery capabilities, such as failover mechanisms or backup systems, to ensure that it can remain operational in the event of a disaster or other disruption.
• Redundancy:
  • A requirement for the system to have multiple redundant components, such as servers or network connections, to ensure that it can continue to operate even if one component fails.
• Fault tolerance:
  • A requirement for the system to be able to tolerate and continue to operate in the event of component failures or other errors.
• High availability:
  • A requirement for the system to be highly available, meaning that it must have minimal downtime and be operational as much as possible. This could include features such as automatic failover or active-active clustering to ensure that the system is always available to users.

Security requirements (e.g. data encryption, user authentication)

1. Confidentiality

• only authorized users have access to sensitive data, such as personal information or financial records.

2. Integrity

• data is not tampered with or modified without authorization.

3. Availability

• software and its associated data is accessible to authorized users at all times.

4. Compliance

• software adheres to relevant industry regulations, such as HIPAA for healthcare or PCI-DSS for payment card security.

5. Authentication

• only authorized users can access the software and its data, through methods such as username and password, multi-factor authentication, or biometric identification.

6. Authorization

• users can only perform actions that they are authorized to perform, based on their role or level of access within the organization.

7. Encryption

• data is securely encrypted both in transit and at rest, to protect against unauthorized access or disclosure.

8. Security monitoring

• Regular monitoring of the software and its usage, for any suspicious activity or potential breaches.

9. Incident response plan

• Having a detailed plan in place for how to respond to security incidents, such as data breaches or network intrusions. 10. Regular security updates and Patches
• Regularly updating software to fix known vulnerabilities and protect against potential attacks. 11. Penetration Testing
• Regularly testing the software to identify vulnerabilities that may be exploited by attackers.

Compliance requirements (e.g. adherence to industry regulations or standards)

• Data privacy:
  • A requirement for the system to comply with data privacy regulations, such as the General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA), by protecting personal data and ensuring that data is used appropriately.
• Payment Card Industry Data Security Standards (PCI-DSS):
  • A requirement for the system to comply with PCI-DSS if it handles or processes credit card information, which includes specific security controls to protect credit card data.
• Health Insurance Portability and Accountability Act (HIPAA):
  • A requirement for the system to comply with HIPAA if it handles or processes personal health information, which includes specific security controls to protect this sensitive information.
• Federal Risk and Authorization Management Program (FedRAMP):
  • A requirement for the system to comply with FedRAMP if it is a cloud service provider, which includes specific security controls to protect the data stored in the cloud.
• International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR):
  • A requirement for the system to comply with ITAR or EAR if it handles or processes export-controlled data, which includes specific security controls to protect this data.

Maintainability requirements (e.g. ease of updating or troubleshooting the system)

• Code readability:
  • The software should be written in a way that is easy to understand and navigate, with clear and consistent naming conventions and documentation.
• Modularity:
  • The software should be broken down into small, reusable modules that can be easily modified or replaced without affecting the rest of the system.
• Testability:
  • The software should be designed in a way that makes it easy to write and run automated tests, to ensure that changes to the code do not introduce new bugs.
• Scalability:
  • The software should be able to handle an increasing number of users and/or data without requiring significant changes to the underlying system.
• Flexibility:
  • The software should be designed to be adaptable to changing requirements and technologies, so that it can be easily updated or extended over time.
• Version control:
  • The software should be version controlled to ensure that it can be easily reverted to a previous version if issues arise.
• Extensibility:
  • The software should be designed to be easily extended to include new features or functionality.
• Configuration management:
  • The software should be designed to be easily configured, deployed, and scaled in different environments.
• Error handling:
  • The software should have a robust error handling system that can detect and report on errors to help support team to diagnose and fix issues.

Usability requirements (e.g. ease of use for end-users)

• There may be organization standards for consistent layout, color schemes, and typography, as well as clear labeling and feedback mechanisms.

Supportability requirements (e.g. ability to provide customer support for the system)

Deployment requirements (e.g. hardware and software environment in which the system will be deployed)

Testing requirements

• Test coverage:
  • The software should be thoroughly tested to ensure that all features and functionality are working as intended.
• Automated testing:
  • The software should be designed in a way that makes it easy to write and run automated tests, to ensure that changes to the code do not introduce new bugs.
• Test documentation:
  • The software should have clear and comprehensive documentation of the testing process, including test cases and test results.
• Test environment:
  • The software should be tested in a variety of environments, including different operating systems, browsers, and hardware configurations.
• Performance testing:
  • The software should be tested to ensure that it performs well under heavy load, and that it meets the organization's performance requirements.
• Security testing:
  • The software should be tested to ensure that it is secure and that it meets the organization's security requirements.
• User acceptance testing:
  • The software should be tested by a representative group of users to ensure that it meets their needs and that it is user-friendly.
• Accessibility testing:
  • The software should be tested to ensure that it is accessible to users with disabilities and that it meets the organization's accessibility requirements.
• Internationalization testing:
  • The software should be tested to ensure that it works properly when localized for different languages and cultures.
• Regression testing:
  • The software should be tested to ensure that changes or updates do not introduce new bugs or break existing functionality.
• Integration testing:
  • The software should be tested to ensure that it integrates well with other software and systems that it needs to work with.

Vendor requirements:

• If contracts have been signed giving preference or restrictions to certain vendors, or requiring their input.

Technical best practice requirements

Global cloud governance requirements