Requirements Analysis 2: More Traceability and Moving to Use Cases - PowerPoint PPT Presentation

Loading...

PPT – Requirements Analysis 2: More Traceability and Moving to Use Cases PowerPoint presentation | free to download - id: cbb03-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Requirements Analysis 2: More Traceability and Moving to Use Cases

Description:

CAR. Porsche. Boxster S. 2345. 2. DOOR. Grey. RFR. Mercedes. S430. 4455. 4. DOOR. BLACK. RFR. FORD ... Graphical or pictures clearly and perhaps interactively. ... – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 30
Provided by: BobRo51
Learn more at: http://www.unf.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Requirements Analysis 2: More Traceability and Moving to Use Cases


1
Requirements Analysis 2 More Traceability and
Moving to Use Cases
  • Sources
  • Use Cases Textbook
  • Personal Notes
  • Leffingwells Article
  • Chapter 9 , Modern Systems
  • Analysis and Design book by
  • Hoffer, George, and Valacich.

2
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

3
We continue with this figure to the figure on
the next slide
4
This is what we are after.
Product Features, and more
from Leffingwells article. This figure says a
great deal!!!
5
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.

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

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

8
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!)

9
Data Flow Diagram Conventions
Data Flow Diagram Conventions
v
Emphasis
is on
Emphasis
Processing
v
Process
v
Process Box
Process Box
v
Transform Inputs into Outputs
w
Transform Inputs into Outputs
w
Performed by People, Computers...
w
Performed by People, Computers...
w
External / Internal Entity
v
External / Internal Entity
v
External
Entity
Define Boundary of System
w
Define Boundary of System
w
Provide Net Inputs and/or Receive
w
Provide Net Inputs and/or Receive
w
Net Outputs from System
Net Outputs from System
1
10
(No Transcript)
11
Simple Physical Data Flow Diagram
Mail Payment
Check
Bank
Stmts
You or
Spouse
Customer
Customer
Customer
Customer
Pay
Listings
Mail Bill
Listings
Listings
Bill
Balanced
Balanced
Previous
Check Register
Statement
Statement
Statements
Withdrawal
Checkbook
Withdrawal Entry
Log Entries
Entry
You or
You or
your
your
Deposit Entry
Spouse
Paycheck
Spouse
Balance
Employer
Withdraw
You or
Checkbook
Cash
Spouse
Account
Deposit
money in
Deposit
Cash Receipt Deposit
to Bank
Any other
Slip
Mail Bank Statement
Source of
Income
and Canceled Checks
Bank
Other income
12
Common Mechanical Errors
NO NOS
12
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
Level 0 DFD
17
Level 1 DFD
18
Step 3 Middle Level Identification of
Transaction Flow
Level 2 DFD
-
Form letter Membership
Welcome or Denial
Form 40 Transcribed Special Order
1.1
Mail Subscription
Process
Potential
Card Order Form
Subscription
Member
Current Member Status
Transaction
Form
Ltr
Notice of Pending Bonus
Member
1.2
Updates
Member Database
Mail
Mbrshp
Renewal Slip
Process
Club
Membership
Member
Renewal
Mail Renewal Welcome
Ltr
Transaction
Form
Ltr
Membership
Member Updates
1.3
Cancellation Confirmation
Process
Mail/Phone Membership
Membership
Form 25 Outstanding
Cancellation (letter)
A/R
Credit Notice
Cancellation
Department
Transaction
4
4
19
Level 3 DFD
Step 4 Detailed Transaction Description
20
Decision Logic Tables
21
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.

22
(No Transcript)
23
Entity Relationship Diagrams (continued)
Entity Relationship Diagrams (continued)
Oftentimes specific attribute
values may be shown in tables
lt
-------------------
ATTRIBUTES (FIELDS / MEMBERS)
----------------
gt
lt
-------------------
ATTRIBUTES (FIELDS / MEMBERS)
----------------
gt
E
E
MAKE MODEL ID BODY TYPE
COLOR REFERENCE
FORD
MUSTANG
1234
2
RED
DOOR
CAR
FORD
MUSTANG
1234
2
-
RED
2
2345
Grey
RFR
Porsche
Boxster S
DOOR
2345
Mercedes
S430
4455
4
-
DOOR
BLACK
RFR
4455
4
-
DOOR
FORD

8899
2
-
DOOR
RFR
RANGER
WHITE
PONT
8899
2
-
DOOR
10
24
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_Num
ber
25
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çadeif 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)

26
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

27
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 applications functionality.
  • DFDs, ERDs, and prototypes include both whats
    and hows in their perspectives can confuse
    users, and this is not advisable.

28
Discussion Summary of Some of these
Technologies - More
  • May run into any number of these.
  • All provide benefitsand 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.

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 its 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!
About PowerShow.com