Requirements
Determination and Requirements Structuring
By Zhenyu Zhu
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 SDLC packs traditional analysis phase and part
of design phase into one step [21] , 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 a correct and
complete set of requirements.
[12]
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 usable systems to be built in as little as 60-90 days.
[14] 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 MapBasic.
[16,17]
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 attributed to incomplete and inaccurate information requirements.
[13] 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:
n
Prepare the interview
carefully, including appointment, priming question, checklist, agenda, and
questions.
n
Listen carefully and take
note during the interview (tape record if possible)
n
Review notes within 48
hours after interview
n
Be
neutral
n
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:
n
The ambiguity of
questions.
n
Consistence of
respondents’ answers.
n
What kind of question
should be applied, open-ended or close-ended?
n
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 make the gathered
information biased. [21]
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 are, etc. [21]
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 where there are areas
of agreement and where there are conflicts.
[2,21]
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 other one third are systems
professionals. [2] 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 how to effectively and
efficiently organize the JAD session a big challenge.
[4,5]
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 the requirements for new systems.
[3]
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 usability data are at least ten times greater than those from late
usability data.
[19,20] 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 rapidly build working
systems, etc. [21]
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
analysis |
JAD |
Prototyping |
|
Information
Richness |
High |
Medium to
low |
High |
Low (passive) and
old |
High |
Medium to
High |
|
Time
Required |
Can be
extensive |
Low to
moderate |
Can be extensive
|
Low to
moderate |
Dedicated period of time
of all kinds of involved people |
Moderate and can be
extensive |
|
Expense |
Can be
high |
Moderate |
Can be
high |
Low to
moderate |
High |
High |
|
Chance for Follow-up and
probing |
Good |
Limited |
Good |
Limited |
Good |
Good |
|
Confidentiality |
Interviewee is known to
interviewer |
Respondent can be
unknown |
Observee is known to
interviewer |
Depends on nature of
document |
All the people know each
other |
Usually know each
other |
|
Involvement of
Subject |
Interviewee is involved
and committed |
Respondent is passive, no
clear commitment |
Interviewees may or may
not be involved and committed depending on whether they know if they are
being observed |
None, no clear
commitment |
All kinds of people are
involved and committed |
Users are involved and
committed |
|
Potential
Audience |
Limited numbers, but
complete responses from those interviewed |
Can be quite large, but
lack of response from some can bias results |
Limited numbers and
limited time of each |
Potentially biased by
which documents were kept or because document not created for this
purpose |
Potentially biased by the
subordinator intentionally don’t want to directly point out his superior’s
errors.
|
Limited numbers; it is
difficult to diffuse or adapt to other potential
users |
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:
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 within a
system. The final deliverables and outcomes for DFD are:
[21]
·
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 and new systems. [21]
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 conditions
& actions |
Second
Best |
Third
Best |
Best |
|
Transforming conditions
& actions into sequence |
Best |
Third
Best |
Best |
|
Checking consistency
& completeness |
Third
Best |
Best |
Best |
The
comparison between decision table and decision trees is shown in table 3.
[21]
Table 3
|
Criteria |
Decision
Tables |
Decision
Trees |
|
Portraying complex
logic |
Best |
Worst |
|
Portraying simple
problems |
Worst |
Best |
|
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 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 today’s 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
convergence of two trends [10, 21]
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 as well as technology. [11] To succeed, RAD relies on
bringing together several system development components, such as JAD,
prototyping, and all kinds of traditional requirements structuring methods.
[9] 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.
Advantages of RAD: [21]
Disadvantages of RAD:
[21]
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 RAD approach. [15]
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 properties, including the data definitions and operations.
[6,18] 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 solve
such problem. [7] 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:
The
commonly admitted points about OOA advantages in OO world are [8, 21]
:
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 still a large number of software communities don’t agree
with them. [8] 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 domain. [6]
Conclusion
No official best way to system analysis, the methods
applied to the project depend on the project context, such as analyst’s
expertise, user’s favorites, project’s size, project’s 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&svc_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
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)