1

Information Systems Engineering

Introduction
The invention and further development of computer technologies has brought a lot of
advantages into our everyday life. We use computer technologies everywhere, including home.
All scientific calculations and experiments, business processes, regular life of people, and so on
all these spheres use computer technologies, or we may call it information technologies (IT).
However, it is clear that computers are only tools that are designed to perform particular tasks. It
is also rather obvious that such sophisticated and complex hammers and wrenches must be
controlled by the end users via intermediates software tools.
The appropriate software is the key to the efficient and convenient usage of the computer
technologies. Software controls the systems, gives commands to the computer or other device on
how and when these commands must be executed. On the other hand, software is made to solve
certain, sometimes, very particular issues and perform necessary tasks. Who has to decide what
kind of architecture future software project will have? The answer is rather obvious and lies on
the surface software designers and developers. Do they know the exact needs of those who will
work with this software product? They definitely do not have such information.
The process of the requirements elicitation and further analysis is called requirements
analysis. The value of the analyzed information and the final conclusions, made on its basis
cannot be overestimated. This paper is aimed at exploring the role of the requirements analysis in
software development, evaluate the traditional and novel approaches and compare them. The
main goal of this paper is to show that there are several approaches can be applied to the
requirements analysis and that different situation might require different approaches. The
development in this area is reflected in the evaluation of novel approaches.

2
Role of Requirements Analysis in Software Development
The requirements analysis can be defined as ..a term used to describe all the tasks that
go into the instigation, scoping and definition of a new or altered computer system.
Requirements analysis is an important part of the software engineering process; whereby
business analysts or software developers identify the needs or requirements of a client; having
identified these requirements they are then in a position to design a solution. (WordIQ.com,
n.d.). In other words, this is the process of gathering together and checking for feasibility and
common sense the requirements that the stakeholders have or might have to the future software
product.
Software development is a rather complicated and continuous process that does not
always give the desired results. As a matter of fact, more than a half of the created software
products simply does not work as expected. The reasons of such frustrating situation are the
flaws in requirements analysis approaches. That is why the role of requirements analysis in the
development of the efficient, useful software is crucial (Zhu, n.d.).. The major goals of any
requirements analysis are as follows: To document the requests (needs) of the end users for the
further analysis and to be able to refer to these sources (emails, various prototypes, documents of
different kinds, etc.) in the process of the software development; to make sure that the software
product, developed according to the documented needs, fits with the main efficient features, such
as speed of work, feasibility, and the overall reliability; and to understand what resources are
going to be necessary to make the software work efficiently and properly (Zhu, n.d.).
In the process of the requirements analysis it is easy to come to the unexpected
conclusion: It is very difficult to make software product that will meet all requirements of the
stakeholders. Such kind of discovery is rather surprising. What could be easier than to determine

3
all feasible needs and requirements that the end users have and implement them in one
integrated, comprehensive solution that can solve particular tasks? Unfortunately, the real-life
state of things is much more complicated. The common problem of all requirements analysis
approaches is in the lack of understanding by the end users of what they really need instead of
what they want to have in the work process.
This is the main reason of the fact that more than a half of developed software simply
does not work as it should be (WordIQ.com, n.d.). End users do not have the functionality of
software they asked about before. It happens because of several problems that analysts
experience in the requirements elicitation process. The first problem can be described as lack of
understanding by the end users and other stakeholders of what they really need to have in the
functionality of the developing software. Usually, they easily determine what they want to see
there but nothing else. The second problem the analysts commonly face is the inaccurate and
blurred expression of the end users thoughts and wishes (Hay, 2003; Maciaszek, 2007).
It plays a crucial part as it influences the overall understanding of the functionality that
must be realized. The final major challenge for the requirements analysts is the continuously
incoming requirements from the stakeholders. Such situations happen all the time when the list
of requirements is set and approved, signed by the stakeholders and then the new requirements
start to appear. The overall process of development becomes very slow and usually does not fit
the time frame. The worst thing is that the final product does not meet the requirements of the
end users so the whole project, time and money, spent on it become useless and meaningless
(Hay, 2003; Maciaszek, 2007).
The role of the requirements analysis on the initial stage of the software development
project is very substantial. As well, as the communication, language, and technical skills are very

4
important for the requirements analyst to be able to single out the really necessary and important
requirements and try to persuade end users regarding meaningless and useless ones. Professional
requirements analyst should also clearly understand the tools, methods, and approaches to the
requirements analysis in order to be ready to use exactly the tools that are appropriate and useful
in every particular situation.
The above noted issues can be resolved by a strong professional with adequate skills and
abilities on the one side and a rather reasonable and technically educated end user on the other.
However, it does not change the fact that this reasonable end user will not change something in
the future and that there will not be new requirements (Hay, 2003; Maciaszek, 2007). So we can
come to the conclusion that requirements elicitation and further analysis of the data is a
continuous process in the software development. Unfortunately, the continuous changes brought
to the project according to new needs of the end users negatively influence the quality of the
final product and make it impossible to keep the development process within the previously set
timeframe.
Inaccurate and blurred end user requirements impact the final software product quality
too. The thing is that the inaccurate and inexact abstract request can be fulfilled in full by lucky
chance only. The current situation is the same. Although the end users want to have particular
features and usability in the future project, they do not usually have enough desire to describe the
ideas and requests in a clear and understandable way. Unclear and inaccurate requirements can
be misinterpret, misunderstood by the requirements analysts and later by the software developers
(Hay, 2003; Maciaszek, 2007). The resulting product will surely differ from the initial idea,
while the money for the project creation, development, and further implementation have already
been spent. The cost of such inaccurate requirements can be rather substantial in some cases. It is

5
clear that the software can be changed. However, further requirements analysis and
implementation of the changes to the software product are time consuming, complex, and cost
money.
Such state of things has two sources. The first one has already been mentioned above
the end users and stakeholders do not realize the actual needs, they express only their wishes in
regards to the required features. The second source of the overall problematic situation is
partially connected with the vocabulary gap between the end users and software analysts. It
happens because the requirements analysts receive information regarding the business processes
that are not entirely clear for them. The same situation is with the end users. These people do not
know the technical side of the process but understand the business processes much better. In
other words, end users, requirements analysts, and business analysts usually speak different
languages. Eventually, the situation with the requirements to the future software product
becomes crucial (Montabert et al., 2009).
The requirements analysis in the software development process plays a more important
role than just simple list of requirements and their analysis for feasibility and usefulness within
the future project vision. It more like understanding of what necessary features and instruments
should be added to the project to make it fit the needs of the end users and other stakeholders.
Without the proper requirements analysis the software product will be most likely very different
from the clients original idea (Montabert et al., 2009; Hay, 2003).
Traditional Approaches to Requirements Analysis
As any other analysis, requirements analysis has orthodox, traditional approaches, tools
and methodologies, as well as novel, advanced ones. The traditional approaches are well-studied
and have already proven their consistency as the appropriate, useful, and ready to use in most of

6
the cases. Novel approaches are usually developed and explored in order to improve the existing
traditional ones or try to look at the abstract problem under the different angle. It can be said that
novel approaches develop and improve the existing methodology, make it evolve and be
contemporary. Anyway, the traditional approaches that are going to be discussed in the paper
are: interviewing, use cases, prototyping, and agile software development (Hay, 2003;
Maciaszek, 2007; Zhu, n.d).
Interviewing approach. This type of approach is based on face-to-face, personal
communication with the end users and/or stakeholders. The idea of the approach is to find out
from the end users the types of features they want to see in the future software product. The
requirements analysts ask previously prepared questions to the end user. Usually two analysts are
needed to facilitate the process of documenting the interview without interruptions. Such model
of interviewing allows to communicate one of the analyst with the interviewee without any
difficulties, like stops to write something down. The other analyst documents the process and
makes notes in regards to present his evaluation of the ideas later (Maciaszek, 2007; Zhu, n.d).
The main goal of this approach is get an understanding of technical capabilities of the
future project that end users point out as must be. However, as it was noted before, end users
usually are not able to speak the technical language and express their ideas and thoughts in
technical terms to facilitate the work of requirements analysts. That is why software analysts
must prepare such examples that will help end users to generate ideas and let analysts understand
the connection between these ideas and technical side of the possible features (Hay, 2003; Zhu,
n.d). The generation of ideas is very useful for the requirements analysts. They can see each
vision of the future project and summarize the data in order to elicit the most common features
that the vast majority of stakeholders seek in the future software product.

7
Another positive side of the end users interviewing is an opportunity to understand the
issues that these users currently have with the software. It is as well important as to get to know
the information about the desired functionality because the information about the flaws and
deficits in the current software along with the information about necessary features can help
software developers to create the product that will meet the most of the end users needs. After
all, this is the main goal of any requirements analysis (Hay, 2003; Zhu, n.d).
Use cases approach. This type of approach is used to present the possible future system to
the end users via the one or set of scenarios that suggest the possible interactions of the end users
with this system. The use cases are focused on the process of accomplishing the goal but not on
the technical side of the process. So they are rather formal and do not present the exact features
or capabilities of the future system. The main idea of the approach is to develop a vision of a
system, its principles and main formal features (Hay, 2003; Outsource2India.com, n.d.).
Therefore, use cases are aimed at creating a formal picture of the future system that
should be created. Use cases give an opportunity to see the concept of the future system as a
whole but not just a set of useful features. It helps analysts make improvements and makes the
process of the development more clear and understandable for the software developer. Use cases
also reduce assumptions that analysts usually have in the process of the concept development.
These assumptions are expectedly based on the previous experience and professional,
technical vision of the future software product. However, such assumptions are not always right
and this can create additional, unnecessary issues that will affect the quality of the product (Hay,
2003; Outsource2India.com, n.d.).. As it was mentioned before, use cases give the conceptual
vision of the system to be built. The most important thing in use cases approach is that this vision
is created mostly by the end users, while the requirements and business analysts just offer the

8
different ways of solving business tasks. Use cases do not contain any particular features or
solutions in the scenarios so they should be used on the initial stages of the requirements analysis
to determine the concept of the future software.
The best possible result on this stage can be achieved via the close cooperation of the
requirements analysts, business analysts, end users, and other stakeholders. Only joint these
forces and very different points of perspective can make future software product a
comprehensive and useful tool, but not just another software that simple does not work. Use
cases approach is one of the most important in the requirements analysis to determine functional
requirements on the early stages of the software development process (Hay, 2003;
Outsource2India.com, n.d.)..
Prototyping approach. This approach is more technically oriented in the matter of
creating the vision of the future software design and visual functionality for the end users and
stakeholders. Prototyping is necessary to create a working model of the future system in order to
present it to the end users to see the results and receive feedbacks regarding the overall usability
of the future system (Soundararajan, 2008). This approach is appropriate to use after the
completion of the preparation stages, like the above mentioned interviewing and use cases.
Within this approach end users can actually see the future software system that should meet their
requirements, make new requirements, and offer improvements. Software developers are able to
test main functions of the future system and make necessary corrections and implement
functional improvements in order to satisfy both end users and requirements analysts
(Soundararajan, 2008).
The major benefit of the prototyping approach is the visualization of the results. It
encourages end users to participate in the process of further determination of the system

9
requirements. Such visual, easy way of the evaluation facilitates the process of further
improvement, functional and ideological, which is utterly important to achieve the main goal of
the new software development to meet the requirements of the stakeholders. Another important
benefit from using prototyping is affordability of the visualization. The software product must be
developed anyway so the prototypes of the software system are the real possible versions of the
future product (Outsource2India.com, n.d.).
This approach is aimed at presenting real functionality of the end product, and realizing
the initial ideas as the working system. End users can see the implementation of the their
requirements from the interview stage, other stakeholders can evaluate the usability and the
overall functionality, basic and limited though. Prototyping helps specialists on both sides to
evaluate the intermediate results of the joint work in order to make corrections, improve or
rebuild some functional units of the future software system. It is necessary to be sure that the
software development project moves in the right direction, which is a rather important sign for
the both sides (Outsource2India.com, n.d.).
Agile software development approach. This type of approach is similar to prototyping but
has several important peculiarities that make it very useful in some cases. The main idea of this
approach is in the development of complete software products according to the development
plan. In general, the list of requirements analyzed by the specialists from the software
development company is the plan (Soundararajan, 2008). The similarity to prototyping is in the
idea of creating a working software. However, the agile software development approach
presupposes a step-by-step development process in order to create the product with one or two
completely functional features.

10
This approach is aimed at achieving two goals at a time. The first goal is to create fully
functional and complete a module of a bigger system. The second goal is to minimize the risks of
creating the software that does not have the required by end users features (Soundararajan,
2008). The process of agile software development is divided into subsequent steps. On each step
that lasts from one to four weeks, the requirements analyst, software developer and end users
work on the implementation of one or several particular requirements and features into the a
actually working, complete product. The size of the group can vary due to the size of the initial
project (Soundararajan, 2008).
The above described approach allows end users, requirements analysts, and software
developers be in a close contact during this session in order to improve the exact part of the
project as much as possible. Each session includes all steps of the software product development
process, such as planning, analysis, design, coding, testing and documentation. The complete
product with the limited functionality is the result of their work. Such agile approach gives the
analysts an opportunity to work on the particular part of the project instead of the whole project
at a time. It allows developers, analysts, and end users to be focused on the particular functions,
which in turn results in the time frame and the quality of the outcome product in a positive way
(Soundararajan, 2008).
A Comparison of Requirements Analysis Approaches
Every approach, described above, has its advantages as well as disadvantages. There are
no perfect or universal tools, methods, approaches since we have so many of them instead of
few. The comparison of these approaches, evaluation of their strong sides and weaknesses can
give us an understanding of such important things as when and how these approaches to

11
requirements analysis should be applied. The combination of approaches can be more beneficial
than using them one by one (Maciaszek, 2007; Hay, 2003).
Interviewing has such benefits as focusing on the end users and their wishes and needs. It
allows the requirements analysts assessing the needs of the end users and document them directly
from the source rather quickly and efficiently. These are the main strong sides of the
interviewing approach. The analysts are able to communicate with end users and stakeholders
rather intensively. Therefore, they are able to clarify any confusing moments, create meticulous
documentation in order to refer to it later if necessary. The above mentioned advantages should
be used as the most effective tool to find out the real needs of end users and create
comprehensive documentation regarding these needs for the future (Maciaszek, 2007; Hay,
2003).
However, this approach has one serious disadvantage time. Interviewing of all end
users in order to find out their slightest issues with current software and document their needs is
very time consuming. It may affect the overall project developing process and the final cost of
the software product. Time always matters. Just imagine a company with a thousand of
employees. All of them are end users somehow. How much time will it take to interview all of
them? It might take forever and that is the point (Maciaszek, 2007; Hay, 2003).
The advantages of user cases approach are rather substantial too. The major advantage is
an opportunity to create the vision, the understanding of the entire concept of the future project
by the end users and software analysts. The end users get the idea of the project to be created and
affect the its structure by changing requirements. The requirements analysts receive the
necessary information regarding the functional requirements of the project. It is crucial for the

12
initial stage to have a clear understanding of what should be done and how it should look at the
end.
However, use cases cannot be applied to capture the non-functional requirements.
Although it might not be that important in the overall progress, but these requirements need to be
determined still. Clarity of the templates, used in the use cases scenarios, is also questionable,
which is rather disadvantageous too (Maciaszek, 2007; Hay, 2003). The scenarios should be well
understood by the end users and appropriately interpreted by both the analysts and end users
sides. It does not happen like this all the time and the lack of clarity and incompleteness of the
scenarios definitions causes differences in the interpretation by the analysts and end users. In
turn, miscommunication between the end users and requirements analysts can create substantial
problems for the further proper development of the project (Maciaszek, 2007; Hay, 2003).
As for the prototype approach, its advantages are time efficiency and cost of prototype
development. This approach allows software developers visualizing the future software system
and create a working model rather quickly. It does not take that much time and it is rather
affordable for most of the companies. The interaction with end users on the practical level where
they can try out the software is very beneficial for the development process too because the end
users make their suggestions and corrections on the fly.
Also, this interaction with the prototype rather quickly determines the level of end user
satisfaction. It is important to make those corrections and add exactly what features that end
users would like to see in the end product to be satisfied with the software product during the
everyday activities. Such approach eases the process of prototype improvement and thus
facilitate the overall project development (Maciaszek, 2007; Hay, 2003).

13
Despite the positive influence on the requirements elicitation process, prototyping has
several disadvantages. The lack of sufficient analysis of the feedbacks from the end users can
decrease the value of the product. It is connected with relatively short periods of time, spent for
the prototype development. Another substantial disadvantage of the prototyping approach is the
attachment of software analysts to their prototypes. They begin to improve prototypes
disregarding necessity and common sense that eventually leads to the sophistication of the
prototype and eliminates the time and low cost advantage.
The agile software development approach has benefits and disadvantages as well as all
three approaches, mentioned before. This type of approach is able to assure minimal risks during
the software development process. Such substantial advantage is achieved by numerous
intermediate stages of the software development process, called iterations (Maciaszek, 2007;
Hay, 2003). Each includes a full cycle of development and allows analysts to determine
problems with software and divergences with end users needs. Since every iteration of the agile
software development process completes with finished product it is very easy to complete the
whole project in time and without serious alterations in the final software product.

14
Works Cited
Geisser, M. & Hildenbrand, T. (2006). A Method for Collaborative Requirements Elicitation and
Decision-Supported Requirements Analysis. International Federation for Information
Processing (IFIP), 219.
Hay, D. C. (2003). Requirements Analysis: From Business Views to Architecture. Upper Saddle
River, NJ: Prentice Hall PTR.
Kim, J-e., Kim, J-k., Park, S., & Vijayan, S. (2004). A Multi-View Approach for Requirements
Analysis Using Goal and Scenario. Industrial Management & Data Systems, 104(9), 702711.
Outsource2India.com (n.d.). Requirements Analysis Process: Requirements Elicitation, Analysis
And Specification. Retrieved from:
http://www.outsource2india.com/software/RequirementAnalysis.asp
Maciaszek, L. (2007). Requirements Analysis and System Design. Harlow, UK: Pearson
Education.
Montabert, C., McCrickard, S. D., Winchester, W. W., & Prez-Quiones, M. A. (2009). An
Integrative Approach to Requirements Analysis: How Task Models Support
Requirements Reuse in a User-Centric Design Framework. Interacting with Computers,
21, 304315.
Soundararajan, S. (2008). Agile Requirements Generation Model: A Soft-structured Approach to
Agile Requirements Engineering. Retrieved from:
http://scholar.lib.vt.edu/theses/available/etd-08132008-193105/unrestricted/ShvethaSThesisFinal.pdf

15
Tastle, W. J., Abdullat, A., & Wierman, M. J. (2010). A New Approach in Requirements
Elicitation Analysis. Journal of Emerging Technologies in WEB Intelligence, 2 (3).
WordIQ.com (n.d.). Requirements analysis Definition. Retrieved from:
http://www.wordiq.com/definition/Requirements_analysis
Zhu, Z. (n.d.). Requirements Determination and Requirements Structuring. Retrieved from:
http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/zhu/