Feasibility Analysis and Requirements Determination

Chapter 2 - Feasibility Analysis and Requirements Determination
CHAPTER OBECT!"E# $%O& #HO&'D BE AB'E TO()

1. Define information systems development feasibility.
2. Define feasibility analysis.
3. Discuss what feasibility analysis allows systems analysts to do.
4. Name and discuss three types of feasibility.
5. Identify the main challenges to reuirements determination.
!. Describe the concept of problem domain.
". Define the sub#activities associated with the reuirements determination activity.
$. Define and apply the %I&'&( framewor) for doing reuirements determination.
*. Define and apply +o,ar-s .euirements /odel framewor) for doing reuirements determination.
10. 1ist and discuss 'oad-s ob2ect#oriented framewor) for doing reuirements determination.
11. Discuss techniues for gathering an information system-s true reuirements.
12. Identify the most common causes of reuirements ambiguity.
3s its name implies4 systems analysis and design is comprised of two ma2or components. 5his chapter
concentrates on the first component6systems analysis. /ore specifically4 it will investigate the feasibility
analysis and the reuirements determination activities central to systems analysis.
FEA#!B!'!T% A*A'%#!#
3 ma2or but optional activity within systems analysis is feasibility analysis. 3 wise person once said4 73ll
things are possible4 but not all things are profitable.7 (imply stated4 this uote addresses feasibility.
(ystems analysts are often called upon to assist with feasibility analysis for proposed systems development
pro2ects. 5herefore4 let-s ta)e a brief loo) at this topic.
'onsider your answer to the following uestions. 'an you ride a bicycle8 'an you drive a car8 'an
you repair a car-s transmission8 'an you ma)e lasagna8 'an you snow s)i8 'an you earn an 737 in this
course8 'an you wal) on the moon8 3s you considered your response to each of these uestions4 you
uic)ly did some )ind of feasibility analysis in your mind. /aybe your feasibility analysis and responses
went something li)e this9 'an you ride a bicycle8 7:f course I can; I 2ust went mountain bi)e riding last
wee)end with my best friend.7 'an you drive a car8 7Naturally. I drove to school today and gasoline is sure
e<pensive.7 'an you repair a car-s transmission8 73re you )idding8 I don-t even )now what a transmission
is;7 'an you ma)e lasagna8 7I never have4 but with a recipe and directions I-m sure that I could. /y mom
ma)es the best lasagna4 yum;7 'an you snow s)i8 7I tried it once and hated it. It was so cold and it cost a
lot of money.7 'an you earn an 737 in this course8 7I thin) it would be easier to wal) on the moon.7 'an
you wal) on the moon8 7%eople have done it. =ith training4 I thin) I could4 and I would li)e to also.7
&ach of us does hundreds or thousands of feasibility analyses every day. (ome of these are 7no
brainers7 while others are more thorough. &very time we thin) words li)e +,an !---.+ we are assessing our
feasibility to do something.
Information systems development pro2ects are usually sub2ected to one or more feasibility analyses
prior to and during their life. In an information systems development pro2ect conte<t4 feasibility is the
measure of how beneficial the development or enhancement of an information system would be to the
business. >easibility analysis is the process by which feasibility is measured. It is an ongoing process done
freuently during systems development pro2ects in order to achieve a creeping commitment from the user
Copyri/ht 0 1222 Ronald - *orman Dra3t date) #eptember 45 1222
*o part o3 this manus,ript may be reprodu,ed 6ithout 6ritten permission 3rom the author-
This boo7 6as pre8iously published by Prenti,e-Hall5 !n,-
24
and to continually assess the current status of the pro2ect. 3 creeping commitment is one that continues over
time to reinforce the user-s commitment and ownership of the information system being developed.
+nowing a pro2ect-s current status at strategic points in time gives us and the user the opportunity to ?1@
continue the pro2ect as planned4 ?2@ ma)e changes to the pro2ect4 or ?3@ cancel the pro2ect.
Feasibility Types
Information systems development pro2ects are sub2ected to at least three interrelated feasibility types6
operational feasibility4 technical feasibility4 and economic feasibility. :perational feasibility is the measure
of how well particular information systems will wor) in a given environment. Aust because BCD
'orporation-s payroll cler)s all have %'s that can display and allow editing of payroll data doesn-t
necessarily mean that 3E' 'orporation-s payroll cler)s can do the same thing. %art of the feasibility
analysis study would be to assess the current capability of 3E' 'orporation-s payroll cler)s in order to
determine the ne<t best transition for them. Depending on the current situation4 it might ta)e one or more
interim upgrades prior to them actually getting the %'s for display and editing of payroll data. Fistorically4
of the three types of feasibility4 operational feasibility is the one that is most often overloo)ed4 minimi,ed4
or assumed to be o)ay. >or e<ample4 several years ago many supermar)ets installed 7tal)ing7 point#of#sale
terminals only to discover that customers did not li)e having people all around them hearing the names of
the products they were purchasing. Nor did the cashiers li)e to hear all of those tal)ing point#of#sale
terminals because they were very distracting. Now the point#of#sale terminals are once again mute.
5echnical feasibility is the measure of the practicality of a specific technical information system
solution and the availability of technical resources. :ften new technologies are solutions loo)ing for a
problem to solve. 3s voice recognition systems become more sophisticated4 many businesses will consider
this technology as a possible solution for certain information systems applications. =hen '3(& technology
was first introduced in the mid#1*$0s4 many businesses decided it was impractical for them to adopt it for a
variety of reasons4 among them being the limited availability of the technical e<pertise in the mar)etplace to
use it. 3doption of (malltal)4 'GG4 and other ob2ect#oriented programming for business applications is
slow for similar reasons.
&conomic feasibility is the measure of the cost#effectiveness of an information system solution. =ithout
a doubt4 this measure is most often the most important one of the three. Information systems are often
viewed as capital investments for the business4 and4 as such4 should be sub2ected to the same type of
investment analyses as other capital investments. >inancial analyses such as return on investment ?.:I@4
internal rate of return ?I..@4 costHbenefit4 paybac) period4 and the time value of money are utili,ed when
considering information system development pro2ects.
'ostHbenefit analysis identifies the costs of developing the information system and operating it over a
specified period of time. It also identifies the benefits in financial terms in order to compare them with the
costs. &conomically spea)ing4 when the benefits e<ceed the costs4 the system has economic value to the
businessI 2ust how much value is a function of management-s perspective on investments.
(ystems development and annual operating costs are the two primary components used to determine the
cost estimates for a proposed information system. 5hese two components are similar to the costs associated
with constructing and operating a new building on the university campus. 5he building has a one#time
construction cost6usually uite high. >or e<ample4 a new library addition on campus recently costs J20
million to build. :nce ready for occupancy and use4 the library addition will incur operating costs4 such as
electricity4 custodial care4 maintenance4 and library staff. 5he operating costs per year are probably a
fraction of the construction costs. Fowever4 the operating costs continue for the life of the library addition
and will more than li)ely e<ceed the construction costs at some time in the future.
25
(ystems development costs are a one#time cost similar to the construction cost of the library addition.
5he annual operating costs are an ongoing cost once the information system is implemented. >igure 2.1
illustrates an e<ample of these two types of costs. In this e<ample4 the annual operating costs are a very
small fraction of the development costs. If the system is pro2ected to have a useful life of ten years4 the
operational costs will still be significantly more than the development costs.
5wo types of benefits are usually identified and uantified6tangible and intangible. 5angible benefits
are those that can ob2ectively be uantified in terms of dollars. >igure 2.2a lists several tangible benefits.
Intangible benefits are those that cannot be ob2ectively uantified in terms of dollars. 5hese benefits must
be sub2ectively uantified in terms of dollars. 3 list of several intangible benefits is shown in >igure 2.2b.
'omparing the benefit dollars to the cost dollars4 one can tell if the proposed information system is
going to brea) even4 cost the business4 or save the business money. :nce a pro2ect is started4 financial
analyses should continue to be done at periodic intervals to determine if the information system still ma)es
economic sense. (ometimes systems development pro2ects are canceled before they become operational4
many because they no longer ma)e economic sense to the business. :perational and technical feasibility
should also be continually assessed during the life of a systems development pro2ect in order to ma)e
ad2ustments when necessary.
2!
RE9&!RE:E*T# DETER:!*AT!O*
5he reuirements determination activity is the most difficult part of information systems analysis.
.euirements determination addresses the gathering and documenting of the true and real reuirements for
the information system being developed. /any te<tboo)s refer to this activity as the 7what7 portion of
information systems development. In other words4 the systems analyst is primarily thin)ing and trying to
answer the uestion4 7=hat must the system do87 during the reuirements determination activity. :nce
information systems development progresses to the design activities4 the systems analyst and the
programmers focus their attention primarily on the uestion4 7Fow does the system do what it is supposed
to do87
=hy is reuirements determination difficult8 5here are several reasons why this is true. /ost are
attributed to the fact that this is a highly cognitive and creative activity for all of the members of the
development team4 including the users. .euirements determination represents perhaps one of the last
frontiers still awaiting significant automated and intelligent support. '3(& technology4 discussed later in
the boo)4 is ma)ing a contribution in this area4 mainly as a documentation and communication aid.
5he systems analyst-s amount of functional understanding of the problem domain also contributes to
the challenge. >or e<ample4 an analyst who is gathering and documenting reuirements for a student course
registration problem domain would normally be more effective if he or she already had an understanding of
how registration systems wor). 5he reason for this is that the systems analyst with registration problem
domain e<perience would be able to better relate to the user and the problem due to the systems analyst-s
familiarity and prior e<perience with registration systems. 5herefore4 the e<perienced systems analyst
would ordinarily be able to as) more effective and complete uestions. :ne very difficult and costly
e<ample of this happened to a colleague a few years ago. &ven though he was an e<perienced systems
analyst4 he )new very little about financial information systems. Fis assignment was to gather reuirements
for a financial information system from the controller of the company. Due to the 7uestion and answer7
2"
nature of reuirements determination4 the controller neglected to mention that he needed a general ledger
report in the system. (ince the systems analyst )new so little about financial systems4 he could not even as)
the controller if he needed this type of a report. Needless to say4 the controller-s 7final7 financial system was
incomplete causing embarrassment4 additional time to 7fi<7 the system ?i.e.4 add the general ledger report to
the system@4 and additional cost to fi< it. Now my colleague )nows about financial systems.
3nother challenge for the systems analyst doing reuirements determination is the dynamic nature of
the problem domain being investigated. 5he following situations illustrate this. /ost businesses are either
e<panding or shrin)ing4 which causes variability in their information systems needs. Kovernment and labor
union regulations change every few months4 which might affect a system under development. 1eadership
within the business may change midstream in a systems development pro2ect4 causing the business to want
to rethin) the system. %roducts that the information systems are to become part of are constantly changing
due to technology improvements4 manufacturing improvements4 mar)et demand for the products4 and so on.
3 company that decides to acuire and merge with another company4 such as the 35L5 and N'.
'orporation and &D( and Keneral /otors mergers of a few years ago4 can create some really interesting
challenges for the systems analysts of both companies.
1ife is dynamic. (o is business. 5ry placing your life on hold for a few months or a year6no way; 5he
same is true for almost all businesses. In spite of this4- information systems development must coe<ist with
the business dynamics. In effect4 systems analysts are essentially shooting at a moving target during
systems development. 5oday-s reuirements may be obsolete tomorrow or ne<t wee)4 month4 or year. >or
e<ample4 today a company offering public seminars in M.(. cities only accepts M.(. dollars as paymentI
ne<t month the company may decide to e<pand its seminars into the international mar)et causing a change
to the system reuirement for only handling M.(. dollars for payment.
'ommunication among the information systems development pro2ect team members has traditionally
been another challenge for reuirements determination. 3s the number of team members e<pands4 the
greater the potential for communication inconsistencies and problems. 5he secret to success is developing a
consistent understanding of the real reuirements among all team members. 5his boo) is a good illustration
of this challenge. 5he goal for the boo) is to effectively communicate the essence of systems analysis and
design to you4 the reader. Fow effective the boo) is at doing this is your 2udgment call. (ometimes
information systems reuirements are so involved that they could fill a boo) this si,e or larger. 5he user is
e<pected to read through the reuirements document ?boo)@ and discover inconsistencies4 errors4 oversights4
and so on. 5his is a very difficult tas)4 especially since the user more than li)ely already has a full day of
wor) activities in addition to doing such a review.
&very problem domain has its own 2argon. >or e<ample4 computer technology has its own6.3/4
.:/4 .3ID4 &%(4 Eaud4 BK34 (NK34 DI//4 >DDI4 and so on. (ometimes different people interpret
2argon differently. 5his can cause communication problems4 so caution is recommended when using it
within any problem domain. >or e<ample4 35/ is generally considered an automated teller machine4 but
recently 35/ within the telecommunications discipline has emerged to mean asynchronous transmission
mode.
>inally4 there are still many other factors that can cause problems while doing reuirements
determination4 for e<ample4 human factors4 such as being tired4 or not feeling well4 distractions that occur
inside a room or on the other side of a room-s window during a meeting4 stress of team members4 and so
forth. 5he probability of these types of challenges e<isting in every systems development pro2ect in varying
degrees is uite high.
PROB'E: DO:A!*
2$
3 problem domain refers to any business area or function. In systems analysis and design4 the problem
domain refers to the business problem4 area4 or function being investigated and analy,ed. 5he purpose of
the investigation and analysis is to determine the need to purchase4 ma)e4 or revise an information system to
enhance the business activity of the problem domain. >or e<ample4 accounts payable problem domain
refers to the activity that all companies perform to pay their bills to the businesses they buy materials and
services from. 5hose of us individuals who pay household bills on a recurring basis4 such as utilities4 rent4
cable television4 car loans4 and others4 also are engaging in an accounts payable problem domain when we
ma)e our payments. 5he problem domain for developing the software and other systems components for an
automated teller machine would be the automated teller machine problem domain. 5he problem domain for
the software and other system components for a video arcade game would be the video game problem
domain. 5he idea is to determine the scope or boundaries of the problem domain and then assign an
appropriate name to it.
.arely does everything within a problem domain become part of the information system. >or e<ample4
there is a variety of information about you as a person4 such as your name4 your residence address4 grade
point average4 courses ta)en4 high school attended4 social clubs you belong to4 sports interests4 hobbies4
religion4 your favorite actor4 actress4 sports figure4 and so on. In your role as a student4 your university-s
course registration information system problem domain probably has no need to )now what high school
you attended4 your social clubs or sports interests4 or who your favorite actor4 actress4 or sports figures are4
so we can eliminate them from this system. :n the other hand4 in an information system having a broader
scope4 say a student information system on campus which is integrated with the previously mentioned
course registration system4 there may very well be a need to have this information. Discussions with the
information system-s user will help determine when to include aspects of the problem domain and when to
e<clude them. 3reas to be included within an information system-s problem domain are often referred to as
the information system-s responsibility or reuirements.
3s mentioned earlier4 reuirements determination addresses the gathering and documenting of the true
and real reuirements for the information system being developed. 5o say this in another way4 it is the
activity systems analysts and users engage in to determine the information system-s responsibilities. 5his is
illustrated in a general way in >igure 2.3. >or e<ample4 you have hundreds of courses available to you at
the university4 yet you only ta)e a small percentage of those courses ?even though it seems li)e a lot of
courses;@. Cou go through some analysis to determine which courses to ta)e. (ome of your analysis is based
on courses that are reuired in order for you to graduate4 such as general education courses. :ther courses
may also be reuired in order for you to graduate with a specific ma2or. Eoth of these e<amples are
analogous to figuring out what the information system is reuired to do in order to be useful and successful
to the user.
:ther courses are selected based on personal preference ?e.g.4 golf4 racuetball4 physics4 and others@
and are counted as electives. 5his could be analogous to including some desirable4 but not mandatory4
features in the proposed information system. >inally4 you may have to ta)e one course from a group of
reuired courses ?e.g.4 ta)e one of the following three courses . . .@. 5his could be analogous to having the
user pic) one feature from a list of features that could be included in the information system. Determining
the responsibilities of an information system involves the use of an analysis techniue also4 not e<actly li)e
the course e<ample here4 but certainly similar.
Determining the scope or boundaries of the problem domain is not always easy because it often
involves trade#offs and compromises. 5herefore4 the definition of reuirements for our purposes is the
wants andHor needs of the user within a problem domain. 5echnically spea)ing4 reuirements refer to those
items that are necessary or essential in the system. =ithin the systems conte<t4 however4 reuirements often
2*
includes those items that may not necessarily be essential but are4 nonetheless4 desired and4 therefore4
reuired.
%erhaps it is this confusion over what is essential4 needed4 desired4 or reuired of the system that ma)es
it so difficult to systematically articulate e<actly what a systems analyst is to do during the reuirements
determination activity of the development pro2ect.- In reality the reuirements are defined at the beginning
of the pro2ect along with the system-s ob2ectives. Fowever4 additional reuirements are often identified
during later activities of the systems development life cycle ?(D1'@. >or e<ample4 new or changed
reuirements may surface during the testing activity4 an activity where it is ultimately determined how the
system will be best implemented in the environment. 5herefore4 while it is nice to thin) about reuirements
determination being completed very early during systems development4 it is somewhat artificial to close off
the definition and gathering of reuirements as we move from analysis activities to design and
implementation activities.
Msing an ob2ect#oriented approach to systems analysis and design to analy,e the informational4
functional4 and behavioral reuirements of the system helps eliminate the need to artificially close one
activity of the (D1' as we move to another activity. .egardless of the approach used for analysis and
design4 systems analysts need to continuously decide throughout their careers what to glean from current
thin)ing about reuirements determination techniues. In most cases articles and boo)s on the sub2ect fall
into two broad categories9 ?1@ framewor)s or ways to classify reuirements into sub2ect areas so that
categories of reuirements are not overloo)ed by the systems analyst4 and ?2@ guidelines or heuristics ?rules
of thumb@ that guide the systems analyst toward specific )inds of uestions to as) users during the
reuirements determination activity of the pro2ect. &ach of these is addressed separately ne<t.
FRA:E;OR<# FOR &*DER#TA*D!*= A*D DO!*= RE9&!RE:E*T# DETER:!*AT!O*
30
=hile there are many framewor)s that can be discussed in this section4 four have been selected that
represent different perspectives of the problem and are discussed here9
1. .euirements determination sub#activities
2. %I&'&( framewor)
3. +o,ar-s .euirements /odel
4. :b2ect#oriented reuirements modeling activities
Requirements Determination #ub-a,ti8ities
.euirements determination is the general data#gathering activity done during analysis. It has four sub#
activities6reuirements anticipation4 reuirements elicitation4 reuirements assurance4 and reuirements
specification. :ne of the earliest research articles to deal with understanding the reuirements determination
activity was presented by Naumann4 Davis4 and /c+een and later e<panded by Nitalari-s wor). 5ogether
they have identified four sub#activities within the reuirements determination activity as listed previously
and described in more detail here9
1- Requirements Anti,ipation- 5he systems analyst hypothesi,es that particular reuirements are relevant
based on his or her previous e<perience with other similar systems and )nowledge about the problem
domain. 3s you progress through college4 you continue to anticipate instructors- reuirements for passing
their courses. If you have the same instructor twice4 you are even more able to anticipate his or her course
reuirements.
2- Requirements Eli,itation- 5he systems analyst uses this activity to gather the essential reuirements
from the user employing a variety of techniues4 such as interviews4 uestionnaires4 group brainstorming
meetings4 and voice and e#mail.
>- Requirements Assuran,e- 5he systems analyst uses the activity of reuirements assurance to validate
and verify the reuirements with the user as being the real and essential reuirements. 3 user wal)#through
in which the systems analyst and the user together review documented reuirements in detail is one
assurance techniue.
?- Requirements #pe,i3i,ation- 5his is the activity that the systems analyst uses to e<plicitly catalog and
document the reuirements either during or after the elicitation and assurance activities. 5his is the activity
most often associated with automated computer#aided software engineering ?'3(&@ technology4 which is
discussed later in the boo).
5he preceding four sub#activities are tightly coupled with each other and highly iterative in nature.
(ystems analysts have often commented that it is difficult to isolate one sub#activity from the others
because they are so interrelated. Nevertheless4 these same systems analysts believe that having a more
complete understanding of the detailed sub#activities within the reuirements determination activity ma)es
them more effective as they gather reuirements for a proposed information system.
The P!ECE# Frame6or7
5he second framewor) to discuss4 called the %I&'&( model and first presented by =etherbe4 focuses on
the actual wor) of doing reuirements determination. 5his model is used to classify identified reuirements
into one of si< sub2ect areas6Per3orman,e5 !n3ormation5 E,onomy5 Control5 E33i,ien,y5 and #er8i,es-
31
5he goal of the model is to assure the systems analyst and the user that uestions will be included during
analysis about each of these si< essential sub2ects as it relates to the problem domain. 5he responses to the
uestions for each of these sub2ect areas significantly contribute to the definition of the system-s
reuirements. =hat follows is a brief summary of each of the si< sub2ect areas.
Per3orman,e uestions address how the system needs to perform for the user. Issues of throughput ?the
amount of wor) performed over some period of time@ and response time ?the average delay between a
transaction or user reuest and the response to that transaction or user reuest@ are considered. >or
e<ample4 the systems analyst may as) uestions about the needed response time or throughput reuired on
the networ)4 the uality of print needed4 or the need to have a graphical user interface or a menu or te<t
type of interface. In other words4 the uestion the systems analyst as)s is4 7Fow does the system need to
perform in this environment87 Its answer can be multifaceted depending on the needs of the user.
5he in3ormation category provides the basis for the information or data model that the system needs to
maintain. Issues dealing with input data4 output data4 and stored data are considered. 5he systems analyst
may as) the following uestions9 7=hat information is reuired by the users of the system87 or 7=hat
outputs are reuired87 and 7=hat do these outputs need to loo) li)e87 5hese uestions need to be addressed
and answered while the systems analyst is interacting with the user to define output or report definitions.
(imilarly4 uestions related to input data reuired in order to produce the outputs are also included in
this category4 for e<ample4 7=hat input screens are needed87 or 7=hat is the source for the input ?where
does it come from@87 and 7'an the input enter the system with source data acuisition euipment such as
bar code scanners4 laser guns4 mouse4 and so on87 Mltimately4 the data need to be defined with a high
degree of detail4 which is discussed further in a later chapter of this boo).
5he third category in this framewor) is e,onomy. 5his sub2ect area addresses pro2ect development and
operational cost information along with any ob2ectives that may relate to economy or savings associated
with the system. >or e<ample4 the systems analyst may as)4 7=hat is the budget for this pro2ect87 or 7=hat
is a wor)able solution to the problem worth to the user of this system87 :ther uestions can include9 7=hat
are some anticipated cost savings associated with this system87 and 73re there current manual activities
that an automated solution to the problem may affect87 If so4 7Fow will the automated system transform
the role of these wor)ers87
5he ,ontrol category is closely associated with system security issues as well as the editing reuired on
the incoming data. >or e<ample4 uestions may be as)ed related to needed accounting controls for some
processes4 or at what levels ?wor)station4 user4 screen4 file4 data element4 and so on@ security is needed. 3ny
issue related to controlling the use of the system4 its outputs and inputs4 or reuired controls over the data
can be included in this category.
(omewhat related to economy4 the other 7&7 in the %I&'&( framewor) refers to e33i,ien,y. &fficiency
is a measure of method correctness. In other words4 73re things being done right87 &fficiency-s impact is
usually measured at least at one of three levels6corporate#wide4 department4 or individual. Ouestions
related to efficiency are primarily directed toward the impact that any solution must have on the
environment. >or e<ample4 7Fow can the operations in the office be improved by this system87 and 7=hat
values can be added to the environment by using an automated solution to the problem87 are two uestions
that the analyst can as) in this sub2ect area.
5he final category in =etherbe-s %I&'&( framewor) is essentially the functional reuirements of the
system that he associates with ser8i,es. 7=hat does the system need to do in order to solve the problem87
and 7=hat processes need to be performed87 or 7Fow are the ob2ects e<pected to perform87 and 7=hat do
the ob2ects need to be able to do87 are typical uestions the analyst as)s for this sub2ect area. In addition to
functional reuirements4 services may also include implementation concerns4 such as ease of use and
needed support for ongoing use of the system4 maintenance of the system4 and training and documentation
reuirements.
32
<o@arAs Requirements :odel
+o,ar-s .euirements /odel is the third framewor) and is shown in the lower portion of >igure 2.4. It too
focuses on a techniue useful to a systems analyst doing reuirements determination. Instead of classifying
reuirements into one of si< categories as in the %I&'&( model4 +o,ar-s reuirements model associates
well with the long#established business 7pyramid7 model ?note9 the pyramid is not part of +o,ar-s modelI he
uses the pyramid model as the foundation upon which he builds his reuirements model@ by associating the
established business ob2ectives and tactics to information system ob2ectives and tactics. 5he )ey to +o,ar-s
model is to establish relationships between what the business wants to accomplish and what the information
system can do to help.
+o,ar-s reuirements model presents five tiers starting with some internal or e<ternal stimuli ?e.g.4
problems4 opportunities4 or directives as discussed in 'hapter 1@ representing the need or desire for some
type of change. (ometimes the change affects the mission of the business4 but most often it affects the
business ob2ectives that have already been documented. Eusiness ob2ectives are often action#oriented4
measurable statements that could lead to one or more ways of increasing a business-s revenue or profit4 or
reducing the business-s e<penses. >or e<ample4 7Increase sales of fishing euipment by 10 percent this
year7 could be a business ob2ective for a sporting goods store. :nce new or changed business ob2ectives are
established4 business tactics to support these ob2ectives can be identified. Eusiness tactics are usually what
people need to do to support the business ob2ectives. 5he same sporting goods store could have 7develop
five or more new television advertisements7 as a business tactic to support the foregoing business ob2ective
e<ample. Information system ob2ectives can be identified to support the business tactics followed by
identifying the information system tactics necessary to carry out the information system ob2ectives.
/ost often4 successful use of the reuirements model e<pects that the business has documented specific
goal and mission statements4 often in a document that is called an enterprise or business model. Eriefly4 an
enterprise or business model attempts to answer the uestion4 7=hy do we e<ist87 5his type of uestion can
33
be as)ed and answered at every organi,ational level6corporate4 division4 region4 department4 section4 and
so on. 5he important point for the reuirements model is that a general business direction must be provided
before the information system reuirements can be identified. 3lthough desirable4 it is not absolutely
essential to have an entire organi,ation-s business model defined before applying the reuirements model. It
is necessary4 however4 for the business model to be established for the business unit ?e.g.4 division4 region4
department4 section4 and so on@ that is doing reuirements determination using the reuirements model
approach.
'ostHbenefit analysis4 described in more detail later in the boo)4 is usually associated with the
2ustification for doing an information systems development pro2ect. Msing the reuirements model4 it is
often possible to euate both business and information system ob2ectives with benefits and business and
information system tactics with costs as shown in the bottom half of >igure 2.4.
In the reuirements model4 business ob2ectives are specific statements of how the organi,ational goals
can be achieved. >or e<ample4 7increase profit 10 percent each year7 and 7reduce customer complaints 15
percent each year7 could be e<amples of business ob2ectives. 5he ob2ectives are business directed4 always
measurable4 usually stated in terms of time andHor money4 and in the spirit of total uality management
?5O/@ often do not have an ending point so that continuous improvement and e<cellence becomes an
ongoing ob2ective.
Eusiness tactics are specific actions that can be ta)en to reali,e the business ob2ectives. 5he business
tactics may or may not specifically involve the information systems of the business. :ften other non#
information systems activities are associated with business tactics4 such as 7hire two new order entry
cler)s7 and 7install a new telephone system.7 5he business tactics that involve the information system are
used to form the final two tiers of the model4 the information system ob2ectives and the information system
tactics.
Information system ob2ectives are the information system accomplishments4 such as using scanners to
enter sales data4 displaying calculations such as total price and sales ta<4 printing reports of sales summary
information4 and so on. 5hese ob2ectives are in direct support of and correlate directly to one or more
business tactics. Ouite often the information system ob2ectives represent 7what the user of the information
system sees7 when interacting with the information system.
>inally4 the information system tactics are the information system actions done 7behind the scenes7 by
the information system in order to accomplish the information system ob2ectives or 7what the user of the
information system sees.7 >or e<ample4 doing a gross pay calculation in a payroll information system may
be an information system tactic to support the information system ob2ective of producing a payroll chec).
Information system tactics usually represent the wor) done by systems analysts and other technical
professionals to accomplish the information system ob2ectives.
3 good guideline for developing business tactics4 information system ob2ectives4 and information
system tactics is that each business ob2ective leads to one or more business tacticsI each business tactic
leads to ,ero or more information system ob2ectives ?remember not all business tactics euate directly to the
information system@I each information system ob2ective will create one or more information system tactics.
3 partial e<ample of mission4 business ob2ectives4 business tactics4 information system ob2ectives4 and
information system tactics is shown in >igure 2.5. 5his list was developed in the classroom with students
wor)ing on a video saleHrental store information system pro2ect.
34
35
+o,ar-s reuirements model for eliciting and developing reuirements has the advantage of building on
good business strategic modeling. If the last two tiers of the model6information system ob2ectives and
information system tactics6were e<panded to consider the %I&'&( framewor)4 then both views are
consolidated into one framewor).
5he biggest drawbac) to the reuirements model is that in practice businesses often do not have well
articulated and documented business models4 mission statements4 or goal statements. &ven when the
business reali,es that it needs to have these in order to get the9 most out of information systems4 it typically
continues with information systems development pro2ects that may not have anything to do with the desired4
but undocumented4 business goals and ob2ectives.
Ideally4 the reuirements model provides a good framewor) for new system development as well as
identifying areas that need re#engineering or constant reevaluation. In practice4 however4 the %I&'&( model
may be more practical when the business model is not well defined andHor the business ob2ectives lac)
specific tactics that can direct information system activities.
ObBe,t-Oriented Requirements Determination :odelin/ A,ti8ities
Kathering reuirements using an ob2ect#oriented perspective emphasi,es ob2ects4 patterns4 responsibilities4
and scenarios. Ee aware that there are several ob2ect#oriented methodologies competing in the commercial
mar)etplace4 and each of these methodologies has its own term4 synonym4 or variation for these four
generic terms. &ach of these is described in significant detail in a later chapter along with the specific ob2ect
notation used in this boo). Fowever4 a simple definition for each of these terms may be useful at this time.
3n ob2ect is a person4 place4 or thing4 such as student4 faculty4 sales cler)4 city hall4 famous par)4 35/
machine4 and videotape. 3 pattern is a template of ob2ects with stereotypical responsibilities and
interactionsI the template may be applied again and again4 by analogy. %attern instances are building bloc)s
used to assemble effective ob2ect models. >or e<ample4 a transaction ob2ect and transaction line item
ob2ects are a familiar pattern or template in business information systems. 3n actual instance of the
transaction-to-transaction line item pattern is a sales order ?transaction@ with its associated sales order line
items ?transaction line item@.
.esponsibility is associated with ob2ects and has three aspects to it9
1- ;hat the obBe,t 7no6s about itsel3. 5he things that an ob2ect )nows about itself are called attributes.
3n attribute is a characteristic associated with a person4 place4 or thing ob2ect. &ach characteristic has a
value or state. >or e<ample4 the following are attributes9 person-s name4 person-s telephone number4
person-s grade point average4 place name4 place location4 vehicle name4 and vehicle type. 5he following are
values or states for the preceding attributes9 .onald Norman4 !1*.5*4.3"344 3."5 ?pretty good K%3 huh8@4
'entral %ar)4 New Cor) 'ity4 /ercedes Een,4 automobile.
2- ;ho the obBe,t 7no6s- 3 problem domain has many ob2ects within it. =ho the ob2ect )nows identifies
relationships between ob2ects. 3 standard relationship is a connection between different types of ob2ects4
such as students and courses ?relationship9 students ta)e coursesI courses are ta)en by students@4 sales
order and line item ?relationship9 sales orders have line items on themI line items are found on sales orders@4
and video tape and customer ?relationship9 video tapes are rented by customersI customers rent video
tapes@.
>- ;hat the obBe,t does- 5his translates into a list of services for each ob2ect. 3 service is some
functionality that an ob2ect is responsible for performing4 such as registering for a course4 dropping a
course4 chec)ing out a video tape4 purchasing products at the supermar)et4 and so on.
5he last term to be discussed here is a scenario. 3 scenario is a time#ordered seuence of ob2ect
interactions to fulfill a specific responsibility. 3 scenario would be developed for each of the preceding
3!
services. >or e<ample4 2ust as ma)ing a ca)e and changing the oil in your car have detailed steps to
accomplish the tas)4 registering for a course also involves several detailed steps to actually accomplish the
service. 5hese steps would ma)e up the scenario for this service.
=ith these simplified definitions in mind. 'oad-s ob2ect#oriented reuirements determination modeling
approach would involve the following four ma2or activities9
1. Identify purpose and features of the information system.
2. Identify ob2ects and patterns.
3. &stablish ob2ect responsibilities9 7what I )now47 7who I )now47 and 7what I do.7
4. =or) out the system-s dynamics using scenarios.
&ach of these four ma2or activities would be considered within four ma2or model components. &ach is
discussed in greater detail in a later chapter so they are 2ust listed here for preliminary e<posure9
1. %roblem domain6activities related primarily to the problem domain under consideration.
2. Fuman interaction6activities related primarily to the human#computer interface4 such as displays
?windows@ and reports.
3. Data management6activities related primarily to the persistent storage of data4 such as databases.
4. (ystem interaction6activities related primarily to the interaction of this system with other systems.
5he details of ob2ect#oriented reuirements determination and the resulting ob2ect#oriented model of the
problem domain are left to later chapters in this boo).
:ETHOD# &#ED TO =ATHER A* !*FOR:AT!O* #%#TE:A# RE9&!RE:E*T#
3ssuming a systems analyst understands what information system-s reuirements mean in a general sense4
the first step in deciding how to gather4 document4 and validate the reuirements is deciding which
method?s@ to use to gather and document them. 5here are several methods to pic) from. Kenerally spea)ing4
the methods for gathering reuirements can be viewed from global4 individual4 or collective ?group@
perspectives.
(tarting with the global view of the system4 the reuirements can be gathered by ?1@ reviewing current
or past reports4 forms4 files4 and so on4 ?2@ conducting research into what other companies have done for
the same problem domain4 and ?3@ conducting site visits to similar system installations. 5he drawbac) to
the global view4 and thus all three of its reuirements#gathering methods4 is that it focuses on what has
already been done and may overloo) innovations needed for the future-. 5he benefits of the global methods
are that they all help to familiari,e the systems analyst with the environment that the new system is being
proposed for4 and they can help acuaint the systems analyst with at least minimum4 already established4
reuirements.
5o customi,e the system reuirements to the problems at hand4 however4 individual reuirements are
always necessary. =ithin the individual category4 common methods include9 ?1@ interviews4 ?2@ observation4
?3@ uestionnaires or surveys4 and ?4@ creating a prototype of the information system in order to obtain
feedbac) from the potential users of the system. Interviews involve at least one systems analyst and at least
one user conversing about the information system-s reuirements. Interviewing for reuirements is similar
to your interviewing for a 2ob position or a television tal) show host interviewing a guest. 5he purpose is to
gather information4 hopefully in an interesting way. Observation is the act of the systems analyst going to a
specific location to observe the activities of the people and machinery involved in the problem domain of
interest. Fopefully4 the systems analyst can see firsthand )nowledge of the problem domain-s process.
3"
Questionnaires are feedbac) forms designed to gather information from large groups of people. No doubt
you have responded to at least one uestionnaire or survey in your lifetime.
'reating a prototype of the information system can be done on an individual level or in a group setting.
5he idea is to e<plore system alternatives by developing small wor)ing models of the proposed system so
that user reactions can be gathered. It goes along with the notion that 7users don-t )now what they want
until the users see what they don-t want.7 5herefore4 uite often the value of prototyping at the reuirements
level is to eliminate the unwanted features of the system4 as well as define the desired features.
5he main ob2ective at this level of gathering reuirements is to find out what the individual user needs
or wants from the system. 5his includes identifying current problems4 current needs4 future wants4 needs
and e<pectations4 and getting to )now the user well enough to determine what organi,ational reuirements
may be necessary in order to ma)e the system functional in the user-s environment. :ne#on#one
interviewing coupled with observation is perhaps the most popular method for gathering these reuirements
but has the drawbac) of often ta)ing the longest time to accomplish.
3s mentioned earlier4 prototyping can also be done in the group or collective user setting and has
proven to be uite effective. (ometimes prototyping is done in con2unction with 2oint application
development ?A3D@ or rapid analysis techniues of any type. &ssentially4 A3D and rapid analysis techniues
are facilitated groups of users that collaborate in concentrated wor) sessions to define needed system
functions4 screens4 reports4 e<pectations4 and data elements. :ften the results of each session can be
translated into a prototype4 which can be reviewed by the user in subseuent sessions and used to
communicate the systems analyst-s understanding of what the system needs to be or do.
In addition to prototyping4 rapid analysis techniues4 and A3D4 other group techniues include group
brainstorming4 electronic A3D ?called &A3D@4 and the use of group systems software often referred to as
groupware. .egardless of whether a computer is used to gather the results obtained from meetings4 as is the
case with &A3D and groupware4 the meetings consist of facilitated sessions in which multiple users interact
with each other in order to produce an agreed#upon list of reuirements.
5he facilitator of the group meetings needs to have a clear and precise idea of what the ob2ectives for
each group session need to be. >or e<ample4 if the ob2ectives of a session are to identify potential problems
with implementing a new information system and ran) order them in terms of severity4 the group might
brainstorm barriers to implementation in the business followed by developing a ran)#ordered list of barriers
to implementation. >ollow#up sessions can be held to brainstorm tactics that can be used to overcome or
address each of the top barriers mentioned.
Kathering reuirements as group interactions has several advantages over individual interviewing and
observation. >irst4 the group develops its own synergy. 'onflicts between or among the users can be readily
identified4 and a global view of the system is possible. Ne<t the user can see that others are affected by
what he or she does and if the group is well facilitated with a way to effectively resolve conflict4
communication among the users improves ?at least with respect to the reuirements of the system at hand@.
>inally4 because the individual ideas of the users are gathered in one place at one time4 group methods are
more efficient for the pro2ect team and provide a natural way to synthesi,e and consolidate results.
Kathering reuirements as group interactions has a few disadvantages as well. Kroup interactions can
be a disaster for the pro2ect team when the meetings are poorly facilitated4 have no way to resolve conflict4
andHor consist of people who are not directly andHor potentially involved with the system. 3ttention needs to
be paid to each of these issues so that they can be minimi,ed or eliminated from group interactions.
>acilitated groups can be used to effectively brainstorm and ran) order system preferences4 solution
attributes or the characteristics the solution needs to consider or include4 constraints or limitations to
implementation4 e<pectations4 and evaluation criteria. (ystem preferences 2ust mentioned include defining
system information4 data4 and functional reuirements. 5he ran) ordering can be as simple as classifying
each of these items as mandatory4 highly desirable4 desirable4 nice to have4 or not necessary.
3$
5he steps to use in facilitating groups are to brainstorm with the e<pectation that as many ideas will be
generated as possible. =hen ideas begin to be repeated or no new ideas come forth4 or if the pre#assigned
time is up4 idea generation is closed off. 3ll ideas4 regardless of 7value7 or seriousness4 are recorded so that
everyone in the room can see the list. 5he list is then reviewed and consolidated where needed. Depending
on the length of the list and its intended use4 the ne<t step can either consist of ran) ordering the items into
a priority list4 classifying each item into one of several categories4 or rated in importance to the system.-
'ategories that are typically used to classify reuirements include9 ?1@ essential or reuired now4 ?2@ nice to
have or deferred until later4 or ?3@ nonessential.
5he systems analysts can then review the user#generated lists for feasibility and classify the essential
and nice#to#have items into categories based on user visibility and technical feasibility. Nisibility refers to
whether the item needs to be visible to or hidden from the user. 5he technical feasibility refers to an
inclusion possibility with relatively little additional cost4 or an impossibility with present cost constraints.
>eedbac) to the user for any modified items needs to be communicated promptly because the output from
the group sessions forms the foundation of user e<pectations.
.ecently and coinciding with the development of computer#based group decision support systems
?KD((@4 the manual group facilitation techniues such as A3D4 .3D ?rapid application development@4 and
other rapid analysis techniues ta)e on a new dimension as the groups use software to assist in the
gathering and documenting of the ideas generated from brainstorming4 consolidating the ideas into
categories4 voting on the ideas using several different voting techniues4 and preparing some of the final
documentation. 5he computer#assisted use of these techniues is often referred to as &A3D ?electronic
A3D@. (ometimes '3(& technology is used to assist with the documentation of reuirements during
facilitated4 group#based meetings.
5he 2ury is still out on the overall effectiveness of automated support used to assist with gathering and
documenting sub#activities of reuirements determination. (ome businesses have had significant success in
their use while others have found that the technology seriously inhibits the ob2ectives of the facilitated4
group#based meetings. >ew practitioners would argue with the fact that computer#based support for these
meetings is beneficial when the technology is unobtrusive to the group.
.egardless of whether reuirements are gathered electronically or manually at the global4 individual4 or
group level4 there are three common threads9 ?1@ feedbac) to the user for verification is necessary4 ?2@
conte<t#free content is desired4 and ?3@ good communication s)ills are reuired. 'onte<t#free content means
that the solution is not part of the uestion. >or e<ample4 the systems analyst might as)9 7=hat problems
are li)ely to be encountered in the environment where the system will be used87 instead of 7=hat problems
are we li)ely to encounter using a database to solve this problem87
Feedba,7 to the &ser
In some ways the feedbac) to the user is what drives the development of many of the new automated
software tools used to document systems development. >or e<ample4 flowcharts and pseudocode were
replaced by conte<t and data flow diagrams as primary tools to diagram system processes because these
two diagrams are often more easily understood by the user. (imilarly4 ob2ect technology is currently
e<ploring notation and symbols that can be used both by the systems analyst to document the essence of the
system and by the user to verify that the systems analyst has indeed gathered the essence of the information
system accurately.
:ther documentation techniues such as the pages of system narrative and signed#off input and output
screen designs are also feedbac) to the user from the systems analyst. 3ll of these techniues fall short of
providing a fail#safe way to assure that the systems analyst has gathered all the reuirements. 'ertainly
records and minutes of meetings held4 decisions made in prototyping sessions4 facilitated group session
3*
results4 and user interview responses are all available to provide multiple ways to verify that the systems
analyst has not misrepresented what the user has indicated is important. No doubt much more research is
needed to find improved techniues to document and verify reuirements.
Requirements Ambi/uity
Kathering reuirements is filled with potential problems due to the uncertainty and ambiguity of this highly
cognitive activity. >igure 2.!a shows that the goal for gathering reuirements is to determine e<actly what
the user wants and e<actly what the user does not want. (ystems analysts often assume that what the user
does not want is everything not mentioned in what the user does want. =hen systems analysts start the
reuirements#gathering activity4 they often vacillate bac) and forth with the user as depicted in >igure 2.!b.
Msers may as) for something to be in the system when in fact they really do not want it ?but genuinely don-t
)now at this time that they don-t want it@. 5his is )ind of li)e wishing you could switch places with some
sports hero or movie star and then4 after doing so4 reali,e how comple< and public such a life would be.
(witching bac) to your real self again4 you are than)ful that you are not /r. hero or /s. movie star.
During the reuirements#gathering activity4 which could span several hours4 days4 or wee)s4 the
systems analyst and the user e<plore and iterate around the real reuirements as in >igure 2.!c4 hoping to
come as close to the real reuirements goal as possible. 5he larger and more comple< the information
system that the systems analyst is wor)ing on4 the less li)ely he or she will be to e<actly match the goal as
shown in >igure 2.!a.
5he three most common sources of reuirements ambiguity are $1( missin/ requirements5 $2(
ambi/uous 6ords5 and $>( introdu,ed elements. /issing reuirements are simply those things that are
needed and necessary for the success of the information system but are not included for a variety of
reasons4 such as the user forgetting to mention them4 politics within the business4 cost4 additional time
reuired to include them4 systems analyst did not thin) to as) about them4 and so on. In most situations
40
missing reuirements happen for legitimate and understandable reasonsI however4 on a less freuent basis4
reuirements are missing for pre2udicial or illegitimate reasons. In such a situation the user either overtly or
covertly attempts to sabotage the system because of personal reasons. 5his may seem hard to believe4 but it
happens. Faven-t you ever tried to sabotage something that you did not want to do or participate in8
5he second most common problem that leads to reuirements ambiguity is ambiguous words. =ords
such as large, small, inventory, service, user, overnight, weekend, net pay, going out, and inexpensive
have a significant amount of fle<ibility as to their interpretation and e<act meaning. 5here are thousands
more 2ust li)e these4 and all of them leave the use of the word in a particular situation open to a great deal
of sub2ectivity. >or e<ample4 a reuirement li)e 7build me a large bedroom addition to my home7 has an
incredible amount of sub2ectivity to it. 5he builder-s interpretation of a large bedroom may be significantly
different than that of the person who wants the large bedroom to be built. =ith that statement as the
reuirement4 even the cost and time estimates to complete the bedroom submitted from different home
building contractors bidding on the 2ob could be all over the map. Information systems are no different. 5he
reuirements must be e<actly spelled out or significant interpretation and sub2ectivity creep into the pro2ect.
5his often leads to user dissatisfaction with the outcome because it differs from his or her e<pectations of
what the information system would be li)e and would accomplish.
5he third most common problem that leads to reuirements ambiguity is introduced elements. (imply
put4 introduced elements are liberties ta)en by the systems development team with the hope that 7the user
will li)e it7 ?I call this the 7/i)ey li)es it7 syndrome@. =ith best intentions4 the systems analyst and even
the programmer may ma)e some decisions that affect the system without first getting the approval of the
user. It could be something as simple as printing the date at the beginning of a report or as comple< as
interpreting an ambiguous word such as overnight to mean that a report is to be delivered to the user by
10930 a.m.4 since that-s the time most overnight delivery services advertise. 5he user may really need the
report by $900 a.m. and so will be unhappy with the liberty ta)en by the systems analyst.
3s with most sports teams4 a systems development team develops synergy as it wor)s together. 5he
team members begin to anticipate responses from other team members based on interaction over time with
each other. 5his is often good4 but it can also lead to problems if our anticipated response is different than
what would be the actual response had we as)ed the individual.
.euirements ambiguity is further e<acerbated by a systems analyst ma)ing observational and recall
errors or interpretation errors4 and can also be attributed to the comple< nature of human interaction.
:bservational errors occur when the systems analyst observes some operation within the business4 say the
canning of tuna fish4 but miss some aspect of the process for one reason or another. .ecall errors occur
primarily when a systems analyst tries to either remember something that was said during a meeting or
loo)s at his or her notes of a meeting and has difficulty recalling the correct interpretation of the notes.
Fave you ever had one of these problems when loo)ing at your own class notes while studying for a test8
Interpretation errors arise when you thought an idea was e<pressed in one way when in actuality it was
e<pressed or intended to be e<pressed differently.
5he bottom line for reuirements gathering and ambiguity is that of time4 money4 and information
systems that do not meet the needs of the user. (tudies over many years have suggested that the cost to fi<
errors4 oversights4 and other problems that e<ist in reuirements documents escalates the further you are
into the pro2ect when the problem is detected. >or e<ample4 the cost of fi<ing a reuirements problem that is
discovered a few days prior to actual system usage by the user can be anywhere between 30 and "0 times
the cost of discovering and fi<ing the same problem during the reuirements determination activity of the
pro2ect. 3 cost of J14000 to fi< a problem during the reuirements activity could wind up costing as much
as J"04000 to fi< the same problem when it is finally discovered very late in the pro2ect. Eased on this
alone4 the s)ills and abilities of the systems analyst to perform reuirements gathering successfully is
critical to any information systems pro2ect.
41
#&::AR%
Information systems feasibility analysis should ta)e into account operational4 technical4 and financial
feasibility prior to starting and during a systems development pro2ect. Information systems are viewed as
capital investments and are therefore sub2ected to the same )inds of investment analysis4 as are other
capital resources of the business. 3ll three feasibility types should be monitored during the life of a systems
development pro2ect. Information systems have two ma2or cost components4 the systems development costs
and the ongoing operational costs. Information systems also have benefits4 some of them are tangible and
others are intangible. 5he intangible ones may be the most difficult to assess in economic terms4 but often
these benefits are the ones that can ma)e an information system which loo)s to be a bad economic
investment become a good one for the business.
5o summari,e the reuirements determination activity4 one needs to )eep in mind that of all the
activities in information systems development4 this one is perhaps the most cognitive and the least
understood. 'onseuently4 very little automated support is available for the cognitive portion of the wor)
done. /ost systems analysts and users agree on what the outcome of reuirements determination needs to
be9 a definitive list of things ?data4 information4 functions or services4 e<pectations4 and so on@ reuired to
build the system. =hat is usually vague or missing is a well#articulated methodology for arriving at the
definitive list.
5he %I&'&( framewor) and the reuirements model provide a way to categori,e uestions that need to
be as)ed so that dimensions to the problem are not overloo)ed. 5he reuirements model actually subsumes
the %I&'&( framewor) by addressing the need for the system or pro2ect from a business perspective. 5his
is desirable so that the information system being developed can enhance some aspect of the business.
'oad-s method for gathering reuirements was given in order to present an ob2ect#oriented approach to
gathering reuirements.
.egardless of the framewor)4 model4 or methodology used to gather reuirements4 there are three
generally accepted ways to answer the uestions needed to build the reuirements list9 ?1@ global research4
such as reviewing reports4 forms4 and files4 and reviewing the performance of other companies by
contacting or visiting themI ?2@ individual interviews4 surveys4 observation4 research4 site visits4 and so onI
and ?3@ group sessions in the form of A3D4 &A3D4 andHor rapid analysis techniues. &ach of these
approaches reuires that the systems analyst as) appropriate uestions4 provide feedbac) to the user4 and
have good communication s)ills.
.euirements ambiguity needs to be avoided when gathering and documenting reuirements. 5he three
most common sources of reuirements ambiguity are missing reuirements4 ambiguous words4 and
introduced elements. 5he systems analyst is responsible for eliminating ambiguity in the final reuirements
specification document.
CHAPTER 9&E#T!O*#)
2.1 =hat is the meaning of feasibility in an information systems development pro2ect conte<t8
2.2 =hat is feasibility analysis and what is its purpose in information systems development8
2.3 Discuss operational feasibility in an information systems development pro2ect.
2.4 =hat does technical feasibility measure8
2.5 =hat are some of the implications of economic feasibility ?or non#feasibility@ of an information systems
development pro2ect8
2.! =hat are some of the different elements that ma)e up systems development costs and annual operating
costs8
42
2." In information systems development4 what does the reuirements determination process accomplish8
2.$ 1ist several of the problems and difficulties associated with reuirements determination.
2.* Describe how a business-s environment can have an effect on the reuirements determination process.
2.10 Discuss a particular problem that may result when a systems analyst is wor)ing with an unfamiliar
topic or functional business area.
2.11 'ontrast the problem domain with an information system as a whole. =hat differentiates the two8 3nd
what or who determines what each will consist of8
2.12 =hat do reuirements mean in an information systems conte<t8 Fow does this differ from a common
definition of reuirements8
2.13 =hy is reuirements determination regarded as a perpetual activity8
2.14 =hat are the four sub#activities within reuirements determination and what is the role of each8
2.15 Fow do these sub#activities relate to each other8
2.1! Eriefly describe the main idea behind the %I&'&( method of reuirements determination.
2.1" =hat are the components of the %I&'&( model8 Eriefly describe each.
2.1$ =hat is the first part of +o,ar-s .euirements /odel8 Discuss its importance with regard to the
model as a whole.
2.1* In what case would the %I&'&( model rather than the reuirements model be a more practical method
of reuirements determination8
2.20 Name and briefly describe the four ma2or activities in 'oad-s ob2ect#oriented method for gathering and
modeling problem domain reuirements.
2.21 Name and briefly describe the four ma2or model components in 'oad-s ob2ect#oriented method for
gathering and modeling problem domain reuirements.
2.22 =hat are the global4 individual4 and group methods available for gathering reuirements8 =hat are
some of the problems with these particular methods8
2.23 =hat is most important to )eep in mind during the reuirements determination process8
2.24 =hat is prototyping and what advantages does it present during reuirements determination8
2.25 =hat are some of the other group#level techniues and how can they be used to enhance the
reuirements determination process8
2.2! Kive an e<ample of how group#level interaction in reuirements determination can fail.
2.2" Describe the steps that facilitated groups ta)e during reuirements determination.
2.2$ =hat are the three common elements essential to reuirements determination4 regardless of the method
used to gather8
2.2* =hat is the main goal behind reuirements determination8
2.30 Discuss some of the problems that lead to reuirements ambiguity. Fow can these problems be
alleviated8
2.31 =hy are correcting errors and reali,ing deficiencies so important during the reuirements
determination process8
CHAPTER REFERE*CE#
'F:N:1&(4 /.A.4 7(uccess with :b2ect 3nalysis9 1essons 1earned on Fow to 'hart Cour 'ourse47
:b2ect /aga,ine ?>ebruary 1**4@4 50#5$.
':3D4 %.4 D. D. N:.5F and /. /3C>I&1D4 Object Models: Strategies, atterns, and !pplications.
&nglewood 'liffs4 NA9 %rentice Fall4 1**5.
43
D3NI(4 3./.4 7.euirements &ngineering47 in "ncyclopedia of Software "ngineering4 ed. A.A. /arcinia).
New Cor)9 Aohn =iley L (ons4 Inc.4 1**44 pp. 1043#10544 Nol. II.
D3NI(4 3./.4 Software #e$uirements !nalysis and Specification. &nglewood 'liffs4 NA9 %rentice Fall4
1**0.
D3NI(4 K:.D:N E.4 7(trategies for Information .euirements Determination47 IE/ (ystems Aournal4
214 no. 1 ?1*$2@4 4#2*.
K3M(&4 D.'.4 and K./.=&INE&.K4 "xploring #e$uirements: %uality &efore 'esign. New Cor)9
Dorset Fouse %ublishing4 1*$*.
F(I34 %.4 3. D3NI(4 and D. +MNK4 7(tatus .eport9 .euirements &ngineering47 I&&& (oftware4 104 no.
! ?November 1**3@4 "5#$0.
I&&& (oftware4 vol. II4 no. 2 ?/arch 1**4@4 theme issue on .euirements &ngineering.
+:D3.4 +..3.4 (umani)ed *nformation Systems !nalysis and 'esign. New Cor)9 /cKraw#Fill Inc.4
1*$*.
N3M/3NN4 D.A.4 K.E. D3NI(4 and A.D. /'+&&N4 7Determining Information .euirements9 3
'ontingency /ethod for (election of a .euirements 3ssurance (trategy47 5he Aournal of (ystems and
(oftware4 1 ?1*$0@4 2"3#2$1.
N:./3N4 ..A. and K.>. ':.EI554 75he :perational >easibility %erspective47 Aournal of (ystems
/anagement4 vol. 424 no. 10 ?:ctober 1**1@.
N&((&C4 1.4 and (.3. ':NK&.4 7.euirements (pecification9 1earning :b2ect4 %rocess4 and Data
/ethodologies47 'ommunications of the 3'/4 3"4 no. 5 ?/ay 1**4@4 102#113.
NI5313.I4 N.%4 73n Investigation of the %roblem (olving Eehavior of (ystems 3nalysts47 unpublished
%h.D. dissertation4 Mniversity of /innesota4 1*$1.
NI5313.I4 N.%4 73 'ritical 3ssessment of (tructured 3nalysis /ethods9 3 %sychological %erspective47 in
Eeyond %roductivity9 Information (ystems Development for :rgani,ational &ffectiveness4 ed. 5h./.3.
Eemelmans9 &lsevier (cience %ublishers E.N ?North Folland@4 1*$44 pp. 421#433.
=::D4 A. and D. (I1N&.4 +oint !pplication 'esign. New Cor)9 Aohn =iley L (ons4 1*$*.
=&5F&.E&4 A3/&( '.4 Systems !nalysis and 'esign ?2nd ed.@. (t. %aul4 /N9 =est %ublishing
'ompany4 1*$4.
=FI55&N4 A.1.4 1.D. E&N51&C4 and N/. E3.1:=4 Systems !nalysis , 'esign Methods ?3rd ed.@.
Eurr .idge4 I19 Irwin4 1**4.
44

Feasibility Analysis and Requirements Determination

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Feasibility Analysis and Requirements Determination

Încărcat de

Drepturi de autor:

Formate disponibile

Chapter 2 - Feasibility Analysis and Requirements Determination

CHAPTER OBECT!"E# $%O& #HO&'D BE AB'E TO()

S-ar putea să vă placă și