Transcript Document 7302901

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.
1/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:
2/29
We continue with this figure – to the figure on the next slide…
3/29
This is what we are after….
Product
Features,
and more
from Leffingwell’s article. This figure says a great deal!!!
4/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.
5/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)
6/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.
7/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!)
8/29
Data Flow Diagram Conventions
v Emphasis is on Processing
Process
v Process Box
w Transform Inputs into Outputs
w Performed by People, Computers...
External
Entity
v External / Internal Entity
w Define Boundary of System
w Provide Net Inputs and/or Receive
Net Outputs from System
1
9/29
Data Flow Diagram Conventions
v Data Stores- Open-Ended
w Cabinets, Logs, Files.
w Data “at rest”
v Data Flows
w Depict Data Flowing Into or Out
of a Process
lines typically labeled.
w Flow
Flowlines
w Directional
w Typically Represent Reports,
Documents, Memos, Phone Calls,
Retrievals, Letters, ...
10/29
Simple Physical Data Flow Diagram
Mail Payment
Check
BankStmts
You or
Spouse
Pay
Bill
Customer
Mail Bill
Check Register
Withdrawal Entry
Paycheck
Employer
Any other
Source of
Income
Deposit Entry
You or
Spouse
Deposit
money in Deposit
to Bank Slip
Customer
Listings:
Previous
Statements
Withdrawal Checkbook
Log Entries
Entry
You or
your
Spouse
Withdraw
Cash
You or
your
Spouse
Balance
Checkbook
Account
Cash Receipt Deposit
Bank
Other income
Customer
Customer
Listings:
Listings:
Balanced
Balanced
Statement
Statement
Mail Bank Statement
and Canceled Checks
11/29
Common Mechanical Errors
NO NOS
12
12/29
Routing or Forwarding Processes
Customer
Sales
Department
Form: Order
Form 13:
Order to be Filled
Mail
Secretary:
Route
Mail
Mail:
Payment and Payment Card Accounts Payment Receipt
Receivable
Letter: Complaint
Customer
Customer Interoffice memorandum:
Relations Customer Credit
Manager
Phone or letter
Response to
Complaint
14
13/29
Common DFD Errors
Employee
Mail: End of Month Bank Statements
3
Form: Credit Union
Membership Application
1
Existing
Accounts
Asst Mgr:
Create
New Member
Account
Member Acct
(file drawer)
Employee
Standing
Clerk:
Generate
Employee
Bank
Statements
Employee (file cabinet)
Employee
Account ID
and Address
2
Asst. Mgr:
Freeze
Modified Account Member
Status: “frozen” Account
Letter: Member Account
Frozen
Notification15
Accounts
Receivable
Department
14/29
The Value of Physical DFDs
v DFDs Force Analysts to Communciate
their Understanding of Systems to EndUsers
v DFDs Require Analysts to Examine the
Interfaces between Systems,
Subsystems, and the Rest of the World
v DFDs model a System in Physical
Terms that are Familiar to End-Users
19
15/29
Step 1: Draw Context DFD
v Draw Context DFD to
describe system’s
relationship to rest of
the world
w
w
Main inputs & outputs
Only single Process
box and External
Entities
w Boundaries of system
w Confirms project
scope to top level
management
w All processing detail
collapsed into single
box
Club
Member
Level 0 DFD
Mail: Member
Order Coupons
0
Member
Mail: Club
Services
Promotions
and Catalogs
Form 40:
Order to be
Warehouse
Filled
1
Computer
Report and
Catalog:
Record
Promotions
Marketing
Department
16/29
Step
Step 2:
2: The
The Systems
Systems Diagram
Diagram
Mail:Subscription Card
and Order Form
Potential
Member
Level 1 DFD
Form 40: Transcribed
Special Order
Current Member Status
Form 40:
Order to
be filled
1
Subscription
Dept
Member
Database
Warehouse
Member details
Member Updates
3
Computer
Report &
Catalog:
Record
Promotion
2
Orders
Member UpdatesDept
Mail: member
Order Coupons
Promotion
Dept
Mail: Auto Catalog and Advertising Fliers
Marketing
Dept
Mail: Club Promotions and Catalogs
3
17/29
Club
Member
Step 3 – Middle Level – Identification of
Transaction Flow
Level 2 DFD
-
Form letter: Membership
Welcome or Denial
1.1
Form 40: Transcribed Special Order
Mail Subscription
Potential Card & Order Form Process
Subscription
Member
Transaction Current Member Status
1.2
FormLtr: Notice of Pending Bonus
Mail: MbrshpRenewal Slip
Club
Member
Mail/Phone: Membership
Cancellation (letter)
Member Database
Process
Membership
Renewal
Transaction
Mail: Renewal Welcome
Ltr
FormLtr: Membership
Cancellation Confirmation
Member
Updates
Member Updates
1.3
Process
Membership Form 25: Outstanding
A/R
Cancellation Credit Notice
Department
Transaction
4
18/29
Level 3 DFD
Step 4 – Detailed Transaction Description
A
Form letter: Membership welcome or denial
Potential
Member
Mail: Subscription card and order form
A
1.1.1
Subscription card and order via advertisement
B Mail Clerk:
Distribute
Mail
Subscription
card and order
via referral
1.1.6
dbase IV
program:
C Chk Refrl
Screen: Validity
Current
Member
Current
Status
member
status
A
1.1.5
Clerk:
Notify
Applicant
of Status
Form ltr:
Notice of
Pending
Bonus
A
Club
Member
D
E
D
1.1.7
1.1.4
Clerk:
Notify
Applicant
of Status
Subscript
ion
clerk:
Approve
Applicant
F
Application
Notebook
Processed
Application
1.1.2
dbase IV
program
Add new
member
A
New member
details
Processed
Application
F
Past Member
File Cabinet
Standing at time
acoount was closed
Special Order Form
dbase IV
Member
Prospective Member application and order
Existing Member’s bonus order (bottom)
1.1.3
Clerk:
Transcribe
Order
Form 40: Transcribed
Special Order
19/29
A
G
Decision Logic Tables
20/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.
21/29
Entity Relationship Diagrams (continued)
v ERDs REPRESENT ALL DATA THAT ARE
INPUT, STORED, TRANSFORMED, AND
PRODUCED IN A MANNER THAT IS
INDEPENDENT OF THE PROCESSING THAT
TRANSFORMS THEM...
cardinality / modality
Manufacturer
builds
9
Automobile
22/29
Entity Relationship Diagrams (continued)
Oftentimes specific attribute
values may be shown in tables
|<------------------- ATTRIBUTES (FIELDS / MEMBERS)
---------------- >
MAKE
MODEL
ID#
BODY TYPE
FORD
MUSTANG
1234
22-DOOR
RED
CAR
Porsche
Boxster S
2345
2 DOOR
Grey
RFR
4455
4-DOOR
BLACK
RFR
8899
2-DOOR
WHITE
RFR
Mercedes S430
FORD
PONT
RANGER
10
COLOR REFERENCE
23/29
E
ERDs Continued. Logical Modeling
Sometimes shown as Logical Entity
Logical Structure may also be shown as logical entities:
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
24/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)
25/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…

26/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.

27/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.
28/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!
29/29