15
Target System Development Non-Functional Requirements Job Aid Non-Functional Requirements Job Aid Non-functional requirements are requirements that cannot be met by a specific function of the application. This document provides guidance that may be used to elicit and analyze non-functional requirements for your project. In the matrix on the subsequent pages you will find probing questions, examples, potential TTS partners, and testing considerations for common types of non-functional requirements. Probing Questions – These common questions can be used to elicit non-functional requirements from your stakeholders. Some of these questions may be duplicates of questions answered in the RIP process, however the primary purpose of the RIP process is to identify standard solutions which does not necessarily include defining the level to which the system should operate. When gathering requirements it is important to identify all stakeholders and end users to ensure that requirements are gathered in the most complete manner. As you identify stakeholders and requirements gathering techniques, you may wish to document them in the Requirements Gathering Plan for your project. Be sure to include other TTS partners as relevant stakeholders. Examples - This document provides examples of non-functional requirements, however every project will have unique requirements. For example, enhancements might impact only a few non-functional areas (ex. adding significant new functionality or deploying an application to a new user base may result in increased capacity and performance requirements). For vendor/package applications, these examples can be used in the RFP process. Potential TTS Partners - TTS partners, including SPOCs (Single Points of Contact) in Engineering and subject matter experts from infrastructure teams, should be included in the non-functional requirements gathering process to ensure that requirements are clear, realistic and in compliance with Target Standards. Design Considerations – This document also shows examples of technical design considerations (which describe “how to” meet the requirements) to be evaluated during the Design phase. Testing Considerations – Non-functional requirements should be traced through design and into the testing phase to ensure adequate test coverage of all requirements. In addition to the Requirements Traceability Matrix, relevant sections of the Master Test Plan should be updated to plan for various types of testing. 1 document.doc Version 3.0, November 2007

Non-Functional Requirements Job Aid

Embed Size (px)

Citation preview

Page 1: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional Requirements Job Aid

Non-functional requirements are requirements that cannot be met by a specific function of the application. This document provides guidance that may be used to elicit and analyze non-functional requirements for your project. In the matrix on the subsequent pages you will find probing questions, examples, potential TTS partners, and testing considerations for common types of non-functional requirements.

Probing Questions – These common questions can be used to elicit non-functional requirements from your stakeholders. Some of these questions may be duplicates of questions answered in the RIP process, however the primary purpose of the RIP process is to identify standard solutions which does not necessarily include defining the level to which the system should operate. When gathering requirements it is important to identify all stakeholders and end users to ensure that requirements are gathered in the most complete manner. As you identify stakeholders and requirements gathering techniques, you may wish to document them in the Requirements Gathering Plan for your project. Be sure to include other TTS partners as relevant stakeholders.

Examples - This document provides examples of non-functional requirements, however every project will have unique requirements. For example, enhancements might impact only a few non-functional areas (ex. adding significant new functionality or deploying an application to a new user base may result in increased capacity and performance requirements). For vendor/package applications, these examples can be used in the RFP process.

Potential TTS Partners - TTS partners, including SPOCs (Single Points of Contact) in Engineering and subject matter experts from infrastructure teams, should be included in the non-functional requirements gathering process to ensure that requirements are clear, realistic and in compliance with Target Standards.

Design Considerations – This document also shows examples of technical design considerations (which describe “how to” meet the requirements) to be evaluated during the Design phase.

Testing Considerations – Non-functional requirements should be traced through design and into the testing phase to ensure adequate test coverage of all requirements. In addition to the Requirements Traceability Matrix, relevant sections of the Master Test Plan should be updated to plan for various types of testing.

1document.docVersion 3.0, November 2007

Page 2: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

AvailabilityWhat is the anticipated criticality of this application to Target Corporation?

Is this a guest facing application?

During which time period(s) does your application need to be available?

Will this application have a “peak” time period (i.e. for HR it is benefits enrollment, for Stores it is the holiday season)?

The application is a mission critical system that will need to be highly available (99.99% availability not including planned maintenance outages which is the equivalent of approximately 10 minutes of unplanned downtime per week)

The application will need to be available as needed in the normal course of business operations (98% availability not including planned maintenance outages which is the equivalent of approximately 3 hours of unplanned downtime per week)

The application needs to be available 7 days a week, 24 hours per day.

Business Continuation

ESM CSC ESS Server Tech DBA Web Application

Services (WAS)

Add redundant infrastructure

Mitigate single points of failure

Load balancing Offline capabilities Uptime monitoring Frequency of backup

schedules Reduce batch

windows Event based job

scheduling rather than time based

Test load balancing, failover, and disaster recovery mechanisms

Update Failover and Recovery Testing plans in the Master Test Plan

2document.docVersion 3.0, November 2007

Elicit high-level non-functional requirements from the business.

Define S.M.A.R.T non-functional requirements based on collaboration with business and TTS

Partner with the appropriate TTS teams to ensure that requirements are clear and realistic.

Ensure traceability through design and testing

Page 3: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

RecoverabilityIn the event of a Target data center disaster (i.e. data center unavailable) is your app critical for Business Continuation? It is critical if you meet one or more of the following conditions: 1) Significant/immediate impact to sales (> 20% of all sales impacted). 2) Significant/immediate impact to Supply Chain Effectiveness. 3) Mandatory Legal/Regulatory Requirements would not be met. 4) Significant impact to Guest, Team Members, Shareholders and/or Community that would adversely impact Targets image.

Are there any dependent downstream or upstream systems that this application relies on that should be included in the recovery plan?

Application and data will need to be backed-up and recoverable in the event of data corruption or data loss.

In the event of a disaster, the application is mission critical and will require an immediate RTO (Recovery Time Objective).

In the event of a disaster, the application is critical and will require a 48 hour RTO (Recovery Time Objective).

In the event of a disaster, the application will require a 7 day RTO (Recovery Time Objective).

In the event of a disaster, the application will require a 30 day RTO (Recovery Time Objective).

Business Continuation

An immediate RTO implies mirrored hardware, software, application data, and network components at a second site.

A 48 hour RTO implies replicated hardware, software, application data, and network components at a second site.

A 7 day RTO implies replicated hardware and network components in standby mode at a second site and offsite backups of software and data

A 30 day RTO implies minimal advanced planning, purchase of hardware and network components, and offsite storage of backup copies

Test load balancing, failover, and disaster recovery mechanisms

Update Failover and Recovery Testing plans in the Master Test Plan

3document.docVersion 3.0, November 2007

Page 4: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

SupportabilityWhat level of support is needed (ex. Gold level, Severe level, Major level, etc)?

This application needs to be supported at the Gold level (i.e. System availability must be recovered within one hour.)

This application needs to be supported at the Severe level (i.e. Impact is to 20% or more of stores in an operating company, one or more DCs, or business groups.)

This application needs to be supported at the Major level (i.e. Potential impact is to 15% or more of stores in an operating company, one or more DCs, or business groups.)

This application needs to be supported at the Significant level (i.e. Loss of system availability impacts non-critical systems for more than a single user.)

This application needs to be supported at the Minor level (i.e. Loss of system availability has a minimal operational impact, affects a single client.)

Transition Services CSC ESS DBA

Ensure system documentation can be made available.

Build in critical error tracking, troubleshooting reports, issue alerts, or other error reporting mechanisms.

Engage with Transition Services and ESS during design.

4document.docVersion 3.0, November 2007

Page 5: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

Capacity/ScalabilityHow many total users are expected to access your application? If this project is an enhancement, will the number of total users be significantly affected by the enhancement?

What is the expected growth of total users per year?

How many concurrent users are expected to access your application?

What is the expected growth of concurrent users per year?

What are the approximate data storage space requirements needed? If this project is an enhancement, will the space requirements be significantly affected by the enhancement?

What is the main driver of application growth (e.x. sales growth, increase in product sku’s, increased number of supported stores, increased number of employees, more product flow through a distribution center, etc)?

The application will require access for 1,000 users.

The application will need to allow access for 2,000 users in two years considering business growth projections.

The application will have an average of 400 concurrent users and a peak of 500 concurrent users.

The application will need to allow access for 500 concurrent users and a peak of 600 concurrent users considering business growth projections.

The application must provide visibility to capacity thresholds in terms of volume matrices.

The application must provide visibility to capacity thresholds in terms of performance matrices.

The application must be able to store all current customer data and must be able to accommodate 10% annual growth in customer data.

Enterprise Capacity Planning

Enterprise Performance Services

Performance Testing Services

Network DBA ISC ServerTech Web Application

Services (WAS) Workstation

Engineering and Mobile Engineering

Enterprise Capacity Planning

DBA BSO-Backup/

Storage Operations Enterprise Storage ServerTech Web Application

Services (WAS)

Sizing (CPU/Disk/RAM/IO)

Clustering Shared Environments Virtualization

Performance Testing Services

E2E Certification Proof of Concept to

refine CPU/Disk/RAM/IO sizing requirements

Performance Testing Services

E2E Certification Update Performance

Test plans in the Master Test Plan

5document.docVersion 3.0, November 2007

Page 6: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

PerformanceWhat is the maximum round-trip response time (in seconds) your application must process a user request? (i.e. for the client to see results).

Which locations will users be accessing the application from?

What is the peak number of activities for an hour (e.g. Transactions, Lookups)?

What is the anticipated growth in the amount of activity your application will process per hour?

What is the largest transaction size?

Are there any specific time limits on regular load rates (i.e. does system need to load bulk data on a regular basis)?

For a HQ user, the web page response time for read only needs to be <=3 seconds (95% of the time) and maximum of 5 seconds

For a HQ user, the web page response time for Update/Insert/Delete needs to be <=3 seconds (95% of the time) and maximum of 7 seconds

For an overseas user, the web page response time for read only needs to be <=5 seconds ( 95% of the time) and maximum of 7 seconds

For an overseas user, the web page response time for Update/Insert/Delete needs to be <=5 seconds (95% of the time) and maximum of 9 seconds

Reports and inquiries need to be generated within 20 seconds to display contents.

The application needs to be able to process 5,000 transactions/lookups per hour.

The solution must be able to load 50000 transactions via the API in less than one hour.

The solution requires the ability to handle a peak average of 200 completed and attempted fill per pharmacy per day.

Enterprise Capacity Planning

Enterprise Performance Services

Performance Testing Services

Network DBA ServerTech Web Application

Services (WAS)

Move the data closer to the client (ex. caching)

Move the client closer to the server (ex. Citrix)

Reduce the number of trips that are made between server and client (ex. encapsulate data intensive logic as stored procedures)

Reduce the amount of data that is sent over the WAN (ex. Network compression devices, Application page compression, limit page size to be less than 256k)

Move large data files to the client during off-peak times (ex. Wide area file sharing such as Tacit)

Purchase additional bandwidth.

Performance Testing Services

E2E Certification Utilize Testing

Simulation Tools (Shunra, LoadRunner)

Include off-site users in User Acceptance Testing

Update Performance Test plans in the Master Test Plan

6document.docVersion 3.0, November 2007

Page 7: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

SecurityWhat type of data will be provided to your users by your application?

Is any of your data cover by regulatory requirements?

What is the anticipated criticality of this application to Target Corporation?

What degree of strength is need in the authentication process? What degree of confidence is required to ensure that users are who they say they are?

Will the application need to be accessible over the Internet?

Does the application need to be accessible from outside of Target?

Note: Complete the Security Requirements Questionnaire. Based on the results of the questionnaire, either incorporate the default Non-Functional Security Requirements into the project’s requirements document or work with [email protected] to determine project specific Non-Functional Security Requirements.

ISC WAS ServerTech Network DBA Web Application

Services (WAS)

Contact Security.Consulting for assistance.

Use role-based access profiles during execution of test cases to ensure that authorizations in roles have been setup properly.

Partner with ISC to develop independent security assessments and audits

Update Security and Access Control Test plans in the Master Test Plan

Inter-Application InterfacesHave you considered all other systems that your application/solutions will integrate with?

Are interfacing systems internal or external to Target? If so, will the interfaces require any special handling?

Will interfacing systems need to

The solution must include a real-time interface with Lawson via file transfer in order to post journal entries to General Ledger (GL) and interface errors will need to be monitored, escalated, and timely resolved.

Any dependent applications (i.e. any upstream applications) and middleware will need to be highly available to meet this application’s availability requirements.

Integration Architecture

BI Tools Architecture

Data translation Middleware systems Error handling

End to End Testing Update the Component

Integration section of the Master Test Plan.

7document.docVersion 3.0, November 2007

Page 8: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

interact in real-time or batch?MonitoringWhat type of monitoring should be in place to ensure the continuous stability, integrity, capacity, and performance of the application?

The application should allow for continuous monitoring so that job abends, volume metrics, performance metrics, and other issues can be identified and resolved appropriately.

The system hardware (ex. CPU usage, CPU temperature), operating system (ex. file system size), and database (ex. table limits) needs to provide the ability for monitoring and alerts to ensure continued availability, capacity, and performance.

ESM (Enterprise Systems Monitoring)

ESS

Job scheduling utilities

Log aggregation and correlation

Integration with the organizations standard monitoring tools

Alerts and notifications

Data Integrity

8document.docVersion 3.0, November 2007

Page 9: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

What type of data will be provided to your users by your application?

Is there any reconciliation of data that could be automated?

Will any data cleansing need to be performed when converting data from legacy applications?

The application needs to provide standardized and consistent error and exception handling.

The application needs to provide systematic processes to handle failure-restart situations thus avoiding redundant processing.

The application must have edit checks performed to validate inputs.

Automated reconciliations are required to ensure balance between input and output from a process by proper means (e.g. ACR balancing).

ESS – Data Integrity Services

Web Application Services (WAS)

Edit for errors as high up in the steam as possible (i.e. data that is not accurate for downstream processing must be rejected upstream).

Negative Testing Update Master Test

Plan.

Data RetentionWhat type of data will be provided to your users by your application?

What is the required retention period for the data?

What retention processes will be needed to accommodate these requirements?

Accounts Payable invoices must be retained for at least 7 years.

Drug labeling data must be retained for 2 years.

Note: Target’s Record Retention Policy is available on-line and provides information about how long each type of record is to be kept (retention period) and what is to happen to the record at the end of that period (destruction). Consider requirements for data retention, data purge, and

Records Management

DBA BSO-Backup/

Storage Operations Enterprise Storage ISC

Archiving Purging Data backup and

recovery utilities, processes, and schedules

9document.docVersion 3.0, November 2007

Page 10: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

Non-Functional RequirementsProbing Questions Examples of Non-Functional Requirements Potential TTS Partners Design Considerations Testing Considerations

Are there any requirements to purge data? data archive.

EnvironmentWhat components are expected as part of the overall system architecture?

Should the system be certified by any external third parties?

The application will need to integrate with several peripherals such as card readers, scanners, etc.

The solution must include support for multiple languages.

The application must be accessible from mobile technology such as PDAs.

The product must be capable of being updated and patched via a Target Standard Software Management System (MS SMS).

Vendor application must support Site Minder for Web authentication

The product must be capable of backup and recovery using Targets standard software with is EMC Legato Network.

The system will need to be certified by “ABC” third party (ex. banks, government agencies, other).

Note: System components should be identified through the RIP process to ensure that the solutions are in alignment with the Target standard.

Enterprise Architecture

ServerTech WorkStation

Engineering and Mobile Engineering

Utilize RIP to identify standard solutions

Training and DocumentationWhat user training is required?

What support documentation is required?

Users will need training on how to use the application.

A help menu will be needed as a reference for users.

10document.docVersion 3.0, November 2007

Page 11: Non-Functional Requirements Job Aid

Target System DevelopmentNon-Functional Requirements Job Aid

11document.docVersion 3.0, November 2007