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 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
"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
Tables 3.2 and 3.3 show functional requirements for the POST system (Liu, 2001).
Table 3.2: Basic functions of the POST system
||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
||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 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.
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.
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.
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").
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)
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.
||When recording a sold item, the description and price will appear within 5 seconds
||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.