IT353_Module 5.pptx.pdf

‫الجامعة السعودية اللكترونية‬ ‫الجامعة السعودية اللكترونية‬ ‫‪26/12/2021‬‬ College of Computing and Informatics System Analysis and Design  Module 5 Analysis: Requirements Determination  1. Performing Requirements Determination 2. Traditional Methods for Determi...

‫الجامعة السعودية اللكترونية‬ ‫الجامعة السعودية اللكترونية‬ ‫‪26/12/2021‬‬ College of Computing and Informatics System Analysis and Design  Module 5 Analysis: Requirements Determination  1. Performing Requirements Determination 2. Traditional Methods for Determining Requirements 3. Contemporary Methods for Determining System Requirements 4. Radical Methods for Determining System Requirements 5. Requirements Determination Using Agile Methodologies Contents  1. Describe diferent techniques for requirement determination 2. Explain the advantages of using observation, JAD, Prototyping for requirements determination Weekly 3. Explain how computing can provide support for requirements determination Learning Outcomes  Required Reading 1. Chapter 6: Requirements Determination , (Modern Systems Analysis and Design, 9th Edition by Joseph S. Valacich and Joey F. George) Recommended Reading 1. Chapter 4, 5 (Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering, Using UML, Patterns, and Java", 3rd ed., Prentice-Hall) This Presentatin is mainly dependent in the textbiik: Midern Systems Analysis and Design, 9th Editin by Jiseph S. Valacich and Jiey F. Geirge 1. Performing Requirements Determination Requirements Determination During requirements determinatin, yiu and ither analysts gather infirmatin in what the system shiuld di frim as many siurces as pissible: frim users if the current system; frim ibserving users; and frim repirts, firms, and pricedures. The Process of Determining Requirements Impertnence Yiu shiuld questin everything Impartality Yiur rile is ti fnd the best silutin ti a business priblem ir ippirtunity. Relaxing cinstraints Assume that anything is pissible and eliminate the infeasible. Attentin ti details Every fact must ft with every ither fact. Reframing Analysis is, in part, a creatve pricess Deliverables and Outcomes Frim interviews and ibservatins Interview transcripts, ibservatin nites, meetng minutes Frim existng written dicuments Missiin and strategy statements, business firms, pricedure manuals, jib descriptins, training manuals, system dicumentatin, fiwcharts Frim cimputerized siurces JAD sessiin results, CASE repisitiries, system prititype displays and repirts 2. Traditional Methods for Determining Requirements Traditional Methods for Determining Requirements Interviewing individuals Individually interview peiple infirmed abiut the iperatin and issues if the current system and future systems needs Interviewing griups Interview griups if peiple with diverse needs ti fnd synergies and cintrasts aming system requirements Observing wirkers Observe wirkers at selected tmes ti see hiw data are handled and what infirmatin peiple need ti di their jibs Studying business dicuments Study business dicuments ti disciver repirted issues, pilicies, rules, and directins as well as cincrete examples if the use if data and infirmatin in the irganizatin Interviewing and Listening Dialigue with user ir manager ti ibtain their requirements Twi firms: Open-ended: cinversatinal, questins with ni specifc answers in mind Clised-ended: structured, questins with limited range if pissible answers Guidelines for Efective Interviewing Plan the interview. Prepare interviewee: appiintment, priming questins. Prepare agenda, checklist, questins. Listen carefully and take nites (tape recird if permittedd. Review nites within 48 hiurs. Be neutral. Seek diverse views. Choosing Interview Questions Open-ended questins Questins in interviews that have ni prespecifed answers. “ What would you say is the best thing about the informaton system you currently use to do your job?” Clised-ended questins Questins in interviews that ask thise respinding ti chiise frim aming a set if specifed respinses. “ Which of the following would you say is the one best thing about the informaton system you currently use to do your job (pick only one)? a. Having easy access to all of the data you need b. The system’s response tme c. The ability to access the system from remote locatons” Typical interview guide Interview Guide is a dicument fir develiping, planning and cinductng an interview. Each questin in an interview guide can include bith verbal and nin- verbal infirmatin. Pros and Cons of Individual Interviews Interview ine persin at a tme Pris Easier ti schedule than griup interviews Cins Cintradictins and incinsistencies between interviewees Filliw-up discussiins are tme cinsuming Interviewing Groups Interview several key peiple tigether In the case if multple interviewers, ine analyst may ask questins while anither takes nites, ir diferent analysts might cincentrate in diferent kinds if infirmatin. Advantages Mire efectve use if tme Can hear agreements and disagreements at ince Oppirtunity fir synergies Disadvantages Mire difcult ti schedule than individual interviews Nominal Group Technique (NGT) Niminal Griup Technique (NGTd A facilitated pricess that suppirts idea generatin by griups. At the beginning if the pricess, griup members wirk aline ti generate ideas. The ideas are then piiled under the guidance if a trained facilitatir NGT Pricess Members cime tigether as a griup, but initally wirk separately. Each persin writes ideas. Facilitatir reads ideas iut liud, and they are written in blackbiard. Griup discusses the ideas. Ideas are priiritzed, cimbined, selected, reduced An NGT exercise ciuld be used ti cimplement the wirk dine in a typical griup interview ir as part if a Jiint Applicatin Design efirt, Directly Observing Users Peiple are nit always very reliable infirmants, even when they try ti be reliable and tell what they think is the truth Direct Observatin Watching users di their jibs Can privide mire accurate infirmatin than self-repirtng (like questinnaires and interviewsd Dicument Analysis? Review if existng business dicuments Can give a histirical and “firmal” view if system requirements These methids are nit titally unbiased ibservatin can cause peiple ti change their nirmal iperatng behaviir Analyzing Procedures and Other Documents Attempt ti fnd all written dicuments abiut the irganizatinal areas relevant ti the systems under redesign missiin statements, business plans, irganizatin charts, business pilicy manuals, jib descriptins, etc. What can be discivered: Priblems with existng system Oppirtunity ti meet new need Organizatinal directin Names if key individuals Values if irganizatin Special infirmatin pricessing circumstances Reasins fir current system design Rules fir pricessing data Useful Documents Fiur types if useful dicuments Written wirk pricedures Describes hiw a jib is perfirmed Includes data and infirmatin used and created in the pricess if perfirming the jib ir task Business firm Explicitly indicate data fiw in ir iut if a system Repirt Enables the analyst ti wirk backwards frim the repirt ti the data that generated it Descriptin if current infirmatin system  Example of a procedure Written wirk pricedure is a business dicument that firmally describes wirk pricesses, privides useful infirmatin regarding system functinality and ligic. Issues May invilve duplicatin if efirt May have missing pricedures May be iut if date May cintradict infirmatin ibtained thriugh interviews Formal and Informal Systems Firmal The ifcial way a system wirks as described in irganizatin’s dicumentatin Pricedure dicuments describe firmal system Infirmal The way a system actually wirks in practce Interviews and ibservatin reveal infirmal system Observation and Document Analysis Formal and Informal Systems Firmal The ifcial way a system wirks as described in irganizatin’s dicumentatin Pricedure dicuments describe firmal system Infirmal The way a system actually wirks in practce Interviews and ibservatin reveal infirmal system 3. Contemporary Methods for Determining System Requirements Contemporary Methods for Determining Requirements Jiint Applicatin Design (JADd Brings tigether key users, managers, and systems analysts Purpise: cillect system requirements simultaneiusly frim key peiple Cinducted if-site Griup Suppirt Systems Facilitate sharing if ideas and viicing if ipiniins abiut system requirements CASE tiils Used ti analyze existng systems Help disciver requirements ti meet changing business cinditins System prititypes Iteratve develipment pricess Rudimentary wirking versiin if system is built Refne understanding if system requirements in cincrete terms Joint Application Design (JAD) Jiint Applicatin Design (JADd A structured pricess in which users, managers, and analysts wirk tigether fir several days in a series if intensive meetngs ti specify ir review system requirements. Intensive griup-iriented requirements determinatin technique Team members meet in isilatin fir an extended periid if tme Highly ficused Resiurce intensive Started by IBM in 1970s  JAD room and Participants Session Leader: facilitates griup pricess Users: actve, speaking partcipants Managers: actve, speaking partcipants Sponsor: high-level champiin, limited partcipatin Systems Analysts: shiuld mistly listen Scribe: recird sessiin actvites IS Staf: shiuld mistly listen Taking Part in a JAD CASE Tiils During JAD Upper CASE tiils are used Enables analysts ti enter system midels directly inti CASE during the JAD sessiin Screen designs and pritityping can be dine during JAD and shiwn ti users Suppirtng JAD with GSS Griup suppirt systems (GSSd can be used ti enable mire partcipatin by griup members in JAD Members type their answers inti the cimputer All members if the griup see what ither members have been typing End Result Dicumentatin detailing existng system Features if pripised system Prototyping Pritityping An iteratve pricess if systems develipment in which requirements are cinverted ti a wirking system that is cintnually revised thriugh clise cillabiratin between an analyst and users Evolutionary and Throwaway Prototyping In evilutinary pritityping, yiu begin by mideling parts if the target system and, if the pritityping pricess is successful, yiu evilve the rest if the system frim thise parts. Unlike evilutinary pritityping, thriwaway pritityping dies nit preserve the prititype that has been develiped. Prototyping Mist useful when: User requests are nit clear Few users are invilved in the system Designs are cimplex and require cincrete firm Histiry if cimmunicatin priblems between analysts and users Tiils are readily available ti build prititype Drawbacks Tendency ti aviid firmal dicumentatin Difcult ti adapt ti mire general user audience Sharing data with ither systems is ifen nit cinsidered Systems Develipment Life Cycle (SDLCd checks are ifen bypassed 4. Radical Methods for Determining System Requirements Business process reengineering (BPR) The search fir, and implementatin if radical change in business pricesses ti achieve breakthriugh imprivements in priducts and services. Gials Reirganize cimplete fiw if data in majir sectins if an irganizatin Eliminate unnecessary steps Cimbine steps Becime mire respinsive ti future change Key business pricesses Set if actvites designed ti priduce specifc iutput fir a partcular custimer ir market Ficused in custimers and iutcime Same techniques are used as were used fir requirements determinatin Disruptive Technologies Disruptve techniligies Techniligies that enable breaking ling held business rules that inhibit irganizatins frim making radical business changes. 5. Requirements Determination Using Agile Methodologies Agile Methodologies for Requirements Determination Cintnual user invilvement Replace traditinal SDLC waterfall with iteratve analyze – design – cide – test cycle Agile usage-centered design Ficuses in user gials, riles, and tasks The Planning Game Based in eXtreme prigramming Expliratin, steering, cimmitment Agile Usage-Centered Design - Steps eXtreme Programming’s Planning Game  References: 1. Chapter 6: Requirements Determination, (Modern Systems Analysis and Design, 9th Edition by Joseph S. Valacich and Joey F. George) 2. Chapter 4, 5 (Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering, Using UML, Patterns, and Java", 3rd ed., Prentice-Hall) This Presentatin is mainly dependent in the textbiik: Midern Systems Analysis and Design, 9th Editin by Jiseph S. Valacich and Jiey F. Geirge Thank You