Lecture 2 Advanced Networking CSE 8344 Southern Methodist University Fall 2003 Mark E. Allen.
1 Requirements Engineering Southern Methodist University CSE 7316.
-
Upload
mitchell-thornton -
Category
Documents
-
view
222 -
download
5
Transcript of 1 Requirements Engineering Southern Methodist University CSE 7316.
1
RequirementsRequirements
EngineeringEngineering
Southern Methodist University
CSE 7316
2
The Requirements ProblemThe Requirements Problem
3
AgendaAgenda
Definitions and general concepts Process and product Product properties Requirements management The problem domain
4
What is a requirement?What is a requirement?
A software capability needed by the user to solve a problem to achieve an objective
A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation
5
(IEEE83), ANSI/IEEE Std 729/1983
Definition of RequirementDefinition of Requirement
A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or a system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or component.
6
Davis90
Requirements Analysis is Requirements Analysis is ImportantImportant
Five Hypotheses:The later in the lifecycle an error is found,
the more expensive it is to fix.Many errors are not found until well after
they are made.Many requirements errors are being made.Requirements errors are typically
incorrect facts, omissions, inconsistencies, and ambiguities.
Requirements errors can be detected
7
ANSI/IEEE Std729/1983
Requirements Analysis Requirements Analysis DefinitionDefinition
The process of studying user needs to arrive at a definition of system or software requirements.
The verification of system / software requirements.
8
Requirements Analysis Requirements Analysis DefinitionDefinition
An Iterative process of:
Identifying Analyzing Documenting Verifying (etc.)
Definition of
requiredsystem
behavior
9
Requirements Analysis TaskRequirements Analysis Task
SoftwareRequirements
Document
ConceptualModel
derive
• understandable• modifiable• precise
• build “outside-in” begin with
environment work inward to
the system
10
Environment and SystemEnvironment and SystemEnvironment System
state ofentities in
environment
state ofsystem
activities
events
11
Process and ArtifactsProcess and Artifacts
ContextAnalysis
DesignProcess
Developer- Oriented Software
Requirements Artifact
Customer RequirementsProcess
DeveloperRequirementsProcess
Customer- Oriented SoftwareRequirements Artifact
Brackett89, CE-SPM-01-02-06
Software NeedsArtifact
12
ContextAnalysis
DesignProcess
Developer- Oriented Software
Requirements Artifact
Customer RequirementsProcess
DeveloperRequirementsProcess
Customer- Oriented SoftwareRequirements Artifact
Brackett89, CE-SPM-01-02-06
Software NeedsArtifact
Market Needs
User Needs Document
System Requirements Specification
Statement of Operational Need (SON)
System Operational Requirements Document (SORD)
Concept of Operations
Process and ArtifactsProcess and Artifacts
13
ContextAnalysis
DesignProcess
Developer- Oriented Software
Requirements Artifact
Customer RequirementsProcess
DeveloperRequirementsProcess
Customer- Oriented SoftwareRequirements Artifact
Brackett89, CE-SPM-01-02-06
Software NeedsArtifact
RequirementsRequirements
DefinitionRequirements
DocumentRequirements
SpecificationUse Case ModelFunctional
DescriptionPart 1
specification.
Process and ArtifactsProcess and Artifacts
14
ContextAnalysis
DesignProcess
Developer- Oriented Software
Requirements Artifact
Customer RequirementsProcess
DeveloperRequirementsProcess
Customer- Oriented SoftwareRequirements Artifact
Brackett89, CE-SPM-01-02-06
Software NeedsArtifact
Behavioral Specification
System Specification
Specification Document
Requirements Specification
Functional Specification
Functional Description
Process and ArtifactsProcess and Artifacts
15
GoalsGoals
Process goalkeep the process under our intellectual
control at all times Artifact goal
organize the artifact so that it allows others to comprehend the product to be built
amount of effort should be proportional to the size of the product -- not worse!
16
Weinberg89
An Effective Artifact is An Effective Artifact is the Primary Goalthe Primary Goal
COMMUNICATION Agreement between developer & customer A basis for design A basis for V&V
17
Artifact PurposesArtifact PurposesThe artifact(s) answer these questions
What problem is the system supposed to solve?
What does the customer require from the system?
What does the developer need to know about the system to design it?
The artifact(s) of the requirements analysis process are specifications that the software designer can use
18
Documentation Documentation vs. Specificationsvs. Specifications
"Documents" are all of the materials produced during requirements analysis, e.g. backs of envelopes, data dictionaries, prototypes, etc.
“Specifications” are formal documents that are "contractually" binding in some manner, such as:Basis for acceptance testsBasis for paymentetc.
19
Properties of a "Good" Properties of a "Good" Requirements SpecificationRequirements Specification
Unambiguous Complete Correct Prioritized Verifiable Sufficient for
design
Consistent Modifiable Traceable Traced Useable during
operations & maintenance
20
UnambiguousUnambiguous
Mathematically precise
A matter of agreement
A “contract” between the customer and the developer ...
STst : Symbol -|-> Type
defined = dom st
21
VerifiableVerifiable
Customer and developer must agree on the criteria and on the method for verification.testinginspectionetc.
Every requirement must have verification criteria — or ... it isn’t a requirement ...
22
ContextAnalysis
DesignDocument1. 2.
3.
RequirementsDocument
Test Plans
4.
TraceableTraceable
1. Backward to context analysis 2. Forward to design 3. Within the document 4. To test/verification plans
23
Requirements ManagementRequirements Management
Requirements Management is one of the 6 KPAs needed to go to level 2 (Repeatable) of the CMM.
Requirements are set at the beginning and not changed during the build -- when they change, the current build stops and a new cycle starts.
24
Key Considerations of Key Considerations of Requirements ManagementRequirements Management
Identify functional requirements (e.g. draft user’s manual)
Identify system needs Identify customer expectations -- delivery,
packaging, and support Identify measures of success -- cost,
schedule, and performance Identify validation & acceptance criteria Identify support requirements
25
Managing the ProcessManaging the Process Estimation -- how can one estimate the
scope of the requirements definition effort early?
Effort depends onsize/scope of projectbreadth of sourcesduration of effort
Two common errorstoo much effort (over-specification)too little effort (under-specification)
26
Humphrey89
Why Requirements Why Requirements Management?Management?
Sometimes we get firm requirements, but the law of software perversity states:
“The firmer the requirements; the more likely they are wrong.”
Requirements change as the job progresseswriting the program changes our
perception of the taskcomputer implementation of a human
task changes the task itself
27
Humphrey89
Why Requirements Why Requirements Management? (cont’d)Management? (cont’d)
In large-scale programs, the task of writing a complete statement of requirements is not just difficult – it is practically impossible.customer doesn’t know what is neededstatement of requirements is wrongstatement of requirements will change
Recommendation: establish a link to someone who knows the application and work together until the job is done.
28
Humphrey89
Practical SolutionPractical Solution
Incremental development processgradually increase level of detail as the
requirements and implementation are mutually refined
Start with the minimal requirements that both we and the user “know” are valid ...implementtestuse in trial formplan & develop next increment
29
The requirements problemThe requirements problem
CustomersExternal entity; buy ours instead of
theirs!!Company that has hired us to develop
high quality s/w that will give them a competitive advantage
Tools vendorDefense business
Our company! Something that will make us better!
30
Some Data (Standish)Some Data (Standish)
$250 billion spent on IT for 175,000 projects$2,322,000 for large company$1,331,000 for medium company$434,000 for small company
31% of projects canceled before completion
52.7% will cost an average of 181% of original estimate
31
10%
30%
50%
RequirementsDefinition
SoftwareDesign
Coding Testing Deployment
$ 5
$ 10
Req’tsDefinition
SoftwareDesign
Coding Testing Deployment
Source of Errors - %'s
Communications of the ACM, Jan. '84
Relative Cost to Correct Errors - $1000'sSource: AT&T Bell Labs Estimates
ErrorsErrors You are here.
32
Root causes of Root causes of “challenged” projects“challenged” projects
Lack of user input (13% of all projects) Incomplete requirements and
specifications (12% of projects) Changing requirements and specifications
(12% of projects) Inadequate technology skills (7%) …..
33
Primary success factorsPrimary success factors
User involvement (16% of all successful projects)
Executive management support (14%) Clear statement of requirements (12%)
Two largest problems cited in other surveysRequirements specificationsManaging customer requirements
34
Defect SummaryDefect Summary
Defect origins Defect potential
Removal efficiency
Delivered defects
Requirements 1.00 77% 0.23
Design 1.25 85% 0.19
Coding 1.75 95% 0.09
Documentation 0.60 80% 0.12
Bad fixes 0.40 70% 0.12
Total 5.00 85% 0.75
35
Defect SummaryDefect Summary
Defect origins Defect potential
Removal efficiency
Delivered defects
Requirements 1.00 77% 0.23
Design 1.25 85% 0.19
Coding 1.75 95% 0.09
Documentation 0.60 80% 0.12
Bad fixes 0.40 70% 0.12
Total 5.00 85% 0.75
36
Relative cost to repairRelative cost to repair
.1-.2
.5
1
2
5
20
Stage
Requirements
Design
Coding
Unit test
Acceptance test
Maintenance
37
Fixing a defectFixing a defect
Re-specification Redesign Recoding Retesting Change orders; telling
users and operators to replace
Corrective action; refund checks to angry customers, rerunning a computer job
Scrap; code, design, test cases
Recall of defective versions of shrink wrap and manuals
Warranty costs Product liability;
customers suing for damages
Service costs Documentation
38
Requirements ManagementRequirements Management
A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between customer and the project team on the changing requirements of the system
Requirements management process called for by both CMM and ISO 9000
39
Requirements ManagementRequirements Management
Boeing 777 – 300,000 requirements > 4 million loc 1280 embedded processors
40
Lifecycle modelsLifecycle models
41
Stagewise ModelStagewise ModelSystemRequirements
SoftwareRequirements
Analysis
ProgramDesign
Implementation
Testing
Operations
1970 [Royce]
42
Waterfall Waterfall ModelModelSystem
Requirements
SoftwareRequirements
Analysis
ProgramDesign
Implementation
Testing
Operations
1970 [Royce]
43
Spiral Spiral ModelModel Evaluate
Alternatives;Identify,Resolve Risks
Determine Objectives,Alternatives,Constraints
Develop, VerifyNext-Level Product
PlanNextPhases
CUMULATIVECOST
COMMITMENT
PARTITION
44
Requirements Definition Requirements Definition Overlaps Later PhasesOverlaps Later Phases
Requirements
Definition Design
Generation
Testing
at some arbitrary time ...
45
Evolutionary Delivery Model: Evolutionary Delivery Model: Rational Unified ProcessRational Unified Process
Business Modeling
Requirements
Analysis & Design
Workflows Inception
Elaboration
PhasesConstruction Transition
Implementation
Test
DeploymentConfiguration &
Change Management
Project Management
Environment
Iterations
Initial E # 1 E # 2 C # 1
C # 2
C # n
T #1 T #2
Co
nte
nt
Time
46
Generalized Software Development ProcessGeneralized Software Development Process
S/WRequirements
S/W systest plan
Systemtest
maintain &enhance
PrelimDesign
Integrationtest plan
Integrationtest
DetailDesign
Unittest plan
Unittest
coding
deliverproduct
47
SummarySummary
Definitions and general concepts Process and product Product properties Requirements management The problem domain
48
Analyzing the ProblemAnalyzing the Problem
49
Requirements roundtableRequirements roundtable
http://interactive.sei.cmu.edu/Features/1999/March/Roundtable/Roundtable.mar99.htm
50
The Problem DomainThe Problem Domain
Home of real users and other stakeholdersPeople whose needs must be addressedPeople who need “the rock”
These people are not like us !Different technical and economic
backgroundsSpeak in funny acronymsMotivations that seem strange and
unfathomable
51
The problem domain
52
A moreRealisticProblemdomain
53
““Features”Features”
A service that the system provides to fulfill one or more stakeholder needs
Simple descriptions in the user’s language used as labels to communicate with the user how the system addresses the problem
54
Problem/solution domainsProblem/solution domains
needs
features
Software requirements
Problem domain
solution domain
55
Software as a team activitySoftware as a team activity
“Software development has become a team sport” – Booch 1998
COCOMO – capability of the TEAM has the greatest impact on software productivity
56
Requisite team skills for Requisite team skills for requirements managementrequirements management
Analyzing the problem domain Understanding user needs Defining the system Managing scope Refining system definition Building the right system
We will discuss all of these !!
57
Different SkillsDifferent Skills
Working with customers Software programming Testing Design and architecture abilities Also requirements management
58
Problem AnalysisProblem Analysis
Some applications solve problems Others take advantage of opportunities in
the market (existence of a problem may not be clear)SimCityMyst
Problem analysis; the process of understanding real-world problems and user needs and proposing solutions to meet those needs
59
What is a Problem?What is a Problem?
“A problem can be defined as the difference between things as perceived and things as derived” – Weinberg
Sometimes the simplest solution is a workaround or revised business plan, rather than a new system
Changing the desire or perception may be the most cost effective solution!
60
Problem AnalysisProblem Analysis
The goal of problem analysis is to gain a better understanding of the problem being solved before development beginsGain agreement on the problem definitionUnderstand the root causes – the problem
behind the problemIdentify the stakeholders and the usersDefine the system boundaryIdentify the constraints to be imposed on
the solution
61
1. Gain Agreement on the 1. Gain Agreement on the Problem DefinitionProblem Definition
Write down the problem and see if everyone agreesHave the customer describe the benefits
Seems simple but this step can cause much discussion and emotion
62
Problem Statement FormatProblem Statement Format
Element Description
The problem of Describe the problem
affects Identify stakeholders affected by the problem
the result of which Describe the impact of this problem on stakeholders and business activity
benefits of Indicate the proposed solution and list a few key benefits
63
2. Understand Root Causes2. Understand Root Causes
Gain understanding of real problem and real causes
“Root cause” analysis Total Quality Management techniques Ask people directly involved what the
problems are!
64
Fishbone DiagramFishbone Diagram
Too much scrap
Inaccu
rate
sale
s ord
ers
Dam
aged in
ship
ment
Custo
mer re
turn
s
Fini
shed
goo
ds
Obs
oles
cenc
e
Man
ufac
turing
def
ects
Oth
er
65
Addressing the root causeAddressing the root cause Quality data demonstrates that many root
causes are simply not worth fixing
05
101520253035404550
Inaccuratesales orders
Obsolescence
Contributions
Pareto chart of root causes
Percentage
66
Sales order problem Sales order problem statementstatement
Element Description
The problem of Inaccuracies in sales orders
affects Sales order personnel, customers, manufacturing, shipping, and customer service
the result of which Is increased scrap, excessive handling costs, customer dissatisfaction, and decreased profitability
benefits of A new system to address the problem include;Increased accuracy of sales orders at point of entryImproved reporting of sales data to managementHigher profitability
67
3. Identify the Stakeholders 3. Identify the Stakeholders and the Usersand the Users
Stakeholder; anyone who could be materially affected by the implementation of a new system or application
Many stakeholders are users Others are indirect users
Affected by the business outcomes that the system influences
Non-user stakeholder needs must also be identified and addressed
68
Questions Questions
Who are the users of the system? Who is the customer (economic buyer) for
the system? Who else will be affected by the outputs
that the system produces? Who will evaluate and bless the system
when it is delivered? Who will maintain the system?
69
Users and stakeholders of Users and stakeholders of new systemnew system
Users Other stakeholders
Sales and order entry clerks
MIS director and development team
Sales order supervisor Chief financial officer
Production control Production manager
Billing clerk
70
4. Define the solution 4. Define the solution system boundarysystem boundary
Boundary defines the border between the solution and the real world that surrounds the solution
inputs
system
outputs
71
System boundarySystem boundary
World divided into two partsOur systemThings that interact with our system
72
ActorsActors
Someone or something, outside the system, that interacts with the system
I/O
users
Our solution
Othersystems
I/O
Systemboundary
73
Finding actorsFinding actors
Who will supply, use, or remove information from the system?
Who will operate the system? Who will perform any system
maintenance? Where will the system be used? Where does the system get its
information?
74
System PerspectiveSystem Perspective
SalesOrderclerk
Billingclerk
Shippingclerk
Productionforeman
New salesOrder entry
LegacySystemWithPricingdata
Systemboundary
75
5. Identify the constraints to 5. Identify the constraints to be imposed on the solutionbe imposed on the solution
Constraints are restrictions on the degrees of freedom we have in providing a solution
Various sources of constraintsScheduleROIBudget for labor and equipmentEnvironmental issuesOperating systems and databasesetc
76
ConstraintsConstraints
Constraints may be given to us before we start or we may have to actively elicit them
Should understand the perspective of the constraint
Should understand when the constraint no longer applies to the solution
The less constrained the better!
77
Potential system Potential system constraintsconstraints
Source Sample considerations
Economic What financial or budgetary constraints are applicable?Are there costs of goods sold or any product pricing considerations?Are there any licensing issues?
Political Are there any internal or external political issues that affect potential solutions?Interdepartmental issues?
Technical Are we restricted in the choice of technologies?Are we constrained to work with existing platforms or technologies?Are we prohibited from any new technologies?Are we to use any purchased software packages?
78
Potential system Potential system constraintsconstraints
Source Sample considerations
System Is the solution to be built on our existing systems?Must we maintain compatibility with existing solutions?What operating systems and environments must be supported?
Environmental Are there environmental or regulatory constraints?Legal?Security requirements?
Schedule and resources Is the schedule defined?Are we restricted to existing resources?Can we use outside labor?Can we expand resources?
79
Summary – 5 steps of Summary – 5 steps of problem analysisproblem analysis
Gain agreement on the problem definition Understand root causes Identify stakeholders and users Identify the system boundary Identify the constraints on the system
80
Constraints Constraints
Purpose of the product Client, customer, other stakeholders Users of the product Requirements constraints Naming conventions and definitions Relevant facts Assumptions
81
Project issuesProject issues
Open issues Off the shelf solutions (COTS) New problems Tasks Cutover Risks Costs User documentation Waiting room
82
Problem Solving Problem Solving
83
Problem Solving
• Course not about programming
• Mainly about how to define a problem for people to solve by programming a computer– must provide all the information that
programmers and interface designers need to make a computer bring about effects outside the computer
• This complete statement of the problem is called requirements
84
Problem SolvingProblem Solving
Writing software requirements is a form of communication between people
All lot of stakeholders involvedpeople who desire effects from the
softwarepeople who want to perform some taskpeople who design the machine behaviorpeople who configure (program) the
machines
85
Pick up cargos
Haul cargos todestinations
Print reports
interfaces
Database schemas
subroutines
Linked lists
R S
Not programmingInterface design
documents
86
IntroductionIntroduction
Goal of any kind of engineering is to give people ability to do something they currently can’t do
Task of the engineer is to build the device To write a useful requirements document
we must understand what engineers to in order to produce a design that meets the requirements
87
EngineeringEngineering
Engineering is essentially bridging the gap between requirements and available materialsaeronautical; materials for flightsoftware engineer; configuring a
computer to perform tasks related to information, transmitting information and causing objects to behave in accordance with specified rules
88
Materials of a Software Materials of a Software EngineerEngineer
Materials are intangibleinstructions that a computer is capable
of executingsubroutine librarieshigh level programming languages
Bridging the requirements/materials gap is not easysponge for cleaning easy to seedishwasher took many years
89
Bridging the GapBridging the Gap
Once somebody figures out how to bridge the gap successfully, the design can be repeated and slightly verified to solve new problems
90
How to bridge the gapHow to bridge the gap Many theories on how to bridge the gap Functional decomposition
top-down designstepwise decomposition
Stepsengineer identifies function of the system
to be builtif function maps directly to available parts,
allocate function to those parts -> done
91
Functional DecompositionFunctional Decomposition
otherwise divide the function into subfunction and repeat steps 2 and 3 until every subfunction is small enough to map onto the smallest parts of the design
Divide and conquer approach Problem is that there are many different
ways to divide a high level function into subfunctions and there is no way to tell if these divisions are good until into lowest levels of design
92
Problem solving and design Problem solving and design patternspatterns
Exhaustive list of all problem solving techniques (order of decreasing effectiveness)Already knowing the solutionAlready knowing the solution to a
similar problemAll other techniques
93
Problem solving and design Problem solving and design patternspatterns
As engineers we are not interested in giving problems a sporting chance
Engineering problems are so different from each other that few of the ideas or knowledge that enable you to solve one problem will help you solve a problem from a different field
Completely generalized ideas are too unfocused
94
How engineering really How engineering really worksworks
Engineers apply and slightly vary already existing, time-tested designs
Engineers engage in unstructured exploration of new designs and new ways to put old designs together
Both types can occur on the same project
95
Design PatternsDesign Patterns
Despite the importance of standard designs in all engineering fields, it has mostly been left implicit
People learn standard designs for bridges, D.C. generators, brakes, etc
What they do not learn is that standard designs separates professional engineering from tinkering
96
Design PatternsDesign Patterns
In software this standard design has become to be know as a design pattern
The word pattern emphasizes that the design can be applied a million times over without ever doing it the same way twicea brick pattern varies little from
application to applicationa suspension bridge pattern is a more
flexible idea that requires additional intelligence and imagination to apply
97
Design PatternsDesign Patterns
Patterns were applied by Christopher Alexander in town planning and architecture
Patterns found in towns and buildingsstreet café is a patterncorner grocery is a patterndormer window
Rich vocabulary of words allows you to write well - rich vocabulary of design patterns allows us to design well
98
Design PatternsDesign Patterns
A pattern is not a reusable componenta component is a physical object
two different instances are identical - both are instances of the same design
a pattern is a reusable idea - no two instances are quite the same
The application of patterns is called design or engineering; the creation of new instances is called manufacturing
99
Why Software is HardWhy Software is Hard
Early in the history of an engineering field, practices tend to be unstructured exploration instead of application of time-tested ideas
This is natural - in the early days there are fewer time-tested ideas
In the early days there is emphasis on innovation - the field does not produce reliable results
Many untested ideas which often fail
100
Why Software is HardWhy Software is Hard
Mature engineering fieldsengineers spend most of their time
combining and making slight variations to time-tested ideas
Solve problems from a well defined set of problems
building a transformer this is a standard design in electrical
engineeringingenuity still required to solve unexpected
problems
101
Why Software is HardWhy Software is Hard
Invention of entirely new designs still continuesspace shuttle tiles
A large vocabulary of time tested ideas makes for a systematic and reliable engineering disciplinevery few homes collapse from their own
weightfew transformers fail to meet
specification
102
Why Software is HardWhy Software is Hard
Orderly engineering; application and slight variation of time-tested design patterns
Exploratory engineering; unstructured exploration of new kinds of designs
Major reason software projects fail is because there is still a large gap between the system that the customer wants delivered and the available time-tested designs
103
Pattern Composition and Pattern Composition and DecompositionDecomposition
Patterns in software engineeringsortingsearchingmany types of data structuresparsingrendering 3-D images
Allow experienced programmers to make design decisions at a higher level than program code
104
Pattern Composition and Pattern Composition and DecompositionDecomposition
Pattern decomposition; recognizing a pattern that is built from smaller patterns
Difference from function decomposition is that the patterns have been put together before
Function composition is what led the Wright brothers to succeed where others failed
105
Pattern Composition and Pattern Composition and DecompositionDecomposition
Structure of birds versus decomposing flight into its subfunctions
Each subfunction then implemented by further decomposition
But is this what they really did .. ?
106
Functional decompositionFunctional decomposition of Wright brothers airplane of Wright brothers airplane
Subfunction Implementation
Forward propulsion
Four cylinder engine, propellers
Lift Wings
Steering Rudder, bendable wingtips
107
Functional decomposition Functional decomposition of Wright brothers airplaneof Wright brothers airplane
Subfunction Implementation
Up/down propulsion ?
East/west propulsion ?
North/south propulsion
?
108
Pattern Composition and Pattern Composition and DecompositionDecomposition
Wright brothers used wings, an engine, a propeller, rudder was because they had those thingsnobody had components that
implemented up/down propulsion, east/west propulsion, etc
despite mathematical elegance, nobody does this!
If internal combustion engine did not exist, they would not have deduced one!
109
Pattern DecompositionPattern Decomposition
Most of the design came from imitation;idea of wings came from birdssteering mechanism from observing the
way birds bend their wings to change direction
engine designed to meet own needs Town planner wants to build a bridge to go
across the bay gives requirements to the engineer who then decomposes the problems into patterns (girders, etc)
110
Pattern Composition and Pattern Composition and DecompositionDecomposition
Exploratory engineering works the other way aroundcomposing patternsbuild a solution in search of a problemearly computers went this way
we’re still a long way from determining everything we can do with a computer
In orderly engineering pattern decomposition is the rule
111
Pattern Composition and Pattern Composition and DecompositionDecomposition
Architecture-driven project; starts with an implementation idea and looks for ways to extend it that provide new and unanticipated benefits to the customer
Requirements-driven project; starts with well-defined benefits and draws upon existing, proven implementation ideas