distinguishing analysis from design
DESCRIPTION
Discusses finding the line between software requirements and software design, predominantly from a modeling perspective.TRANSCRIPT
©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
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 12
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?
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
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 29
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 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