CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

Chapter Object !e"

At the end of this chapter, you would have learnt : activities in requirements determination; fact-findings techniques; prototyping; tools for requirements specification. E""e#t a$ Rea% #&" '(r th " Chapter Analysis & Design of Information ystems !"nd #dition$, %ames A. )c*raw-+ill. ,-hapter ., page &/" - &.01 enn !&'('$,

ystems Analysis and Design, *ary 2. helly, 3homas %. -ashman, %udy Adams4i & %oseph %. Adams4i !&''&$, 2oyd & 5raser. ,-hapter ., page & - "&1 ystems Analysis And Design !"nd #dition$, 6enneth #. 6endall & %ulie #. 6endall !&''"$, 7rentice-+all. ,-hapter &&, page "(. - ./81

4-1

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)*

I#tr(%+ct (#
In the preliminary investigation, your main tas4 is to identify what activities are ta4ing place in the e9isting system. 3he ne9t activity of system analysis is to find out how the activities are carried out, who are responsi:le for them, to whom the information is for, and where they are carried out. 3his activity is 4nown as requirements determination. -ollecting the right requirements for su:sequent systems development is a critical tas4. Incorrect requirements identification will lead to displeased users and unwanted systems; resources invested will therefore go to waste. ;ou therefore should put in effort and allow enough time to perform this facts collection stage. 3o determine systems requirements, it means studying the e9isting :usiness system to identify the functions and tas4s :eing performed. As the system is :eing carefully analysed, possi:le areas for improvements are identified. 3his study includes :oth manual and computerised functions. ;ou should avoid the following fum:les commonly made :y many analysts: -oncluding solutions for those pro:lems identified, as the study is conducted. 3his tends to result :etter and more effective solutions :eing overloo4ed. <orse, the solutions committed at such an earlier stage may not even :e appropriate. 3his stage demands patience and leaves design at a later stage. 7artial 4nowledge is formed as an analyst identifies only areas that can :e computerised, which can cause su:sequent interface difficulty. -omputerisation is not the only means of improvement. Instead, pursue complete and comprehensive understanding of the wor4ing of the e9isting system, not a partial one.

4),

Act ! t e" # Re-+ re.e#t" Deter. #at (#

7reliminary Investigation

=equirement Anticipation =equirement Investigation =equirement pecification

During requirements determination, three main activities !as shown in figure 0.&$ are involved: requirements anticipation, requirements investigation, and requirements specifications.

Figure 4.1: Activities of Requirement Determination

4-2

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4),)*

Re-+ re.e#t" A#t c pat (#

In all systems analysis cases, system analysts would employ a certain degree of their own e9periences to investigate the systems. 3hey would try to relate e9periences particularly of similar systems studied :efore. 3he relevant e9periences may ena:le these analysts to e9amine areas of the current systems that would otherwise go unnoticed :y an ine9perienced analyst. -ertain pro:lems or features required in new systems may also :e anticipated too. =elevant e9perience is indeed :eneficial in systems investigation. >n the other hand, e9perience can introduce :ias or shortcuts during investigation. #9perienced analysts tend to map their current pro?ects investigation with past pro?ects studied, even they are different. 3his inevita:ly results :ias :eing introduced. imilarly, e9perienced analysts may content with their e9periences and thus may ta4e shortcuts :y assuming certain features without conducting any appropriate investigation.

4),),

Re-+ re.e#t" I#!e"t &at (#

An important and relia:le method of gathering requirements is through investigation. 3his activity is the core of systems analysis. In conducting this activity, the following characteristics of e9isting systems are to :e uncovered: Content Inputs <hat are the data that will :e flowing into the systems@ 3he amount of inflow data@ <hen do the inputs come in@ Any special pea4 period@ 2y phone, fa9, forms, ver:al, or others@ -ustomerBs place, or counter@ <ho are the senders@ Outputs <hat are the records and files to :e maintained, and reports to :e generated@ 3he amount of information to :e maintained@ <hen are the outputs required@ 3o :e produced regularly, periodically, or on demand@ 3o :e displayed, printed in hard copies, stored in recordsAfiles, or others@ -a:inets, or safes@ <ho are the receivers@ Processes <hat are the functions and computations to :e carried out@ 3he capacity e9pectancy@ 2atch or realtime processing@ 3he turnover capacity@ -alculators, typewriters, shelves, or others@ Divisions, departments, or sections@ <ho are the operators@ Controls <hat are the rules and regulations@ 3he accepta:le ranges@ 3urnover time@ 2eing performed on demand, periodically or regularly@ Alarm systems, forms, or others@

Volume Timing Frequency

Equipment

Location People

Divisions, Departments, or sections@ <ho are responsi:le@

5act-finding techniques !discussed later in section 0..$ are employed to carry out the requirements investigation. 5ollowing the investigation is documentation.

4-3

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4),)/

Re-+ re.e#t" Spec ' cat (#"

3he facts gathered after the requirements investigation are e9amined to identify :oth e9isting and potential pro:lems. A list of desired features for the new system, in alignment with the organisationBs needs, is derived. #ssential features are separated from the less critical features and are documented accordingly as requirements specification. >perational details to performance criteria are specified in it too. 3he methods that will :e used achieve these stated features are selected. 3hese form the :asis for systems design, which follows requirements specification.

4)/

Fact0' #% #& Tech# -+e"

3he specific fact-finding techniques employed :y analysts in gathering facts are: a. :. c. d. e. interview; questionnaire; documents review; o:servation; and research.

It is common analysts employ a com:ination of the a:ove techniques to investigate systems requirements. 3he following sections will e9amine these in more details.

4)/)*

I#ter! e1

)uch of analystsC time during information gathering and even preliminary investigation phases is used in conducting interviews. 3he interviewees are current users, sometimes customersAsuppliers, of the current system or potential users of the proposed systems. During interviews, it is important to gather as much relevant information as possi:le. +ence you ought to create a conversational atmosphere rather than an interrogative atmosphere for more cooperative participants. 3o enhance the communication, it should :e conducted in an appropriate environment !prefera:ly a quiet meeting room$. 3his technique is often the :est source of qualitative information, li4e individualsC opinions, su:?ective activities and pro:lems. )any analysts prefer this approach then other fact-finding techniques. In face of illiterate individuals or those who cannot communicate effectively in writings, interviews are effective fact-finding means. 3he intervieweesC face e9pressions can :e o:served. o are their :ody language. It reveals avenues of further questioning that may have gone untapped. +owever, you should :e warned that interview has limitations and other techniques ought to :e considered too. Interviews tend to ta4e up considera:le and dedicated time of :oth interviewer and interviewee. Interviewees may not spea4 the truths as they suspect its confidentiality. And a num:er of times, interviewees simply would deviate off to irrelevant details. In short, the success of an interview depends very much on the s4ill and preparation of the interviewer.

4-4

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)/),

Q+e"t (##a re"

3his is a commenda:le approach in terms of target of audience. It ena:les a large num:er of participants, from various departments to even various countries, to :e involved in the systems investigation. <ith standardised questions and assurance of anonymity, the facts gathered tend to :e more relia:le and often more honest responses. Analysts may use open-ended questionnaires to gather qualitative information !opinions, su:?ective activities and pro:lems$ and closed-ended questionnaires to gather quantitative information !num:ers, frequencies, and volume$. D 3he following notes, from here onwards, are e9tractedAmodified from: Analysis & Design of Information ystems, %ames A. enn !&'('$. +owever, the high cost of developing and distri:uting questionnaires demands that analysts carefully consider the o:?ective of the questionnaire and determine what structure will :e most useful to the study and most easily understood :y the respondents. Euestionnaires should :e tested and, if necessary, modified :efore printed and distri:uted. As with interviewees, recipients of questionnaires should :e selected for the information they can provide. 3he analyst should ensure that the respondentsC :ac4ground and e9periences qualify them to answer the questions.

4)/)/

D(c+.e#t" Re! e1

)any 4inds of records and reports can provide analysts with valua:le information a:out organisation and operations. In documents reviews, analysts e9amine information that has :een recorded a:out the system and users. =ecord inspection can :e performed at the :eginning of the study, as an introduction, or later in the study, as a :asis for comparing actual operations with what the records indicate should :e happening. =ecords include written policy manuals, regulations, and standard operating procedures used :y most organisations as a guide for managers and employees. 3hey do not 4now what activities are actually occurring, where the decision-ma4ing power lies, or how tas4s are performed. +owever, they can help analysts understand the system :y familiarising them with what operations must :e supported and with formal relations within the organisations. 2e aware, however, that sometimes the documented records !i.e. the operating procedures, policy manuals, and regulations$ can :e out dated. ome documented forms might no longer :e in use, or actual practices might not comply to system documentation. +ence you should only review copies of the actual forms and operating documents that are currently used in the system. 2oth :lan4 copies of forms and samples of actual completed forms should :e collected. D 3he following notes, from here onwards, are e9tractedAmodified from: ystem Analysis and Design, *ary 2. helly, 3homas %. -ashman, %udy Adams4i & %oseph %. Adams4i !&''&$.

4-5

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)/)4

Ob"er!at (#

Another fact-finding technique is the o:servation of current operating procedures. >ften, it ta4es o:servation of a system in action to fully understand that systemCs requirements. eeing the system in action gives you an additional perspective to supplement what you have heard and read. During o:servation, you might solidify your haFy understanding of the system and its procedures. ;ou might also correct any misconceptions or erroneous impressions you had formed. In addition, :y personal o:servation you can verify statements made in interviews as well as determine if procedures operate as specified in the system documentation. ;ou might even discover that neither the system documentation nor the statements from those interviewed truly reflect the system in operation. 7ersonal o:servation can also provide advantages that will :ecome significant during later phases in the systems development life cycle. 5or e9ample, recommendations often receive :etter acceptance when they are :ased on personal o:servation of actual operations. Also, personal o:servation helps you acquire the 4now-how you will need if you are as4ed to assist or supervise the testing or installation of the changes that have :een recommended. ;ou also :ecome :etter acquainted with the operating personnel who will :e implementing the new or changed system. 7lan your o:servations in advance :y preparing a chec4list of the steps that you want to o:serve and the questions you want to as4. <hen you o:serve individuals performing tas4s, you should :e aware of a phenomenon called the +awthorne #ffect. 3he name comes from a study performed in the +awthorne, -hicago plant of <estern #lectric -ompany in &'"/s. 3he purpose of the study was to determine whether various types of changes in the wor4 environment would improve wor4er productivity. 3he surprising result was that wor4er productivity improved whether the environmental conditions were made :etter or worseG 3he conclusion drawn was that the wor4ersC productivity improved :ecause they 4new they were :eing o:served. <hen you o:serve wor4ers doing their ?o:s, 4eep the +awthorne #ffect in mind. Hormal operations might not always run as smoothly as your o:servations indicate. <or4ers might also :e nervous when you o:serve them. 2efore you o:serve them, therefore, you might meet with them and their supervisors to discuss your plans and o:?ectives and to help esta:lish a good wor4ing relationship with them.

4)/)2

Re"earch

=esearch represents yet another important fact-finding technique. =esearch can involve reviewing ?ournals, periodicals, and :oo4s that contain information relevant to the tas4 at hand. =esearch can involve attending professional meetings and seminars. 5ormal and informal discussions with other professionals in related areas also can shed valua:le light on the su:?ect. Also analysts may desire to learn more a:out the su:?ect :y visiting other similar systems for o:servations. D #nd of notes e9tractedAmodified from: ystem Analysis and Design, *ary 2. helly, 3homas %. -ashman, %udy Adams4i & %oseph %. Adams4i !&''&$.

4-6

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)4

Pr(t(t3p #&
7rototyping is the technique of quic4ly :uilding a functioning, :ut incomplete model of the information system using rapid application Development tools. 7rototyping has :ecome the design technique for many system designers. 7rototypes typically evolve into the final version of the system or application. 3raditionally, physical design has :een a paper-and-pencil process where analyst draws pictures that depict the layout or structure of outputs, inputs and data:ase and flow of dialogue and procedures. 3his process is normally time-consuming and prone to considera:le errors and omissions. )ore often than not the resulting paper wor4 is inadequate, incomplete, or inaccurate. A relia:le set of user requirements is a 4ey ingredient in a successful system development effort. +owever, in some cases gathering complete and accurate requirements are not possi:le. 3he proposed system may represent a totally new capa:ility for the user and as such the user may not :e a:le to accurately provide the new requirements, irrespective the amount effort :eing made. 3his is simply :ecause it is not possi:le for the user to visualise how the system would wor4. 7rototyping can help the user to visualise how the proposed system will wor4 via prototype. A prototype is an actual wor4ing model of the system, including sufficient functionality !although may not :e complete$ to allow the model to :e used in a IliveI setting. 7rototyping could involve the addition of new capa:ilities, the automation of currently manual processes, or any situation where the operational impact of the system is unclear.

Identify initial requirements and :uild a prototype

=eview the prototype

Dispose prototype

=evise the prototype

Prototyping Process

=efine the requirements

7rototyping is an iterative process as shown in figure a:ove. It :egins :y :uilding an initial prototype, :ased on initial requirements consolidated. 3he prototype is :uilt and revised fairly rapidly J usually in a matter of wee4s or months. 3he user wor4s with the prototype. =efinement of the requirements will :e made and effected :y revising the prototype. 3his process may :e repeated a few times until the user is satisfied with the prototype. In some cases, the prototype can actually :e placed in production. It is li4ely, however, that the prototype is disposed and the features of the prototype are used to complete the new system requirements. 3he main o:?ective of prototyping is thus to enhance the quality of the requirements specification.

4-7

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)4)*

C(#!e#t (#a$ SDLC !er"+" Pr(t(t3p #& Appr(ach

-onventional DK- !systems development life cycle$ and prototyping approaches each offer advantages and disadvantages for system development. 3he conventional approach to system development should :e used when the degree of user e9perience with systems development is high. In other words, the management and the system users should have average 4nowledge of computers. 3he conventional approach is also useful when systems requirements are well defined. <hen systems requirements are unclear, prototyping may :e the :est candidate. 3he proposed development of a new e9pert system to assist quality control managers in identifying defective parts is a good e9ample. uch a system may ta4e a considera:le amount of time to :uild. If immediate results are needed, prototyping is preferred. 7rototyping is also useful for pro?ects with a high degree of ris4, a large num:er of alternatives, and considera:le processing comple9ity. Analyst may also adopt a com:ination of :oth conventional and prototyping approaches as shown earlier in figure ".0 of chapter ".

4)4),

C$a"" ca$ Str+ct+re% !er"+" Pr(t(t3p #& Appr(ach

3here is another reason for the popularity of prototyping: classical structured analysis is regarded in some organisation as too time consuming; :y the time the analysis phase is finished, the user will have forgotten why he wanted the system in the first place. 3his is usually the result of one of the following pro:lems: 3he pro?ect team spent far too much time developing models of the current system and then had to spend even more time modelling the new system. 3he organisation prefers to invest little or no time doing any system analysis and to :egin coding as soon as possi:le. In such environment, the lengthy wor4 of system analysis, which appears to have no output e9cept lots of diagrams with :o9es and lines on them, is deemed unproductive. 3here may e9ist a steep learning curve in the :eginning as the systems analysts are learning new techniques and arguing with one another as to the :est way of applying the techniques. 7rototyping is thus seen as an effective solution to pro:lems mentioned a:ove. Hote also that prototyping tends to concentrate more on the human interface aspect of a systems development pro?ect. Lnfortunately, prototyping is often misused to simply avoid the steps of structured system development.

4-8

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)4)/

A%!a#ta&e" (' Pr(t(t3p #&

Lser orientation

>ne ma?or o:?ective of prototyping is to develop systems that meet user needs to a greater e9tent. 5ast development time It can ta4e a few wee4s or months to o:tain meaningful results, compared to the traditional approach, which can ta4e years for the complete system to :e operations. 5ewer errors 7rototyping allows errors to :e detected earlier. <ith the conventional factfinding approach, miscommunicated systems requirements, wrong requirements interpretation, and incorrect translation from design to coding, may go undetected until the end of the development process, which could ta4e years. )ore opportunity for changes <ith prototyping, the user can see and wor4 with the outputs from each su:system or component as it is :eing developed, ena:ling the user to suggest changes during the development process.

4)4)4

D "a%!a#ta&e" (' Pr(t(t3p #&

Demand high cooperation :etween the user and the developer Active usersC participation requires time that some users may not :e a:le to spend, particularly the managers. 3otal development costs can :e higher 3his is especially true if the user is constantly ma4ing changes to the system. 3his may also results longer development time. Ho or poor documentation 7rototyping is an iterative process, as such constant updates of documentation is la:orious and difficult. ystems developers tend to avoid the documentation completely, or produce an incomplete one.

4)2

T(($" '(r Re-+ re.e#t" Spec ' cat (#

<ith system requirements identified, the following activity is to document the requirements, particularly the :usiness processes. 3o document the :usiness processes means to descri:e the :usiness policy and the steps to transform certain inputs into outputs. #nglish may stri4e you as the natural tool to :e used in documentation. +owever, #nglish itself is not an effective tool. <hen used in descri:ing an iterative process, or alternatives, or even nested selections, the description will end up to :e wordy and clumsy. 3he comprehensi:ility of such description is difficult, if not impossi:le. 5urthermore, the wordings can :e am:iguous. 3he following sections will instead

4-9

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS e9amine some tools that can :e more effective in helping us to document the decisions involved in systems processes.

4 - 10

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

3he following notes, from here onwards, are e9tractedAmodified from: ystems Analysis And Design !"nd #dition$, 6enneth #. 6endall & %ulie #. 6endall !&''"$.

4)2)*

Dec " (# Tree"

Decisions trees are used when comple9 :ranching occurs in a structured decision process. 3rees are also useful when it is essential to 4eep a string of decisions in a particular process. Although the decision tree derives its name from natural trees, decision trees are more often drawn on their side, with the root of the tree on the left-hand side of the paper, :ranching out to the right. 3his allows the analyst to write on the :ranches in order to descri:e conditions and actions. It is useful to distinguish :etween conditions and actions when drawing decision trees. 3his is especially relevant when conditions and actions ta4e place over a period of time and their sequence is important. 5or this purpose, use a square node to indicate an action, and a circle to represent a condition as illustrated in figure 0... 3hus use of notation ma4es the decision tree more reada:le when one thin4s of a circle as signifying I5 while the square means 3+#H.

-hec4 if the desired :oo4 are &

Hot Availa:le

7lace a reservation

tamp due date " 8 -hec4 whether the :oo4 is classified as 0 N Ho M

Issue

Availa:le

;es (

=e?ect :orrow

Figure 4.3: Decision Tree for Book Borro ing Process In drawing the tree: &. ". Identify all conditions and actions and the order and timing of these !if they are critical$. 2egin :uilding the tree from left to right while ma4ing sure you are complete in listing all possi:le alternatives :efore moving over to the right.

4 - 11

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)2),

Dec " (# Tab$e"

A decision ta:le is a ta:le of rows and columns, separated into four quadrants, as shown in figure 0.0. 3he upper-left quadrant contains the condition, the upper-right quadrant contains the condition alternatives. 3he lower half of the ta:le contains the actions the actions to :e ta4en !on the left side$ and the rules for e9ecuting the actions on the right. C(#% t (#" a#% Act (#" -ondition Actions R+$e" -ondition alternatives Actions entries Figure 4.4: Decision Ta!"e

De!e$(p #& Dec " (# Tab$e" In order to :uild decision ta:les, the analyst needs to determine the ma9imum siFe of the ta:le, eliminate any impossi:le situations, inconsistencies, or redundancies, and simplify the ta:le as much as possi:le. 3he following steps provide the analyst with a systematic method for developing decision ta:les: &. Determine the num:er of conditions that may affect the decision. -om:ine rows that overlap J for e9ample, conditions that are mutually e9clusive. 3he num:er of conditions :ecomes the num:er of rows in the top half of the decision ta:le. Determine the num:er of possi:le actions that can :e ta4en. 3his :ecomes the num:er of rows in the lower half of the decision ta:le. Determine the num:er of condition alternatives for each condition. In the simplest form of decision ta:le, there would :e two alternatives !; or H$ for each condition. In an e9tended-entry ta:le, there may :e many alternatives for each condition. -alculate the ma9imum num:er of columns in the decision ta:le :y multiplying the num:er of alternatives for each condition. If there were five conditions and two alternatives !; or H$ for each of the conditions, there would therefore :e " N O ." !i.e. AH where A is the num:er of alternatives and H is the num:er of com:inations$ possi:ilities. 5ill in the condition alternatives. tart with the first condition row, divide the num:er of columns :y the num:er of alternatives for that condition. In the foregoing e9ample, there are ." columns and " alternatives !; or H$, so ." divided :y " is &8. 3hen choose the first row and write ; in all of the &8 columns, write H in the remaining &8 columns as illustrated :elow. =epeat the step for the rest of the conditions. Again using the e9ample, the second condition row will :e &8 divided :y " is (, the third condition row will :e ( divided :y " is 0 and so on.
;;;;;;;;;;;;;;;;HHHHHHHHHHHHHHHH ;;;;;;;;HHHHHHHH;;;;;;;;HHHHHHHH ;;;;HHHH;;;;HHHH;;;;HHHH;;;;HHHH ;;HH;;HH;;HH;;HH;;HH;;HH;;HH;;HH ;H;H;H;H;H;H;H;H;H;H;H;H;H;H;H;H

". ..

0.

N.

-ondition & -ondition " -ondition . -ondition 0 -ondition N

4 - 12

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

8. M. (.

-omplete the ta:le :y inserting an P where rules suggest certain actions. -hec4 the ta:le and remove any impossi:le situations, contradictions, and redundancies. 3hese will :e discussed in more detail later. -om:ine rules where it is apparent that an alternative does not ma4e a difference in the outcome; for e9ample: ; ; P ; H P can :e e9pressed as: -ondition & -ondition & Action & ; P

-ondition & -ondition " Action &

3he dash !-$ signifies that condition " can :e either ; or H and the action that will still :e ta4en. '. =earrange the conditions and actions !or even rules$ if this ma4es the decision ta:le more understanda:le.

-hec4ing over decision ta:les for completeness and accuracy is essential. 3wo common pro:lems that can occur are contradictions and redundancy. -ontradictions occur when rules suggest different actions :ut satisfy the same conditions. 3his could :e the fault of the analyst in constructing the ta:le, or in the information the analyst receives. -ontradictions often occur if dashes !-$ are incorrectly inserted into the ta:le. -ontradictions could also :e a result of discrepant information gathered from different systems users. Lncovering such a discrepancy can :e very useful to an analyst wor4ing to improve a decision situation. =edundancy occurs when identical sets of alternatives require the e9act same action. 3he analyst has to determine which is correct and resolve the contradictions or redundancy. E#ha#ce% Dec " (# Tab$e" Decision ta:les can :ecome very :urdensome :ecause they grow rapidly as the num:er of conditions and alternatives increase. A ta:le with only seven conditions with yes or no alternatives would have &"( columns. >ne of the ways to reduce the comple9ity of unwieldy decision ta:les is to use e9tended entries, use the else rule, or construct multiple ta:les. E4te#%e%0E#tr3 F(r. In e9tended-entry form, a narrative action approach is used instead of simply a ; or H in the case of a limited-entry form ta:le. Hotice in the ; or H ta:le :elow: taff )em:er Associate )em:er )aster tudent )em:er >ther )em:er )a9imum " :orrowed :oo4s )a9imum 0 :orrowed :oo4s Ho limit of :orrowed :oo4s ; H H H H ; H H P P H H ; H P H H H ; P

Figure 4.#: $imite%&entry Form Ta!"e that since the conditions are mutually e9clusive, they can :e written in e9tended-entry form as shown :elow. 3he num:er of columns and rows decreases while the understanda:ility increases. Instead of using four rows for the num:er of times a customer orders, only one row is needed.

4 - 13

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

3ype of mem:erships )a9imum :orrowed :oo4s

taff Ho Kimit

Associate 0

)aster "

>thers "

Figure 4.': ()ten%e%&entry Form Ta!"e In fact, only one action entry e9ists !as illustrated a:ove$. )any people favour this format for its e9plicit signalling of actions. ELSE0E#tr3 F(r. Another useful technique in :uilding decision ta:les is to use the else column. 3his technique is useful in helping to eliminate many repetitious rules requiring the same e9act action. It is also useful in preventing errors of omission. 2elow shows an e9ample. 3ype of mem:erships )a9imum :orrowed :oo4s taff Ho Kimit Associate 0 #K # "

Figure 4.*: ("se&entry Form Ta!"e M+$t p$e Tab$e" )ultiple ta:les are used to control the siFe of the ta:le. A structured approach to :uilding decision ta:les would avoid use of gotos !?umping to another ta:le$ and instead use the instruction perform. 5igure 0.( shows how transfer is made :etween ta:les using perform. 3he perform action would allow transfer to another ta:le and return to the original ta:le when finished with 3a:le A.

->HDI3I>H AHD A-3I>H 2oo4 is lost =eturned :oo4 is damaged 2oo4 is overdue tamp Q-ancelB on the date-due 7#=5>=) 3A2K# 2 -harge price of :oo4 Issue an official receipt:

&

"

N H ; ;

P P P

->HDI3I>H AHD A-3I>H >verdue less than ./ days >verdue more than ./ days taffAassociate mem:er 5ine &/ cents per day 5ine "/ cents per day 5ine R&/ =#3L=H

&

"

N ; H ;

Figure 4.+: ,u"tip"e Ta!"es D #nd of notes e9tractedAmodified from: ystems Analysis And Design !"nd #dition$, 6enneth #. 6endall & %ulie #. 6endall !&''"$.

4 - 14

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

4)2)/

Str+ct+re% E#&$ "h

)any functional operations of an organisation do not involve the consideration of multiple conditions and resulting outcomes li4e those a:ove !i.e. decision trees and decision ta:les$. Instead, they simply involve straightforward sequence of tas4s or the iteration of smaller operations. In such instances, a series of concise #nglish statements, using precise selected voca:ulary, can :e used to communicate the processing rules. 3his technique is 4nown as tructured #nglish. >ne of the values of structured #nglish is that ver:al statements are a natural medium of communication :etween users and programmers. Lsers are generally comforta:le with #nglish statements. At the same time, the format of structured #nglish is sufficiently precise so that it will not :e misinterpreted :y designers or programmers; an additional tool to overcome language am:iguity in stating conditions and actions. 3o maintain the userCs understanding, however, care must :e ta4en to avoid structured #nglish statements loo4 li4e pseudocode, or worse, li4e ->2>K code. tructured #nglish comprises three :asic constructs: sequence, selection, and iteration. 2efore reviewing the special characteristics of each construct, several general points can :e made that apply to all: tructured #nglish statements are :rief. Ad?ectives are not used.

tatements :egin with a strong, action-oriented ver: that specifies the action to :e ta4en on a given o:?ect. 3here is no restricted list of ver:s that must :e used, as there is in a computer language. tatements are formatted using multiple levels of indentation. #ach level of indentation corresponds with a processing :loc4 or group of statements that are processed together. equence J 3he sequence construct simply amounts to series of structured #nglish statements together, one after the other. 3he statements can :e simple commands or processing :loc4s arising from one or the other constructs. #ach statement in the sequence :egins on a new line without indentation. An e9ample is shown :elow. =equest the :orrowerCs li:rary card. -hec4 the :orrower is the owner of the card. =eceive the :oo4s from the :orrower. -hec4 the :oo4s are non-reference materials. tamp due dates on the :oo4s. =eturn the li:rary card and the stamped :oo4s to the :orrower. Figure 4.-: .equence /onstruct in .tructure% (ng"is0 election J 3he selection construct has two possi:le forms. 3hey are illustrated in figure 0.&/. 3he I5-3+#H-#K #-#HDI5 form is pro:a:ly easier for the user to understand when there are only two options possi:le for the selection. Hote the use of indentation and the separation of lines. <hen three or more options are possi:le for a selection, the -A #->3+#=<I #-#HD-A # construct usually communicates :etter than use of nested I5-3+#H-#K #-#HDI5 form. Again note the use of indentation. 3he two forms can also :e used together.

4 - 15

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

I5 the :oo4s are overdue 3+#H -ompute the overdue fine. -ollect the fine from the :orrower. Issue a receipt. =eturn the :oo4s to the shelves. #K # =eturn the :oo4s to the shelves. #HDI5 Identify the category of the :oo4s -A # !Artificial Intelligent category$ Ka:el the :oo4 inde9 with prefi9 CAIC -A # !Data:ase category$ Ka:el the :oo4 inde9 with prefi9 CD2C -A # !7rogramming category$ Ka:el the :oo4 inde9 with prefi9 C7*C >3+#=<I # Ka:el the :oo4 inde9 with prefi9 CPPC #HD-A # Figure 4.11: .e"ection /onstruct in .tructure% (ng"is0 Iteration J 3he iteration construct has three possi:le forms. 3hey are used when there is a sequence of tas4s that need to :e repeated a num:er of times as a group. 3he group of statements to :e repeated is indented directly :elow the conditional statement !as shown in figure 0.&&$. 3he conditional statement specifies the num:er of times the iteration is to occur. 5>= each purchased :oo4 -hec4 the title matches with the invoice statements. 2rowse through the :oo4 to ensure no torn pages. I5 the :oo4 is torn 3+#H =e?ect the :oo4. #HDI5 #HD5>= D> <+IK# there are unpac4ed :oo4s -hec4 the :oo4 is not torn. =eturn the :oo4 to appropriate :oo4 shelve. #HDD> =#7#A3 -reate an overdue reminder letter for the mem:er. )ail the letter to the reminder. LH3IK no more overdue cases. Figure 4.11: 2teration /onstruct in .tructure% (ng"is0

4 - 16

CHAPTER 4: TOOLS FOR DETERMINING SYSTEMS REQUIREMENTS

Re! e1 Q+e"t (#"

&. ". .. 0. N. 8. M. (. '. &/. &&. Descri:e the activities involved in determining systems requirements. In the course of investigating systems requirements, what are some common systems characteristics a systems analyst ought to e9amine@ 2riefly descri:e five fact-finding techniques. As a system analyst, illustrate the type of circumstances you would adopt each various factfinding technique. %ustify your selection. Descri:e prototyping with an appropriate diagram. -ompare prototyping with classical structured analysis approach. Kist three advantages of prototyping approach. tate three disadvantages of prototyping approach. 7rototyping is sometimes 4nown as a Iquic4 and dirtyI method. #9plain the term Iquic4 and dirtyI. Hame three popular tools that can help to document a systems specification. 2riefly descri:e each of these. Lnder what type of pro:lem definition will the following specification tool :e most appropriate: a. :. c. &". Decision tree Decision ta:le tructured #nglish

Identify the differences :etween the following various types of decision ta:les: a. :. c. d. Kimited-entry form #9tended-entry form #lse-entry form )ultiple ta:les

F+rther Rea% #&"

ystems Analysis And Design !"nd #dition$, 6enneth #. 6endall & %ulie #. 6endall !&''"$, 7rentice-+all. 3he ystems Analysis Interview, 2rian %ames !&'('$, H-- 2lac4well.

4 - 17