Add System Design Information

To save time, I suggest that after you build your requirements using the template, you save an archive version and then plug in system design information and settings as you determine them. When you add them to the requirements document, the specifications complete a one-source record for use while you create and maintain your configuration. This doesn’t apply to requirements that include extensive customizations that include coding or that may demand requirements and specification documentation of their own.

Notifications

Record information relative to your installation in Table 3-9.

Table 3-9: Notification Service Information

REQUIREMENT	VALUE
Default e-mail message
From address
Company e-mail address
SMTP server
SMTP port
Daily runtime

SharePoint Team Services Information

Record information relative to your SharePoint Team Services installation in Table 3-10.

Table 3-10: SharePoint Team Services Information

REQUIREMENT	VALUE
SharePoint Server name
Port #
Administration port #
SSL port
Database server name
Database name
Set server to automatic or manual subweb creation?
Automatically or manually add users to subwebs?
Automatically add users to Public Documents subweb project manager role?

Home Page Content and Link Additions

Record home page links and content links in Table 3-11.

Table 3-11: Home Page Content and Links

REQUIREMENT	VALUE
Specify URLs to add.
Specify content links to add.

Server Register

Record your server names and OS in Table 3-12.

Table 3-12: Servers in the Configuration

MACHINE	NAME	OS
Microsoft Project Server
SharePoint Team Services
SQL Server 2000 Database Server
Notification Server (SMTP)
Analysis Server
Terminal Services Server
Other

Define Custom Fields from Requirements

Once you’ve finished gathering your requirements, you must translate the custom attribute requirements into enterprise fields and outline codes. Remember that any attribute that you’d like to become a dimension in the OLAP cube must be created as an outline code.

Because custom field names don’t publish to the fields list in Project Web Access when building views, it’s essential to have an easy-to-read record of your customizations. The format of the grid shown in Figure 3-1 comes from the chapter’s accompanying template and is one that I recommend you use to record your field definitions. I use an abbreviation system for representing the codes. (If you’re new to Project Server, you may want to read more about custom fields and codes in Chapter 8 before completing your design.)

Figure 3-1. Custom fields design grid

Columns represented include the Field Label, which is the descriptive name you’ll give the field. Next, the Field column contains an abbreviation structure for representing specific fields described in the following abbreviation list. The third column tracks whether the field is mandatory or optional. The fourth column contains a value list if one applies, and the fifth column contains a specified default value. Finally, the sixth column is a place to make some notes that further describe your intention for the field.

Enterprise fields come in three flavors: project, task, and resource. In the abbreviations shown in the grid, “E” represents enterprise and “P” represents project. Use “R” and “T” to represent resource and task, respectively. The next two letters in the coded abbreviation are used as follows:

• OC = outline code

• TX = text field

• CO = cost field

• NU = number

• FG = flag field

• DT = date

• DU = duration

Follow the first four letters with a number to identify which field number is designated for this use. There you have it, a six-character representation for all of your custom fields.

Lastly, note that in the Field column, some additional entries are added. “SH” indicates that the field “shares” a value list with the field listed on the next line. This will remind you to set it up this way when you actually perform the customizations.