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), 702-

711.

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., & Pérez-Quiñones, 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, 304–315.

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/ShvethaS-

ThesisFinal.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/