Copyright (c) 2012 Pragmatic CohesionConsulting1Why Should Business RequirementsFocus on the System BoundaryMaking your Customers’ Needs the TRUE focus of your IT Projects.
Why should Business Requirements only specifyWhat a system must do?• The upmost concern of Business Requirements is to properly identifyusers’ needs that can be fulfilled by a system’s services or products.• Business Requirements therefore should squarely describe thecharacteristics of a system in direct relation to their ability to fulfill clearlyidentified user needs.• Business Requirements too often describe the functionality of a systemwhile crossing into the realm of the system design solution.• An important drawback of phrasing Business Requirements in such a wayis the loss of focus on properly characterizing the customer needs.• Another side effect is to prematurely constrain the design solution spaceby favoring an alternative over another without first establishing clear andlogical justifications for it.• A way of dealing with the last point during Business Requirementsgathering is to capture and categorize as such all design specificationconsiderations and revisit them later during the system design phase.Copyright (c) 2012 Pragmatic CohesionConsulting2
System Users only care about the system Inputs andOutputs and how well they fulfill their needs.• System Users are consumers of a system’s services orproducts; they provide inputs to the system andreceive outputs from it.• System inputs and outputs become valuable (useful)to a User only if they fulfill their needs within specificservice/product consumption scenarios.• System Inputs and Outputs can take the shape of:information, matter , or energy.Copyright (c) 2012 Pragmatic CohesionConsulting3
System’s Inputs and Outputs define the systemBoundary: its Contract.• The boundary of a system is defined in a conceptual mannerby the interactions that it has with external systems and users.• A Contract defines the responsibility of a system regarding itsenvironment; since interactions are either Inputs or Outputsthey define the System boundary: its Contract.• The system then can be viewed as being responsible foraccepting Inputs from its external systems and users andproviding outputs back to them.• The Quality of Inputs and Outputs contributes to making thesystem Contract robust. Input/Output Quality examples are:accuracy, correctness, confidence, error rate, security,intensity, size, throughput, velocity, response time, updatefrequency, availability, etc…Copyright (c) 2012 Pragmatic CohesionConsulting4
Design Specifications describe what’s inside asystem Boundary.• Any specification describing or addressing theinside of a system Boundary crosses into therealm of system design specifications• Such specification no longer focuses on thesystem Contract/Boundary and itsresponsibility to the external environment(users and external systems) and consequentlyfalls out of scope of system BusinessRequirements.Copyright (c) 2012 Pragmatic CohesionConsulting5
Business Requirements specify a Systemcontract for acceptable design solutions.• Identifying and specifying the system Inputs andOutputs delineates its Boundary: a Contract forthe system to its Users.• Describing the internal mechanics of a system isspecifying the system design solution.• Focusing squarely on specifying the Systemboundary, not only enables freedom in the designsolution space but also provides robustevaluation criteria of alternative design solutions.Copyright (c) 2012 Pragmatic CohesionConsulting6
What Vs How: The Coca ColaHappiness Factory MovieCopyright (c) 2012 Pragmatic CohesionConsulting7Check out this video!Contact Didier at Pragmatic Cohesion Consulting to learn moreabout making your Customers’ Needs the TRUE focus of your ITProjects.http://pragmaticohesion.com/