• No results found

CME - Mobile Blogging

N/A
N/A
Protected

Academic year: 2021

Share "CME - Mobile Blogging"

Copied!
81
0
0

Loading.... (view fulltext now)

Full text

(1)

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

(2)

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

(3)

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

(4)

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 Application

30-11-2006 To add interface prototypes. Change the name

(5)

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".

(6)

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.

(7)

1.5

References

[RFC2119] “Key words for use in RFCs to Indicate Requirement Levels”,

(8)

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

(9)

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:

(10)

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.

(11)

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.

(12)

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.

(13)

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

(14)

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.

(15)

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

(16)

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.

(17)

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

(18)

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.

(19)

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.

(20)

4.

User Interface prototypes

4.1

Web Interfaces

The following prototypes will show the web interfaces relevant to our functional requirements.

(21)

Forgot Password interface

(22)

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.

(23)

Buddies

Relevant interfaces for the Buddy management are as follows.

(24)
(25)
(26)
(27)
(28)
(29)
(30)
(31)

Invite buddies

(32)

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.

(33)
(34)
(35)
(36)
(37)
(38)
(39)

Inbox

The Sent Items / Trash folders will be look like the same as the Inbox.

From Subject Type Date

BuddyName Message Subject Message Type

(40)
(41)
(42)
(43)
(44)
(45)
(46)

Add an Item

The following interface is corresponding to add a picture, add a video and add a joke.

Download an Item

(47)
(48)
(49)

Searching Interfaces Search people

(50)
(51)

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

(52)

FOGOTP<sp><NE WPASSWORD> Message Sent. Your new password is NUTSY Forgot Password ER 101, ER 003, ER 999

(53)

BLOG<sp> <SUBJECT><sp> <MESSAGE><sp> Message Sent. You have successfully posted to the blog. blog id = XXXXXX

Create a blog post

(54)

msg<sp><blogid ><sp><message > Message Sent. Message Successfully Send

Send a message to another blog

(55)

CAL<sp> <DD::MM::YY> <sp><CONTENT> Message Sent. Event successfully added. Object ID = <OBJECTID>

Add a Calendar Event

(56)

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

(57)

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

(58)

rate<sp><object ID><sp><value> Message Sent. Picture/...was rated successfully Rate a object ER 012, ER013,ER015,ER101.ER102,ER999

(59)

INVI<sp><MOBIL E #>

Message Sent.

Your buddy request is been sent for approvals.

Invite a friend

(60)

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:

(61)

USERLEVEL<sp>O BJECTID<sp>LEV EL

Message Sent. Successfully chan

ed. User level cha nged from <PAST > to <NOW>

Change content access level.

(62)

DEL<sp>OBJECT_ ID Message Sent. Item successfully removed. Remove/Delete content ER018 / ER 012, ER 101 / ER102/ER999

(63)

DOW<sp> <OBJECT ID>

Message Sent.

Successfully download. Save content to the phone ?

Download

(64)

REM<sp> <DD:: MM::YY> <sp><MESSAGE> Message Sent. Item successfully added. Item ID = ITEM_ID Add a reminder ER101/ER102/ER 006

(65)

SEARCH<sp>TYPE

Message Sent. Top list of TYPE

ID NAME - - - - - - - - - - - - - - - - -

(66)

Download instructions.

Registration failed. You haven’t used the correct format

ERROR MESSAGES

(67)

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

(68)

Already a CMe user. Try with forget password option

Operation unsuccessful. Please check the object id and retry.

ER 022 : Already a CMe User

(69)

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

(70)

The object you are trying to rate is not ratable.

You can’t send an invitation to non dialog mobile user.

ER015 – Not ratable

(71)

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

(72)

You can not approve a friend who has not invited you.

Cannot contact the Server

ER 017 – Mobile number has not invited

(73)

Mobile Number Error

Group Name Error!

ER 007: Wrong mobile number

(74)

SMS limit is up.

Not Enough Space !

ER 010 :: SMS Limit is up

(75)

Object not belongs to you. Check the object id Object not supported to change the user level

ER 018 :: Object Not Belongs to you

(76)

Object not downloadable!

Type not supported!

ER 020 :: Object not downloadable

(77)

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.

(78)

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

(79)

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.

(80)

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.

(81)

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

References

Related documents

a secondary object meant to substitute for the original, such as a metadata record used in place of the original physical object or a digital image used in place of a

The minimum overall completion time is 23 weeks, which is the sum of the times on the critical path, as well as the earliest finish time for the last activity.. In other words, we

We model how selection and differential payments—the value of the capitation payments the firm receives to insure an individual minus the counterfactual cost of his coverage

4.2 Three (3) of the strategic intervention at the national level in regards the sustainable stewardship of the Belize Barrier Reef and its associated ecosystems are: the

Among the different goals that have been suggested, there are at least three that are worth considering more closely, namely (1) to improve the average level of health (or the like)

This research study examined the effectiveness of the Sistas Accessing HIV/AIDS Resources At a click (SAHARA) computer-based, behavioral prevention intervention with a population

• CCAR 2011, has been followed with CCAR 2012 and CCAR 2013 – in alignment with the Dodd Frank Act’s requirements for annual capital adequacy assessment and stress

Therefore, gefitinib is an important and valid treatment option for previously treated advanced NSCLC patients a Kris (2009) 100 Response and progression-free survival in 1006