This document summarizes a presentation by Perry J. McLeod on developing requirements. It introduces McLeod's multi-dimensional model for requirements elicitation, analysis, and communication. The model examines requirements from different focal points, perspectives, and depths. Requirements are formed as SMART statements induced from discoveries throughout the engagement process. The presentation aims to establish a focal point for discussion and understand that multiple perspectives and depths of analysis are needed.
Entrepreneurship & organisations: influences and organizations
How to build a requirement
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. 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. 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. 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. 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
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
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.
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. 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. 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
Hinweis der Redaktion
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