Expressing Requirements

1. 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(also for 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 (definitely closer to design)

2. “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- covered 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 ---- covered in Graduate Formal Methods (SWE6883 Class) • Logic {propositional, predicate, temporal} • SDL (specification and description language) • SCR (Software Cost Reduction techniques)

3. 3 “Common” Requirements Representations • Plain English with Diagrams and Forms(remains as most commonly used by many practitioners) • Data Flow Diagram(from Structured Analysis) • Use Case Diagram & Description(from OO technology) ERDmay be considered as a 4th Common way to represent Requirement (Data part of requirement)

4. Most Common Requirements Expression“English” • Many Requirements Analysts are extrovert, domainexperts 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 IT and software organizations • designers, programmers, and testers who have been building systems in that domain • trainers and project managers who have been operating in that domain

5. Examples of Requirement-Forms in “English” • High Level Opportunity Profile • Organization Profile • User Profile • User Information Needs • User Functional Needs Description

6. High Level OpportunityProfile(‘plumbing’ product manufacturing) 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 is the investment justified: 1- $2 million extra inventory is too high & needs better control 2- increase customer order by 40% Big business payback potential - - - needs domain knowledge Scope: Project Boundaries: 1- inventory control 2- order processing Include distributors and associated manufacturers ? Constraints: Other Key constraints : How about deadline dates ? Current budget of $750k Functional: Goals: 1- reduce inventory level by $1miilion 2- respond to customer orders within 1 hour 3. On-line customer order booking for “standard” products in one-session or 1 phone call 1- improve inventory control 2- reduce customer order response time 3. Process customer order while customer is on-line or on the phone

7. High Level Organizational Profile Profile Tell Us about impact Success Factor: Install the system and show results this year. (any specific date?) -Become Profitable this year -Booking Sales Order Guidelines : About management, legal, etc. direction: none at this time Need to comply with legal accounting rules Compatibility needs: System Issues: -Parallel run for 1 quarter (must be no later than 3Q) -must keep current XML format for EDI Must be able to cut over to new system within 3 months of delivery

8. High Level User-Profile “Order Processing Personnel” or On-line “customer” Job Title Job Function Sales and take customer orders Answer customer inquiry; check product availability and price; book orders; and setup ship dates Job Activities Query inventory to see “sales” items; and update customer file for new customers or customer info changes Other Activities Education & Exp. High School education with 1 or more years of sales experience Customer oriented: patient&pleasant; Flexible and accurate in details Style

9. User Information Needs Order-Entry/Sales Person Activity : Process Order Information needed for processing orders: Customer name, address, accnt. number, order item #, quantity, price per item, availability date, order date, ship date Responding to customers’ inquiry , entering an order, and scheduling ship date online while the customer is calling in Information used for: Currently 20 calls an hour and expect growth to 25 calls an hour Usage Mode & Frequency: Inventory availability and price data comes back too slowly; order confirmation is too slow (needs 1 second response time for each) Current problems:

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

11. Functionalities UI Data/Information Business Flow System and system Interface Non Functional High Level Opportunity Profile High Level Organization Profile High Level User Profile User Information Needs User Functional Needs Compare Against 6 Categories of Requirements Can you associate and see how this covers the 6 categories of requirements?

12. Data Flow Diagram (DFD) • Data Flow Diagram is a network representation of a system • This representation is often used in the analysis of the requirements (e.g. business flow). • 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

13. Data Flow Diagram (graphically) Source or Destination of Data Flow of Data Processing Your text book and many use Data Store

14. Example of DFD Inventory Info. Package Data Item Search info Product avail. Info. Packaging details Shipping Instruct. Orders Order Processing Packaging Customer Order Confirmation Invoice Customer credit, address, etc. cust. query info Customer Customer Info DB

15. Comments on DFD • Refinement: If we want to explain the Order Processing process further, we can take that processing “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 specifictest case to test that diagram. • Best coupled with a Data Dictionary and Process explanation (in English)

16. 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

17. 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

18. Functionalities UI Data/Information Business Flow System and system Interface Non Functional DFD’s : Process Data flow Data Dictionary Compare Against 6 Categories of Requirements Covers? Can you associate and see how this covers the 6 categories of requirements?

19. A note on DFD diagram of library system - text (p 173 ) • The discussion on “items returned” to Loan Record data-store versus “items returned” to Process Fines function is somewhat interesting --- do you feel that this is confusing? • Is it possible that it is the same information? • If not, perhaps more descriptive naming of information would be the answer? items returned return loan record items returned items returned patron overdue fines Process fine patron’s fine payment Outstanding fines

20. Use Case • Use Case was first introduced by Ivar Jacobson in early 1990’s as a “scenario- based” technique to capture requirements. In some ways Use Case is similar to DFD, which came before Use Case, in capturing high level functionalities, flow, and interactions.

21. Use Case Diagram from UML • A scenariois 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 to delete/modify the purchase or continue. • Use Case is a set of scenarios tied together by a user. • e.g. (a use case for online payment at the conclusion of on-line purchase) : • scenario 1) user processes and completes the purchases; • scenario 2) user chooses payment option; • scenario 3) user provides customer information and financial 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. These may be more than 1 Use Case

22. USE CASE Diagram (graphically) Actor – external interface (humanor another system/subsystem) Use Case – scenarios (processing or functionalities) Association Extend Relationship

23. Use Case Diagram for “Requirements Gathering” Requirements Gathering Mgmt System Record Reqs User/customer Analyst Verify Reqs <<includes>> Prototype Specify Reqs Requirements DB Manage Activities Extension Pt Develop schedule Develop Schedule <<extends>> Rectangle is the system boundary Proj. Mgr.

24. Applicability of Use Cases • Use Cases are natural source for describing: • Functionalities • Business Flow • System Interface Thus they also serve as inputs for design/and coding • Use Cases are also a good source for developing test scenarios and test cases.

25. Expanding (Refining) on Use Case Diagram with Use Case Description • Each use case in the use case diagram may be further refined with Use Case Description: • The use case diagram, itself, needs to be further “expanded” via English or some other specification language separately. (Later in the design, the Use CaseDescription is the source for class diagrams, sequencediagrams, etc.) • Statements about system characteristics and other non-functional requirements may be described with each Use Case Descriptionor within the system boundary rectangle.

26. Use Case Descriptionfor 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 for • normal path (main line functionality) • alternative paths (choices of alternative functions) • exceptions ( error path and possible “re-do”) How would you get all 6 categories of information into the above?: - functional - UI - non-functional - existing system and other interfaces - data - business workflow

27. Sample Use Case Description Pre-conditions: customer is in good standing and item available in inventory Use Case Description for: Order Processing Main path – (i) Customer request of items are pulled from available inventor; ------ the response time for pulled information needs to be less than or equal to 1 second per item, --------- (ii) If the customer completes the purchase, the inventory for that item is updated Error path - if preconditions are not all met, provide an error message; depending on the error, give the user an opportunity to improve his/her status and/or an opportunity to order another item Post condition: upon purchase completion, item quantity in the inventory file is deducted