April Repost: Requirements Analysis

Time for our monthly blast from the past. Below is a five year old article which I believe is timeless, especially in times of Siebel Open UI (scripting). Please enjoy...

(Note: Links have been slightly updated)

***

This is a follow-up post (and the first in a semi-series) on the scriptless Siebel challenge.

Question: Why is so much script code written in Siebel projects?

Possible answers (not a complete list, add your own...):

• Developers are used to write code (we have been coding since Siebel 99, haven't we?).
• Workflow, Business Rules, etc are nice but they are difficult to learn/manage and we don't have time to evaluate solutions.
• Architects and developers don't know that alternatives exist.

As we all agree, the best time to avoid writing custom code in standard enterprise applications is design time. So it's the responsibility of the business analyst or technical architect to design a code-free solution for a given requirement.

Back in the Siebel days (and also today in Oracle days) we spent a lot of time and effort to develop and deliver trainings for business analysts. During these trainings we teach a process based approach to gather and analyse requirements. A business analyst or technical architect involved in a Siebel CRM project needs many skills. Analytical thinking, process orientation and a strong knowledge of the product features is key to a successful design phase.

You might want to read more about business process analysis here and here.

Starting with the high-level process, the business analyst should collect the information and requirements for each step of the process. As the requirements become more detailed, they have to be analyzed whether the standard application ("vanilla", "out-of-the-box") meets those requirements.

We can depict a process for analyzing requirements as follows:

You can minimize the amount of script code dramatically when you apply this simple decision process to any functional requirement.

1. Evaluate whether the requirement can be met by using out-of-the-box (OOB) functionality.
   Examples: Export data to Excel (List Applet), modify the tab layout (User Preferences), save records as a template for others (Quick Fill Templates), predefined queries to name but a few.


2. If there is no OOB solution (a gap situation), there is a high probability that you will find an administrative way to modify the application behavior.
   Examples: Audit Trail, State Model, Activity Templates, Business Rules, Data Validation Manager, Personalization, Runtime Events and everything else you can manage using the administrative screens.


3. There are still many requirements left which you can meet by declaratively configuring the application using Siebel Tools.
   Examples: Create/modify applets, views and screens; set default values; define user properties; create workflows, etc.


4. The (possibly very small) remainder of the requirements can be met by adding the missing functionality by writing script code. The best possible place for your code are business services. Applying industry best practices and using standard business services wherever possible limits the amount of script code that you will have to manage.

have a nice day

@lex