Your SlideShare is downloading. ×
Business requirements what versus how
Business requirements what versus how
Business requirements what versus how
Business requirements what versus how
Business requirements what versus how
Business requirements what versus how
Business requirements what versus how
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Business requirements what versus how

875

Published on

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.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
875
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
56
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Copyright (c) 2012 Pragmatic CohesionConsulting1Why Should Business RequirementsFocus on the System BoundaryMaking your Customers’ Needs the TRUE focus of your IT Projects.
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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/

×