Data Flow Diagram of Any Industry

							            Expressing Requirements
• There are many different ways to express the
  requirements, some examples are :
  – English and Diagrams (most natural and popular)
  – Graphical Requirements Languages
     • Data Flow Diagrams
     • SADT(Softech’s proprietary version of DFD)
     • TRW’s proprietary Software Requirements Engr. Method
     • Use Case Diagram from UML
  – Very “Detailed” Requirements Specification (closer to design):
     • Formal Z Language and other Axiomatic definitions
     • Backus-Naur notation
     • Decision Tables
     • State Transition diagrams and Finite State Automata
     • Data dictionary
     • Entity Relation Diagram (ERD)
     • Object/Class diagram from UML
            “Modeling” Notations and Languages
• Just “read” through sections 4.5 & 4.6 of your text (over-stuffed)
   – ERD (we will cover in Design except for Data Dictionary here)
   – UML:
       •   Use Case; (we will cover in requirements)
       •   Class Diagram; (we will cover in design later)
       •   State Chart;   (we will cover in design later)
       •   Sequence Chart (we will cover in design later)
   – Petri Net (we will not cover and you will not be held responsible)
   – Data Flow Diagram (we will cover in requirements)
   – Formal Methods (we will not cover & you will not be held responsible)
       •   Decision Tables
       •   Z-Language
       •   Logic {propositional, predicate, temporal}
       •   SDL (specification and description language)
       •   SCR (Software Cost Reduction techniques)
3 Common Requirements Representations

• Plain English with Diagrams and Forms
  (most commonly used by current
  practitioners)
• Data Flow Diagram (from Structured
  Analysis)
• Use Case Diagram & Description (from
  OO technology)
  ERD may be considered as a 4th Common way to
  represent Requirement (Data part)
   Most Common Requirements Expression
               “English”
• Many Requirements Analysts are extrovert, domain
  experts who feel most comfortable with English and
  “pictures.”
  – many are ex-sales and ex-marketing people in the industry
  – many are people who worked in specific industry domain
     • health (ex-nurse , ex-doctors, ex-radiologist, ex-pharmacist, etc.)
     • manufacturing (ex-machinist, ex-engineer, ex-demand forecaster,
       etc.)
  – some are from the information technology organization
     • designers, programmers, and testers who have been building
       systems in that domain
     • trainers and project managers who have been operating in that
       domain
     Examples of Requirement Forms in
                 “English”


•   High Level Opportunity Profile
•   Organization Profile
•   User Profile
•   User Information Needs
•   User Functional Needs Description
                        High Level Opportunity Profile
                   Profile                                  Tell Us
             Opportunity/Needs :                     Problems that we are to address:
               1- Inventory is too high
               2- lose 50% of customer orders          Any other problems ?

             Justification:                           How the investment is justified:
              1- $2 million extra inventory is
              too high                                  Big business payback potential
              2- increase customer order by 40%
             Scope:                                   Project Boundaries:
  needs
 domain      1- inventory control                     Include distributors and
knowledge    2- order processing                       associated manufacturers ?
             Constraints:                              Other Key constraints :
            Budget of $350k                          How about deadline dates ?


             Functional:                              Goals:
            1- improve inventory control             1- reduce inventory level by $1miilion
            2- reduce customer order response time   2- respond to customer orders within 1 day
            3. Process customer order while          3. On-line customer order booking for
            customer is on the phone                 “standard” products in one phone call
       High Level Organizational Profile

    Profile                    Tell Us about impact

Success Factor:
                                   Install the system and
-Become Profitable this year       show results this year.
-Booking Sales Order                (any specific date?)


  Guidelines :                 About management,
                               legal, etc. direction:
none at this time
                               Need to comply with
                               legal accounting rules

   System Issues:              Compatibility needs:
                                    -Parallel run for 1 quarter
Must be able to cut over to        (must be no later than 3Q)
new system within 3 months         -must keep current XML format for EDI
of delivery
         High Level User Profile
  Job Title          Sales-Order Processing Personnel

 Job Function       Sale and take customer orders
                   Answer customer inquiry; check
 Job Activities    product availability and price; book
                   orders; and setup ship dates
                   Query inventory to see “sales” items;
Other Activities
                   and update customer file for new
                   customers or customer info changes
Education & Exp. High School education with 1 or
                 more years of sales experience

                   Customer oriented: patient&pleasant;
 Style             Flexible and accurate in details
          User Information Needs
 Order-Entry/Sales Person   Activity : Process Order

Information needed for      Customer name, address, accnt.
processing orders:          number, order item #, quantity,
                            price per item, availability date,
                            order date, ship date

Information used for:       Responding to customers’
                            inquiry , entering an order,
                            and scheduling ship date online
                            while the customer is calling in

Usage Mode & Frequency:     Currently 20 calls an hour and
                            expect growth to 25 calls an hour

                            Inventory availability and price
Current problems:            data comes back too slowly;
                            order confirmation is too slow
                            (needs 1 second response time for
                            each)
     User Functional Needs & Description
Function       Input              Processing               Output

                                                        Quantity available;
            Item type or                                selling price;
                                Search inventory
            item number                                 quantity on order;
Query                           & respond (less
                                than 1 second)          next available date;
Customer Customer name
                                                        bulk discount rate;
Order item or accnt #
                                                        special customer
                                                        discount
                                                     Accept message with
           Item name or numb;   Accept or reject     confirmation # and
           Item quantity;       the order;           a list of all ordered
           Shipping date and    Send info to         items with respective
Book an
           address;             accnts receivable;   prices, total invoice
order
           Customer Info;       Send info to         amount and shipping
           sales person I.d.    packaging;           info ;
                                Send info sales      Rejection message
                                personnel file       and reason
      Compare Against 6 Categories of Requirements


                                                • Functionalities
•   High Level Opportunity Profile              • UI
•   High Level Organization Profile             • Data/Information
•   High Level User Profile                     • Business Flow
•   User Information Needs                      • System and system
•   User Functional Needs                         Interface
                                                • Non Functional


    Can you associate and see how this covers the 6 categories of requirements?
             Data Flow Diagram (DFD)
• Data Flow Diagram is a network representation
  of a system (a bit like petri-net)
• This representation is often used in the analysis
  of the requirements.
• From the initial diagram one may refine the
  diagram and portray deeper levels of the system.
• It has 4 basic elements :
   –   Source or Destination of Data
   –   Flow of Data
   –   Process which transforms Data
   –   Store of Data
Data Flow Diagram (graphically)


              Source or Destination of Data




              Flow of Data



              Processing



               Data Store
              Example of DFD

                          Inventory Info.
                                                       Package Data
                               Product avail.
                                                            Packaging
                               Info.
                                                            details
                                           Shipping
           Orders
                          Order Processing Instruct.     Packaging
Customer   Order
           Confirmation
                                                             Invoice
                                  Customer credit,
                                  address, etc.
                                                          Customer

                               Customer Info DB
              Comments on DFD
• Refinement: If we want to explain the Order
  Processing process further, we can take that
  “bubble” and further refine it with the next
  level DFD
  – In general, how deeply should we take the DFD
    diagram?
     • To the lowest level that needs to be described for the
       customers to understand and the designers to design
     • To the level where it provides a “traceability” from
       code to design to requirements.
     • To the level that the tester can generate one specific
       test case to test that diagram.
• Best coupled with a Data Dictionary and
  Process explanation (in English)
                        Data Dictionary
• Data dictionary is list of all the data with each
  data item in the list described in further detail:

  – e.g. a data item called “Address”
  – Address is composed of Street Address + City Name + State
    + ZipCode
     • Street Address is an alphanumeric string of no more than 50
       characters long; it is right filled with blank spaces; initialized
       default is blank character
     • City Name is an alphanumeric string of no more than 20 characters
       long; it is right filled with spaces; initialized default is blank
       character
     • State is a 2 character string; initialized default is blank character
     • ZipCode is a numeric character string of no more than 5
       characters; initialized default is blank character
                Data Dictionary

• A data dictionary entry should exist for all
  the data - reports, query, and processing of
  information (also helps for DB design)

• Not all parts of the information may be
  easily obtained from customers or users
  (e.g. default or initial value – needs you to
  ask customers)

• There are also tools to help in the tracking
  of usage and conflicts of data elements
     Compare Against 6 Categories of Requirements

                                           • Functionalities
                                           • UI
• DFD’s :
                                           • Data/Information
   – Process
                              Covers?      • Business Flow
   – Data flow
                                           • System and system
• Data Dictionary                            Interface
                                           • Non Functional


Can you associate and see how this covers the 6 categories of requirements?
                      Use Case Diagram from UML
       • A scenario is a sequence of steps describing an interaction
         between a user and the system
               – e.g. (a scenario for purchasing one item) : a) user picks an item and
                 fills in quantity number(s), b) user “sees” total cost for that item, c)
                 user given a choice for next item.

       • Use Case is a set of scenarios tied together by a user.
               – e.g. (a use case for on-line purchase & payment) :
                   • scenario 1) user completes the purchases;
These may be
                   • scenario 2) user chooses payment option;
more than 1        • scenario 3) user provides customer information and financial
Use Case             information;
                   • scenario 4) user reviews the purchase and payment information.
                   • scenario 5) user accepts the terms and terminate


       • A Use Case Diagram is a graphical representation of the
         use cases. It represents an external view of the system.
USE CASE Diagram (graphically)


       Actor - interface (human or another system)




       Use Case - processing or function



       Association

       Extend Relationship
  Use Case Diagram for Requirements
              Gathering

              Gather
               Reqs
Analyst
              Verify
                                        User/customer
              Reqs      <<includes>>

              Specify       Prototype
               Reqs

             Manage
              Reqs                      Rectangle is the
                                        system boundary
Proj. Mgr.
      Expanding on Use Case Diagram
• Each of the use case in the use case diagram is
  further refined:
   – The use case, itself, needs to be described via English
     or some other specification language separately.
     (Later in the design, the Use Case Description is the
     source for class diagrams, sequence diagrams, etc.)

   – Statements about system characteristics and other
     non-functional requirements may be described with
     each use case description or within the system
     boundary rectangle.

• * Use Case and Scenarios are “a natural” for
  developing test scenarios and test cases.
            Use Case Description for the Diagram
 • sentences or paragraphs about the use case which
   describes the interaction between the “actor” and the
   system
 • Pre-conditions to the use case
 • Post-condition to the use case

 • The actual use case description may be
     – normal path
     – alternative paths
     – exceptions (or error path)



How would you get all 6 categories of information into the above?:
  - functional        - UI
  - non-functional    - existing system and other interfaces
  - data              - business workflow