Popular in Course
Popular in Information technology
This 26 page Class Notes was uploaded by Augustine Cummings on Monday October 26, 2015. The Class Notes belongs to INFSCI2510 at University of Pittsburgh taught by Staff in Fall. Since its upload, it has received 39 views. For similar materials see /class/229372/infsci2510-university-of-pittsburgh in Information technology at University of Pittsburgh.
Reviews for INFORMATIONSYSTEMSANALYSIS
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 10/26/15
InfSci 2510 Information System Analysis and Design Lecture 8 10282002 Topics Review Information gathering o HyperCase exercise Review Use Cases amp Assignment 6 0 Requirements Document for Project InputOutput Design System Development Life Cycle Identi z problems or opportunities Determine the requirements Analyze the existing system Design a solution the intended system Develop the new system Test functional correctness and performance Implement deploy the system MaintenanceEvaluation fixesenhancements Information Gathering 0 Sampling documents people 0 Interviews 0 Questionnaires 0 Observations in the work place Information Gathering Sampling Documents Work ow Analysis collect documents and trace their life cycles for each kind Work ow Modeling simulation for static and dynamic analysis also for system implementation Information Gathering 0 Sampling People Interview Design for interview session JAD Joint Application Design Questionnaires Observations in the work place Requirements Gathering 0 One major point of gathering information for the project is to reach a set of requirements for the information system 0 The rst deliverable is therefore the Requirements Documents Requirements Document Overall Project Statement The purpose of this project is to The stake holders Identify people the client who finances the project the people involved from Whom you need information and the endusers community Goals speci c targets to reach Requirements Document Functional Requirements The system should do process retail sale while keeping inventory immediately uptodate with accurate sales analysis always available List them in a table table of functional requirements System Attributes For each of the system functions describe the quality characteristics required credit checking must respond within 10 seconds payment logged to accounts receivable within 24 hours Incorporate these into the table of functional requirements Functional Requirements List of System Functions Describe What the system should do in a table Function Categories State how important is that function Evident system should do this and obvious to users that the system must do this Hidden system should do this but not visible to users Hidden functions are often missed Optional fri11 nice to have and it is not costly Functional Requirements List the System Functions in a table Ref Function Description Category R11 Record the current sale the items purchased evident R12 Calculate current total sale including tax and evident coupons R13 Capture purchase item information from its bar evident code or use use manually entered UPC R1 4 Update inventory quantities when a sale is made hidden R15 Log every completed sale hidden R16 Cashier must log in with employee ID and evident password to use the system R17 Provide a persistent storage system hidden FURPS Requirements checklist Functional features capabilities security Usability human factors help documentation Reliability frequency of failure recoverability predictability Performance response time throughput accuracy availability resource usage Supportability adaptability maintainability con gurability FURPS Requirements checklist Implementation resource limitations languages and tools hardware Interface constraints imposed by interfacing with external systems Operations system management in its operational setting Packaging the means for deploying the system Legal licensing charges propagation System Attrlbutes The quality characteristics of the system ease of use fault tolerance response time interface metaphor in use retail cost maximum load of users afforded performance versus load platforms System Attributes The quality characteristics of the system as exhibited in the performance of functions incorporate into the table of functional requirements Ref Function Cat Attribute Notes Cat R19 Display description and evident response max 5 sec must price of item recorded time interface form based must metaphor colorful want R24 Log credit payments to hidden fault must log to must accounts receivable foerance accounts system for subsequent receivable 9553mm W Cred within 24 hours servrce response max 10 sec must time Topics Review Information gathering yperCase exercise Review Use Cases amp Assignment 6 0 Requirements Document for Project InputOutput Design Information Gathering Hypercase an exercise in information gathering designed by Kendall and Kendall team using WWW as a practice tool for system analyst httpwwwv a whall quot 39 39 L n quot llhtml n 39 htm Topics Review Information gathering HyperCase exercise Review Use Cases amp Assignment 6 0 Requirements Document for Project InputOutput Design Use Cases 0 A use case is a narrative documentation in text that describes the sequence of events of an actor an external agent using a system to complete a process 0 We may also use a collection of use cases to express the functional requirements of an information system Use Case describing a process Use case name the use case with a descriptive name Primary Actor name the role of the external party interacting with the system Purpose the intention of the use case Other stakeholders other parties who may have an interest here Pre conditions situations assumed to be true to start with Post conditions situations guaranteed to be true upon completion Type brief casual full References reference numbers of related requirements Brief form of the Use Case Use Case Example Cashier Machine Use case buy items with cash Primary Actor cashier Purpose to capture the sale of items purchased with cash Other stakeholders customer desires to make the purchase store owner capture sale and account for it Pre conditions cashier already logged on Post conditions cash collected and inventory updated Type brief References Coming up With the Use Cases How can we find the Use Cases ActorBased who EventBased external events Domain Process business processes from start to finish The use cases may then point us to the functional requirements for the system Use Case Diagram Treating the system to be built as a black box the use case diagram defines the system boundary and the actors external parties interacting with the system The use case diagram presents a set of use cases in the context of the external actors as to how they would use the system U59quot aise 1 Actor quotquotquotquot g T he System Use Case Diagram Cashier Machine 7 Buy Items p eaccounts receivable r n 39 Set Salepric K 4 39 Mana er C h Refundfpurchased G t d lysales g as ter Ilfems report Cashier Machine System Use Case type brief Use case name the use case with a descriptive name Primary Actor name the role of the external party interacting with the system Purpose the intention of the use case Other stakeholders other parties who may have an interest here Preconditions situations assumed to be true to start with Posteonditions situations guaranteed to be true upon completion Type brief References reference numbers of related requirements Use Case types casual full 0 Casual use case that is expressed in an ideal form remaining relatively free of technology and implementation details Casual Use Case may then consist of a more elaborate description of the Typical Course of Events Full concretely describes the process in terms of its real current design committed to specific technologies for implementation with full details consistent with the preconditions and postconditions Use Case type Casual expanded Use case buy items with cash Primary Actor GaShier Purpose to capture the sale of items purchased with cash Other stakeholders customer desires to make the purchase store owner capture sale and account for it Preconditions cashier already logged on Post conditions cash collected and inventory updated Type casual Typical Course of Events Actor Action System Response 1 Cashier sees customer approaching to buy items 2 Cashier records each item and quantity 3 D etermines the item price and charge and adds item into current sale transaction 4 Use Case type Casual expanded Use case Typical Course of Events Buy items with cash Actor Action System Response 1 Customer approaches Cashier to checkout 2 u 1 u 1 A L and adds item into 3 current sale transaction 4 Indicate completion ofitem entries 5 Computes and presents sales total o Cashier tells customer how much to pay 7 Customer pays cash a Cashier records cash tendered 9 presents balance due back to customer 10 Cashier gives the balance due back 11 Logs the completed sale 12 Updates inventory levels 13 Generates a receipt 14 Cashier gives receipt to customer Use Case type Casual expanded Typical Course of Events Actor Action System Response 1 Customer approaches Cashier to checkout 2 L A L A 3 M and adds item into current sale transaction 4 Indicate completion ofitem entries 5 Computes and presents sales total o Cashier tells customer how much to pay 7 Customer pays cash a Cashier records cash tendered 9 presents balance due back to customer 10 Cashier gives the balance due back 11 Logs the completed sale 12 Updates inventory levels 13 Generates a receipt 14 Cashier gives receipt to customer Alternative Courses 7 Customer does not have enough cash Cashier cancels sale 10 Cashier L L a lit a quot L aiiici P Essential Use Case multiple sections Buy Items I I Use case Typical Course of Events Actor Action System Response 1 Customer approaches Cashier to checkout 7 Lfcustomer pays cash go to Cash Payment If credit card go to Credit Card Payment If check go to Payment by Check Cash Payment Section Actor Action I System Response I I 1 Customer makes a cash payment I I Credit Card Payment Section Actor Action System Response I I 1 Customer produces credit card I Full Use Case The Use Case generally describes the use case from a functional point of View treating the system as a black box The full Use Case includes detailed description of the user interface and how the external actor interacts with the system In system analysis we should defer full Use Cases as far as possible until design time Full use cases should always be in the fully expanded form39 no need to have full use case in brief form Use Cases Diagram Identify all relevant use cases into one diagram showing the system in the context of how it is used The Use Cases Diagram also helps to define the system boundary m a A Ctor The System Use Case Assignment 6 Use Cases Diagram for the Library Information System L Arrival ofneyv Bboksg Membership r Patron Librarian The Library Information System Use Cases ranked in importance More important Use Cases 0 Member request to borrow a book most often 0 Member returning a book almost as often 0 Membership registration always needed Less important Use Cases 0 Member reporting a lost book 0 Arrival of new books also needed 0 Membership information update 0 Membership removal request Use case Member request to borrow a book Actors Patron initiator Librarian Purp ose To provide for any member to borrow any book Overview A patron arrives at the circulation desk with the book to borrow The librarian checks and records all relevant information and allows the book to be checked out Type primary and essential expanded format Typical Course of Events Actor Action System Response book to borrow 1 Patron approaches circulation desk with the 2 L book and identity ofthe patron uutu 3 checks the updated information about borrowing the book vaeri ed records the book on loan 4 Librarian a11ows the book to checkout Alternative Courses 4 A minimal set of Use Cases A minimal set of use cases to be implemented in the next iterative development cycle Member request to borrow a book Membership registration Arrival of new books This is a minimal set so that we can put books and library members into the system and that we can apply the borrow a book use case Topics Review Information gathering HyperCase exercise Review Use Cases amp Assignment 6 quirements Document for Project InputOutput Design Requirements Document For the project report 0 OK to have just the traditional requirements document full table of all functional requirements 0 Also appropriate to have all the Use Cases in Use Cases Diagram and of each of the use cases with description in casual expanded form 0 Both showing one in relationship to the other Topics Review Information gathering HyperCase exercise Review Use Cases amp Assignment 6 0 Requirements Document for Project InputOutput Design Reading Chapter I 5 Designing Effective Output Chapter I 6 Designing Effective Input Chapter I 8 Designing User Interfaces Chapter 9 Designing Accurate DataEntry Procedures 20 Principles of Effective Output intended purpose business appropriate to the user in right quantity to the right place at the right time with the right output method Principles of Effective Input Easy to comprehend 7 intuitive ow 7 purpose is explicit 7 consistent look and feel Easy to work with 7 make options available easier to recognize than to recall 7 exibility Pleasing to use aesthetically arranged Media for input 7 hard copy forms on paper 7 electronic forms on screen or web page 21 Objectives in User Interface Design 0 Matching the User Interface to the task 0 Making the User Interface Ef cient 0 Providing Appropriate Feedback Generating Usable Queries 0 Improving Productivity Types of User Interfaces Natural Language vs Use of Icons Q amp A style Menu choices Form to be filled Command Language Graphical Interaction User customization andor adaptation 22 Natural Language vs Use of Icons 0 Intuitive 0 Can user read the language 0 Dif culty in coming up with right words 0 Icons understandable universal Question and Answer Style System drives the input process May become inef cient too many questions to get to one point Not enough exibility Layback user feels better no need to think User has no easy way to perceive how long this will take 23 Menu Choices 0 List the choices before the user 0 It is easier to recognize than to recall 0 Too many choices Form to be filled 0 Better presentation of the Whole picture 0 Cross reference possible Within the form 0 Input validation more easily understandable Same principles in paper form design and more sophisticated feature possible 24 Command Language 0 More userdriven instead of system driven Provide for better interaction with data 0 Scripting possible with programming and integrating command language into more sophisticated tools Graphical User Interface Interactive System Design Dropdown pulldown and popup menu styles Menu length Immediate feedback Principle of minimality Context sensitive online help User behavior tracking 25 User Customization Adaptation 0 Users have different background and taste 0 Allow customer to make adjustments 0 Make this automatic adaptive user interface User profiling 0 Massive customization 26
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'