You are on page 1of 22

Business Alignment - Working with

Requirements
Whitepaper
Version: 1.4
Business Alignment - Working with Requirements Whitepaper

Disclaimer and Trademarks


© Select Business Solutions, Inc. 2003. All Rights Reserved.
Information in this document is subject to change without notice and does not represent a commitment
on the part of Select Business Solutions, Inc. to provide or continue providing said functionality. This
document may not, in whole or part, be copied, photocopied, reproduced, translated or reduced to any
electronic medium or machine-readable form without prior written consent of Select Business
Solutions, Inc. Company names, data and other information appearing in examples are fictitious in
nature unless otherwise designated.
The software described in this document is furnished under license or non-disclosure agreement and
may be used or copied only in accordance with the terms and conditions of that agreement. It is
against the law to copy the software on any medium except as specifically allowed in the license or
non-disclosure agreement.
Select Enterprise is a Registered Trademark of Select Business Solutions, Inc., and Select Component
Factory, Select Component Architect, Select Component Manager, Select Component Portal, Select
JSync, Select CSync, Select C#Sync, Select ForteSync, Select VBSync, Select DBSync, Select
XMLSync, Select ORSync, Select Document Generator, Select Object Animator, Reviewer for Select
Component Architect, Reviewer for Select Enterprise, Reviewer for Rose, Select Process Director,
Select Process Director Plus, Select UDDIServer, Select Application Composer, Select Scope
Manager, Select Perspective, Select SE, Select SSADM, Select Yourdon are all Trademarks of Select
Business Solutions, Inc.
Because of the nature of the material, numerous hardware and software products are mentioned by
their trade names in the publication. In most, if not all, cases these designations are claimed as
trademarks by their respective companies. It is not the publisher's intent to use any of these names
generically, and the reader is cautioned to investigate all claimed trademark rights before using any of
these names other than to refer to the product described.
For more information about Select Business Solutions Inc., or to download an electronic copy of this
document please visit the Select Website: http://www.selectbs.com/

© Select Business Solutions, Inc. 2003 Page: 1


Business Alignment - Working with Requirements Whitepaper

Table of Contents
Introduction ......................................................................................................3
This Document ..................................................................................................................... 3
About Select Business Solutions.......................................................................................... 3
Types of Requirement......................................................................................5
Behavioral Requirements ..................................................................................................... 5
Algorithmic Requirements .................................................................................................... 6
Non-Functional Requirements.............................................................................................. 7
Objectives............................................................................................................................. 7
Properties of Requirements.................................................................................................. 8
Integrating the Requirement Model .................................................................................... 10
Tracing Requirements....................................................................................11
Documentation of Requirements........................................................................................ 11
Relating To Use Cases....................................................................................................... 13
Derivation of Use Cases..................................................................................................... 14
Implementing Requirements .............................................................................................. 15
Managing Change..........................................................................................17
Principles for Recording Change........................................................................................ 17
Use Case Changes ............................................................................................................ 19
Implementing Change ........................................................................................................ 19
Conclusions ...................................................................................................21

© Select Business Solutions, Inc. 2003 Page: 2


Business Alignment - Working with Requirements Whitepaper

Introduction
Most IT projects fail. An insufficient understanding of the requirements that are driving the project
causes most of these failures. Lack of understanding can have many causes – lack of communication
with the user community is a common fault. Select Perspective has always emphasized the importance
of gaining and maintaining a very clear view of the project requirement – of achieving alignment with
the business need. Business Alignment is one of the core consume-side workflows that must be
executed in a Perspective-based project.
If effort is dedicated to understanding the requirement, it will be wasted unless:
• The requirement is fully and accurately documented;
• Traceable links are maintained with elements of the design and implementation.
Continuous management of the project requirement from inception to completion is essential if the
delivered solutions are to match the needs of the user community and maximize the benefits to the
users.
Of course, gaining an understanding of the requirement is not a one-shot affair. The workflow based
approach of Select Perspective makes clear the incremental structure of a typical project. The
requirement, design and implementation are all elaborated in a series of increments that, ultimately,
deliver the agreed scope. The incremental approach is central to maintaining the alignment between
the project and the user community. It is also an important tool helping to manage change and risk.
These benefits arise because the delivery of the design and implementation is spread across as many
increments as possible. Full awareness of the complexity of the solutions being created is achieved
early in the project. Risks are realized early and their impact assessed and communicated to the users.
Impact of change can be measured, together with its likely cost – decisions of prioritization can be
referred back to the users allowing them to decide the issues of timing and cost.
A central message of Select Perspective is the importance of the extensive and continuous involvement
of users throughout the project. This serves to ensure that the level of alignment with the true business
need is high at the start of the project and remains high throughout. Only by having access to the users
on a continuous basis can the project team gain a sufficient understanding of the requirements and
deliver the high value added solutions that are required in today’s customer focused environment.
This Document
This document describes the approach to modeling the project requirement adopted by projects that use
Select Perspective. Leveraging UML as its core notation, Select Perspective extends the reach of UML
by adding explicit support for Business Process Modeling (BPM) – an aid to achieving a shared
understanding of the business context within which the solutions will operate. It also explicitly
recognizes the different types of requirement that project teams have to take into account.
Supported by Select Component Architect, the different requirements can be formed into an integrated
model that offers complete traceability across the items in the model. Traceability can be extended
backwards into source documents and the Business Process Model and forwards into the design and,
ultimately, the implementation of the solutions.
About Select Business Solutions
For more than 10 years, Select Business Solutions has created a successful track record with tools and
process solutions and is generally recognized as being one of the early adapters of Service and
Component Based Development (CBD) worldwide. The technology behind the Select tools is
continually recognized as being innovative, ensuring that customers’ demands are met to the fullest
satisfaction. It is this three-way focus on development, customers and emerging markets that makes
Select Business Solutions a leader in its field.
The ADT division of Select Business Solutions provides a comprehensive suite (named Select
Component Factory™) of business software development solutions comprised of Select Component
Architect™, Select Component Manager™, Select Component Portal™, Select UDDI Server™,

© Select Business Solutions, Inc. 2003 Page: 3


Business Alignment - Working with Requirements Whitepaper

Select Process Director™, Select Reviewer™, Select JSync™, Select VBSync™ Select C#Sync and
C++Sync™. These tools are supported by a full complement of professional services (support,
training, consultancy/mentoring) in addition to the development method, Select Perspective™.

© Select Business Solutions, Inc. 2003 Page: 4


Business Alignment - Working with Requirements Whitepaper

Types of Requirement
It is quite clear that the requirements that make up the scope of a given solution are divided into several
types. Commonly identified are functional and non-functional requirements – reflecting the
quantitative and qualitative aspects of the solution. However, functional requirements can be usefully
sub-divided into behavioral and algorithmic requirements. Behavioral requirements describe the
external, visible – white box – functionality of the system; algorithmic requirements describe the
internal, hidden – black box – functionality.
This categorization applies to requirements that can be clearly assigned a role in the context of the
solution. However, early statements of need may be expressed at a very abstract level. At first glance
these requirements may seem to be non-functional in nature, but further consideration will frequently
show that they have implications in terms of the functional and non-functional aspects of the solution.
An additional category of objective can be identified as a place-holder for these abstract needs. The
categorizations are shown in figure 1.

R
«requirement»

R R R
«functional» «non-functional» «objective»

R R
«behavioral» «algorithmic»

Figure 1 - Classification of Requirement Types using Stereotypes

Even though different types of requirement can be identified, all the requirements, together, form an
integrated statement of the capabilities and qualities that the solution must embody. It is essential to
represent the integrated nature of the overall requirement, seeking a complete description and avoiding
duplication. This is achieved by establishing appropriate relationships between requirements of
different types. For example, objectives are often not decomposed directly, but their impact is seen
through dependencies on requirements of other types.
Equally important are the other traceable relationships. Those that trace each requirement back to
some source – document or person. Most obviously importantly of all, capturing the relationships that
show how the design and implementation of the solution is derived from the requirements. It is this
last form of relationship that is used for impact analysis as the requirement changes.
Behavioral Requirements
The invention of the Use Case by Ivar Jacobson, published as part of the OOSE method1, represented a
significant step forward in the description of systems’ requirements. The content of a use case has
been re-interpreted many times, but the core concept of describing a unit of interaction between the
user and the system remains constant. By describing units of interaction, use cases effectively support
the incremental working that is at the core of today’s modern development methods.
A single unit of interaction will encompass within its scope many different possible navigation routes
through the described behavior. These arise because of alternative choices made by the user, errors

1
Object-Oriented Software Engineering; Ivar Jacobson; ACM Press, 1992.

© Select Business Solutions, Inc. 2003 Page: 5


Business Alignment - Working with Requirements Whitepaper

encountered in information provided by the user, violations of policies imposed by the business (and
implemented by the solution) and so on. Each possible form of the interaction is regarded as a course
through the use case. The course, which occurs most frequently, which represents the “normal” flow
of events, is chosen as the basic course. Other courses are described as alternate courses.
Each course in turn encompasses a number of scenarios of interaction. Each scenario describes the
characteristics of the data provided by the user, possibly even the precise values to be used. A scenario
can be likened to a single test case for a course through a use case.
The use case is describing an interaction between the user and the system. It is describing the behavior
that the user will experience when the system is used to achieve the goal described for the use case.
Use cases are an excellent tool for describing behavioral requirements. In its earliest incarnations,
Select Perspective2 (supported by the Select Enterprise modeling tool) was the first method to
recognize the value of use cases and to combine them with the market-leading object-modeling
notation described by James Rumbaugh3. This combination of market leading notations, of course,
later formed the basis of the UML.
Algorithmic Requirements
An algorithmic requirement describes an item of complex behavior internal to the system; no actor
interaction is required other than to stimulate the behavior and to receive the output (if any) at the end.
Algorithmic requirements can vary hugely in their complexity; at the most simple, they express simple
rules or policies chosen by the organization and imposed by the solution – these are often referred to as
business rules.
The most complex algorithmic requirements capture the complex rules – true algorithms – involved in
the processes that drive the organization. Such complex requirements include:
• Scheduling algorithms for real-time operating systems;
• Solutions to the “traveling salesman” problem for logistics companies;
• Seat allocations on airline flights and room allocations for hotel chains;
• Complex price and bonus formulae based on periods, volumes, discounts and other factors;
• Calculation of the future value of financial instruments using actuarial formulae.
Many algorithms lie between the two extremes, expressing rules with multiple clauses that combine
items of information to derive additional, new items of information.
The behavioral requirement – the use case – is not able to express all of the complexity associated with
a solution. Use cases are very good at capturing the behavior to be displayed by the solution to the
user, but are not so useful for capturing the algorithmic complexity that is required. First, the
algorithmic complexity is usually completely hidden from the user – even a very simple interaction
may involve significant algorithmic behavior inside the solution.
Second, algorithms have a complex relationship with the behavioral requirement – a single use case
may involve the evaluation of many algorithms (this certainly applies to business rules) and each
algorithm may be used by many use cases. Consequently any attempt to describe algorithmic
requirements in the body of specific use cases leads to duplication and increased complexity in the
requirements model.
In process terms, algorithmic requirements can be difficult to manage. They may be identified early in
the process (as part of BPM, for example), but may not be fully elucidated or designed until much later
in the process. Their initial impact is in terms of the use cases that make use of them, but later in the
process their impact on specific services must be designed and understood.

2
The Select Perspective; Stuart Frost; Select Software Tools, 1995.
3
Object-Oriented Modeling And Design; Rumbaugh et al.; Prentice-Hall, 1991.

© Select Business Solutions, Inc. 2003 Page: 6


Business Alignment - Working with Requirements Whitepaper

Non-Functional Requirements
Non-functional requirements are used to specify the qualitative characteristics of the solution to be
delivered. Qualities include, but are not limited to:
• Speed of response;
• Availability of the solution or specific elements of it;
• Meantime between failure and recovery times;
• Ease of maintenance and enhancement;
• Extent of configurability;
• Usability characteristics, including interface design standards.
These requirements do not influence the functionality that is implemented, but they play a large role in
determining how the functionality is designed and constructed.
Note, too, there is no single requirement for each quality. Whilst it may be desirable to construct a
perfect, defect-free system which never suffers hardware failures and always responds instantaneously,
such an objective is impossible to achieve – at least at a finite cost. Different parts of the solution will
be subject to different qualitative needs, ranging from core business functions to solution
administration functions. Core functions must be “always” available and offer excellent response. In
contrast solution administration functions can afford to suffer downtime and need not offer brilliant
response times. By relaxing the qualitative constraints, the non-essential functions can be implemented
more cheaply and rapidly. Establishing qualitative requirements is, of course, a matter of trading cost
and benefit, realism on the part of the use community is essential.
A functional requirement for the solution is the ability to search for Customers based on certain
criteria. This use case may be constrained by a Speed of Response non-functional requirement
requiring a response within 10 seconds. Such constraints clearly impose a limit on the number of
records that can be returned in a single search transaction and impose a need for the paged display of
the selected records.
The non-functional requirement is not influencing the need for the ability to search for customers, but
is certainly going to impact the way the functionality is implemented and even the design and style of
the user interface offered by the solution.
Of course, other search use cases may be constrained by the same non-functional requirement; the need
for paged display of search results is more general in the solution. The generic capability to retrieve
records in batches and display them in a paged layout can be designed and implemented as part of the
technical architecture. Reuse of technical architecture facilities obviates the need for continual
duplication of the same facilities within the solution itself.
This is a very important point – the non-functional requirements imposed on a solution are often the
source of functional requirements in the technical architecture. In a mature organization, where the
technical architecture is stable4, non-functional requirements are achieved most often by (re-) using
capabilities, services, code or patterns from the technical architecture.
Objectives
Objectives are statements of need expressed at a high-level of abstraction, often as an initial definition
of the critical success factors for the project. Objectives show a clear alignment to the strategy of the
organization, but typically do not directly affect the final set of requirements gathered for the project.
The effect of objectives is, rather, to guide the identification of (some) of the more detailed
requirements – consequently there is a clear dependency between achieving the objective and
achieving these other requirements.

4
The technical architecture is stable, but not static. A new project may well introduce new or changed
needs that must be added to the extant technical architecture; business and technology changes may
introduce additional or changed requirements.

© Select Business Solutions, Inc. 2003 Page: 7


Business Alignment - Working with Requirements Whitepaper

An objective may be set for the project in terms of “increasing web-based sales by 20% year-on-year
and 50% faster than other sales channels”. This objective may be made dependent on non-functional
requirements:
• Make the web site content exciting and visually attractive so the site “sticks”;
• Make the web site easy to use.
It may also be dependent on functional requirements such as:
• Offer web channel specific discounts to new and frequent customers;
• Offer free secure email services to encourage regular visits.
Each of these requirements may, of course, be decomposed into more detailed items.

Properties of Requirements
To form a coherent requirement model, requirements must be documented in a consistent way.
Consistency must apply to the properties recorded and to the relationships formed between
requirements and other requirements and between requirements and other model items. Table 1 shows
the types of relationships that exist between requirements.
Table 1 - Relationships between requirements.
Name Description
Decomposition Structuring of requirements into a tree structure to show the decomposition of
high-level requirements into finer-grained, more detailed sub-requirements.
Dependency Showing how requirements are dependent on each other. Dependencies often
exist between requirements in different categories, for example, functional
requirements being dependent on non-functional requirements.
Impact A specific usage of dependency to show the existing requirements that are
impacted by a change requirement.

Table 2 shows the types of relationships that can be formed between requirements and other items in
the model.
Table 2 - Relationships between Requirements and other Model Items
Name Description Typical Model Items
Sourced From Indicates the non-requirement items in the model • Business processes
that are the source of the requirement to which • Exclusive arcs
they are related. • Process transitions
Implemented By Indicates the non-requirement items in the model • Use cases
that form the design or implementation of the • Service Interfaces
related requirement. • Service Operations
• Classes
Target Indicates the project increment in which the • Increment
requirement will be implemented
References Relationships with documents external to the • Any model item
model which contain source information for the • Any requirement
requirement

Table 3 shows the set of attributes typically used to document requirements. These can be extended if
additional information needs are identified.
Table 3 – Common Attributes of Requirements
Name Description Applicability
Intent Summarize the objective or focus Functional requirements, or high-level
of the requirement requirements of all categories

© Select Business Solutions, Inc. 2003 Page: 8


Business Alignment - Working with Requirements Whitepaper

Name Description Applicability


Description Detailed description of the All requirements; high-level requirements will
requirement normally have brief descriptions, being
elaborated by decomposition
Constraints Any constraints that operate on Any requirement; non-functional constraints
the requirement can be modeled using dependencies on other,
non-functional requirements
Priority Sets the priority of the Any requirement; most commonly used for
requirement based on a standard behavioral requirements because of the
scheme dependencies that exist
Reference Unique identifier for the All requirements; often assigned by
requirement requirement or change management systems
Owner The named owner of the All requirements; supports the resolution of
requirement issues that arise
Originator The named originator of the All requirements; supports the clarification of
requirement the requirement
Status Records the progress of the All requirements; most commonly used for
requirement based on a standard functional requirements because of the
set of states dependencies that can be established

A screenshot of the functionality provided by Select Component Architect to support the


documentation and modeling of project requirements is shown in figure 2. It shows, using an explorer
view, some of the relationships available between the requirements and between requirements and

Figure 2 - Select Component Architect Supports Requirements

other model items.

© Select Business Solutions, Inc. 2003 Page: 9


Business Alignment - Working with Requirements Whitepaper

Integrating the Requirement Model


Key benefits of the adoption of use cases for the expression of the behavioral requirement include the
ability to drive the project on a “by use case” basis, and to deliver incrementally based on groups of
use cases. The delivery of a use case must include the delivery its algorithmic and non-functional
requirements. Thus, by making the use case the unit of work on the project, it becomes the core of the
requirement model. The use cases are dependent on the algorithmic and non-functional requirements
that support or influence them – refer to figure 3.
To understand the full scope of a use case, traceable links must be established to the algorithmic and
non-functional requirements that influence it. The design of the solution involves taking into account
the non-functional constraints and the specification or re-use of services to evaluate the algorithms
needed. The implementation of the use case includes the implementation (or re-use) of the services
that provide the required algorithms and the re-use of the elements of the technical architecture
required to support its non-functional constraints.

Algorithmic Behavioral Non-Functional


Rules Use Cases Constraints
Algorithms
Figure 3 - Integrated requirement model; use cases related to other requirements

© Select Business Solutions, Inc. 2003 Page: 10


Business Alignment - Working with Requirements Whitepaper

Tracing Requirements
The previous section showed how an integrated, consistent and complete set of requirements can be
created, based on the use cases that describe the behavioral needs of the users. Unfortunately,
requirements are rarely supplied in a form that can be used as the basis of such a requirement model.
The typical project must take the high-level statement of need supplied by the various users and
analyze these needs to form the integrated requirement model.
Similarly, solutions are not implemented directly from the requirement. The requirement must be
evolved into a design, which integrates the constraints imposed by the technical architecture and which
conforms to the service-based architecture. The design is, in turn, interpreted into the code from which
the solution is built, tested and deployed.
It is clear, therefore, that more than an integrated requirement model is needed. The requirements must
in turn be traceable to their sources and to the elements of the design that effect their implementation.
Only in this way can the impact of changes to the users’ need be understood. First the changes are
analyzed to establish which of the requirements are will be affected. Second, the change to each
requirement is analyzed to quantify the effect on the design and implementation of the solution.
Documentation of Requirements
The business needs that a solution must fulfill are expressed in many different forms. Some of the
more frequently occurring forms include:
• Notes from interviews and meetings;
• Informal requests from users;
• Formal project request documents;
• High-level statements of business strategy;
• Brain-storming sessions;
• Formal modeling sessions.
Quite clearly, the style of expression, content and level of detail of these various formats is going to be
inconsistent; there may even be contradictions between them. The documented needs must be
analyzed and re-expressed as true requirements. How much analysis is required depends on the
formality of the initial expression. At their most informal a document may simply list a few bullet
points, requiring extensive analysis and elaboration. A formal model, such as a Business Process
Model (BPM) will typically require the least analysis work because of its very formality.
Analysis activities include:
• Categorization – by type of requirement or other classification;
• Decomposition – refining widely-scoped needs into precise requirements;
• Quantification – attaching measurable targets to needs;
• Distillation – merging different statements of the same need;
• Aggregation – forming associations between related requirements;
• Confirmation – ensuring that restated requirements match the need.
Consider, for example, a very broad (but also typical) statement of need: “the system must be
responsive”. The following table shows a very simple analysis that might proceed from such a need.
Of course, the analysis shown will be undertaken with the users who must agree the restated
requirements. Later in the process, these non-functional requirements will be related to the functional
requirements that they influence or constrain.
Table 4 - Analysis of Need to Form Requirements
Activity Starting Point Result
Categorization The System must be Responsive Non-functional Requirement (Speed)
Decomposition The System must be Responsive Fast Response
Normal Response
Administrative Response

© Select Business Solutions, Inc. 2003 Page: 11


Business Alignment - Working with Requirements Whitepaper

Activity Starting Point Result


Quantification Fast Response 95% transactions complete in 5 seconds.
99% transactions complete in 10 seconds.
Transactions timeout in 20 seconds.
Less than .01% transactions timeout.
Normal Response 80% transactions complete in 5 seconds.
90% transactions complete in 10 seconds.
95% transactions complete in 30 seconds.
Transactions timeout in 50 seconds.
Less than 1% transactions timeout.
Administrative Response 50% transactions complete in 10 seconds.
80% transactions complete in 30 seconds.
95% transactions complete in 60 seconds.
Transactions timeout in 90 seconds.
Less than 3% transactions timeout.
Decomposition Fast Response Fast Response
Rapid Timeout
Normal Response Normal Response
Standard Timeout
Administrative Response Administrative Response
Slow Timeout
Categorization Rapid Timeout Non-Functional Requirement (Timeout)
Standard Timeout
Slow Timeout
Aggregation Fast Response Is dependent on Rapid Timeout
Normal Response Is dependent on Standard Timeout
Administrative Response Is dependent on Slow Timeout

Figure 4 shows the resulting set of requirements and their relationships to each other and to the original
statement of need. Of course, this model does not yet include the cross-references between these non-
functional requirements and the functional requirements that they will constrain.

“The system must


«references» be responsive.” «references»

R
«non-functional»

R R
«non-functional» «non-functional»
Speed Timeout

R R R «dependent»
R R R
«non-functional» «non-functional» «non-functional» «non-functional» «non-functional» «non-functional»
Fast Response Normal Response Administrative Slow Timeout Normal Timeout Rapid Timeout
Response
«dependent»

«dependent»

Figure 4 - Analysis of a Simply Stated Non-Functional Need

Very often, functional requirements are also initially stated in a very informal manner. The
interpretation of these informal statements of need into more formal requirement forms is even more
problematic. For this reason, it is often beneficial to establish a formal model of the need – typically
expressed as a BPM. A BPM is a very powerful source of information about both behavioral and non-
functional requirements and may be used as an intermediate step between informal statements from
users and the more formal requirement model. Whatever style of expression is chosen for the
functional needs, they are the sources of the functional requirements of the solution.

© Select Business Solutions, Inc. 2003 Page: 12


Business Alignment - Working with Requirements Whitepaper

Figure 5 shows how functional requirements can be related to their source references and to a BPM if
one is created. Notice how the initial user need of “fully support online ordering” is decomposed into
“Add Products To Existing Order” – it is this more detailed requirement which is cross-referenced to
the BPM. Note, too, the dependency on the non-functional requirements – this dependency can be
derived from volumetric information recorded in the BPM.

«EBP» Customer Product Eligibility «EBP»


Add Item To
Browse Catalog
Customer Eligible Order
To Buy Product

«sourced from» «sourced from» «sourced from»

R R
«behavioral» «algorithmic»

«references»
R R R R
«behavioral» «behavioral» «non-functional» «algorithmic»
“The system must… Online Product Order Products Speed Customer Product
• provide online access Catalog Access Online Eligibility
to the product catalog
• fully support online «references»
ordering”

R «dependent»
R
«behavioral» «non-functional»
Add Products To Fast Response
Existing Order

Figure 5 - Functional Requirements related to Documents and BPM

Relating To Use Cases


In the section Behavioral Requirements starting on page 5; it was made clear that use cases are an
effective way of documenting and describing the behavioral requirement for a solution. This section
has shown the use of ad-hoc requirements rather than use cases so far. The choice to use requirements
to capture behavioral need, before use cases are modeled, is essentially a question of process and risk
management.
Projects that start with many disparate sources of requirements and without a coherent BPM need to
create a comprehensive and coherent requirement model in order to keep risk at a manageable level.
Documenting behavioral requirements and then creating use cases to implement them provides this
complete picture and will help to manage project risk – particularly risks associated with change. In
contrast, projects that start with a comprehensive BPM can use this as the source of the behavioral
requirements with relatively little risk. Project managers must choose the combination of techniques
and models that best matches the project profile in terms of risk, timescales and cost. The key is to
maintain the agility of the development organization in the face of different and changing project
needs.
In many projects, all of the different techniques and modeling forms will be combined and will be
undertaken in parallel:
• Needs will be expressed in ad-hoc form and be translated into requirements;
• Business Process Modeling will explore the business context for the solution;
• Use Cases will be derived from requirements and the BPM.

© Select Business Solutions, Inc. 2003 Page: 13


Business Alignment - Working with Requirements Whitepaper

However the requirement model is completed, it can be comprised of the following elements:
• Cross-references to documents supplied by the user community;
• Decomposed behavioral, algorithmic and non-functional requirements;
• Business Process Model describing the business and behavioral context;
• Use Cases describing the solution behavior in detail.

R
«behavioral»

“The system must… «EBP»


R
• provide online access
to the product catalog”
«references»
R «sourced from»
Browse Catalog
«non-functional»
«behavioral» Speed
Online Product
Catalog Access
«derived from»
«implements»

«implements»
Browse Catalog
R
«non-functional»
Fast Response

«dependent»

Figure 6 - Use Case Derived from EBP and Implements Requirements

Derivation of Use Cases


Use Cases are best derived from the BPM5. The Process Hierarchy provides a decomposition of
processes allowing the modeler to accurately judge the appropriate level of granularity most
appropriate for each use case. A Process Thread, the leaf node of the hierarchy, is decomposed into
elementary business processes (EBP). In turn, each EBP is constrained by the “one time, one person,
one place” heuristic – this heuristic describes a “unit of activity” for the business process.
Of course, not all of the activity in the process can be automated, so a single EBP is the source of one
or more use cases – each representing a “unit of activity” for the solution. The BPM simplifies the
identification of use cases and confirms their start and end points. The resulting Use Case Model is
typically simpler and more easily understood than one derived from first principles because it is
structurally more closely aligned to the business process. A Use Case Model derived without the
benefit of a BPM may need to pass through several iterations to achieve the same degree of business
alignment.
The documentation of each use case course is also likely to be easier to write, because it can be based
on the description of its corresponding EBP. In terms of structure and content, the use case courses are
more detailed than the documentation of an EBP and they focus on the interaction between actor and
system. The use case is derived from the EBP on which it is based. It is the implementation of one or
more behavioral, algorithmic and non-functional requirements.
Many solutions implement use cases in addition to those that directly support the business process
being automated. These use cases are typically related to the need to administrate the solution –

5
Value adding use cases typically support Business Processes; solution administration use cases are
not value adding because they do not actively support the business processes, however they do form
part of the overall requirement for the solution.

© Select Business Solutions, Inc. 2003 Page: 14


Business Alignment - Working with Requirements Whitepaper

maintain business rule values, standing data tables and so on. Additional, administrative needs can be
sensibly stated as requirements. The use cases derived from these requirements then form the
implementation of the corresponding administrative needs.
Implementing Requirements
Understanding requirements is only the precursor. A project provides no value to the business unless it
delivers an operational solution that supports the business processes in its scope. The ability to trace
from requirement to implementation is key in being able to maintain and improve the solution in the
long term.

R
«non-functional»

UI Standards Document
R
«non-functional»
Standards

«references»

«references» «references»

R R R
«non-functional» «non-functional» «non-functional»
HTML Standards GUI Standards ASP Standards

«implements» «implements» «implements» «implements» «implements»

«HTML» «form» «form» «asp» «asp»


HomePage frmLogin frmSubmitOrder pgLogin pgSubmitOrder

Figure 7 - Implementation by model items other than use cases

The model supported by Select Component Architect has traceable links inherent in it. For example, it
is possible, given a use case and a sufficiently detailed model, to derive the set of service interfaces and
service operations required to construct the use case. Since the use case is part of the requirement
model, linked to other forms of requirement, the traceable links in the design model itself provide
sufficient coverage. The automation of the traceable links provided in this way also reduces the effort
involved in maintaining the linkages that are established.
As a general principle, then, requirements should only be linked to use cases or other items that
encompass their implementation, an example is shown in figure 7. More finely grained model items –
interfaces or operations, for example – should rely on indirect linkage through the owning use case or
other model item.
However, requirements certainly can apply to items other than use cases. User interface standards may
be included as part of the requirement for a given solution. It can be argued that these standards are
implemented by use cases. More precisely, they are implemented by the different elements of the user
interface (forms, html files, server pages and so on) that are controlled by the use cases. A more
effective model will be obtained by directly linking the standards requirements to the classes used to
represent the elements of the user interface.
A second example is the linkage between algorithmic requirements and the service operations that
must use or implement these requirements. Initially, the requirement is linked to the use case, but once
the service operations required to implement the use case have been identified (through interaction

© Select Business Solutions, Inc. 2003 Page: 15


Business Alignment - Working with Requirements Whitepaper

modeling), the linkages must be refined to show relationships between algorithmic requirements and
specific service operations.

© Select Business Solutions, Inc. 2003 Page: 16


Business Alignment - Working with Requirements Whitepaper

Managing Change
The one great constant of all IT projects is change. Indeed, many IT projects are all about change –
change to the business; change to the solutions that support the business. Even in “green-field”
projects, changes are requested once the initial requirements are agreed. Documenting requirements
for change offers additional challenges, including:
• Mixtures of new features and change requests which must be managed as part of the same project;
• Widely varying scale of requirement from simple screen changes to extensive functional change;
• Items impacted by change extend far beyond use cases, potentially including any design model
item;
• Conflict between the requested changes, which must be resolved before they are implemented;
• Transitory change – once implemented changes simply become part of the implementation;
• Cumulative change – changes may impact existing changes before they are even implemented.
Despite these additional complexities, the principles of documenting changes and their relationships to
source materials and impacted implemented items are essentially the same. Some refinement is needed
in the way that requirements documented in the first instance.

R
«change»

R R R R
«behavioral» «non-functional» «behavioral» «non-functional»

R R R R R
«behavioral» «non-functional» «behavioral» «behavioral» «non-functional»
Improve Online Speed Online Product Order Products Speed
Catalog Access Catalog Access Online

R R R R «dependent»
R
«behavioral» «behavioral» «non-functional» «behavioral» «non-functional»
Product Search Sort Search Speed-up Add Products To Fast Response
By Keyword Results Fast Response Existing Order

«dependent»

«dependent»

Figure 8 - Change Requirement Structure and Relationships to Current Requirement

Principles for Recording Change


The transitory and cumulative nature of change makes it important to partition the documentation of
changes from the documentation of the existing set of requirements. This:
• Facilitates separation of change from current design or implementation;
• Allows change to be integrated into current requirements in a controlled manner.
Principle 1 – change requirements are partitioned from the current working set of requirements.

© Select Business Solutions, Inc. 2003 Page: 17


Business Alignment - Working with Requirements Whitepaper

Change can apply to any of the requirements currently being designed or implemented. In particular,
change can be behavioral, for example “the system must offer improved catalogue search facilities”;
change can be algorithmic, for example “the system must validate the credit rating of the customer”;
change can be non-functional, for example “it takes too long to create a new customer order”.
Principle 2 – change requirements can be part of any of the categories of requirement – behavioral,
algorithmic or non-functional – and should be categorized accordingly.
Change requirements are refined in exactly the same way as any other requirement. The refinement
helps to obtain a more detailed understanding of the precise nature and scope of the change that is
being requested. Linkage between requested changes, base requirements and other model items are
established at the appropriate level of granularity in order to keep the requirement model simple.

R
«change»

R
«behavioral»

R
«behavioral»
Improve Online
Catalog Access

«references»
R «implements» «asp»
pgSearchResult
«behavioral»
Change Request Add Information
To Results Form

Figure 9 - Change Requirement Related to Specific Implementation Item

Principle 3 – change requirements must be refined to an appropriate level of detail so their impact on
existing requirements and design can be accurately reflected.
Change can serve to modify existing requirements for the solution. For example, the service level
agreed for “fast response” may initially be as shown in Table 4 on page 11. Later in the delivery of
the solution a decision may be made to change the required service level, perhaps to require an even
higher level of performance. In this instance, the change is impacting a requirement, but may well not
affect other aspects of the solution or component design – the impact of the change may well be in
terms of the technical architecture, ensuring that the higher levels of performance can be delivered.
The same concept can be used to trace the impact of behavioral and algorithmic requirements. Where
these have a clear relationship to existing requirements, this should be modeled in preference to
relationships with implementing items. Examples are shown in figure 8.
Principle 4 – where the impact of change requirements can be traced using existing requirements,
linkage to these requirements is sufficient to assess the impact of each change.

© Select Business Solutions, Inc. 2003 Page: 18


Business Alignment - Working with Requirements Whitepaper

Some changes may not relate to existing requirements because their target is a specific item of
implementation. These implementation items will, of course, be related to existing requirements –
otherwise, why would they exist? The relationship to the existing requirement is indirect, through
some traceable parent element of the design or implementation. In this case, the change requirement is
linked to the implementing item rather than to an existing requirement. For example, additional
information may be requested on a specific form in the user interface – see figure 9. Such a change
might well impact several use cases, but is more simply and accurately traced to the single form being
impacted.
Principle 5 – Requirements that impact a specific implementation item are directly related to that item
rather than to current requirements.

Use Case Changes


Some changes to behavioral requirements are sufficiently large that they represent alterations to
existing use case courses, or the addition of new alternate courses to the use case. It is often useful to
retain a clear separation between the courses that have already been implemented and the courses that
are new or are being altered.

R
«change»

R R
«behavioral» «behavioral»

«EBP»

R «dependent»
R «sourced from» Take Payment
Remotely
«behavioral» «behavioral»
Support Electronic Process Payments
Gift Vouchers Remote From Customer

«implements» «implements»
«derived from»

«added»
Take Remote «extends» Take Payment
Payment by Gift Remotely
Voucher

Figure 10 - Change Impacts on Use Case

In the use case model, the «extends» relationship is used to factor significant alternate courses into
separate use cases. Whilst not every changed or new course need be “significant”, the same
relationship can be used pragmatically to separate current and changing designs – refer to figure 10. In
addition, stereotyping of the extending use cases can indicate whether the course is replacing an
existing course or being added as a new course – figure 10 shows an example of the use of this idea.
Implementing Change
Changes cease to be changes as soon as they are implemented. As part of the updated solution,
implemented changes become potential targets for future change. To ensure that the requirement
model retains its consistency with the implementation, the change requirements must be integrated into
the main requirement model as the change is implemented.
In an ideal situation, at the point of deployment, the model of the solution would contain only
implemented requirements. Of course, such an ideal is unlikely to be achieved. New changes can be

© Select Business Solutions, Inc. 2003 Page: 19


Business Alignment - Working with Requirements Whitepaper

requested at any time, irrespective of the implementation schedule and the known changes may be too
extensive to be implemented in a single increment. In any case, changes will be prioritized, so that
high priority change is delivered first. More value may be derived by delivering a few high-priority
changes quickly than by waiting until all changes have been implemented.

R
«change»

R R
«behavioral» «behavioral»

«EBP»

R «dependent»
R «sourced from» Take Payment
Remotely
«behavioral» «behavioral»
Support Electronic Process Payments
Gift Vouchers Remote From Customer

«implements» «implements»
«derived from»

«added»
Take Remote «extends» Take Payment
Payment by Gift Remotely
Voucher

Figure 10 - Integration of Implemented Changes

The allocation of change requirements to delivery increments supports the prioritization of changes.
At the end of each increment, the implemented change requirements are integrated into the main
requirement model to ensure that the model accurately reflects the updated implementation.
Outstanding change requirements are left in the change set, and will be delivered in a later increment.
For behavioral changes, there is a choice to be made concerning the integration of the extending use
case into its parent. Unless the new use case represents a real extending case, it is probably best being
integrated with the parent use case – otherwise, the use case model will become increasingly complex
as changing use cases accumulate in the model. Figure 10 shows the requirement and the change use
case being rolled into the main requirement following implementation.

© Select Business Solutions, Inc. 2003 Page: 20


Business Alignment - Working with Requirements Whitepaper

Conclusions
Projects fail for many different reasons, but most often because of a lack of clear understanding of the
project requirement. The failure to understand the users’ needs arises for many reasons, many of them
associated with the seeming inability to communicate effectively with the user community. If we
manage to survive these risks, then a failure to accurately record and analyze the project requirement
remains a significant risk.
A very significant part of the understanding of the project requirement is expressed in the relationships
between the requirements. The formation of an integrated, complete and consistent requirement model
is essential.
Relationships exist not only between requirements, but also to provide traces between the requirements
and the source materials for the project and the design and implementation of the software solution.
These traceable relationships are key to understanding the impact of change and to ensuring that
change is accurately reflected in the design and implementation.
Such high levels of integration are required to meet the challenges of complexity and change that only
by incorporating requirements and design into a shared model can the needed levels of tracing be
achieved. It is the integration of requirements as an extension to the UML notation, supported by
Select Component Architect, which provides this level of integration in an easily accessible and
intuitive manner. In this way, Select Component Architect provides an important extra weapon for
project teams as they struggle to provide the user community with the efficient, fully aligned solutions
that today’s competitive business environment requires.

© Select Business Solutions, Inc. 2003 Page: 21