Identifying Needs

As we begin the work of creating a portal and determining what’s right for our organization, we need to gather information about why we want to utilize it.  We’ll gather functional and technical details that will give us a clear view of effort required to create and support our portal. This stage can be considered identifying portal needs. The identification stage can be as detailed as we’d like it to be, but our goal is to generate a vague picture of what we’ll need and identify any large technical constraints that may become an issue during our design stage.

Gathering portal requirements

We can break our portal requirements effort into a few topical goals.  Those topics are the Business Process, Data Domain, and Security.

Business Process
The business process is the flow of how we expect a user to navigate an action or process with the company.  Creating a mock-up or flow diagram of these interactions that a user will experience will help us to understand not only the look of our portal later, but also help us identify data and security needs.  If your company already has documentation in the form of mock-ups or flow diagrams, these can be utilized in your efforts.  Efficiency and accuracy in the development of the portal from this point forward rely on the fact that the business processes are outlined correctly.  This is also a good time to start identifying the different types of users that may interact with your portal.  Processes may differ depending on their role inside or outside the organization.

Data Domain
Now that we have an idea of how our business expects to operate with users, we need to understand the data that we’ll be exposing to them.  Identification of this requirement includes not only determining what data is needed but also where that data is stored and any possible controls that we may need to operate with.  For instance, imagine a scenario where you maintain customer information within CRM but have several proprietary or third-party tools that contain specific business data about them.  In this scenario, not only will we need to have access to CRM data but to other systems as well. During this stage, we should also identify how unique data stores are related.  In the example above, we recognized that customer data was separate from other systems, but we also need to understand how we can relate that customer data in a useful manner.  Does the customer data share a key value between the data stores?  Will we need to create those relationships as part of our portal development?

Security and Where Your Users Reside
Finally, you’ll need to understand your user base.  Users for portals can be internal or external, users or clients and a wide variety of other configurations.  Identifying where your users live will help to identify security requirements as well as some business process.  For instance, a client and support engineer might both utilize the same access process to gather or create case information, but they may have different nuances to each of the access pages that they see.

The next section of this book will cover portal design.