Expressing Requirements
• There are many different ways to express the
requirements, some examples are :
1.
2.
3.
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)
“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
Opportunity/Needs :
1- Inventory is too high
2- lose 50% of customer orders
Justification:
1- $2 million extra inventory is
too high & needs better control
2- increase customer order by 40%
needs
domain
knowledge
Tell Us
Problems that we are to address:
Any other problems ?
How is the investment justified:
Big business payback potential - - -
Scope:
Project Boundaries:
1- inventory control
2- order processing
Include distributors and
associated manufacturers ?
Constraints:
Current budget of $750k
Functional:
1- improve inventory control
2- reduce customer order response time
3. Process customer order while
customer is on-line or on the phone
Other Key constraints :
How about deadline dates ?
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
High Level Organizational Profile
Profile
Tell Us about impact
Success Factor:
-Become Profitable this year
-Booking Sales Order
Guidelines :
none at this time
System Issues:
Must be able to cut over to
new system within 3 months
of delivery
Install the system and
show results this year.
(any specific date?)
About management,
legal, etc. direction:
Need to comply with
legal accounting rules
Compatibility needs:
-Parallel run for 1 quarter
(must be no later than 3Q)
-must keep current XML format for EDI
High Level User-Profile
Job Title
Job Function
“Order Processing Personnel” or
On-line “customer”
Sales and take customer orders
Job Activities
Answer customer inquiry; check
product availability and price; book
orders; and setup ship dates
Other Activities
Query 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
Style
Customer oriented: patient&pleasant;
Flexible and accurate in details
User Information Needs
Order-Entry/Sales Person
Information needed for
processing orders:
Information used for:
Usage Mode & Frequency:
Current problems:
Activity : Process Order
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
Currently 20 calls an hour and
expect 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 for
each)
User Functional Needs & Description
Function
Input
Item type or
item number
Query
Customer Customer name
Order item or accnt #
Book an
order
Item name or numb;
Item quantity;
Shipping date and
address;
Customer Info;
sales person I.d.
Processing
Search inventory
& respond (less
than 1 second)
Accept or reject
the order;
Send info to
accnts receivable;
Send info to
packaging;
Send info sales
personnel file
Output
Quantity available;
selling price;
quantity on order;
next available date;
bulk discount rate;
special customer
discount
Accept message with
confirmation # and
a list of all ordered
items with respective
prices, total invoice
amount and shipping
info ;
Rejection message
and reason
Compare Against 6 Categories of Requirements
•
•
•
•
•
High Level Opportunity Profile
High Level Organization Profile
High Level User Profile
User Information Needs
User Functional Needs
•
•
•
•
•
Functionalities
UI
Data/Information
Business Flow
System and system
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
• 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 many
use
Example of DFD
Inventory Info.
Package Data
Item
Search
info
Orders
Customer
Product avail.
Info.
Shipping
Order Processing Instruct.
Order
Confirmation
cust.
query
info
Customer credit,
address, etc.
Customer Info DB
Packaging
details
Packaging
Invoice
Customer
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
• DFD’s :
– Process
– Data flow
• Data Dictionary
Covers?
•
•
•
•
•
Functionalities
UI
Data/Information
Business Flow
System and system
Interface
• Non Functional
Can you associate and see how this covers the 6 categories of requirements?
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?
return
items returned
loan record
items
returned
patron
overdue fines
payment
Process
fine
Outstanding fines
patron’s fine
Use Case
• Use Case was first introduced by Ivar
Jacobson in early 1990’s as a “scenariobased” 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) :
These may be
more than 1
Use Case
• 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.
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”
Requirements Gathering Mgmt System
Record
Reqs
User/customer
Analyst
Verify
Reqs
Specify
Reqs
Manage
Activities
Extension Pt
Develop schedule
Proj. Mgr.
Prototype
Requirements DB
Develop
Schedule
Rectangle is the
system boundary
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 nonfunctional 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 case
3. 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
- non-functional
- UI
- existing system and other interfaces
- data
- business workflow
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