Expressing Requirements• There are many different ways to express the

requirements, some examples are :1. English and Diagrams (most natural and popular)

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

3. 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)

“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 “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)

ERD may be considered as a 4th Common way to represent Requirement (Data part of requirement)

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

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(‘plumbing’ product manufacturing)

Profile Tell Us

Opportunity/Needs : Problems that we are to address:1- Inventory is too high2- lose 50% of customer orders

Justification:1- $2 million extra inventory is too high & needs better control2- increase customer order by 40%

How is the investment justified:

Big business payback potential - - -

Scope:

Constraints:

Functional:

Project Boundaries:

Other Key constraints :

Goals:

1- inventory control2- order processing

Current budget of $750k

1- improve inventory control2- reduce customer order response time3. Process customer order while customer is on-line or on the phone

Include distributors and associated manufacturers ?

How about deadline dates ?

1- reduce inventory level by $1miilion 2- respond to customer orders within 1 hour3. On-line customer order booking for “standard” products in one-session or 1 phone call

Any other problems ?

needsdomain

knowledge

High Level Organizational Profile

Profile Tell Us about impact

Success Factor:

Guidelines : About management,legal, etc. direction:

Compatibility needs:System Issues:

-Become Profitable this year -Booking Sales Order

Install the system andshow results this year. (any specific date?)

none at this time

Must be able to cut over tonew system within 3 monthsof delivery

-Parallel run for 1 quarter(must be no later than 3Q)-must keep current XML format for EDI

Need to comply withlegal accounting rules

High Level User-Profile

Job Title“Order Processing Personnel” or On-line “customer” Job Function Sales and take customer orders

Job ActivitiesAnswer customer inquiry; check product availability and price; bookorders; and setup ship dates

Other ActivitiesQuery inventory to see “sales” items;and update customer file for new customers or customer info changes

Education & Exp. High School education with 1 or more years of sales experience

StyleCustomer oriented: patient&pleasant;Flexible and accurate in details

User Information NeedsActivity : Process OrderOrder-Entry/Sales Person

Information needed forprocessing orders:

Customer name, address, accnt.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 onlinewhile the customer is calling in

Usage Mode & Frequency:

Current problems:

Currently 20 calls an hour andexpect growth to 25 calls an hour

Inventory availability and price data comes back too slowly;order confirmation is too slow (needs 1 second response time foreach)

User Functional Needs & Description

Function Input Processing Output

Query CustomerOrder item

Item type oritem number

Search inventory & respond (less than 1 second)

Quantity available;selling price; quantity on order;next available date; bulk discount rate;special customer discount

Customer name or accnt #

Book anorder

Item name or numb;Item quantity;Shipping date and address;Customer Info;sales person I.d.

Accept or reject the order;Send info to accnts receivable;Send info to packaging; Send info sales personnel file

Accept message with confirmation # anda list of all ordereditems with respective prices, total invoice amount and shipping info ;Rejection message and reason

Compare Against 6 Categories of Requirements

• 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

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

• 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

Data Flow Diagram (graphically)

Source or Destination of Data

Flow of Data

Processing

Data Store Your text book and manyuse

Example of DFD

CustomerCustomer

OrdersOrder Processing

Customer Info DB

Customer credit, address, etc.

Inventory Info.

Packaging

Invoice

Product avail.Info.

Package Data

Packagingdetails

ShippingInstruct.

CustomerCustomer

Order Confirmation

ItemSearchinfo

cust.queryinfo

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

• Data/Information

• Business Flow

• System and system Interface

• Non Functional

• DFD’s :– Process

– Data flow

• Data Dictionary

Can you associate and see how this covers the 6 categories of requirements?

Covers?

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?

patron

return

Process fine

items returnedloan record

patron’s fine

items returned

items returned

overdue fines

Outstanding finespayment

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.

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 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 bemore than 1Use Case

USE CASE Diagram (graphically)

Actor – external interface (human or another system/subsystem)

Use Case – scenarios (processing or functionalities)

Association

Extend Relationship

Use Case Diagram for “Requirements Gathering”

RecordReqs

VerifyReqs

SpecifyReqs

ManageActivitiesExtension Pt

Develop schedule

Prototype

<<includes>>

Analyst

Proj. Mgr.

User/customer

Rectangle is thesystem boundary

Requirements DB

Develop Schedule

<<extends>>

Requirements Gathering Mgmt System

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.

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 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 Description for the Diagram

1. sentences or paragraphs about the use case which describes the interaction between the “actor” and the system

2. Pre-conditions to the use case3. 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

Sample Use Case Description

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 updatedError 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

Pre-conditions: customer is in good standing and item available in inventory

Post condition: upon purchase completion, item quantity in the inventory file is deducted