Course: Software Requirements Definition And Analysis - Discussion Board 2
farzadbigz
SystemsEngineering.pdf
Copyright © 2018 Javed Iqbal et al. This is an open-access article distributed
under the terms of the Creative Commons Attribution License 4.0, which
permits unrestricted use, distribution, and reproduction in any medium, provided
the original author and source are credited.
Circulation in Computer Science
International Conference on Engineering, Computing & Information Technology (ICECIT 2017), pp:14-18
Conference Article
Significant Software Requirements Engineering
Practices in Systems Engineering Context
Javed Iqbal Department of
Computer Science, COMSATS Institute
of IT, Islamabad, Pakistan
Rodina Ahmad Faculty of CS and IT University of Malaya,
Kuala Lumpur, Malaysia
Mohd Hairul Nizam Md Nasir Faculty of CS and IT University of Malaya,
Kuala Lumpur, Malaysia
Muzafar Khan Department of
Computer Science, COMSATS Institute
of IT, Islamabad, Pakistan
ABSTRACT Utilization of the software is increasing day by day. The
advancement in hardware and software have paved the way
for systems engineering that supports the development of
complex systems encompassing software as a part. Such
systems need more vigorous Requirements Engineering (RE)
practices and guidelines to cater the multidimensional needs.
The objective of this study is to identify the significant
software RE practices in the systems engineering context.
Through the questionnaire survey and by employing four
categories for the perceived benefits of RE practices, we have
identified 55 RE practices that are significant for
improvement of RE process in systems engineering context.
Keywords Requirements Engineering Practices, Requirements
Engineering Process, Software Requirements Engineering,
Systems Engineering.
1. INTRODUCTION The rapid growth of hardware and software paves the way of
complex systems in which software is just a single component
with many others from different domains e.g. mechanical
engineering. Computer systems are no more standalone
systems with application software. Researchers are working
on smart grids [1], smart homes [2], and many other similar
projects in which data from different sensors/system
components is continuously generated and processed to make
decisions. Such systems need more vigorous Requirements
Engineering (RE) practices and guidelines to cater the
interests of multiple parties involved. This whole development
scenario leads towards system engineering.
System engineering is defined as “the multidisciplinary
application of analytical, mathematical, and scientific
principles for formulating, selecting, developing, and
maturing a solution that has acceptable risk, satisfies user
operational need(s), and minimizes development and life
cycle costs while balancing stakeholder interests” [3].
Keeping in view this definition, an important aspect of
system engineering is to satisfy the users’ requirements. RE
deals with analysis, specification, prioritization and
management of user requirements.
In near past, researchers focused developing methods for
elicitation, analysis, documentation, and prioritization of user
requirements in the context of software development. System
engineering which involves multidisciplinary development,
demands the wider scope of RE. RE is the most imperative
activity of the software development life cycle [4] and it
affects the other software development activities considerably
[5]. The success or failure of a project is reliant on the RE
process [4]. Cost of removing defects after the deployment of
software can be 10 to 200 times as compared to the cost if
defects are detected and eliminated during RE phase [6].
Therefore, to fulfill the wide-ranging demands of systems
engineering, significant RE practices in systems engineering
context must be identified for the enhancement of RE process.
With this context, this study intends to answer the following
research question:
Research Question: Which RE practices are significant for
software development in systems engineering context?
2. LITERATURE REVIEW The various approaches to capture, specify and communicate
requirements for safety critical systems have been discussed
in [7]. A systematic literature review on requirements for
safety critical systems has been presented in [8]. The study [9]
presents framework to engineer the requirements in case of
adaptive systems. Holtman et al. provide an algorithm for
refinement of the software requirements for model based
systems engineering [10]. Another study [11] defines the
high-level safety requirements for automotive industry by
providing the safe systems requirements engineering process
and OS&SHA method. A case study, about goal-oriented RE
in case of complex systems for research purpose, has been
presented in [12]. Based on emotions, the people-oriented RE
has been discussed in [13] through a case study on emergency
systems. Lutz & Keith emphasis on software requirements
engineering for cloud computing and large-scale systems [14].
The study [15] discusses the impact of volatility of
requirements in case of systems engineering. This can be
observed through literature review that numerous studies
focus on RE in case of systems engineering but no one
presents the significant RE practices for systems engineering.
3. RESEARCH METHODOLOGY To explore the significant Software Requirements
Engineering Practices (SREPs) in systems engineering
context, we have utilized Sommerville and Sawyer’s 57 (n)
RE practices [16] for requirements documentation,
requirements elicitation, requirements analysis and
negotiation, requirements description, system modeling,
requirements validation and requirements management.
This study is based on a questionnaire that contains closed
ended and open-ended questions. Our respondents are system
engineers, requirements engineers, project managers, manger
operations and software engineers who have at least 10 years’
experience regarding software development. The
questionnaire has been emailed to 160 relevant practitioners.
Out of which 103 questionnaires have been sent back.
Keeping in view various parameters like practitioners’
experience and job profile, 100 (TN) questionnaires have been
Circulation in Computer Science
International Conference on Engineering, Computing & Information Technology (ICECIT 2017), pp:14-18
www.ccsarchive.org
15
chosen for data analysis. The practitioners have ranked 57 RE
practices keeping in view the perceived benefits of the RE
practices in the context of systems engineering. The four
categories of the perceived benefits are [17-18]:
a) High Perceived Benefits (HPB): A High Perceived Benefits RE practice is mandatory and is employed
almost always.
b) Medium Perceived Benefits (MPB): A Medium Perceived Benefits RE practice is not mandatory but
it is used in case of the most of projects.
c) Low Perceived Benefits (LPB): A Low Perceived Benefits RE practice is employed in case of some
specific projects.
d) Zero Perceived Benefits (ZPB): A Zero Perceived Benefits RE practice is used hardly or never.
3.1 Criterion to find Significant Software
Requirements Engineering Practices If 50% respondents or more select ‘high perceived benefits’ or
‘medium perceived benefits’ category in case of an RE
practice then that RE practice will be considered as significant
in systems engineering context. Several studies [18-20]
successfully employ the same criterion.
The ‘significant’ means ‘important to be worthy of attention’
or ‘important enough to have an effect’. For this study, the
‘high perceived benefits’ and ‘medium perceived benefits’
categories have been considered to select significant SREPs in
systems engineering context as ‘high’ category RE practices
are mandatory almost for each project and ‘medium’ category
RE practices are widely employed. For every RE practice, the
Importance Level (IL) indicates responses’ percentage in
‘high’ and ‘medium’ perceived benefits’ categories. It can be
obtained by using formula:
IL= [(HPB + MPB) / TN] × 100
4. RESULTS AND DISCUSSION Results and discussions have been presented with respect to
seven applicability areas of RE practices which are: i).
Requirements documentation practices, ii) Requirements
elicitation practices, iii). Requirements analysis and
negotiation practices, iv). Requirements description practices,
v). System modeling practices, vi). Requirements validation
practices and vii). Requirements management practices.
We have denoted each SREP through a unique Practice
IDentification (PID) from SREP1, SREP2, SREP3…to SREP57.
The number of responses for various ranks/categories have
been denoted by HPBI, MPBI, LPBI and ZPBI (I = 1, 2,…, 57)
for high, medium, low and zero perceived benefits
respectively.
Whereas n SREP
NTZPBLPBMPBHPB n
I
IIII
1
)( and
n
I
IIII TNnZHBLPBMPBHPB
1
)()(0
4.1 Requirements Documentation Practices Table 1 shows that there are 8 requirements documentation
practices represented by SREP1, SREP2, …, SREP8. The
number of responses in various categories are denoted by
HPBI, MPBI, LPBI, and ZPBI (I = 1, 2, …, 8). The SREPs in
case of which IL is 50 or more, are considered as significant
RE practices in systems engineering context.
By applying significance criterion, this can be observed that
out of 8 RE practices, 7 are significant RE practices whereas 1
RE practice (SREP3) is unimportant in the systems
engineering context. The IL in case of SREP3 is 45 which is
less than 50, therefore, SREP3 does not meet the significance
criterion. In case of the rest of 7 requirements documentation
practices the ILs are 69, 71, 60, 89, 63, 70 and 74. All these
ILS are more than 50, therefore, these requirements
documentation RE practices are significant for RE process.
Table 1. Requirements documentation practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP1 Defining standard document structure 41 28 21 10 69
SREP2 Explaining how to use document 47 24 17 12 71
SREP3 Including requirements’ summary 30 15 50 05 45
SREP4 Making business case for necessity of system 52 08 38 02 60
SREP5 Providing definitions for special terms 50 39 07 04 89
SREP6 Designing document to support readability 43 20 29 08 63
SREP7 Assisting reader in finding required information 40 30 21 09 70
SREP8 Making changes in requirements’ document easy 35 39 20 06 74
4.2 Requirements Elicitation Practices Table 2 shows that there are 13 requirements elicitation
practices. By applying significance criterion, this can be
observed that out of 13 practices, 12 are significant RE
practices whereas 1 RE practice (SREP16) is insignificant in
the systems engineering context. The IL in case of SREP16 is
48 which is less than 50 and hence does not meet the
significance criterion. In case of the remaining 12
requirements elicitation practices i.e. SREP9, SREP10,
SREP11, SREP12, SREP13, SREP14, SREP15, SREP17, SREP18,
SREP19, SREP20, SREP21, the ILs are 60, 62, 59, 76, 88, 69,
56, 60, 71, 58, 90, 70 respectively. This can be observed that
all the ILs are more than 50. Thus, according to the opinion of
practitioners, these RE elicitation practices fulfil the
significance criterion and are significant to address the
requirements elicitation issues.
Circulation in Computer Science
International Conference on Engineering, Computing & Information Technology (ICECIT 2017), pp:14-18
www.ccsarchive.org
16
Table 2. Requirements elicitation practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP9 Assessing feasibility of system 47 13 31 09 60
SREP10 Considering organizational and political factors 42 20 28 10 62
SREP11 Finding and consulting potential stakeholders of the system 45 14 27 14 59
SREP12 Recording sources of the requirements 39 37 16 08 76
SREP13 Considering operating environment of the system 46 42 09 03 88
SREP14 Using business goals for deriving elicitation of the requirements 39 30 26 05 69
SREP15 Considering constraints of domain 36 20 38 06 56
SREP16 Knowing rationale for the requirements 25 23 30 22 48
SREP17 Gathering requirements keeping in view various viewpoints 46 14 35 05 60
SREP18 Prototyping the requirements that are unclear 44 27 17 12 71
SREP19 Employing scenarios for eliciting requirements 41 17 29 13 58
SREP20 Documenting the operational processes of business 40 50 08 02 90
SREP21 Reusing requirements from alike systems 48 22 25 05 70
4.3 Requirements Analysis and Negotiation Practices Table 3 shows that there are 8 requirements analysis and
negotiation practices. By applying significance criterion, this
can be observed that all the 8 practices are significant RE
practices in the systems engineering context.
Table 3. Requirements analysis and negotiation practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP22 Outlining boundaries of computer based system 50 44 05 01 94
SREP23 Developing and using checklist for analyzing requirements 30 36 27 07 66
SREP24 Facilitating requirements negotiation by using software 35 20 35 10 55
SREP25 Anticipating requirements conflicts and planning for resolving the conflicts 46 47 04 03 93
SREP26 Assigning requirements priorities 40 27 22 11 67
SREP27 Classifying requirements with respect to different dimensions 40 29 19 12 69
SREP28 Employing Interaction Matrices for identifying requirements conflicts and
overlapping 44 24 29 03 68
SREP29 Assessing potential risks related to requirements 51 10 33 06 61
4.4 Requirements Description Practices Table 4 shows that there are 5 requirements description
practices. By applying significance criterion, this can be
observed that all the 5 practices are significant RE practices in
the systems engineering context.
Table 4. Requirements description practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP30 Defining and using standard templates to describe requirements 44 48 06 02 92
SREP31 Describing requirements by applying simple, consistent and brief language 38 20 32 10 58
SREP32 Describing requirements through apposite utilization of diagrams 35 32 19 14 67
SREP33 Supplementing the natural language description with the other descriptions 30 37 29 04 67
SREP34 Specifying requirements through quantitative values 40 23 36 01 63
4.5 System Modelling Practices Table 5 shows that there are 6 system modeling practices. By
applying significance criterion, this can be observed that all
the 6 practices are significant RE practices in the systems
engineering context.
Circulation in Computer Science
International Conference on Engineering, Computing & Information Technology (ICECIT 2017), pp:14-18
www.ccsarchive.org
17
Table 5. System modelling practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP35 Developing various complementary models of the system 47 40 11 02 87
SREP36 Developing numerous models to show the system’s
environment 50 47 02 01 97
SREP37 Developing the system architecture 42 44 10 04 86
SREP38 Employing structured methods to model the system 33 37 23 07 70
SREP39 Using data dictionary 41 31 19 09 72
SREP40 Mentioning association between requirements and system
models 40 40 15 05 80
4.6 Requirements Validation Practices Table 6 shows that there are 8 requirements validation
practices. By applying significance criterion, this can be
observed that all the 8 practices are significant RE practices in
the systems engineering context.
Table 6. Requirements validation practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP41 Checking that requirements specification document is according to standards 34 20 38 08 54
SREP42 Arranging for the inspections of the requirements 31 38 20 11 69
SREP43 Employing multi-disciplinary teams for sake of reviewing requirements 40 43 10 07 83
SREP44 Preparing checklists for validating requirements 40 27 27 06 67
SREP45 Developing prototypes for requirements’ animation 30 32 28 10 62
SREP46 Writing user manual 42 40 12 06 82
SREP47 Suggesting test cases for checking requirements 40 29 11 20 69
SREP48 Paraphrasing the various models of system through natural language 48 32 18 02 80
4.7 Requirements Management Practices Table 7 shows that there are 9 requirements management
practices. By applying significance criterion, this can be
observed that all the 9 practices are significant RE practices in
the systems engineering context.
Table 7. Requirements management practices
PID Software Requirements Engineering Practice (SREP) Ranking
IL HPBI MPBI LPBI ZPBI
SREP49 Assigning identifier to each requirement 30 30 33 07 60
SREP50 Formulating policies to manage requirements 43 40 15 02 83
SREP51 Defining policies for requirements’ traceability 41 45 09 05 86
SREP52 Maintaining manual for traceability of the requirements 39 28 26 07 67
SREP53 Developing database for requirements management 41 31 19 09 72
SREP54 Defining policies to support requirements change management 30 33 31 06 63
SREP55 Detecting global system requirements 44 43 09 04 87
SREP56 Detecting requirements that are expected to change 47 24 17 12 71
SREP57 Keeping track of requirements that are rejected 31 39 27 03 70
Thus (7 + 12 + 8 + 5 + 6 + 8 + 9) 55 RE practices are
significant in systems engineering context.
5. CONCLUSION This study aims at improving the RE process in systems
engineering context. For this purpose, survey research method
has been employed. One hundred practitioners have
participated in the study through the emailed questionnaire.
The respondents have been solicited to rank the Sommerville
and Sawyer’s 57 RE practices for the seven areas of
requirements documentation, elicitation, analysis and
negotiation, description, modeling, validation and
management.
The practitioners have ranked the given RE practices
according to the perceived benefits of the practices in systems
engineering context. The four ranks or categories of the
perceived benefits are high, medium, low and zero. By
analyzing the data and applying the 50% criterion for
significance, we have explored 55 software RE practices that
are significant for RE process in systems engineering context.
The study suggests to adopt the identified significant RE
practices to ensure an effective RE process in systems
engineering context
Circulation in Computer Science
International Conference on Engineering, Computing & Information Technology (ICECIT 2017), pp:14-18
www.ccsarchive.org
18
6. REFERENCES [1] Feng, S., Setoodeh, P., & Haykin, S. (2017). Smart
home: cognitive interactive people- centric internet
of things. IEEE Communications Magazine, Volume 55,
No. 2, pp. 34–39.
[2] Stojmenovic, I., Wen, S., Huang, X., & Luan, H. (2016). An overview of fog computing and its security issues.
Concurrency and Computation: Practice and Experience,
Volume 28, No. 10, pp. 2991–3005.
[3] Wasson, C. S. (2015). System engineering analysis, design, and development: concepts, principles, and
practices. Wiley, 2nd edition, pp. 2.
[4] Bhat, J. M., Gupta, M., & Murthy, S. N. (2006). Overcoming requirements engineering challenges:
lessons from offshore outsourcing. IEEE Software,
Volume 23, No. 5, pp.38–44.
[5] Sommerville, I., & Ransom, J. (2005). An empirical study of industrial requirements engineering process
assessment and improvement. ACM Transaction on
Software Engineering and Methodology, Volume 14, No.
1, pp. 85–117.
[6] Mead, N. R. (2007). How to compare the Security Quality Requirements Engineering (SQUARE) method
with other methods. Report No. CMU/SEI-2007-TN-021,
Software Engineering Institute, Carnegie-Mellon
University, Pittsburgh.
[7] Martins, L. E. G., & Gorschek, T. (2017). Requirements engineering for safety-critical systems: overview and
challenges. IEEE Software, Volume 34, No. 4, pp. 49–
57.
[8] Martins, L. E. G. & Gorschek, T. (2016). Requirements engineering for safety-critical systems: a systematic
literature review. Information and Software Technology,
Volume 75, pp. 71–89.
[9] Morandini, M., Penserini, L., Perini, A., & Marchetto, A.
(2017). Engineering requirements for adaptive systems.
Requirements Engineering, Volume 22, No. 1, pp. 77–
103.
[10] Holtmann, J., Bernijazov, R., Meyer, M., Schmelter, D.,
& Tschirner, C. (2016). Integrated and iterative systems
engineering and software requirements engineering for
technical systems. Journal of Software: Evolution and
Process, Volume 28, No. 9, pp. 722–743.
[11] Mauborgne, P., Deniaud, S., Levrat, E., Bonjour, E., &
Micaëlli, J. P., Loise, D. (2016). Operational and system
hazard analysis in a safe systems requirement
engineering process – application to automotive industry.
Safety Science, Volume 87, pp. 256–268.
[12] Woldeamlak, S., Diabat, A., Svetinovic, D. (2016). Goal-
oriented requirements engineering for research-intensive
complex systems: a case study. System Engineering,
Volume 19, No. 4, pp. 322–333.
[13] Miller, T., Pedell, S., Lopez-Lorca, A. A., Mendoza, A, Sterling, L., & Keirnan, A. (2015). Emotion-led
modelling for people-oriented requirements engineering:
the case study of emergency systems. Journal of Systems
and Software, Volume 105, pp. 54–71.
[14] Schubert, L., & Jeffery, K. (2015). New software engineering requirements in clouds and large-scale
systems. IEEE Cloud Computing, Volume. 2, No. 1, pp.
48–58.
[15] Peña, M., & Valerdi, R. (2015). Characterizing the impact of requirements volatility on systems engineering
effort. System Engineering, Volume 18, No. 1, pp. 59–
70.
[16] Sommerville, I., & Sawyer, P. (1997). Requirements engineering- a good practice guide. Practical Process
Improvement, Wiley, 1997, pp. 15–36.
[17] Niazi, M., Attar, M. E., Usman, M., & Ikram, N. (2012). GlobReq: a framework for improving requirements
engineering in global software development projects:
preliminary results. Proceeding of 16 th
International
Conference on Evaluation & Assessment in Software
Engineering, pp. 166–170.
[18] Cox, K., Niazi, M., & Verner, J. (2009). Empirical study of Sommerville and Sawyer’s requirements engineering
practices. IET Software, Volume 3, No. 5, pp. 339–355.
[19] Rainer, A., & Hall, T. (2002). Key success factors for implementing software process improvement: a maturity-
based analysis. Journal of Systems and Software,
Volume 62, No. 2, pp.71–84.
[20] Niazi, M., Wilson, D., & Zowghi, D. (2005). A maturity model for the implementation of software process
improvement: an empirical study. Journal of Systems and
Software, Volume 74, No. 2, pp. 155–172.
CCS | 2018 | ISSN 2456-3692
Published by: CSL Press, USA
