Critical Review Paper

Journal:
'Remo N. Ferrari and Nazim H. Madhavji (2008) Architecting-problems rooted in requirements.
Information and software technology, 50 (1-2). Pp.53–66.'

Introduction:
The above selected paper carries out a study on the requirements orientated problems for software
development architecting and using the requirements for the architecting process. This paper is a
systematic study of the requirements orientated problems. The paper has good introduction, explanation
of the methodology and the conclusion derived from given data analysis. With logical flow that starts
with explanation of the problem statement and ends with the conclusion and the hypothesis for further
research implications.

Summary:
The introduction explains the rationale of the paper and the research carried out in the subject
area of requirements architecting. Importance is emphasized of the requirements in the software
development and the architecting process. The necessity to take an effort towards the software
engineering as is done with the requirements engineering during the systems development process is
stated. Authors pose an important question about the problems that are faced during software
development process regarding the requirements orientated problems. Authors say that the research
question means to look in the software architecting process and find the way of using the requirements
during this software architecting process. Authors want to study the treatment of the requirements
during this early stage of software architecting in the systems development process. Other areas where
the requirements are used are not included in the study and the focus remains on the requirements
orientated problems during the software architecting. The study and reducing the requirements
orientated problem affects the quality positively of the overall software development. Authors have
spend good number of words to define the problem or the research statement in the introduction. The
methodology is explained, used by the authors for the study. The authors have used the data from the
16 different development teams or the architects. These 16 different systems development teams are
working on the requirements of a banking application. The study was carried out parallel in the 16
different teams. The 16 teams are further divided into two groups of requirements engineering people
and non requirements engineering people. This was determined by the authors by a questionnaire. The
banking project that had to be considered for development and architecting was related to the ATM,
online banking and phone banking. Total 85 requirements had been provided to the architecting teams.
The requirements had been checked and validated by experienced team of five of analysts. The task for
the architecting teams was to develop and document the requirements and systems architecture.
Feedback was recorded by the authors from the architecting teams when there were difficulties and
issues with the task. This feedback is used by the authors to find out the difficulties faced by the
architecting teams. Data is collected from such feedback and the recorded architecting problems. The
data is analyzed is carried out on the data collected as discussed. The analysis of the RO problems has
not revealed any new category but the authors have found out three different levels, severe, moderate
and mind. The problems are stated that the teams and given the analysis of the researchers. The levels
of the difficulties are discussed. After data analysis, validation of the data analysis carried out.
Validation process is discussed and the limitations of the validation is stated. The validation procedure
is explained in detail and types of validation with their description are given in the research paper. The
paper talks on the results for the analysis. The results are interpreted and implications are found using
that interpretation. The results show 35% of the problems are related to the RO when the total number
of problems considered. Therefore authors state that this area is of more importance to be analyzed
further due the percentile significance of the RO problems. The authors have drawn a table showing the
RO problems for the teams with the difficulty levels. Testing these results and drawing the table the
authors find out statistically that the significance of the RO problem has to be dealt by the requirements
engineering community. The major areas of problems are identified and a pie chart is drawn to illustrate
those. Further all the identified RO problems are discussed in detail. These areas of less or no problem
are stated. Authors compare the problems of RO against the knowledge of RE and non RE teams of
architecting. This comparison or the analysis is done to find the significance of the knowledge of RE
when the RO problems are considered while architecting. After the statistical analysis, authors state that
the RE experienced teams had relative less problems than those faced by the non RE experienced
teams. The technological requirements are deals better by the RE experienced teams. A graph shows the
exact finding of the comparison between the RE and the non RE teams. The summary gives a clear idea
of the results that have been found by the study of the author. This study has artifacts in form of two
hypothesis. These hypothesis give the implications for the further research in the area of RO problems.
The conclusion by the authors describe the study and the emphasize the results found from the data
analysis and validation. The summary of the major RO problems is given in the conclusion. The
limitations and the constraint of this study are also mentioned in this part but the significance and the
results are said to have significant importance in the area of RO problems during the architecting of the
software systems.
Critical Review:
The study carried out by the authors is of the software development architecting and the use of
the requirements. The abstract describes the research question in an effective way which gives the
reader a clear idea about the content of the paper. This view of RE being an important area has been
supported by researchers (Alves, et.al,2010). Bail(2006) supports the view of the authors that the
requirements engineering that there is need of research in this area of software architecting. The view
point of this paper differs on a way that this paper does not concentrate on the RE but instead studies
the problematic RO during the architecting of the software. The authors pose an important question
about the problems that are faced during software development process regarding the requirements
orientated problems which is supported by Team(1996). The areas where the requirements are used are
not included in the study and the focus remains on the requirements orientated problems during the
software architecting process. But the literature by Swartout and Balzer(1982) emphasizes the
intertwining of the specifications or the requirements and the implementations. Therefore to keep aside
the RE becomes impractical. Another study by De Boer and Vliet(2009) indicates that there are
different opinions about the relationship between the requirements and the architecting.
Authors say that the study and reducing the requirements orientated problem can have a positive
effect on the quality of the overall software development. A study by Kirner(1997) supports this
statement on getting the desired quality from the requirements understanding. In the introduction of this
paper the authors have spend good number of words to define the problem or the research statement.
The introduction gives the rationale and the scope of the study and the logical flow is maintained
during and after the introduction. This makes it easy for the reader to understand the purpose of the
research paper. The study by Saiedian and Dale(2000) supports the notion that requirements
engineering acts as the connection between the consumer and the systems developers but does not talk
about the tools and the techniques used to reduce the problematic requirements. The methodology used
by the authors is qualitative. Quantitative analysis follows thereafter. A study by Eisenhardt(1987)
describes that the effectiveness of a research can be maximum when both the methodologies are used.
Authors have undertaken an effective analytical method and the validation after the analysis. Therefore
these results are validated and tested to be correct and perfect. The data from the 16 different
development teams indicates a good sample size. 'Attribute driven design' is the methodology used by
the architecting teams. In this case authors does not mention the other successful frameworks and
methodologies that are used, as described by Pohl(1994). Aurum and Wohlin(2003) describes few
models using the combination of the RE techniques to overcome the problematic RO (Nguyen and
Shanks,2009). The severity of the problems vary in each case. The 16 teams are further divided into
two groups of requirements engineering people and non requirements engineering people. Total 85
requirements had been provided and the requirements had been checked and validated by experienced
team of five of analysts. Author does not describe the teams as is important according to Levy(2010).
The task for the architecting teams was to develop and document the requirements and systems
architecture. Feedback was recorded by the authors from the architecting teams when there were
difficulties and issues with the task. This feedback is used by the authors to find out the difficulties
faced by the architecting teams. Data is collected from such feedback and the recorded architecting
problems. 'Ethnographic' method is followed to conduct the interviews of the architecting teams. The
analysis of the RO problems found out three different levels, severe, moderate and mild. Authors have
produced a table which gives a clear understanding of the categories. But the categories described by
Maiden and Hare(1998) show different categories to be important. The authors do not talk about these
categories. The researchers have stated the problems of the teams and given the analysis of the
researchers. The levels of the difficulties are discussed as well. After the analysis of the data collected
from the teams, validation of the data analysis carried out. Further validation process is discussed and
the limitations of the validation is stated. The validation procedure is explained in detail and types of
validation with their description are given in the research paper. The authors donot include any
procedures for treatment of the requirements which is given by Karlsson, Wohlin and Regnell(1998),
which describes the methods and the benefits of prioritizing the software requirements or the
specifications.
The results are interpreted and implications are found using that interpretation. The results state
that 35% of the problems are related to the RO when the total number of problems are considered. The
understanding of the RO problems across the teams is made easier by the authors by a table showing
the RO problems and the difficulty levels. Testing these results and drawing the table the authors find
out statistically that the significance of the RO problem. The major areas of problems are identified and
a pie chart is drawn to illustrate those. All the identified RO problems are discussed in detail making
the reader understand the problems. Authors have discussed the issues which were not problematic to
the architecting teams. The study can be said a complete and well balanced.

Conclusion:
It can be concluded after the that the overall paper has a good flow of subject and the problem
area is discussed by the authors. The scope of the research is restricted to the problem statement and the
rationale of the study is stated. The methodology for research is supported by literature and the
statistical analysis gives a dept to the results. The results are validated and the validation is explained in
detail. The conclusion is drawn and stated in easy words. The future implications for the research are
given in the concluding part. In my view the research paper achieves the purpose of the study and can
be said a valuable study in the area of requirements oriented problems in software architecting.

References:
Alves, V., Niu, N., Alves, C., and Valenca G.(2010) Requirements engineering for software product
lines: A systematic literature review. Information and Software Technology, 52(8), Pp.806-820

Aurum, A., and Wohlin, C.(2003) The fundamental nature of requirements engineering activities as a
decision-making process, Information and Software Technology, 45(14), Pp.945-954

Bail W.G.(2006) Requirements Management for Dependable Software Systems. Advances in

Computers, 66, Pp.79-141

De Boer, R.C., and Vliet, H.V.(2009) On the similarity between requirements and architecture.
Journal of Systems and Software, 82(3), Pp.544-550

Eisenhardt K.(1989) Making fast strategic decisions in high-velocity environments. Acad Manage
Journal, 32(2), pp.543–76.

Karlsson, J., Wohlin, C., and Regnell, B.(1998) An evaluation of methods for prioritizing software
requirements. Information and Software Technology, 39(14-15), Pp.939-947

Kirner T. G.,(1997) QUALITY REQUIREMENTS FOR REAL-TIME SAFETY-CRITICAL

SYSTEMS. Control Engineering Practice, 5(7), Pp.965-973

Klaus Pohl (1994) The three dimensions of requirements engineering: A framework and its
applications. Information Systems, 19(3), Pp.243-258

Levy S.M.(2010) Selecting and working with an architect. Construction Process Planning and
Management, Pp.13-44

Nguyen, L. and Shanks G.(2009) A framework for understanding creativity in requirements

engineering. Information and Software Technology, 51(3)Pp.655-662

Saiedian, H. and Dale, R.(2000) Requirements engineering: making the connection between the
software developer and customer. Information and Software Technology, 42(6), Pp.419-428

Swartout, W. and Balzer, R. (1982) On the inevitable intertwining of specification and implementation,
Communications of the ACM. 25(7), pp.438–440

Team, N. (1996) Defining visions in context: Models, processes and tools for requirements
engineering. Information Systems, 21(6), Pp.515-547