Distinguishing Analysis from Design

©2007 S. Frezza 1

Walking the Line:On Distinguishing

Requirements Analysis and System Design

Stephen T. Frezza, Ph.D., C.S.D.P.

Erie, Pennsylvania

©2007 S. Frezza 2

What is at issue ?What is at issue ?What distinguishes a requirements model…

… from a design model?Where does requirements work end…

…and design work begin?

Are these distinctions meaningful in practice?

©2007 S. Frezza 3

Software Development:Software Development:

Using a uniform modeling approach throughout the life-cycle is usually sound and reasonable.

1 2 3 4 5

1. Yes

2. No

3. Unsure

©2007 S. Frezza 4

Development MethodologiesDevelopment Methodologies

THEN:Waterfall: Requirements as a phase - distinct from designSpiral: Requirements as iterative activity – distinct from

design

NOW:Agile: Requirements activities embedded, integral to

development. No emphasis on distinction

AreAre

Requirements Activities Requirements Activities distinguished fromdistinguished from

Design Activities ?Design Activities ?

©2007 S. Frezza 5

Distinctive ApproachesDistinctive Approaches

SynthesisAnalysis models domain; Design specifies organizationAnalysis models evolve into design modelsTransitions are smooth – adding design classes (software

structure)

DistinctionAnalysis is about human activity – the problem domain

E.g., {person, model of person}Design represents information about the activity

E.g., {person, model of person, software (person object) }

Uniform Modeling ApproachUniform Modeling Approach

Distinctive Modeling ApproachDistinctive Modeling Approach

©2007 S. Frezza 6

Synthesis ApproachSynthesis Approach

ICONIX:Think about the problem domainIdentify classes that belong to the domainLook for reusable abstractions (classes) that participate in

multiple scenariosThink about how required system behavior gets allocated

to the identified abstractions

Uniform Modeling ApproachUniform Modeling Approach

©2007 S. Frezza 7

Uniform Modeling ViewUniform Modeling ViewAnalysis:

The object model is software structure Analysis classes package data & behavior Detail added to transition into design Good models bridge distinct analyst/designer cultures

Design:Specifies software organization

Analysis and Design are a continuumAnalysis and Design are a continuum

Transitioning is continuous – not an issueTransitioning is continuous – not an issue

©2007 S. Frezza 8

Distinctive Modeling ViewDistinctive Modeling ViewAnalysis:

Model human activity, existing systemsCapture architectural qualities needed in a system

Design:Model the abstract machine to solve the problemEmbody compromises among multiple viewpoints to one

point in the solution space

Analysis and Design are different kinds of workAnalysis and Design are different kinds of work

Transitioning is distinctive, requires planningTransitioning is distinctive, requires planning

©2007 S. Frezza 9

Ad HominemAd Hominem

SynthesisKarl Frank - TogethersoftIvar Jacobsen – RationalStephen Mellor – Project Technology, Inc.

DistinctiveHermann Kaindl – Seimens AGJoaquin Miller - MITRE

©2007 S. Frezza 10

Hominem - ContinuedHominem - Continued

Edsger DijkstraThe purpose of the specification: to act as an interface

between the system’s users and the system’s builders.

The task of ‘making a thing satisfying our needs’ as a single responsibility is split into two parts: ‘stating the properties of a thing, by virtue of which it would

satisfy our needs’ and ‘making a thing guaranteed to have the stated properties.’

Business data processing systems are sufficiently complicated to require such a separation of concerns.

©2007 S. Frezza 11



1 2 3 4 5

1. Yes

2. No

3. Unsure

©2007 S. Frezza 12





Is there a line, or not?Is there a line, or not?

©2007 S. Frezza 13

Primer on RequirementsPrimer on Requirements

Requirements Requirements Capability that the system must deliverStatement of system need or constraint

©2007 S. Frezza 14

Problems vs. RequirementsProblems vs. Requirements

Problems?Problems?Problems don’t have requirements…Proposed systems have requirements…

Systems?Systems?Systems don’t have problems…People have problems…

Is that a bug or a feature?Is that a bug or a feature?

©2007 S. Frezza 15

Requirements ManagementRequirements ManagementSystematic approach to

Eliciting, Analyzing, Documenting the requirements of a system

Negotiation/ Agreement

Documentation

Analysis

Start?

End

Elicitation

Process to Establish and maintain

agreement on the changing requirements

©2007 S. Frezza 16

What is What is ““A ProblemA Problem”” ? ?

Difference between:

things as things as perceivedperceived and

things as things as desireddesired.

RM is about the problem: Propose ‘systems’ to solve the problem

Use ‘proposed systems’ to identify requirements

©2007 S. Frezza 17

Empirical Case for RMEmpirical Case for RM

RequirementsRequirements Largest number of delivered defects into final systemLikely to be the most common class of errorMost expensive error to fix, if not found during

requirements phase(s)

Yet… well managed requirements areYet… well managed requirements areLargest single contributor to project success

©2007 S. Frezza 18

Requirements SpecificationsRequirements Specifications

EnvironmentEnvironment

ProblemProblem Lives Lives

Here…Here…MachineMachine

Specification Specification defines the defines the

sharedshared phenomenaphenomena

©2007 S. Frezza 19

Under constrainedUnder constrained

Good Enough

Goal of RequirementsGoal of Requirements

Unacceptable Solution

Acceptable Solution

Over constrainedOver constrained

Divide the world into two sets:

©2007 S. Frezza 20

Pitfalls to RMPitfalls to RMElicitation:

Wrong peopleWrong attitude

Agreement:MisunderstandingExpectation mismatch

Documentation:IncompleteInconsistentConstraining

Analysis:UnfocusedIneffectual

©2007 S. Frezza 22

Requirements ModelsRequirements ModelsDescriptiveAnalysis activity

Results in documentation Supports negotiation & agreement

Goals:…identify known design constraints…more precise definition…change support…communicate system vision

ToolsTools

MethodMethod

NotationNotation

©2007 S. Frezza 23

Problems with Uniform Problems with Uniform ApproachApproach

Nature of Requirements: WhatWhatSystem feature or capability … needed to solve a problem

Nature of Design: HowHowImplementation: …needed for complete solution

Discrepancies:Req. Models: Design Models:

Ask TellExplore Assert

Complete Efficient External Internal

©2007 S. Frezza 24

Requirements Models vs. Requirements Models vs. Design ModelsDesign Models

Similarities:Similarities:Notations

UML very commonDFDsFFBDs

Overlapping audiencesRequirements models

include development team Design models exclude

others

DifferencesDifferencesPurpose

Analysis/agreement on whatwhatBlueprint for howhow

IntentPurposely ambiguousDecisions on how to proceed;

InvestmentLittle as possibleArchitect for quality

©2007 S. Frezza 25

Sample Use Case DiagramSample Use Case Diagram

Faculty Schedule Approval System

Update Schedule

Faculty

Approve Schedule

Dean

Manage Site

AdminDatatel

©2007 S. Frezza 26

Sample Domain ModelSample Domain Model

What value does this model provide ?

+getClassSchedule(faculty)()

Official class schedule

-instructor name-section id-section name-course title-course id-days-times-room

+getFacultyScheduleInformation(semester schedule)()

Faculty Schedule Information

-instructor name-section id-section name-course title-course id-days-time-room

1...*1

Section

-section id-section name-program director name

Courses

-course id-course title-teaching credits-student credits

1...*1 Session

-day-start time-end time-room

Laboratory CoursesCo-taught Courses NS Courses NU CoursesCross-listed Courses

1...*

1+enterOfficeHours(faculty schedule)()

Office Hour

-instructor name

Entering Faculty Office Hours

Sessio

-day-start time-end time-room

+enterOff-campusHours(faculty schedule)()

Off-campus Hours

-instructor name

Entering Faculty Off-campus Hours

Session

-location-phone

Fig: Class diagram for “Faculty Scheduling System”

©2007 S. Frezza 27

Sample Robustness ModelSample Robustness ModelManage SiteManage Site use case – AGILIX-style

Admin Archive

Upload from Datatel

Datatel

ExplorationExploration: Is it…: Is it…Necessary? Complete?Necessary? Complete?

AssertionAssertion: Is it…: Is it…The best way? Most efficient? The best way? Most efficient?

©2007 S. Frezza 28



1 2 3 4 5

1. Yes

2. No

3. Unsure

©2007 S. Frezza 29





©2007 S. Frezza 30

Walking the LineWalking the LineUniform Modeling Approach

Analysis models seamlessly evolve into implementation models

No line… No issue..Distinctive Modeling Approach

Early modeling: understanding of problem/needsLate modeling: architecture/design of implementationCrossing the line is

Intentional – move from what to how Affects requirements change

Ignoring the line increases project risk

©2007 S. Frezza 31

Using the LineUsing the LineUniform Modeling Approach

We’re always thinking about, modeling for implementationDistinctive Modeling Approach

Some modeling is for analysis onlyCross when enough agreement reachedSave ‘analysis’ models; distinguish from ‘design’ models

Caution: Mixing analysis w/ design riskyCommon activity when requirements change

©2007 S. Frezza 32

Agile LinesAgile LinesAnalysis models used for:

Architecting, release planningThe big pictureSeparate from user stories and detailed modelsSource for user stories and detailed models

Design models capture:Capture architectural decisionsKey, cross-cutting design decisions

©2007 S. Frezza 33

Walking the LineWalking the LineIntentIntent distinguishes requirements models from

design modelsAssertionsAssertions determine when design work begins

Requirements work ends when we stop adding new features

MeaningfulMeaningful distinctions exist between analysis and design modeling Greater requirements risk more usefulLess requirements risk less useful