1. 1 /29 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. 2 /29 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. 3 /29 We continue with this figure – to the figure on the next slide…

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

5. 5 /29 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. 6 /29 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)

7. 7 /29 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. 8 /29 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!)

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

10. 10 /29 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  Flowlines  Directional  Typically Represent Reports, Documents, Memos, Phone Calls, Retrievals, Letters,...  Data Stores-Open-Ended  Cabinets, Logs, Files.  Data “at rest”  Data Flows  Depict Data Flowing Into or Out  Flow lines typically labeled.  Directional  Typically Represent Reports, Documents, Memos, Phone Calls, Retrievals, Letters,...

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

12. 12 /29 12 NO NOS Common Mechanical Errors

13. 13 /29

14. 14 /29

15. 15 /29

16. 16 /29 Level 0 DFD

17. 17 /29 Level 1 DFD

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

19. 19 /29 Step 4 – Detailed Transaction Description Level 3 DFD

20. 20 /29 Decision Logic Tables

21. 21 /29 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. 22 /29 9 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... ManufacturerbuildsAutomobile cardinality / modality

23. 23 /29 10 Entity Relationship Diagrams (continued) Oftentimes specific attribute values may be shown in tables |<-------------------ATTRIBUTES (FIELDS / MEMBERS)----------------> E FORDMUSTANG12342-RED 2345 44554-DOOR PONT88992-DOOR |<-------------------ATTRIBUTES (FIELDS / MEMBERS)----------------> MAKE MODEL ID# BODY TYPE COLOR REFERENCE E FORDMUSTANG12342 DOOR RED CAR PorscheBoxster S 2345 2 DOOR GreyRFR Mercedes S43044554-DOORBLACKRFR FORD RANGER 88992-DOOR WHITE RFR

24. 24 /29 ERDs Continued. Logical Modeling Sometimes shown as Logical Entity 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 Logical Structure may also be shown as logical entities:

25. 25 /29 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. 26 /29 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. 27 /29 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. 28 /29 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. 29 /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!