Difference between revisions of "System Definition"

From EUDP
Jump to: navigation, search
(Why)
(What)
Line 1: Line 1:
 
== What ==
 
== What ==
  
System Definition -  summary of the new system.  
+
System Definition -  summary of the new system-to-be.
  
 
== How ==
 
== How ==

Revision as of 07:59, 30 July 2012

What

System Definition - summary of the new system-to-be.

How

The dish

System definition

Ingredients

Process

Summarise the present understanding of the IT system-to-be in a few sentences (max. ¾ of a page is needed). Try to integrate the customer's main values into the system definition.

It is recommended to prepare more than one system definition with different philosophy views and let the customer choose the one that fits best into his expectations.

Why

The system definition is a short description of the system-to-be that is going to be developed. It is the first description of the system according to the developer's understanding of the requirements. It follows the rich picture which has been drawn in cooperation with the customer.

The system definition is a good way to communicate to the customer how we have understood the system-to-be. Remember the development process is still in its early stages and the developer still needs to acquire a basic understanding of which type of system the customer wants. By describing the requirements in a relatively short summary (max. ¾ of a page), the developer can communicate his or hers perception of the system.

Not only is it vital that the system definition encapsulates the essence of the system, but just as important, it is that the system definition also indicates the boundary of the system, and from here it is obvious what is NOT a part of the system. Hereby the forthcoming tasks and analysis can focused to target the essentials, the system-to-be.

It is important to incorporate the customer's values in the product, therefore the system definition can be written in several versions, each differing by the way you express the customer's values, and thereby the philosophy in the product.

The customer's values may not be clearly stated, and there may be different employee values at the customer's company. The sales department may have different values and opinions about the new product than the research and development (engineering) department. The management may have values that differ from all other departments. Sales may want a product that have some smart easily saleable functions that may not be of any technical value for the engineering people who want a product with high technical functions. The management's interest is mainly a saleable product that solves the problem at the lowest possible cost.

Therefore, the developer should perform an analysis of the different parties interested in the project - the so-called stakeholders. The analysis can provide the developer with information about the different kinds of interest in the project. This knowledge should be kept in mind through out the lifetime of the project.

Example

SystemDefinitionEx.png