Skip to main content

Advertisement

Springer Nature Link
Log in

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

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

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.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Subscribe and save

Springer+ Basic
$34.99 /Month
  • Get 10 units per month
  • Download Article/Chapter or eBook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime
Subscribe now

Buy Now

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3

Similar content being viewed by others

References

  1. Ali N, Lai R (2014) Managing requirements change in global software development. In: IEEE international conference on data and software engineering, Indonesia

  2. Ali N, Lai R (2016) A method of requirements change management for global software development. Inf Softw Technol 70:49–67

    Article  Google Scholar 

  3. Atkins D, Handel M, Hersleb J, Mockus A, Perry D, Wills G (2001) Global software development, the bell labs co-laboratory in international conference on software engineering, Toronto

  4. Babar MA, Kitchenham B, Jeffery R (2008) Comparing distributed and face-to-face meetings for software architecture evaluation: a controlled experiment. Empir Softw Eng 13(1):39–62

    Article  Google Scholar 

  5. Bartholomew R (2008) Globally distributed software development using an immersive virtual environment. In: IEEE international conference on electro/information technology (EIT’08), pp 355–360

  6. Berenbach B, Paulish DJ, Kazmeier J, Rudorfer A (2009) Software & systems requirements engineering. In Practice, Mcgraw-Hill Professional

  7. Brockmann PS, Thaumuller T (2009) Cultural aspects of global requirements engineering: an empirical chinese-german case study. In: Fourth IEEE international conference on global software engineering (ICGSE ‘09), pp 353–357

  8. Conchuir EO, Holmström H, Ågerfalk PJ, Fitzgerald B, (2006) Exploring the assumed benefits of global software development. In: Proceedings of the 1st international conference on global software engineering, pp 159–168

  9. Damian D, Zowghi D (2003) Requirements engineering challenges in multi-site software development organizations. Requir. Eng J 8:149–160

    Article  Google Scholar 

  10. Ebert C, Neve PD (2001) Surviving global software development. IEEE Softw 18(2):62–69

    Article  Google Scholar 

  11. Elliott J, Raynor-Smith P (2000) Achieving customer satisfaction through requirements understanding. Softw Process Technol 1780(20020):203–219

    Article  Google Scholar 

  12. Heinonen S, Tanner H (2010) Early validation of requirements in distributed product development: an industrial case study. In: Proceedings of the 2010 international conference on the move to meaningful internet systems, pp 279–288

  13. Herbsleb JD, Mockus A (2003) An empirical study of speed and communication in globally-distributed software development. IEEE Trans Software Eng 29(6):481–494

    Article  Google Scholar 

  14. Herbsleb JD, Moitra D (2001) Global software development. IEEE Softw 18(2):16–20

    Article  Google Scholar 

  15. Hsieh Y (2006) Culture and shared understanding in distributed requirements engineering. In: International conference on global software engineering; brazil, pp 101–108

  16. Hull E, Jackson K, Dick J (2010) Requirements engineering. Springer Science & Business Media

  17. IEEE Standard 830 (1998) Recommended practice for software requirements specifications. The Institute of Electrical and Electronics Engineers, Inc. New York

  18. Johri A (2011) Sociomaterial bricolage: the creation of location-spanning work practices by global software developers, special issue on “Studying work practices in Global Software Engineering”. Inf Softw Technol 53(9):955–968

    Article  Google Scholar 

  19. Lai R, Ali N (2013) A method of requirements management for global software development, Advances in Information Sciences, Human and Science Publication, Volume 1, Issue 1, pp 38–58

  20. Lee Y, Zhao W (2006) Domain requirement elicitation and analysis- an ontology based approach, Volume 3994/2006. In: Workshop on computational science in software engineering (CSSE’06)

  21. Lloyd WJ, Rosson MB, Arthur JD (2002) Effectiveness of elicitation techniques in distributed requirements engineering. In: IEEE joint international conference on requirements engineering proceedings, pp 311–318

  22. Lobo OL, Arthur JD (2005) Effective requirements generation: synchronizing early verification and validation, method and methods selection criteria, Virginia Tech

  23. Lopes L, Prikladnicki R, Audy J, Majdenbaum A (2005) Requirements specification in distributed software development: a process proposal. In: Proceedings of the 38th Hawaii international conference system sciences (HICSS 05)

  24. Paasivaara M, Durasiewicz S, Lassenius C (2008) Distributed agile development: using scrum in a large project. In: IEEE international conference on global software engineering (ICGSE’08), pp 87–95

  25. Prikladnicki R, Audy JLN, Damian D, Oliveira TC (2007) Distributed software development: practices and challenges in different business strategies of off-shoring and on-shoring. In: Second IEEE international conference on global software engineering, pp 262–274

  26. Prikladnicki R, Audy JLN, Evaristo R (2003) Global software development in practice lessons learned. Softw Process Improv Pract 8(4):267–281

    Article  Google Scholar 

  27. Rickman DM (2001) A new process for requirements understanding. In 20th Conference on digital avionics system, pp 4D4/1–4D4/6

  28. Rodgers JL, Nicewander WA (1988) Thirteen ways to look at the correlation coefficient. Am Stat 42(1):59–66

    Article  Google Scholar 

  29. Salger F, Englert J, Engels G (2010) Towards specification patterns for global software development projects—experiences from the industry. In: Seventh international conference on the quality of information and communications technology (QUATIC), pp 73–78

  30. Shami NS, Bos N, Wright Z, Hoch S, Kuan KY, Olson J, Olson G (2004) An experimental simulation of multi-site software development. In: Proceedings of the 2004 conference of the centre for advanced studies on collaborative research, pp 255–266

  31. Shewell C (2000) Good business communicates across cultures: a practical guide to communication. Mastek Publications, Bristol

    Google Scholar 

  32. Smite D (2007) Project outcome predictions: risk barometer based on historical. In: Proceedings of the 2nd international conference on global software engineering (ICGSE’07), pp 103–112

  33. Sommerville I (2007) Software engineering, 8th edn. Addison-Wesley, England

    MATH  Google Scholar 

  34. Sommerville I, Sawyer P (1997) Requirements engineering: a good practice guide. Wiley, New York

    MATH  Google Scholar 

  35. Walle VD, Campbell C, Deek FP (2007) The impact of task structure and negotiation sequence on distributed requirements negotiation activity. Conflict, and Satisfaction, published by LNCS vol 4495, pp 381–394

  36. Wiegers KE (2003) Software requirements. Microsoft Press, Redmond

    Google Scholar 

  37. Wolf T, Dutoit AH (2005) Supporting traceability in distributed software development projects. In: Proceedings of international workshop on distributed software development

  38. Wongthongtham P, Chang E, Dillon T (2007) Multi-site distributed software development: issues, solutions, and challenges. In: Proceedings of the 2007 international conference on computational science and its applications, pp 346–359

  39. Yousuf F, Zaman Z, Ikram N (2008) Requirements validation techniques in GSD: a survey. In Proceedings of the IEEE multi-topic conference, pp 553–557

Download references

Acknowledgments

This work is supported by a La Trobe University Postgraduate Write-up scholarship.

Author information

Authors and Affiliations

  1. Department of Computer Science and Information Technology, La Trobe University, Melbourne, VIC, 3086, Australia

    Naveed Ali & Richard Lai

Authors
  1. Naveed Ali
    View author publications

    You can also search for this author inPubMed Google Scholar

  2. Richard Lai
    View author publications

    You can also search for this author inPubMed Google Scholar

Corresponding author

Correspondence to Richard Lai.

Appendices

Appendix 1

See Table 20.

Table 20 Description of non-functional requirements
Full size table

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
Full size table

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
Full size table

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
Full size table

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
Full size table

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
Full size table

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

  1. a.

    Functional requirements

    1. (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.

    2. (ii)

      Purchase

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

  2. b.

    Performance requirements

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

  3. c.

    Design constraints

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

  4. 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.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Ali, N., Lai, R. A method of software requirements specification and validation for global software development. Requirements Eng 22, 191–214 (2017). https://doi.org/10.1007/s00766-015-0240-4

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-015-0240-4

Keywords