daily pastebin goal


a guest Oct 22nd, 2012 1,924 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  2. After an overview of the systems analysis phase, this
  3. chapter describes requirements modeling techniques
  4. and team-based methods that systems analysts use
  5. to visualize and document new systems. The chapter
  6. then discusses system requirements and factfinding
  7. techniques, which include interviewing,
  8. documentation review, observation, surveys and
  9. questionnaires, sampling, and research.
  10. Chapter 4 includes a Video Learning Session that
  11. shows you how to use a functional decomposition
  12. diagram (FDD) to model business functions and
  13. processes.
  14. Introduction
  15. Phase 2 Systems Analysis
  16. 141
  17. CHAPTER INTRODUCTION CASE: Mountain View College Bookstore
  18. Background: Wendy Lee, manager of college services at Mountain View College, wants a new
  19. information system that will improve efficiency and customer service at the three college
  20. bookstores.
  21. In this part of the case, Tina Allen (systems analyst) and David Conroe (student intern)
  22. are talking about requirements modeling tasks and concepts.
  23. Participants: Tina and David
  24. Location: Tina’s office, Monday morning, October 3, 2011
  25. Project status: The project has advanced to the systems analysis phase. Now, Tina and David will work on
  26. modeling, fact-finding, and the documentation they need to build a requirements model for
  27. the proposed bookstore information system.
  28. Discussion topics: Modeling, team-based development strategies, fact-finding techniques, and documentation
  29. Tina: Before I tell you about the project,
  30. look at this Dilbert cartoon. You’ll
  31. like it!
  32. David: It’s funny, but scary too. Hope it
  33. doesn’t apply to us!
  34. Tina: Me too. That’s why we have to
  35. do a good job of requirements
  36. modeling.
  37. David: So, what do we do next?
  38. Tina: We need to create a model of the
  39. new system. We call this a requirements
  40. model, because it will
  41. include all the outputs, inputs, processes,
  42. and controls for the new
  43. system. The model will consist of
  44. various diagrams, charts, and documentation.
  45. David: How will we use the model when
  46. we’re done?
  47. Tina: We’ll study it carefully and review it frequently with system users.
  48. David: Who are the users?
  49. Tina: Users might include bookstore staff, students, faculty members, and the college business office. External users
  50. might include textbook publishers and suppliers of bookstore merchandise. The main thing is to work with
  51. users every step of the way. We’ll perform fact-finding, and we’ll document everything carefully. Here’s a task
  52. list to get us started:
  53. DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.
  54. FIGURE 4-1 Typical requirements modeling task list.
  57. The overall objective of the systems analysis
  58. phase is to understand the proposed project,
  59. ensure that it will support business requirements,
  60. and build a solid foundation for system
  61. development. In this phase, you use
  62. models and other documentation tools to
  63. visualize and describe the proposed system.
  64. Systems Analysis Activities
  65. The systems analysis phase includes the four
  66. main activities shown in Figure 4-2: requirements
  67. modeling, data and process modeling,
  68. object modeling, and consideration of development
  69. strategies.
  70. Although the waterfall model shows
  71. sequential SDLC phases, it is not uncommon
  72. for several phases (or certain tasks within a
  73. phase) to interact during the development process,
  74. just as they would in an adaptive model.
  75. For example, this occurs whenever new facts
  76. are learned or system requirements change
  77. during the modeling process. Figure 4-2 shows
  78. typical interaction among the three modeling
  79. tasks: requirements modeling, data and process
  80. modeling, and object modeling.
  81. REQUIREMENTS MODELING This chapter describes requirements modeling, which
  82. involves fact-finding to describe the current system and identification of the requirements
  83. for the new system, such as outputs, inputs, processes, performance, and security.
  84. Outputs refer to electronic or printed information produced by the system. Inputs refer
  85. to necessary data that enters the system, either manually or in an automated manner.
  86. Processes refer to the logical rules that are applied to transform the data into meaningful
  87. information. Performance refers to system characteristics such as speed, volume,
  88. capacity, availability, and reliability. Security refers to hardware, software, and procedural
  89. controls that safeguard and protect the system and its data from internal or
  90. external threats.
  91. DATA AND PROCESS MODELING In Chapter 5, Data and Process Modeling, you will
  92. continue the modeling process by learning how to represent graphically system data and
  93. processes using traditional structured analysis techniques. As you learned in Chapter 1,
  94. structured analysis identifies the data flowing into a process, the business rules that transform
  95. the data, and the resulting output data flow.
  96. OBJECT MODELING Chapter 6 discusses object modeling, which is another popular
  97. modeling technique. While structured analysis treats processes and data as separate
  98. components, object-oriented analysis (O-O) combines data and the processes
  99. that act on the data into things called objects. These objects represent actual
  100. people, things, transactions, and events that affect the system. During the system
  101. FIGURE 4-2 The systems analysis phase consists of requirements modeling,
  102. data and process modeling, object modeling, and consideration of development
  103. strategies. Notice that the systems analysis tasks are interactive, even though
  104. the waterfall model generally depicts sequential development.
  105. Data and
  106. Process
  107. Modeling
  108. Requirements
  109. Modeling
  110. Development
  111. Strategies
  112. Object
  113. Modeling
  114. Systems Analysis Phase Tasks
  115. VIDEO
  118. To learn more about
  119. data flow diagrams,
  120. visit the
  121. Management
  122. Information Systems
  123. CourseMate Web
  124. site at www.
  125. cengagebrain.
  126. com and navigate to
  127. the Video
  128. Learning Sessions
  129. for this book. These
  130. sessions can help
  131. you understand key
  132. concepts, practice
  133. your skills, and
  134. check your work.
  135. Joint Application Development
  136. Phase 2 Systems Analysis
  137. 143
  138. development process, analysts often use both modeling methods to gain as much
  139. information as possible.
  140. DEVELOPMENT STRATEGIES In Chapter 7, Development Strategies, you will consider
  141. various development options and prepare for the transition to the systems design phase
  142. of the SDLC. You will learn about software trends, acquisition and development alternatives,
  143. outsourcing, and formally documenting requirements for the new system.
  144. The deliverable, or end product, of the systems analysis phase is a system requirements
  145. document, which is an overall design for the new system. In addition, each activity within
  146. the systems analysis phase has an end product and one or more milestones. As you learned
  147. in Chapter 3, project managers use various tools and techniques to coordinate people,
  148. tasks, timetables, and budgets.
  149. Systems Analysis Skills
  150. You will need strong analytical and interpersonal skills to build an accurate model of the
  151. new system. Analytical skills enable you to identify a problem, evaluate the key elements,
  152. and develop a useful solution. Interpersonal skills are especially valuable to a systems
  153. analyst who must work with people at all organizational levels, balance conflicting needs
  154. of users, and communicate effectively.
  155. Because information systems affect people throughout the company, you should consider
  156. team-oriented strategies as you begin the systems analysis phase.
  157. Team-Based Techniques: JAD, RAD, and Agile Methods
  158. The IT department’s goal is to deliver the best possible information system, at the lowest
  159. possible cost, in the shortest possible time. To achieve the best results, system developers
  160. view users as partners in the development process. Greater user involvement usually
  161. results in better communication, faster development times, and more satisfied users.
  162. The traditional model for systems development was an IT department that used
  163. structured analysis and consulted users only when their input or approval was needed.
  164. Although the IT staff still has a central role, and structured analysis remains a popular
  165. method of systems development, most IT managers invite system users to participate
  166. actively in various development tasks.
  167. As you learned in Chapter 1, team-based approaches have been around for some time.
  168. A popular example is joint application development (JAD), which is a user-oriented technique
  169. for fact-finding and requirements modeling. Because it is not linked to a specific
  170. development methodology, systems developers use JAD whenever group input and interaction
  171. are desired.
  172. Another popular user-oriented method is rapid application development (RAD).
  173. RAD resembles a condensed version of the entire SDLC, with users involved every step
  174. of the way. While JAD typically focuses only on fact-finding and requirements determination,
  175. RAD provides a fast-track approach to a full spectrum of system development
  176. tasks, including planning, design, construction, and implementation.
  177. Finally, as you learned in Chapter 1, agile methods represent a recent trend that
  178. stresses intense interaction between system developers and users. JAD, RAD, and agile
  179. methods are discussed in the following sections.
  181. Joint application development (JAD) is a popular fact-finding technique that brings
  182. users into the development process as active participants.
  183. To learn more about
  184. interpersonal skills,
  185. visit the Management
  186. Information Systems
  187. CourseMate Web
  188. site at www.
  189. cengagebrain.
  190. com, navigate to On
  191. the Web Links for
  192. this chapter, and
  193. locate the
  194. Interpersonal
  195. Skills link.
  196. User Involvement
  197. Users have a vital stake in an information system, and they should participate fully in
  198. the development process. Until recent years, the IT department usually had sole responsibility
  199. for systems development, and users had a relatively passive role. During the
  200. development process, the IT staff would collect information from users, define system
  201. requirements, and construct the new system. At various stages of the process, the IT staff
  202. might ask users to review the design, offer comments, and submit changes.
  203. Today, users typically have a much more active role in systems development. IT professionals
  204. now recognize that successful systems must be user-oriented, and users need
  205. to be involved, formally or informally, at every stage of system development.
  206. One popular strategy for user involvement is a JAD team approach, which involves a
  207. task force of users, managers, and IT professionals that works together to gather information,
  208. discuss business needs, and define the new system requirements.
  209. JAD Participants and Roles
  210. A JAD team usually meets over a period of days or weeks in a special conference room
  211. or at an off-site location. Either way, JAD participants should be insulated from the distraction
  212. of day-to-day operations. The objective is to analyze the existing system, obtain
  213. user input and expectations, and document user requirements for the new system.
  214. The JAD group usually has a project leader, who needs strong interpersonal and
  215. organizational skills, and one or more members who document and record the results
  216. and decisions. Figure 4-3 describes typical JAD participants and their roles. IT staff
  217. members often serve as JAD project leaders, but that is not always the case. Systems
  218. analysts on the JAD team participate in discussions, ask questions, take notes, and provide
  219. support to the team. If CASE tools are available, analysts can develop models and
  220. enter documentation from the JAD session directly into the CASE tool.
  221. A typical JAD session agenda is shown in Figure 4-4. The JAD process involves
  222. intensive effort by all team members. Because of the wide range of input and constant
  223. interaction among the participants, many companies believe that a JAD group produces
  224. the best possible definition of the new system.
  225. To learn more about
  226. JAD, visit the
  227. Management
  228. Information Systems
  229. CourseMate Web
  230. site at www.
  231. cengagebrain.
  232. com, navigate to
  233. On the Web Links
  234. for this chapter, and
  235. locate the JAD link.
  236. FIGURE 4-3 Typical JAD participants and roles.
  238. JAD project leader Develops an agenda, acts as a facilitator, and leads the JAD session
  239. Top management Provides enterprise-level authorization and support for the project
  240. Managers Provide department-level support for the project and understanding
  241. of how the project must support business functions and requirements
  242. Users Provide operational-level input on current operations, desired changes,
  243. input and output requirements, user interface issues, and how the project
  244. will support day-to-day tasks
  245. Systems analysts and Provide technical assistance and resources for JAD team members on
  246. other IT staff members issues such as security, backup, hardware, software, and network
  247. capability
  248. Recorder Documents results of JAD sessions and works with systems analysts
  249. to build system models and develop CASE tool documentation
  250. Rapid Application Development
  251. Phase 2 Systems Analysis
  252. 145
  253. JAD Advantages and Disadvantages
  254. Compared with traditional methods, JAD is more expensive and can be cumbersome if
  255. the group is too large relative to the size of the project. Many companies find, however,
  256. that JAD allows key users to participate effectively in the requirements modeling process.
  257. When users participate in the systems development process, they are more likely to feel a
  258. sense of ownership in the results, and support for the new system. When properly used,
  259. JAD can result in a more accurate statement of system requirements, a better understanding
  260. of common goals, and a stronger commitment to the success of the new system.
  262. Rapid application development (RAD) is a team-based technique that speeds up
  263. information systems development and produces a functioning information system.
  264. Like JAD, RAD uses a group approach, but goes much further. While the end product
  265. of JAD is a requirements model, the end product of RAD is the new information system.
  266. RAD is a complete methodology, with a four-phase life cycle that parallels the
  267. traditional SDLC phases. Companies use RAD to reduce cost and development time,
  268. and increase the probability of success.
  269. RAD relies heavily on prototyping and user involvement. The RAD process allows
  270. users to examine a working model as early as possible, determine if it meets their needs,
  271. and suggest necessary changes. Based on user input, the prototype is modified and the
  272. interactive process continues until the system is completely developed and users are satisfied.
  273. The project team uses CASE tools to build the prototypes and create a continuous
  274. stream of documentation.
  275. RAD Phases and Activities
  276. The RAD model consists of four phases: requirements planning, user design, construction,
  277. and cutover, as shown in Figure 4-5. Notice the continuous interaction between the
  278. user design and construction phases.
  279. To learn more about
  280. RAD, visit the
  281. Management
  282. Information Systems
  283. CourseMate Web
  284. site at www.
  285. cengagebrain.
  286. com, navigate to
  287. On the Web Links
  288. for this chapter, and
  289. locate the RAD link.
  290. REQUIREMENTS PLANNING The requirements planning phase combines elements of
  291. the systems planning and systems analysis phases of the SDLC. Users, managers, and IT
  292. staff members discuss and agree on business needs, project scope, constraints, and system
  293. requirements. The requirements planning phase ends when the team agrees on the
  294. key issues and obtains management authorization to continue.
  295. USER DESIGN During the user design phase, users interact with systems analysts and
  296. develop models and prototypes that represent all system processes, outputs, and inputs.
  297. The RAD group or subgroups typically use a combination of JAD techniques and
  298. CASE tools to translate user needs into working models. User design is a continuous,
  299. Requirements
  300. Planning
  301. User
  302. Design Construction
  303. Cutover
  304. Cutover Tasks
  305. • Data conversion
  306. • Full-scale testing
  307. • System changeover
  308. • User training
  309. Construction Tasks
  310. • Program and
  311. application
  312. development
  313. • Coding
  314. • Unit, integration,
  315. and system testing
  316. Requirements Planning
  317. Tasks
  318. • Users, managers, and IT
  319. staff agree upon business
  320. needs, project scope, and
  321. systems requirements
  322. • Obtain approval to
  323. continue
  324. User Design Tasks
  325. • Interact with users
  326. • Build models and
  327. prototypes
  328. • Conduct intensive
  329. JAD-type sessions
  330. FIGURE 4-5 The four phases of the RAD model are requirements planning, user design, construction,
  331. and cutover. Notice the continuous interaction between the user design and construction phases.
  332. Agile Methods
  333. Phase 2 Systems Analysis
  334. 147
  335. interactive process that allows users to understand, modify, and eventually approve a
  336. working model of the system that meets their needs.
  337. CONSTRUCTION The construction phase focuses on program and application development
  338. tasks similar to the SDLC. In RAD, however, users continue to participate and
  339. still can suggest changes or improvements as actual screens or reports are developed.
  340. CUTOVER The cutover phase resembles the final tasks in the SDLC implementation
  341. phase, including data conversion, testing, changeover to the new system, and user training.
  342. Compared with traditional methods, the entire process is compressed. As a result,
  343. the new system is built, delivered, and placed in operation much sooner.
  344. RAD Objectives
  345. The main objective of all RAD approaches is to cut development time and expense by
  346. involving users in every phase of systems development. Because it is a continuous
  347. process, RAD allows the development team to make necessary modifications quickly,
  348. as the design evolves. In times of tight corporate budgets, it is especially important to
  349. limit the cost of changes that typically occur in a long, drawn-out development
  350. schedule.
  351. In addition to user involvement, a successful RAD team must have IT resources, skills,
  352. and management support. Because it is a dynamic, user-driven process, RAD is especially
  353. valuable when a company needs an information system to support a new business function.
  354. By obtaining user input from the beginning, RAD also helps a development team design a
  355. system that requires a highly interactive or complex user interface.
  356. RAD Advantages and Disadvantages
  357. RAD has advantages and disadvantages compared with traditional structured analysis
  358. methods. The primary advantage is that systems can be developed more quickly with significant
  359. cost savings. A disadvantage is that RAD stresses the mechanics of the system itself
  360. and does not emphasize the company’s strategic business needs. The risk is that a system
  361. might work well in the short term, but the corporate and long-term objectives for the system
  362. might not be met. Another potential disadvantage is that the accelerated time cycle
  363. might allow less time to develop quality, consistency, and design standards. RAD can be an
  364. attractive alternative, however, if an organization understands the possible risks.
  366. In Chapter 1, you learned that agile methods attempt to develop a system incrementally,
  367. by building a series of prototypes and constantly adjusting them to user requirements.
  368. As the agile process continues, developers revise, extend, and merge earlier versions into
  369. the final product. An agile approach emphasizes continuous feedback, and each incremental
  370. step is affected by what was learned in the prior steps.
  371. As agile methods become more popular, a large community of agile-related software
  372. and services has evolved. For example, Visual Paradigm offers Agilian, which includes a
  373. set of agile modeling tools, as shown in Figure 4-6 on the next page. The Agilian modeling
  374. toolset includes support for many modeling tools, such as the Unified Modeling
  375. Language, entity-relationship diagrams, data flow diagrams, and business process
  376. modeling, among others.
  377. Some agile developers prefer not to use CASE tools at all, and rely instead on whiteboard
  378. displays and arrangements of movable sticky notes. This approach, they believe,
  379. reinforces the agile strategy: simple, rapid, flexible, and user-oriented.
  380. Scrum is another agile approach. The name is derived from the rugby term scrum
  381. (Figure 4-7), where team members prepare to lunge at each other to achieve their objectives.
  382. The systems development version of Scrum involves the same intense interaction,
  383. though more mental than physical. In a Scrum session, agile team members play specific
  384. roles, including colorful designations as pigs or chickens. These roles are based on the
  385. old joke about the pig and chicken who discuss a restaurant where ham and eggs would
  386. be served. However, the pig declines, because that role would require a total commitment,
  387. while for the chicken, it would only be a contribution.
  388. In the agile world, the pigs include the product owner, the facilitator, and the development
  389. team; while the chickens include users, other stakeholders, and managers. Scrum
  390. sessions have specific guidelines that emphasize time blocks, interaction, and team-based
  391. activities that result in deliverable software.
  392. To learn more
  393. about agile methods,
  394. visit the
  395. Management
  396. Information Systems
  397. CourseMate Web
  398. site at www.
  399. cengagebrain.
  400. com, navigate to
  401. On the Web
  402. Links for this chapter,
  403. and locate the
  404. Agile Methods link.
  405. FIGURE 4-6 Visual Paradigm’s Agilian includes many types of agile modeling tools.
  406. Modeling Tools and Techniques
  407. Phase 2 Systems Analysis
  408. 149
  409. Agile Method Advantages and Disadvantages
  410. Agile, or adaptive, methods are very flexible and efficient in dealing with change. They
  411. are popular because they stress team interaction and reflect a set of community-based
  412. values. Also, frequent deliverables constantly validate the project and reduce risk.
  413. However, some potential problems exist. For example, team members need a high
  414. level of technical and interpersonal skills. Also, a lack of structure and documentation
  415. can introduce risk factors. Finally, the overall project may be subject to significant
  416. change in scope as user requirements continue to evolve during the project.
  417. FIGURE 4-7 In a rugby scrum, team members prepare to lunge at each other to achieve their objectives.
  419. North Hills College has decided to implement a new registration system that will allow
  420. students to register online, as well as in person. As IT manager, you decide to set up a JAD
  421. session to help define the requirements for the new system. The North Hills organization
  422. is fairly typical, with administrative staff that includes a registrar, a student support and services
  423. team, a business office, an IT group, and a number of academic departments. Using
  424. this information, you start work on a plan to carry out the JAD session. Who would you
  425. invite to the session, and why? What would be your agenda for the session, and what
  426. would take place at each stage of the session?
  428. Models help users, managers, and IT professionals understand the design of a system.
  429. Modeling involves graphical methods and nontechnical language that represent the system
  430. at various stages of development. During requirements modeling, you can use various tools
  431. to describe business processes, requirements, and user interaction with the system.
  432. In Chapter 1, you learned about CASE tools that offer powerful modeling features.
  433. CASE tool modeling is discussed in detail in Part B of the Systems Analyst’s Toolkit.
  434. Systems analysts use modeling and fact-finding interactively — first they build factfinding
  435. results into models, then they study the models to determine whether additional
  436. fact-finding is needed. To help them understand system requirements, analysts use functional
  437. decomposition diagrams, business process models, data flow diagrams, and
  438. Unified Modeling Language diagrams. Any of these diagrams can be created
  439. with CASE tools or standalone drawing tools if desired.
  440. Functional Decomposition Diagrams
  441. A functional decomposition
  442. diagram (FDD) is a topdown
  443. representation of a
  444. function or process. Using
  445. an FDD, an analyst can
  446. show business functions
  447. and break them down into
  448. lower-level functions and
  449. processes. Creating an FDD
  450. is similar to drawing an
  451. organization chart — you
  452. start at the top and work
  453. your way down. Figure 4-8
  454. shows an FDD of a library
  455. system drawn with the
  456. Visible Analyst CASE tool.
  457. FDDs can be used at several
  458. stages of systems development.
  459. During
  460. requirements modeling,
  461. analysts use FDDs to model
  462. business functions and show
  463. how they are organized into
  464. lower-level processes. Those processes translate into program modules during application
  465. development.
  466. Business Process Modeling
  467. As you learned in Chapter 1, a business process model (BPM) describes one or more business
  468. processes, such as handling an airline reservation, filling a product order, or updating
  469. a customer account. During requirements modeling, analysts often create models that use
  470. a standard language called business process modeling notation (BPMN). BPMN includes
  471. various shapes and symbols to represent events, processes, and workflows.
  472. FIGURE 4-8 FDD showing five top-level functions. The Library
  473. Operations function includes two additional levels that show processes
  474. and subprocesses.
  477. Video Learning Sessions can help you understand key concepts, practice your skills, and check your
  478. work. To access the sessions, visit the Management Information Systems CourseMate Web site at
  479. www.cengagebrain.com and navigate to the Video Learning Sessions for this book. This
  480. session is about functional decomposition diagrams (FDDs). You’ll learn about FDDs and why they
  481. are important, how to use FDDs to model business functions and processes, and how to use CASE
  482. tools to create FDDs.
  483. ms, ed
  485. The CASE tools in
  486. Part B of the
  487. Systems Analyst’s
  488. Toolkit can help you
  489. document business
  490. functions and processes,
  491. develop
  492. graphical models,
  493. and provide an overall
  494. framework for
  495. information system
  496. development. To
  497. learn more about
  498. these tools, turn to
  499. Part B of the
  500. four-part Toolkit that
  501. follows Chapter 12.
  502. Modeling Tools and Techniques
  503. Phase 2 Systems Analysis
  504. 151
  505. When you create a business process model
  506. using a CASE tool such as Visible Analyst, your
  507. diagram automatically becomes part of the overall
  508. model. In the example shown in Figure 4-9,
  509. using BPMN terminology, the overall diagram is
  510. called a pool, and the designated customer areas
  511. are called swim lanes. Integrating BPM into the
  512. CASE development process leads to faster
  513. results, fewer errors, and reduced cost. Part B of
  514. the Systems Analyst’s Toolkit describes business
  515. process modeling in more detail.
  516. Data Flow Diagrams
  517. Working from a functional decomposition
  518. diagram, analysts can create data flow diagrams
  519. (DFDs) to show how the system stores, processes,
  520. and transforms data. The DFD in
  521. Figure 4-10 describes adding and removing
  522. books, which is a function shown in the Library
  523. Management diagram in Figure 4-8. Notice that
  524. the two shapes in the DFD represent processes,
  525. each with various inputs and outputs. Additional levels
  526. of information and detail are depicted in other, related
  527. DFDs. Data and process modeling is described in detail
  528. in Chapter 5.
  529. Unified Modeling Language
  530. The Unified Modeling Language (UML) is a widely used
  531. method of visualizing and documenting software systems
  532. design. UML uses object-oriented design concepts, but it is
  533. independent of any specific programming language and
  534. can be used to describe business processes and requirements
  535. generally.
  536. UML provides various graphical tools, such as use case
  537. diagrams and sequence diagrams. During requirements
  538. modeling, a systems analyst can utilize the UML to represent
  539. the information system from a user’s viewpoint. Use
  540. case diagrams, sequence diagrams, and other UML concepts
  541. are discussed in more detail in Chapter 6, along with
  542. other object-oriented analysis concepts. A brief description
  543. of each technique follows.
  544. USE CASE DIAGRAMS During requirements modeling, systems analysts and users
  545. work together to document requirements and model system functions. A use case
  546. diagram visually represents the interaction between users and the information
  547. system. In a use case diagram, the user becomes an actor, with a specific role that
  548. describes how he or she interacts with the system. Systems analysts can draw use
  549. case diagrams freehand or use CASE tools that integrate the use cases into the
  550. overall system design.
  551. Figure 4-11 shows a simple use case diagram for a sales system where the actor is a
  552. customer and the use case involves a credit card validation that is performed by the
  553. system. Because use cases depict the system through the eyes of a user, common business
  554. FIGURE 4-9 Using the Visible Analyst CASE tool, an analyst can create
  555. a business process diagram. The overall diagram is called a pool, and the
  556. two separate customer areas are called swim lanes.
  557. FIGURE 4-10 A library system DFD shows how books
  558. are added and removed.
  559. To learn more about
  560. the Unified Modeling
  561. Language, visit the
  562. Management
  563. Information Systems
  564. CourseMate Web
  565. site at www.
  566. cengagebrain.com,
  567. navigate to On the
  568. Web Links for this
  569. chapter, and locate
  570. The Unified Modeling
  571. Language link.
  572. FIGURE 4-11 Use case diagram of a sales system,
  573. where the actor is a customer and the use case involves
  574. a credit card validation.
  575. FIGURE 4-13 Use case diagram of a student records system.
  576. FIGURE 4-12 A table documents the credit card validation use case shown in Figure 4-11.
  577. Name of Use Case: Credit card validation process
  578. Actor: Customer
  579. Description: Describes the credit card validation process
  580. Successful Completion: 1. Customer clicks the input selector and
  581. enters credit card number and expiration date
  582. 2. System verifies card
  583. 3. System sends authorization message
  584. Alternative: 1. Customer clicks the input selector and
  585. enters credit card number and expiration date
  586. 2. System rejects card
  587. 3. System sends rejection message
  588. Precondition: Customer has selected at least one item and
  589. has proceeded to checkout area
  590. Postcondition: Credit card information has been validated
  591. Customer can continue with order
  592. Assumptions: None
  593. language can be used to describe the transactions.
  594. For example, Figure 4-12 shows a table
  595. that documents the credit card validation use
  596. case, and Figure 4-13 shows a student records
  597. system, with several use cases and actors.
  598. SEQUENCE DIAGRAMS A sequence diagram
  599. shows the timing of interactions between
  600. objects as they occur. A systems analyst might
  601. use a sequence diagram to show all possible
  602. outcomes, or focus on a single scenario.
  603. Figure 4-14 shows a simple sequence diagram
  604. of a successful credit card validation.
  605. The interaction proceeds from top to bottom
  606. along a vertical timeline, while the horizontal
  607. arrows represent messages from one object
  608. to another.
  609. System Requirements Checklist
  610. Phase 2 Systems Analysis
  611. 153
  613. During requirements modeling, systems developers must identify and describe all system
  614. requirements. A system requirement is a characteristic or feature that must be included
  615. in an information system to satisfy business requirements and be acceptable to users.
  616. System requirements serve as benchmarks to measure the overall acceptability of the finished
  617. system.
  618. System requirements fall into five general categories: outputs, inputs, processes, performance,
  619. and controls. Typical examples of system requirements for each category are
  620. listed below.
  621. Output Examples
  622. ✓ The Web site must report online volume statistics every four hours, and hourly
  623. during peak periods.
  624. ✓ The inventory system must produce a daily report showing the part number,
  625. description, quantity on hand, quantity allocated, quantity available, and unit
  626. cost of all sorted by part number.
  627. ✓ The contact management system must generate a daily reminder list for all sales reps.
  628. ✓ The purchasing system must provide suppliers with up-to-date specifications.
  629. ✓ The sales tracking system must produce a daily fast-moving-item report, listing all
  630. products that exceed the forecasted sales volume grouped by style, color, size, and
  631. reorder status.
  632. ✓ The customer analysis system must produce a quarterly report that identifies
  633. changes in ordering patterns or trends with statistical comparisons to the previous
  634. four quarters.
  635. Input Examples
  636. ✓ Manufacturing employees must swipe their ID cards into online data collection
  637. terminals that record labor costs and calculate production efficiency.
  638. ✓ The department head must enter overtime hours on a separate screen.
  639. ✓ Student grades must be entered on machine-scannable forms prepared by the
  640. instructor.
  641. ✓ Each input form must include date, time, product code, customer number, and
  642. quantity.
  643. ✓ Data entry screens must be uniform, except for background color, which can be
  644. changed by the user.
  645. ✓ A data entry person at the medical group must input patient services into the
  646. billing system.
  647. Process Examples
  648. ✓ The student records system must calculate the GPA at the end of each semester.
  649. ✓ As the final step in year-end processing, the payroll system must update employee
  650. salaries, bonuses, and benefits and produce tax data required by the IRS.
  651. ✓ The warehouse distribution system must analyze daily orders and create a routing
  652. pattern for delivery trucks that maximizes efficiency and reduces unnecessary
  653. mileage.
  654. ✓ The human resources system must interface properly with the existing payroll
  655. system.
  656. ✓ The video rental system must not execute new rental transactions for customers
  657. who have overdue videos.
  658. ✓ The prescription system must automatically generate an insurance claim form.
  659. Performance Examples
  660. ✓ The system must support 25 users online simultaneously.
  661. ✓ Response time must not exceed four seconds.
  662. ✓ The system must be operational seven days a week, 365 days a year.
  663. ✓ The accounts receivable system must prepare customer statements by the third
  664. business day of the following month.
  665. ✓ The student records system must produce class lists within five hours after the
  666. end of registration.
  667. ✓ The online inventory control system must flag all low-stock items within one
  668. hour after the quantity falls below a predetermined minimum.
  669. Control Examples
  670. ✓ The system must provide logon security at the operating system level and at the
  671. application level.
  672. ✓ An employee record must be added, changed, or deleted only by a member of the
  673. human resources department.
  674. ✓ The system must maintain separate levels of security for users and the system
  675. administrator.
  676. Future Growth, Costs, and Benefits
  677. Phase 2 Systems Analysis
  678. 155
  679. ✓ All transactions must have audit trails.
  680. ✓ The manager of the sales department must approve orders that exceed a customer’s
  681. credit limit.
  682. ✓ The system must create an error log file that includes the error type, description,
  683. and time.
  685. In addition to the system requirements, systems analysts must consider scalability, which
  686. determines how a system will handle future growth and demands, and the total cost of
  687. ownership, which includes all future operational and support costs.
  688. Scalability
  689. Scalability refers to a system’s ability to handle increased business volume and transactions
  690. in the future. Because it will have a longer useful life, a scalable system offers a better
  691. return on the initial investment.
  692. To evaluate scalability, you need information about projected future volume for all
  693. outputs, inputs, and processes. For example, for a Web-based order processing system,
  694. you would need to know the maximum projected number of concurrent users, the periods
  695. of peak online activity, the number and types of data items required for each transaction,
  696. and the method of accessing and updating customer files.
  697. Even to print customer statements, you need to know the number of active accounts
  698. and have a forecast for one, two, or five years, because that information affects future hardware
  699. decisions. In addition, with realistic volume projections, you can provide reliable cost
  700. estimates for related expenses, such as postage and online charges.
  701. Similarly, to ensure that a Web-based hotel reservation system is sufficiently scalable,
  702. you would need to project activity levels for several years of operation. For example,
  703. you might forecast the frequency of online queries about room availability and estimate
  704. the time required for each query and the average response time. With that information,
  705. you could estimate server transaction volume and network requirements.
  706. Transaction volume has a significant impact on operating costs. When volume exceeds
  707. a system’s limitations, maintenance costs increase sharply. Volume can change dramatically
  708. if a company expands or enters a new line of business. For example, a new Internetbased
  709. marketing effort might require an additional server and 24-hour technical support.
  710. Data storage also is an important scalability issue. You need to determine how
  711. much data storage is required currently and predict future needs based on system
  712. activity and growth. Those requirements affect hardware, software, and network
  713. bandwidth needed to maintain system performance. You also must consider data
  714. retention requirements and determine whether data can be deleted or archived on a
  715. specific timetable.
  716. Total Cost of Ownership
  717. In addition to direct costs, systems developers must identify and document indirect
  718. expenses that contribute to the total cost of ownership (TCO). TCO is especially important
  719. if the development team is assessing several alternatives. After considering the indirect
  720. costs, which are not always apparent, a system that seems inexpensive initially
  721. might actually turn out to be the most costly choice. One problem is that cost estimates
  722. tend to understate indirect costs such as user support and downtime productivity losses.
  723. Even if accurate figures are unavailable, systems analysts should try to identify indirect
  724. costs and include them in TCO estimates.
  726. The financial analysis
  727. tools in Part C of
  728. the Systems Analyst’s
  729. Toolkit can help you
  730. analyze project
  731. costs, benefits, and
  732. economic feasibility.
  733. To learn more about
  734. these tools, turn to
  735. Part C of the fourpart
  736. Toolkit that follows
  737. Chapter 12.
  738. Microsoft has developed a method for measuring total costs and benefits, called
  739. Rapid Economic Justification (REJ), which is described in Figure 4-15. According to
  740. Microsoft, REJ is a framework to help IT professionals analyze and optimize IT investments.
  741. Notice that the primary emphasis is on business improvement, rather than operational
  742. efficiency. As the Web site points out, the strategic role of IT investments should
  743. be included, even when the specific benefits are difficult to quantify.
  745. Now that you understand the categories of system requirements, scalability, and TCO,
  746. the next step is to begin collecting information. Whether you are working on your own
  747. or as a member of a JAD team, during requirements modeling you will use various factfinding
  748. techniques, including interviews, document review, observation, surveys and
  749. questionnaires, sampling, and research.
  750. Fact-Finding Overview
  751. Although software can help you to gather and analyze facts, no program actually
  752. performs fact-finding for you. First, you must identify the information you need.
  753. Typically, you begin by asking a series of questions, such as these:
  754. • What business functions are supported by the current system?
  755. • What strategic objectives and business requirements must be supported by the
  756. new system?
  757. • What are the benefits and TCO of the proposed system?
  758. • What transactions will the system process?
  759. • What information do users and managers need from the system?
  760. To learn more
  761. about REJ, visit the
  762. Management
  763. Information Systems
  764. CourseMate Web
  765. site at www.
  766. cengagebrain.
  767. com, navigate to
  768. On the Web
  769. Links for this
  770. chapter, and locate
  771. the REJ link.
  772. FIGURE 4-15 Microsoft developed Rapid Economic Justification (REJ) as a
  773. framework to help IT professionals analyze and optimize IT investments.
  774. Fact-Finding
  775. Phase 2 Systems Analysis
  776. 157
  777. • Must the new system interface with legacy systems?
  778. • What procedures could be eliminated by business process reengineering?
  779. • What security issues exist?
  780. • What risks are acceptable?
  781. • What budget and timetable constraints will affect system development?
  782. To obtain answers to these questions, you develop a fact-finding plan, which can
  783. involve another series of questions (who, what, where, when, and how), or use a more
  784. structured approach such as the Zachman Framework, which is explained in a following
  785. section. Either way, you will develop a strategy, carry out fact-finding techniques, document
  786. the results, and prepare a system requirements document, which is presented to
  787. management.
  788. Who, What, Where, When, How, and Why?
  789. Fact-finding involves answers to five familiar questions: who, what, where, when, and
  790. how. For each of those questions, you also must ask another very important question:
  791. why. Some examples of these questions are:
  792. 1. Who? Who performs each of the procedures within the system? Why? Are the
  793. correct people performing the activity? Could other people perform the tasks
  794. more effectively?
  795. 2. What? What is being done? What procedures are being followed? Why is that
  796. process necessary? Often, procedures are followed for many years and no one
  797. knows why. You should question why a procedure is being followed at all.
  798. 3. Where? Where are operations being performed? Why? Where could they be performed?
  799. Could they be performed more efficiently elsewhere?
  800. 4. When? When is a procedure performed? Why is it being performed at this time?
  801. Is this the best time?
  802. 5. How? How is a procedure performed? Why is it performed in that manner?
  803. Could it be performed better, more efficiently, or less expensively in some other
  804. manner?
  805. There is a difference between asking what is being done and what could or should be
  806. done. The systems analyst first must understand the current situation. Only then can he
  807. or she tackle the question of what should be done. Figure 4-16 lists the basic questions
  808. and when they should be asked. Notice that the first two columns relate to the current
  809. system, but the third column focuses on the proposed system.
  810. FIGURE 4-16 Sample questions during requirements modeling as the focus shifts from the current system to
  811. the proposed system.
  812. The Zachman Framework
  813. In the 1980s, John Zachman observed how industries such as architecture and
  814. construction handled complex projects, and he suggested that the same ideas could be
  815. applied to information systems development. His concept, the Zachman Framework for
  816. Enterprise Architecture, is a model that asks the traditional fact-finding questions in a
  817. systems development context, as shown in Figure 4-17. The Zachman Framework is a
  818. popular approach, and the Visible Analyst CASE tool now includes a Zachman
  819. Framework interface that allows users to view a systems project from different perspectives
  820. and levels of detail. The Zachman Framework helps managers and users understand
  821. the model and ensures that overall business goals translate into successful IT projects.
  822. FIGURE 4-17 Visible Analyst uses the Zachman Framework for Enterprise Architecture. The Zachman concept
  823. presents traditional fact-finding questions in a systems development context.
  824. To learn more
  825. about the Zachman
  826. Framework, visit the
  827. Management
  828. Information Systems
  829. CourseMate Web
  830. site at www.
  831. cengagebrain.
  832. com, navigate to
  833. On the Web
  834. Links for this
  835. chapter, and locate
  836. The Zachman
  837. Framework link.
  838. Interviews
  839. Phase 2 Systems Analysis
  840. 159
  842. Interviewing is an important fact-finding tool during the systems analysis phase. An
  843. interview is a planned meeting during which you obtain information from another person.
  844. You must have the skills needed to plan, conduct, document, and evaluate interviews
  845. successfully.
  846. After you identify the information you need, as described earlier in the chapter, you
  847. can begin the interviewing process, which consists of seven steps for each interview:
  848. 1. Determine the people to interview.
  849. 2. Establish objectives for the interview.
  850. 3. Develop interview questions.
  851. 4. Prepare for the interview.
  852. 5. Conduct the interview.
  853. 6. Document the interview.
  854. 7. Evaluate the interview.
  855. Step 1: Determine the People to Interview
  856. To get an accurate picture, you must select the right people to interview and ask them
  857. the right questions. During the preliminary investigation, you talked mainly to middle
  858. managers or department heads. Now, during the systems analysis phase, you might need
  859. to interview people from all levels of the organization.
  860. Although you can select your interview candidates from
  861. the formal organization charts that you reviewed earlier, you
  862. also must consider any informal structures that exist in the
  863. organization. Informal structures usually are based on interpersonal
  864. relationships and can develop from previous work
  865. assignments, physical proximity, unofficial procedures, or personal
  866. relationships such as the informal gathering shown in
  867. Figure 4-18. In an informal structure, some people have more
  868. influence or knowledge than appears on an organization
  869. chart. Your knowledge of the company’s formal and informal
  870. structures helps you determine the people to interview during
  871. the systems analysis phase.
  872. Should you interview several people at the same time?
  873. Group interviews can save time and provide an opportunity to
  874. observe interaction among the participants. Group interviews
  875. also can present problems. One person might dominate the
  876. conversation, even when questions are addressed specifically
  877. to others. Organization level also can present a problem, as
  878. the presence of senior managers in an interview might prevent
  879. lower-level employees from expressing themselves candidly.
  880. Step 2: Establish Objectives for the Interview
  881. After deciding on the people to interview, you must establish
  882. objectives for the session. First, you should determine the general
  883. areas to be discussed, and then list the facts you want to
  884. gather. You also should try to solicit ideas, suggestions, and
  885. opinions during the interview.
  886. FIGURE 4-18 When setting up interviews, an analyst
  887. should look outside a formal organization chart to
  888. identify people who might provide valuable information
  889. The objectives of an interview depend on the role of the person being interviewed.
  890. Upper-level managers can provide the big picture and help you to understand the system
  891. as a whole. Specific details about operations and business processes are best learned
  892. from people who actually work with the system on a daily basis.
  893. In the early stages of systems analysis, interviews usually are general. As the factfinding
  894. process continues, however, the interviews focus more on specific topics.
  895. Interview objectives also vary at different stages of the investigation. By setting specific
  896. objectives, you create a framework that helps you decide what questions to ask and how
  897. to phrase the questions.
  898. Step 3: Develop Interview Questions
  899. Creating a standard list of interview questions helps to keep you on track and avoid
  900. unnecessary tangents. Also, if you interview several people who perform the same job, a
  901. standard question list allows you to compare their answers. Although you have a list of
  902. specific questions, you might decide to depart from it because an answer to one question
  903. leads to another topic that you want to pursue. That question or topic then should be
  904. included in a revised set of questions used to conduct future interviews. If the question
  905. proves to be extremely important, you may need to return to a previous interviewee to
  906. query him or her on the topic.
  907. The interview should consist of several different kinds of questions: open-ended,
  908. closed-ended, or questions with a range of responses. When you phrase your questions,
  909. you should avoid leading questions that suggest or favor a particular reply. For example,
  910. rather than asking, “What advantages do you see in the proposed system?” you might
  911. ask, “Do you see any advantages in the proposed system?”
  912. OPEN-ENDED QUESTIONS Open-ended questions encourage spontaneous and
  913. unstructured responses. Such questions are useful when you want to understand a
  914. larger process or draw out the interviewee’s opinions, attitudes, or suggestions. Here
  915. are some examples of open-ended questions: What are users saying about the new
  916. system? How is this task performed? Why do you perform the task that way? How
  917. are the checks reconciled? What added features would you like to have in the new
  918. billing system? Also, you can use an open-ended question to probe further by asking:
  919. Is there anything else you can tell me about this topic?
  920. CLOSED-ENDED QUESTIONS Closed-ended questions limit or restrict the response.
  921. You use closed-ended questions when you want information that is more specific or
  922. when you need to verify facts. Examples of closed-ended questions include the following:
  923. How many personal computers do you have in this department? Do you review
  924. the reports before they are sent out? How many hours of training does a clerk receive?
  925. Is the calculation procedure described in the manual? How many customers ordered
  926. products from the Web site last month?
  927. RANGE-OF-RESPONSE QUESTIONS Range-of-response questions are closed-ended
  928. questions that ask the person to evaluate something by providing limited answers
  929. to specific responses or on a numeric scale. This method makes it easier to tabulate
  930. the answers and interpret the results. Range-of-response questions might include
  931. these: On a scale of 1 to 10, with 1 the lowest and 10 the highest, how effective
  932. was your training? How would you rate the severity of the problem: low, medium,
  933. or high? Is the system shutdown something that occurs never, sometimes, often,
  934. usually, or always?
  935. Interviews
  936. Phase 2 Systems Analysis
  937. 161
  938. Step 4: Prepare for the Interview
  939. After setting the objectives and developing the questions, you must prepare for the
  940. interview. Careful preparation is essential because an interview is an important meeting
  941. and not just a casual chat. When you schedule the interview, suggest a specific day and
  942. time and let the interviewee know how long you expect the meeting to last. It is also a
  943. good idea to send an e-mail or place a reminder call the day before the interview.
  944. Remember that the interview is an interruption of the other person’s routine, so you
  945. should limit the interview to no more than one hour. If business pressures force a postponement
  946. of the meeting, you should schedule another appointment as soon as it is
  947. convenient. Remember to keep
  948. department managers informed of
  949. your meetings with their staff
  950. members. Sending a message to
  951. each department manager listing
  952. your planned appointments is a
  953. good way to keep them informed.
  954. Figure 4-19 is an example of such
  955. a message.
  956. You should send a list of topics
  957. to an interviewee several days before
  958. the meeting, especially when
  959. detailed information is needed, so
  960. the person can prepare for the interview
  961. and minimize the need for a
  962. follow-up meeting. Figure 4-20
  963. shows a sample message that lists
  964. specific questions and confirms the
  965. date, time, location, purpose, and
  966. anticipated duration of the
  967. interview.
  968. If you have questions about documents,
  969. ask the interviewee to have
  970. samples available at the meeting.
  971. Your advance memo should
  972. include a list of the documents you
  973. want to discuss, if you know what
  974. they are. Also, you can make a general
  975. request for documents, as the
  976. analyst did in her e-mail shown in
  977. Figure 4-20.
  978. Two schools of thought exist
  979. about the best location for an
  980. interview. Some analysts believe
  981. that interviews should take place
  982. in the interviewee’s office, whereas
  983. other analysts feel that a neutral
  984. location such as a conference
  985. room is better.
  986. Supporters of interviews in the
  987. interviewee’s office believe that is
  988. the best location because it makes
  989. the interviewee feel comfortable
  990. during the meeting. A second
  991. FIGURE 4-19 Sample message to a department head about interviews.
  992. FIGURE 4-20 Sample message to confirm an interview.
  993. argument in favor of the interviewee’s office is that the office is where he or she has the
  994. easiest access to supporting material that might be needed during the discussion. If you
  995. provide a complete list of topics in advance, however, the interviewee can bring the necessary
  996. items to a conference room or other location.
  997. Supporters of neutral locations stress the importance of keeping interruptions to a
  998. minimum so both people can concentrate fully. In addition, an interview that is free of
  999. interruptions takes less time. If the meeting does take place in the interviewee’s office,
  1000. you should suggest tactfully that all calls be held until the conclusion of the interview.
  1001. Step 5: Conduct the Interview
  1002. After determining the people to interview, setting your objectives, and preparing the
  1003. questions, you should develop a specific plan for the meeting. When conducting an
  1004. interview, you should begin by introducing yourself, describing the project, and explaining
  1005. your interview objectives.
  1006. During the interview, ask questions in the order in which you prepared them, and
  1007. give the interviewee sufficient time to provide thoughtful answers. Establishing a good
  1008. rapport with the interviewee is important, especially if this is your first meeting. If the
  1009. other person feels comfortable and at ease, you probably will receive more complete and
  1010. candid answers. Your primary responsibility during an interview is to listen carefully to
  1011. the answers. Analysts sometimes hear only what they expect to hear. You must concentrate
  1012. on what is said and notice any nonverbal communication that takes place. This
  1013. process is called engaged listening.
  1014. After asking a question, allow the person enough time to think about the question
  1015. and arrive at an answer. Studies have shown that the maximum pause during a conversation
  1016. is usually three to five seconds. After that interval, one person will begin talking.
  1017. You will need to be patient and practice your skills in many actual interview situations
  1018. to be successful.
  1019. When you finish asking your questions, summarize the main points covered in the
  1020. interview and explain the next course of action. For example, mention that you will
  1021. send a follow-up memo or that the interviewee should get back to you with certain
  1022. information. When you conclude the interview, thank the person and encourage him or
  1023. her to contact you with any questions or additional comments. Also, when the interview
  1024. ends, it is a good idea to ask the interviewee whether he or she can suggest any additional
  1025. topics that should be discussed.
  1026. After an interview, you should summarize the session and seek a confirmation from
  1027. the other person. By stating your understanding of the discussion, the interviewee can
  1028. respond and correct you, if necessary. One approach is to rephrase the interviewee’s
  1029. answers. For example, you can say, “If I understand you correctly, you are saying that ...”
  1030. and then reiterate the information given by the interviewee.
  1031. Step 6: Document the Interview
  1032. Although taking notes during an interview has both advantages and disadvantages, the
  1033. accepted view is that note taking should be kept to a minimum. Although you should
  1034. write down a few notes to jog your memory after the interview, you should avoid writing
  1035. everything that is said. Too much writing distracts the other person and makes it
  1036. harder to establish a good rapport.
  1037. After conducting the interview, you must record the information quickly. You
  1038. should set aside time right after the meeting to record the facts and evaluate the information.
  1039. For that reason, try not to schedule back-to-back interviews. Studies have
  1040. shown that 50 percent of a conversation is forgotten within 30 minutes. You, therefore,
  1041. should use your notes to record the facts immediately so you will not forget
  1042. Interviews
  1043. Phase 2 Systems Analysis
  1044. 163
  1046. Deep River College is a two-year school in Southern California. Twice a year, the fundraising
  1047. office at Deep River mails requests for donations to the alumni. The staff uses a word
  1048. processing program and a personal information database to create personalized letters. Data
  1049. on past contributions and other alumni information, however, is stored manually. The dean,
  1050. Alexandra Ali, recently submitted a systems request asking the college’s IT department to
  1051. develop a computerized alumni information system. The school does not have a formal systems
  1052. review committee, and each department has an individual budget for information services.
  1053. Eddie Bateman, a systems analyst, performed a preliminary investigation and he concluded that
  1054. the system met all the feasibility tests. After reading his report, Alexandra asked him to proceed
  1055. with the systems analysis phase. Eddie has scheduled an interview with her, and he has asked you
  1056. to help him prepare for the meeting. Specifically, he wants you to list all the topics he should
  1057. cover during the interview. Eddie also wants you to prepare a list of specific questions that he
  1058. should ask. Be sure to include open-ended, closed-ended, and range-of-response questions.
  1059. them. You can summarize the facts by preparing a narrative describing what took
  1060. place or by recording the answers you received next to each question on your prepared
  1061. question list.
  1062. Tape recorders are effective tools for an interview; however, many people feel uncomfortable
  1063. when recorders are present. Before using a recorder, you should discuss its use
  1064. with the interviewee. Assure the interviewee that you will erase the tape after you transcribe
  1065. your notes and that you will stop and rewind the tape anytime during the interview
  1066. at his or her request. If you ask sensitive questions or the interviewee wants to
  1067. answer a question without being recorded, explain that you will turn off the tape for a
  1068. period of time during the interview.
  1069. Even with a tape recorder in use, you should listen carefully to the interviewee’s
  1070. responses so you can ask good follow-up questions. Otherwise, you might have to
  1071. return for a second visit to ask the questions you missed the first time. Also, remember
  1072. that each recorded interview takes twice the amount of time, because you must listen to
  1073. or view the recorded meeting again after conducting the interview itself.
  1074. After the interview, send a memo to the interviewee expressing your appreciation for
  1075. his or her time and cooperation. In the memo, you should note the date, time, location,
  1076. purpose of the interview, and the main points you discussed so the interviewee has a
  1077. written summary and can offer additions or corrections.
  1078. Step 7: Evaluate the Interview
  1079. In addition to recording the facts obtained in an interview, try to identify any possible
  1080. biases. For example, an interviewee who tries to protect his or her own area or function
  1081. might give incomplete answers or refrain from volunteering information. Or, an interviewee
  1082. with strong opinions about the current or future system might distort the facts.
  1083. Some interviewees might answer your questions in an attempt to be helpful even though
  1084. they do not have the necessary experience to provide accurate information.
  1085. Unsuccessful Interviews
  1086. No matter how well you prepare for interviews, some are not successful. One of the
  1087. main reasons could be that you and the interviewee did not get along well. Such a situation
  1088. can be caused by several factors. For example, a misunderstanding or personality conflict
  1089. could affect the interview negatively, or the interviewee might be afraid that the new system
  1090. will eliminate or change his or her job.
  1091. In other cases, the interviewee might give only short or incomplete responses to your
  1092. open-ended questions. If so, you should switch to closed-ended questions or questions
  1093. with a range of responses, or try rephrasing your open-ended questions into those types
  1094. of questions. If that still does not help, you should find a tactful way to conclude the
  1095. meeting.
  1096. Continuing an unproductive interview is difficult. The interviewee could be more
  1097. cooperative later, or you might find the information you seek elsewhere. If failure to
  1098. obtain specific information will jeopardize the success of the project, inform your supervisor,
  1099. who can help you decide what action to take. Your supervisor might contact the
  1100. interviewee’s supervisor, ask another systems analyst to interview the person, or find
  1101. some other way to get the needed information.
  1103. In addition to interviewing, systems analysts use other fact-finding techniques, including
  1104. document review, observation, questionnaires and surveys, sampling, and research. Such
  1105. techniques are used before interviewing begins to obtain a good overview and to help
  1106. develop better interview questions.
  1107. Document Review
  1108. Document review can help you understand how the current system is supposed to work.
  1109. Remember that system documentation sometimes is out of date. Forms can change or be
  1110. discontinued, and documented procedures often are modified or eliminated. You should
  1111. obtain copies of actual forms and operating documents currently in use. You also should
  1112. review blank copies of forms, as well as samples of actual completed forms. You usually
  1113. can obtain document samples during interviews with the people who perform that procedure.
  1114. If the system uses a software package, you should review the documentation for
  1115. that software.
  1116. Observation
  1117. The observation of current operating procedures is another fact-finding technique.
  1118. Seeing the system in action gives you additional perspective and a better understanding
  1119. of system procedures. Personal observation also allows you to verify statements made in
  1120. interviews and determine whether procedures really operate as they are described.
  1121. Other Fact-Finding Techniques
  1122. Phase 2 Systems Analysis
  1123. 165
  1124. Through observation, you might discover that neither the system documentation nor the
  1125. interview statements are accurate.
  1126. Personal observation also can provide important advantages as the development process
  1127. continues. For example, recommendations often are better accepted when they are
  1128. based on personal observation of actual operations. Observation also can provide the
  1129. knowledge needed to test or install future changes and can help build relationships with
  1130. the users who will work with the new system.
  1131. Plan your observations in advance by preparing a checklist of specific tasks you want
  1132. to observe and questions you want to ask. Consider the following issues when you prepare
  1133. your list:
  1134. 1. Ask sufficient questions to ensure that you have a complete understanding of the
  1135. present system operation. A primary goal is to identify the methods of handling
  1136. situations that are not covered by standard operating procedures. For example,
  1137. what happens in a payroll system if an employee loses a time card? What is the
  1138. procedure if an employee starts a shift 10 minutes late but then works 20 minutes
  1139. overtime? Often, the rules for exceptions such as these are not written or formalized;
  1140. therefore, you must try to document any procedures for handling exceptions.
  1141. 2. Observe all the steps in a transaction and note the documents, inputs, outputs, and
  1142. processes involved.
  1143. 3. Examine each form, record, and report.
  1144. Determine the purpose each item of information
  1145. serves.
  1146. 4. Consider each user who works with the system
  1147. and the following questions: What information
  1148. does that person receive from other people?
  1149. What information does this person generate?
  1150. How is the information communicated? How
  1151. often do interruptions occur? How much downtime
  1152. occurs? How much support does the user
  1153. require, and who provides it?
  1154. 5. Talk to the people who receive current reports
  1155. to see whether the reports are complete, timely,
  1156. accurate, and in a useful form. Ask whether
  1157. information can be eliminated or improved and
  1158. whether people would like to receive additional
  1159. information.
  1160. As you observe people at work, as shown in
  1161. Figure 4-21, consider a factor called the Hawthorne
  1162. Effect. The name comes from a well-known study
  1163. performed in the Hawthorne plant of the Western
  1164. Electric Company in the 1920s. The purpose of the
  1165. study was to determine how various changes in the
  1166. work environment would affect employee productivity.
  1167. The surprising result was that productivity
  1168. improved during observation whether the conditions
  1169. were made better or worse. Researchers concluded
  1170. that productivity seemed to improve whenever the
  1171. workers knew they were being observed.
  1172. Although some recent studies have raised questions
  1173. about the original findings, you should be aware that
  1174. observation can and does have an effect on normal
  1175. FIGURE 4-21 The Hawthorne study suggested that worker
  1176. productivity improves during observation. Always consider
  1177. the Hawthorne Effect when observing the operation of an
  1178. existing system.
  1179. operations. With this in mind, always give advance notice to the supervisor in that area.
  1180. In some situations, it might be helpful to explain the purpose of your visit to the people
  1181. being observed.
  1182. Questionnaires and Surveys
  1183. In projects where it is desirable to obtain input from a large number of people,
  1184. a questionnaire can be a valuable tool. A questionnaire, also called a survey, is a document
  1185. containing a number of standard questions that can be sent to many individuals.
  1186. Questionnaires can be used to obtain information about a wide range of topics,
  1187. including workloads, reports received, volumes of transactions handled, job duties,
  1188. difficulties, and opinions of how the job could be performed better or more efficiently.
  1189. Figure 4-22 shows a sample questionnaire that includes several different question and
  1190. response formats.
  1191. FIGURE 4-22 Sample questionnaire. Does it follow the suggested guidelines?
  1192. Other Fact-Finding Techniques
  1193. Phase 2 Systems Analysis
  1194. 167
  1195. A typical questionnaire starts with a heading, which includes a title, a brief statement of
  1196. purpose, the name and telephone number of the contact person, the deadline date for completion,
  1197. and how and where to return the form. The heading usually is followed by general
  1198. instructions that provide clear guidance on how to answer the questions. Headings also are
  1199. used to introduce each main section or portion of the survey and include instructions when
  1200. the type of question or response changes. A long questionnaire might end with a conclusion
  1201. that thanks the participants and reminds them how to return the form.
  1202. What about the issue of anonymity? Should people be asked to sign the questionnaire,
  1203. or is it better to allow anonymous responses? The answer depends on two questions.
  1204. First, does an analyst really need to know who the respondents are in order to
  1205. match or correlate information? For example, it might be important to know what percentage
  1206. of users need a certain software feature, but specific usernames might not be relevant.
  1207. Second, does the questionnaire include any sensitive or controversial topics?
  1208. Many people do not want to be identified when answering a question such as “How
  1209. well has your supervisor explained the system to you?” In such cases, anonymous
  1210. responses might provide better information.
  1211. When designing a questionnaire, the most important rule of all is to make sure that your
  1212. questions collect the right data in a form that you can use to further your fact-finding. Here
  1213. are some additional ideas to keep in mind when designing your questionnaire:
  1214. • Keep the questionnaire brief and user-friendly.
  1215. • Provide clear instructions that will answer all anticipated questions.
  1216. • Arrange the questions in a logical order, going from simple to more complex topics.
  1217. • Phrase questions to avoid misunderstandings; use simple terms and wording.
  1218. • Try not to lead the response or use questions that give clues to expected answers.
  1219. • Limit the use of open-ended questions that are difficult to tabulate.
  1220. • Limit the use of questions that can raise concerns about job security or other
  1221. negative issues.
  1222. • Include a section at the end of the questionnaire for general comments.
  1223. • Test the questionnaire whenever possible on a small test group before finalizing it
  1224. and distributing to a large group.
  1225. A questionnaire can be a traditional paper
  1226. form, or you can create a fill-in form and collect
  1227. data on the Internet or a company intranet. For
  1228. example, you can use Microsoft Word, as
  1229. shown in Figure 4-23, to create form fields,
  1230. including text boxes, date pickers, and dropdown
  1231. lists where users can click selections.
  1232. Before you publish the form, you should protect
  1233. it so users can fill it in but cannot change the
  1234. layout or design. Forms also can be automated,
  1235. so if a user answers no to question three, he or
  1236. she goes directly to question eight, where the
  1237. form-filling resumes.
  1238. Sampling
  1239. When studying an information system, you
  1240. should collect examples of actual documents
  1241. using a process called sampling. The samples
  1242. might include records, reports, operational logs,
  1243. FIGURE 4-23 Using Microsoft Word, you can create a fill-in form
  1244. with text boxes, date pickers, and drop-down lists.
  1245. data entry documents, complaint summaries, work requests, and various types of forms.
  1246. Sampling techniques include systematic sampling, stratified sampling, and random sampling.
  1247. Suppose you have a list of 200 customers who complained about errors in their statements,
  1248. and you want to review a representative sample of 20 customers. A systematic
  1249. sample would select every tenth customer for review. If you want to ensure that the sample
  1250. is balanced geographically, however, you could use a stratified sample to select five
  1251. customers from each of four zip codes. Another example of stratified sampling is to select
  1252. a certain percentage of transactions from each zip code, rather than a fixed number.
  1253. Finally, a random sample selects any 20 customers.
  1254. The main objective of a sample is to ensure that it represents the overall population
  1255. accurately. If you are analyzing inventory transactions, for example, you should select a
  1256. sample of transactions that are typical of actual inventory operations and do not include
  1257. unusual or unrelated examples. For instance, if a company performs special processing
  1258. on the last business day of the month, that day is not a good time to sample typical daily
  1259. operations. To be useful, a sample must be large enough to provide a fair representation
  1260. of the overall data.
  1261. You also should consider sampling when using interviews or questionnaires. Rather
  1262. than interviewing everyone or sending a questionnaire to the entire group, you can use a
  1263. sample of participants. You must use sound sampling techniques to reflect the overall
  1264. population and obtain an accurate picture.
  1265. Research
  1266. Research is another important fact-finding technique. Your research can include the
  1267. Internet, IT magazines, and books to obtain background information, technical material,
  1268. and news about industry trends and developments. In addition, you can attend professional
  1269. meetings, seminars, and discussions with other IT professionals, which can be
  1270. very helpful in problem solving.
  1271. The Internet is an extremely valuable
  1272. resource. Part D of the Systems Analyst’s
  1273. Toolkit describes a variety of Internet
  1274. resource tools. Using the Internet, you also
  1275. can access information from federal and
  1276. state governments, as well as from publishers,
  1277. universities, and libraries around the
  1278. world. Online forums and newsgroups are
  1279. good resources for exchanging information
  1280. with other professionals, seeking answers
  1281. to questions, and monitoring discussions
  1282. that are of interest to you.
  1283. All major hardware and software vendors
  1284. maintain sites on the Web where you
  1285. can obtain information about products
  1286. and services offered by the company and
  1287. send e-mail with specific questions to company
  1288. representatives. In addition to contacting
  1289. specific firms, you can access Web
  1290. sites maintained by publishers and independent
  1291. firms that provide links to hundreds
  1292. of hardware and software vendors,
  1293. as shown in Figure 4-24. Such sites are
  1294. one-stop information centers where IT
  1295. professionals can find information, share
  1296. ideas, and keep posted on developments in
  1297. technology.
  1298. To learn more about
  1299. sampling, visit the
  1300. Management
  1301. Information Systems
  1302. CourseMate Web
  1303. site at www.
  1304. cengagebrain.
  1305. com, navigate to
  1306. On the Web Links
  1307. for this chapter, and
  1308. locate the Sampling
  1309. link.
  1310. FIGURE 4-24 InfoWorld’s Web site offers many resources for IT professionals.
  1311. Other Fact-Finding Techniques
  1312. Phase 2 Systems Analysis
  1313. 169
  1314. Research also can involve a visit to a physical location,
  1315. called a site visit, where the objective is to observe a system in
  1316. use at another location. If you are studying your firm’s
  1317. human resources information system, for example, you might
  1318. want to see how another company’s system works. Site visits
  1319. also are important when considering the purchase of a software
  1320. package. If the software vendor suggests possible sites
  1321. to visit, be aware that such sites might constitute a biased
  1322. sample. A single site visit seldom gives you true pictures, so
  1323. you should try to visit more than one installation.
  1324. Before a site visit such as the one shown in Figure 4-25,
  1325. prepare just as you would for an interview. Contact the
  1326. appropriate manager and explain the purpose of your visit.
  1327. Decide what questions you will ask and what processes you
  1328. will observe. During your visit, observe how the system works
  1329. and note any problems or limitations. You also will want to
  1330. learn about the support provided by the vendor, the quality of
  1331. the system documentation, and so on.
  1332. Interviews versus Questionnaires
  1333. When you seek input from a large group, a questionnaire is a very useful tool. On the
  1334. other hand, if you require detailed information from only a few people, then you probably
  1335. should interview each person individually. Is it better to interview or use a questionnaire?
  1336. Each situation is different, and you must consider the type of information, time
  1337. constraints, and expense factors.
  1338. The interview is more familiar and personal than a questionnaire. People who are
  1339. unwilling to put critical or controversial comments in writing might talk more freely in person.
  1340. Moreover, during a face-to-face interview, you can react immediately to anything the
  1341. interviewee says. If surprising or confusing statements are made, you can pursue the topic
  1342. with additional questions. In addition, during a personal interview, you can watch for clues
  1343. to help you determine if responses are knowledgeable and unbiased. Participation in interviews
  1344. also can affect user attitudes, because people who are asked for their opinions often
  1345. view the project more favorably.
  1346. Interviewing, however, is a costly and time-consuming process. In addition to the
  1347. meeting itself, both people must prepare, and the interviewer has to do follow-up work.
  1348. When a number of interviews are planned, the total cost can be quite substantial. The
  1349. personal interview usually is the most expensive fact-finding technique.
  1350. In contrast, a questionnaire gives many people the opportunity to provide input and
  1351. suggestions. Questionnaire recipients can answer the questions at their convenience and do
  1352. not have to set aside a block of time for an interview. If the questionnaire allows anonymous
  1353. responses, people might offer more candid responses than they would in an interview.
  1354. Preparing a good questionnaire, however, like a good interview, requires skill and
  1355. time. If a question is misinterpreted, you cannot clarify the meaning as you can in a
  1356. face-to-face interview. Furthermore, unless questionnaires are designed well, recipients
  1357. might view them as intrusive, time-consuming, and impersonal. As an analyst, you
  1358. should select the technique that will work best in a particular situation.
  1359. Another popular method of obtaining input is called brainstorming, which refers to a
  1360. small group discussion of a specific problem, opportunity, or issue. This technique
  1361. encourages new ideas, allows team participation, and enables participants to build on
  1362. each other’s inputs and thoughts. Brainstorming can be structured or unstructured. In
  1363. structured brainstorming, each participant speaks when it is his or her turn, or passes. In
  1364. unstructured brainstorming, anyone can speak at any time. At some point, the results
  1365. are recorded and made part of the fact-finding documentation process.
  1367. Ann Ellis is a systems analyst at CyberStuff, a large company that sells computer hardware and
  1368. software via telephone, mail order, and the Internet. CyberStuff processes several thousand
  1369. transactions per week on a three-shift operation and employs 50 full-time and 125 part-time
  1370. employees. Lately, the billing department has experienced an increase in the number of customer
  1371. complaints about incorrect bills. During the preliminary investigation, Ann learned that
  1372. some CyberStuff representatives did not follow established order entry procedures. She feels
  1373. that with more information, she might find a pattern and identify a solution for the problem.
  1374. Ann is not sure how to proceed. She came to you, her supervisor, with two separate questions.
  1375. First, is a questionnaire the best approach, or would interviews be better? Second,
  1376. whether she uses interviews, a questionnaire, or both techniques, should she select the participants
  1377. at random, include an equal number of people from each shift, or use some other
  1378. approach? As Ann’s supervisor, what would you suggest, and why?
  1380. Keeping accurate records of interviews, facts, ideas, and observations is essential to successful
  1381. systems development. The ability to manage information is the mark of a successful
  1382. systems analyst and an important skill for all IT professionals.
  1383. The Need for Recording the Facts
  1384. As you gather information, the importance of a single item can be overlooked or complex
  1385. system details can be forgotten. The basic rule is to write it down. You should document
  1386. your work according to the following principles:
  1387. • Record information as soon as you obtain it.
  1388. • Use the simplest recording method possible.
  1389. • Record your findings in such a way that they can be understood by someone else.
  1390. • Organize your documentation so related material is located easily.
  1391. Often, systems analysts use special forms for describing a system, recording interviews,
  1392. and summarizing documents. One type of documentation is a narrative list with
  1393. simple statements about what is occurring, apparent problems, and suggestions for
  1394. improvement. Other forms of documentation that are described in Chapter 4 include
  1395. data flow diagrams, flowcharts, sample forms, and screen captures.
  1396. Software Tools
  1397. Many software programs are available to help you record and document information.
  1398. Some examples are described here.
  1399. CASE TOOLS You can use CASE tools at every stage of systems development. This
  1400. chapter contains several examples of CASE tools. Part B of the Systems Analyst’s
  1401. Toolkit describes other features and capabilities of CASE tools.
  1402. PRODUCTIVITY SOFTWARE Productivity software includes word processing,
  1403. spreadsheet, database management, presentation graphics, and collaboration software
  1404. programs. Although Microsoft Office is the best-known set of productivity software
  1405. programs, other vendors offer products in each of these categories.
  1406. Documentation
  1407. Phase 2 Systems Analysis
  1408. 171
  1409. Using word processing software such as Microsoft Word, Corel WordPerfect, or
  1410. OpenOffice.org Writer, you can create reports, summaries, tables, and forms. In addition
  1411. to standard document preparation, the program can help you organize a presentation
  1412. with templates, bookmarks, annotations, revision control, and an index. You can
  1413. consult the program’s Help system for more information about those and other features.
  1414. You also can create fill-in forms to conduct surveys and questionnaires, as described
  1415. earlier in this chapter.
  1416. Spreadsheet software, such as Microsoft Excel, Corel Quattro Pro, or OpenOffice.org
  1417. Calc, can help you track and manage numeric data or financial information. You also
  1418. can generate graphs and charts that display the data and show possible patterns, and you
  1419. can use the statistical functions in a spreadsheet to tabulate and analyze questionnaire
  1420. data. A graphical format often is used in quality control analysis because it highlights
  1421. problems and their possible causes, and it is effective when presenting results to management.
  1422. A common tool for showing the distribution of questionnaire or sampling results
  1423. is a vertical bar chart called a histogram. Most spreadsheet programs can create histograms
  1424. and other charts that can display data you have collected. Figure 4-26 displays a
  1425. typical histogram that might have resulted from the questionnaire shown in Figure 4-22
  1426. on page 166.
  1427. FIGURE 4-26 This histogram displays results from Question 2 in the questionnaire shown in Figure 4-22 on page 166.
  1428. Database management software allows you to document and organize fact-finding
  1429. results such as events, observations, and data samples. You can use a database program
  1430. such as Microsoft Access to manage the details of a complex project, create queries to
  1431. retrieve specific information, and generate custom reports.
  1432. Presentation graphics software, such as Microsoft PowerPoint, Apple Keynote, or
  1433. OpenOffice.org Impress, is a powerful tool for organizing and developing your formal
  1434. presentation. Presentation graphics programs enable you to create organization charts
  1435. that can be used in a preliminary investigation and later during requirements modeling.
  1436. These high-quality charts also can be included in written reports and management
  1437. presentations.
  1438. Collaboration software is the latest weapon in the struggle to boost productivity.
  1439. More than ever, people work in teams and use Web-based software such as Google
  1440. Docs and Microsoft Web Apps to access data and share files. Google and others are
  1441. betting that cloud computing will create a virtual workplace, where people will be able
  1442. to interact in real time, with all the benefits of a traditional face-to-face workplace, but
  1443. none of the limitations.
  1444. GRAPHIC MODELING SOFTWARE Microsoft Visio is a popular graphic modeling
  1445. tool that can produce a wide range of charts and diagrams. Visio includes a library of
  1446. templates, stencils, and shapes. An analyst can use Visio to create many types of visual
  1447. models, including business processes, flowcharts, network diagrams, organization
  1448. charts, and Web site maps, such as the one shown in Figure 4-27.
  1449. FIGURE 4-27 This Microsoft Visio screen shows shapes that can be used to create a Web site map.
  1450. Documentation
  1451. Phase 2 Systems Analysis
  1452. 173
  1453. PERSONAL INFORMATION MANAGERS A busy analyst needs to keep track of
  1454. meetings, interviews, appointments, and deadlines. A personal information manager
  1455. (PIM), such as Microsoft Outlook or IBM’s Lotus Organizer, can help manage those
  1456. tasks using a personal calendar and a to-do list, with priorities and the capability to
  1457. check off completed items.
  1458. In addition to desktop-based organizers, handheld computers are popular. Some handheld
  1459. computers, also called personal digital assistants (PDAs), accept handwritten input,
  1460. while others have small keyboards. These devices can handle calendars, schedules,
  1461. appointments, telephone lists, and calculations. A PDA can be standalone, Bluetoothcapable
  1462. to synchronize with a desktop, or fully wireless-enabled, such as the HP iPAQ
  1463. shown in Figure 4-28.
  1464. WIRELESS COMMUNICATION DEVICES Even in the dynamic world of IT, the recent
  1465. explosion in wireless technology is almost unprecedented. The latest wireless standard,
  1466. called 4G (fourth generation), is opening new frontiers in broadband Web access,
  1467. e-mail, social networking, file exchange, and streaming multimedia. Users enjoy new
  1468. hardware and software, easy synchronization with office networks, and innovative
  1469. services designed for a wired generation.
  1470. The rapid growth of wireless communication has resulted in a merger of various
  1471. technologies. Many people swear by all-in-one devices such as Research in Motion’s
  1472. BlackBerry or smart phones, such as the Apple iPhone. Others are devoted to products
  1473. that use Google’s Android operating system, which is a mobile device platform adopted
  1474. by many hardware vendors, including Motorola, Kyocera, and LG. Figure 4-29 on the
  1475. next page shows some examples of these products.
  1476. FIGURE 4-29 Three popular examples of current wireless technology.
  1477. Beyond hardware choices, users can select from literally thousands of portable
  1478. applications for business and personal use. No one can predict the future with certainty,
  1479. but it is apparent that portable wireless technology is having an enormous impact on
  1480. business practices, everyday communications, and social interaction.
  1481. Chapter Summary
  1482. Phase 2 Systems Analysis
  1483. 175
  1485. At the conclusion of requirements modeling, systems developers should have a clear
  1486. understanding of business processes and system requirements. The next step is to
  1487. construct a logical model of the system.
  1488. Data and process modeling, which is described in Chapter 5, uses a structured
  1489. analysis approach. Structured analysis is a popular, traditional technique that describes
  1490. the system in terms of data and the processes that act on that data.
  1491. An alternative to structured analysis modeling is object modeling, which is described
  1492. in Chapter 6. Object modeling is a methodology that combines data and processes into
  1493. things called objects that represent actual people, things, transactions, and events.
  1494. Systems analysts use object models to visualize and document real-world business processes
  1495. and operations.
  1496. IT professionals have differing views about systems development methodologies, and
  1497. no universally accepted approach exists. By studying both structured analysis and objectoriented
  1498. methods, you gain valuable knowledge, skills, and perspective. You then can use
  1499. that information to determine what method, or combination of methods, is best for the
  1500. different situations you will face in your career.
  1502. The systems analysis phase includes three activities: requirements modeling, data and
  1503. process modeling, and consideration of development strategies. The main objective is to
  1504. understand the proposed project, ensure that it will support business requirements, and
  1505. build a solid foundation for the systems design phase.
  1506. During requirements modeling, you identify the business-related requirements for the
  1507. new information system, including outputs, inputs, processes, performance, and controls.
  1508. You consider scalability to ensure that the system can support future growth and
  1509. expansion. You also estimate total cost of ownership (TCO) to identify all costs, including
  1510. indirect costs.
  1511. Popular team-based approaches include JAD, RAD, and agile methods. Joint application
  1512. development (JAD) is a popular, team-based approach to fact-finding and
  1513. requirements modeling. JAD involves an interactive group of users, managers, and IT
  1514. professionals who participate in requirements modeling and develop a greater commitment
  1515. to the project and to their common goals.
  1516. Rapid application development (RAD) is a team-based technique that speeds up
  1517. information systems development and produces a functioning information system.
  1518. RAD is a complete methodology, with a four-phase life cycle that parallels the traditional
  1519. SDLC phases.
  1520. Agile methods attempt to develop a system incrementally, by building a series of
  1521. prototypes and constantly adjusting them to user requirements.
  1522. Systems analysts use various tools and techniques to model system requirements.
  1523. Unified Modeling Language (UML) is a widely used method of visualizing and documenting
  1524. software design through the eyes of the business user. UML tools include use
  1525. case diagrams and sequence diagrams to represent actors, their roles, and the sequence
  1526. of transactions that occurs.
  1527. A functional decomposition diagram (FDD) is a model of business functions and
  1528. processes. A CASE tool can generate a set of data flow diagrams directly from a FDD.
  1529. The fact-finding process includes interviewing, document review, observation, questionnaires,
  1530. sampling, and research. Successful interviewing requires good planning and strong
  1531. interpersonal and communication skills. The systems analyst must decide on the people to
  1532. interview, set interview objectives, and prepare for, conduct, and analyze interviews. The
  1533. analyst also might find it helpful to use one or more software tools during fact-finding.
  1534. Systems analysts should carefully record and document factual information as it is
  1535. collected, and various software tools can help an analyst visualize and describe an information
  1536. system. The chapter concluded with a preview of logical modeling. Data and
  1537. process modeling is a structured analysis approach that views the system in terms of
  1538. data and the processes that act on that data. Object modeling is an approach that views
  1539. the system in terms of data and the processes that act on that data.
RAW Paste Data