Software Requirements and Quality Assurance

In software requirements engineering there is a systematic use of principles, technique and tools for cost effective analysis, documentation and user needs. Both the software engineer and customer take an active role in software requirements engineering.

In this chapter e will discuss the concept of user and functional requirements. We describe functional and non functional requirements. Finally we will learn how software requirements may be organized in software requirements document.

What is requirement engineering?

Requirement engineering is the process of

Establishing the services that the customer requires from a system.
And the constraints under which it operates and is developed.

The requirements themselves are the descriptions of the system services and constraints that are generated during, the requirements engineering process.

What is a requirement?

A requirement can range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

The requirement must be open to interpretation and it must be defined in detail.

Types of requirements

The requirements can be classified as – Types of requirements

- System
- Software specification
- User
- User requirements

It is a collection of statements in natural language plus description of the services the system provides and its operational constraints. It is written for customers.

System requirements

It is a structured document that gives the detailed description of the system services. It is written as a contract between client and contractor.

Software specification

It is a detailed software description that can serve as a basis for design or implementation. Typically it is written for software developers.

Requirement Engineering Tasks

Requirement engineering is the process characterized for achieving following goals –

Understanding customer requirements and their needs
Analyzing the feasibility of the software requirements
Negotiating the reasonable solutions
Specification of an unambiguous solution.
Managing all the requirements of the project

Finally transforming the requirements into the operational systems

Requirement engineering process performs following seven distinct functions

Requirement engineering tasks

- Inception
- Elicitation
- Elaboration
- Requirement
- Engineering
- Tasks
- Negotiation
- Specification
- Validation
- Requirement management

Let us now discuss these tasks in detail –

Inception

The inception means specifying the beginning of the software project. Most of the software projects get started due to business requirements. There may be potential demand from the market for a particular product and then the specific software project needs to be developed.

There exist several stakeholders who define the business ideas. Stakeholders mean an entity that takes active participation in project development. In software project development, the stakeholders that are responsible for defining the ideas are business managers, marketing people, product managers and so on. Their role is to do rough feasibility study and to identify the scope of the project.

During the inception a set of context free questions is discussed. The purpose of inception is to –

Establish the basic understanding of the project.
Find out all possible solutions and to identify the nature of the solution.
Establish an effective communication between developer and the customer.

Elicitation

Before the requirements can be analyzed and modelled they must undergo through the process of elicitation process. Requirements elicitation means requirements discovery. Requirements elicitation is very difficult task.

Following are the reasons for : why it is difficult to understand customer wants?

Customer sometimes is unable to specify the scope of the project. Sometimes customers specify too many technical details and this may increase the confusion
There is difficulty in understanding the problem. Sometimes customer could not decide what are their needs and wants. Sometimes they have got poor understanding of capabilities and limitations the existing computing environment, Sometimes customers find it difficult to communicate with the system engineer about their needs. Sometimes customers may have got some conflicting requirements. This ultimately results in specifying ambiguous requirements.
As project progresses the needs or requirements of the customers changes. This creates a problem of volatility. To overcome these problems the requirements gathering must be done very systematically.

Elaboration

Elaboration is an activity in which the information about the requirements is expanded and refined. This information is gained during inception and elicitation.
The goal of elaboration activity is to prepare a technical model of software functions, features and constraints.
The elaboration consists of several modelling and refinement tasks. In this process several user scenarios are created and refined. Basically these scenarios describe how end-user will interact with the system.
During elaboration, each user scenario is parsed and various classes are identified. These classes are nothing but the business entities that are visible to end user. Then the attributes and services (functions) of these classes are defined. Then the relationship among these classes is identified. Thus various

UML (Unified Modelling Diagrams) are developed during this task.

Finally the analysis model gets developed during the elaboration phase.

Negotiation

Sometimes customer may demand for more than that is achieved or there are certain. situations in which customer demands for something which cannot be achieved in limited business resources. To handle such situations requirement engineers must convince the customers or end users by solving various conflicts. For that purpose, requirement engineers must ask the customers and stakeholders to rank their requirements and then priority of these requirements is decided. Using iterative approach some requirements are eliminated, combined or modified. This process continues until the users’ satisfaction is achieved.

Specification

A specification can be a written document, mathematical or graphical model, collection of use case scenarios, or may be the prototypes.
There is a need to develop a standard specification in which requirements are presented in consistent and understandable manner.
For a large system it is always better to develop the specification using natural language and in a written document form. The use of graphical models is more useful for specifying the requirements.
Specification is the final work product of requirement engineering process. It describes the functions, constraints and performance of computer based systems.

Validation

Requirement Validation is an activity in which requirement specification is analyzed in order to ensure that the requirements are specified unambiguously. If any inconsistencies, omissions and errors are identified then those are corrected or modified during the validation.
The most commonly used requirement validation mechanism is formal technical review (FTR). In FTR, the review team validates the software requirements. The review team consists of requirement engineers, customers, end users, marketing person and so on. This review team basically identifies conflicting requirements, inconstancies or unrealistic requirements.

Requirement Management

Definition Requirements management is the process of managing changing requirements

during the requirements engineering process and system development,

Why requirements get change?

Requirements are always incomplete and inconsistent. New requirements occur during the process as business needs change and a better understanding of the system is developed.
System customers may specify the requirements from business perspective that can conflict with end user requirements.
During the development of the system, its business and the technical environment may get changed.

Functional and Non Functional Requirements

Software system requirements can be classified as functional and non functional requirements.

Functional Requirements

Functional requirements should describe all the required functionality or system services.
The customer should provide statement of service. It should be clear how the system should react to particular inputs and how a particular system should behave in particular situation.
Functional requirements are heavily dependent upon the type of software, expected users and the type of system where the software is used.
Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.

For example : Consider a library system in which there is a single interface provided to multiple databases. These databases are collection of articles from different libraries. A user can search for, download and print these articles for a personal study.

From this example we can obtain functional requirements as –

The user shall be able to search either all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document store.
A unique identifier (ORDER_ID) should be allocated to every order. This identify. can be copied by the user to the account’s permanent storage area.

Problems Associated with Requirements

Requirements imprecision –

Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and users.
Consider meaning of term ‘appropriate viewers’.
User intention – Special purpose viewer for each different document type;
Developer interpretation – Provide a text viewer that shows the contents of the document.

Requirements completeness and consistency –

The requirements should be both complete and consistent. Complete means they should include descriptions of all facilities required. Consistent means there should be no conflicts or contradictions in the descriptions of the system facilities.

Actually in practice, it is impossible to produce a complete and consistent requirements document.

Non Functional Requirements

The non functional requirements define system properties and constraints. Various properties of a system can be : Reliability, response time, storage requirements. And constraints of the system can be : Input and output device capability, system representations etc.
Process requirements may also specify programming language or development method.
Non functional requirements are more critical than functional requirements. If the non functional requirements do not meet then the complete system is of no use.

Types of Non Functional Requirements

The classification of non functional requirements is as given below.

The system should posses a traditional word dictionary and user supplied dictionary. It shall provide a user-activated facility which checks the spelling of words in the document against spellings in the system dictionary and user-supplied dictionaries.
When a word is found in the document which is not given in the dictionary, then the system should suggest 10 alternative words. These alternative words should be based on a match between the word found and corresponding words in the dictionaries.
When a word is found in the document which is not in any dictionary, the system should propose following options to user:
Ignore the corresponding instance of the word and go to next sentence.
Ignore all instances of the word.
Replace the word with a suggested word from the dictionary.
Edit the word with user-supplied text.
Ignore this instance and add the word to a specified dictionary.

System Requirement

System requirements are more detailed specifications of system functions, services and constraints than user requirements.
They are intended to be a basis for designing the system.
They may be incorporated into the system contract.
The system requirements can be expressed using system models.
The requirements specify what the system does and design specifies how it does.
System requirement should simply describe the external behaviour of the systemand its operational constraints. They should not be concerned with how the system should be designed or implemented.
For a complex software system design it is necessary to give all the requirements in detail.
Usually, natural language is used to write system requirements specification and user requirements.

Why requirement and design are inseparable?

A system architecture may be designed to structure the requirements.
The system may inter-operate with other systems and that may generate design requirements.
The use of a specific design may be a domain requirement.

Collaborative Requirement Gathering – Software Requirements

Collaborative requirement gathering is done using collaborative, team-oriented approach. Facility Application Specification Technique (FAST) is an approach in which joint team of customers and developers work together to identify the problem, propose elements of solution, negotiate different approaches and prepare a specification for preliminary set of solution software requirements.

Guideline for FAST approach –

A meeting should be conducted and attended by both software engineers and customers. The place of meeting should be a neutral site.
Rules for preparation and participation must be prepared.
An agenda should be prepared in such a way that it covers all the important point as well as allows all the new innovative ideas.
A facilitator controls the meeting. He could be customer, developer or outsider.
A definition mechanism is used. The mechanism can be work sheets, flip charts, wall stickers, electronic bulletin board, chart room, virtual forum.
The goal is to identify the problem, decide the elements of solution, negotiate different approaches and specify the preliminary set of solution requirements.

In FAST meeting each FAST attendee is asked to prepare a list of objects, list of services and a list of constraints.
The list of objects consists of all the objects used in the system, the objects that are produced by the system and the objects that surround the system.
The list of services contain all the required functionalities that manipulate or interact with the objects.
The list of constraints consists of all the constraints of the system such as cost, rules, memory requirement, speed accuracy etc.
As the FAST meeting begins, the very first issue of discussion is the need and justification for the new product. Once everyone agrees upon the fact that the product is justified, each participant has to present his lists.
These lists are then discussed, manipulated and these modified or refined lists are combined by a group.
The combined list eliminates redundant entries adds new ideas that come up during the discussion. The combined list is refined in such a way that it helps in building the system.
The combined list should be prepared in such a way that a “consensus lists” can be prepared, for object, services and constraints.
A team is divided into subteams. Each subteam develops a mini specification from each consensus list.
Finally a complete draft specification is developed.

For example – Software Requirements

A FAST team is working on a commercial product. A following software products description is given as below –

“Nowadays the market for video game is growing rapidly. We would like to enter this market with more features, like attractive GUI, multiple sound setting, realistic (3D) animations. This product is tentatively called ‘Game fun’. At the end of game, scores of each player should be displayed”.

The FAST attendee prepare following lists –

List of objects – Display, menu, a sound, an event (moving from one level to another) and so on.
List of services – Setting sounds, setting colors in GUI, HELP, instructions for players, score card etc.
constraints – Must be user friendly, must have high speed, must accommodate less size, should have less cost.

The minispecification for Menu (object) can be as given below –

Contains ‘Start game’ and ‘exit’ options.
List of all functional keys with corresponding functionality.
Software provides interaction guidance, quick tour, sound controls.
All players will play or interact through keys.
Software provides facility for change in the look of GUI.
Software displays scores of each player.

Quality Function Deployment (QFD)

Quality function deployment is a quality management technique which translates the customer needs and wants into technical requirements. This technique was introduced n Japan. Under quality function deployment three types of requirements can be defined –

Normal requirements – Software Requirements

The requirements as per goals and objectives of the system are called norm requirements. These requirements can be easily identified during the meeting with the customer.

Read More Topics

The address resolution protocol (ARP)

Introduction to internet protocol

Domain name system in computer networks