Understanding the case

In the previous chapter we discussed a number of fundamental properties and principles about Systems. In this chapter we will look at another fundamental system design which is used in many systems today. What we will do is that I will design an Information system and you will evaluate it.

Case - Passenger Railway Reservation System

For me to discuss this fundamental design, let's design a passenger railway reservation system. I am taking this case for two reasons. One because Railway reservation system is a highly complex system and second most of us is aware of this system and the corresponding rules. So let's start applying all the principles that we have learnt till now.

System Boundary

The moment we are given a task of designing a system, the first thing that we need to do is draw the "System Boundary".To draw the System Boundary you will need to first find out the Context from which the system needs to be viewed.System Boundary, although looks very simple, but is very important to the Architect or the Designer.

Can you think about the significance of the System Boundary to the Architect/Analyst?

The System Boundary helps the designer understand what is internal to the system and what is external to the system.

Why is it important to understand what is internal and what is external to the system?

Everything that is Internal to the system is under the Designer's control and is easy to design while everything that is External to the system is beyond the control of the designer. If the internal system details are dependent on the external systems, then the design decisions may get influenced by the external systems.The System Boundary is like the BODMAS in arithmetic. You need to go in the right sequence so as to retain the actual meaning of the expression.We will discuss more about System Boundary when we deal with the case study of designing a financial portal.

To find the System Boundary, first get the context right.


In this case we will look at Indian Railways as a system from the context of Passenger Railway Reservation System.

Once we know the context, we need to find out the behaviors delivered by the system within this context.

The following are the behaviors offered by a Railway Reservation System:

  • Reserve a Ticket.
  • Cancel a Ticket.
  • Postpone a Ticket.
  • Check the availability of the Ticket, etc.

There are many more behaviors but we will consider only the above ones for the sake of discussion.




Once we know the behaviors the next thing we need to find out is all the Actors who will interact with the System and get value out of it.

The following are the actors of this system:

  • Railway Reservation Clerk (RRC)
  • Travel Agent (TA)
  • Online User (OLU)


Once we have found out the Actors, remember that not every other actor is supposed to use all the behaviors and functionalities of a system.

Hence we should find out from the customer as to which are the Actors who can use a particular functionality within the proposed system.

This is called as "Mapping" the users to the different functionalities / behaviors of the system.

Although the mapping rules can be in accordance to the business rules defined by the customer, but for the sake of simplicity, let's say that the RRC can invoke all the behaviors while the TA can use the first couple of behaviors while the OLU can use the first four behaviors.


All this was a part of behavioral modeling.

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer