Portal Solution Requirements Table

 <  Day Day Up  >  

We have surveyed some of the key functions that are required of today's portals, but which ones must you implement in version 1 of your portal? Which are least important? Where do you get started in scoping the hardware and software requirements for the portal? To answer these and other questions, a good place to start is with the following solution requirements table (Table 2.3).

Table 2.3. Portal Requirements Table

Requirements Question

Comments and Suggestions

Who are the intended users of the portal? Will anonymous users be supported? Will any features require authentication?

For example, estimate the number of public (anonymous) portal users, the total number of internal employee users. Content management features will definitely require authentication.

What growth in portal usage is anticipated?

Consider usage statistics for other sites in calculating these numbers .

Does the security and authentication of the portal integrate with any other security scheme? Is it part of a larger domain with single sign-on?

Single sign-on is quite popular, but not easy to implement as it requires trust and changing behavior on the part of system administrators.

What are the roles for the portal users? How will their access to portal elements be controlled?

 

What groups must be created and what permissions assigned to each group ? For instance, will groups be needed for content authors, editors, administrators, template authors, graphic designers, subscribers, and application developers?

See Chapter 9 and Microsoft Content Management Server documentation for descriptions of typical roles.

Who will administer user accounts in the portal? Is this management centralized or decentralized?

Consider delegation of access administration to those closest to the users. For a large portal, centralized administration can grow to quite a burden .

What is the failover plan? How will the plan be tested and exercised?

This is the most often overlooked part of portal planning.

How will the portal be monitored ? Will certain events trigger alerts to administrators?

 

What applications need to be integrated with the portal?

Gather detailed information about each of the applications, such as browser and bandwidth requirements, as well as authentication.

How much content will the portal contain when it is launched? How quickly will the content grow?

Be optimistic that content will grow at a significant rate, especially if you are implementing content management.

Where is content currently stored? Is it in static HTML files or in a content management system? What formats are used? Which web servers?

Content may require editing and reformatting during the migration.

How will existing content be migrated to the portal? Will content be edited or removed during this process?

Migrating content is one of the most time-consuming tasks in portal development.

What are the business rules for routing and approval of content?

A pilot to test these rules is often useful.

Are commerce capabilities required? What are the commerce requirements for the portal?

The catalog project may be run independently from the static content migration.

What is the estimated transaction volume for portal transactions?

Include average and peak loads.

Will the portal be integrated with third parties such as financial institutions or suppliers? What are the integration points? What standards are these organizations supporting? Are they publishing XML schemas? Do they support web services?

Contact these third parties early in the development process and solicit their rules for integration.

How can you test the integration with outside parties? What failover plans do they offer?

Be sure you can submit test records that will not affect your accounts.

Will source code be controlled with a product such as Visual SourceSafe?

I recommend that you use a tool like this for projects with multiple developers.

How will you test and built iterative versions of your site? Will builds be performed on a daily basis?

A build schedule allows managers to see progress regularly.

What is the graphic design for the portal? Has the necessary artwork and photography been completed?

Keep the group for making these decisions as small as possible.

Are color and font standards set?

 

Which accessibility standards will be followed? Will the site comply with section 508 guidelines? If so, how will the site be tested for such compliance?

Automated testing tools are available for this purpose.

Are collaboration tools needed for the site? Which ones? Should any of these be made available to anonymous users?

Consider requirements for moderating these discussions when outsiders are permitted.

Has a taxonomy been developed for the portal? Who is responsible for creating and maintaining the taxonomy?

The earlier you start this process, the better.

Which devices should be supported? What browsers and browser versions will be supported?

New devices are shipping every day. Don't invest too much in devices or technologies that have small numbers of users or are on the edge of obsolescence.

What are the search requirements for the site? Which content will be indexed? Will content outside the portal be indexed?

Typically you will want to support simple and advanced searches.


 <  Day Day Up  >  


Building Portals, Intranets, and Corporate Web Sites Using Microsoft Servers
Building Portals, Intranets, and Corporate Web Sites Using Microsoft Servers
ISBN: 0321159632
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net