Slide #1.

Requirements Analysis 2: More Traceability and Moving to Use Cases Sources:     Use Cases Textbook Personal Notes Leffingwell’s Article Chapter 9 , Modern Systems Analysis and Design book by Hoffer, George, and Valacich. 1/29
More slides like this


Slide #2.

Continue the Traceability Mapping  From the Product Vision Document for the Application, which contains the desired Features derived from Stakeholder Needs, we need to map the Features to Use Cases.  Consider the next two slides: 2/29
More slides like this


Slide #3.

We continue with this figure – to the figure on the next slide… 3/29
More slides like this


Slide #4.

This is what we are after…. Product Features, and more from Leffingwell’s article. This figure says a great deal!!! 4/29
More slides like this


Slide #5.

Modern Approach: Use Cases  We must move onto a technology that can capture the functional requirements as well as the non-functional requirements.  But first, some traditional tools used to capture some of or parts of requirements.  These ‘work’ to a greater or lesser degree.  They emphasize different things and have been around for a long time. 5/29
More slides like this


Slide #6.

Additional Sources that May be Used to Capture Requirements  Generally Accomplished by Business Analysts, but…         Requirements Lists  Data Flow Diagrams (DFDs) • Structured English within DFDs to show steps in Logical Processes  Decision Logic Tables – to represent Logic of Choice in conditional statements  Structured English, decision tables, and decision trees for representing processing logic  Entity-Relation Diagrams – representation of logic information and their relationships  Prototyping  Use Cases – our choice! (next lecture) 6/29
More slides like this


Slide #7.

Requirements Lists Terribly boring; text plus maybe flowcharting. Variable.  Open to huge misinterpretation  Imply completeness  Can result in volumes of text…   A comprehensive list of functions; An itemization   Implies functions can be extracted and implemented.  7/29
More slides like this


Slide #8.

Data Flow Diagrams Structured Analysis Tool  DFDs – show data flows; interacting processes. • Contains Processes, Data Flows, Data Stores. • Data flows from process to process; stops at a data store. • A dynamic view of the system. “Information in motion!” • Used extensively; a traditional process modeling tool. • Shows what happens INSIDE the system. – • Typically contain a lot of detail and many levels… • Still useful in structured analysis and structured design approaches – especially with non-object-oriented systems (transaction processing systems; show information flow!) 8/29
More slides like this


Slide #9.

Data Flow Diagram Conventions  Emphasis is on Processing Process  Process Box  Transform Inputs into Outputs  Performed by People, Computers... External Entity  External / Internal Entity  Define Boundary of System  Provide Net Inputs and/or Receive Net Outputs from System 1 9/29
More slides like this


Slide #10.

Data Flow Diagram Conventions  Data Stores- Open-Ended   Cabinets, Logs, Files. Data “at rest”  Data Flows  Depict Data Flowing Into or Out of a Process lines typically labeled.  Flow Flowlines  Directional  Typically Represent Reports, Documents, Memos, Phone Calls, Retrievals, Letters, ... 10/29
More slides like this


Slide #11.

Simple Physical Data Flow Diagram Mail Payment Check BankStmts You or Spouse Pay Bill Customer Mail Bill Check Register Withdrawal Entry Paycheck Employer Any other Source of Income Deposit Entry You or Spouse Deposit money in Deposit to Bank Slip Customer Listings: Previous Statements Withdrawal Checkbook Log Entries Entry You or your Spouse Withdraw Cash You or your Spouse Balance Checkbook Account Cash Receipt Deposit Bank Other income Customer Customer Listings: Listings: Balanced Balanced Statement Statement Mail Bank Statement and Canceled Checks 11/29
More slides like this


Slide #12.

Common Mechanical Errors NO NOS 12 12/29
More slides like this


Slide #13.

Routingor ForwardingProcesses Customer Sales Department Form: Order Form13: Order tobeFilled Mail Secretary: Route Mail Mail: Payment andPayment Card Accounts Payment Receipt Receivable Letter: Complaint Customer Customer Interofficememorandum: Relations Customer Credit Manager Phoneor letter Responseto Complaint 14 13/29
More slides like this


Slide #14.

CommonDFDErrors Employee Mail: Endof MonthBankStatements 3 Form: Credit Union MembershipApplication 1 Existing Accounts Asst Mgr: Create NewMember Account Member Acct (filedrawer) Employee Standing Clerk: Generate Employee Bank Statements Employee(filecabinet) Employee Account ID andAddress 2 Asst. Mgr: Freeze ModifiedAccount Member Status: “frozen” Account Letter: Member Account Frozen Notification 15 Accounts Receivable Department 14/29
More slides like this


Slide #15.

TheValueof Physical DFDs DFDsForceAnalyststoCommunciate their Understandingof SystemstoEndUsers DFDsRequireAnalyststoExaminethe InterfacesbetweenSystems, Subsystems, andtheRest of theWorld DFDsmodel aSysteminPhysical Termsthat areFamiliar toEnd-Users 19 15/29
More slides like this


Slide #16.

Step1: DrawContext DFD DrawContext DFDto describesystem’s relationshiptorest of theworld  Maininputs&outputs  OnlysingleProcess boxandExternal Entities  Boundariesof system  Confirmsproject scopetotoplevel management  All processingdetail collapsedintosingle box Club Member Level 0 DFD Mail: Member Order Coupons 0 Member Mail: Club Services Computer Report and Promotions Catalog: andCatalogs Record Promotions Form40: Order tobe Warehouse Filled 1 Marketing Department 16/29
More slides like this


Slide #17.

Step Step 2: 2: The The Systems Systems Diagram Diagram Mail:Subscription Card and Order Form Potential Member Level 1 DFD Form 40: Transcribed Special Order Current Member Status 1 Subscription Dept Member Database Computer Report & Catalog: Record Promotion 2 3 Orders Member UpdatesDept Mail: member Order Coupons Promotion Dept Marketing Dept Form 40: Order to be filled Member details Member Updates Warehouse Mail: Auto Catalog and Advertising Fliers Mail: Club Promotions and Catalogs 3 17/29 Club Member
More slides like this


Slide #18.

Step 3 – Middle Level – Identification of Transaction Flow Level 2 DFD - Form letter: Membership Welcome or Denial 1.1 Form 40: Transcribed Special Order Mail Subscription Potential Card & Order Form Process Subscription Member Transaction Current Member Status 1.2 FormLtr: Notice of Pending Bonus Club Member Mail: MbrshpRenewal Slip Process Membership Renewal Transaction Mail: Renewal Welcome Ltr FormLtr: Membership Cancellation Confirmation Mail/Phone: Membership Cancellation (letter) Member Updates Member Database Member Updates 1.3 Process Membership Form 25: Outstanding A/R Cancellation Credit Notice Department Transaction 4 18/29
More slides like this


Slide #19.

Level 3 DFD Step 4 – Detailed Transaction Description A Form letter: Membership welcome or denial Potential Member Mail: Subscription card and order form A 1.1.1 Subscription card and order via advertisement B Mail Clerk: Distribute Mail Subscription card and order via referral 1.1.6 dbase IV program: C Chk Refrl Screen: Validity Current Member Current Status member status A 1.1.5 Clerk: Notify Applicant of Status Form ltr: Notice of Pending Bonus A Club Member D E D 1.1.7 1.1.4 Clerk: Notify Applicant of Status Subscript ion clerk: Approve Applicant F Application Notebook Processed Application 1.1.2 dbase IV program Add new member A New member details Processed Application F Past Member File Cabinet Standing at time acoount was closed Special Order Form dbase IV Member Prospective Member application and order Existing Member’s bonus order (bottom) 1.1.3 Clerk: Transcribe Order Form 40: Transcribed Special Order 19/29 A G
More slides like this


Slide #20.

Decision Logic Tables 20/29
More slides like this


Slide #21.

Entity Relationship Diagrams (ERDs)  Entity-Relation Diagrams • A static view of data and data relationships… • Show details of entities (attributes, relationships) • Show how data ‘may be’ stored in application • Used a lot for information engineering approaches. • Not dynamic and require DFDs for the dynamics.  Sometimes the differences between static and dynamic views of system are confusing to users. • Still good for creating logical data models after requirements have been gathered and for creating your database and your fully-attributed list. Used extensively in database modeling and design.  Provide little meaning / utility to the user. 21/29
More slides like this


Slide #22.

Entity Relationship Diagrams (continued)  ERDs REPRESENT ALL DATA THAT ARE INPUT, STORED, TRANSFORMED, AND PRODUCED IN A MANNER THAT IS INDEPENDENT OF THE PROCESSING THAT TRANSFORMS THEM... cardinality / modality Manufacturer builds 9 Automobile 22/29
More slides like this


Slide #23.

Entity Relationship Diagrams (continued) Oftentimes specific attribute values may be shown in tables |<------------------- ATTRIBUTES (FIELDS / MEMBERS) ---------------- > MAKE MODEL ID# BODY TYPE FORD MUSTANG 1234 22-DOOR RED CAR Porsche Boxster S 2345 2 DOOR Grey RFR 4455 4-DOOR BLACK RFR 8899 2-DOOR WHITE RFR Mercedes S430 FORD PONT RANGER 10 COLOR REFERENCE 23/29 E
More slides like this


Slide #24.

ERDs Continued. Logical Modeling Sometimes shown as Logical Entity Logical Structure may also be shown as logical entities: Member Member_ID Member_Type_Number Member_First_Name Member_Middle_Initial Member_Last_Name Member_Address Member_City Member_State Member_Zip_Code Member_Phone_Number Member_Email University_ID_Number 24/29
More slides like this


Slide #25.

Prototypes and Prototyping  Prototypes • • •     Concentrate on user interface Omit almost all computations and background coding. Executives may have a hard time realizing that what they see is only façade…if not told ‘up front.’ Should not be used as a main requirements tool. But may be used to notice thing missing… Good for ascertaining the user interface, though Emphasize utility and usability (much more later) 25/29
More slides like this


Slide #26.

Prototype  Mock-up of user interface. Storyboarding…  Graphical or pictures clearly and perhaps interactively.  Introduced now; refined later after the requirements have stabilized a bit. • should be rapid; ignore some alternatives / exceptions  Avoids temptations to proceed solving problems before they are understood.  Prototype helps to demonstrate a ‘proof of concept’ It also forms the rough basis for a user manual – as if the prototype were a working system…  26/29
More slides like this


Slide #27.

Discussion: Summary of Some of these Technologies  Requirements Specs are rarely used once application is produced. ??? (Discuss!)  DFDs and ERDs are useful for moving into Design (procedural and database) and implementation • But can hold little meaning to users  Prototypes obscure the real requirements and seem to emphasize the interface at the expense of the real application’s functionality. DFDs, ERDs, and prototypes include both ‘whats’ and ‘hows’ in their perspectives – can confuse users, and this is not advisable.  27/29
More slides like this


Slide #28.

Discussion: Summary of Some of these Technologies - More  May run into any number of these.  All provide benefits…and sometimes confusion to some.   Many long-time software development corporations still use some of these older technologies.   Again, they are quite useful especially if coupled with more modern techniques. 28/29
More slides like this


Slide #29.

Interactions with the User  Need to emphasize capturing the requirements of the system from the users’ perspective.  Users view systems as black boxes (explain)  Requirements emphasizing black box approach – much more meaningful to users. • Implies: it’s all about interactions, that is, what does the stakeholder SEE!  Use Cases are tools that should be used to show the ‘What’ of a system exclusively! 29/29
More slides like this