Software Requirements
Specification
for
C
ME
- Mobile Blogging
Framework and Application
Version 1.1
Prepared by Team of Group 10
Computer Science & Engineering Department
University of Moratuwa
Table of Contents
1. Introduction...1
1.1 Purpose ... 1
1.2 Document Conventions... 1
1.3 Intended Audience and Reading Suggestions ... 2
1.4 Project Scope ... 2
1.5 References... 3
2. Overall Description ...4
2.1 Product Perspective... 4
2.2 Product Features ... 5
2.3 User Classes and Characteristics ... 6
2.4 Operating Environment... 7
2.5 Design and Implementation Constraints ... 7
2.6 User Documentation... 7
2.7 Assumptions and Dependencies ... 8
3. System Features...9
3.1 Registration... 9
3.2 Posting Media and Mediums... 9
3.3 Personalization... 10
3.4 Messaging... 10
3.5 WAP and web ... 11
3.6 Maintaining and Archiving options ... 12
3.7 Administration ... 12
3.8 Animation ... 13
3.9 Security ... 14
3.10 Billing... 14
3.11 Advanced Features ... 15
4. User Interface prototypes...16
4.1 Web Interface prototypes... 16
5. External Interface Requirements...73
5.1 User Interfaces ... 73
5.2 Hardware Interfaces ... 73
5.3 Software Interfaces... 73
5.4 Communications Interfaces... 74
6. Other Nonfunctional Requirements ...75
6.1 Performance Requirements ... 75
6.2 Safety Requirements... 75
6.3 Security Requirements... 75
6.4 Software Quality Attributes... 75
7. Other Requirements...76
Revision History
Name Date Reason For Changes Version
Software Requirement Specification for “MyDiary”- Mobile Blogging framework and Application
26-10-2006 Version 1.0
Software Requirement Specification for “
CME
”- Mobile Blogging framework and Application30-11-2006 To add interface prototypes. Change the name
1.
Introduction
1.1
Purpose
Forging ahead to next generation of messaging and value added services MyDiary will exploit the internet blog concept to offer mobile subscribers with variety of new messaging and community based services.
The SRS corresponds to the version 1.0; this fully describes the functional, non functional, external interface requirements of the product.
1.2
Document Conventions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. These key words mean the same thing whether capitalized or not.
An implementation is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the product. An implementation that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for the product is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for the product is said to be "conditionally compliant".
1.3
Intended Audience and Reading Suggestions
This SRS is intended for the below mentioned audiences. The developers
The testers The project manager
The client (undisclosed network operator).
The rest of the SRS contains overall system description, system features, external interface requirements, non functional requirements and other requirements. The above mentioned main sections will be addressed under different appropriate sub sections.
Top down approach is recommended for each audience for reading.
1.4
Project Scope
MyDiary is the realization of bringing the power of blogging to the mobile community in Sri Lanka. The network operator (the client) will be able to expand their horizons on their well established user community paving way for
Revenue Benefits Strategic Benefits Marketing Benefits
among its competitors since the idea is novel and very likely to be grabbed by the community with spread arms.
The end users (mobile community) will have the opportunity to build their own communities, create and post their own content to their own individual websites, all using their mobile phones. It is the coolest way to share pictures, text, audio and even video from a mobile phone and to let family and friends know what is happening.
1.5
References
[RFC2119] “Key words for use in RFCs to Indicate Requirement Levels”,
2.
Overall Description
2.1
Product Perspective
MyDiary will be a brand new product of its nature in Sri Lanka. It is not coupled with any other existing products hence self contained.
Figure 1.0 System Overview
2.2
Product Features
MyDiary will be providing the below mentioned main features.
The followings are the summarized version of the significant functions of the system. Finer descriptions about those functions are provided in the section 3.
Registration:
This feature enables end users to register with MyDiary moblog using different mechanisms through their mobile or through web or WAP.
Posting Media and Mediums:
This describes the different media that can be used in posting their blog contents (pictures, text, videos, sound clips, etc) and what kind of mediums are used to submit those (via SMS,.MMS, etc)
Personalization:
This feature will allow users to personalize moblogs according to their personal preferences.
Messaging:
This illustrates the interactions between the user and the blog and how, when and why the notifications are sent.
WAP and Web:
This feature will provide the presentation interfaces of the moblog. Maintaining and Archiving Options:
This specifies how users can manage and archive their profiles. Administration:
This specifies how to administer the moblog. Animation:
The dynamic and popularity measurement features are specified here. Security:
The levels of security users can have in thier blogs and how to maintain access rights are provided with this feature.
Billing
Specification of billing mechanisms found here. Advanced Features
Specifies the advanced features of the system.
2.3
User Classes and Characteristics
General users
General users are the set of frequent users who make use of the mobile communities created by themselves or others to fulfill their various expectations.
No administrative rights are granted apart from, for their own moblogs. No technical expertise is expected to be possessed by the user, being knowledgeable about handling the mobile functionalities will be adequate. Generals users MAY have certain privileges than co-operate users.
Co-operate users
This is a custom made application for a set of users in cooperate environment mainly focusing their co-operate requirements.
Apart from that they level of experience is expected to be as same as the general users. Co-operate users MAY have the lowest privilege level depending on the co-operate package policies.
Administrative users
Administrative users are responsible in administering the moblog as a whole.
They are the user group with the highest expected experience on technology and policies. They have the highest privilege levels.
Filtering Administrators
The key roles of the filtering administrator are to filter content and delete what isn’t suitable to be published in a public moblog and handle user abuse reports.
The filtering administrator is expected to know the moblog policies published by the network operator/application developer. Has higher privilege than general and co-operate user.
2.4
Operating Environment
Sun Sparc Servers / GPRS enabled phones Sun Solaris 10/9 or 8
JDK 1.5 / mySql databases
2.5
Design and Implementation Constraints
One user can have only one blog at the beginning due to operator’s constraints. Gateways can handle only 10 messages at an instance.
Restrictions due to pre picked programming language due to operator’s requirement.
2.6
User Documentation
Delivering a comprehensive user manual for the product SHOULD be supplied at the end of the project. This manual SHOULD help the application developers in using the development platform to develop various moblog applications.
2.7
Assumptions and Dependencies
The product is depended upon the SMSC, MMSC, interfaces provided, capabilities and functionalities provided.
The product is depended upon the existing components provided by the network operator.(eg. Billing API’s).
The developing environment and deployment environment are different from each other. It is assumed that if the system functions correctly in the developed environment, it will function correctly in the deployment environment too.
3.
System Features
System features and the major services provided by the product are described below.
3.1
Registration
3.1.1 Description
This feature enables end users to register with MyDiary moblog using different mechanisms through their mobile or through web or WAP.
3.1.2 Functional Requirements
(a) Corporate users SHOULD be able to do bulk registration. (b) Users MUST be able self-register to over SMS.
(c) Users MUST be able self-register to over MMS. (d) Users MUST be able self-register to over WAP. (e) Users MUST be able self-register to over the web. (f) Users SHOULD be able to over STK Application. (g) Pre-registration of users.
3.2
Posting Media and Mediums
This describes the different media that can be used in posting their blog contents (pictures, text, videos, sound clips, etc) and what kind of mediums are used to submit those (via SMS,.MMS, etc)
3.2.2 Functional Requirements
(a) Users MUST be able to post photographs, audio, video and text by MMS, SMS, IVR, web and email.
(b) Multiple attachments per entry SHOULD be supported. (c) All common media files SHOULD be supported.
3.3 Personalization
3.3.1 Description
This feature will allow users to personalize moblogs according to their personal preferences.
3.3.2 Functional Requirements
(a) Users MUST be able to change the look and feel of their Blog/Album by choosing a different skin.
(b) Users SHOULD decide their own title, description, URL, etc on each of their Blogs/Albums.
3.4 Messaging
3.4.1 Description
This illustrates the interactions between the user and the blog and how, when and why the notifications are sent.
3.4.2 Functional Requirements
a) MMS, SMS, Email Messages SHOULD be able to be composed from a user's Blog/Album
b) Users MUST be alerted when their Blog/Album is commented on by SMS, WAP Push, email or MMS.
c) Viewers can subscribe to site and SHOULD be alerted whenever the Blog is updated.
d) Cooperate Users SHOULD be have bulk messaging capabilities (SMS, WAP Push, MMS).
e) Users MUST be able to comment on the comment able contents of the moblogs.
f) User MUST be able to rate ratable contents.
g) Users MUST be able to report abuse of published content through WAP and web to an administrator
3.5
WAP and Web
3.5.1 Description
3.5.2 Functional Requirements
a) Users MUST be provided a complete WAP/web portal.
b) Every Blog/Album automatically MUST have a corresponding WAP/web site. c) WAP pages SHOULD dynamically be rendered to each individual phone's
capabilities.
d) Images MUST be scaled and displayed accordingly.
e) Users MUST be able to sign in and administer their Blog/Albums over WAP/web.
f) Users SHOULD be able to compose MMS,SMS,Email messages over WAP/web.
3.6
Maintaining and Archiving Options
3.6.1 Description
This specifies how users can manage and archive their profiles. 3.6.2 Functional Requirements
a) Each user MUST have only one profile.
b) Users MUST be able to have any number of blogs.
c) Users MUST be able to have any number of photo albums per blog.
d) Media MUST be able to move/copy between blogs/albums over web and WAP.
e) Deleted media MUST be sent to Trash Can.
3.7 Administration
3.7.1 Description
This specifies how to administer the moblog. 3.7.2 Functional Requirements
a) User self administration and central administration functions MUST be provided.
b) Filtering administrator MUST be able to filter the contents.
c) Administrators MUST be able to suspend, unsubscribe and delete user.
d) Administrators MUST be able to remove and ban user from public Blog directory.
e) Administrators SHOULD be able to generate complete reports on any date period.
f) Administrators MUST be able to find the blog statistics i.e. number of MMS, SMS, web posts etc.
3.8 Animation
3.8.1 Description
The dynamic and popularity measurement features are specified here. 3.8.2 Functional Requirements
a) Most recent, most popular directories SHOULD be visible on the relevant type of blogs.
b) Banners SHOULD be able to be displayed on the blogs.
3.9 Security
3.9.1 Description
The levels of security users can have in thier blogs and how to maintain access rights are provided with this feature.
3.9.2 Functional Requirements
a) Users MUST be identified by MSISDN.
b) Blog/Albums MUST have the capability to be either totally private, open to a community or public.
c) Automatic sign in over WAP with out password being required MUST be facilitated.
d) MMS and SMS messages automatically routed on MSISDN with out any password being required SHOULD be facilitated.
e) Web password is sent by SMS.
3.10 Billing
3.10.1 Description
Specification of billing mechanisms found here. 3.10.2 Functional Requirements
a) Reverse SMS Billing, including support for pre-paid users MUST be incorporated.
b) Bill per action (MMS, SMS composer) MUST be incorporated.
3.11 Advanced
Features
3.11.1 Description
Specifies the advanced features of the system. 3.11.2 Functional Requirements
a) It MUST be possible to have Open Community Blogs where anyone can post. b) It MUST be possible to have Closed Community Blog where only a defined
community can post.
c) Advanced image editing capabilities such as including crop, rotate and many more SHOULD be included.
4.
User Interface prototypes
4.1
Web Interfaces
The following prototypes will show the web interfaces relevant to our functional requirements.
Forgot Password interface
My Blog
In the blog panel, when you select a particular date in the calendar it will displays the corresponding events in the right hand side panel.
Buddies
Relevant interfaces for the Buddy management are as follows.
Invite buddies
My Messages
Send a Message to a Buddy – home
In the following cases, right hand panel of the above Interface will be replaced by the corresponding panel.
Inbox
The Sent Items / Trash folders will be look like the same as the Inbox.
From Subject Type Date
BuddyName Message Subject Message Type
Add an Item
The following interface is corresponding to add a picture, add a video and add a joke.
Download an Item
Searching Interfaces Search people
REGISTER<sp>< USERNAME><sp> <PASSWORD>
Message Sent. You have successfully
registered to mblog. Username : ….. Password
4.2
SMS Interface prototypes
The following prototypes will show the SMS interfaces relevant to our functional requirements.
Registration
FOGOTP<sp><NE WPASSWORD> Message Sent. Your new password is NUTSY Forgot Password ER 101, ER 003, ER 999
BLOG<sp> <SUBJECT><sp> <MESSAGE><sp> Message Sent. You have successfully posted to the blog. blog id = XXXXXX
Create a blog post
msg<sp><blogid ><sp><message > Message Sent. Message Successfully Send
Send a message to another blog
CAL<sp> <DD::MM::YY> <sp><CONTENT> Message Sent. Event successfully added. Object ID = <OBJECTID>
Add a Calendar Event
SMS <sp> <BUDDY LIST NAME> <sp><MESSAGE> <sp> Message Sent.
Your message has been sent to the buddy list.
Send a message to a buddy list
COM<sp>OBJECTI D<sp>COMMENT Message Sent. Comment Pending to be approved by <NICKNAME> Add a comment ER 101, ER 102, ER 999, ER 012, ER 013, ER 014
rate<sp><object ID><sp><value> Message Sent. Picture/...was rated successfully Rate a object ER 012, ER013,ER015,ER101.ER102,ER999
INVI<sp><MOBIL E #>
Message Sent.
Your buddy request is been sent for approvals.
Invite a friend
APPROVE<sp>MO BILE#
Message Sent. Approval successf
ul. Now, you and <NICKNAME> are connected.
<MOBLIE#>(NICK NAME> has ace pted your buddy r equest. Now you & <NICKNAME>
t d
Approve a Buddy.
ER 101, ER 102, ER 999, ER 007, ER 017 Note:
USERLEVEL<sp>O BJECTID<sp>LEV EL
Message Sent. Successfully chan
ed. User level cha nged from <PAST > to <NOW>
Change content access level.
DEL<sp>OBJECT_ ID Message Sent. Item successfully removed. Remove/Delete content ER018 / ER 012, ER 101 / ER102/ER999
DOW<sp> <OBJECT ID>
Message Sent.
Successfully download. Save content to the phone ?
Download
REM<sp> <DD:: MM::YY> <sp><MESSAGE> Message Sent. Item successfully added. Item ID = ITEM_ID Add a reminder ER101/ER102/ER 006
SEARCH<sp>TYPE
Message Sent. Top list of TYPE
ID NAME - - - - - - - - - - - - - - - - -
Download instructions.
Registration failed. You haven’t used the correct format
ERROR MESSAGES
Operation not successful. Wrong number of arguments.
You are not a registered user. You can’t use mblog facilities.
ER 999: Wrong number of arguments
Already a CMe user. Try with forget password option
Operation unsuccessful. Please check the object id and retry.
ER 022 : Already a CMe User
You don’t have permission to add a comment to this user.
The object you are trying to comment is not commentable
ER013: Not enough privileges
The object you are trying to rate is not ratable.
You can’t send an invitation to non dialog mobile user.
ER015 – Not ratable
You can’t send an invitation to non dialog mobile user.
You can not approve a friend who has not invited you.
ER 017 – Mobile number has not invited
You can not approve a friend who has not invited you.
Cannot contact the Server
ER 017 – Mobile number has not invited
Mobile Number Error
Group Name Error!
ER 007: Wrong mobile number
SMS limit is up.
Not Enough Space !
ER 010 :: SMS Limit is up
Object not belongs to you. Check the object id Object not supported to change the user level
ER 018 :: Object Not Belongs to you
Object not downloadable!
Type not supported!
ER 020 :: Object not downloadable
5.
Interface Requirements
5.1
User Interfaces
There will be mainly two interfaces, a web interface and a WAP interface. Web interface will provide necessary UIs for different user functionalities such as log in, adding photos, rating photos and etc. User interfaces will be designed in such a way that they can be customized according to the user preferences. Users having administrative privileges will get additional set of UIs for administrative functionalities.
WAP interface will be much constrained than the web interface. WAP interface will be customized to suit different mobile devices.
5.2
Hardware Interfaces
System will consist of mainly two major components, a back-end platform and a front-end application. Customized applications can be built on top of the backend platform to cater different user requirements.
Back-end platform will be deployed in one of the network operator’s servers. Front-end application may also be deployed in the same server or another remote server. Users will be able access the front-end application through web using desktop machines and through WAP using mobiles, PDAs or any other WAP enabled device. Not only that, any mobile device having the STK application capabilities should be able to use the product.
5.3
Software Interfaces
For database connectivity, MySQL 5.x software interface will be used and standard SQL statements will be used when communicating with MySQL.
In the system development some of the utility components developed/used by the network operator will be used.
J2SDK 1.5 native libraries will be used during development.
5.4
Communications Interfaces
These protocols will be used for communication between:
Source Destination Protocol Mobile Application SMS, MMS, IVR
Application Mobile WAP Application Desktop PC HTTP
6.
Other Nonfunctional Requirements
6.1
Performance Requirements
When the load on the backend is at its peak, system should be able to balance its load by utilizing all the resources in an optimal way so that there’s no noticeable delay.
6.2
Safety Requirements
The information uploaded into active (non dormant) user accounts SHOULD not be lost hence periodical archiving SHOULD be carried out.
The information of the deleted profiles SHOULD not be kept in the system.
6.3
Security Requirements
System SHOULD make sure that privacy of the sensitive information is kept throughout and not disclosed to any unwanted party.
System SHOULD only allow users with necessary privileges to alter and manipulate data.
6.4
Software Quality Attributes
The system SHOULD be available even when the load exceeds the upper limitations hence the system SHOULD NOT crash even during the over stressed situations.
The system SHOULD be easy to use to a moderate person who has some experience of using web browsing or WAP browsing.
The system SHOULD have Model – View – Controller architecture so that the presentation layer is not dependant upon the data layer.
7.
Other Requirements
The product SHOULD be culture independent and SHOULD support Sinhala and Tamil languages in the future.
The product MUST agree to any terms or conditions posted by a third party vendor on using their existing products in the applications.
New moblog applications similar to MyDiary MUST be able to developed and deployed on the built framework with out trouble.
System SHOULD be built in such a way that the framework will not have any coupling with the applications built upon it. So that the framework can be used extensively to built new various applications.
Appendix A: Glossary
Abbreviation Description
SRS Software Requirements Specification SMS Short Message Service
SMSC Short Message Service Center MMS Multimedia Messaging Service
MMSC Multimedia Messaging Service Center IVR Interactive Voice Response
GPRS General Packet Radio Service UI User Interface
STK Subscriber Identity Module Tool Kit URL Uniform Resource Locator
ISDN Integrated Services Digital Network
MSISDN Mobile Station International ISDN Number PDA Personal Digital Assistants
WAP Wireless Application Protocol SQL Structured Query Language J2SDK Java 2 Software Development Kit HTTP Hyper Text Transfer Protocol RFC Request For Comments
API Application Programming Interface PC Personal Computer