Business requirements what versus how
Upcoming SlideShare
Loading in...5

Business requirements what versus how



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.

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.



Total Views
Views on SlideShare
Embed Views



3 Embeds 30 22 7 1


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Business requirements what versus how Business requirements what versus how Presentation Transcript

  • 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.