When a new software system needs to be developed, the first thing off course is the user requirements. Based on user requirements, a system model needs to be developed. This is where the software system design is done. When you design the system you need to keep some important things in your mind.
Types of users
Enterprise or web based systems have many types of users who will be using the system for various purposes. For example, you can have inventory clerks, warehouse managers, MRP controllers, picking & packing staff etc. if the system you are developing is to be used for a warehouse. Each of these types of users will be using the system for different purposes. For example, the warehouse managers will be more concerned about warehouse reports so that they can manage and plan the warehouse effectively. The MRP controllers will be concerned with stock levels, safety stocks etc. so that they can plan for creating purchase requisitions. The inventory clerks will be concerned with accurately accounting for all incoming, outgoing and in stock goods. You need to provide features which are suitable for each type of user. At the same time you also need to ensure that each type of user has proper authorization so that they can get access to the system securely.
The software model you build should be robust, easily navigable, user friendly and consistent. If your system is going to be heavily transaction oriented (like the warehouse system) then you must ensure that transactions are fail safe. I have seen so many systems which are difficult to navigate or crash or having very cumbersome user interfaces. For this reason it is very important that during modeling time, the architecture, security model, user interface model etc. should be done properly. if it is not done at this stage then the software built will fail in either of the contexts mentioned above.
Top to bottom & bottom to top
Initially as users as well as system designers are not aware of detailed functionality of the software system, a top to bottom system design should be done. first the top level functionality should be designed like the main features of the system. Only then as more information is available about detailed features, you can design these smaller components which will be part of your larger features.
This means that first you create an skeleton of your system and then add smaller features around parts of your skeleton.
Generally at high level meetings, demonstrating fully featured model of your system is not a good idea. It is because most people will not understand the complicated parts of your model. In these meetings, it is better to show high level model of your system. You can later show detailed models to specific users who will be using specific features of the system. Showing everything to everybody will never work.