SMS

(Software Management System)

Software Requirement Specifications Document
 Table of Contents

Table of Contents.............................................................................................................................2

Table of Figures...............................................................................................................................4

Table of Tables................................................................................................................................5

Revision History..............................................................................................................................6

1. Introduction..............................................................................................................................7

1.1 Purpose..............................................................................................................................7

1.2 Scope.................................................................................................................................8

1.3 Definitions, acronyms, and abbreviations.........................................................................8

1.4 References.......................................................................................................................10

1.5 Overview.........................................................................................................................10

2 Overall Description................................................................................................................12

2.1 Product Perspective.........................................................................................................12

2.2 Product Functions...........................................................................................................15

2.3 User Characteristics........................................................................................................16

2.4 Constraints......................................................................................................................16

2.5 Assumptions and Dependencies......................................................................................17

3 Specific Requirements...........................................................................................................18

3.1 External Interface requirements......................................................................................18

3.2 Functions.........................................................................................................................20

3.3 Performance requirements..............................................................................................40

3.4 Logical database requirements........................................................................................41

3.5 Design constraints...........................................................................................................41

 3.6 Software system attributes or other requirements...........................................................41

Appendixes....................................................................................................................................47

Appendix A: Data Flow Diagrams............................................................................................47

Appendix B: Data Dictionary....................................................................................................51

 Table of Figures

Figure 1 SMS Use Cases...............................................................................................................21

Figure 2 Context Level Diagram...................................................................................................47

Figure 3 1st Level DFD.................................................................................................................48

Figure 4 2nd Level DFD: 8th Process...........................................................................................49

Figure 5 2nd Level DFD: 7th Process...........................................................................................50

 Table of Tables

Table1. Login Page........................................................................................................................39

Table 2. SMS Main Menu.............................................................................................................39

Table 3. Form to add new software...............................................................................................40

Table 4. Data Dictionary................................................................................................................59

1 Revision History

Description Version # Date Author

Draft Document 1.0 3/2/2007 Jolanta Soltis
Second Draft 1.1 3/13/2007 Jolanta Soltis
Revision 1.2 3/18/2007 Ali Avni Cirik
Revision 1.3 3/19/2007 John Krane
Revision 1.3 3/19/2007 Rich Schuler
2 Introduction

2.1 Purpose

The Software Management System (SMS) serves as a management effective tool for

software management across university to better manage and track how software is

used. The pilot program for SMS would be developed and implemented at NJIT;

however the system could be adapted to any other university. The purpose of this

document is to define the requirements gathering process used to elicit requirements

from the product stakeholders, to list the enterprise, system functional and non-

functional requirements that are essential to the success of this product, and describe

the issues and improved understanding in the process.

Currently, there is no visibility of software usage across the university because there is

no single repository that lists which software is in use or ready for purchase. NJIT also

lacks a unified method of notifying individuals, departments, and research projects

about what software is currently available. They also lack a unified method of

requesting the purchasing of new software.

These issues lead to wasted resources as disparate groups attempt to acquire software

on their own when it may be possible to aggregate software purchases and realize bulk

savings. In addition, there is no accurate count of the current software licenses in use

which may lead to having too many or too few licenses.

In order to solve these problems NJIT needs a software management tool that allows

effective management of all software purchases, requests, installations, maintenances

and availabilities. This system will not replace any current system since no such system

is in use.

The intended audience for the SMS system includes representatives from NJIT. The

systems will be usable by non-experts: students, faculty and staff, and customizable to

professionals NJIT’s IT administrators.

2.2 Scope

The product we will design is called Software Management System. The system is a

web-based utility used to manage all the software available to NJIT employees and

students. Users will benefit from this system by being able to communicate with IT

Administrators and request software, keys, and licensees. In addition users will be able

to request help for specific software problems, receive notification of software updates,

and request new software purchases. IT Administrators will benefit from the system by

having central location for all software information. New software will be added to the

database and stored there. IT Administrators will be able to run reports and display

statistics about the software usage. The software will run scripts that simplify IT

administrators work: adding keys to the software database, removing users from the

database and requesting new keys from software vendors’ website. The goal of the

system is to create central point where all software is listed, managed, and requested.

2.3 Definitions, acronyms, and abbreviations

2.3.1 SMS: Software Management System.

 2.3.2 Non-Functional requirements: requirements which specify criteria

that can be used to judge the operation of a system, rather than specific

behaviors.

2.3.3 Functional requirements: define the internal workings of the

software: that is, the calculations, technical details, data manipulation and

processing and other specific functionality that show how the use cases are

to be satisfied.

2.3.4 Use Cases: use case is a technique for capturing functional

requirements of systems and systems-of-systems.

2.3.5 PHP: PHP (Hypertext Preprocessor) is a programming language designed

for producing dynamic Web pages.

2.3.6 MySQL: An open source database server geared towards web based
applications.

2.3.7 DD: Data Dictionary

2.3.8 DFD: Data Flow Diagram

2.3.9 NJIT: New Jersey Institute of Technology

2.3.10 LDAP: Lightweight Directory Access Protocol

2.3.11 SSL: Secure Sockets Layer

2.3.12 UCID: University Computing ID

2.4 References

IEEE (1998). IEEE Recommended Practice for Software Requirements Specifications

(1998). Retrieved March 19, 2007, from the World Wide Web:

http://ieeexplore.ieee.org/iel4/5841/15571/00720574.pdf?

tp=&isnumber=15571&arnumber

“SottRack” (2005). Enterprise Software Audit and Control Platform. Audit, Inventory,

Metering, License Compliance. Retrieved March 19, 2007, from the World Wide

Web: http://www.softwaremetering.com

Sommerville, I. (2004). Software Engineering. Boston, MS: Addison Wesley

2.5 Overview

This document is intended for providing an abstract overview of the Software

Management System and a general overview of the entire project. The rest of the

document will provide detail instruction about: the Functional and Non-Functional

Requirements, Stake Holders, Team Architecture, System Functional and Non-

Functional Requirements. The software requirements specification is divided into three

sections: this introduction, the general description of the project, and the specific

requirements of the project. The general description is an overview of the project’s

requirements, including a product perspective, functional and data requirements,

constraints, assumptions, dependencies, and guidelines. The specific requirements

section is a more detailed look at the project’s requirements, including external interface

requirements, performance requirements, quality attributes, and a detailed look at

functional requirements.

SMS is divided into three sections: software information, availability and vendor

information. IT Administrator can access all sections. He or she can add software,

change software information, add keys to the database and request reports. He/she is

notified by the system about license expiration for particular software. Faculty and staff

can only request software installation or license for requested software. Students can

request software key.

3 Overall Description

The Software Management System design for New Jersey Institute of Technology will

monitor usage of variety of software, availability of licenses for particular software and it

will generate reports which will allow NJIT IT Administrators to see the software

download statistics and better manage software purchases. As a brand new product in

the field, the system should work well in collaboration with existing web platforms to

provide convenience for users at various levels within the institution or organization. The

SMS system will use the existing NJIT LDAP system to authenticate the users of the

application.

3.1 Product Perspective

The Software Management System is an independent product that can exist without

authentication, but for the implementation at NJIT it will use LDAP for authentication.

The SMS should work well in collaboration with existing web platforms to provide

convenience for users at various levels within the institution or organization. The SMS is

using existing LDAP system to authenticate. The application is by developed by using

PHP and HTML language. The application will be accessible via the Internet. Web

browsers that can be used include Internet Explorer and Netscape Navigator.
 2.1.1 System interfaces

The web interface is the main system interface, used for listing software and adding

new software to the database as well as new product keys. These functions are

independent of each other yet share the same database. The only system interface that

will alter the database will be the script that adds new software. The primary interfaces

to the database will be read-only.

2.1.2 User interfaces

There are three primary interfaces which will be implemented. The first one is the login

screen, which will ask for the user name and the password. The second one is the main

splash menu, which will have several options to choose from (view software list, add

software, generate reports, adds keys to the database, etc). The third one is an

administration form used to add new software to the database and other administration

functions.

2.1.3 Software interfaces

The software interfaces will be contingent upon MySQL server and PHP as well as the

web server the system will be implemented on.

The interfaces will have requirements of:

2.1.3.1 Operating Systems: Any distribution of Linux (kernel v2.2 or higher;

www.linux.org) or Microsoft Windows (XP, 2003; www.microsoft.com). The operating

system is used to interface the SMS with the underlying hardware.

2.1.3.2 Web Server: Apache (v1.3.x or later; www.apache.org). The Web Server

is used to serve SMS web pages to a user’s Web Browser.

2.1.3.3 Database: MySQL (v3.2.x or higher; www.mysql.com).

2.1.3.4 Programming Languages: PHP (v2.2.x or higher; www.php.net). XHTML

(v4.x; www.w3c.org). These are the languages that SMS is built with.

2.1.3.5 Web Browser: Firefox (www.getfirefox.com) or Microsoft Internet Explorer

(v6 or later; www.microsoft.com). The web browser is used to connect to the SMS over

a local network or the Internet.

2.1.4 Communications interfaces

The system will use the standard TCP/IP protocol for communications between

interfaces.
3.2 Product Functions

3.2.1 The SMS system shall have a browser-based user interface

allowing authorized users to log in and manage software.

3.2.2 The system shall be accessible to student, faculty and staff.

3.2.3 The system shall expose functionality to the users as per their

defined access levels.

3.2.4 The system shall provide unrestricted access to IT Administrators.

3.2.5 The system shall allow users to request software key, license

information and be way of communication with IT Administrators.

3.2.6 The system shall allow configuration and generation of detailed

reports based on an IT Administrator’s query.

3.2.7 The system shall provide an option to send e-mail alerts that are

triggered based on specified conditions set by IT Administrators.

3.2.8 The system shall allow IT Administrators to define access privileges

that define the level of data detail available for view by different user

groups.

3.2.1 The system shall integrate with the existing NJIT LDAP
authentication scheme so users may use their current UCID to login.
 3.3 User Characteristics

All active users with a valid UCID will have access to the SMS system (unless the UCID

is of a restricted type). The intended users of the system will be students, staff, faculty,

and IT Administrators. The functionality allowed to a user will be limited by the

accessibility entitlements defined for that user.

3.4 Constraints

3.4.1 The product is a web-based application, so a most recent

internet browser is needed (Internet Explorer 6/7, Firefox 2.0, Safari,

Opera 8+).

3.4.2 Hardware limitations: Server hardware is unspecified as long as it meets

the software requirements (PHP and MySQL)

3.4.3 Safety and security considerations: only NJIT students and employees

should be able to access the system.

3.4.4 Interfaces to other applications: TCP/IP interface to MySQL,

port 3306.

3.4.5 Audit functions: Apache and internal log auditing.

3.4.6 Safety and security considerations: SSL encryption for UCID/password

exchange.
3.5 Assumptions and Dependencies

3.5.1 The system will depend on NJIT LDAP for user authentication.

Sufficient access to NJIT LDAP system is assumed.

3.5.2 The users will have basic knowledge of web browser use.

3.5.3 SMS requires MySQL.

3.5.1 Criticality of the application: Application is not mission critical to NJIT.

4 Specific Requirements

4.1 External Interface requirements

4.1.1 User Interface: The SMS shall be a web-enabled application

compatible with all major web browsers like Internet Explorer, Netscape

Navigator, Mozilla FireFox, etc.

4.1.2 Hardware Interface: The target audience of this product shall be

using an Apple, Windows PC or a computer running Linux with X windows.

There is no special hardware that is required. The web browser will be the

interface between the hardware and software.

4.1.3 Software Interfaces: The SMS system shall interface with the NJIT LDAP

for user authentication. It requires PHP and MySQL.

4.1.4 User Authentication: The system shall require all users to login before

using the system: LDAP

4.1.4.1 Internal

users, i.e. users that are already logged onto the main computer

network, will not be required to login again. However, if the same user

tries to access the system from an external network, SMS shall require

the user to login.

4.1.4.2 The

external user (user not on the main intranet) shall need to use their

main computer systems login id and password to login to the SMS.

4.1.4.3 The user

id and password authentication shall be done with the help of the main

computer system.

4.1.5 The system shall support two categories (general user and IT

administrator) and three different types of general users (students, faculty

and staff) with a capability to add new user types. The user types are

characterized by the functionality available to that group. These types are

defined below along with the functionalities available to them.

4.1.6 General user shall have access to minimum features and generic

data of the system.

4.1.6.1 The

general user shall request software key or license information.

4.1.7 Administrative Users are member of the group responsible for the

configuration and maintenance of the SMS. These users shall have access

to all the features specified for all the above-mentioned user groups and

additional features as described below.

 4.1.7.1 Administr

ative Users shall add or delete other users and assign them to a

specific user group.

4.1.7.2 Administr

ative Users shall create new user groups and allow them a new set of

access privileges from a combination of the functionalities that exist for

the system.

3.1.8 Reliability requirements: Shall provide “three nines” uptime (99.9%) or

better.

4.2 Functions

4.2.1 Validity checks on the inputs: java script shall have functions that make sure

all is formatted properly and all required fields are field in.

4.2.2 Server-side or client-side functions shall be used for data and form-field

validation.

4.2.3 All abnormal halts shall exit cleanly with no data commit.
Use Case Diagram

SMS Use Cases

Key Request

Request Report

User *
*
*

Log in
*
*
*

* LDAP

Request Report

* Add Keys

It is not decomposed. (Prof. Kirova Ok)

* Update Software
*
IT Admin * *
* * *

Add Software
*

*
Remove Software

Figure 1 SMS Use Cases

Use Case 1: Update software (Admin updates system with software information)

Characteristic Information:

Goal in Context: Allow an Admin to update the system with information about a

piece of software, it's availability, versions, license information, updates, and

patches.

Scope: Primary task.

Primary Actor: Admin

Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

Preconditions: Admin is already logged in and authorized to make changes to the

system.

Success End Condition: Changes are saved to the database.

 Failed End Condition: Admin is notified that his changes were not saved and if

possible given a reason why not.

Sunny Day Scenario:

1. User is displayed a list of available software titles to modify.

2. System checks for the existence of the software title and if found displays it and

its information.

3. User modifies the information about the software.

4. System saves the modifications and notifies Admin that changes were saved.

Extensions:

1. Database is unavailable

a. System is unable to access the database or other data retrieval failure.

i. Admin is notified that system is unavailable.

2. Software the Admin is looking for is not in the database

a. Software list does not contain a software record.

i. Admin needs to add new software record.

3. Data cannot be saved

a. System is unable to access the database or other data save failure.

i. Admin is notified that system is unavailable.

 Variations: None

Priority: Medium

Performance Target: 3 seconds for data to be saved and Admin to be notified.

Frequency: Average 1 Admin login per day

Use Case 2: Request reports (Admin requests reports from the system) ¶

Characteristic Information

Characteristic Information:

Goal in Context: Allow Admin to view reports about data contained in the system.

Scope: Primary task.

Primary Actor: Admin

Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

 Preconditions: Admin is already logged in and authorized to make changes to the

system.

Success End Condition: Admin is able to view the report.

Failed End Condition: Admin is notified that the report is unavailable.

Sunny Day Scenario:

1. Admin is presented with a list of report types that are available.

2. Admin selects a report they wish to see.

3. System fetches the required information from the database and formulates the

report.

4. System displays the report.

Extensions:

3. Database is unavailable

a. The data for the report is unavailable.

i. The Admin is notified that the report is unavailable.

Variations: None
 Priority: Low

Performance Target: 3 seconds for report to be generated and displayed.

Frequency: Average 1 Admin report request per day.

Use Case 3: Key request (User requests software license/key)

Characteristic Information:

Goal in Context: User is assigned a software license/key for a certain piece of

software.

Scope: Primary task.

Primary Actor: User

Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

Preconditions: User is logged in and has access to at least 1 piece of software.

 Success End Condition: User is granted a software license/key for the requested

software.

Failed End Condition: User is notified why their request is unable to be fulfilled.

Sunny Day Scenario:

1. User selects the software package that they are interested in getting a

license/key for

2. System checks if the User is authorized to be granted a license/key for the

software.

3. System checks if there is an available license/key for the software.

4. System returns the license/key information to the user.

Extensions:

1. No software available to user or desired software not listed

a. The software they want a license/key for is not listed

i. User cannot request license/key.

2. User is not allowed to request license/key for selected software

a. The User is not authorized

i. The user is notified that they are not authorized.

3. Software license/keys are used up, no keys available.

 a. There are no available licenses/keys.

i. User is notified that there are no available licenses/keys.

ii. Admin is notified that there are no more licenses/keys for that

software.

Variations: None

Priority: Medium

Performance Target: 3 seconds for request to be checked for availability and

authorization.

Frequency: Average 20 User key requests per day.

Use Case 4: Request reports (User requests reports from the system)

Characteristic Information:

Goal in Context: Allow a User to requests reports from the system. Example of

reports would be how many licenses they currently have assigned to them.

Scope: Primary task.

Primary Actor: User

 Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

Preconditions: User is already logged in and authorized to view reports.

Success End Condition: User views selected report.

Failed End Condition: User is notified selected report is unavailable.

Sunny Day Scenario:

1. User is presented with a list of report types that are available.

2. User selects the report type.

3. System fetches the required information from the database and formulates the

report.

4. System displays the report.

Extensions:

3. Database is unavailable.

a. The data for the report is unavailable.

 i. The User is notified that the report is unavailable.

Variations: None

Priority: Low

Performance Target: 3 seconds for report to be generated and displayed.

Frequency: Average 1 User report generated per day.

Use Case 5: Log in (User/Admin logs in to the system)

Characteristic Information:

Goal in Context: The proper authentication and authorization of a user/admin into

the system.

Scope: Primary task.

Primary Actor: User/Admin

Channel to primary actor: web browser

Supporting Actors: NJIT LDAP Server, database

Channel to supporting actors: LDAP directory, database

 Preconditions: User/Admin already has valid username and password.

Success End Condition: User/Admin is logged in successfully and granted

access to appropriate parts of the system via a menu.

Failed End Condition: User/Admin is notified that they have not successfully

logged in, and are asked to try again.

Trigger: User/Admin goes to web site homepage of the system.

Sunny Day Scenario:

1. User/Admin is presented with a login page where they enter their username

and password.

2. The system accesses the NJIT LDAP Server to authenticate their username

and password.

3. Authenticated user is checked against list of acceptible Admin usernames.

4. The system associates that user with either Admin or User rights.

5. The system then notifies the user that they have logged in.

6. The system allows access to appropriate parts of the system via a menu.

Extensions:
 2. User/Admin provides incorrect username and password.

a. The username and password did not authenticate.

i. The User/Admin is notified and presented with the information they

might need to reset their account.

ii. The system starts at the beginning of the login.

3. LDAP authentication is unavailable.

a. LDAP cannot be contacted to authenticate the user.

i. User/Admin is told system is unavailable.

4. Admin is not presented with appropriate admin menu functions.

a. The system did not associate the user with Admin rights

i. The system associates the user with User rights.

Variations: None

Priority: Critical

Performance Target: Less than 3 seconds once login form is submitted.

Frequency: Average 20 logins per day.

Use Case 6: Add software (Admin adds software entries to the system)

Characteristic Information:
 Goal in Context: Successful addition of a new software package record in the

system.

Scope: Primary task.

Primary Actor: Admin

Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

Preconditions: Admin is logged in and authorized.

Success End Condition: Admin successfully added a new software package to

the system.

Failed End Condition: Admin is notified that their addition has been unsuccessful

and why.

Sunny Day Scenario:

1. Admin selects the software package to be removed.

 2. System checks off a "make unavailable" option for software entry.

3. Admin confirms removal.

4. System removes the software package from the available list and records it as

a removed package.

5. System notifies Admin of successful removal.

Extensions:

4. Admin cannot remove software package

a. Confirmation is declined.

i. Admin is notified that removal could not be completed and why.

Variations: None

Priority: Medium

Performance Target: Less than 3 seconds once request form is submitted.

Frequency: One-time entering of all current software packages. Additional

packages added as needed.

Use Case 7: Remove software (Admin removes software from the system)

Characteristic Information:
 Goal in Context: Successful removal of a software package record in the system.

Scope: Primary task.

Primary Actor: Admin

Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

Preconditions: Admin is logged in and authorized.

Success End Condition: Admin successfully removed a software package to the

system.

Failed End Condition: Admin is notified that their removal has been unsuccessful

and why.

Sunny Day Scenario:

1. Admin selects the software package to be removed.

2. System checks off a "make unavailable" option for software entry.

 3. Admin confirms removal.

4. System removes the software package from the available list and records it as

a removed package.

5. System notifies Admin of successful removal.

Extensions:

4. Admin cannot remove software package

a. Confirmation is declined.

i. Admin is notified that removal could not be completed and why.

Variations: None

Priority: Medium

Performance Target: Less than 3 seconds once removal form is submitted.

Frequency: Rare, only after software license agreement with vendor has expired

and there are no more issued licenses/keys active.

Use Case 8: Remove Report problem (User reports a software problem / help

request)

Characteristic Information:
 Goal in Context: Successful addition of a software problem / help request into the

database.

Scope: Primary task.

Primary Actor: User

Channel to primary actor: web browser

Supporting Actors: database

Channel to supporting actors: database

Preconditions: User is logged in and authorized.

Success End Condition: User successfully submits a software problem / help

request.

Failed End Condition: User is notified that their submission has been

unsuccessful and why.

Sunny Day Scenario:

1. User selects the software package to submit a problem or help request for.
 2. User enters in the problem description.

3. User submits to the system for a preview of their problem description

4. System checks preview submission for errors.

5. User reviews submission and submits.

6. System notifies User of successful submission.

Extensions:

4. System encounters an error with the preview submissions

a. User is presented with information on what error was encountered and

how to correct it.

i. Return to step 3

Variations: None

Priority: Low

Performance Target: Less than 3 seconds once request form is submitted.

Frequency: Average 5 reports per day.

Login Page

The purpose of the login page is to provide the user with an interface for
Purpose
authentication.
Inputs The inputs to the Main Menu will come in the form text.
 The user name and password will be verified by LDAP and depends on

Processing the role: students or staff/faculty user will see Main Menu with features

available to them.
Outputs User will see the SMS Main Menu.
Table1. Login Page

SMS Main Menu

The purpose of the main page is to provide the user with an interface for

Administrator to request information about existing software, add new

Purpose
software to the database or request report. User will be able to request

product key and submit problem.

The inputs to the Main Menu will come in the form of clicks to
Inputs
hyperlinks that will move the user to desired areas.
The amount of data processing is minimal because the web browser will
Processing
handle the mouse clicks and webpage linking and parsing.
The output will come in the form of the user moving from one page to
Outputs
another.
Table 2. SMS Main Menu

Form to add new software

This section will initialize the interface necessary input information

Purpose
about new software.
The inputs to the program will come in the form of text that will be saved
Inputs
to the database.
Processing Data will be moved to the server database.
Outputs Dialog box will show the user that the operation is completed.
Table 3. Form to add new software
4.3 Performance requirements

4.3.1 The number of terminals to be supported: the software

shall run from the browser.

4.3.2 The number of simultaneous users to be supported: The hardware

shall have the capacity to support 300 users.

4.3.3 Amount and type of information to be handled: The information

shall be related to the needs of the IT Administrators. The system

shall store information about software vendor, users and departments

that shall request keys and software keys downloaded from software

website. 95% of the transactions shall be processed in less than 5 s.

4.3.4 The performance required for this product shall largely depend on

the hardware used.

4.4 Logical database requirements

4.4.1 The types of information used by various functions shall be mostly strings,

dates and integer values.

4.5 Design constraints

4.5.1 Report shall have format of graphs and statistics

4.6 Software system attributes or other requirements

4.6.1 Availability

3.6.1.1 The system shall be available 24x7 to all user groups. The web

servers shall be in a cluster to allow maintenance of the system without any

down time.

4.6.2 Security

Introduction:

The system authenticates the user against an LDAP directory using a username and

password. The login form should be submitted over Secure Socket Layer (SSL)

connection via the web browser. This will ensure that the submission of the username

and password are encrypted through the network. An authentication hash should be

stored on in a browser cookie and checked on load of every subsequent page. It should

not be possible to stumble onto a page past the authentication front-end and have the

system perform authenticated functions. For added security, web pages in the system

that accept or display license keys can also be encrypted via SSL, to prevent keys from

being “sniffed” out of the network traffic. It is possible to require VPN authentication from

off-campus as well.

The system shall

3.6.2.1 The system shall authenticate the user against NJIT's LDAP directory

using their UCID and password

3.6.2.2 The system shall use SSL for all communication involving the UCID and

password

3.6.2.3 The system shall check for validity of the user upon load of every page

3.6.2.4 The system shall require the use of secure tunnel (VPN) when connecting

from off-campus

3.6.2.5 The system shall transmit web pages that display software key information

over SSL (Optional)

4.6.3 Maintainability

3.6.3.1 All processes and detailed design shall be well documented to

allow for easy maintenance and upgrading of the system to add new

functionality.

3.6.3.2 All components shall be modular and loosely coupled with each

other.
 4.6.4 Portability

4.6.4.1 Percentage of components host-dependent code shall be: 0%

4.6.4.2 Percentage of code that is host dependent shall be: 0%

4.6.4.3 Portable language shall be HTML code and java script code

4.6.4.4 Particular compiler or language subset shall be XHTML, PHP

4.6.4.5 The operating system shall be Linux or Microsoft Windows.

4.6.5 Interoperability:

3.6.5.1 The system shall be able to interpret data from NJIT’s LDAP

directory.

4.6.6 Reliability:

3.6.6.1 The system shall be reliable so as to confirm to the availability

requirements given above.

3.6.6.2 System shall be deployed on reliable hardware and the application

testing should be done before making the system

3.6.6.3 The system shall be to have PHP, web server and MySQL enabled.
 4.6.7 Backup and Recovery:

3.6.7.1 Full data backup shall be taken every week and incremental

backup taken every night.

4.6.8 Accessibility:

3.6.8.1 The system shall be accessible to anyone with a valid username

and password, and who is also either a student or faculty/staff member. Guest

accounts are not permitted.

3.6.8.2 The system website shall support the 2 major web browsers

(Internet Explorer, Firefox).

3.6.8.3 The system shall run 24 hours a day, 7 days a week, and shall be

available from any IP address range (unless VPN restrictions are in place).

3.6.8.4 The system shall run 24 hours a day, 7 days a week

3.6.8.5 The system shall be accessible to anyone with a valid UCID and

password

3.6.8.6 The system shall disallow guest, temporary, other such designated

UCIDs

3.6.8.7 The system shall be viewable through two major web browsers

(Microsoft Internet Explorer and Firefox)

4.6.9 Performance:

Introduction

As with any modern web site, the system should respond almost instantly to simple

requests (page requests), and have a <5 second response time on pages that are

processing or fetching data from the database or the LDAP directory. This means that

the web server, database server, and LDAP directory server must also meet similar

performance metrics. A response time of <3 seconds is optimal. Anything longer than

>5 seconds and the user may think the system: a) has failed to receive their last

request, b) has become unresponsive, or c) is not designed with performance or the

user experience in mind. With sufficient processing power and network bandwidth, this

system should have near-instant response times.

The system shall

3.6.9.1 The system shall respond to non-interactive page requests in <5 seconds,

preferably <2 seconds

3.6.9.2 The system shall respond to interactive and query-based requests in <5

seconds

3.6.9.3 The system shall be able to accommodate approximately 10 simultaneous

users within these performance metrics

4.6.10 Data retention:

3.6.10.1 User data should be retained from 10 years.

 Appendixes

Appendix A: Data Flow Diagrams

Context Level Diagram

IT N JIT
U SER
ADMIN LDAP

Authentication
confirmation

User login data

for authentication
Admin login data
control
for authentication
control

U nsolved problem query

Added keys data Product key / License request

Solution to new problem Problem report

Admin login data Software request /inquiry

Report request User login data

Added/ R emoved softw are data Software info for update control

Softw are info /detail change data

SOFTWARE
Removed user data for adding
MANAGEMENT SYSTEM
to table w ith software title

Reports

Versi on update license change noti fication

S oftware availabi lity report or soft ware

New problem data

Li cense/ product key email
Help/ problem recorded em ail

Welcome screen

Available admin actions

A vail able user acitons

Welcome screen
User doesnÕtexist info
Adm in doesnÕtexist i nf o

Confirmation
Report doesnÕt exist

S oft ware doesnÕtexist error

Report doesnÕtexist error

IT
U SER
ADMIN

Figure 2 Context Level Diagram

1st Level DFD

NJIT
LDAP
Admin login data for
Authentication User login data for authentication control
authentication control
confirmation
1
Available user actions Authorize Admin info
user& send Available admin actions
Welcome screen available IT

A dmin info
USER Welcome screen
actions list ADMIN
User login data Admin login data
User inf o
S oft ware request / inquiry

User doesnÕ
t exist info
S oft ware avail abi lity report / sof tware

Admin doesnÕ
t exist info
User info
Confirmation
Admin
info
Software info /detail change data

Confirmat ion
P roduct key/li cense em ail

Product key /
license request
2 Software doesnÕ
t exist error
Change
Software
3

A dmin info
Info 5
Evaluate
Add product Added keys data
product key /
Available keys / licenses
4 license Revised
request software software
Evaluate to make
software info License / key Removed user
changes info data with
User inf o

request /
inquiry software title
Product key /
License info
Software info

New problem SOFTWARE , LICENSE & 6

Rem ove user &
data for admin
USER DATABASE
add to table with
IT software title
New problem dat a

ADMIN New problem

data
P roblem description
to dbase

Removed user dat a for adding t o t able wit h s oft ware tit le
List of removable
reports
Required dat a

Solution
to new Available
Update/ license
problem reports
change info
7 list
Evaluate Added/ Removed
Unsolved problem query problem software info
reports& send
Admin info help email 9
Problem report Add / Remove
Report doesnÕ t
8 exist error Software
Create
Help/ Problem
Reports
recorded email 10 Confirmation
M anage version
Software info
for update control update / license Software doesnÕ t
change Report exist error

Report Added /removed

request software data
Version update / license
USER
change notification
IT
ADMIN

Admin info
Confirmation
Admin info

Figure 3 1st Level DFD

2nd Level DFD

8th Process

Available reports
list

Report request

Admin info

8.1
Required report
Evaluate
info
request

Report doesnÕt
exist error

8. 2
Required
Edit
data
data

Edited data 8. 3
Create& send Report
reports

Figure 4 2nd Level DFD: 8th Process

 7th Process

Problem report
User info

Admin info

Unsolved problem
query

7. 1
Evaluate Solution to
New problem data new problem
request
for writing to database
Problem description

Problem description
to be mailed

Notification about
recorded new
Query problem

7. 2 7. 3
Put new problem Get problem data
description from database & 7.4
Help/Problem recorded mail
to database send to IT Admin Send mail

New problem
New problem data to dbase New problem data
data for admin

Figure 5 2nd Level DFD: 7th Process

 Appendix B: Data Dictionary

Data Dictionary of Software Management System

Data Flow Structure Description/ Purpose Connections to Connections to

processes - Source processes - Sink

User login data for Provide user login info/ 1-authorize user & send NJIT LDAP

authentication control data to be given available action list

authentication control

process
Authentication Authenticate login NJIT LDAP 1-authorize user &

confirmation confirmation to valid send available

user/ Admin action list

Admin login data for Provide Admin login 1-authorize user & send NJIT LDAP

authentication control info/ data to be given available action list

authentication control

process
Welcome screen Display “welcome” on 1-authorize user & send User

the screen while user available action list

successful login
Welcome screen Display “welcome” on 1-authorize user & send IT Admin

the screen while Admin available action list

successful login
Available user actions Authorize user to 1-authorize user & send User

proceed actions available action list

Available Admin actions Authorize Admin to 1-authorize user & send IT Admin

proceed actions available action list

User login data User provides individual User 1-authorize user &

information to login send available

action list
Admin login data Admin provides IT Admin 1-authorize user &

individual information to send available

login action list

User doesn’t exist info Display wrong user 1-authorize user & send User

individual information & available action list

send feedback to user

who logged
Admin doesn’t exist info Display wrong user 1-authorize user & send IT Admin

individual information & available action list

send feedback to Admin

who logged
Admin info Provides Admin info to 1-authorize user & send 2-change software

internal process (2) available action list info

Software doesn’t exist Display wrong software 2-change software info IT Admin

error info and status to IT

Admin
Software info/ detail Make change of IT Admin 2-change software

change data software info and detail info

to be updated
Confirmation Give feedback of 2-change software info IT Admin

confirmation to IT Admin
 Revised software info Proceed revised 2-change software info SOFTWARE,

software and send to LICENSE & USER

Database DATABASE
Available software to Database confirmed SOFTWARE, LICENSE 2-change software

make changes changes of software info & USER DATABASE info

and send feedback into

to internal process (2)

Product key/ license Users request license User 3-evaluate product

request key for using key/ license request

Product key/ license Evaluate product key or 3-evaluate product key/ User

email license available status license request

and send keys or license

to user
Product key/ license info Database provides SOFTWARE, LICENSE 3-evaluate product

product key & license & USER DATABASE key/ license request

information to internal

system process (3)

User info Provides user info to 1-authorize user & send 3-evaluate product

internal process (3) available action list key/ license request

Software request/inquiry Users request or inquire User 4-evaluate software

software for using request/ inquiry

Software availability Report available 4-evaluate software User

report/ software software status to users request/ inquiry

who request or inquiry

for individual software

 Software info Database provides SOFTWARE, LICENSE 4-evaluate software

software information to & USER DATABASE request/ inquiry

internal process (4)

User info Provides user info to 1-authorize user & send 4-evaluate software

internal process (4) available action list request/ inquiry

Admin info Provides Admin info to 1-authorize user & send 5-add product keys/

internal process (5) available action list licenses

Added keys data Make addition license IT Admin 5-add product keys/

keys for using licenses

Confirmation Give feedback of 5-add product keys/ IT Admin

confirmation to IT Admin licenses

License/ key info Proceed added license 5-add product keys/ SOFTWARE,

keys to be added into licenses LICENSE & USER

Database DATABASE
Admin info Provides Admin info to 1-authorize user & send 6-remove user &

internal process (6) available action list add to table with

software title
Removed user data for Remove user from IT Admin 6-remove user &

adding to table with database and gather add to table with

software title statistics of title of software title

software
Confirmation Give feedback of 6-remove user & add to IT Admin

confirmation to IT Admin table with software title

Removed user data with Proceed removed user 6-remove user & add to SOFTWARE,
 software title data with software title to table with software title LICENSE & USER

be updated in Database DATABASE

Admin info Provides Admin info to 1-authorize user & send 7-evaluate problem

internal process (7) available action list reports & send help

email
User info Provides user info to 1-authorize user & send 7-evaluate problem

internal process (7) available action list reports & send help

email
Solution to new problem Provide and list solution IT Admin 7-evaluate problem

to new problem comes reports & send help

from Database email

New problem data Give new problem data 7-evaluate problem IT Admin

to IT Admin reports & send help

email
Unsolved problem query Provide unsolved IT Admin 7-evaluate problem

problem into internal reports & send help

process (7) for query email

Problem report Users provide User 7-evaluate problem

discovered problem and reports & send help

report back email

Help/ problem recorded Send help/ problem 7-evaluate problem User

email recorded email to user reports & send help

for solving problems email

which user faced

New problem data to Provide new problem 7-evaluate problem SOFTWARE,

dbase data to be recorded into reports & send help LICENSE & USER

Database email DATABASE

Problem description Problem description SOFTWARE, LICENSE 7-evaluate problem
 provided by Database & USER DATABASE reports & send help

email
New problem data for Provide new problem SOFTWARE, LICENSE 7-evaluate problem

Admin data for Admin using & USER DATABASE reports & send help

email
Admin info Provides Admin info to 1-authorize user & send 8-create reports

internal process (8) available action list

Report request Request for reports IT Admin 8-create reports

Report Send information of 8-create reports IT Admin

reports

Report doesn’t exist Display error information 8-create reports IT Admin

error of exist and send to IT

Admin
Required data Provide updated SOFTWARE, LICENSE 8-create reports

required data & USER DATABASE

Available reports list Provide updated SOFTWARE, LICENSE 8-create reports

available reports list & USER DATABASE

Admin info Provides Admin info to 1-authorize user & send 9-add/ remove

internal process (9) available action list software

Added/ removed Make added or removed IT Admin 9-add/ remove

software data software data for software

updated
 Confirmation Give feedback of 9-add/ remove software IT Admin

confirmation to IT Admin

Software doesn’t exist Display error information 9-add/ remove software IT Admin

error of exist and send to IT

Admin
Added/ removed Proceed added/ 9-add/ remove software SOFTWARE,

software info removed software info to LICENSE & USER

be updated in Database DATABASE

List of removable reports Make list of removable SOFTWARE, LICENSE 9-add/ remove

reports to internal & USER DATABASE software

process (9)
Admin info Provides Admin info to 1-authorize user & send 10-manage version

internal process (10) available action list update/ license

change
Software info for update Request software info User 10-manage version

control update update/ license

change
Version update/ license Notify user of software 10-manage version User

change notification info update, license update/ license change

change, software

version update
Update/ license change Provide valid software SOFTWARE, LICENSE 10-manage version

info info update and license & USER DATABASE update/ license

change change
Table 4. Data Dictionary

Data Dictonary Level 1 for User

1. software request/ inquiry: users request or inquiry individual software

1.1source: user

1.2sink: 4-evaluate software request/ inquiry

1.3BNF descriptio006E

(software request/ inquiry = sfw_req)

sfw_req => Login_info + sfw_info

Login_info => Login + pwd

Login => “LoginID”+ 10{α/n}10

pwd => “psd” + 10{α/n}10

sfw_info => sfw_id + sd_action_cd + [ {sfw_data}*| action_result_message]

sfw_id => {n}16

sd_action_cd => [SFW_ADD | SFW_DELETE | SFW_UPDATE]

sfw_data => sfw_name + sfw_description

2. product key/ license request: Users request license key for registering

individual software authentication

2.1. source: user

2.2. sink: 3-evaluate product key/ license request

2.3. BNF description

( Pdt= product, lic= license, req= request, pwd= password)

(product key/ license request= Pdt_key_lic_req)

Pdt_key_lic_req => login_info + lic_info

Login_info => Login + pwd

Login => “LoginID”+ 10{α/n}10

pwd => “psd” + 10{α/n}10

lic_info => lic_id + ld_action_cd + [ {lic_data}*| action_result_message]

lic_id => {n}16

ld_action_cd => [LIC_ADD | LIC_DELETE | LIC_UPDATE]