CS302: Software Engineering (2021.B.01)

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 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 the 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 categorized as 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
R1.1	Record the underway (current) sale - the items purchased	evident
R1.2	Calculate current sale total	evident
R1.3	Capture purchase item information from a barcode using a barcode scanner or manual entry of a product code such as a universal product code (UPC)	evident
R1.4	Reduce inventory quantities when a sale is committed	hidden
R1.5	Log completed sales	hidden
R1.6	Cashier must log in with an ID and password in order to use the system	evident
R1.7	Provide a persistent storage mechanism	hidden
R1.8	Provide inter-process and inter-system communication mechanisms	hidden
R1.9	Display description and price of item recorded	evident

Table 3.3: Payment functions of the POST System

Ref #	Function	Category
R2.1	Handle cash payments, capturing amount tendered and calculating balance due	evident
R2.2	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.	evident
R2.3	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.	evident
R2.4	Log credit payments to the accounts receivable system, since the credit authorization services owes the store the payment amount.	hidden

 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 its 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 

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
fault-tolerance	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.