Requirements Analysis 2: More Traceability and Moving to Use Cases

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.

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:

3. We continue with this figure – to the figure on the next slide…

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

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.

6. Additional Sources that May be Used to CaptureRequirements • 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)

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.

8. Data Flow DiagramsStructured 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!)

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

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

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

12. Common Mechanical Errors NO NOS 12

16. Level 0 DFD

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

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 Process Potential Card & Order Form Subscription Member Current Member Status Transaction 1.2 Member Form Ltr : Notice of Pending Bonus Updates Member Database Mail: Mbrshp Renewal Slip Process Club Membership Member Renewal Mail: Renewal Welcome Ltr Transaction Form Ltr : Membership Member Updates 1.3 Cancellation Confirmation Process Mail/Phone: Membership Membership Form 25: Outstanding Cancellation (letter) A/R Credit Notice Cancellation Department Transaction 4 4

19. Level 3 DFD Step 4 – Detailed Transaction Description

20. Decision Logic Tables

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.

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

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

24. ERDs Continued. Logical ModelingSometimes 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

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)

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…

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.

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.

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!