Chapter 2 - Feasibility Analysis and Requirements Determination

CHAPTER OB ECT!"E# $%O& #HO&'D BE AB'E TO() 1. 2. 3. 4. 5. !. ". $. *. 10. 11. 12. Define information systems development feasibility. Define feasibility analysis. Discuss what feasibility analysis allows systems analysts to do. Name and discuss three types of feasibility. Identify the main challenges to re uirements determination. Describe the concept of problem domain. Define the sub#activities associated with the re uirements determination activity. Define and apply the %I&'&( framewor) for doing re uirements determination. Define and apply +o,ar-s .e uirements /odel framewor) for doing re uirements determination. 1ist and discuss 'oad-s ob2ect#oriented framewor) for doing re uirements determination. Discuss techni ues for gathering an information system-s true re uirements. Identify the most common causes of re uirements 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 re uirements 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 fre uently 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 authorThis 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.

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

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.

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

2!

RE9&!RE:E*T# DETER:!*AT!O* 5he re uirements determination activity is the most difficult part of information systems analysis. .e uirements determination addresses the gathering and documenting of the true and real re uirements 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 re uirements 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 re uirements 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. .e uirements 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 re uirements 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 re uirements for a financial information system from the controller of the company. Due to the 7 uestion and answer7
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

2"

nature of re uirements 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 re uirements 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 ac uire 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 re uirements 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 re uirement for only handling M.(. dollars for payment. 'ommunication among the information systems development pro2ect team members has traditionally been another challenge for re uirements 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 re uirements 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 re uirements are so involved that they could fill a boo) this si,e or larger. 5he user is e<pected to read through the re uirements 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 re uirements 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!*
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

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 re uirements. 3s mentioned earlier4 re uirements determination addresses the gathering and documenting of the true and real re uirements 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 re uired in order for you to graduate4 such as general education courses. :ther courses may also be re uired 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 re uired to do in order to be useful and successful to the user. :ther courses are selected based on personal preference ?e.g.4 golf4 rac uetball4 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 re uired 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 techni ue 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 re uirements for our purposes is the wants andHor needs of the user within a problem domain. 5echnically spea)ing4 re uirements refer to those items that are necessary or essential in the system. =ithin the systems conte<t4 however4 re uirements often

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

2*

includes those items that may not necessarily be essential but are4 nonetheless4 desired and4 therefore4 re uired.

%erhaps it is this confusion over what is essential4 needed4 desired4 or re uired of the system that ma)es it so difficult to systematically articulate e<actly what a systems analyst is to do during the re uirements determination activity of the development pro2ect.- In reality the re uirements are defined at the beginning of the pro2ect along with the system-s ob2ectives. Fowever4 additional re uirements are often identified during later activities of the systems development life cycle ?(D1'@. >or e<ample4 new or changed re uirements 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 re uirements determination being completed very early during systems development4 it is somewhat artificial to close off the definition and gathering of re uirements 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 re uirements 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 re uirements determination techni ues. In most cases articles and boo)s on the sub2ect fall into two broad categories9 ?1@ framewor)s or ways to classify re uirements into sub2ect areas so that categories of re uirements 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 re uirements determination activity of the pro2ect. &ach of these is addressed separately ne<t.

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

30

FRA:E;OR<# FOR DETER:!*AT!O*

&*DER#TA*D!*=

A*D

DO!*=

RE9&!RE:E*T#

=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. .e uirements determination sub#activities 2. %I&'&( framewor) 3. +o,ar-s .e uirements /odel 4. :b2ect#oriented re uirements modeling activities Requirements Determination #ub-a,ti8ities .e uirements determination is the general data#gathering activity done during analysis. It has four sub# activities6re uirements anticipation4 re uirements elicitation4 re uirements assurance4 and re uirements specification. :ne of the earliest research articles to deal with understanding the re uirements 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 re uirements determination activity as listed previously and described in more detail here9 1- Requirements Anti,ipation- 5he systems analyst hypothesi,es that particular re uirements 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- re uirements for passing their courses. If you have the same instructor twice4 you are even more able to anticipate his or her course re uirements. 2- Requirements Eli,itation- 5he systems analyst uses this activity to gather the essential re uirements from the user employing a variety of techni ues4 such as interviews4 uestionnaires4 group brainstorming meetings4 and voice and e#mail. >- Requirements Assuran,e- 5he systems analyst uses the activity of re uirements assurance to validate and verify the re uirements with the user as being the real and essential re uirements. 3 user wal)#through in which the systems analyst and the user together review documented re uirements in detail is one assurance techni ue. ?- Requirements #pe,i3i,ation- 5his is the activity that the systems analyst uses to e<plicitly catalog and document the re uirements 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 re uirements determination activity ma)es them more effective as they gather re uirements for a proposed information system. The P!ECE# Frame6or7

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

31

5he second framewor) to discuss4 called the %I&'&( model and first presented by =etherbe4 focuses on the actual wor) of doing re uirements determination. 5his model is used to classify identified re uirements into one of si< sub2ect areas6 Per3orman,e5 !n3ormation5 E,onomy5 Control5 E33i,ien,y5 and #er8i,es5he 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 re uirements. =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 re uest and the response to that transaction or user re uest@ are considered. >or e<ample4 the systems analyst may as) uestions about the needed response time or throughput re uired 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 re uired by the users of the system87 or 7=hat outputs are re uired87 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 re uired 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 ac uisition e uipment 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 re uired 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 re uired 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 re uirements 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
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

32

functional re uirements4 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 re uirements. <o@arAs Requirements :odel +o,ar-s .e uirements /odel is the third framewor) and is shown in the lower portion of >igure 2.4. It too focuses on a techni ue useful to a systems analyst doing re uirements determination. Instead of classifying re uirements into one of si< categories as in the %I&'&( model4 +o,ar-s re uirements 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 re uirements 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 re uirements 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 e uipment 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.
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

33

/ost often4 successful use of the re uirements 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 be as)ed and answered at every organi,ational level6corporate4 division4 region4 department4 section4 and so on. 5he important point for the re uirements model is that a general business direction must be provided before the information system re uirements can be identified. 3lthough desirable4 it is not absolutely essential to have an entire organi,ation-s business model defined before applying the re uirements 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 re uirements determination using the re uirements 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 re uirements model4 it is often possible to e uate 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 re uirements 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 e uate 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.

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

34

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

35

+o,ar-s re uirements model for eliciting and developing re uirements 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 re uirements 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 re uirements 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 re uirements 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.

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

3!

5he last term to be discussed here is a scenario. 3 scenario is a time#ordered se uence of ob2ect interactions to fulfill a specific responsibility. 3 scenario would be developed for each of the preceding 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 re uirements determination modeling approach would involve the following four ma2or activities9 1. 2. 3. 4. Identify purpose and features of the information system. Identify ob2ects and patterns. &stablish ob2ect responsibilities9 7what I )now47 7who I )now47 and 7what I do.7 =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 re uirements 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 re uirements mean in a general sense4 the first step in deciding how to gather4 document4 and validate the re uirements 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 re uirements can be viewed from global4 individual4 or collective ?group@ perspectives. (tarting with the global view of the system4 the re uirements 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 re uirements#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 ac uaint the systems analyst with at least minimum4 already established4 re uirements. 5o customi,e the system re uirements to the problems at hand4 however4 individual re uirements 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 re uirements. Interviewing for re uirements 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
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

3"

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. 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 re uirements 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 re uirements 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 re uirements 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 re uirements 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 techni ues of any type. &ssentially4 A3D and rapid analysis techni ues 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 subse uent 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 techni ues4 and A3D4 other group techni ues 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 re uirements. 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 re uirements 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 re uirements 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 re uirements 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
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

3$

system information4 data4 and functional re uirements. 5he ran) ordering can be as simple as classifying each of these items as mandatory4 highly desirable4 desirable4 nice to have4 or not necessary. 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 re uirements include9 ?1@ essential or re uired 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 techni ues such as A3D4 .3D ?rapid application development@4 and other rapid analysis techni ues 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 techni ues4 and preparing some of the final documentation. 5he computer#assisted use of these techni ues is often referred to as &A3D ?electronic A3D@. (ometimes '3(& technology is used to assist with the documentation of re uirements 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 re uirements 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 re uirements 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 re uired. '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 techni ues 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 techni ues fall short of
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

3*

providing a fail#safe way to assure that the systems analyst has gathered all the re uirements. 'ertainly records and minutes of meetings held4 decisions made in prototyping sessions4 facilitated group session 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 techni ues to document and verify re uirements. Requirements Ambi/uity Kathering re uirements 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 re uirements 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 re uirements#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 re uirements#gathering activity4 which could span several hours4 days4 or wee)s4 the systems analyst and the user e<plore and iterate around the real re uirements as in >igure 2.!c4 hoping to come as close to the real re uirements 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 re uirements ambiguity are $1( missin/ requirements5 $2( ambi/uous 6ords5 and $>( introdu,ed elements. /issing re uirements are simply those things that are needed and necessary for the success of the information system but are not included for a variety of
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

40

reasons4 such as the user forgetting to mention them4 politics within the business4 cost4 additional time re uired to include them4 systems analyst did not thin) to as) about them4 and so on. In most situations missing re uirements happen for legitimate and understandable reasonsI however4 on a less fre uent basis4 re uirements 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 re uirements 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 re uirement 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 re uirement4 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 re uirements 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 re uirements 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. .e uirements 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 re uirements 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 re uirements documents escalates the further you are into the pro2ect when the problem is detected. >or e<ample4 the cost of fi<ing a re uirements 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 re uirements determination activity of the pro2ect. 3 cost of J14000 to fi< a problem during the re uirements 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
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

41

alone4 the s)ills and abilities of the systems analyst to perform re uirements gathering successfully is critical to any information systems pro2ect. #&::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 re uirements 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. 'onse uently4 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 re uirements determination needs to be9 a definitive list of things ?data4 information4 functions or services4 e<pectations4 and so on@ re uired 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 re uirements 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 re uirements 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 re uirements was given in order to present an ob2ect#oriented approach to gathering re uirements. .egardless of the framewor)4 model4 or methodology used to gather re uirements4 there are three generally accepted ways to answer the uestions needed to build the re uirements 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 techni ues. &ach of these approaches re uires that the systems analyst as) appropriate uestions4 provide feedbac) to the user4 and have good communication s)ills. .e uirements ambiguity needs to be avoided when gathering and documenting re uirements. 5he three most common sources of re uirements ambiguity are missing re uirements4 ambiguous words4 and introduced elements. 5he systems analyst is responsible for eliminating ambiguity in the final re uirements 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
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

42

2.! =hat are some of the different elements that ma)e up systems development costs and annual operating costs8 2." In information systems development4 what does the re uirements determination process accomplish8 2.$ 1ist several of the problems and difficulties associated with re uirements determination. 2.* Describe how a business-s environment can have an effect on the re uirements 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 re uirements mean in an information systems conte<t8 Fow does this differ from a common definition of re uirements8 2.13 =hy is re uirements determination regarded as a perpetual activity8 2.14 =hat are the four sub#activities within re uirements 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 re uirements 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 .e uirements /odel8 Discuss its importance with regard to the model as a whole. 2.1* In what case would the %I&'&( model rather than the re uirements model be a more practical method of re uirements determination8 2.20 Name and briefly describe the four ma2or activities in 'oad-s ob2ect#oriented method for gathering and modeling problem domain re uirements. 2.21 Name and briefly describe the four ma2or model components in 'oad-s ob2ect#oriented method for gathering and modeling problem domain re uirements. 2.22 =hat are the global4 individual4 and group methods available for gathering re uirements8 =hat are some of the problems with these particular methods8 2.23 =hat is most important to )eep in mind during the re uirements determination process8 2.24 =hat is prototyping and what advantages does it present during re uirements determination8 2.25 =hat are some of the other group#level techni ues and how can they be used to enhance the re uirements determination process8 2.2! Kive an e<ample of how group#level interaction in re uirements determination can fail. 2.2" Describe the steps that facilitated groups ta)e during re uirements determination. 2.2$ =hat are the three common elements essential to re uirements determination4 regardless of the method used to gather8 2.2* =hat is the main goal behind re uirements determination8 2.30 Discuss some of the problems that lead to re uirements ambiguity. Fow can these problems be alleviated8 2.31 =hy are correcting errors and reali,ing deficiencies so important during the re uirements 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.
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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

43

D3NI(4 3./.4 7.e uirements &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 .e uirements 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 .e uirements &ngineering47 I&&& (oftware4 104 no. ! ?November 1**3@4 "5#$0. I&&& (oftware4 vol. II4 no. 2 ?/arch 1**4@4 theme issue on .e uirements &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 .e uirements9 3 'ontingency /ethod for (election of a .e uirements 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.e uirements (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.

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 authorThis boo7 6as pre8iously published by Prenti,e-Hall5 !n,-

44