Bespoke Software Development

Software development is the process of creating a bespoke software application to meet the requirements as set out by the domain expert in a requirements document.

A bespoke software project is tested against requirements analysis documentation and must therefore be detailed and measurable so that the software can be tested against it.

Requirements documentation will typically contain a list of requirements that can then be measured and ticked when completed. This is particularly important for contract based IT outsourcing. It is also important when designing software to identify all the stakeholders of the system, because a new software system can have a knock on effect on other systems.

The requirements specification stage is an important part of bespoke software solutions because it determines what is needed from the new ecommerce system.

A requirements analyst or custom application development team can obtain information from the domain expert by "prototyping" and "use cases".

A 'use case' analysis is used to identify the usage requirements and to identify the functional requirements of a bespoke software system. This will help to define the classes of actors (end user or hardware) and processes to put into a use case diagram. It is the foundation of most bespoke software development solutions.

The interaction between an actor and the system is viewed from the perspective of the actor so that the system itself remains a black box. Actors exist outside this black box but take part in the sequence of events with it in order to achive the result.

To gather the requirements of a new bespoke software solution, a use case analysis starts off by specifying the system's framework such as its actors (online shop customer) and processes (payment), classes of actors and processes (A Sale), and data used by them (product details).

Then the behaviour of the system from the perspective of the actor is described and grouped into classes but without going into the internal workings of the black box.

Once the classes or groups of actors and processes that are needed by the system are identified, the relationships between those classes then need to be identified and the interation between them. Each class (eg customer, product, payment) must have a task to complete that no other class in the system is responsible for so that there is no overlap. Sometimes one class can be related to a class many times such as a customer might buy many products from an ecommerce website. The one to many relationship between the website customer class and the product class need to be specified. Each class' attributes need to be identified, for example a product will have a name, a customer an address. Finally the components such as exception handling and process communication are identified for the overall problem domain.

Each use case is a complete series of events and a system can have many use cases. A UML Diagram can help to graphically model many use cases. Use cases are represented as ovals and the system is encapsulated in a box with the actors located outside it. Actors have no interaction but there are three types of relationships between use cases.

1) A use case can use another use case. The first use case depends on the outcome of the included use case identified by a dashed arrow from the including use case to the included use case with the label <>. For example a customer purchase in an online shop website includes the use case of validating the customer's purchase details.

2) Extending interation between use cases is when one use case extends another use case so that the behaviour of one use case is inserted in another use case such that one use case is a special case of another use case. This is represented with a dashed arrow from the extensible use case to the extended use case with the label <>. For example, the validation include use case of a customer purchase use case can be extended by an exception handling use case that performs error logging.

3) A generalisation relationship between use cases is when a use case is derived from a more generalised use case, identified with a hollow arrow from the specialised sub class use case to the more general use case. For example a customer purchase use case is a generalisation of taking payment from the customer and depositing payment to the online shop website owner.

Use case analysis is not well suited to non functional requirements which are not measurable and describe quality of systems such as the ease of use of the user interface Non functional requirements are determined by presenting the end user with prototype software so that the actor can get an idea of the look and feel of the system and provide the necessary feedback for example.