User Requirement Specification for Tender Alert Website

3,625 views

Published on

This is a user requirement specification I wrote for as commissioned by a Project Manager. The site is a commercial success, with a Africa wide footprint and a regular monthly subscriber base. The site is Africa's leading tenders notification website, with hundreds of Tenders and Business Leads available, and has helped get Africa's economy rocking...
I am no longer involved with the site and its development, however architected the original database scheme, code pertaining to capturing and searching, user management and navigation.

Published in: Business, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,625
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

User Requirement Specification for Tender Alert Website

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 6
  7. 7. 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
  8. 8. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  9. 9. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  10. 10. 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
  11. 11. View Tender Document 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
  12. 12. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  13. 13. 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 following information: 13
  14. 14. 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 following information: 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
  15. 15. IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  16. 16. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  17. 17. 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
  18. 18. 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
  19. 19. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  20. 20. 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. System Configuration 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
  21. 21. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION Application Password Recovery 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 21
  22. 22. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  23. 23. 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: IMAGE REMOVED BY CM 20081009 DUE TO SIZE RESTRICTION 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
  24. 24. Displaying Tender Documents Using ActiveX Control Scope Limitations Flowchart Summary Public User Processes TenderAlert ASP.NET application – Public User Process Revision 1 View Tender Document Apply for Tender 24
  25. 25. 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 Application Password Recovery System Configuration 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

×