Strategic Non-Functional Requirements

From MIKE2.0 Methodology

Activity: Strategic Non-Functional Requirements

Objective

Strategic Non-Functional Requirements need to be gathered from the business and technical users to complement the strategic functional requirements for the solution. These requirements, whilst in many ways just as important for vendor selection, are often overlooked until later stages of the project.

Many client environments will have a more defined set of standards in this area, especially regarding security, backup and recovery and archiving. Understanding what standards are already in place and which ones are most strictly adhered to is an important part of this activity.

Across each of the categories below, the non-functional requirements should be defined for developing applications, infrastructure and information. Applications as defined here only apply to Business Intelligence applications.

Listed below are some example categories of non-functional requirements. The should be defined at the strategic level, which is only detailed enough to make long-term technology decisions.

Non Functional Requirements Categories:

Useability

• Business users presentation interface
• Operations interface usability
• Documentation standards

Backup and Restore

• Requirements for Backup of Data
• Offline archiving requirements
• Minor Failure Recovery Requirements
• Major Failure Recovery Requirements

Minor failures are a disruption requiring restarting servers or operations other than database or hardware. Major failures relate to disruption requiring database restoration or hardware replacement. Fail-over points where the system activity cannot proceed would need to be identified. Monitoring around these components, along with auto restart and support notification in this situation would need to be determined. Major Recovery requirements include Disaster Recovery requirements.

Availability Requirements

Availability Requirements are defined as the period of time that the Product/Service is supported and available for use by the Customer, expressed as a fraction of the Support Coverage Period. These requirements can be defined at either the overall system level or for underlying components.

Error Handling

Error Handling describes the mechanism for dealing with either business or technical error conditions. These requirements would define how to handle exception cases and the level of automation required if a failure scenario occurs. This includes the alerts and notifications that will need to occur.

Transaction and Data Integrity

Provide the requirements around integrity of data at rest in systems and the validation rules and processes for issues with data flowing between systems. This includes process rules for loading data or notifying users should this occur.

Implementation and Supportability

• Hardware and Software SOE compliance requirements
• Requirements for Deployment process
• Change Management and training requirements
• Overall solution maintainability requirements
• Software reuse requirements
• Development Standards

Operations and Monitoring

• Component Monitoring
• Platform Monitoring
• System Administration and Maintenance

Performance and Configuration

• Expected Business Volumes
• System Responsiveness
• Performance Requirements
• Process Performance
• Vertical and Horizontal Scalability requirements
• Configurability

Security

• Data Security
• Encryption Requirements
• Privacy issues
• Physical access security

Major Deliverables

• Non-Functional Requirements across Applications, Infrastructure and Information Management

Tasks

Define Non-Functional Requirements for BI Application Development

Objective:

Defining the Non-Functional Requirements for the Business Intelligence system (EIS/DSS/MIS Application Development) will be particularly focused on security, usability and performance within a system.

Input:

• Strategic Functional Requirements for Application Development
• Guiding Principles
• Future-State Conceptual Architecture
• High Level Solution Architecture Options

Output:

• Strategic Non-Functional Requirements for Application Development

Define Non-Functional Requirements for Infrastructure Development

Objective:

Infrastructure Development is the workstream most impacted by the NFRs. Key activities of this task will be to determine the volumes and transformations necessary to support the information management environment. The findings are used to develop the hardware infrastructure model, network capacity plans, and process management of the information management environment. In the case of a Data Warehouse, this may involve sizing focused on a single target system; for data synchronisation this may involve multiple systems for sizing and result in more complex scenarios around peak load volumes.

Input:

• Strategic Functional Requirements for Application Development
• Strategic Functional Requirements for Infrastructure Development
• Guiding Principles
• Future-State Conceptual Architecture
• High Level Solution Architecture Options

Output:

• Strategic Non-Functional Requirements for Infrastructure Development

Define Non-Functional Requirements for Information Development

Objective:

Defining the Non-Functional Requirements for Information Development will be particularly focused on security, data integrity and performance. Initial estimates at data quality (value issues, data gaps) can be estimated at this stage.

Input:

• Strategic Functional Requirements for Application Development
• Strategic Functional Requirements for Information Development
• Guiding Principles
• Future-State Conceptual Architecture
• High Level Solution Architecture Options

Output:

• Non-Functional Requirements for Information Development

Core Supporting Assets

Yellow Flags

• End-users of the technology are not engaged to define usability requirements
• Organisation lacks a mature set of foundation capabilities for security and network infrastructure
• Organisation has had security issues in the past or is particularly impacted by data security issues

Key Resource Requirements

• Technical Business Analyst
• Information Architect
• Infrastructure Architect
• Business Architect

Potential Changes to this Activity

There is some overlap of this activity and the Strategic Requirements for Technology Backplane Development. This distinction should be made more clear.