The benefits of phrasing Business Requirements in such a way that they only specify what is expected of a given system rather than how the system will be designed to meet its aim or mission.

1. Copyright (c) 2012 Pragmatic Cohesion
Consulting
1
Why Should Business Requirements
Focus on the System Boundary
Making your Customers’ Needs the TRUE focus of your IT Projects.

2. Why should Business Requirements only specify
What a system must do?
• The upmost concern of Business Requirements is to properly identify
users’ needs that can be fulfilled by a system’s services or products.
• Business Requirements therefore should squarely describe the
characteristics of a system in direct relation to their ability to fulfill clearly
identified user needs.
• Business Requirements too often describe the functionality of a system
while crossing into the realm of the system design solution.
• An important drawback of phrasing Business Requirements in such a way
is the loss of focus on properly characterizing the customer needs.
• Another side effect is to prematurely constrain the design solution space
by favoring an alternative over another without first establishing clear and
logical justifications for it.
• A way of dealing with the last point during Business Requirements
gathering is to capture and categorize as such all design specification
considerations and revisit them later during the system design phase.
Copyright (c) 2012 Pragmatic Cohesion
Consulting
2

3. System Users only care about the system Inputs and
Outputs and how well they fulfill their needs.
• System Users are consumers of a system’s services or
products; they provide inputs to the system and
receive outputs from it.
• System inputs and outputs become valuable (useful)
to a User only if they fulfill their needs within specific
service/product consumption scenarios.
• System Inputs and Outputs can take the shape of:
information, matter , or energy.
Copyright (c) 2012 Pragmatic Cohesion
Consulting
3

4. System’s Inputs and Outputs define the system
Boundary: its Contract.
• The boundary of a system is defined in a conceptual manner
by the interactions that it has with external systems and users.
• A Contract defines the responsibility of a system regarding its
environment; since interactions are either Inputs or Outputs
they define the System boundary: its Contract.
• The system then can be viewed as being responsible for
accepting Inputs from its external systems and users and
providing outputs back to them.
• The Quality of Inputs and Outputs contributes to making the
system Contract robust. Input/Output Quality examples are:
accuracy, correctness, confidence, error rate, security,
intensity, size, throughput, velocity, response time, update
frequency, availability, etc…
Copyright (c) 2012 Pragmatic Cohesion
Consulting
4

5. Design Specifications describe what’s inside a
system Boundary.
• Any specification describing or addressing the
inside of a system Boundary crosses into the
realm of system design specifications
• Such specification no longer focuses on the
system Contract/Boundary and its
responsibility to the external environment
(users and external systems) and consequently
falls out of scope of system Business
Requirements.
Copyright (c) 2012 Pragmatic Cohesion
Consulting
5

6. Business Requirements specify a System
contract for acceptable design solutions.
• Identifying and specifying the system Inputs and
Outputs delineates its Boundary: a Contract for
the system to its Users.
• Describing the internal mechanics of a system is
specifying the system design solution.
• Focusing squarely on specifying the System
boundary, not only enables freedom in the design
solution space but also provides robust
evaluation criteria of alternative design solutions.
Copyright (c) 2012 Pragmatic Cohesion
Consulting
6

7. What Vs How: The Coca Cola
Happiness Factory Movie
Copyright (c) 2012 Pragmatic Cohesion
Consulting
7
Check out this video!
Contact Didier at Pragmatic Cohesion Consulting to learn more
about making your Customers’ Needs the TRUE focus of your IT
Projects.
http://pragmaticohesion.com/