This chapter describes a method for changing the requirements of an application that is in production. In chapter we saw a process for identifying the requirements of an Application Use Case (AUC) for a new application; but what if the application already exists and we:


Chapter 8 Iterative Development This chapter describes a method for changing the requirements of an application that is in production. In chapter we saw a process for identifying the requirements of an Application Use Case (AUC) for a new application; but what if the application already exists and we: 1. wish to add a new AUC to the application’s functionality? 2. wish to change existing functionality of an AUC that has already been deployed? 3. wish to change an AUC that is already being changed by another development team? In this chapter I discuss how to manage your AUC requirements such that all 3 scenarios are possible without breaking someone else’s work. The processes described in this chapter are significantly complicated. Normally in order to solve these problems, I would insist upon using tools that have much of the functionality that I require built-in (management of traceability for example). Instead I will use nothing more sophisticated than MS Office with SharePoint Server (MOSS). Why? Because a significant number of analysts are using nothing more appropriate to manage their requirements today. I have worked in offices where these were the only tools I was given to work with. This chapter starts by describing the problem, then it describes an architecture for handling the problem and then explains the details of the processes used to configuration manage the use cases. 8.1 The Problem The initial release of an application has been deployed into production. This application is part of an Enterprise environment and therefore has interfaces to several other applications. The requirements for this application (and those that it interfaces with) come from several different business areas, each with their own set of business needs. Now suppose that the business wishes to make some changes to the way that the business needs have been implemented. Either the business process had changed, or there is more automation that has been identified for a subsequent release. Maybe these business needs are coming from a different business organization than that which defined the original requirements. As well as changing the business artifacts, these changes could impact any of the AUCs used to capture the requirements for the initial release of the application, and they could have an impact on any interfacing application. Figure 1: shows that changes to the way in which the database organizes it’s data, has a knock-on effect to all systems that use that data. Figure 1: Impacted Systems I like to think of application requirements, as application source code, but at a higher level of abstraction. Supposing software development organizations treated their source code as they do their requirements. Imagine the chaos there would be with their staged applications: · Code is deployed that is incomplete and just crashes the system when executed. · Changes are made to the software without checking out the source file from the source code control system. · Every release of the software is rewritten from scratch. · Software functionality is deployed into production without the SMEs confirming that it is what they needed. [Ok, so this one happens anyway.] In this chapter I am attempting to solve the problem of requirements management, traceability and configuration management using MS Office tools. Of course no analyst worth their weight in paper would recommend using MS Office as a requirements management tool, but in reality that is what is happening. Many analysts I meet (and organizations that I have worked at) will give their analysts MS Office and expect them to maintain functional specs in Word, manage traceability either in Word or Excel, draw diagrams in Visio and produce reports with PowerPoint. In this chapter I am going to attempt to replace my IBM Rational Analyst Studio Suite, with MS Office with SharePoint Server (MOSS). The following diagram shows a simple traceability model that will be used to solve these problems. Figure 2: Simple Traceability Model[1] Traces To – Traces From – A business use case step is a type of business requirement. A business use case step resides in a BUC document. Business rules, may or may nor reside in the document, but they trace to the business use case that they impact. Similarly, supplementary requirements trace to the AUC that they impact. The application use case traces from one or more BUC steps. A BUC step only traces to a single AUC (if a BUC step is tracing to more than one AUC, then it is probably to complicated or part of it can be made into a business rule and traced to the steps). So how do we go about modifying the requirements such they reflect the ‘to-be’ enterprise model? Firstly let’s reflect on what I consider to be the definition of a business requirement. 8.1.1 The Difference Between A BUC And An AUC Business needs, (documented as business requirements) come from the business area of the organization, and not from IT. IT writes AUCs which are specific to the requirements of a particular application. (For example, a user enters a customer profile into the system and this is propagated to a Enterprise database is described by an AUC). The business does not specify which application in an Enterprise architecture, carries out what functionality. That is the IT department’s job; and as such the business requirements should not be discussing systems performing functionality. The business requirements simply state the ‘to-be’ business process, (without mentioning any name of systems or applications) and give an indication of those that have been automated and a priority as to those requirements that should be automated. The IT folks will take these requirements and in conjunction with the business SMEs, identify which business requirements will be automated by which application. IT then documents these decisions in AUCs. Getting back to the problem at hand: 8.1.2 Assumptions (or preconditions) Assume that the state of the Enterprise is as follows: · The business requirements reflect the ‘to-be’ state of the Enterprise after the next project release. · The AUCs and supporting requirements reflect the state of the enterprise architecture requirements as it is deployed into production today. [Yes, we have become lost in fantasy land at this point.] · The AUCs trace from the business requirements that they implement, so we know which AUCs are changing and what new requirements are to be implemented. [ Now that you have stop laughing ..] Let’s assume that the requirements and documents are configuration managed within MOSS. In chapter , Architecture Of The Process, I described an architecture for managing requirements with Visio, Microsoft Office and SharePoint Services (MOSS). Figure 3: Architecture Overview Use case documents are stored in Microsoft Office SharePoint Services (MOSS) as Word documents. Visio diagrams are Stored in MOSS as Visio files. Supplementary requirements are stored in MOSS as records. The following diagram shows the requirements for a requirements repository structure that may be configured within SharePoint. Figure 4: Repository Structure Requirements Diagram This diagram was drawn from a Requirements Management Plan template, which is independent of any development tools. Starting with the RequirementsRepository – to the right is a relationship that shows that it contains the CentralBusinessRepository of requirements for each business silo. The CentralBusinessRepository is a BusinessRepository for requirements, as is a BusinessProjectRelease. A BusinessProjectRelease will contain a version of the requirements in the CentralBusinessRepository. BusinessRepositories of requirements contain BusinessRequirements and Documents. Documents may contain BusinessFunctionalRequirements. Below the RequirementsRepository – is a link to the IT side of the requirements repository. There is a CentralApplicationRepository for each application. There is also an ApplicationRelease repository for versions of the application. Both ApplicationRelease and CentralApplicationRepository are types of ApplicationRepository. An ApplicationRepository contains SupplementaryRequirements and application UseCases. ChageRequests, Issues and Risks are assigned to requirements repositories as necessary. [Every organization will have their own opinion about how these are applied, or what is even their purpose.] Finally the BusinessFunctional Requirement is traced to the appropriate AUC. So now we know how everything is related, what does it all mean? If you are familiar with checkin, checkout and branching using a change and configuration management system (such as ClearCase), the concepts should be clear. There are two distinct and independent areas to consider; the Business and IT. In an enterprise environment, any business functional requirement may trace to any application in the environment, therefore I separate them. The concepts are similar in both areas, but I will address each independently. 8.1.2.1 Information Technology In the IT area each application has a central repository that always contains the requirements as they are in production today. Every time a new version of the application is required, a release repository branch is created and all of the central repository requirements are checkedout to the release repository by copying them. [Note, that we copy all the contents of application central repository into the release repository so that we never have to return back to the central repository and every requirement will be of the correct version when the scope changes, even if it never used.] Now consider 2 scenarios: · The application is already deployed – In this case the central repository needs to be populated with the AUCs that describe its functionality as it is in production today. A new branch is created from the central repository and it is populated by checking out the application’s current requirements into the new repository. Most of the time that I propose populating a central repository with its actual requirements, I get pushback from project management, asking why their funding should be used to do other peoples work (i.e. why are we writing AUCs that we will not be using)? Almost always it is agreed to only populate the central repository with the requirements needed for this release of the application. The trouble with this solution is that if it is necessary to create new requirements and another development team is also creating new requirements for the same application, (and neither development team knows that the other is working on the same application – it happens a lot) when both teams come to checkin their AUC to the central repository there is going to be a clash of inconsistencies, (and it may be that this clash is not discovered until another team tries to check out one of the AUCs for their project). If project management insists that they will only work on requirements that are necessary for their project, then I recommend that you insist that no other project team may work on the same application at the same time. · It is a new application going into production – This is not such a common event in an enterprise environment, but when it does happen there is no excuse for not populating the central repository once release 1 is deployed. Of course, even with an up-to-date central repository of requirements, it is possible for 2 development teams to work on the same functionality at the same time and come up with different requirements, but this is greatly reduced when one team knows that the other is already working with this functionality. These scenarios are described by the following activity diagram. Figure 5: Checkin/Checkout Process Diagram The precondition for this process is that some business requirements have been baselined. [Notice it does not say all of them, but we do not create a new repository for every iteration. Any subsequent iterations to this will use the same storage area to update their requirements.] The systems analysts may start analyzing the business requirements to determine their impact on each application for which they are responsible. The release area for AUCs and supporting information is created. [Note that since the central repository is for a single application, every impacted application will create its own release repository. This implies that prior to the release areas being created, some analysis must have occurred to determine which applications are impacted. See Chapter 5 on moving from BUCs to AUCs for this process.] If this is an existing application (the basic flow), then copy all of the central repository requirements to the project repository and reference the new repository from the central repository. The analysts work on the requirements until the software is deployed into production. Once the software is deployed the AUCs in the project repository are merged back into the central repository AUCs and the project repository is no longer editable. If the application is new (an alternate path), then there is no need to copy the requirements nor is there any need to merge them back once the software is deployed. That’s it. We branch from the main path by creating a repository for the requirements. We checkout the requirements, by copying them to the project repository. We checkin the requirements by merging them into the central repository. Just like we do with our source code. 8.1.2.2 Business Organization The business requirements follow a very similar process, except that the central repository does not contain the ‘as-is’ requirements, it contains the ‘to-be’ requirements. The business requirements are not organized by application; they are organized by departmental silo, (or whatever business structure is used by the organization). Just as for applications requirements when a new business project is created, a project repository is setup. The business requirements are copied to the project repository and the project is linked back to the central repository. As business requirements are passed to IT for implementation, they must be made read-only and merged into the central repository. No changes must be made to the business requirement once it is being worked by IT, without first informing IT that there is a change request to that requirement. The business project is complete, once all requirements have been made read-only and the central repository has been updated. 8.2 Implementing the Process As mentioned earlier, the only tools that I have available to me are MS Office and SharePoint Server. 8.2.1 The Hierarchy Structure The following diagram(s) show the hierarchical structure that I have setup inside SharePoint in order to house the requirements. The first diagram shows the business structure and the second the application structure. Both structures are located within the same SharePoint site. Figure 6: SharePoint Repository Hierarchy (Business) Figure 7: SharePoint Repository Hierarchy (Application) The top level SharePoint site contains 2 other SharePoint sites, 1 for the business and 1 for IT. The business repository contains 1 central repository SharePoint site for each business area (for example, Accounting, Sales, Marketing, etc). The IT repository contains a central repository SharePoint site for each application in the enterprise, (for example, SAP, Claims Management System, Line Planning Application, etc). Each central repository includes 1 or more project repositories. Each project, be it a business project or an application project is also a SharePoint site. Business repositories contain business use case documents and business rules. Business use case documents contain business use case steps. Application repositories contain AUC documents and supplementary requirements. Documents are contained within a document library. Business rules and supplementary requirements are in a list. The location indicates the URL at which each item resides. The child URL inherits all of the parent addresses preceded by a ‘/’. For example, a business functional document location URL, is /jose/business/<businesscaregory>/Business Documents/Forms/<documentName>, if in a central repository document or /jose/business/<businesscaregory>/<projectName>/businessDocuments/Forms/<documentName>, if in a project. 8.2.2 Connecting It All Together This section describes how we connect the artifacts using the available tools. The following diagrams show what artifacts are connected to each other. Figure 8: Links Between Business Requirements Artifacts In SharePoint Figure 9: Links Between IT Requirements Artifacts In SharePoint Both the BusinessRepository and the ITRepository are reached from the SharePoint site Home page. Figure 10: SharePoint Home Page The business repositories are reached by clicking the Business Requirements link; the IT repositories from the IT Application Requirements link. [Note that I have added both of these pages as tabs of the site, for ease of navigation.] Clicking on the Business Requirements link brings up a list of business areas. Figure 11: The Business Area In this example there are 2 business areas, the Matter Transporter and the Restaurant business.[2] Clicking on either link business brings up the customized home page for the business requirements. Figure 12: The Restaurants Business Home Page Each business area contains links to: Business Documents – where the business functional requirements are located. Business Rules – a list where individual business requirements are located. Projects – where completed and on-going business project artifacts are located. Change Requests – a list of proposed changes to the business. Click on the Business Documents link to bring up the business requirements documents. The business requirements documents are saved in MS Word format and opened with SharePoint when clicked. (Set the ‘Browser Enabled Documents’ setting to ‘Display As Web Page’ to open the Word documents in the web browser, which allows links to other requirements to be navigated from within SharePoint.[3]) Figure 13: SharePoint Home Page From the home page we may navigate to the Automated Restaurant or the Matter Transporter business repositories. [‘My Site’ is a personal repository that is available to all SharePoint users.] 8.2.3 Initial Deployment 8.2.4 Add A New Use Case Figure 14: Fulfill Menu Order 8.2.5 Change An Existing Use Case 8.2.6 Multiple Changes To The Same Use Case [1] To’ ‘From’ relationships may be changed by simply reversing the arrow. [2] [2] Why would a restaurant business be sharing a SharePoint site with a high tech matter transporter – I hear you ask? Because they are going to need restaurants on the moon. [3] Except that when I set the MS Word documents to display in Internet Explorer, they open with MS Word.

2. wish to change existing functionality of an AUC that has already been deployed?

3. wish to change an AUC that is already being changed by another development team?

In this chapter I discuss how to manage your AUC requirements such that all 3 scenarios are possible without breaking someone else’s work.

The processes described in this chapter are significantly complicated. Normally in order to solve these problems, I would insist upon using tools that have much of the functionality that I require built-in (management of traceability for example). Instead I will use nothing more sophisticated than MS Office with SharePoint Server (MOSS). Why? Because a significant number of analysts are using nothing more appropriate to manage their requirements today. I have worked in offices where these were the only tools I was given to work with.

This chapter starts by describing the problem, then it describes an architecture for handling the problem and then explains the details of the processes used to configuration manage the use cases.

8.1 The Problem

The initial release of an application has been deployed into production. This application is part of an Enterprise environment and therefore has interfaces to several other applications. The requirements for this application (and those that it interfaces with) come from several different business areas, each with their own set of business needs.

Now suppose that the business wishes to make some changes to the way that the business needs have been implemented. Either the business process had changed, or there is more automation that has been identified for a subsequent release. Maybe these business needs are coming from a different business organization than that which defined the original requirements. As well as changing the business artifacts, these changes could impact any of the AUCs used to capture the requirements for the initial release of the application, and they could have an impact on any interfacing application.

Figure 1: shows that changes to the way in which the database organizes it’s data, has a knock-on effect to all systems that use that data.

I like to think of application requirements, as application source code, but at a higher level of abstraction. Supposing software development organizations treated their source code as they do their requirements. Imagine the chaos there would be with their staged applications:

· Code is deployed that is incomplete and just crashes the system when executed.

· Changes are made to the software without checking out the source file from the source code control system.

· Software functionality is deployed into production without the SMEs confirming that it is what they needed. [Ok, so this one happens anyway.]

In this chapter I am attempting to solve the problem of requirements management, traceability and configuration management using MS Office tools. Of course no analyst worth their weight in paper would recommend using MS Office as a requirements management tool, but in reality that is what is happening. Many analysts I meet (and organizations that I have worked at) will give their analysts MS Office and expect them to maintain functional specs in Word, manage traceability either in Word or Excel, draw diagrams in Visio and produce reports with PowerPoint. In this chapter I am going to attempt to replace my IBM Rational Analyst Studio Suite, with MS Office with SharePoint Server (MOSS).

The following diagram shows a simple traceability model that will be used to solve these problems.

A business use case step is a type of business requirement. A business use case step resides in a BUC document. Business rules, may or may nor reside in the document, but they trace to the business use case that they impact.

Similarly, supplementary requirements trace to the AUC that they impact. The application use case traces from one or more BUC steps. A BUC step only traces to a single AUC (if a BUC step is tracing to more than one AUC, then it is probably to complicated or part of it can be made into a business rule and traced to the steps).

So how do we go about modifying the requirements such they reflect the ‘to-be’ enterprise model?

Firstly let’s reflect on what I consider to be the definition of a business requirement.

8.1.1 The Difference Between A BUC And An AUC

Business needs, (documented as business requirements) come from the business area of the organization, and not from IT. IT writes AUCs which are specific to the requirements of a particular application. (For example, a user enters a customer profile into the system and this is propagated to a Enterprise database is described by an AUC).

The business does not specify which application in an Enterprise architecture, carries out what functionality. That is the IT department’s job; and as such the business requirements should not be discussing systems performing functionality. The business requirements simply state the ‘to-be’ business process, (without mentioning any name of systems or applications) and give an indication of those that have been automated and a priority as to those requirements that should be automated.

The IT folks will take these requirements and in conjunction with the business SMEs, identify which business requirements will be automated by which application. IT then documents these decisions in AUCs.

8.1.2 Assumptions (or preconditions)

· The business requirements reflect the ‘to-be’ state of the Enterprise after the next project release.

· The AUCs and supporting requirements reflect the state of the enterprise architecture requirements as it is deployed into production today. [Yes, we have become lost in fantasy land at this point.]

· The AUCs trace from the business requirements that they implement, so we know which AUCs are changing and what new requirements are to be implemented.

Let’s assume that the requirements and documents are configuration managed within MOSS.

In chapter , Architecture Of The Process, I described an architecture for managing requirements with Visio, Microsoft Office and SharePoint Services (MOSS).

Use case documents are stored in Microsoft Office SharePoint Services (MOSS) as Word documents. Visio diagrams are Stored in MOSS as Visio files. Supplementary requirements are stored in MOSS as records.

The following diagram shows the requirements for a requirements repository structure that may be configured within SharePoint.

This diagram was drawn from a Requirements Management Plan template, which is independent of any development tools.

Starting with the RequirementsRepository – to the right is a relationship that shows that it contains the CentralBusinessRepository of requirements for each business silo. The CentralBusinessRepository is a BusinessRepository for requirements, as is a BusinessProjectRelease. A BusinessProjectRelease will contain a version of the requirements in the CentralBusinessRepository. BusinessRepositories of requirements contain BusinessRequirements and Documents. Documents may contain BusinessFunctionalRequirements.

Below the RequirementsRepository – is a link to the IT side of the requirements repository. There is a CentralApplicationRepository for each application. There is also an ApplicationRelease repository for versions of the application. Both ApplicationRelease and CentralApplicationRepository are types of ApplicationRepository. An ApplicationRepository contains SupplementaryRequirements and application UseCases.

ChageRequests, Issues and Risks are assigned to requirements repositories as necessary. [Every organization will have their own opinion about how these are applied, or what is even their purpose.]

So now we know how everything is related, what does it all mean? If you are familiar with checkin, checkout and branching using a change and configuration management system (such as ClearCase), the concepts should be clear. There are two distinct and independent areas to consider; the Business and IT. In an enterprise environment, any business functional requirement may trace to any application in the environment, therefore I separate them. The concepts are similar in both areas, but I will address each independently.

8.1.2.1 Information Technology

In the IT area each application has a central repository that always contains the requirements as they are in production today. Every time a new version of the application is required, a release repository branch is created and all of the central repository requirements are checkedout to the release repository by copying them. [Note, that we copy all the contents of application central repository into the release repository so that we never have to return back to the central repository and every requirement will be of the correct version when the scope changes, even if it never used.]

· The application is already deployed – In this case the central repository needs to be populated with the AUCs that describe its functionality as it is in production today. A new branch is created from the central repository and it is populated by checking out the application’s current requirements into the new repository. Most of the time that I propose populating a central repository with its actual requirements, I get pushback from project management, asking why their funding should be used to do other peoples work (i.e. why are we writing AUCs that we will not be using)? Almost always it is agreed to only populate the central repository with the requirements needed for this release of the application. The trouble with this solution is that if it is necessary to create new requirements and another development team is also creating new requirements for the same application, (and neither development team knows that the other is working on the same application – it happens a lot) when both teams come to checkin their AUC to the central repository there is going to be a clash of inconsistencies, (and it may be that this clash is not discovered until another team tries to check out one of the AUCs for their project). If project management insists that they will only work on requirements that are necessary for their project, then I recommend that you insist that no other project team may work on the same application at the same time.

· It is a new application going into production – This is not such a common event in an enterprise environment, but when it does happen there is no excuse for not populating the central repository once release 1 is deployed. Of course, even with an up-to-date central repository of requirements, it is possible for 2 development teams to work on the same functionality at the same time and come up with different requirements, but this is greatly reduced when one team knows that the other is already working with this functionality.

The precondition for this process is that some business requirements have been baselined. [Notice it does not say all of them, but we do not create a new repository for every iteration. Any subsequent iterations to this will use the same storage area to update their requirements.]

The systems analysts may start analyzing the business requirements to determine their impact on each application for which they are responsible. The release area for AUCs and supporting information is created. [Note that since the central repository is for a single application, every impacted application will create its own release repository. This implies that prior to the release areas being created, some analysis must have occurred to determine which applications are impacted. See Chapter 5 on moving from BUCs to AUCs for this process.]

If this is an existing application (the basic flow), then copy all of the central repository requirements to the project repository and reference the new repository from the central repository.

The analysts work on the requirements until the software is deployed into production. Once the software is deployed the AUCs in the project repository are merged back into the central repository AUCs and the project repository is no longer editable.

If the application is new (an alternate path), then there is no need to copy the requirements nor is there any need to merge them back once the software is deployed.

That’s it. We branch from the main path by creating a repository for the requirements. We checkout the requirements, by copying them to the project repository. We checkin the requirements by merging them into the central repository. Just like we do with our source code.

8.1.2.2 Business Organization

The business requirements follow a very similar process, except that the central repository does not contain the ‘as-is’ requirements, it contains the ‘to-be’ requirements.

The business requirements are not organized by application; they are organized by departmental silo, (or whatever business structure is used by the organization).

Just as for applications requirements when a new business project is created, a project repository is setup. The business requirements are copied to the project repository and the project is linked back to the central repository.

As business requirements are passed to IT for implementation, they must be made read-only and merged into the central repository. No changes must be made to the business requirement once it is being worked by IT, without first informing IT that there is a change request to that requirement.

The business project is complete, once all requirements have been made read-only and the central repository has been updated.

8.2 Implementing the Process

As mentioned earlier, the only tools that I have available to me are MS Office and SharePoint Server.

8.2.1 The Hierarchy Structure

The following diagram(s) show the hierarchical structure that I have setup inside SharePoint in order to house the requirements. The first diagram shows the business structure and the second the application structure. Both structures are located within the same SharePoint site.

The top level SharePoint site contains 2 other SharePoint sites, 1 for the business and 1 for IT.

The business repository contains 1 central repository SharePoint site for each business area (for example, Accounting, Sales, Marketing, etc).

The IT repository contains a central repository SharePoint site for each application in the enterprise, (for example, SAP, Claims Management System, Line Planning Application, etc).

Each central repository includes 1 or more project repositories. Each project, be it a business project or an application project is also a SharePoint site.

Business repositories contain business use case documents and business rules. Business use case documents contain business use case steps.

Documents are contained within a document library. Business rules and supplementary requirements are in a list.

The location indicates the URL at which each item resides. The child URL inherits all of the parent addresses preceded by a ‘/’. For example, a business functional document location URL, is /jose/business/<businesscaregory>/Business Documents/Forms/<documentName>, if in a central repository document or

/jose/business/<businesscaregory>/<projectName>/businessDocuments/Forms/<documentName>, if in a project.

8.2.2 Connecting It All Together

This section describes how we connect the artifacts using the available tools. The following diagrams show what artifacts are connected to each other.

Both the BusinessRepository and the ITRepository are reached from the SharePoint site Home page.

The business repositories are reached by clicking the Business Requirements link; the IT repositories from the IT Application Requirements link. [Note that I have added both of these pages as tabs of the site, for ease of navigation.]

In this example there are 2 business areas, the Matter Transporter and the Restaurant business.[2]

Clicking on either link business brings up the customized home page for the business requirements.

Projects – where completed and on-going business project artifacts are located.

Click on the Business Documents link to bring up the business requirements documents.

The business requirements documents are saved in MS Word format and opened with SharePoint when clicked. (Set the ‘Browser Enabled Documents’ setting to ‘Display As Web Page’ to open the Word documents in the web browser, which allows links to other requirements to be navigated from within SharePoint.[3])

From the home page we may navigate to the Automated Restaurant or the Matter Transporter business repositories. [‘My Site’ is a personal repository that is available to all SharePoint users.]

8.2.3 Initial Deployment

8.2.4 Add A New Use Case

8.2.5 Change An Existing Use Case

8.2.6 Multiple Changes To The Same Use Case

[1] To’ ‘From’ relationships may be changed by simply reversing the arrow.

[2] [2] Why would a restaurant business be sharing a SharePoint site with a high tech matter transporter – I hear you ask? Because they are going to need restaurants on the moon.

[3] Except that when I set the MS Word documents to display in Internet Explorer, they open with MS Word.