Requirements Management with Product Models

1
Requirements Management with Product Models

• Arto Kiviniemi Martin Fischer
• VTT CIFE, Stanford University

2
Problem Description

• Lack of requirement management through the design
  and construction process is a problem, which
  causes uncontrollability and unwanted results in
  the process.
• Requirements are not properties of physical
  elements, but another abstraction level
• Users dont need X m2 meeting room, they need
  meeting room for Y people
• Relationships between requirements and
  design/construction solutions can be also complex
  with many-to-many connections.
• For example Room conditions vs. technical
  systems and bounding elements.

3
Current Process

• Changes are often based on the previous solution,
  not on the actual requirements.
• Because of amount of information, nobody can
  learn all the requirements, neither revisit all
  the documentation in every change
• Process is long, people in it also change, and
  transfer of tacit knowledge is very difficult
• Thus the end result can significantly differ from
  the real needs of the customer without any
  conscious decisions related to the impact of the
  changes.

4
Worst Case Scenario
Goal
Clients requirements
Initial solution
Change 1
Change 2
Change 3
Change 4
Change 5
End result
5
Proposal

• Functional requirements should be linked to the
  physical objects in product models (spaces,
  building elements and technical systems) with
  flexible connections.
• These links could improve controllability and
  quality of the process, and thus support decision
  making significantly.

6
Goal

• The goal of the project is
• to develop a theoretical model for the systematic
  management of structured requirements in all
  parts of the value network in the AEC/FM
  industry, and
• to develop and test mechanisms to attach the
  requirements to the physical design and
  construction solutions.
• Main focus area is in the design phase.

7
Model Layers
Briefing
Design
Construction
Facility Management
Sequential process view
Although processes are partly concurrent or
parallel, the intensity of the activities varies
substantially in different stages
8
Adjusting either design solutions...
Goal
End result
Clients requirements
Initial solution
Change 1
9
...or requirements?
Original goal
Clients requirements
Initial solution
Change 1
Usually both, but in any case Informed and
managed process leading to solutions matching
with the requirements.
Change 3
Change 5
End result
10
Requirement levels

• There are (at least) two requirement levels
• Primary requirements set by the client, like
• Capacity of the space (X people, Y meters of
  bookshelf)
• Properties of the space (temperature, sound
  level), or building element (mechanical or
  chemical resistance, colour)
• Secondary requirements derived from primary
  level, but not managed by client, like
• Area of the room
• Properties of the bounding elements and technical
  solutions, material selections

11
Domain of the Research

• Domain of the research is 'user requirements for
  buildings for knowledge workers'.
• The following issues are not in the scope of the
  research
• Financial issues and cost implications,
• Prediction of building performance and actual
  simulations,
• Post occupancy evaluation, and
• Tradeoffs between requirements.

12
Thank you