nipate srs

7/30/2019 Nipate SRS

1/17

[Nipate Limited] SOFTWARE REQUIREMENTS SPECIFICATION[Nipate Bulk Sms System] [1.0] | [6/11/2012]

Bespoke Business Systems 1 Project Name SRS V 1.0

BESPOKE BUSINESS SYSTEMS

software

requirements specification

[Nipate Limited]

[Nipate Bulk Sms System]

VERSION: [1.0] REVISION DATE: [6/11/2012]

Approver Name Title Signature Date

Contents


2/17



1 Introduction

1.1 Purpose of this document

1.2 Intended Audience and reading suggestions

1.3 Scope of this document

1.4 Business Context

1.5 Project Scope

1.6 References

2 Overall Description

2.1 Product Perspective

2.2 Product Features

2.3 User Characteristics

2.4 User Problem Statement

2.5 User Objectives

2.6 Design and Implementation Constraints

2.7 User Documentation

2.8 Assumptions and Dependencies

3 Functional Requirements

3.1 Short, imperative sentence stating highest ranked functional requirement.

3.2 And so forth...

4 Interface Requirements

4.1 User Interfaces

4.2 Hardware Interfaces

4.3 Software Interfaces

4.4 Communications Interfaces

5 Non Functional Requirements

5.1 Performance Requirements

5.2 Safety Requirements


3/17



5.3 Security Requirements

5.4 Software Quality Attributes

5.5 Reliability

5.6 Maintainability

5.7 Portability

5.8 Extensibility

5.9 Reusability

5.10 Application Affinity/Compatibility

5.11 Adaptability,

5.12 Availability,

5.13 Correctness,

5.14 Flexibility,

5.15 Interoperability,

5.16 Maintainability,

5.17 Robustness,

5.18 Testability

5.19 Usability

5.20 Serviceability

6 Preliminary System Design

6.1 Use cases

6.1.1 System Use Cases

6.1.2 Send Copyright

6.2 Sequence Diagrams

6.2.1 Sequence 1

6.2.2 Sequence 2

6.3 Database design

6.3.1 Reviewer Data Entity

7 Operational Scenarios


4/17



8 Project Plan

9 Budget

10 Appendices

10.1 Definitions, Acronyms, Abbreviations

10.2 References

IntroductionPurpose of this document

A software requirements specification document for Nipate Bulk Sms system

1.0. This document describes the requirements of the entire Nipate Bulk Sms System.

Intended Audience and reading suggestions

This document is intended for developers,the project manager and the system testers.The

rest of this document describes the the system,the environment surrounding the system and the

various goals that should be achieved by the system

Scope of this document

Business Context


5/17



Product Features

The product has a client management feature.

The product has send bulk or individual sms features.This can be inform of informative

tips or reminder alerts.

User Characteristics

User Problem Statement

User Objectives

Simple none clustered UI Easy management of clients

Design and Implementation Constraints

User Documentation

We will provide online user help and documention on top of context help and online

support.

Assumptions and Dependencies

Functional RequirementsFunctional requirements describewhatthe system must accomplish. Other kinds of requirements(such as interface requirements, performance requirements, or reliability requirements)describehowthe system accomplishes its functional requirements.


6/17



The following scale is used to rank criticality

Criticality Scale: Very Low (1)

Low (2)

Medium (3)

High (4)

Very High (5)

1. Very Low:Items that can be eliminated should serious system constraints encountered.

2. Low:Items that are extra functionalities that may be evaluated for possible elimination.

3. Medium:Items that are strongly desired by the users of the system.

4. High:Items which are required in the system in order for lower criticalities to function.

5. Very High:Items that are mission critical and that the system cannot function without.

Functionality should be listed in order of criticality.

Each functional requirement should be specified in a format similar to the following:

Short, imperative sentence stating highest ranked functional requirement.

DescriptionA full description of the requirement.

CriticalityDescribes how essential this requirement is to the overall system.

Technical issuesDescribes any design or implementation issues involved in satisfying thisrequirement.

RisksDescribes the circumstances under which this requirement might not able to besatisfied, and what actions can be taken to reduce the probability of this occurrence.

Dependencies with other requirementsDescribes interactions with other requirements.

And so forth...

Example

===============================================================

1. The system shall be able to display the homepage.


7/17



DescriptionAfter being properly coded, the system shall be able to display a GUI of the RU ClubSoccer Website.

Criticality5

Technical issuesPre-condition: website shall be properly coded.Post-condition: the system shall properly display the clubs homepage.

RisksThe system may not properly display the homepage.

Dependencies with other requirementsN/A

===============================================================

1 The system shall enable our customers to login to there accounts

DescriptionOnce the system securty is well developed it must enable the user to login in asecure manner to the system

Criticality5

Technical issuesPre-condition: The system security must be well developPost-condition: The system must enable the user to securely login

RisksThe system must authenticate the users


2 The system shall enable our customers to add and manage their clients.

Description

Once the system coded it must enable our customers to create their clients andmanage them by putting the into groups

Criticality5

Technical issuesPre-condition: The ability to create and manage client clients must be developedPost-condition: The system must enable customers to to create and manage clients

RisksThe system must enable creation and management of clients


3 The system shall enable our customers to login to there accounts

DescriptionOnce the system securty is well developed it must enable the user to login in asecure manner to the system

Criticality5

Technical issuesPre-condition: The system security must be well develop


8/17



Post-condition: The system must enable the user to securely login Risks

The system must authenticate the users Dependencies with other requirements

N/A

Interface RequirementsUser Interfaces

GUI

CLI


9/17



The system will have 4 CLI commands namely

individual_alert-This command will check for in

alerts/remenders scheduled to a given user at the time it

invoked and send them out group_alert-This command is similar to individual_alert

command but instead sends messages to a group of

indiviaduals

individual_tip-This command will check the database

informative messages scheduled for the user at the time it is

ivoked and send them

group_tip-This command is similar to the the individual_tip

but send messages to a group of individuals.

Diagnostics or ROM

We shall obtain logging information from log files genarated by theapplication.

Hardware Interfaces

Software Interfaces

The system will be developed using the Yii Framework version 1.1.12.

The storage will be provided by MYSQL We will use gosms to send out the sms messages

The data to will be going out of the system will mainly be sms messages.This will be sent to

gosms gateway for forwarding.

Communications Interfaces

The system shall be communicating mainly over http.

Non Functional Requirements


10/17



Specifies any other particular non-functional attributes required by the system. Examples areprovided below.

Performance Requirements

Safety Requirements

Security Requirements

Software Quality Attributes

.

Reliability

Maintainability

Portability

Extensibility

Reusability

Application Affinity/Compatibility

Adaptability,

Availability,

Correctness,

Flexibility,


11/17



Interoperability,

Maintainability,

Robustness,

TestabilityUsability

Serviceability

Preliminary System Design

This section presents a list of the fundamental objects that must be modeled within the system tosatisfy its requirements. The purpose is to provide an alternative, "structural" view on the

requirements stated above and how they might be satisfied in the system.

Use cases

System Use Cases

Send Copyright

This use case extends the Update Articleuse case.

Diagram:

Use Case Name Login

Description This use case describes the login process


12/17



XRef

Trigger The user access the application without a valid session

Precondition A login screen is displayed

Step by Stepdescription

The user supplies the username and password for the account

The system validated the user details against the database

If the details are correct the system allow the user access to the system

If the details are incorrect then the system show and error

Alternative Paths

Post condition The the user accesses the system

Exception Paths

Other

Use Case Name New group

Description This use case describes creation of a new group

XRef

Trigger The user selects create from the groups->new menu

Precondition A form for creating a new record is displayed


The user fill the form and hits save

The system validated the user the form

If the form passes validation rules the system saves the group andredirect to the group detail page.


13/17



Alternative Paths If the user chooses to upload a csv then the upload csv form is shownfor bulk upload.

The user selects the file with the groups

The system validate the details in the csv and the save all the groups

Post condition The the user create a group ot mult

Exception Paths

Other

Use Case Name Manage Groups

Description The will be manage their client groups

XRef

Trigger The user selets manage from the groups menu

Precondition A grid with all the users group is displayed


The user can selest to update the details of a group

The user can choose to view the group details

The user can choose to delete the group

Alternative Paths In step 2, If the user chooses to update the group the system willredirect them to them to the update form we they will edit the group and


14/17



hit save for the system to save their details back to the database

In step 2, If the user chooses to view a group the system will redirectthem to the view detail screen

in step 2,i fthe user chooses to delete the group the system asks for

confirmation and if the user is sure it removes the record from thedatabase

Post condition Depending on the choice the user should archive the following

Have details of a group updated

View group details in a clear way

Have a group deleted

Use Case Name Send Instant sms

Description This use case describes the login process

XRef Section 2.2.1, Search Article

SDD, Section 7.1

Trigger The user access the application without a valid session

Precondition A login screen is displayed


The user supplies the username and password for the account


15/17



The system validated the user details against the database

If the details are correct the system allow the user access to thesystem

If the details are incorrect then the system show and error

Alternative Paths In step 2, if the Reader selects to search by category, the systemcreates and presents a list of all categories in the database.

The Reader selects a category.

The system creates and presents a list of all articles in thatcategory in the database. Return to step 5.

In step 2, if the Reader selects to search by keyword, the systempresents a dialog box to enter the keyword or phrase.

The Reader enters a keyword or phrase.

The system searches the Abstracts for all articles with thatkeyword or phrase and creates and presents a list of all sucharticles in the database. Return to step 5.

Post condition The the user accesses the system

Exception Paths The Reader may abandon the search at any time.

Other The categories list is generated from the information provided whenarticle are published and not predefined in the Online Journal database.

Sequence Diagrams

Sequence 1

Sequence 2

Database design


16/17



Reviewer Data Entity

Data Item Type Description Comment

Name Text Name of principle author

ID Integer ID number of HistoricalSociety member

Used as key in HistoricalSociety Database

Email Address Text Internet address

Article Pointer Article entity of May be several

Num Review Integer Review entity Number of not returned reviews

History Text Comments on pastperformance

Specialty Category Area of expertise May be several

Editor Data Entity

Project Plan

Budget

.

Appendices


17/17



Definitions, Acronyms, Abbreviations

References

nipate srs

Documents