CME - Mobile Blogging

Transcription

1 Software Requirements Specification for CME - Mobile Blogging Framework and Application Version 1.1 Prepared by Team of Group 10 Computer Science & Engineering Department University of Moratuwa

2 Software Requirements Specification for MyDiary Page ii Table of Contents 1. Introduction Purpose Document Conventions Intended Audience and Reading Suggestions Project Scope References Overall Description Product Perspective Product Features User Classes and Characteristics Operating Environment Design and Implementation Constraints User Documentation Assumptions and Dependencies System Features Registration Posting Media and Mediums Personalization Messaging WAP and web Maintaining and Archiving options Administration Animation Security Billing Advanced Features User Interface prototypes Web Interface prototypes SMS Interface prototypes... 47

3 Software Requirements Specification for MyDiary Page 3 5. External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces Other Nonfunctional Requirements Performance Requirements Safety Requirements Security Requirements Software Quality Attributes Other Requirements...76 Appendix A : Glossary...77

4 Software Requirements Specification for MyDiary Page iv Revision History Name Date Reason For Changes Version Software Requirement Specification for MyDiary - Mobile Blogging framework and Application Software Requirement Specification for CME - Mobile Blogging framework and Application Version To add interface prototypes. Version 1.1 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, S. Bradner, March 1997, (

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 - 4 -

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: - 5 -

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 cooperate 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 Description This feature enables end users to register with MyDiary moblog using different mechanisms through their mobile or through web or WAP 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 Description - 9 -

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) Functional Requirements (a) Users MUST be able to post photographs, audio, video and text by MMS, SMS, IVR, web and . (b) Multiple attachments per entry SHOULD be supported. (c) All common media files SHOULD be supported. 3.3 Personalization Description This feature will allow users to personalize moblogs according to their personal preferences 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. (c) User MUST be able to move, copy, remove or edit entries

15 3.4 Messaging Description This illustrates the interactions between the user and the blog and how, when and why the notifications are sent Functional Requirements a) MMS, SMS, 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, 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 Description This feature will provide the presentation interfaces of the moblog

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, messages over WAP/web. 3.6 Maintaining and Archiving Options Description This specifies how users can manage and archive their profiles 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 Description This specifies how to administer the moblog 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 Description The dynamic and popularity measurement features are specified here 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 Description The levels of security users can have in thier blogs and how to maintain access rights are provided with this feature 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 Description Specification of billing mechanisms found here 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 Advanced Features Description Specifies the advanced features of the system 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. Home Page

21 Forgot Password interface When user sign in to CME, it shows his profile

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. My Buddies

24 Top 10 Buddies

25 Buddy Circles Home

26 Buddy Circles Add Buddy

27 Buddy Requests Incoming Requests

28 Buddy Requests Outgoing requests

29 My network of Buddies

30 Profile visitors

31 Invite buddies Should specify the mobile numbers of the buddies in the following interface

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 Send a SMS to a Buddy

34 Send a MMS to a Buddy

35 Send a Message to a Buddy s moblog

36 Send a Message to a Buddy List home

37 Send a SMS to a Buddy List

38 Send a MMS / Message to a Buddy group

39 Inbox From Subject Type Date BuddyName Message Subject Message Type Date The Sent Items / Trash folders will be look like the same as the Inbox

40 Send a massage to selected recipients

41 My Collections My Pictures

42 My Collections My Videoes

43 My Collections My Songs

44 My Collections My Multimedia jokes

45 My Collections My Text Jokes

46 Add an Item The following interface is corresponding to add a picture, add a video and add a joke. Download an Item The following interface is corresponding to download an item

47 My Scheduler Add an event

48 My Scheduler View events

49 Searching Interfaces Search people

50 Search Item

51 4.2 SMS Interface prototypes The following prototypes will show the SMS interfaces relevant to our functional requirements. Registration REGISTER<sp>< USERNAME><sp> <PASSWORD> You have successfully registered to mblog. Username :.. Password Message Sent. ER 002, ER

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

53 Create a blog post BLOG<sp> <SUBJECT><sp> <MESSAGE><sp> You have successfully posted to the blog. blog id = XXXXXX Message Sent. ER 004, ER101, ER102, ER

54 Send a message to another blog msg<sp><blogid ><sp><message > Message Successfully Send Message Sent. ER 007, ER008, ER009, ER101, ER102, ER

55 Add a Calendar Event CAL<sp> <DD::MM::YY> <sp><content> Event successfully added. Object ID = <OBJECTID> Message Sent. ER 005, ER 102, ER 999, ER

56 Send a message to a buddy list SMS <sp> <BUDDY LIST NAME> <sp><message> <sp> Your message has been sent to the buddy list. Message Sent. ER 010, ER

57 Add a comment COM<sp>OBJECTI D<sp>COMMENT Comment Pending to be approved by <NICKNAME> Message Sent. ER 101, ER 102, ER 999, ER 012, ER 013, ER

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

59 Invite a friend INVI<sp><MOBIL E #> Your buddy request is been sent for approvals. Message Sent. ER 101, ER 102, ER 995, ER 007, ER

60 Approve a Buddy. APPROVE<sp>MO BILE# Approval successf ul. Now, you and <NICKNAME> are connected. Message Sent. ER 101, ER 102, ER 999, ER 007, ER 017 Note: The inviter would be notified as. <MOBLIE#>(NICK NAME> has ace pted your buddy r equest. Now you & <NICKNAME> t d

61 Change content access level. USERLEVEL<sp>O BJECTID<sp>LEV EL Successfully chan ed. User level cha nged from <PAST > to <NOW> Message Sent. ER 101, ER 102, ER 999, ER 012, ER 018, ER

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

63 Download DOW<sp> <OBJECT ID> Successfully download. Save content to the phone? Message Sent. ER 012, ER 101, ER 102, ER 999, ER

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

65 Search Item SEARCH<sp>TYPE Top list of TYPE ID NAME Message Sent

66 Download instructions. ERROR MESSAGES ER 002 : Registration Failed Registration failed. You haven t used the correct format

67 ER 999: Wrong number of arguments Operation not successful. Wrong number of arguments. ER101 Not a registered user You are not a registered user. You can t use mblog facilities

68 ER 022 : Already a CMe User Already a CMe user. Try with forget password option ER012 : Wrong object id Operation unsuccessful. Please check the object id and retry

69 ER013: Not enough privileges You don t have permission to add a comment to this user. ER Not commentable The object you are trying to comment is not commentable

70 ER015 Not ratable The object you are trying to rate is not ratable. ER 016 Cross network error You can t send an invitation to non dialog mobile user

71 ER 017 Mobile number has not invited You can not approve a friend who has not invited you. ER 016 Cross network error You can t send an invitation to non dialog mobile user

72 ER 017 Mobile number has not invited You can not approve a friend who has not invited you. ER 102 : Server Down Cannot contact the Server

73 ER 007: Wrong mobile number Mobile Number Error ER 008: Group Name Error Group Name Error!

74 ER 010 :: SMS Limit is up SMS limit is up. ER 899 :: Not Enough Space Not Enough Space!

75 ER 018 :: Object Not Belongs to you Object not belongs to you. Check the object id ER 019 :: Not Supporting to change the user level Object not supported to change the user level

76 ER 020 :: Object not downloadable Object not downloadable! ER 021::Type not supported Type not supported!

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 SRS SMS SMSC MMS MMSC IVR GPRS UI STK URL ISDN MSISDN PDA WAP SQL J2SDK HTTP RFC API PC Description Software Requirements Specification Short Message Service Short Message Service Center Multimedia Messaging Service Multimedia Messaging Service Center Interactive Voice Response General Packet Radio Service User Interface Subscriber Identity Module Tool Kit Uniform Resource Locator Integrated Services Digital Network Mobile Station International ISDN Number Personal Digital Assistants Wireless Application Protocol Structured Query Language Java 2 Software Development Kit Hyper Text Transfer Protocol Request For Comments Application Programming Interface Personal Computer