Ams Srs - Jane

8/6/2019 Ams Srs - Jane

http://slidepdf.com/reader/full/ams-srs-jane 1/48

Copyright © 2011 by Jane Chukwurah. Permission is granted to use, modify, and distribute this

document.

Software Requirements

Specification

For

Abstract Management System

Version 2.0 approved

Prepared by Jane Chukwurah

American University of Nigeria

12/04/2011



Revision History

5HYLVLRQ

1XPEHU

5HYLVLRQ

'DWH

5HYLVLRQ'HVFULSWLRQ 5HYLVLRQ%\

Rev01 12/04/2011 Initial draft/ AMS version 1.0 Chukwurah Jane

Rev02 5/05/2011 AMS version 2.0 Chukwurah Jane

Rev03 Rev04



3 of 48SRS-AMS July 2, 2011June 6, 2011May 7, 2011

7$%/(2)&217(176

Revision History ....................... ................................................................... 2 ([HFXWLYH2YHUYLHZ ............................................................................. 5

1.1 Introduction ....................... .............................................................. 6 1.2 Objectives .......................... .............................................................. 6 1.3 Scope ......................... .....................................................................76 1.4 References ......................... .............................................................76 1.5 Outstanding Issues .......................... ................................................87 1.6 Assumptions ........................... ........................................................87

&XUUHQW(QYLURQPHQW ..........................................................................97 2.1 User Classes and Characteristics ......................... ............................97 2.2 Business Functions .............................................................. .........119 2.2.1 Elaborated Use Cases ......................... .....................................1210 2.3 Component or System Description .............................................2116 2.4 Deficiencies ....................... .........................................................2218 3. System Overview...........................................................................2218 3.1 Goals ..........................................................................................2218 3.2 Input and Output Requirements ..................................................2218 3.3 Functional Requirements ........................... .................................2419 3.4 Performance Requirements ........................ .................................2520 3.5 System and Communications Requirements ........................... ....2721 3.6 Hardware Interface ......................................................... ............2721 3.7 Software Interface.......................................................................2721 3.8 System Security Requirements ...................................................2822

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed



4 of 48SRS-AMS July 2, 2011June 6, 2011May 7, 2011

3.9 Operating Environment...............................................................2923 3.10 System Quality Requirements ........................ .............................3023 3.10.1 Accessibility ........................... .................................................3023 3.10.2 Timeliness ...............................................................................3024 3.10.3 Efficiency ........................ ........................................................3124 3.10.4 Interoperability ........................................................................3124 3.10.5 Capacity ..................................................................................3224 3.10.6 Latency ........................... .........................................................3225 3.10.7 Reusability...............................................................................3225 3.10.8 Robustness...............................................................................3325 3.10.9 Safety ......................................................................................3326 3.11 Usability Characteristics ........................ .....................................3426

7HFKQLFDO5HTXLUHPHQWV .................................................................3426 4.1 Technical Specifications ........................ .....................................3527 4.2 Design and Implementation Constraints ............... ......................3627 4.2 User Documentation ........................... ................................ ........3628

'HILQLWLRQV$FURQ\PV$EEUHYLDWLRQV*ORVVDU\RI7HUPV.........3829 5HVXOWVRI'HOLYHUDEOH5HYLHZ .......................................................3930 Appendix I ......................... .....................................................................4233 Appendix II ........................ .....................................................................4636 Appendix III ...........................................................................................4837

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed



5 of 4862065826.docxRequirements Specification Doc_v1.1 7/2/20116/6/20115/7/2011

([HFXWLYH2YHUYLHZ

The Abstract Management System (AMS) will be a Web-based abstract management system

bringing together individuals¶ abstracts that will then be reviewed. It will take advantage of the

Internet and World Wide Web to radically improve the management of abstracts.

The Submitter objectives for the AMS are to:

y Provide abstracts according to the available themes.

y Enable them to easily submit their abstracts.

y Enable them to view submitted abstracts.

y Enable them to get feedback adequately .

y Minimize risks associated with loosing abstracts.

The R eviewer objectives for the AMS are to:

y Provide them with an easier way to review abstracts.

y Enable them to easily view abstracts.

y Reduces work load.

y Minimize risks associated with loosing abstracts.

The AMS (American University of Nigeria) objectives for the AMS are to:

y Automate the manual process.

y Maximize efficiency.




,QWURGXFWLRQ

This software requirement specification describes functional and non-functional requirements for

release 1.0 of the Abstract Management System (AMS). This document is intended to be used by

the members of the project team of SEN408 (Software process and Project Management) that will

implement and verify the correct functioning of the system. Unless otherwise noted, all

requirements specified here are of high priority and committed for release 2.0. Some of the

purposes of this document include;

y Communication between the Users, System developers, maintainers and so on

y Firm foundation for the design phase

y Support system testing activities

y Support project management and control

y Controlling and monitioring the evolution of the system

2EMHFWLYHV

This software requirement specification document especially addresses the following:

y Functionality: What is the Abstract Management System supposed to do?

y External interfaces: How does the Abstract Management System interact with people, the

system¶s hardware, other hardware, and other software?

y Performance: What is its speed, availability, response time, recovery tim e, etc?

y Attributes: What are the portability, correctness, maintainability, security, etc.

considerations?

y Design constraints imposed on an implementation: Are there any required standards in

effect, implementation language, policies for database integrity, resource limits, operating

environment(s) etc.?




6FRSH

The Abstract Management System manages abstracts that follow specific stated guidelines. These

abstracts are reviewed and managed by the system admin who oversees the work done on the

abstracts.

The system would develop from a file system to an online management which will be used by the

System Admin, Submitters and Reviewers and will be adequately maintained by the system

developers.

The main objective of the proposed system is automating the current manual process by ensuringthe following;

y Make the abstract management process faster

y Efficiency

y Accuracy

y Provides the means of proper tracking.

y Ability to capture the abstracts according the date, user and so on

5HIHUHQFHV

1. Wiggers, Karl. Cafeteria Ordering System,www.processimpact.com

2. Ume, Arthur. Software Requirement Specification Template. Moodle.aun.edu.ng/SEN405

3. Polytechnic Montreal. Time Monitoring Tool, Software Requirement Soecification.




2XWVWDQGLQJ,VVXHV

Below is a list of outstanding issues on the existing system;

$VVXPSWLRQ,' 7H[W

2, The system currently implements the file system management

2, The existing system is highly inefficient

2, The system does not introduce any security measures

$VVXPSWLRQV

Below is a list of assumptions that may derail the project: example«availability of clean data;

stability of the persistency; availability of enough time to deliver system; availability of skilled

programmers to implement system etc«

$VVXPSWLRQ,' 7H[W

$6 There may be the lack of skilled programmers to implement the

system

$6 The system may take a longer time to be functional due to lack of

facilities

$6 Programmers may not have enough time to deliver the system

$6 Requirements inflation may arise while preparing the system

$6 User involvement may cause time delays and increased costs to

the project

$6 Specifications may not be broken down adequately

$6 The technology needed to implement the system may not be




$VVXPSWLRQ,' 7H[W

available

$6 Vague budgets may slow down the preparation of the system

&XUUHQW(QYLURQPHQW

This section consists of four subsections of brief descriptions that provide understanding of the

context for the proposed effort.

8VHU&ODVVHVDQG&KDUDFWHULVWLFV

Submitters: These are the members that send abstracts to be reviewed. They could come from any

part of the world. They submit abstract according to date, discipline and submission. They have the

ability to search the system and print their abstracts

R eviewers: These are individuals that look through submitted abstracts. They are assigned specific

number of abstracts and review and view abstracts discipline date and submission. They score

abstracts on a scale of 1-10; 1-4(reject), 5-10(approve).

System Admin: This is the individual that oversees and controls the processes in the system. The

admin sorts and groups abstracts by date, discipline and group, print by data, discipline and group,

delete abstracts, Communicate with the submitters and reviewers, collect s abstracts and associates

abstracts to date and location.




Figure 2.1 Context Diagram, Abstract Management System




%XVLQHVV)XQFWLRQV

This section shows a high-level picture of the processes and procedures by which information is

currently handled by the owner/ customer in the area being automated or modified.

Figure 2.2 High Level Use Case Diagram




(ODERUDWHG8VH&DVHV

Use Case ID: 1

Use Case: The submitter shall submit abstract

Created By: Chukwurah Last Updated By: Chukwurah

Date Created: April 30, 2011 Date Last Updated: April 30, 2011

Use Case Description:

Actor(s): Submitter

Description: The submitter submits abstract to the Abstract Management system to be

reviewed

Condition(s): 1. The submitter must be a registered member

Special Requirements: 1. The submitter shall enter password

1.2. The submitter shall select theme

Normal Flow: y Submitter opens index page

y Submitter enters user ID and password

y Submitter clicks on the drop down menu and selects theme

y Submitter uploads theme

y Submitter confirms submission

Exception(s): None

Includes: None

Priority: High

Frequency of Use: High

Assumptions: None

Notes and Issues: None

Use Case ID: 2

Use Case: The submitter shall be able to search abstracts

Formatted: Bullets and Numbering





Date Created: April 30, 2011 Date Last Updated: April 30, 2011Use Case Description:

Actor(s): Submitter

Description: The submitter searches abstract in the system


1.2. The submitter must be logged in

Special Requirements: None

Normal Flow: y Submitter enters what to be searched on the search bar

y Submitter clicks ́ searchµ

Exception(s): None

Includes: None

Priority: Medium

Frequency of Use: Medium

Assumptions: None


Use Case ID: 3

Use Case: The submitter shall be able to print abstract




Actor(s): Submitter

Description: The submitter requests to print already uploaded abstract



1.3. Submitter is not authorized to print abstracts other than his/her






own

Special Requirements: NoneNormal Flow: y Submitter right clicks on submitted abstract

y Submitter selects print

y Submitter confirms print.

Exception(s): None

Includes: None

Priority: Medium

Frequency of Use: Medium

Assumptions: None


Use Case ID: 4

Use Case: The submitter shall be able to view only his/her abstract




Actor(s): Submitter

Description: The submitter views submitter abstract



1.3. Submitter is not authorized to view abstracts other than his/her

own


Normal Flow: y Submitter views submitted abstract

y Submitter opens abstract

Exception(s): None





Includes: NonePriority: Medium


Assumptions: None


Use Case ID: 5

Use Case: The reviewer shall be able to view abstracts




Actor(s): Reviewer

Description: Reviewer opens abstracts to be reviewed

Condition(s): 1. Reviewer must be a registered reviewer

1.2. The reviewer must be logged in


Normal Flow: y Reviewer logs in

y Reviewer opens list of submitted abstract

y Reviewer selects abstract

y Reviewer views abstracts

Exception(s): None

Includes: None

Priority: High


Assumptions: NoneNotes and Issues: None





Use Case ID: 6

Use Case: The reviewer shall be able to review abstracts




Actor(s): Reviewer

Description: Reviewer looks through abstract and give it a score(1-10); 1-4 (reject) , 5-10

(approve)

Condition(s): 1. Reviewer must be a registered reviewer

1.2. The reviewer must be logged in


Normal Flow: y Reviewer logs in

y Reviewer opens list of submitted abstract

y Submitter views each abstract gives each one a deserved score

Exception(s): None

Includes: None

Priority: High


Assumptions: None


Use Case ID: 7

Use Case: The system admin shall be able to sort abstracts








Actor(s): System Admin

Description: System admin manually sorts abstracts when necessary

Condition(s): 1. System admin must be logged in

1.2. System admin must only sort abstracts when necessary

Special Requirements: 1. System shall be able to sort abstracts according to date of

submission, group and discipline.

1.2. If an error occurs, system admin shall be able to manually sort

abstracts

Normal Flow: y System admin views abstracts according to date of submission,

group and discipline.

y If any abstract is out of place, system admin arranges abstracts

Exception(s): None

Includes: None

Priority: Low

Frequency of Use: Low

Assumptions: None


Use Case ID: 8

Use Case: The system admin shall be able to delete abstracts










Description: System admin manually deletes abstracts if they have been rejected for any

reason


1.2. Abstracts must be on the status ́ rejectedµ before they can be

deleted

Special Requirements: 1. If reviewed abstracts are between the scores (1-4), system shall give

abstract status ́ rejectedµ

Normal Flow: y System admin views abstracts according to date of submission,

group and discipline.

y System admin deletes abstracts with the status ́ rejectedµ

Exception(s): None

Includes: None

Priority: High


Assumptions: None


Use Case ID: 9

Use Case: The system admin shall be able to communicate to submitters if there is an

extension on deadline









Description: System admin sends a system message indicating extension on deadline for

abstract submissionCondition(s): 1. System admin must be logged in


Normal Flow: y System admin opens message box

y System admin types in extension message

y System admin clicks enter

Exception(s): None

Includes: None

Priority: Low


Assumptions: None


Use Case ID: 10

Use Case: The system admin shall be able to group abstracts according to date of

submission, group or discipline





Description: System admin puts abstracts in their appropriate groups when necessary


1.2. System admin must only group abstract when a problem occurs

with system grouping.






Normal Flow: y System admin opens list submitted abstracts

y System admin views groups

y System admin locates abstracts that are out of place

y System admin groups located abstracts

Exception(s): None

Includes: None

Priority: Low


Assumptions: None


NOTE: The system admin manually performs system functions when necessary.




&RPSRQHQWRU6\VWHP'HVFULSWLRQ

The Abstract Management System as the name implies concentrates on the management of

Abstracts submitted by individuals. Abstracts are captured according date, discipline and group

3URFHVV6WHS $FWLRQ

6WHS Submitter registers as a member

6WHS Submitter enters unique ID and password

6WHS Submitter selects a theme of submission

6WHS Submitter submits abstract

6WHS System changes status of abstract to ³accepted´

6WHS Reviewer enters password

6WHS Reviewer views abstracts according to date, discipline and group

6WHS Reviewer reviews abstracts

6WHS Reviewer scores abstracts (1 -10)

6WHS System updates status of abstract to ³Rejected´ or ³Approved´ and

³Reviewed´

6WHS System sends feedback to submitter

6WHS System updates status of abstract to ³Communicated´

6WHS Submitter logs in

6WHS Submitter views reviewed abstract




'HILFLHQFLHV

The current Abstract Management system makes use of the file system. Papers (Abstracts) are sent

to the reviewers and they are carefully reviewed afterwards they are brought to the conference and

showcased. This system poses a lot of difficulty due to the amount of abstracts sent. The

inefficiency of the system results in certain uncontrollable situations such as missing abstracts,

abstract submitted after deadlines, inconsistency in review methods and many others. This brought

about the need to create a more efficient system that will manage abstracts properly and regulate

the running of the entire procedures and stages involved in the Abstract Management System.

6\VWHP2YHUYLHZ

This section takes a look at the overall system activities.

*RDOV

The SRS provides a clear list of the expectations of a new system or function(s), both in terms of

what must be improved and that must be retained from the current processes. All detailedrequirements stated below addresses one or more of these goals.

y Automating the current manual process

y Provision of an environment that makes work faster

y Ensuring Efficiency

y Proper Tracking

y Proper Storage

,QSXWDQG2XWSXW5HTXLUHPHQWVThese set of requirements provide a description of all manual and automated input requirements

for the software product such as data entry from source documents and data extracts from other




applications, as well as all output requirements for the software produ ct such as printed forms,

reports, display screens, files and other deliverables the system will process and produce.

5HTXLUHPHQW,' 5HTXLUHPHQW7H[W

,2 The system shall display screen that prompts user for password

,2 The submitter shall enter the password derived after registration process

,2 If the submitter does not have a password, the submitter shall begin the

registration process by entering required personal information.

,2 The submitter shall submit abstract by first selecting a theme from a drop

down menu,2 After submission, the submitter may choose to view submitted abstract

,2 The submitter may request abstract be printed

,2 The system shall print selected abstract requested by the submitter

,2 The reviewer shall enter the password provided by the university

,2 If the reviewer does not have a password, the reviewer shall be display

screen prompting user to contact university

,2 The reviewer shall be able to view list of submitted abstracts according to

date of submission and discipline

,2 The reviewer shall be able to enter scores of abstracts on a scale of 1 -10

,2 The system admin shall be able to print abstracts according to date of

submission, discipline and group

,2 The system admin shall be able to delete rejected abstracts

,2 The system admin shall be able to send e -mails to submitters in situations

of an extension on submission deadline

,2 The system admin shall be able to sort abstracts by date of submission,

discipline and group if necessary

,2 The system admin shall be able to group abstracts by date of submission ,

discipline and group if necessary




)XQFWLRQDO5HTXLUHPHQWVThis section shows at a detailed level, computer system requirements within the context of the

processes they must support. A process model supports this, which may be included.


) The system shall let the submitter who is logged on to the Abstract

Management System submit one or more abstracts

) The system shall confirm that the submitter is registered as a member

to submit abstract

) If the submitter is not registered, the system shall give the submitter

options to register now or to exit from the Abstract Management

System

) If the submitter is registered, the system shall provide access to the

submitter for abstract submission

) The submitter shall specify what theme the abstract belongs under

) If the submitter does not specify a theme, the system shall prompt the

user to select a theme

) When the submitter has confirmed submission, the system shall do the

following as a single transaction:

) Store the abstract with and initial status of ³ Received´

) Send a message to the selected reviewer prompting him/her of a new

submission

) Update the current reviewers list with new submission

) If the submission fails, the system shall roll back the process and notify

the submitter that the submission was unsuccessful , along with the

reason for failure

) If submission fails, the system shall store the abstract with status of ³

Rejected´

) The system shall permit the submitter to view submitted abstract

within the period of five months [ Priority = Medium]





) The system shall let the reviewer who is logged on to the Abstract

Management System review one or more abstracts

) The system shall confirm that the reviewer is registered as a reviewer

to review abstracts

) If the reviewer is not registered, the system shall prompt the reviewer

to contact the university or to exit from the Abstract Management

System

) The system shall display abstracts to be reviewed to the reviewer

) The system shall display available scores for abstract

) If the reviewed abstract is between scores 1 -14, the system shall store

the abstract with the status of ³Rejected´

) If the reviewed abstract is between scores 5 -10, the system shall store

the abstract with the status of ³Approved´

) After abstracts have been reviewed, the system shall do the following

as a single transaction:

) Store the reviewed abstract with the status of ³ Reviewed´

) Send an e-mail message to the submitter informing of the reviewed

abstract

) After the e-mail has been sent, the system shall store the abstract with

the status ³ Communicated´

3HUIRUPDQFH5HTXLUHPHQWV

This set if requirements Portrays owner/customer defined performance requirements standards

relating to system response time, maintainability and so on


3 The system shall accommodate 300 users during the peak usage time

window of 8:00am to 10:am local time, with an estimated average





session duration of 10 minutes

3 The maximum response time for the submission of an abstract shall

be 1 minute.

3 The system shall send feedback to submitter after abstract has been

reviewed within 1 minute

3 The system shall update status of abstract within 8 seconds of action

3 Assuming submitted statistics for abstracts are accurate, the AMS

shall ensure that all abstracts are allowed a 2% error allowance.

3 Upload time of abstracts must not exceed 1minute

3 Under all circumstances, the maximum cost payable as submitted by

the submitter will be the maximum cost charged to the submitter.

3 All Web pages generated by the system shall be fully downloadable

in no more that 10 seconds over a 40KBps modem connection

3 Responses to queries shall take no longer that 8 seconds to load onto

the screen after the user submits the query

3 The inquiry response database may not contain more than 1% of

incorrect, inaccessible, or inappropriate lines of information.

3 The system shall display confirmation messages to users within 4

seconds after the user submits information to the system

3 The AMS shall provide timely resolution for all problems identified

during submission

3 The AMS shall provide timely resolution for all problems identified

during review

3 A minimum of 90% of the surveyed submitter base must be satisfied

with the overall level of service provided





programmatic interface

6 , The AMS shall communicate with the Payment system through a

programmatic system

6 , The AMS shall accept band teller number as confirmation of

payments

6 , The AMS shall check whether bank teller number is valid

6\VWHP6HFXULW\5HTXLUHPHQWV

.


66 All network transactions that involve financial information or personal

identifiable information shall be encrypted

66 A minimum of 99.999% of the time , the system shall identify submitter

before permitting him/her to perform use cases

66 A minimum of 99.999% of the time ,the system shall identify reviewer

before permitting him/her to perform use cases

66 A minimum of 99.999% of the time ,the system shall identify system

admin before permitting him/her to perform use cases

66 A minimum of 99.999% of the time , the system shall verify the identity

of submitter before permitting him/her to perform use cases


of reviewer before permitting him/her to perform use cases


of system admin before permitting him/her to perform use cases

66 The AMS shall scan all entered or downloaded data against the published

definition of known computer viruses, worms, Trojan horses, and other





similar harmful programs

66 If possible , the AMS shall disinfect any data or software found to

contain such harmful program

66 The AMS shall delete the infected file if it cannot disinfect the data or

software

66 The system shall notify a member of the security team if it detects a

harmful program during a scan.

66 The system shall protect a minimum of 99.999% of its persistent data

from unauthorized intentional corruption

66 The system shall ensure that authorized modifications during

maintenance will not inadvertently allow unauthorized users access the

system

66 Users shall be required to log in to the Abstract Management System for

all operations except viewing the home page

66 The system shall permit only the system admin to delete Abstracts

66 The system shall permit only the system admin to sort abstracts

66 The system shall permit only reviewers who are on the list of authorized

Reviewers to review abstracts

66 The system shall permit only submitters to view only their own

previously submitted abstracts , not abstracts submitted by other

submitters

66 Abstracts shall be confidential until they have been reviewed

66 The system shall be based on membership

66 The system shall be password protected

2SHUDWLQJ(QYLURQPHQW

OE-1 The AMS shall be accessible through a web-browser or a Windows compatible




client.

OE-2

The AMS shall operate with the following Web Browsers: Microsoft InternetExplorer, Google Chrome, Mozilla Firefox

OE-3 The AMS shall operate on a relational database

OE-4 The AMS shall be password protected and based on membership

OE-5 The AMS shall be accessible with screen-reading software, screen

magnification software, and other software programs designed to increase

accessibility.

6\VWHP4XDOLW\5HTXLUHPHQWV

$FFHVVLELOLW\

This subsection specifies the following requirements associated with the degree to which the

system must be accessible to people with disabilities:


$& Any graphical user interfaces of the AMS shall be usable by persons with

color blindness.

$& Any graphical user interfaces of the AMS shall use an adequate font size

for to be usable by users with limited visual acuity

7LPHOLQHVV


system must be accessible to people with disabilities:





TI-01 The system shall automatically transfer ³old´ information from on -line

storage to off-line archives after TBD days.

7 , The system shall permanently delete1

³obsolete´ information from all

storage after TBD days.

7 , The AMS shall not return requested information to an external that is

more than one second obsolete.

(IILFLHQF\


system effectively uses its resources:


EFF-01

The GPM shall not require users to permanently download software to

their computers.

,QWHURSHUDELOLW\

This subsection specifies the following usability requirements associated with the ease with which

the system can be installed.


INT-01

The system shall interoperate with the following browsers, Mozilla

Firefox, Google chrome, Internet Explorer





RU-1

The system shall reuse common classes such as name, address, phone

number etc

58 The AMS shall incorporate a database continuous availability layer.

58 The GPM shall reuse software for sending emails.

5REXVWQHVV


system continues to properly function under abnormal circumstances.


RO-1

The system should gracefully handle invalid input.

5 2 The system should gracefully handle hardware failures

6DIHW\


system does not directly or indirectly (e.g., via inactivity) cause accidental harm to life or property

(e.g., loss of money or data).


SF-1

The system shall not accidentally loose submitter¶s account




7HFKQLFDO6SHFLILFDWLRQV

This section documents the technical approach that translates customer requirements into specific

requirements that can be used by programmers/analysts to create the system design .


76 Submitter must submit abstracts in two formats : MS word and PDF

7 6 Submitters are not required to send in both formats

7 6 All submitted abstracts must be virus free

7 6 Zip files shall not be accepted

7 6 Each registered submitter shall be entitled to 32MB storage

7 6 Each registered reviewer is entitled to 256MB of storage

7 6 The system shall be compatible with 32- or 64- bit versions of Windows

7 6 The System shall be compatible with Microsoft Windows Vista, XP, 7,

Server 2008 or 2003, Mac OS

7 6 The system shall connect to all AMS data sources including relational

databases, and desktop files

7 6 The system shall support viewing

7 6 The system shall support filtering

7 6 The system shall support sorting

7 6 The system shall support printing

7 6 The system shall be a complete solution, no other pre-requisite software

will be required

7 6 The system shall support access from Microsoft Internet Explorer 7&8,

Mozilla Firefox 3.x and higher, Google Chrome and Apple Safari 3.x

7 6 The system shall have 2GB minimum system memory




'HVLJQDQG,PSOHPHQWDWLRQ&RQVWUDLQWV

This section documents any design constraints that should be taken into consideration during thesystem design phase.


'& The system shall use a fully relational database back-end.

'& The system shall produce standards-compliant HTML.

'& All HTML code shall conform to the HTML 4.0 standard

'& The system shall provide a development and training environment

with the ability to migrate configurations to a production environment

'& User rights and privileges will be controlled through security groups

and/or ³roles´ that allow access control for individuals, workgroups,

and arbitrary staff groups.

'& These requirements shall not constrain functionality.

8VHU'RFXPHQWDWLRQ


8' The system shall provide an online hierarchical and cross -linked help

system in HTML that describes and illustrates all system functions

8 ' The first time a new submitter accesses the system and on user demand

thereafter the system shall provide an online tutorial to allow users

practice sending abstracts using a static tutorial menu

8 ' The software developer shall provide complete data specifications for

authority records, bibliographic records, and other records maintained or

accessed by AMS.

8 ' The software developer shall provide a thorough high -level description

of major processes in the AMS




'HILQLWLRQV$FURQ\PV$EEUHYLDWLRQV*ORVVDU\RI7HUPV

$FURQ\P$EEUHYLDWLRQ 'HVFULSWLRQ

SRS Software Requirements Specification

SEN Software Engineering

AMS Abstract Management System

TBD To be decided




0,1255(9,6,2165(48,5('35,2572$33529$/

0LQRU5HYLVLRQV

'(/,9(5$%/(1(('66,*1,),&$175(9,6,21$1'72%(5(68%0,77('

0DMRU5HYLVLRQV

6FRUH

Formatted: Left



July 2, 2011June 6, 2011May 7, 2011

Appendix I

DATA DICTIONARY AND DATA MODEL

Submission Instruction = submitter name

+ submitter phone number

+ submission date

+ submission time window

Submission time window = * 10-minute range during which an abstract is to be

Submitted*

Submitter1D = unique ID of submitter; between 6-10 character numeric

String*

Submitter password = characters chosen by the submitter; 6 -8 character numeric

String*

Reviewer ID = unique ID of reviewer; between 6 -10 character numeric

String*

Reviewer password = characters given to reviewer by AUN; 6-8 character

Numeric String*

Submission date = * the date abstract was submitted; format MM/DD/YYYY

; default = current date if the current time is before the subm -

cut off time, else next day ; may not be prio r to current date*

Abstract submission = abstract number

+ submission date

+ abstract status



July 2, 2011June 6, 2011May 7, 2011

Abstract number = * a unique , sequential integer that the system assigns to

each accepted abstract*

Abstract status = [Approved| Rejected| Received| Communicated|

Reviewed] * see state transition in Appendix II

Registration payment = payment amount

+ payment method

Abstract = abstract name

+abstract theme

Abstract name = * the name given to the abstract by the submitter*

Abstract theme =* theme in which abstract is centered upon*

Submission cut off time =* time of day before which all submissions for that date

must be placed

Submitter = submitter name

+ submitter ID

+ submitter phone number

+submitter location

+submitter e-mail

Submitter e-mail =* e-mail address of submitter who submits an abstracts; 50

character alphanumeric*

Submitter location =* city and state where the submitter is located; 50character alphanumeric*

Submitter phone number =* telephone number of submitter; format AAA -EEE-XXXX



July 2, 2011June 6, 2011May 7, 2011

Submitter name =* name of submitter; 30 character alphanumeric

Reviewer = reviewer name

+ reviewer ID

+ reviewer phone number

+ reviewer location

+ reviewer e-mail

Reviewer e-mail =* e-mail address of reviewer who reviews abstracts; 50


Reviewer location =* city and state where the reviewer is located; 50


Reviewer phone number =* telephone number of reviewer; format AAA -EEE-XXXX

Reviewer name =* name of reviewer; 30 character alphanumeric

Payment amount =* total price for registration; Naira *

Payment method = [Bank]

Submission extension =* extension of initial deadline*

Review = reviewer name

+ submitter name+ abstract name

+abstract number

+ abstract score



July 2, 2011June 6, 2011May 7, 2011

+abstract status

Abstract score = *numeric digits given to abstracts ; [1 -4 (rejected), 5-10

(approved)*

Delete Abstract = abstract name

+ abstract number

+ abstract score

+abstract status

View Abstract = abstract name

+ abstract number

Print Abstract = abstract name

+ abstract number

Feedback =* messages sent to submitters after submission and review*



July 2, 2011June 6, 2011May 7, 2011

Figure 3. Partial data model of version 1.0 of the Abstract Management System



July 2, 2011June 6, 2011May 7, 2011

Appendix II

ANALYSIS MODEL

)LJXUH6WDWHWUDQVLWLRQGLDJUDPIRUDEVWUDFWVWDWXV



Appendix III

PROCESS MAP

Figure 5. Process Map for Abstract Management System

Ams Srs - Jane

Documents

Transcript of Ams Srs - Jane