Structure Of An Analysis Specification

Published Date: 02 Nov 2017

The analysis stage of system development begins with a period of fact finding during which the system developer investigates the current system. The aims of the analysis stage of object-oriented system development are:

To determine the scope of the system and establish the business case for developing it, including risk assessment and criteria for success

To establish an agreed set of requirements

To identify a set of objects that will fulfill these requirements

To describe the attributes and observable behavior of these objects

To identify relationships and patterns of communication between objects

To chronicle events which may occur n the system and describe the way in which the objects may be affected by these events.

The physical deliverable from the analysis stage of object-oriented developments is a validated specification of requirements which has been agreed with the client and which contains the initial class diagram and dynamic models of the system.

2.1.1 Requirement engineering

The term requirements engineering refers to the collection of tasks that identify, record and validate the requirements for the system. Each requirement is a statement, originating from a client, user or other stakeholder, that defines some desired feature of the system.

As defined in requirements engineering, functional requirements specify particular results of a system. Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system. Functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Generally, functional requirements are expressed that the system must do that requirement, while non-functional requirements are expressed that the system should do that requirement.

Functional requirements

Functional requirements state what the system was to do, what its inputs and outputs were and how these were linked. A functional requirement defines a function of a software system or its component. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Functional requirements are supported by non-functional requirements which impose constraints on the design or implementation (such as performance, security, reliability). The plan for implementing functional requirements is detailed in the system design.

Non-functional requirements

Non-functional requirements can be divided into non-functional requirements of the system and non-functional requirements arising from external sources. Non-functional requirements of the system will include issues such as usability, performance, reliability and security.

Non-functional requirements that arise from external sources include methods of operation, such as the client’s existing procedures; physical constraints, such as the layout of the accommodation available; international quality control standards and constraints relating to costs or the system delivery date. The plan for implementing non-functional requirements is detailed in the system architecture.

2.1.2 Use Case

Among the different views of a system, the use case view describes the externally visible behavior of the system. The use case describes the use case view. The use case view establishes the forces that will drive and constrain subsequent development. The use case view presents a structured view of a system's functionality. It does this by defining a number of actors which model the roles that users can play when interacting with the system, and describing the use cases that those actors can participate in. The use case view contains a set of use cases, which should define the complete functionality of the system, or at least the functionality defined for the current iteration, in terms of the tasks that can be achieve with tis help.

A use case diagram is a list of steps, shows actors and use cases together with various relations between them, to achieve a goal. The use case describes a specific task that a user can achieve with the system. Use cases are different tasks that a system's users can perform using the system.

One use case can include another, this means that the interaction specified by the included use case form part of every performance of the including use case. One use case can extend another; this means that the interaction specified by the extending use case forms an optional part of a performance of the extended use case.

An actor represents a role that a user can play when interacting with a system. Actors are associated with use cases, showing which tasks users in a given role can perform. Actors can be related by generalization, to make explicit their shared capabilities.

2.1.3 Architecture

System architecture

A system architecture or systems architecture is the conceptual model that defines the structure, behavior, and more views of a system.

An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structure of the system which comprises system components, the externally visible properties of those components, the relationships (e.g. the behavior) between them, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. The language for architecture description is called the architecture description language (ADL).

Human-Computer Interface

Human–computer Interaction (HCI) involves the study, planning, and design of the interaction between people (users) and computers.

Initial class diagram

A class diagram shows the classes within a model. It illustrates which classes interact but not what happens when they do. A class diagram provides a static view of the system, defining the static relationships between classes.

The initial class diagram can be produced using the results of the CRC process. Remember the CRC process will produce a candidate classes with assigned responsibilities and collaborations. We can initially draw all of these classes on a diagram with simple links between classes to represent collaborations.

2.2 Content of an analysis specification

2.2.1 Requirements engineering

Functional requirements

Customer must:

Register user information

Check username whether it is existing

Have a valid bank account

Log In to buy a car

Choose payment method

Receive voucher to ensure order success

Agree legal terms for security and privacy

Manager must:

Create correct car information

Update appropriate car information

Delete when the car had bought

Confirm payment

Generate voucher after payment success

Non-functional requirements

Customer should:

Connect with bank for payment

Manager should:

Create staff registration

Log in to access the system

Advertise other car websites

2.2.2 Use Cases

2.2.3 Architecture

System Architecture

Initial Class Diagram