A method of software requirements specification and validation for global software development

Abstract

Global software development (GSD), where software teams are located in different parts of the world, has become increasingly popular. To devise a high-quality software requirements specification (SRS), effective communication and collaboration between stakeholders are necessary for GSD. However, geographical distance, cultural diversity, differences in time zones and language barriers create difficulties for stakeholders in engaging in effective collaboration. Taking into consideration the factors involved in GSD, previous research showed that the ways by which requirements are documented and validated for collocated software development projects cannot be used effectively for GSD. In this paper, we present a method of GSD requirements specification and validation. Our method begins with generating a requirements graph to understand details of the software requirements with respect to different GSD sites. The information obtained from a requirements graph is to be contained in a requirements specification document, and then be circulated between different GSD sites for reviewing, updating and finalizing its content. Finally, the requirements contained in the specification document are to be validated by generating and comparing validation matrices at different GSD sites. Past researchers used student groups in a university environment to play the roles of stakeholders in experiments in GSD studies. We therefore validate our method by applying it to a case study of an online shopping system, where the roles of stakeholders were played by a group of students.

Appendices

Appendix 1

See Table 20.

Table 20 Description of non-functional requirements

Appendix 2: Software requirements specification of online shopping system (Developed by using proposed method)

2.1 Introduction

Purpose of SRS: The SRS document describes the requirements for the online shopping system. For correspondence purposes, the reference number of this SRS document is V101-Online Shopping.

The persons who will use this document are the requirements engineers, project analysts, designers, developers and users from client XYZ. Any possible changes made in the requirements of the online shopping system will be recorded in the SRS document, and the latest version will then be used by these groups of people.

Scope of SRS: Client XYZ wants to develop a software product called an “online shopping system” for their organization by which they can sell different products to a broad range of customers. The shopping system must be able to: (1) facilitate customers/end-users in purchasing different products, tracking their orders, viewing sellers’ information, and making payments via a secure payment platform; and (2) facilitate XYZ in selling different products, managing information about customers (i.e. shoppers) and wholesale merchandisers (i.e. sellers), managing all the orders made by the customers, and managing information about the products sold or still available.

Acronyms and definitions: (Table 21).

Table 21 List of acronyms and definitions

References: The following references are used in the SRS document.

• IEEE 830 [17] standard for writing SRS document.

• List of scenarios and use cases

• Sommerville [33]

Overview of SRS: The remaining sections of the SRS document are organized as follows.

• Section 4.2.2 defines the product perspective, functions, user classes and characteristics, locations and time zones of user classes, list of communication modes, mechanisms and tools used between user classes, operating environment, design and implementation constraints, user documentation, and assumptions and dependencies.

• Section 4.2.3 specifies the details about functional and non-functional requirements.

2.2 General description

Product perspective: The online shopping system is a new and stand-alone software product. Therefore, it is not a part of a larger system or a modification of the existing systems.

There are two basic modules/components in the online shopping system. The first module is responsible for the different types of services offered by the shopping system. However, the second module covers the security aspect of the shopping system. A detailed description of these modules and their functionalities is listed in Sect. 4.2.3.

User classes and characteristics: The users who will interact with the shopping system are the requirements engineers, project analysts, designers, developers, client XYZ and end-users. Requirements engineers, project analysts and designers are assumed to have detailed knowledge of the overall requirements, and developers are more aware about the development and technical aspects. However, easy-to-use graphical user interfaces and user documentation will be provided to educate client XYZ and other end-users about how to use the shopping system.

Locations and time zones of user classes: Details about the location and time zones of each user class are given in Table 22.

Table 22 Locations and time zones of user classes

Communication modes, mechanisms and tools used by user classes: Details about the communication modes, mechanisms and tools that will be used by each user class are mentioned in Table 23.

Table 23 List of communication modes, mechanisms and tools used by user classes

Operating environment: The shopping system is a website and should be able to operate in Internet Explorer (v.7.0 and later), Mozilla Firefox (v.2.0 and later), Google Chrome and Opera.

Design and implementation constraints: Details about the design and implementation constraints are given in Table 24.

Table 24 Design and implementation constraints

User documentation: Four different types of documentation will be produced during the software development life cycle.

• High-level description of the most important software processes

• Data specification report for purchase orders, order tracking, seller information, and payment and authentication mechanisms

• Online help about how to use the shopping system

• Feedback and error-reporting mechanisms to be used by the system administrator

Assumptions and dependencies: The following assumptions are made about the online shopping system

• User and management-related processes are combined at a central site, accept input and provide different services to different users at different locations

• ASP.Net will be used as a development platform and the SQL server to store database

• The shopping system will be easy to use by different groups of users

• The performance of shopping system depends on the speed of the internet

2.3 Specific requirements

There are different types of services and payment mechanisms in the online system. Detailed descriptions about their associated requirements are listed below.

2.3.1 Functional requirements

I. Services

Introduction: Three different types of services are required: purchase; order tracking; and seller information

Requirement id: 2

Priority: High

Child requirement: Purchase, order tracking and seller information

Parent requirement: Online shopping system

Input: Purchase details, order tracking information, sellers’ specification

Processing:

• Purchase details browse catalogue, select product, payment, and place order.

• Order tracking tracking criteria and shipping information

• Sellers’ specification user rating and history

Output:

• Purchase details catalogue browsing, product selection, make payment and order placement.

• Order tracking track orders

• Sellers’ specification view seller information

Developed at user class: India

Direct and indirect affected requirements: Changes in the requirements of the service module will affect the requirements of the payment module, developed at the Chinese site.

External interfaces:

• User interface All the GUI’s must follow a similar theme and have a clear structure.

• Hardware interfaces The shopping system is a web-based software product that should run easily on the aforementioned web browsers, and will be hosted on a Windows server.

• Software interfaces Any operating system capable of running different web browsers could be used.

• Communication interfaces HTTP protocols must be used to facilitate communications between client and server machines.

II. Purchase

Similarly, the requirements engineers and analysts document details about other functional requirements.

2.3.2 Non-functional requirements

Performance requirement:

• Response timeThe system should be able to retrieve order details within 10 s

• Workload The system should be able to support 4 pages/second

• Scalability The system should be capable of supporting no less than 50 customers at a time when implemented

• Platform The system should be able to operate in Internet Explorer (v. 7 and later), Mozilla Firefox (v. 2 and later), Google Chrome and Opera.

Safety requirement: To prevent possible data damages or losses, the shopping system must have a data recovery procedure.

Security requirement: The shopping system must ensure that data about different types of transactions must be processed in a secured channel.

Quality attributes:

• Usability End-users with different background knowledge can easily use the shopping system

• Support Regardless of the time difference between Australia, India and China, 24/7 helpdesk, network, application, database, administration, security and training supports will be required for 6 months from the offshore sites

• Reliability The system must be able to store database information on different computers to prevent it from possible losses and damage

• Localizability Although the system will be developed in India and China, localizability must be ensured with respect to Australian traits

• Availability The shopping system should be accessible to users 24/7, except the specified maintenance period

2.4 Other requirements

For further details, the user should refer to the following documents.

• Use case documentation

Appendix 3: Software requirements specification of online shopping system (Developed by using existing method)

3.1 Introduction

Purpose: The SRS document provides information on the requirements of the OSS. The reference number of the SRS document is SRS00-1/ONS.

The people who will use this document are the requirements engineers, project analysts, designers, developers and users from client XYZ.

Scope: Client XYZ wants to develop a software product called an “online shopping system” for their organization. The shopping system must be capable of providing the following functionalities:

• Facilitate customers/end-users in purchasing different products, tracking their orders, viewing sellers’ information, and making payments via a secure payment platform.

• Facilitate XYZ in selling different products, managing information about customers (i.e. shoppers) and wholesale merchandisers (i.e. sellers), managing all the orders made by the customers, and managing information about the products sold or still available.

• Easy-to-use graphical user interface (GUI).

Definitions, acronyms and abbreviations: The following acronyms are used in the SRS document (refer to Table 25).

Table 25 List of acronyms and definitions used in the SRS document

References: The following reference is used in the SRS document.

• IEEE 830 [17] standard to write the SRS document.

Overview of SRS: The SRS document is organized as follows.

• A general description presents details on the product perspective and functions, user characteristics, design and implementation constraints, and assumptions and dependencies.

• A specific requirements list which details the functional and non-functional requirements.

3.2 General description

Product perspective: This is a new system which is neither an extension of an old system nor a component of a larger system.

Product function: The overall system has two main modules that cover the different functionalities of services and payment features of the shopping system.

User characteristics: The users who will interact with the OSS are the requirements engineers, project analysts, designers, developers, and users from the client.

Design and implementation constraints: Depending on the nature of the interaction, the rights and privileges must be ensured for each group of users.

Assumptions and dependencies: The shopping system must be easy to use by different groups of users.

3.3 Specific requirements

• a. Functional requirements

  • (i) Services

    Introduction: The three types of services that will be required are: purchase, order tracking and seller information.

    Input: Details of purchase, information to track orders, and sellers’ specifications.

    Processing: To process different types of inputs, the following mechanisms will be used:

    Details of purchase- browse catalogue, select product, make payment,

    Information to track orders supply order details

    Sellers’ specifications- seller history

    Output: For each input, one of the following outputs will be generated.

    Details of purchase order will be placed after browsing the available catalogue

    Information to track orders- order tracking

    Sellers’ specifications- view information about the seller’s rating and past history

    External interfaces: For each of the external interfaces, the specifications listed below will be used.

    User interface a clear and consistent theme should be used in all GUI’s

    Hardware interface a Windows server 2008–2010 will be used to host the OSS.

    Software interface the versions of Mozilla Firefox, Google Chrome and Internet Explorer released after the year 2005 will be used to run the OSS.

    Communication interface TCP/IP and HTTP protocols must be used for communication purposes.

  • (ii) Purchase

    Likewise, the requirements engineers and the project analysts documented details about the other functional requirements.

• b. Performance requirements

  The overall performance of the shopping system mainly depends on the aforesaid hardware and software specifications.

• c. Design constraints

  Each of the developed subsystems must be traced back to its associated use case and non-functional requirements.

• d. Attributes

  Security- The possible transactions that occur in the shopping system must be processed in a secured and encrypted channel.

  Safety- To minimize data loss, safety measures must be taken to prevent data.

  Availability- The shopping system should be available 24 h a day, 7 days a week.

  Reliability- The shopping system should be reliable

3.4 Other requirements

For further clarification, contact the project analyst.