http://www.umsl.

edu/~sauterv/analysis/6840_f03_papers/zhu/

Requirements Determination and Requirements

Structuring

By Zhenyu Zhu

Abstract

Requirements determination and requirements structuring are two core

components of system analysis. Traditionally, interviewing, questionnaires, directly

observing and analyzing documents are four main methods adopted by system

analysts to collect information. JAD and prototyping are two modern requirements

determination methodologies, which are developed and based on the previous

traditional methods. A well-structured representation of system requirements can

dramatically improve the communication among analysts, designers, users, and

programmers. DFD, structured English, decision tables, decision trees, and E-R

diagrams are traditional primary requirements structuring tools. Nowadays, RAD

and OOA are emerging to help streamline and shorten the total SDLC. While RAD
[21]
SDLC packs traditional analysis phase and part of design phase into one step ,

OOA tries to make the outcomes of analysis phase can be reused by the following

developing phases.

Introduction

Analysis is the first SDLC phase where we begin to understand, in depth, the

needs for system. System analysis involves a substantial amount of effort and cost

and is therefore undertaken only after management had decided that the systems
development project under consideration has merit and should be pursed through

this phase. Most observers would agree than many of the errors in developed

system are directly traceable to inadequate efforts in the analysis and design

phases of the life cycle. Industry studies show that 56% of systems problems are

based on poor requirements definition, as opposed to 7% that are caused by poor

coding. In the maintenance arena, 82% of the effort is due to poor requirements as

opposed to 1% for poor coding.[1] However, for many reasons, it is difficult to obtain
[12]
a correct and complete set of requirements.

As analysis can be divided into three main activities: Requirement

determination, Requirements Structuring, and Alternative generation and selection.

The third one is usually regarded as the automatic result from the first two

processes. So, in this article, I focus on requirements determination and

requirements structuring.

Requirements determination is the beginning sub phase of analysis. In this sub

phase, analysts should gather information on what the system should do from as

many sources as possible. There are some traditional methods to help collecting

system requirements, such as interviewing, survey, directly observing users, etc.

Nowadays, some modern requirements colleting methods, such as JAD and

prototyping, emerged.

Requirements structuring is the process to use some kind of systematical and

standard, well-structured methods to model the real world. Traditionally, we use

data flow diagram for process modeling, decision table or decision tree for logic

modeling, and Entity-relationship diagram for data modeling. These modeling tools

usually separately model only one face of the real world. So, when we try to show
the integral picture of a system, we usually choose more than one of the above

requirements structuring methods.

Rapid Application Development (RAD) is an approach that promises better and

cheaper systems and more rapid deployment by having system developers and end

users work tighter jointly in real-time to develop systems. Usually, RAD allows
[14]
usable systems to be built in as little as 60-90 days. RAD is not a single

methodology but is more a general strategy of developing information systems. It

brings several system development components together. Nowadays, a lot of RAD

tools are available, such as VB for windows application, MBBuilder for MapInfo
[16,17]
MapBasic.

Object-oriented analysis and development is a brand new methodology.

Although OOP has become popular in computer world, whether OOA is superior to

traditional methods is still a question mark. However, from the view of OO world,

OOA seems having an important role to play in the future.

The objectives of this article are to introduce some widely adopted basic

requirements determination and requirements structuring methods, compare and

contrast those methods and try to find a best way for system requirements analysis.

Requirements Determination

Collection of information is at the core of systems analysis. Information requirement

determination (IRD) is frequently and convincingly presented as the most critical

phase of information system (IS) development, and many IS failures have been
[13]
attributed to incomplete and inaccurate information requirements. System

analysts must collect the information about the current system and how users
would like to improve their performance with new information system. Accurately

understanding the users requirements will help the system developing team deliver

a proper system to the end users in limited time and limited budget. If user just

wants an ant, definitely, an elephant is improper. There are many methods to

collect information. This article will discuss some basic and widely adopted ones of

them.

Interviewing is one of the primary ways to gather information about an

information system. A good system analyst must be good at interviewing and no

project can be conduct without interviewing. There are many ways to arrange an

effectively interview and no one is superior to others. However, experience analysts

commonly accept some following best practices for an effective interview:

Prepare the interview carefully, including appointment, priming question,

checklist, agenda, and questions.

Listen carefully and take note during the interview (tape record if possible)

Review notes within 48 hours after interview

Be neutral

Seek diverse views

Questionnaires have the advantage of gathering information from many

people in a relatively short time and of being less biased in the interpretation of

their results. Choosing right questionnaires respondents and designing effective

questionnaires are the critical issues in this information collection method. People
usually are only use a part of functions of a system, so they are always just familiar

with a part of the system functions or processes. In most situations, one copy of

questionnaires obviously cannot fit to all the users. To conduct an effective survey,

the analyst should group the users properly and design different questionnaires for

different group. Moreover, the ability to build good questionnaires is a skill that

improves with practice and experience. When designing questionnaires, the analyst

should concern the following issues at least:

The ambiguity of questions.

Consistence of respondents answers.

What kind of question should be applied, open-ended or close-ended?

What is the proper length of the questionnaires?

The third one is directly observing users. People are not always very reliable

informants, even when they try to be reliable and tell what they think is the truth.

People often do not have a completely accurate appreciation of what they do or how

they do it. This I especially true concerning infrequent events, issues from the past,

or issues for which people have considerable passion. Since people can not always

be trusted to reliably interpret and report their own actions, analyst can supplement

and corroborate what people say by watching what they do or by obtaining

relatively objective measures of how people behave in work situation. However,

observation can cause people to change their normal operation behavior. It will
[21]
make the gathered information biased.
 The fourth one is analyzing procedures and other documents. By

examining existing system and organizational documentation, system analyst can

find out details about current system and the organization these systems support. In

documents analyst can find information, such as problem with existing systems,

opportunities to meet new needs if only certain information or information

processing were available, organizational direction that can influence information

system requirements, and the reason why current systems are designed as they
[21]
are, etc.

However, when analyzing those official documentations, analysts should pay

attention to the difference between the systems described on the official

documentations and the practical systems in real world. For the reason of

inadequacies of formal procedures, individual work habits and preferences,

resistance to control, and other factors, the difference between so called formal

system and informal system universally exists.

The fifth one is Joint Application Design (JAD). JAD is a facilitated, team-

based approach for defining the requirements for new or modified information

systems. JAD is started at IBM in the late 1970s. The main idea behind JAD is to

bring together the key users, managers, and system analysts involved in the

analysis of a current system. The primary purpose of using JAD in the analysis phase

is to collect systems requirements simultaneously from the key people involved with

the system. The result is an intense and structured, but highly effective, process.

Having all the key people together in one place at one time allows analysts to see
[2,21]
where there are areas of agreement and where there are conflicts.
 The typical participants in a JAD are: JAD session leader, end users, business

managers, sponsor, system analysts, IS staff, scribe, etc. The JAD team is a group of

from six to sixteen individual who all have a stake in designing a high quality

system. Approximately two thirds of the group members are functional experts the
[2]
other one third are systems professionals. JAD sessions are usually conducted in

a location other than the place where the people involved normally work, and are

usually held in special purpose rooms where participants sit around horseshoe-

shaped tables. Involving so many different kinds of people in one workshop makes
[4,5]
how to effectively and efficiently organize the JAD session a big challenge.

When a JAD is completed, the final result is a set of documents that detail the

workings of the current system related to study of a replacement system. These

requirements definition document generally includes business activity model and

definitions, data model and definition, data input and output requirements. It may

also include interface requirements, screen and report layouts, ad hoc query

specifications, menus, and security requirements. When used at a later point in the

system development life cycle, a JAD session can also be used to refine a system

prototype, develop new job profiles for system users, or develop an implementation

plan. [2]

However, to exploit full potential of JAD, the groupware tools should be

applied in JAD workshop sessions. The use of groupware tools to support the joint

Application Development technique increases the value of this technique

dramatically. When groupware tools are used in an automated JAD workshop, they

greatly facilitate the generation, analysis, and documentation of information. This is

particularly valuable for JAD workshops conducted to define and build consensus on
[3]
the requirements for new systems.

The Sixth one is Prototyping. Prototyping is a means of exploring ideas before

you invest in them. Most system developers believe that the benefits from early

[19,20]
usability data are at least ten times greater than those from late usability data.

Prototyping allow system analysts quickly show users the basic requirement into a

working version of the desired information system. After viewing and testing the

prototype, the users usually adjust existing requirements to new ones. The goal with

using prototyping to support requirement determination is to develop concrete

specification for the ultimate system, not to build the ultimate system from

prototyping. Prototyping is most useful for requirements determination when user

requirements are not clear or well understood, one or a few users and other

stakeholders are involved with the system, possible designs are complex and

require concrete form to fully evaluate, communication problems have existed in

the past between users and analysts, and Tools and data are readily available to
[21]
rapidly build working systems, etc.

When adopting prototyping, analysts should concern about the potential problems

about this requirements determination method, such as informal documentation,

ignored subtle but important requirements, etc.

When we choose requirements determination method for a specific project,

there seven characters of them we should consider. They are Information Richness,

Time Required, Expense, Chance for Follow-up and probing, Confidentiality,

Involvement of Subject, Potential Audience. Table 1 concludes these characters of

previously discussed six requirements determination methods.

Table 1

Characteristic Interviews Questionnaires Observation Document JAD

analysis

Information High Medium to low High Low (passive) High

Richness and old

Time Required Can be Low to moderate Can be Low to Dedicated

extensive extensive moderate period of tim
of all kinds o
involved
people

Expense Can be high Moderate Can be high Low to High

moderate

Chance for Good Limited Good Limited Good

Follow-up and
probing

Confidentiality Interviewee Respondent can Observee is Depends on All the peop

is known to be unknown known to nature of know each
interviewer interviewer document other

Involvement of Interviewee Respondent is Interviewees None, no clear All kinds of

Subject is involved passive, no clear may or may commitment people are
and commitment not be involved and
committed involved and committed
committed
depending on
whether they
know if they
are being
observed
Potential Limited Can be quite Limited Potentially Potentially
Audience numbers, but large, but lack of numbers and biased by biased by th
complete response from limited time which subordinato
responses some can bias of each documents intentionally
from those results were kept or dont want t
interviewed because directly poin
document not out his
created for superiors
this purpose errors.
Requirements Structuring:

In the last section, we discuss about the methods to determine information

system requirements. In this section, we will focus on the widely adopted

methods used to present the requirements. Traditionally, there are three basic

methods for requirements structuring:

Data flow diagrams, it is widely used for process modeling

Structure English, decision tables, and decision trees, they are used for

logic modeling

Entity and relationship diagram, it is used for data modeling

First, a data flow diagram (DFD) is a graphical tool that allows analysts

(and users) to depict the flow of data in an information system. DFD graphically

representing the functions, or processes, which capture, manipulate, store and

distribute data between a system and its environment and between components
[21]
within a system. The final deliverables and outcomes for DFD are:

Context data flow diagram, which defines the boundary of the system

DFDs of current physical system, which is used to determine how to

convert the current system into its replacement.

DFDs of current logical system

DFDs of new logical system

Thorough descriptions of each DFD component

 In a DFD, there are only four symbols that represent the same things: data

flows, data stores, processes, and source/sinks (or external entities). A data flow

can be best understood as data in motion, moving from one place in a system to

another. A data store is data as rest, which may take the form of many different

physical representations. A process is the work or actions performed on data so

that they are transformed, stored, or distributed. Source/sink is the origin or

destination of data, sometimes referred to as external entities.

Data flow diagrams should be mechanically correct, but they should also

accurately reflect the information system being modeled. To that end, analyst

should check DFDs for completeness and consistency and draw them as if the

system being modeled were timeless. Complete sets of DFDs should extend to

the primitive level where every component reflects certain irreducible properties.

Following above guidelines, DFDs can aid the analysis process by analyzing the

gaps between existing procedures and desired procedures and between current
[21]
and new systems.

Second, logic Modeling involves representing the internal structure and

functionality of the processes represented on data flow diagrams. In the analysis

phase, logic modeling will be complete and reasonably detailed, but it will also

be generic in that it will not reflect the structure or syntax of a particular

programming language. There are three traditional tools for logic modeling:

structure English, decision tables and decision trees. Structured English is

modified form of the English language used to specify the logic of information

system processes. Although there is no single standard, structured English

typically relies on action verbs and noun phrases and contains no adjectives or

adverbs. Decision table is a matrix representation of the logic of a decision,

which specifies the possible conditions for decision and the resulting actions.
Usually, there are there parts in a decision table: the condition stubs, the action

stubs, and the rules. A decision tree is a graphical technique that depicts a

decision or choice situation as a connected series of nodes and branches.

Decision trees have two main components: decision points and actions. Nodes

represent decision points, while actions are represented by oval. The comparison

among these three is showed in following table 2:

Table 2

Criteria Structured English Decision Table Decision Tree

Determining Second Best Third Best Best

conditions &
actions

Transforming Best Third Best Best

conditions &
actions into
sequence

Checking Third Best Best Best

consistency &
completeness

[21]
The comparison between decision table and decision trees is shown in table 3.

Table 3

Criteria Decision Tables Decision Trees

Portraying complex logic Best Worst

Portraying simple Worst Best

problems

Making decisions Worst Best

More compact Best Worst

Easier to manipulate Best Worst

Third, data modeling develops the definition, structure, and relationships

within the data. Many analysts believe that a data model is the most important

part of the statement of information system requirements. This belief is based on

following reasons:

The characteristics of data captured during data modeling are crucial in

the design of databases, programs, computer screens, and print reports

Data rather than processes are the most complex aspects of many modern

information systems and hence require a central role in structuring system

requirements.

The characteristics about data (such as length, format, and relationship

with other data) are reasonable permanent.

The most common format used for data modeling is entity-relationship (E-R)

diagramming. E-R data model is a detailed, logical representation of the data for

organization or for a business area. There are three main constructs in E-R

diagram: data entities, relationships, and their associated attributes. An entity is

a person, place, object event, or concept in the user environment about which
the organization wishes to maintain data. Each entity type has a set of attributes

associated with it. An attribute is a property or characteristic of an entity that is

of interest to the organization. Relationships are the glue that holds together the

various components of an E-R model. A relationship is an association between

the instances of one or more entity types that is of interest to the organization.

Advanced system analysis:

Nowadays, there are other two very widely adopted methods for system

analysis. They are Rapid Application Development (RAD) and Object-Oriented

analysis. These two are always labeled as advanced system analysis or modern

system analysis. The popularity of these two methods owes to the high pressure

of todays quickly changed business environment. The present end-users cannot

wait for two to three years to have a system. So, streamlining the SDLC and

shortening the total SDLC play a critical role in system development. To achieve

this goal, RAD tries to compact several phases into one single step while OOA try

to make the analysis phase seamlessly pass to OO design phase.

RAD is an approach to developing information systems that promises better and

cheaper systems and more rapid deployment by having systems developers and

end users work together jointly in real time to develop. RAD grew out of the
[10, 21]
convergence of two trends

Te increased speed and turbulence of doing business. As global

competition increases, processes for detecting and satisfying customers

must be redesigned and continuously improved. To do this, information

technology should be merged into business-process design as early as

possible.
 Ready availability of high-powered computer-based tools to support

systems development and easy maintenance.

Comparing with seven phases standard SDLC, RAD SDLC has only four

phases. They are planning, design, development, and cutover. RAD pushes

analysis and part of design jobs of standard SDLC into one design step. Actually,

RAD is not a single methodology but is instead a general strategy of developing

information systems, which takes account human factors and corporate culture
[11]
as well as technology. To succeed, RAD relies on bringing together several

system development components, such as JAD, prototyping, and all kinds of

[9]
traditional requirements structuring methods. It is impossible to do so without

using the high-powered computer-based tools such as visual tools and integrated

CASE tools, which include code generators for creating code from the designs

end users and analysts create during prototyping. According to Martin, there are

four necessary pillars for RAD approach: tools, people, methodology, and

management.

[21]
Advantages of RAD:

Time saving, money saving, human effort saving

Tighter fit between user requirements and system specifications

Best fit for quickly changed business environment

Concentrates on essential system elements from user viewpoint.

[21]
Disadvantages of RAD:

High costs of commitment on the part of key user personnel

 Easy to ignore some issues, such as missing information on underlying

business processes, inconsistent internal designs with and across systems,

lack of scalability, lack of attention to later systems administration built

into the system, etc

In one sentence, RAD heavily depends on JAD and Prototyping, so it inherits the

advantages of these two approaches while it has to tolerate the disadvantages of

the two. [9] Last but not the least, the RAD approach is not appropriate to all

projects Project scope, size and circumstances all determine the success of a
[15]
RAD approach.

Object-orient system analysis abstracts concepts from the application

domain and describes what the intended system must do, rather than how it will

be done. Instead of using functional decomposition of the system, the OOA

approach focuses on identifying objects and their activities. Using the Object-

oriented approach, system analysts model information systems by identifying a

set of objects, along with their attributes and operations that manipulate the

object data. Objects are grouped into classes that have common properties.

Classes are organized into hierarchies, in which the subclasses inherit the
[6,18]
properties, including the data definitions and operations. The model specifies

the functional behavior of the system, independent of concerns relating to the

environment in which it is to be finally implemented.

The OO analysts need to devote sufficient time to clearly understand the

requirements of the problem and the analysis model should capture those

requirements completely and accurately. The core of OO is reusability. The whole

OO system is built on inheritance, so a subtle misunderstanding of the basic

requirements of the problem may cause the whole system seems ridiculous. OOA

is inspired by nowadays very popular object-orient programming (OOP). The

traditional system analysis methods cannot adapt to OOP to make the whole

development process smoother and seamless, so OOA comes up and tries to

[7]
solve such problem. The outcomes of OOA usually are considered reusable for

further OO system development phase, such as OOD and OOP, and this

reusability characters can dramatically shorten the total SDLC.

OOA has it own whole set of modeling tools to represent the system

requirements. They are:

Use-case diagram help to generate a requirements analysis model, which

captures the functionalities of the system as seen by external actors

Class diagram help to analyze the objects in the problem domain an

describe their static structure

State diagram shows how the object transitions from one state to other

states

Sequence diagram show the explicit sequencing of messages

[8, 21]
The commonly admitted points about OOA advantages in OO world are :

An easier modeling process and the ability to tackle more challenging

problem domains

Improved communication among users, analysis, designers, and

programmers

Increased consistency among analysis, design, and programming activities

Improved quality of system

 Reusability of analysis, design, and programming results

So far, although more and more system analysts adopt OOA, whether it is

superior to traditional system analysis is still in hot arguing. Although in OO

world, the above advantage points about OOA are commonly accepted, there are
[8]
still a large number of software communities dont agree with them. Dr.vicky

L.Sauter said people may more naturally think with a procedure way than with an

object way. Moreover, it is commonly accepted in the Object-oriented research

field that the methodology of OOA is far from mature and the identification of

object classes remains an art because it is highly dependent on the problem

[6]
domain.

Conclusion

No official best way to system analysis, the methods applied to the project

depend on the project context, such as analysts expertise, users favorites,

projects size, projects complexity, etc. So, a good system analyst should be

able to use any of these methods on the fly according to specific project context.

Although the new system analysis methods come out one by one, the

traditional ways for requirements determination, like interviewing,

questionnaires, directly observing, and analyzing documents can never be simply

replaced. Further more, neither in modern requirements determination methods,

such as JAD and prototyping, nor in nowadays advanced system analysis, such as

RAD and OOA, those four types of information collecting approaches are always

the cornerstones, which can never touched.

As the result of high business environment pace changing, RAD show itself

at dramatically shorten the SDLC. However, from the view of a system

requirements analysis, RAD intensively combines all kinds of system analysis

methodologies into one-step process by using nowadays high-powered computer

technology. RAD heavily adopts JAD and prototyping as the two primary ways to

gather the requirements, so the merits and drawbacks of these two methods also

can be found in RAD.

OOA may be the real revolution in system analysis field. However, such

revolution just happened at the requirements structuring level. It does not touch

the basic requirements determination methods, although better requirements

representation can help requirements determination process more efficient and

effective. In order to adapt to the OOP, a whole set of OOA requirements

structuring tools, such as use-case diagram, class diagram, etc, were developed,

which are thoroughly different to the traditional requirements structuring tools,

such as DFD, structured English, etc. So far, whether the OOA is better than the

traditional analysis methods or not is still a question mark. However, traditional

requirements analysis techniques were inspired by, and founded on, structured

programming concepts. Nowadays, in a programming world that is increasingly

turning to object orientation, such traditional techniques seemed out of date and

had to be replaced.[7]
References:

[1] JAD to the rescue

Matthews, Joy. Computerworld. Framingham: Dec 4,

1995. Vol. 29, Iss. 49; pg. 93, 1 pgs

[2] JAD basics

Anonymous. Journal of Systems Management. Cleveland: Sep/Oct 1995. Vol. 46, Iss. 5; pg. 18, 1 pgs

[3] Using groupware tools to automate Joint Application Development

Leventhal, Naomi S. Journal of Systems Management. Cleveland: Sep/Oct 1995.

Vol. 46, Iss. 5; pg. 16, 6 pgs

[4] Coping with JAD

Kelly, David A. Computerworld. Framingham: Oct 24, 1994. Vol. 28, Iss. 43; p. 123 (1 page)

[5] Why JAD goes bad

Garner, Rochelle. Computerworld. Framingham: Apr 25, 1994. Vol. 28, Iss. 17; p. 87 (2 pages)

[6] Two MIS analysis methods: An experimental comparison

Wang, Shouhong. Journal of Education for Business. Washington: Jan 1996. Vol. 71, Iss. 3; p. 136

[7] From object-oriented to goal-oriented requirements analysis

John Mylopoulos. Association for Computing Machinery. Communications of the ACM. New York: Jan
1999. Vol. 42, Iss. 1; p. 31

[8] The ups and downs of object-oriented systems development

Richard A Johnson. Association for Computing Machinery. Communications of the ACM. New York: Oct
2000. Vol. 43, Iss. 10; p. 68

[9] Systems analysis

Chris Chmielewski. Mortgage Banking. Washington: Feb 1998. Vol. 58, Iss. 5; p. 111

[10] Rapid-fire re-engineering

Seybold, Patricia B. Chief Executive. New York: Sep 1995. p. 68

[11] Planning, testing, teamwork a recipe for quality apps

Adhikari, Richard. Software Magazine. Englewood: Mar 1994. Vol. 14, Iss. 3; p. 41

http://gateway.proquest.com/openurl?ctx_ver=z39.88-
2003&res_id=xri:pqd&rft_val_fmt=ori:fmt:kev:mtx:journal&genre=article&rft_id=xri:pqd:did=000000000809590&sv
c_dat=xri:pqil:fmt=text (last viewed date 12/15/03)

[12] Strategies for information requirements determination By G. B. Davis

http://domino.watson.ibm.com/tchjr/journalindex.nsf/0/adf8cf6682e8529d85256bfa00685b4d?
OpenDocument ( last viewed date 12/15/03)

[13] The Use of Stopping Rules in Information Requirements Determination

Mitzi G. Pitts

http://hsb.baylor.edu/ramsower/ais.ac.97/papers/pitts.htm (last viewed date

12/15/03)

[14] RAPID APPLICATION DEVELOPMENT 1997 by Walter Maner

http://csweb.cs.bgsu.edu/maner/domains/RAD.htm (last viewed date 12/15/03)

[15] Process/Project RAD - RAD - Rapid Application Development Process

http://www.gantthead.com/Gantthead/process/processMain/1,1289,2-19516-
2,00.html

(Last viewed date 12/15/03)

[16] http://www.microolap.com/products/gis/mbbuilder.htm

(Last view date 12/15/03)

[17] Rapid Application Development

Ted Brockwood http://www.webdevelopersjournal.com/articles/rad.htm

(Last viewed date 12/15/03)

[18] Object-Oriented Analysis and Design

By Michael Gora DBMS, May 1996

http://www.dbmsmag.com/9606d15.html (Last viewed date 12/15/03)

[19] Paper Prototyping: Getting User Data Before You Code

Jakob Nielsen, April 14, 2003

http://www.useit.com/alertbox/20030414.html (Last viewed date 12/15/03)

[20] The Art of UI Prototyping

Scott Berkun, November 2000

http://www.uiweb.com/issues/issue12.htm (Last viewed date 12/15/03)

[21] Modern Systems Analysis and Design (3rd Edition)

by Jeffrey A. Hoffer (Author), Joey George (Author), Joseph Valacich (Author)