User Requirement Specification for Tender Alert Website

URS for TenderAlert Website

Chris Morton
Thursday, 11 January 2007
Version 1 of URS for TenderAlert Website.doc

Table of Contents
NOTES ....................................................................................2
Introduction ..........................................................................3
Objective Summary ............................................................4
User Access Levels ..............................................................4
Internal Users..................................................................4
Public Users ....................................................................5
Capture Tender .....................................................................5
Post Tender ..........................................................................6
Managing Tenders .................................................................7
The Life Cycle of a Tender .................................................7
Search Tender .......................................................................8
Fields to be searched against ...............................................9
View Tender Details ...............................................................9
View Tender Document ........................................................ 11
Applying for a Tender ........................................................ 11
Reports and Audit Trails ....................................................... 12
Report Types .................................................................... 12
Tender Specific Reports .................................................. 12
Public User Specific Reports............................................. 13
Internal User Specific Reports .......................................... 13
Report Formats ................................................................ 14
Reporting Functionality ...................................................... 14
Online Registration .............................................................. 15
Company Data ................................................................. 15
Personal Data ................................................................... 15

1

Login Data ....................................................................... 15
Account Creation .............................................................. 15
Application Password ...................................................... 16
Account Verification ........................................................ 16
Note on Internal Users Accounts ......................................... 16
Other Functionality .............................................................. 17
Account Login ................................................................... 17
User Configuration ............................................................ 17
Configuring a new Internal User Account ........................... 17
Configuring an existing Internal User Account .................... 18
Default Accounts ............................................................ 18
Message Configuration ...................................................... 19
Configuring a Message .................................................... 20
System Configuration ........................................................ 20
Application Password Login ................................................ 20
Application Password Recovery ........................................... 21
Public User Account Maintenance ........................................ 22
Internal User Account Maintenance ..................................... 22
Emailing Functionality ....................................................... 22
Interface Design .................................................................. 23
Colour Scheme and Graphics .............................................. 23
CSS .............................................................................. 23
MasterPage (ASP.net 2.0) ............................................... 23
General Page Template (Look and Feel) ............................... 23
Prototype 1 ................................................................... 23
Prototype 2 ................................................................... 23
Prototype 3 ................................................................... 23
Menu Structure ................................................................. 23
Use of Ajax ...................................................................... 23
Displaying Tender Documents Using ActiveX Control ............. 24
Scope Limitations ................................................................ 24
Flowchart Summary ............................................................. 24
Public User Processes ........................................................ 24
Internal User Processes ..................................................... 25
Administrator ................................................................ 25
Tender Capturer ............................................................ 25
Tender Manager ............................................................. 25

Diagrams
Notes

2

Note: in this document the ‘?’ preceding a word indicates this point
needs to be discussed
Note: items highlighted in green are point that needs to be
discussed in detail with Project Manager as I do not have a clear
idea on the functionality.

Introduction
Our client has requested that an interactive website be developed to
manage the publication of tenders for the Msunduzi Municipality.
The core functionality must incorporate the following:
1. Capture Tender
This must allow an Tender Capturer of the site to upload the
tender onto the system in order to allow the public to view the
tender.
2. Verify Tender
This must allow Tender Manager to verify captured tenders
and post them on the application to make the tenders
available to the public.
3. Search Tender
The public must be able to search for tenders using key
words. Additionally the public must be able to browse for
tenders using a categorized menu system.
4. View Tender
The public must be able to view the tender details online.
According to a discussion with Prenesh the public must submit
payment before they are able to view a tender document in
PDF format. Please confirm.
5. ? Apply for Tender
6. Email Tender
Project Manager please explain in more detail.
7. Reports and Audit Trails
3

Administrators must be able to generate reports on the public
viewing of tenders including number of times each tender has
been viewed and applied for.
8. Online Registration
The public must be able to register online, this registration is
mandatory to apply for a tender.
Objective Summary
The simplified business model for the TenderAlert application follows
this pattern:
IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION
User Access Levels
The users of this system are divided into two categories, namely:
Internal Users
Public Users
The user access levels identified at this stage of development are:

Internal Users
1. Administrator
The administrator
functionality:
o
o
o
o
o

role

has

access

to

the

following

the

following

? Message Configuration
User Configuration
Report Generation
Application Password Recovery
System Configuration

2. Tender Capturer
The tender capturer
functionality:

role

o Capturing Tenders

4

has

access

to

3. Tender Manager
The Tender Manager has access to the following functionality:
o Verifying Tenders
o Posting Tenders
o Managing Tenders

Public Users
4. Registered Contractor
o View Tender Document
o Apply for Tender
o Public User Account Maintenance
5. Anonymous User
All functionality included in the anonymous user’s profile is
available to the previously mentioned users.
The anonymous
functionality:

users

have

access

to

the

following

o Search for a tender
o View Tender Details (but not the tender document)
o Online Registration

Capture Tender
The process of capturing the tender must involve the login of a
Tender Capturer which allows the user access to the ‘Tender
Administration’ page.
The tender administration page must encompass the following
functionality:
Capturing Geographical Details:
Country
Region
? City
Capturing Tender Details:

5

Industry Type
? Date Submitted
Date of Closure
? Closure Type:
o Via Mail
o Via Personal Delivery
Tender Description
? Tender Title
Site Inspection – Project Manager please explain
ID – automatically generated for system use
Contract Number
? Tender Document in PDF format

The Capturing business model follows this generalized pattern:

Post Tender
Once a tender has been captured onto the system it must be
verified and posted, and thus made available to the public.
The verification process is the simple process of checking whether
the details entered by the capturer are true and correct and the
matching tender document is present. Once the details are verified
the Tender Manager can post the tender and it becomes available to
the public via the search facilities.
In the case that some of the details are not correct the detail(s)
that are incorrect are recorded and the verifier is given the option to
correct the details. In the case that the correct details are not
available the tender remain unverified until the correct details are
present.
Once a tender has been verified the tender capturing process is
complete and the tender details cannot be altered further.
The business model of posting a tender follows this process:

6

Managing Tenders
Since the interaction of tenders in regards to the public is not a
static process functionality to manage tenders is necessary.
The seven possible states of a tender are as follows:
Open
Closed
Under Evaluation
Awarded
Expired
Cancelled
Suspended
The manage tender functionality must allow the Tender Manager to
change the states of these tenders as necessary. The ‘Open’ and
‘Closed’ states of the tender can be managed automatically by the
TenderAlert application. The ‘Awarded’, ‘Expired’ and ‘Cancelled’
states require manual input from the Tender Manager. The ‘Under
Evaluation’ and ‘Suspended’ states are automatically managed by
the TenderAlert application but the Tender Manager must intervene
to change the state of the tender to the correct state.

The Life Cycle of a Tender
Once a tender is posted on the TenderAlert application the tenders’
state becomes open.
During the open phase the tender can be viewed and applied for by
registered users of the TenderAlert application. If however the
tender needs to be cancelled the Tender Manager can cancel the
tender and registered users who have applied for the tender will be
alerted by email.
As the Date of Closure is reached the tender state automatically
becomes ‘Closed’. The tender remains searchable on the system but
registered users can no longer apply for the tender.
In the case that no registered users have applied for the tender the
Tender Manager is alerted by email to either change the state of the
tender to ‘Expired’ or ‘Cancelled’.
Additional functionality to extend the Date of Closure must be
discussed.

7

During the interim period between the Date of Closure and the
Tender Managers interaction to change the state of the tender, the
tender automatically becomes ‘Suspended’.
In the case that one or more registered users have applied for the
tender the state of the tender automatically achieves the ‘Under
Evaluation’ state. The ‘Under Evaluation’ state remains indefinitely
until the Tender Manager changes the state of the tender to either
‘Awarded’, ‘Cancelled’ or ‘Suspended’.
The business model of managing tenders follows this business
model:

Search Tender
At this stage of the development process I would like to propose
several scenarios whereby effective searches can take place:
1. Search by Keyword
The search tender must support searching by keyword, for
example:
If a user types in Computers all tenders that involve that keyword
must be displayed.
2. Advanced Search By Optional Keyword
The Advanced Search Functionality allows the user to refine his
search by using Industry Type, Date Submitted, Date of Closure,
Open Tenders, and Tenders under Evaluation and Tenders Awarded.
In this search a keyword is optional.
3. Browse for tenders using categorized Menu System
This allows the user to view tenders by the industry type category.
Once a search has been carried out using the one of the various
methods the results must be displayed in a datagrid that displays
the following:
Tender Title

8

Industry Type
Contract Number
Tender Status (Open/Closed)
Date Submitted
Date of Closure
The user must be able to click on a tender and be directed to the
‘View Tender’ Page for the specified tender.
The Search Business model follows this general process:


Fields to be searched against
To achieve functionality in the search the fields to be searched
against must be determined. I propose the following fields be
searched against using the search component of the program:
Country
Region
? City
Industry Type
? Date Submitted
Date of Closure
Tender Description
? Tender Title
Contract Number
? Tender Document in PDF format
Please note with reference to the tender document in PDF format. I
am uncertain whether the actual text in the PDF document can be
searched against. If it can be I believe the functionality in the
search component of this application must support it.

View Tender Details
The view tender functionality immediately proceeds after search. To
reach the view tender page a user must first search for a tender
which results in a datagrid of tenders meeting the search criteria. A
specific tender is selected and is displayed in the view tender page.

9

The view tender page displays the following data:
Geographical Details:
Country
Region
? City
Tender Details:
Industry Type
? Date Submitted
Date of Closure
? Closure Type:
o Via Mail
o Via Personal Delivery
Tender Description
? Tender Title
Site Inspection – Project Manager please explain in more
detail
ID – automatically generated for system use
Contract Number
? A link to the Tender Document in PDF format
Tender State
These details are captured when Tender Capturer has uploaded the
tender, and are verified by a Tender Manager.
Once the tender details for the specified tender are displayed the
user has the following options:
Going back to the search results page
View Tender Document
If the view tender document option is selected the TenderAlert
application checks whether the user is logged in.
If the user is logged in, the application proceeds to show the tender
document as described in the next section.
If the user is not logged in the TenderAlert application prompts the
user to log in. If the user successfully logs in the application
proceeds to show the tender document.
In the login dialog the user also has the option of online registration
as described in the online registration section.

10

The view tender document page access is limited to logged-in
registered users and internal users (as described in the
introduction).
The view tender page allows an authorised user to view a tender
document with certain limitations as listed below:
The tender document cannot be saved onto the users system.
The tender document cannot be printed by the user.
Selecting text from the tender document is disallowed.
The tender documents location is not revealed by the URL
(which could allow advanced users to download it anyway);
one way to achieve this is to display the tender document in a
frame or ActiveX control.
The tender document is not copied to the users’ temporary
internet files.
Once the tender document is visible on the users system the user
has the option to apply for the tender as described below, or
continue browsing (go back to the search results page).
Applying for a Tender
If the user proceeds to apply for the tender the TenderAlert
application enters a secure section, protected by SSL, to allow for a
secure financial transaction to take place.
To apply for a tender the user must enter the Application Password
that is associated with the users account. The Application Password
is automatically generated by the system when the user is
registered using the online registration as described in the online
registration section.
On successful entry of the Application Password the user is directed
to a Paypal page where the user can select the payment method
they wish to use; typically the payment is made using a credit card
or Paypal account.
If the Application Password is not entered successfully within three
attempts the user is alerted via email. The Application Password
cannot be reissued but can be resent by the Administrator if
requested by the user.

11

On successful payment the TenderAlert application automatically
emails the applicant a copy of the tender document in PDF format
and the application forms.
If the payment is not successfully processed the user is alerted via
email and the documents are not sent.
The view tender document and tender application follow this
business model:

Reports and Audit Trails
The TenderAlert application requires the functionality of generating
reports that can be used to deduce audit trails pertaining to the
activity on the site.
At this stage of development I have identified the following reports
are necessary to deduce a comprehensive audit trail of the site:
Report Types

Tender Specific Reports
Monthly Report of new tenders submitted including
information on there status (Not Verified, Verified) and there
state (Open, Closed, Under Evaluation, Suspended, Expired,
Cancelled).
Monthly Report of Tenders most viewed (Tender Details).
Monthly Report of Tenders most applied for.
Reports on all Tenders according to there state within a
specified time period.
Report on Tenders captured according to a specified Tender
Capturer within a specified time period.
Report on Tenders managed according to a specified Tender
Manager.
An Audit Trail Report on a specific Tender captured including
information on the Tender Capturer, Tender Manager, and
Registered Contractors that have applied for the Tender (if
applicable). Additionally information pertaining to Timestamp
specific transactions took place and information on the
number of times the Tender Details have been viewed for the
specified tender.

12

Public User Specific Reports
Total number of Registered Contractors.
Monthly Report of new Registered Contractors.
Monthly Report of Registered Contractors matched against the
Tenders Applied for.
Monthly Report of most active Registered Contractors (i.e.
which contractors logged-in the most).
Monthly Report of attempted Security Breaches, including IP
addresses of the clients’ computers and the usernames used.
Audit Trail Report of a specified Registered Contractor
including information on there account details and tender
‘history’, i.e. tender details viewed, tender documents viewed,
tenders applied for, and ? tenders awarded.

Internal User Specific Reports
Reports pertaining to account types, account age and account
status (active/inactive).
Audit Trail Report of a specified user that summarises
information on account activities according to there account
type.
o For Administrators:
 A report for an Administrator includes the
following information:
User
Configured
by
the
specified
administrator
Messages Configured by the specified
administrator
System configuration changes by the
specified administrator
Reports
generated
by
the
specified
administrator
Application Passwords recovered by the
specified administrator
Account login history including attempted
security breaches
Reports
contain
information
on
the
Timestamp of all transactions
o For Tender Capturers:
 A report for a Tender Capturer includes the

13

Tender Details Captured for a specified
capturer, excluding the PDF document, but
including information about the PDF
document uploaded.
The Timestamp of all tenders captured by
the specified Tender Capturer.
o For Tender Managers:
 A report for a Tender Manager includes the
Tenders Verified and Posted by the specified
Tender Manager.
Tender ‘history’ of the specific tenders’ state
changes as executed by the specified
Tender Manager.
The
Timestamp
of
all
transactions
performed on each tender worked on by the
specified Tender Manager
Due to infinite complexity of the configuration of internal user
accounts the following restriction must be implemented:
In the case of the administrator(s) changing the type of internal
user account for a specific staff member the administrator is
prompted to generate an audit trail report for the activity recorded
for the user. The administrator should export and save this report
for future use if needed since the account history for the user will
become unavailable once the account type is changed. Refer to User
Configuration.
Report Formats
Report formats will ideally use the functionality and formatting
provided by Crystal Reports. At this stage the reporting formats
cannot be determined generally but this should be addressed in a
separate document that shows examples of each report.
Reporting Functionality
To accommodate the reporting described above it is necessary to
have three separate reporting interfaces. Each interface should have
a report building tool that accommodates for the specific reports
that can be generated from the page. This reporting functionality
should be addressed in more detail in a separate document.
All reporting should follow a standard procedure and the reports
must be exportable to windows in the form as excel documents.
The Reporting Functionality follows this business model:

14


Online Registration
Online Registration must allow the public (anonymous user) to
register on the TenderAlert application and become an active
participant in the tendering process.
The process of online registration should be simple and quick. The
process of online registration involves the collection of three sets of
data, namely the company data, personal data pertaining to the
company representative and login data.
Company Data
The following company data must be collected:
Company Name
Company Type
Location
? Industry Type
? Physical Address
? VAT Registration Number
Personal Data
The following personal data must be collected:
Contact person’s First and Last name
? ID Number
Telephone Number
? Cell Number
Fax number
Email address
Login Data
The following login data must be collected:
Username
Password (only strong passwords are permitted)
Account Creation

15

Once all the data is collected the account is created on the system
and the anonymous user becomes a registered contractor.
The TenderAlert application allows for more than one representative
for a company.
During the account creation process the new registered contractor is
emailed two emails. The first email includes the information
collected from the company data, personal data and login data
processes.

Application Password
The second email includes is an email that sends an automatically
generated unique strong password to the registered contractor. This
password is used to access the secure parts of the website
(protected by SSL) where financial transactions take place. It is
necessary to have this second layer of security to prevent
fraudulent transactions.

Account Verification
To verify that the registered contractor has in-fact entered a correct
email address the TenderAlert application will request that the
registered contractor enters the application password in the first
login of the new registered user. The account will become active
once the account has been verified successfully. If the account is
not verified within two weeks of online registration the TenderAlert
application deletes the record in the database for the unverified new
account.
The Online Registration follows this business model:
Note on Internal Users Accounts
To provide access for the internal users to the public user interface
of the TenderAlert application a ‘dummy’ account is configured for
the internal user accounts when an administrator creates their
account using the User Configuration functionality.
The ‘dummy’ user account is restricted from applying for tenders
online (the dummy user account by-passes the Process Payment

16

page) but all other functionality
Contractor account is available.

included

in

the

Registered

This ‘dummy’ user account is necessary to provide internal users
the ability to test the TenderAlert application as changes are made.

Other Functionality
To achieve the objectives of the TenderAlert application certain
unspecified functionality needs to be included, these are listed
below.
Account Login
The account login functionality allows the internal and public users
to access the required functionality according to the users account
type once the username and password have been successfully
entered.
In the event that the user (as determined by the public IP address
for the client computer) repeatedly enters the incorrect details more
that three times, a security alert is issued and email is sent to the
user (determined by the username) trying to access the site.
Administrators can access the security alerts by means of
generating a report.
The account login dialog also includes a link to the Online
Registration Page.
The business model of the account login is too simple to warrant a
business model model.
User Configuration
It is necessary that the administrator be able to configure internal
user accounts as staff within the clients’ (###’s Client)
environment changes.
To fulfil this functionality the user
configuration section allows new internal users to be created,
configured, activated and deactivated.

Configuring a new Internal User Account
The following data must be collected to configure an Internal User
account:
First and Last name of staff member

17

ID Number
Username
Password
Account Type
Email Address
Telephone Number
Cell Number
By default a new internal user’s account is activated (Refer to next
section).
By default a new ‘dummy’ account is created using the settings
configured in the System Configuration.
By default the new internal users account is unlocked (Refer to next
section).
Upon account creation an email is sent to the new internal user
introducing them to the system and what role they will fulfil. The
email also includes the information collected above and the URL of
the TenderAlert application.

Configuring an existing Internal User Account
Since the environment of ###’s client is constantly changing the
user account configuration must allow for certain changes, in
particular in the case that an internal user is no longer assigned to
work on the TenderAlert application.
The functionality to de-activate an account allows the administrator
to prevent the internal user from logging-in. The de-activating of
account does not existing records in the database and all reporting
for the de-activated user account remains available.
Additionally the administrator can lock the account to prevent
internal users from making changes via the internal user account
maintenance section.
The administrator can change any of the details of an existing
internal user account, except the username and password.

Default Accounts
The TenderAlert application installs three default accounts upon
installation, namely:
Default Administrator

18

Default Tender Capturer
Default Tender Manager
By default the Default Administrator is activated and the other two
accounts are de-activated. The default administrator uses the
username ‘admin’ and this cannot be changed. To begin using the
application the Default Administrator must first configure his
account and the system configuration, this will be addressed in the
user manual.
Configuring Internal User Accounts follows this business model:
Message Configuration
The TenderAlert application integrates a high level of
communication via email and the TenderAlert application interface.
In order to allow email messages to stay relevant to the economic
environment and other social aspects of the country the emails sent
by the application must remain up to date. To allow this flexibility
within the TenderAlert application the email messages sent by the
application cannot be hard coded into the application, and hence the
need for a configurable messaging system.
At this stage of development I have identified the following
communication
channels
that
the
message
configuration
functionality must target:
Communication via email to specified Registered Contractors
Communication via email to specified Internal Users
Communication via the TenderAlert interface that targets all
users
Communication via the TenderAlert interface that targets all
Registered Contractors (Such as the Terms of Use agreement
that must be agreed to before a account is created for the
user)
Communication via email to the development team that alerts
the developers of unhandled application errors
The message configuration makes use of ‘variables’ defined by the
development team that act as place holders for data that is
assimilated from the database. These place holders are ‘held’ within
certain predefined text (which is configurable using the message
configuration interface). Together the placeholders and text are

19

parsed by the system and a custom message is produced, this
message can be emailed or displayed on screen as required.

Configuring a Message
Since there are several categories of messages, which are
subdivided into several individual messages it must be noted that
only certain place holders can be used in a specified message.
In order to configure a message an administrator must type the text
for the specified message and add the placeholders pertinent to the
specific message. The message configuration functionality uses a
‘find and replace’ function to replace the placeholders with real data
derived from the database for the specific function in the
TenderAlert application.
The message configuration business model is beyond the scope of
this URS.
The system configuration allows the administrator to define certain
default settings as listed below:
‘dummy user’ Account Settings, this includes:
o Company Data and Personal Data related to the
‘dummy’ registered contractor
Organisation Name, the name that will be used in the emailed
messages, for example Msunduzi Municipality.
? Default Style Sheet – to allow a semi customisable interface.
? SMTP server settings
An Upload facility to upload the application form in PDF format
for the tendering process.
‘no-reply’ (unmonitored) email addresses used by the system
for both internal and external communication.
Set the amount to be charged for the obtaining of tender
documents.
Paypal settings
These settings are relatively simple and allow for the customisation
needed to sell an off the shelf solution to future customers.
The business model in beyond the scope of this URS.
Application Password Login

20

The application password login creates a second level of security to
allow secure financial transactions to take place.
The application password login requests that a user enters the
system generated application password to access the secure
payment processing section of the TenderAlert application.
To help prevent fraudulent transactions the password cannot be
generated more than once. In the case that a registered contractor
has mislaid his password, the password can be requested from the
Default Administrator.
Once the password has been submitted successfully the TenderAlert
application is redirected to a Paypal site where the transaction is
processed. Upon a successful transaction an email is sent to the
registered contractor, which contains a printable copy of the PDF
document of tender and the application forms. The email should
also contain instructions that guide the registered contractor
through the tendering process.
The application password login also includes a link whereby he can
contact the default administrator to request his password.
In the case that the application password is entered three times
incorrectly the registered contractor is alerted via email and the
registered contractor account is de-activated for 3 hours.
The application password login follows this business model:
Only the default administrator account has access to the application
password recovery section.
If a registered contractor has mislaid his application password and
requests that he be resent the password, the default administrator
can recover the application password by entering the username for
the registered contractor.
Once the username has been confirmed the registered contractor is
emailed his password to the address configured for the registered
contractor.
The application password recovery follows this business model:

21

Public User Account Maintenance
In order to implement security and accommodate changes for
Registered Contractors details on a public application such as the
TenderAlert application it is necessary to allow Registered
Contractors to update there details on the system.
Registered Contractors can update all details for their specific
account except for their username.
The public user account maintenance shares the same interface and
functionality of the online registration section except for the ability
to change their username.
The business model for public user account maintenance is slightly
different to the online registration section.
The public user account maintenance follows this business model:
Internal User Account Maintenance
The internal user account maintenance allows internal users to
change the following details of their account:
First and Last name
Password
Email Address
Telephone Number
Cell Number
The internal user account maintenance section also allows the
internal user to view recent account activity and export it to excel.
The internal user account maintenance follows this business model:
Emailing Functionality
The emailing functionality of the TenderAlert application combines
the message configuration and exposed user interaction
functionality with a background emailing class. The primary purpose
of the emailing functionality is to enable communication from the
TenderAlert application to the registered contractors, in particular

22

for the distribution of tender
application forms via email.

documents

and

corresponding

Emailing takes place automatically upon the execution of certain
user interactions such as the successful payment of the fee to
obtain tender documents. The email is composed via a mail merge
operation between stored data and the messages configured via the
message configuration. Once the email is composed the email is
sent via a background process that requires no user interaction.
The emailing functionality follows this business model:

Interface Design
The interface design of the TenderAlert application consists of three
distinct elements, namely:
The Navigation Structure
The ‘Control Container’
The Header and Footer
The integration of CSS and Flash are essential to create an aesthetic
look and feel of the TenderAlert application.
Colour Scheme and Graphics

CSS
Flash
MasterPage (ASP.net 2.0)
General Page Template (Look and Feel)

Prototype 1
Prototype 2
Prototype 3
Menu Structure
Use of Ajax

23

Displaying Tender Documents Using ActiveX Control

Scope Limitations
Flowchart Summary
Public User Processes
TenderAlert ASP.NET application – Public User Process Revision 1

Apply for Tender

24

Search for a tender
View Tender Details (but not the tender document)
Online Registration
Public User Account Maintenance
Internal User Processes
Internal User Account Maintenance

Administrator
? Message Configuration
User Configuration
Report Generation

Tender Capturer
Capturing Tenders

Tender Manager
Verifying Tenders
Posting Tenders
Managing Tenders

Last Modified: 2013/10/12 05:38:00 AM by Chris Morton

25

User Requirement Specification for Tender Alert Website

More Related Content

What's hot (7)

Viewers also liked (20)

Similar to User Requirement Specification for Tender Alert Website (20)

More from MakeNET (14)

Recently uploaded (20)

User Requirement Specification for Tender Alert Website