SharePoint Analysis and Design Tips.

Object-Oriented Analysis and Design is a relatively mature technique. We call it Object-Oriented because the technique is to implement various requirements with objects in code. Likewise, In SharePoint Analysis and Design, we map requirements to SharePoint components such as web parts, lists, document libraries, views, site columns, content types, page layouts, info path forms, application pages, excel services, business catalogs, user profiles, my sites, site maps and so on.

The article is not to establish a methodology. It tries to explain a couple of experiences that may help in SharePoint Analysis and Design.

1. Map business requirements to technical solution as early as possible.

In object-oriented design, separating business domain requirements and technical solutions is a good practice. Technical solutions should not impact collecting business requirements if possible. However, this separation of requirement and solution is what SharePoint Analysis and Design should avoid. Considering technical solution at early stage will provide the following benefits:

• Make business users aware what cannot be done with SharePoint's out-of-box features. Business users expect SharePoint to do Anything through configuration, but custom development is inevitable for most of the enterprise-level MOSS applications. Custom development demands more efforts, and we need to inform those efforts to customers as early as possible.


• Give SharePoint developers the opportunities to explain the out-of-box features that will meet or exceed the same business goals with different business processes. For example, the business goal of sharing knowledge and experience among employees can be archived by using out-of-box wiki library. Therefore, the original use cases collected from customers for achieving the same business goal will be altered according to the wiki libraries' behavior.

2. Strive for configurable/customizable solutions.

SharePoint allows end users to customize solutions without going through development cycles. End users may customize lists, document libraries, site pages, site master pages, define security groups and permission levels, etc; They may publish InfoPath forms and excel sheets, and create ad-hoc reports and dashboards using PerformancePoint. To take advantage of those features while designing SharePoint solution, consider separate the responsibilities of developers and end users. Both end users and developers have the responsibilities to contribute to SharePoint solutions. For example, in an InfoPath form, developers implement the web services for InfoPath to connect to and configure the SSO application while end users are responsible to create the InfoPath connections to the web services using SSO authentication. The relationship between developers and end users is very much like how frameworks' developers are related to the developers who use the frameworks. Basically, developers should deal with more difficult tasks and expose their work through interfaces to end users. The interfaces in SharePoint context, which is very different from the .NET interfaces, are in the formats of InfoPath connection, SSO, Content Type, Page Layout, etc.