1/29

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.

2/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:

3/29

We continue with this figure – to the figure on the next slide…

4/29from Leffingwell’s article. This figure says a great deal!!!

ProductFeatures,and more

This is what we are after….

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

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

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

8/29

Data Flow DiagramsStructured 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/29

1

Data Flow Diagram ConventionsData Flow Diagram Conventions

Emphasis

Process Box Transform Inputs into Outputs Performed by People, Computers...

External / Internal Entity Define Boundary of System Provide Net Inputs and/or Receive

Net Outputs from System

Emphasis is on Processing

Process Box Transform Inputs into Outputs Performed by People, Computers...

External / Internal Entity Define Boundary of System Provide Net Inputs and/or Receive

Net Outputs from System

Process

ExternalEntity

10/29

Data Flow Diagram ConventionsData Flow Diagram Conventions

Data Stores - Open-Ended Cabinets, Logs, Files. Data “at rest”

Data Flows Depict Data Flowing Into or Out

of a Process Flowlines Directional Typically Represent Reports,

Documents, Memos, Phone Calls, Retrievals, Letters, ...

Data Stores - Open-Ended Cabinets, Logs, Files. Data “at rest”

Data Flows Depict Data Flowing Into or Out

Flow lines typically labeled. Directional Typically Represent Reports,

Documents, Memos, Phone Calls, Retrievals, Letters, ...

11/29

Mail Bill

Mail Payment

Customer

Withdrawal Entry

Check

CustomerListings:BalancedStatement

CustomerListings:BalancedStatement

BankStmts

CustomerListings:PreviousStatements

WithdrawalEntry

You or your SpouseBalanceCheckbookAccount

You or your SpouseWithdrawCash

Check Register

Mail Bank Statementand Canceled Checks

Bank

You or SpouseDeposit money in to BankAny other

Source ofIncome

Employer

You or SpousePayBill

Paycheck

Other income

Deposit Entry

DepositSlip

Cash Receipt Deposit

CheckbookLog Entries

Simple Physical Data Flow Diagram

12/2912

NO NOS

Common Mechanical Errors

13/29

14

Routing or Forwarding ProcessesRouting or Forwarding Processes

Secretary:RouteMail

Customer

Form 13:Order to be Filled

Mail:Payment Receipt

Interoffice memorandum:Customer Credit

Form: Order

Payment and Payment Card

Letter: Complaint

Phone or letterResponse to Complaint

Mail

CustomerSales

Department

AccountsReceivable

CustomerRelationsManager

14/2915

Common DFD ErrorsCommon DFD Errors

Employee

Asst Mgr:CreateNew MemberAccount

Asst. Mgr:Freeze MemberAccount

Clerk:GenerateEmployeeBankStatements

AccountsReceivableDepartment

Member Acct(file drawer)

Employee (file cabinet)

Mail: End of Month Bank Statements

Form: Credit Union Membership Application

ExistingAccounts

Modified AccountStatus: “frozen”

Letter: Member Account FrozenNotification

EmployeeAccount IDand Address

EmployeeStanding

1

2

3

15/2919

The Value of PhysicalDFDsThe Value of PhysicalDFDs

DFDsForce Analysts toCommunciatetheir Understanding of Systems to End-Users

DFDsRequire Analysts to Examine the Interfaces between Systems, Subsystems, and the Rest of the World

DFDsmodel a System in Physical Terms that are Familiar to End-Users

DFDsForce Analysts toCommunciatetheir Understanding of Systems to End-Users

DFDsRequire Analysts to Examine the Interfaces between Systems, Subsystems, and the Rest of the World

DFDsmodel a System in Physical Terms that are Familiar to End-Users

16/2911

Step 1: Draw Context DFDStep 1: Draw Context DFD

Draw Context DFD to describe system’s relationship to rest of the worldMain inputs & outputsOnly single Process

box and External Entities

Boundaries of systemConfirms project

scope to top level management

All processing detail collapsed into single box

Draw Context DFD to describe system’s relationship to rest of the worldMain inputs & outputsOnly single Process

box and External Entities

Boundaries of systemConfirms project

scope to top level management

All processing detail collapsed into single box

MemberServices

ClubMember

Warehouse MarketingDepartment

Mail: MemberOrder Coupons

Mail: ClubPromotionsand Catalogs

ComputerReport andCatalog: RecordPromotions

Form 40:Order to beFilled

0

Level 0 DFD

17/293

Step 2: The Systems DiagramStep 2: The Systems Diagram

PotentialMember

MarketingDept Club

Member

Warehouse

SubscriptionDept

PromotionDept

OrdersDept

MemberDatabase

Mail:Subscription Cardand Order Form

Current Member Status

Form 40: TranscribedSpecial Order

Member Updates

ComputerReport &Catalog:RecordPromotion

Mail: Club Promotions and Catalogs

Mail: Auto Catalog and Advertising Fliers

Mail: memberOrder Coupons

Form 40:Order tobe filledMember details

Member Updates

1

2

3

Level 1 DFD

18/29

Step 3 – Middle Level – Identification of Transaction Flow

44

-

PotentialMember

ClubMember

ProcessSubscriptionTransaction

ProcessMembership

RenewalTransaction

ProcessMembershipCancellationTransaction

A/RDepartment

Member Database

Form letter: MembershipWelcome or Denial

Mail SubscriptionCard & Order Form

Form 40: Transcribed Special Order

Current Member Status

FormLtr: Notice of Pending Bonus

Mail: MbrshpRenewal Slip

Mail: Renewal WelcomeLtr

FormLtr: MembershipCancellation Confirmation

Mail/Phone: MembershipCancellation (letter)

MemberUpdates

Form 25: OutstandingCredit Notice

Member Updates

1.1

1.2

1.3

Level 2 DFD

19/29

ApplicationNotebook

Past MemberFile Cabinet

dbase IVMember

Form letter: Membership welcome or denial

Mail: Subscription card and order form

Subscription card and order via advertisement

ProcessedApplication

ProcessedApplication

Standing at timeacoount was closed

Special Order Form

Form 40: TranscribedSpecial Order

Existing Member’s bonus order (bottom)

Form ltr:Notice of PendingBonus Prospective Member application and order

New memberdetails

Currentmemberstatus

Screen:CurrentMemberStatus

Subscriptioncard and ordervia referral

PotentialMember

ClubMember

Clerk:TranscribeOrder

1.1.3

A

1.1.5Clerk: Notify Applicant of Status

Mail Clerk:DistributeMail

1.1.1

1.1.6dbase IVprogram:Chk RefrlValidity

1.1.7dbase IV programAdd newmember

1.1.2Subscript

ionclerk:

ApproveApplicant

1.1.4

Clerk:Notify Applicantof Status

G

A

AF

A

F

D

DC

A

E

A

B

Step 4 – Detailed Transaction Description Level 3 DFD

20/29

Decision Logic Tables

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

22/299

Entity Relationship Diagrams (continued)Entity Relationship Diagrams (continued)

ERDs REPRESENT ALL DATA THAT ARE INPUT, STORED, TRANSFORMED, AND

PRODUCED IN A MANNER THAT IS INDEPENDENT OF THE PROCESSING THAT TRANSFORMS THEM...

Manufacturer builds Automobile

cardinality / modality

23/2910

Entity Relationship Diagrams (continued)Entity Relationship Diagrams (continued)

Oftentimes specific attribute values may be shown in tables

|<------------------- ATTRIBUTES (FIELDS / MEMBERS) ---------------- >

E

FORD MUSTANG 1234 2- RED

2345

4455 4-DOOR

PONT 8899 2-DOOR

|<------------------- ATTRIBUTES (FIELDS / MEMBERS) ---------------- >

MAKE MODEL ID# BODY TYPE COLOR REFERENCE E

FORD MUSTANG 1234 2 DOOR RED CAR

Porsche Boxster S 2345 2 DOOR Grey RFR

Mercedes S430 4455 4-DOOR BLACK RFR

FORD RANGER 8899 2-DOOR WHITE RFR

24/29

ERDs Continued. Logical ModelingSometimes shown as Logical Entity

Member

Member_IDMember_Type_NumberMember_First_NameMember_Middle_InitialMember_Last_NameMember_AddressMember_CityMember_StateMember_Zip_CodeMember_Phone_NumberMember_EmailUniversity_ID_Number

Logical Structure may also be shown as logical entities:

25/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)

26/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…

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

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

29/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!