A Domain Specific Requirements Model for Scientific. Computing (NIER Track). Yang Li, Nitesh Narayan, Jonas Helming and Maximilian Koegel. Institut für ...
A Domain Specific Requirements Model for Scientific Computing (NIER Track) Yang Li, Nitesh Narayan, Jonas Helming and Maximilian Koegel Institut für Informatik Technische Universität München Boltzmannstrasse 3, 87548 Garching, Germany
{liya, narayan, helming, koegel}@in.tum.de ABSTRACT Requirements engineering is a core activity in software engineering. However, formal requirements engineering methodologies and documented requirements are often missing in scientific computing projects. We claim that there is a need for methodologies, which capture requirements for scientific computing projects, because traditional requirements engineering methodologies are difficult to apply in this domain. We propose a novel domain specific requirements model to meet this need. We conducted an exploratory experiment to evaluate the usage of this model in scientific computing projects. The results indicate that the proposed model facilitates the communication across the domain boundary, which is between the scientific computing domain and the software engineering domain. It supports requirements elicitation for the projects efficiently.
Categories and Subject Descriptors D.2.1 [Software Engineering]: Requirements/Specifications; J.2 [Computer Applications]: Physical Science and Engineering
General Terms Documentation, Theory
Keywords Requirements Modeling, Domain Specific, Scientific Computing
1.
INTRODUCTION
Requirements engineering is concerned with defining what the software is expected to do, and supports other development activities, such as design, coding and testing. Hence requirements engineering is a key activity to the success of a software [13, 5].
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICSE ’11, May 21–28, 2011, Waikiki, Honolulu, HI, USA Copyright 2011 ACM 978-1-4503-0445-0/11/05 ...$10.00.
Scientific computing is about design and analysis of approaches for solving mathematical problems in science and engineering domains. Software applications that are developed to serve scientific computing projects, especially research projects tend to be different from software applications developed for commercial purposes [12, 8, 3]. Most of the effort is put on achieving accurate and stable results, while efficiently harnessing the computational power [12]. In many projects, traditional requirements engineering methodologies are often ignored or considered to be time consuming. Kelly et al. [9] claimed that the majority of scientific software is developed without a detailed requirements specification. Sanders et al. [14] also quoted their survey findings of requirements engineering in this domain: “none of our interviewees created an up-front requirements specification until it was mandated, and only wrote it when the software was almost complete”. Most requirements of scientific computing projects are discovered during the course of project, due to the explorative nature of scientific research [4]. Carver et al. claimed this as one major reason for missing documentation of requirements. Furthermore, there is a knowledge gap between the scientific computing domain and the requirements engineering domain. Hannay et al. [6] conducted a survey to study how scientists develop and use scientific software. They discovered only 52% of the scientists have good/expert understanding of software requirements concepts and activities. Moreover only 46.4% of the scientists think formalizing the requirements are important. Thus, it is difficult to apply traditional requirements engineering methods in this domain without proper adjustments. However, it does not imply that requirements engineering in scientific computing projects can be neglected. In fact, a requirements document helps in dealing with the complexity of scientific computing software development [11]. New methodologies are required to provide the flexibility to document requirements with the possibility of refinement and extensibility [1]. Smith [15, 16] proposed a systematic approach to requirements documentation for scientific computing projects by providing a requirements template while addressing the challenges of writing validatable, abstract requirements and non-functional requirements. However, the mentioned approach is restricted to textual documentation and therefore it lacks in applicability for models [2]. Also, the terms used in the template are not self-explanatory. Thus, it first requires efforts to understand the template before documenting requirements. In this paper we present a new model-based approach
to elicit requirements in scientific computing projects. The model provides domain specific requirement model elements and associations between them. It has two main advantages. Firstly, a requirements model is at a higher level of abstraction than a textual requirements specification. Models can support traceability, reusability and extensibility. Therefore, it can better deal with complexity and change. Secondly, a domain specific model provides abstractions and notations targeted at the specific domain [10]. This makes modeling less complicated and reduces the learning effort for scientists. The model facilitates the communication across the domain boundary between the scientific computing domain and the software engineering domain. It promotes software engineering in scientific computing projects.
problem can be represented by a mathematical model, the 2 = ∂∂xu2 , where u(x, t) is one-dimensional heat equation ∂u ∂t the temperature at point x and time t. We assume that the given region starts at x = 0 and ends at x = L and the material is uniform. Finally, this equation can be solved by a finite-difference numerical method with explicit timestepping. We model the scientific knowledge for three reasons. First of all, the use of sophisticated mathematical models indicates the high complexity of the problem domain. Modeling scientific knowledge reduces this complexity. Secondly, all these information can help elicit and detail requirements. Finally, the modeled scientific knowledge can be reused for related scientific computing projects.
2.
2.2
DOMAIN SPECIFIC REQUIREMENTS MODEL
Solving scientific problems is a collaborative activity and requires shared scientific knowledge. Therefore, identifying requirements inherently depends on related scientific knowledge. The scientific knowledge cannot be ignored during requirements engineering, as this knowledge is the key driving force behind the creation or evolution of functional as well as non-functional requirements in this domain.
Scientific Knowledge
uses
Requirements Modeling
The elements for requirements modeling are customized to incorporate important concepts within the scientific computing domain. Figure 3 depicts the requirements part of the model. Features describe desirable properties that are enduser visible and represent an abstract view of the expected solution. We model features to perform a preliminary acquisition step for requirements engineering [7]. For instance, a feature is “a fast and accurate simulation for heat distribution with low computational costs”. A feature can be further refined and be detailed into the realizing requirements.
Requirements Requirements
Hardware depends
Figure 1: Domain Specific Requirements Model
is restricted Constraint
Figure 1 illustrates our domain specific requirements model. It consists of two parts, where the requirements part depends on the scientific knowledge part. Subsequent sections detail each part and describe how elements from each part correlate with each other.
2.1
Scientific Knowledge Modeling
Typically in scientific computing (see Figure 2), a scientific or engineering problem is first defined. Then mathematical models are created to represent the scientific problem in mathematical terms. In the mathematical modeling process, governing principles and physical laws are determined and factors which influence the scientific problem are identified. In order to obtain computational solutions, numerical methods are applied to solve the problems. Mathematical models and numerical methods are created on assumptions. Scientific Knowledge refines represents
Mathematical Model
Scientific Problem
depends Assumption
solves
Numerical Method
depends
Figure 2: Scientific Knowledge Modeling
As an example, we want to solve the scientific problem, simulating the distribution of heat in a rod over time. The
Feature details
Requirement
requires provides requires provides
Software Interface
User Interface
refines
Figure 3: Requirements Modeling
Hardware is an influential factor in scientific computing software development. To better utilize the computation power, scientific computing software applications are often hardware dependent. This is especially true for supercomputing applications. Another key element associated with feature is interface. An interface can either be a software interface or a user interface. The former provides an interface for external libraries and the latter supports end-user interaction with the software itself. Besides the above metioned limitations, any other constraints that will limit the developer’s design choices, such as the implementation language, have to be identified explicitly as well. Subclasses of the requirement model element are shown in Figure 4. The functional hierarchy of the detailed requirements is based on IEEE Std 830-1998. Requirement has subclasses of process and performance, with data definition associated with it . Processes specify the functions of processing data, including the algorithm or mathematical expression of each process. A process can be parallel to perform high performance computing tasks, in contrast to a sequential process. Data Definition is the meta-data of the data to be processed. It contains information such as data type, format, range and accuracy. This information is used by the process to better manage the data flow. Furthermore,
it is also beneficial for data distribution in parallel computing. There are also subclasses of process to satisfy the needs for scientific computing projects. However, it is out of scope to elaborate these subclasses in this paper.
their Ph.D and are continuing their work as scientific researchers. Table 1 shows various details for each of the five participants, where “experience” denotes the number of years since the participant developing scientific computing applications.
Requirement
Table 1: Experiment Participants Data Flow
Process
Performance
Data Definition
Participant
Background
Project
Experience
1
Computer Science
High-Dimensional Numerics
3-5 years
2
Computer Science
Computational Chemistry
3-5 years
3
Chemistry
Computational Chemistry
3-5 years
4
Applied Mathematics
Computational Seismology
5-10 years
5
Scientific Computing
Computational Geodynamics
> 10 years
Figure 4: Requirement
Referring back to the heat simulation example, we can identify the data flow as “input the space and time information x and t, output the temperature u”. The data definition for x is specified as “x is a vector corresponding to the length of the rod, 0 ≤ x ≤ L, and with double precision”. t and u are also specified respectively. To achieve a fast and low cost computation, we define a requirement of the type process as “The temperature u shall be computed according to the explicit finite-difference numerical method ”. This requirement can be further refined to steps of the computation process, i.e. initialization, computing, updating etc.
2.3
Integration
So far, we have already looked at the two parts of the proposed model separately. In this section, we discuss how these two parts are integrated. Figure 5 shows links between the two parts. A feature is influenced by a scientific problem. Qualities which the problem solving procedure shall have are defined in the feature. To detail this feature, requirements are created to realize suitable numerical methods for the corresponding mathematical model. Links within each part and links between the two parts establish the traceability support of this domain specific requirements model. Scientific Knowledge
Requirements
Scientific Problem
is influenced
Feature
Numerical Method
realizes
Requirement
Figure 5: Links between Two Parts
3.
EXPERIMENT
We conducted an initial experiment with the proposed model. The goal of this experiment was to evaluate the model itself in terms of usability and the learning curve involved to understand the model. To get a close and valuable feedback we interviewed developers who are already involved in several scientific computing projects within different disciplines.
3.1
Experiment Design
Participants. In total, five developers from four different research projects participated in the experiment. Three of them are Ph.D students, while two have already received
Procedure. Each participant was asked to model a feature with its requirements from his/her real software development work, by using our domain specific requirements model. Apart from this task, individual interviews are also included at the pre- and post-modeling stage. Questions being asked before the modeling task were: 1) Do you know what a requirement is? 2) Have you ever written any requirements specification? If yes, than in what way? 3) How necessary and beneficial do you think requirements are? Questions after the modeling task included: 1) Were you able to understand the model of your own? 2) Do you think you are more comfortable writing requirements this way or in textual format? 3) Do you think having a requirements model like this can help you understand the software and the development process itself? If yes, what other benefits do you see? 4) Was it too much effort or was it a time consuming task to model your requirements in this way? 5) Do you think it helps to evoke details, which you might need before implementation?
3.2
Experiment Results
The resulting requirements model instance created by each participant represented what are required to obtain in the participant’s project. This model establishes the basis for communication between various stakeholders and project planning. It also provides a baseline for validation and verification. In response to the interview questions of pre-modeling, we received some interesting responses. Most of the participants understand the word “requirement” in a generic way, but not the meaning of requirement from the software engineering perspective. Only one of the participants was clear about requirements in terms of software engineering. All of them agreed that they have never done requirements elicitation in a formal way and it’s not even a practice in their projects, until they had to submit any report. Usually they will discuss what they are supposed to do with colleagues orally, create sketches or note down bullet points. Three participants agreed that proper requirements specification is beneficial for any given project while the other two thought that it depends upon the complexity of the project. Interestingly, one participant also quoted that “People in this domain should practice requirements engineering but they never do so because identifying or maintaining requirements seems to be a tedious job, not as fun as coding.” Another participant presented his thoughts as “People should have concrete ideas of the whole system before programming.”
In the second part of the interview (post-modeling), four among the five participants stated that requirements engineering process can definitely help the way they develop. All of them think it is very helpful especially when working in a team, and it can greatly help members communicate and cooperate. All participants like this way of requirements engineering by employing our model. In response to the model itself we received positive feedback from the participants. They found this approach of modeling requirements very suitable for their domain as they can easily understand the terminology and it is very easy to identify the relationship between a requirement and how it evolves from the theoretical model. This domain specific requirements model allows them to capture the rationale behind a given requirement and helps them to discover open issues. They eventually showed their interests of having a tool support to model requirements so that they can collaborate with other members of the project. Above all, the transition from “no requirements engineering” to “worth trying” is clearly visible, according to the response of pre- and post-modeling. This transition shows that within the scope of our experiment the proposed model is suitable for this domain to elicit requirements and support the software development.
4.
[5]
[6]
[7]
[8]
CONCLUSION AND FUTURE WORK
We proposed a new domain specific requirements model for scientific computing projects to address the problem of missing or incomplete requirements within this domain. The model provides domain specific abstractions and notations to bridge the gap between the scientific computing domain and the software engineering domain. Requirements are at the model level of abstraction so as to inherit the properties of models, i.e. traceability, reusability and extensibility. To evaluate our model, we also conducted an exploratory experiment with developers from scientific computing projects. The participants gave positive feedback on the model and its usage. They were able to model the requirements for their projects and found that it helps capture the rationale and discover open issues by employing our model. The work presented in this paper is a part of our research focus to identify and incorporate suitable methodologies for requirements engineering in scientific computing projects. In the future, further investigations will be carried out to evaluate and improve the proposed model.
5.
[4]
REFERENCES
[1] K. S. Ackroyd, S. H. Kinder, G. R. Mant, M. C. Miller, C. A. Ramsdale, and P. C. Stephenson. developing scientific software Scientific Software Development at a Research Facility. Science And Technology. [2] B. A. Berenbach. Comparison of uml and text based requirements engineering. In Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, OOPSLA ’04, pages 247–252, New York, NY, USA, 2004. ACM. [3] J. C. Carver, R. P. Kendall, S. E. Squires, and D. E. Post. Software development environments for scientific and engineering software: A series of case studies. In ICSE ’07: Proceedings of the 29th international
[9]
[10] [11]
[12]
[13]
[14] [15]
[16]
conference on Software Engineering, pages 550–559, Washington, DC, USA, 2007. IEEE Computer Society. J. C. Carver, R. P. Kendall, S. E. Squires, and D. E. Post. Software Development Environments for Scientific and Engineering Software: A Series of Case Studies. 29th International Conference on Software Engineering (ICSE’07), pages 550–559, May 2007. B. H. C. Cheng and J. M. Atlee. Research directions in requirements engineering. In 2007 Future of Software Engineering, FOSE ’07, pages 285–303, Washington, DC, USA, 2007. IEEE Computer Society. J. E. Hannay, C. MacLeod, J. Singer, H. P. Langtangen, D. Pfahl, and G. Wilson. How do scientists develop and use scientific software? 2009 ICSE Workshop on Software Engineering for Computational Science and Engineering, pages 1–8, May 2009. J. Helming, M. Koegel, F. Schneider, M. Haeger, C. Kaminski, B. Bruegge, and B. Berenbach. Towards a unified requirements modeling language. In Requirements Engineering Visualization (REV), 2010 Fifth International Workshop on, pages 53 –57, 2010. M. A. Heroux and J. M. Willenbring. Barely sufficient software engineering: 10 practices to improve your cse software. In SECSE ’09: Proceedings of the 2009 ICSE Workshop on Software Engineering for Computational Science and Engineering, pages 15–21, Washington, DC, USA, 2009. IEEE Computer Society. D. Kelly, O. N. Canada, and R. Sanders. Assessing the Quality of Scientific Software. Communications, (May), 2008. S. Kelly and J. Tolvanen. Domain-Specific Modeling. John Wiley & Sons, Inc., Hoboken, NJ, USA, 2008. K. Kreyman and D. L. Parnas. On Documenting the Requirements for Computer Programs Based on Models of Physical Phenomena. pages 1–14. H. Naguib and Y. Li. Applying software engineering methods and tools to cse research projects. Procedia Computer Science, 1(1):1505 – 1509, 2010. ICCS 2010. B. Nuseibeh and S. Easterbrook. Requirements engineering: a roadmap. In Proceedings of the Conference on The Future of Software Engineering, ICSE ’00, pages 35–46, New York, NY, USA, 2000. ACM. R. Sanders and D. Kelly. Dealing with risk in scientific software development. IEEE Software, 25:21–28, 2008. S. Smith. Systematic Development of Requirements Documentation for General Purpose Scientific Computing Software. 14th IEEE International Requirements Engineering Conference (RE’06), pages 209–218, 2006. W. S. Smith and L. Lai. A new requirements template for scientific computing. volume 5, pages 107–121.
