The following is a brief introduction of a model for Effective Requirements Elicitation, Analysis and
Communication being ...
Abstract – for your consideration
Business Analysts should not elicit requirements
Requirements should be formed into S.M....
Presentation Objectives
Establish a focal-point for a requirement discussion
Understand that each focal-point will have mu...
Requirements as Seen by the
BABOK®
Business

Stakeholder
Solution
Transition

Let’s consider this
This model is still vali...
It’s a Matter of Perspective
Thinking outside the box is a fallacious statement
Finding the right box to think inside of i...
Characteristics of Excellent Requirements

How to build a requirement

Focus

f

2014-01-10

Perspective

Pn

Depth

r

St...
Characteristics of Excellent Requirements

Where do I focus my attention?
Rules
May be
Internal or
External

Focus
Policie...
Characteristics of Excellent Requirements

Where do I focus my attention?
Rules
May be
Internal or
External

Focus
Policie...
Characteristics of Excellent Requirements

Where do I focus my attention?
Rules
May be
Internal or
External

Focus
Policie...
Characteristics of Excellent Requirements

Where do I focus my attention?
Rules
May be
Internal or
External

Focus
Policie...
Focal Point Example – Policy
Endorsement
Recognize

Relate to

Must have
Business Rule
Statement

Are based on
Is the basi...
Characteristics of Excellent Requirements

What makes up a solution?
Characteristics

Behaviors

Drive and Constrain Speci...
Characteristics of Excellent Requirements

What makes up a solution?
Characteristics

Behaviors

Support

Specifications

...
Characteristics of Excellent Requirements

How do I put things into perspective?
Security

Information

Process

2014-01-1...
Perspective
Processes

Business processes, workflow, processes and workflow metadata, events, transactions,
exceptions, bu...
Characteristics of Excellent Requirements

Bringing depth to perspective
Processes

Information

Security

Systems

Infras...
Depth
Context

Concept

A strata of requirements that describes how A strata of requirements that describes how
a particul...
Putting Perspective into Perspective
Assuming you would only examine two focal points at one time there are 66 possible fo...
C O MMENT S AN D Q U EST IO N S M AY BE D IR EC T ED TO :
PER RYJ MC LEOD@ICL OUD .COM | L IN KED IN /PER RYMC LEOD
F O R ...
Upcoming SlideShare
Loading in …5
×

How to build a requirement

515 views

Published on

This short presentation briefly describes how to effectively elicit, analyze, communicate and manage requirements from the business all the way down to the system level. Currently under development by Perry McLeod, CBAP, PMP it argues that requirements must be examined in focus, perspective and depth. Perry welcomes any feedback you may have which will help to develop this model for publication to the business analysis community.

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

  • Be the first to like this

No Downloads
Views
Total views
515
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • An alternative view of the nature of requirementsBusiness analysts should not elicit requirements.Requirements should be formed into S.M.A.R.T declarative statements using the wants, desires, problems, issues, threats, opportunities, constraints and the like that the BA discovers throughout the entire engagement processTo accomplish this, the analyst must examine information within a given subject domain at various focal-points, perspectives and depths
  • Each of the five basic perspectives may be broken down into specific processes, information systems and the likeEach perspective may be examined alone or as a binomial coefficient where p is the number of different perspectives to choose from, and r is the number chosenMore perspective may be added, as needed
  • How to build a requirement

    1. 1. The following is a brief introduction of a model for Effective Requirements Elicitation, Analysis and Communication being developed by Perry J. McLeod, business analyst, educator and thought leader. Requirements for the New Business Analyst A M U LT I - D I M E N S I O N A L V I E W O F R E Q U I R E M E N T S | P R E S E N T E D B Y P E R RY MCLEOD S P O N S O R E D B Y: W W W. T H E N E W B U S I N E S S A N A LY S T. C O M | A P J M C O M PA N Y I I B A T O R O N T O C H A P T E R J U N E 1 9 TH, 2 0 1 3
    2. 2. Abstract – for your consideration Business Analysts should not elicit requirements Requirements should be formed into S.M.A.R.T declarative statements using the wants, desires, problems, issues, threats, opportunities, constraints and the like that the BA discovers throughout the entire engagement process Requirements are therefore reasonably induced from the discoveries mentioned above To accomplish this, the analyst must examine information within a given problem domain at various focal-points, perspectives and depths
    3. 3. Presentation Objectives Establish a focal-point for a requirement discussion Understand that each focal-point will have multiple perspectives of understanding Express an understanding that each perspective has multiple depths of analysis
    4. 4. Requirements as Seen by the BABOK® Business Stakeholder Solution Transition Let’s consider this This model is still valid model as an area of but its missing focus – each layer is a perspective and depth focal-point • Functional • Non-Functional
    5. 5. It’s a Matter of Perspective Thinking outside the box is a fallacious statement Finding the right box to think inside of is our first step That box is our knowledge domain or subject area That subject may be viewed in different perspectives Each perspective may be viewed independently or in combination Each combined or independent perspective may be analyzed at multiple strata or depth As each depth is analyzed, specific requirements come into focus
    6. 6. Characteristics of Excellent Requirements How to build a requirement Focus f 2014-01-10 Perspective Pn Depth r Stated Requirement d ©2014 PJM LIMITED. ALL RIGHTS RESERVED 6
    7. 7. Characteristics of Excellent Requirements Where do I focus my attention? Rules May be Internal or External Focus Policies Stakeholders Focus Focus Organization Focus 2014-01-10 May be Internal or External Drive and Constrain Transition ©2014 PJM LIMITED. ALL RIGHTS RESERVED Solution Focus 7
    8. 8. Characteristics of Excellent Requirements Where do I focus my attention? Rules May be Internal or External Focus Policies Stakeholders Focus Focus Organization Focus 2014-01-10 May be Internal or External Support Transition ©2014 PJM LIMITED. ALL RIGHTS RESERVED Solution Focus 8
    9. 9. Characteristics of Excellent Requirements Where do I focus my attention? Rules May be Internal or External Focus Policies Stakeholders Focus Focus Organization Focus 2014-01-10 May be Internal or External Drive and Constrain Transition ©2014 PJM LIMITED. ALL RIGHTS RESERVED Solution Focus 9
    10. 10. Characteristics of Excellent Requirements Where do I focus my attention? Rules May be Internal or External Focus Policies Stakeholders Focus Focus Organization Focus 2014-01-10 May be Internal or External Support Transition ©2014 PJM LIMITED. ALL RIGHTS RESERVED Solution Focus 10
    11. 11. Focal Point Example – Policy Endorsement Recognize Relate to Must have Business Rule Statement Are based on Is the basis for Is a Group Policy Is a Are grouped by Business Rule Is a Process Internal Is a Information External
    12. 12. Characteristics of Excellent Requirements What makes up a solution? Characteristics Behaviors Drive and Constrain Specifications Solution 2014-01-10 ©2014 PJM LIMITED. ALL RIGHTS RESERVED 12
    13. 13. Characteristics of Excellent Requirements What makes up a solution? Characteristics Behaviors Support Specifications Solution 2014-01-10 ©2014 PJM LIMITED. ALL RIGHTS RESERVED 13
    14. 14. Characteristics of Excellent Requirements How do I put things into perspective? Security Information Process 2014-01-10 Systems Permutated ©2014 PJM LIMITED. ALL RIGHTS RESERVED Infrastructure 14
    15. 15. Perspective Processes Business processes, workflow, processes and workflow metadata, events, transactions, exceptions, business objects, states, transitions, business process taxonomy, endorsements, standards, policies, rule statements, business rules, and business roles. Information Business data, attributes, relationships, metadata, data flow, data transformation, and business data taxonomy. Services Data exchange, data management, security, remote access, locations directory, file management, graphics, imaging, operating systems, software engineering, network interfaces, network protocols, user interfaces, software localization, transaction processing, systems and network management. Systems Applications, modules, interfaces, and databases, UDA and COTS. Network devices, storage area network (SAN), network-attached storage (NAS), firewalls, Infrastructure servers, custom devices, cabling, racks, UPS (uninterrupted power supply), virtual and physical environment, and communication circuits.
    16. 16. Characteristics of Excellent Requirements Bringing depth to perspective Processes Information Security Systems Infrastructure must be examined at one or more Context Depth Concept Logical Physical 2014-01-10 ©2014 PJM LIMITED. ALL RIGHTS RESERVED 16
    17. 17. Depth Context Concept A strata of requirements that describes how A strata of requirements that describes how a particular perspective relates to the a particular perspective relates to the organization’s external environment. organization’s internal structure. Logical A strata of requirements that describes how a particular perspective is assembled using the rules of formal logic. Formal logic provides us with a powerful set of techniques for criticizing some arguments and showing others to be valid using inductive and deductive reasoning. Logical requirements are usually expressed using decision nodes. Physical A strata of requirements that describes the individual components of the solution and their dependencies. In addition, the physical deployment and relationships among software and hardware in a delivered solution. Last, explains how a solution interacts with the external environment.
    18. 18. Putting Perspective into Perspective Assuming you would only examine two focal points at one time there are 66 possible focal combinations As each perspective may also be combined, where only 2 are examined at one given time, there are 10 possible combinations However, each perspective may be examined at each strata – this provides 40 possible combinations of perspective and strata Since each perspective and focal point may also be combined at each strata or depth (order does not matter, no repetition allowed) and assuming we examine only 2 at a time there are 6670 possible combinations of perspective, strata and focus to be considered So the next time you PM tells you to hurry up…..
    19. 19. C O MMENT S AN D Q U EST IO N S M AY BE D IR EC T ED TO : PER RYJ MC LEOD@ICL OUD .COM | L IN KED IN /PER RYMC LEOD F O R MO R E IN F O R M AT ION: W W W.T H ENEW BUSINESSAN ALYST.C OM

    ×