Documente Academic
Documente Profesional
Documente Cultură
Confidential
CR
1 of 15
Confidential
CR
2 of 15
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
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
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
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
CR
6 of 15
3.4
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
3.8
CR
7 of 15
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
CR
8 of 15
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
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
5.5
APPLICATION ARCHITECTURE
<Describe the application architecture in which the service will operate, including client/server, web, service availability and versions>
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
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
7.2
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
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:
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
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
Alternative Courses:
Exceptions:
CR
14 of 15
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:
8.2
CR
15 of 15