Object-Oriented Analysis

1. What are Requirements

Requirements as defined by Liu (2001) are a description or statement of a function, feature or condition that a user seeks to have implemented in a system. A requirement is:

1. A function that a system must perform

2. A feature of the system or a description of something the system is capable of doing in order to fulfil the system's purpose.

3. A statement about the proposed system that all stakeholders agree that must be true in order for the customer's problem to be adequately solved.

The creation of correct and thorough requirements specification is essential to a successful project. We use a case study (Point-of-Sale) to illustrate the following three problems.

1. What should be produced in the requirements capture and analysis?

2. How to identify the elements of these artifacts?

3. How are artefacts expressed?

Source: Ellen Ambakisye Kalinga, https://oer.avu.org/bitstream/handle/123456789/667/CSI%203104_EN%20Object%20Oriented%20Analysis%20and%20Design1.pdf?sequence=1&isAllowed=y
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

2. Requirement Specification

Requirements documentation is a very important activity, which is written after the requirements elicitation/gathering and analysis, i.e. requirement capture and analysis phase of the software development process. This is the way to represent requirements in a consistent format. The requirements document is called the Software Requirements Specification (SRS). The SRS is a specification for a particular software product, program, or set of programs that perform certain functions in a specific environment.

The requirements specification is a description of needs or desires for a product. It is the official statement of what is required of the system developer. The requirements must be described unambiguously and in a form that clearly communicates to the client and to the development team members.

It is not a design document and it must state what to be done rather than how it is done. It must be in a form which can be taken as the starting point for the software development. A specification language is often used. Graphical notations are often also used to describe the requirement specification.

It is recommended that the requirements specification at least include the following information:

i. An overview of the project

ii. Goals/purpose

iii. Glossary – definition all relevant terms

iv. System functions

System functional requirements, these are functional requirements
System attributes (non-functional requirements)

v. Use cases – narrative descriptions of the domain processes

vi. Conceptual model – a model of important concepts and their relationships in the application domain.

These are typically produced through gathering and digesting

i. Documented information such as the client's statements about their needs, preliminary investigation report, and electronic documents,

ii. interview results,

iii. requirements definition meetings, and so on

3. An Overview of the Project

This is a sentence which gives the purpose of the project. This should describe the need for the system. e.g.

The project intends to create a standalone system for ……………….

Goals

The purpose of this project is to create a point-of-sale terminal system to be used in retail sales. This is to describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.

The goals of the POST system can be stated as:

In general the goal is increased checkout automation, to support faster, better and cheaper services and business processes. More specifically, these include:

Quick checkout for the customer,
Fast and accurate sales analysis,
Automatic inventory control.

Note: The overview and the goals can be combined into an introduction section in the document.

3.1. Glossary

Glossary is the definition of all relevant terms and concepts. It provides the clarification of ambiguous terms and concepts, explanations of jargons, as well as the description of business events or description of software actions. There is no specific format for glossaries and they can be included when needed.

3.2. System Functions

Requirements are the capabilities to which the system has to conform. Requirements are captured in terms of the system functions; hence system functions are requirements the system is supposed to do. There are two broad categories of requirements:

Functional Requirements

Are those that relate directly to the functioning of the system.

These are the aspects of the system the client is most likely to recognize.

Non-functional requirements:

They are constraints/restrictions imposed on the system

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
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 bar code using a bar code 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 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
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.

4. Conclusion

Functional requirements are requirements in which users seek for them to be implemented. However, there are also requirements done by the system, but not directly recognized by users, these requirements should be considered when documenting requirements. These are the once referred to hidden functionalities.

Site:	Saylor Academy
Course:	CS302: Software Engineering
Book:	Object-Oriented Analysis

Printed by:	Guest user
Date:	Saturday, June 10, 2023, 1:36 AM