Please see the SAP Analytics Approach document, section 'Documentation' for more information about the context of this document.

 It is to be populated by the story owner and the reporting functional consultant collaboratively.  

It does NOT describe business logic e.g. KPI definitions delivered by the data models (e.g. analytic models) that it consumes. This is covered in the Data Model Functional Specification  

If a requirement is for a flat table, then this will be delivered as a story and this document may simply show the order of the columns.  Where more detailed requirements for a story layout are known, this template will capture these requirements. 

 As story building is an iterative and agile process, it is expected that this document will be updated through the development process.

High-Level Specification

Functional Overview

Describe why the report/analytics is needed:

What business requirements it will address, 

What business questions it will answer 

Why it is important to the business.

Scope

Describe the scope of this report/analytics. Scope can cover any limitations in terms of functional, regional, application and data usage.

Process Flow Diagram

This section is predominantly for planning stories and can be deleted if not applicable. Insert the flowchart and fill in the steps. The flowchart will detail how (it is anticipated) that the user will navigate through the screens and what order they will perform activities.

Solution Overview

Content Ownership: Functional Consultant, Input from: Reporting & Analytics Consultant

Story Definition

Overview Page 

Optional. This page details what the story does and, if a multipage story, acts as an index. State if required and, if so, what it should contain.

Story Page N

Page Objective

Page filters

Page level input controls

Calculations

(Only if not possible within Datasphere).

Layout

This section will contain a wire-frame of the page indicating the widgets on it. The wire-frame can be a draw-io diagram or a screenshot of e.g. an excel mock-up.

 If there are multiple data models in the story, indicate which data models the widget takes data from at page or widget level.

Widget level details such as filters, dimensions, hierarchy usage, history, comparatives, targets, thresholds, top N etc can also be included. N.B. This level of detail is not mandatory and often changes through the iterative development process. For tables, indicate the number of expected rows.

If multiple datasources consumed by story:

Story Page N+1 (etc.)

As story page N.

Story Filters

Details any filters that apply to the entire story. N.B. Most mandatory (e.g. security variables) should be applied in Datasphere.

Data models 

This section lists the data models consumed by the story and links to the functional specification describing them.

Business Roles

List the business roles who will be executing the report

Design Rationale

Content Ownership: Functional Consultant, Input from: Reporting & Analytics Consultant

Assumptions

Describe any assumptions that have been made in the process of completing this design. What functionality is expected of configuration or other developments that pass information to this development and/ or retrieve the information processed by it (performance, triggers, exceptions, etc)

Dependencies

Indicate any dependencies or constraints that may impact development, in terms of requirements from internal or external applications or teams, limited access to legacy system, time constraints or data restrictions. Also, please specify schedule dependencies e.g. interface or batch jobs that must run prior to execution.

Special Requirements

Specify any special requirements or considerations that may impact the development based on specific locations, regulatory compliance or system limitations. Clearly outline requirements e.g. localization rules for countries like China

If the development interacts with third-party systems such as Icertis, describe any additional integration, security or authentication considerations that must be taken into account.

Frequency of Analysis/Report Run

Provide information regarding report run frequency like ad-hoc, monthly analysis, weekly, yearly analysis etc.

Testing Considerations / Dependencies

N.B. Unless this is a planning story, the testing should cover layout and user experience NOT data values for metrics created in the data model. Data model values will be tested in conjunction with the data model specification.

How to test

Please provide some guidance and/or test data to help the developer unit test the report. Please include both positive and negative testing (to validate error situations handling)

List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI).

The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions performed so the test may be run again, or explain how to create new input data to the test. In particular, the developer will need logons for test users representing the various roles within the approval process.

Test Conditions and Expected Results

Testing Considerations / Dependencies

List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.

Other Requirements

Description of requirements not covered by topics above

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log