Keywords

1 Introduction

Software requirements are properties of system behavior desired by various stakeholders such as paying customers, users, and developers. Software engineers gather users’ needs and identify the priorities for solving some real-world problems, and they define goals, functions, external interfaces, quality attributes, and constraints placed on a software product or service. Many researchers and practitioners have developed diverse techniques, methods, and tools [1] for dealing well with requirements engineering activities. The requirements engineering activities can be roughly classified into two: requirements development and requirements management [2]. The requirements development includes elicitation, analysis, specification, validation of requirements [3]. The requirements management comprises identification, documentation, maintenance, communication, tracking & tracing requirements throughout the life cycle of a system, product, or service [4].

Zave [5] has mentioned that traditional requirements engineering studies focused on the requirements development activities by translations into formal specifications from informal observations of the real world. Formal methods, such as VDM [6], Z [7], and Alloy [8], contribute to specifying precise and unambiguous formal specifications, and such formal expressions permit verifying properties or models by supporting tools. In contrast, agile software development has been mainly driven by the software industry for dealing with frequent change requests from clients or business environments during a project. As the manifesto [9] talks of welcoming change, agile software development manages customer requirements flexibly by iterative and incremental development.

Some studies [10] propose a combination of formal methods and agile software development for producing reliable software. Most agile practitioners in the software industry do not use formal methods. Succeeding in the software business [11, 12] has more to do with managing expectations and gaining consensus from their customers than developing secure and reliable products at first release. Agile philosophy has been critical of writing requirements documents and specifications at the beginning of a project as a waste of time and unrealistic. The reason is that the requirements will change over time. Meyer [13] argues against the criticism that writing a product requirements document provides a sound basis for discussion about the system’s future functions. Especially, it is helpful to decide which function to remove.

To tackle the criticism of writing requirements documents and response demand of specifications, we propose to use SOFL [14]. First, SOFL aids to integrate structured methods and object-oriented methods. It uses Vienna Development Method Specification Language (VDM-SL) [6] as textual notations. VDM-SL gives precise definitions of data and operations by simple propositional logics, basic set theory, and predicates for describing formal specifications. Also, SOFL provides graphical notations by adopting Data Flow Diagram [15], and Petri Nets [16]. The graphical notations help inexperienced persons to give an understandable overall architecture, associations with functions, and a hierarchic structure of the system. Second, SOFL supports transforming into formal descriptions from informal descriptions by a phased approach. In general, formal specifications use formal descriptions based on set theory, logic, algebra. Whereas, user requirements in agile software development are written in natural language. The transformation into formal descriptions in SOFL is called the three-step specification approach and constructs informal, semi-formal, and formal specifications. In this approach, informal and semi-formal specifications keep a good balance between preciseness and readability for even an inexperienced person to formal descriptions. Third, SOFL can effectively facilitate the combination of prototyping development and formal specifications [17, 18] in an iterative and incremental development manner. Rapid software prototyping is commonly used in agile software development as we will mention in the next section. Also, we conducted a case study to observe whether this combined process can handle changes caused by feedback from stakeholders. The result gives an interesting indication by revealing what kind of requirements and where changes occur during projects.

This paper is organized as follows. Section 2 introduces the background of our study on agile software development. Section 3 gives detailed instructions on our requirement development process with the informal and semi-formal specifications of SOFL. Section 4 explains the case study and discusses the results. Section 5 reviews related work. Finally, in Sect. 6 we conclude the paper and point out future research directions.

2 Background

Agile software development is not a single development methodology, but a superset of principles, practice, roles, and artifacts in each agile method such as Extreme Programming (XP) [19], Scrum [20], and Crystal [21]. For instance, Scrum takes in an iterative and incremental development manner for accepting changes at any time. In this section, we discuss the agile artifacts produced by typical agile requirements development to find a seamless transition process from informal descriptions written in natural language into formal descriptions. Prototypes, use cases and scenarios [22], and story cards [23] are commonly used in agile requirements development. These agile artifacts give more insight into designing a final product and improve communication between various stakeholders.

A prototype is a model of a product sketched ideas as depicted on the left-hand side of Fig. 1. It provides useful feedback from stakeholders in the initial stages of product development. Snyder [24] expresses that paper prototyping facilitates brainstorming, designing, creating, testing, and refining user interfaces. Nevertheless, these activities do not record automatically, nor we reproduce them. To overcome these challenges, numerous web designers use mock-up tools. A mock-up is also a model of a product illustrated by desktop, mobile, or online applications. And, the model seems the final product as if the functions provide. Especially, some online mock-up tools permit collaborative editing by a team; as a result, team members’ feedback or questions save in the cloud, and the editor response anytime and anywhere. Despite these benefits, a paper prototype or mock-up is not a document written in any natural language, but a picture. Consequently, it would not by itself define what to be done by the system precisely.

A use case diagram represents a system behavior with labeled oval shapes and stick figures as shown in the middle of Fig. 1. Each ellipse has a name as a user goal, what we call “use case”. A user case consists of scenarios, and a scenario is a sequence of actions and interactions that occur under certain conditions. A story card is a piece of paper used to write down a “user story” as illustrated on the right-hand side of Fig. 1. A user story describes a small unit of functionality that will be valuable to a user of the system.

Both use case and user story utilize the scenarios which indicate the properties of the system’s functionality from the users’ point of view. A scenario is merely one episode of user interaction. No matter how many episodes, a scenario is not itself a constituent behavior of the system. And above all, generating tests based on such episodes do not satisfy test case completeness. These reasons are these typical agile artifacts do not cause the actions of decomposition, composition, encapsulation, abstraction, and generalization, in comparison with structured methods and object-oriented methods. In summary, agile artifacts are insufficient for comprehensive analysis to produce reliable software.

Fig. 1.
figure 1

Agile requirements development

Full size image

3 Requirements Development Process

SOFL provides the three-step specification approach: informal, semi-formal, and formal specifications which enable to build formal specifications from informal descriptions written in a natural language step by step. Especially, informal and semi-formal specifications have an important role in functional decomposition and object composition. This section explains with an example of the development of informal and semi-formal specifications. Additionally, we propose an integrated requirement development process with the informal and semi-formal specifications of SOFL.

3.1 Informal Specification

The informal specification is a well-organized document written in a natural language as with scenarios described in use cases and user stories. However, SOFL makes a shift in perspective from user to system. Agile requirements development describes system functions from the user’s perspective as mentioned above. In contrast, SOFL requires an informal specification to clearly define from the point of view of systems. The informal specification contains three items: functions to be implemented, data resources to be used, and necessary constraints on both functions and data resources. For example, an informal specification for developing a mobile application to find a babysitter is given as follows.

Functions

  • Receive a request: This system receives the time, date, and location which a customer specifies to find an available babysitter.

  • Display search results: The system shows the candidate babysitters that match the input data. When there is no available babysitter, the system shows the message that the customer needs to select a wider range area for search.

  • Provide babysitters’ profiles: The system gives a babysitter’s profile depend on the customer’s selection among the search results. A profile includes personal data, hourly pay rate, available optional services, and reviews from other customers.

  • Book babysitter: The system enables to book one babysitter with some optional services and asks to agree on pay rate and responsibility.

  • Arrange contact: The system makes communication go smoothly with the customer and the babysitter by phone for an interview directly.

  • Cancel or change booking: The system accepts a cancellation or changing request from the customer, though there’s a cancellation charge under some conditions.

  • Collect monthly services fees: The system calculates a monthly charge for babysitter service and collects the amount from each customer by credit card. On the other hand, the system calculates a monthly wage for each babysitter in consideration of babysitter service and sends the amount by bank transfer.

Data Resources

  • sitter data: ID, password, name, email, phone number, address, bank account, profile data, hourly rate, customer reviews.

  • customer data: ID, password, name, email, phone number, address, credit card number, child data.

  • child data: age, gender, allergies, special supports.

  • booking data: location, date, start time, end time, sitter data, client data, specified optional services.

  • charge amount: hourly rate, total service time, additional fee for optional services.

Constraints

  • A password consists of six or more character sets.

  • The maximum number of browsing historical log data is 10

  • All windows for showing search results are visible but not editable.

  • This program prohibits multiple running

Fig. 2.
figure 2

The three-step specification approach

Full size image

3.2 Semi-formal Specification

The semi-formal specification is described as a set of modules to encapsulate required functions, data resources, and constraints in a hierarchical fashion. A module is composed of a module name, constant declarations, type declarations, variable declarations, an invariant section, and a list of processes as illustrated in Fig. 2. The module name represents a relation between the high-level module and its decomposition module. The constant declarations, type declarations, and variable declarations support clarifying the data items defined in the formal specification. The invariant section defines the constraints which are applied to the whole specification. A process carries out an operation with process name, input and output ports, precondition, and postcondition. The precondition describes a constraint on the input data flows before the execution of the process, while the postcondition provides a constraint on the output data flows after the execution. The semi-formal specification obeys the syntax of VDM-SL, but the precondition and postcondition are written in a natural language.

Two graphs illustrated by the right-hand side in Fig. 2 represent system behavior of modules in the formal specification, respectively. Also, the graphs show a decomposition from the upper module into the lower module in the formal specification. Generally, visualizations of system behavior strongly support understanding the big picture and facilitating communications as with agile software development. SOFL does not restrict whether graphical notations should be used for expressing modules in semi-formal specifications instead of formal specifications. For this reason, we decide to draw roughly data flow diagrams to identify a hierarchical structure at the semi-formal specifications as we describe below in a combined requirement development process.

3.3 A Combined Requirement Development Process

We propose a requirement development process combined with agile software development and the SOFL informal and semi-formal specifications. It is possible to adapt frequent change requests from stakeholders and support constructing formal specifications. Figure 3 explains that the combined requirement development process has five steps: prototype, use case & scenario, informal specification, Data Flow Diagram, and semi-formal specification . The prototypes represent ideas for user interfaces of final products, and include not only paper prototypes but also mock-ups. In use cases & scenarios, a system designer describes episodes from a viewpoint of product users by diagrams and/or documents. However, the system designer changes the perspective from the beneficiary receiver of the product into the system supplier after informal specification. As we explained above, the designer needs to refine informal descriptions to formal specifications with the aid of Data Flow Diagram, and semi-formal specification step by step. In the combined requirement development process, each artifact is refined by stakeholder feedback during a short-cycled iteration just as “sprint” in Scrum [20]. SOFL serves as a bridge to ensure a smooth transition from the agile artifacts into formal specifications.

Fig. 3.
figure 3

The combined requirements development process

Full size image

4 Case Study

We conducted a case study to evaluate the combined requirement development process for inexperienced undergraduate students in formal descriptions. Twelve undergraduate students who major in business participated in this experiment as project managers. One professor who has experience in developing software and knowledge of formal methods took on the facilitator. Each project consisted of four to eight team members, one project manager, and one facilitator. The manager was in charge of one mobile application development project, respectively. And each target domain for the project was based on social experiences through part-time jobs or internships. After they got six months of training in agile software development and SOFL, they decided on target domains. The target domains were finding a babysitter, employee shift planning, umbrella rental service, and bus routing guide. And then, they carried out brainstorming, designing, creating, and modifying the artifacts: prototypes, use case & scenario, informal specification, Data Flow Diagram, and semi-formal specification.

4.1 Results

The manager kept a record of when and what items he or she revised based on feedback from other team members. Each step of the combined requirement development process generally took two or three iterations, and each iteration was carried out during the two-week sprint duration. The total time for the experiment took almost six months. The periods were from November 2017 to June 2018, and from November 2018 to June 2019.

The facilitator analyzed feedback and reactions, and categorized requirement changes into five parts: interface, domain, functions, data, and constraints. Table 1 shows that each column represents the feedback point, and it arranges according to the timeline. The rows mean the category of reactions. We can find two features from the Table 1.

Table 1. The result of case study
Full size table

First, informal specification, Data Flow Diagram, and semi-formal specification steps support discovering data and constraints. Second, requests for changing the domain continue from the beginning to the end of the combined requirement development process. The problem of the change needs more discussion for handling development if we apply the combined requirement development process in practice. We mention project managers’ actions during reworking requirement changes in the next part.

4.2 Findings

During the case study, the facilitator realized some project managers were forgetting the most important services to provide the system. The missing core services occurred when the managers focused on the feedback from other team members too much. Additionally, some projects returned the previous step for changing problem domains, for instance, adding a new target user. The reworks occurred during informal specification, Data Flow Diagram, and semi-formal specification.

To address the former case, the facilitator decided iteration goals and a set of acceptance criteria in advance. The iteration goals clearly define what the team accomplish. The acceptance criteria help to judge disagreement or agreement of stakeholders’ feedback. The latter case expresses that our proposed process is not easy to adapt to the changes in domains’ properties without repeating the activities from the previous step to the current step.

5 Related Work

Some studies focus on the changes in domain properties and for managing continuous changes. Zave and Jackson [25] have emphasized that it is important to distinguish the machine and problem domains carefully. Because, the machine behavior is to be created by programming, whereas the problem domains have given properties and behaviors. The domains’ properties and behaviors might be given, in actuality, they are influenced by environmental conditions. Also, Jackson [26] has mentioned that pre-formal work creates a bridge from the stakeholders’ purposes and desires, leading to a detailed software specification. He has explained his proposed “Problem Frames approach” [27] applied for cyber-physical systems as pre-formal work.

Ghezzi [28] addresses the problem of environmental change and shows a model for cyber-physical systems. The model makes it possible to achieve self-adaptation software to changes in the environment. He shows how to incorporate formal modeling and verification iteratively and incrementally of agile software development. However, he suggests further research is needed to adapt modeling and verification.

We use SOFL as pre-formal work to ensure a smooth transition from the agile artifacts into formal specifications. However, it is not limited to apply for cyber-physical systems, we need more studies on the changes in domains’ properties for the sake of the development of an integrated tool to manage our proposed requirement development process.

6 Conclusions

This paper describes the combined requirement development process with agile requirements development and the SOFL informal and semi-formal specifications. The proposed process aims both to adapt frequent change requests from stakeholders and develop secure and reliable products, simultaneously. The case study shows that the proposed process contributes to discovering the data and constraints at the latter steps. In contrast, the requests for changing the domain exist at every step of the proposed process. It means that the proposed process is successful to supply agile development with structured methods and object-oriented methods. On the other hand, it is not enough to prevent returning the previous step for adapting after changes in domains’ properties. We need more studies for the changes in domains’ properties and behaviors and examine the associations with self-adaptation software for managing continuous changes in our future research.