Change Request Functional Requirement

DiGi Telecommunications Sdn Bhd (201283-M)

Confidential

<Project Name> <CR Ref Number: NodeName-YY001>

Functional Requirements

Doc. Ref. Number Filename Revision Date of Issue Author Position

CR

1 of 15

Change Request Functional Requirement

DiGi Telecommunications Sdn Bhd (201283-M)

Confidential

Document History Version Date of issue Author Comments

CR

2 of 15

Change Request Functional Requirement

DiGi Telecommunications Sdn Bhd (201283-M)

Confidential

Table of Contents
1 DESCRIPTION OF SERVICE/PRODUCT 2 STATEMENT OF REQUIREMENTS 3 FUNCTIONAL REQUIREMENTS 3.1 PRODUCT PERSPECTIVE 3.2 PRODUCT FUNCTIONS 3.3 USER CLASSES AND CHARACTERISTICS 3.4 DESIGN AND IMPLEMENTATION CONSTRAINTS 3.5 REPORTS INFORMATION 3.6 ADMINISTRATION 3.7 HANDSET & DEVICE ASSUMPTIONS AND DEPENDENCIES 3.8 OTHER ASSUMPTIONS AND DEPENDENCIES 4 OPERATIONAL REQUIREMENTS 4.1 KEY PERFORMANCE INDICATORS / KEY QUALITY INDICATORS 4.2 PERFORMANCE REQUIREMENTS 4.3 SECURITY REQUIREMENTS 4.4 PRODUCT QUALITY ATTRIBUTES 4.5 BUSINESS RULES 5 SYSTEM ARCHITECTURE 5.1 OPERATING ENVIRONMENT 5.2 SERVER & PC ARCHITECTURE 5.3 NETWORK ARCHITECTURE 5.4 DATABASE ARCHITECTURE 5.5 APPLICATION ARCHITECTURE 6 EXTERNAL INTERFACE REQUIREMENTS 6.1 USER INTERFACES 6.2 HARDWARE INTERFACES 6.3 SOFTWARE INTERFACES 5 5 6 6 6 6 7 7 7 7 7 8 8 8 8 8 9 9 9 9 9 9 10 10 10 10 10

CR

3 of 15

Change Request Functional Requirement

DiGi Telecommunications Sdn Bhd (201283-M)

Confidential

6.4 ALARM INTERFACES 6.5 COMMUNICATIONS INTERFACES 6.6 BILLING INTERFACES 7 DOCUMENTATIONS AND TRAINING 7.1 TIME PLAN 7.2 DOCUMENTATION AND MANUAL 7.3 TEST PLAN 7.4 TRAINING 8 USE CASES 8.1 USE CASE 1 8.2 USE CASE 2 (AND SO ON)

11 11 11 12 12 12 12 12 13 13 15

CR

4 of 15

Change Request Functional Requirement

DiGi Telecommunications Sdn Bhd (201283-M)

Confidential

1 DESCRIPTION OF SERVICE/PRODUCT
<Provide a short description of the product or service and its purpose, including relevant objectives, and goals. A reminder: The product or service propose must relate to DiGi corporate goals or business strategies. > Need to refer to the corporate strategy documents Note: this document could/should be used to desribe a service or product that PD/PM are intending to terminate or outsource as well!

2 STATEMENT OF REQUIREMENTS
This section contains the Statements of Requirements that address DIGIs business requirements. Additional features not mentioned in the Statement of requirements that are deemed useful and beneficial to DIGI shall be proposed as supplementary information to the response of this document. The Vendor shall follow instructions outlined below in preparing the responses. The Vendor shall respond to all questions contained in the Statement of Requirements. Response must also be provided for detailed requirements defined within each question. Please ensure the response to each item is complete and accurate, as the response will be taken as firm commitment for the delivery of the proposed solution. In completing this section, Vendor is requested to indicate the availability of each functional requirement by stating in the response column (S, M1, M2, X) as defined in the following section. S M1 STANDARD feature. Requirement is met fully by the base package at no additional cost. MODIFICATION. Requirement is not met by the standard base package but feature can be provided by modifying the base and/or additional packages at no additional cost. M2 MODIFICATION. Requirement is not met by the standard base package but feature can be provided by modifying the base and/or additional packages at additional cost. X NOT AVAILABLE AND WOULD NOT MODIFY.

CR

5 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

3 FUNCTIONAL REQUIREMENTS
3.1 PRODUCT PERSPECTIVE
<Describe the context and origin of the product being specified in this FR. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.>

3.2

PRODUCT FUNCTIONS
<Summarize the major functions the product must perform or must let the user perform. Details will be provided in Section 9, so only a high level summary (such as a bullet list) is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or object class diagram, is often effective.>

3.3

USER CLASSES AND CHARACTERISTICS

<Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the most important user classes for this product from those who are less important to satisfy.>

CR

6 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

3.4

DESIGN AND IMPLEMENTATION CONSTRAINTS

<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customers organization will be responsible for maintaining the delivered software).>

3.5

REPORTS INFORMATION
<List the user reports require to be produce by this system including the contents, format, owner and purpose of the report>

3.6

ADMINISTRATION
<List the application administration level and access policy>

3.7

HANDSET & DEVICE ASSUMPTIONS AND DEPENDENCIES

<List any handset or terminal dependencies here>

3.8

OTHER ASSUMPTIONS AND DEPENDENCIES

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the FR. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as other projects.>

CR

7 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

4 OPERATIONAL REQUIREMENTS
4.1 KEY PERFORMANCE INDICATORS / KEY QUALITY INDICATORS
<Describe what key performance and/or service indicators are required to be used to measure the service availability and quality from an end user perspective. These should include: provisioning metrics, call event processing and completion metrics, and maybe even (internal or external) process metrics. These should also describe what changes to existing Key Performance Indicators and/or Key Quality Indicators are required.>.

4.2

PERFORMANCE REQUIREMENTS
<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>

4.3

SECURITY REQUIREMENTS
<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>

4.4

PRODUCT QUALITY ATTRIBUTES

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability,

CR

8 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

4.5

BUSINESS RULES
<List any operating principles about the product, such as which individuals or roles can perform which functions under specific circumstances. These are not functional requirements in themselves, but they may imply certain functional requirements to enforce the rules.>

5 SYSTEM ARCHITECTURE
5.1 OPERATING ENVIRONMENT
<Describe the environment in which the service will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>

5.2

SERVER & PC ARCHITECTURE

<Describe the servers logical and physical architecture in which the service will operate, including the hardware platform, operating system, system availability and versions>

5.3

NETWORK ARCHITECTURE
<Describe the network architecture in which the service will operate, including the LAN, WAN, firewall rules, security and versions>

5.4

DATABASE ARCHITECTURE
<Describe the database architecture in which the service will operate, including the

CR

9 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

disk usage, kernel parameters, and versions>

5.5

APPLICATION ARCHITECTURE
<Describe the application architecture in which the service will operate, including client/server, web, service availability and versions>

6 EXTERNAL INTERFACE REQUIREMENTS

6.1 USER INTERFACES <Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Details of the user interface design should be documented in a separate user interface specification.> 6.2 HARDWARE INTERFACES
<Describe the logical and physical characteristics of each interface of the service. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used. Provisioning for functional, Operations & Maintenance, provisioning, and billing interfaces separately if possible.>

6.3

SOFTWARE INTERFACES
<Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools,

CR

10 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint. Provisioning for functional, Operations & Maintenance, provisioning, and billing interfaces separately if possible >

6.4

ALARM INTERFACES
<Describe the requirements associated with any communications functions from this product to DiGi alarm systems>

6.5

COMMUNICATIONS INTERFACES
<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms. Provisioning for functional, Operations & Maintenance, provisioning, and billing interfaces separately if possible >

6.6

BILLING INTERFACES
<Describe any requirements specific to billing collection and rating>

CR

11 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

7 DOCUMENTATIONS AND TRAINING

7.1 TIME PLAN
<Describe the project milestone activities and time plan>

7.2

DOCUMENTATION AND MANUAL

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the service. Identify any known user documentation delivery formats or standards.>

7.3

TEST PLAN
<List the test plan to be deliver together with the project>

7.4

TRAINING
<List the training to be deliver together with the project>

CR

12 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

8 USE CASES
<This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. This section is organised by use case >

8.1

USE CASE 1
<Dont really say Use Case 1. State the feature name in just a few words.>

Use Case ID: Use Name: Case Last Updated By: Date Last Updated:

Created By: Date Created:

User:

An user is a person or other entity external to the service system being specified who interacts with the system and performs use cases to accomplish tasks. Different users often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the users(s) that will be performing this use case. Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions and the outcome of executing the use case List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each precondition. Examples: Users identity has been authenticated.

Description:

Preconditions:

CR

13 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

Users computer has sufficient free memory available to launch task. Postconditions: Describe the state of the system at the conclusion of the use case execution. Number each postcondition. Examples: Document contains only valid SGML tags. Price of item in database has been updated with new value. Priority: Indicate the relative priority of implementing the functionality required to allow this use case to be executed. The priority scheme used must be the same as that used in the software requirements specification Estimate the number of times this use case will be performed by the actors per some appropriate unit of time Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, How do I <accomplish the task stated in the use case name>? This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use Case ID as a prefix, followed by AC to indicate Alternative Course. Example: X.Y.AC.1 Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use case execution fails for some unanticipated reason. Number

Frequency of Use: Normal Course of Events:

Alternative Courses:

Exceptions:

CR

14 of 15

Change Request Functional Requirement

Confidential

DiGi Telecommunications Sdn Bhd (201283-M)

each exception using the Use Case ID as a prefix, followed by EX to indicate Exception. Example: X.Y.EX.1 Includes: List any other use cases that are included (called) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description. List any additional comments about this use case or any remaining open issues or TBDs (To Be Determineds) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is

Special Requirements:

Assumptions:

Notes and Issues:

8.2

USE CASE 2 (AND SO ON)

CR

15 of 15