Object-Oriented Analysis

Analysis emphasizes an investigation and understanding of the problem domain and requirements, rather than a solution. Read this section to learn more about some of the terms and concepts related to requirements and their types. These terms can seem ambiguous at first, but we will quickly learn how they relate to one another.

3. An Overview of the Project

Functional requirements

Functional requirements describe interaction between a system and its environment. Describe how a system should behave under certain stimuli. Liu, (2001) argue that to verify that some X is indeed a system function, it should make sense in the following sentence:

"The system should do < XX>" The system's function should be categorized in order to prioritize them or to avoid from missing them. Categories include: 

1. Evident functions whereby the requirement will be performed and recognized by the user.

2. Hidden functions whereby the requirement will be performed by the system, but not visible to users. Examples of hidden functions can be "save information in a persistent storage mechanism". It has been noticed that hidden functions are often forgotten hence missed during the requirements gathering process.

System functions can be presented as shown in template given in Table 3.1. They should be divided into logical cohesive (interrelated/organized) groups. Each function should be given a reference number that can be used in other documents of the development. A function should be category in either "evident" or "hidden".

Table 3.1: Template for Presenting Functional Requirements

Ref # Function Category

Tables 3.2 and 3.3 show functional requirements for the POST system (Liu, 2001).

Table 3.2: Basic functions of the POST system

Ref # Function Category
Record the underway (current) sale - the items purchased
Calculate current sale total
Capture purchase item information from a bar code using a bar code scanner or manual entry of a product code such as a universal product code (UPC)
Reduce inventory quantities when a sale is committed
Log completed sales
Cashier must log in with an ID and password in order to use the system
Provide a persistent storage mechanism
Provide inter-process and inter-system communication mechanisms
Display description and price of item recorded

Table 3.3: Payment functions of the POST System

Ref # Function Category
Handle cash payments, capturing amount tendered and calculating balance due
Handle credit payments, capturing credit information from a card reader or by manual entry, and authorizing payment with the store's (external) credit authorization service via a modem connection.
Handle cheque payments, capturing driver's license by manual entry, and authorizing payment with the store's (external) cheque authorization service via a modem connection.
Log credit payments to the accounts receivable system, since the credit authorization services owes the store the payment amount.

 Requirements are expected to have the following characteristics:

(a) Verifiable: 

A requirements document often becomes part of the contract between a client and a system developer. It describes what the developer will deliver and be paid for. Requirements should be verified against requirements, i.e. to check if the software meets the requirements. 

(b) Complete 

The requirements should be complete, and not leave out any areas. This can be very hard to achieve, especially in large systems. Current trends are to break the development up into smaller modules and implement each of them.

(c) Unambiguous 

A requirement is ambiguous if it has more than one possible meaning. May be ambiguous due to poor choice of words and/or differing definitions of a word or phrase.

(d) Consistent 

All parts of the requirements document should be consistent with each other. They should not contradict each other (the following do: "If you delete a task all of its subtasks should be deleted automatically" "You should always be prompted to confirm the deletion of a task and any of it's subtasks"). 

(e) Modifiable 

The requirements should be structured so that it is possible to change it at little to no cost. Requires it be structured carefully, e.g. separating functional from non functional requirements, supplying a glossary (a table of definitions) 

(f) Traceable

The requirements should be structured so that it is possible to uniquely identify each requirement 

  • Each one should have a unique number 
  • This allows it to be referred to in final testing of the delivered software, and in discussions with a client.

(b) Non-Functional Requirements 

System non-functional requirements of system, also known as system attributes, are constraints imposed on the services or functions offered by the system. System attributes define how a system is supposed to behave and they are often called qualities of the system. They are being applied to the system as a whole. Examples are; usability, cost, reliability, response time, performance, ease of use, security, compatibility, fault-tolerance, and so on. 

You can't write a specific line of code to implement non-functional requirements; rather they are "emergent" properties that arise from the entire solution.

Table 3.4 shows examples of non-functional requirements for the POST system.

Attribute Constraints
response time
When recording a sold item, the description and price will appear within 5 seconds
interface metaphor
Forms-metaphor windows and dialog boxes
Must log authorized credit payments to accounts receivable within 24 hours, even if power or device fails
operating system platform
Microsoft Window 95 and NT

Non-functional can be classified into:

(a) Product requirements 

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. 

(b) Organisational requirements 

Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. 

(c) External requirements 

Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.