Business Analysis

CIA-3
Research Based Assignment
Article: Shah, T., & Patel, S. (2016). A Novel Approach for
Specifying Functional and Non-functional Requirements Using RDS
(Requirement Description Schema). Procedia Computer Science, 79,
852-860. doi:10.1016/j.procs.2016.03.083
http://www.sciencedirect.com/science/article/pii/S1877050916002143

Submitted to,
Prof. N. Ramakrishnan

Submitted by,
Kunnam SP Dheeraj

Reddy,
1528116,
L1.

Introduction:
Requirements engineering basically deals with identifying, analyzing, documenting and
verifying a set of requirements. This process is complex and critical especially when it comes to
development of systems which are software intensive. There can be many errors during
requirements phase because of poor writing, ambiguousness etc. If the requirements are not
specified correctly there can be lot of delay in deliverables and also there can be cost overruns.
So it is important that the requirements have to be elicitated properly and both functional as well
as non-functional requirements need to be considered. In this paper different elicitation
paradigms, including automated as well as semi-automated approaches have been discussed and
compared. The manual requirement specification approach is time consuming, difficult and also
inconsistent. It is also difficult to trace the requirements and it doesnt consider the metadata of
requirements. So a new approach, Requirement Description Schema (RDS), which has a
structured requirement specification format have been suggested in this paper to specify both
functional and non-functional requirements.

Structure of the paper:

In the paper, firstly research related to different markup languages and methodologies, which
cover both functional and non-functional specifications are discussed. Secondly, potential areas
of RDS are discussed. Then the design aspect of RDS specification is explained with the help of
case study on online examination system. Then RDS specification is compared with other
markup languages and is evaluated. And then the possible areas for RDS extension is discussed.

Research methodology used:

Secondary research was done in order to study various markup languages with respect to both
functional and non-functional requirements. Then primary research is done with the help of a
case study to validate RDS design structure and also to compare it with other markup languages
and specifications.

Major findings/results:
Requirement Description Schema (RDS), not only incorporates conventional functional
requirements but also incorporates various non-functional requirements properties with attributes
of privacy and security. RDS is effective and suitable to specify functional and non-functional
requirements including the artefacts. The ambiguity of RDS is found to be relatively low and
represents requirements at module level with artefacts. RDS emphasizes more on metadata of the
requirements. Some RDS conventions also facilitate translation and mapping to requirement
representation systems and this helps in developing semi-automatic processes to elicitate
requirements. Also the advanced architecture of RDS can extend the application of requirements
engineering and service oriented requirement engineering to automated requirement elicitation.
The format of RDS specification can fill the gap between migration and transformation of
functional and non-functional requirements. The RDS data which will be in the form of XML
can be easily transferred to designing team and developing team.

Criticism:
The traditional approach of requirements engineering doesnt consider the metadata of the
requirements and this makes it difficult to process the requirements which are in textual form. So
considering a new approach with structured specification format was good as it is easy to
transform into repositories of requirements in order to trace and manage the requirements. In this
paper, a case study was used to validate Requirements Description schema with respect to few
important requirement elements. As only few elements were considered the scope for specifying
detailed requirements was limited. And also the case study doesnt have much focus on how to
represent complex and unstructured requirement components in the form of interoperable and
electronic forms. When it comes to comparison of RDS with other markup languages only two
aspects i.e. language and requirement engineering are considered and thus limiting the scope of
comparison. And also the markup languages considered for comparison are in a different state of
development. There is no reasoning provided on why these markup languages are considered at
different states. Though the potential areas of RDS are discussed they are not discussed in detail
with the help of case study. And also the RDS schema is represented as a combination of
functional requirement schema, non-functional requirement schema and requirements artefacts
schema. But there is no much explanation about how these schemas are interlinked.