Understanding Requirements

Business Alignment
Working With Requirements

Business Alignment Working With Requirements
Table of Contents
Introduction ..................................................................................................... 2
This Document...................................................................................................................... 2
About Select Business Solutions .......................................................................................... 2
Types Of Requirement .................................................................................... 3
Behavioral Requirements ..................................................................................................... 3
Algorithmic Requirements..................................................................................................... 4
Non-Functional Requirements .............................................................................................. 5
Objectives ............................................................................................................................. 5
Properties of Requirements .................................................................................................. 6
Integrating The Requirement Model ..................................................................................... 7
Tracing Requirements..................................................................................... 9
Documentation of Requirements .......................................................................................... 9
Relating To Use Cases ....................................................................................................... 11
Derivation Of Use Cases .................................................................................................... 12
Implementing Requirements ............................................................................................... 13
Managing Change......................................................................................... 14
Principles For Recording Change....................................................................................... 14
Use Case Changes ............................................................................................................. 16
Implementing Change......................................................................................................... 16
Conclusions .................................................................................................. 18
© Aonix Europe Ltd, 2003 Page: 1

Saved: 17 February 2003
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
Select Business Solutions is the market leader in the provision of Visual Modeling and Component
Management technology for the rapid development of business solutions assembled from components
and services. Select Perspective is the thought-leading, practical component and service-oriented
development process, based on over 100 effort-years of real experience in the delivery of business
solutions in service-oriented architectures. Select Perspective is delivered through Select Process
Director, which enables users to amend and maintain the definition of the process to suit their
organizations’ culture and working practices. Adding further value, Process Director delivers the
process in a practical way, helping project managers to focus on the optimal planning of their projects
and encouraging team members to play an active role in following the process and feeding back
suggestions for process improvement.

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.
1
Object-Oriented Software Engineering; Ivar Jacobson; ACM Press, 1992.

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

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

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

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 other model items.
Figure 2 - Select Component Architect Supports Requirements
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
cases related to other requirements

Tracing Requirements
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

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.
Less than 1% transactions timeout.
Administrative Response 50% transactions complete in 10 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.

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 3, 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.

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

Implementing
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
modeling), the linkages must be refined to show relationships between algorithmic requirements and
specific service operations.

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.

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

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
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
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
«EBP»
R «dependent»
R «sourced from» Take Payment
Remotely
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.

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.


Understanding Requirements

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding Requirements

Uploaded by

Copyright:

Available Formats

Business Alignment

Working With Requirements

© Aonix Europe Ltd, 2003 Page: 1

© Aonix Europe Ltd, 2003 Page: 2

Figure 1 - Classification of Requirement Types using Stereotypes

© Aonix Europe Ltd, 2003 Page: 3

© Aonix Europe Ltd, 2003 Page: 4

© Aonix Europe Ltd, 2003 Page: 5

© Aonix Europe Ltd, 2003 Page: 6

Name Description Applicability

Figure 2 - Select Component Architect Supports Requirements

Integrating The Requirement Model

© Aonix Europe Ltd, 2003 Page: 7

Algorithmic Behavioral Non-Functional

© Aonix Europe Ltd, 2003 Page: 8

© Aonix Europe Ltd, 2003 Page: 9

Activity Starting Point Result

“The system must

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

© Aonix Europe Ltd, 2003 Page: 10

«EBP» Customer Product Eligibility «EBP»

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

Figure 5 - Functional Requirements related to Documents and BPM

Relating To Use Cases

© Aonix Europe Ltd, 2003 Page: 11

“The system must… «EBP»

Figure 6 - Use Case Derived from EBP and Implements Requirements

Derivation Of Use Cases

© Aonix Europe Ltd, 2003 Page: 12

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

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

Figure 7 - Implementation by model items other than use cases

© Aonix Europe Ltd, 2003 Page: 13

Figure 8 - Change Requirement Structure and Relationships to Current Requirement

Principles For Recording Change

© Aonix Europe Ltd, 2003 Page: 14

Figure 9 - Change Requirement Related to Specific Implementation Item

© Aonix Europe Ltd, 2003 Page: 15

Use Case Changes

Figure 10 - Change Impacts on Use Case

© Aonix Europe Ltd, 2003 Page: 16

Figure 10 - Integration of Implemented Changes

© Aonix Europe Ltd, 2003 Page: 17

© Aonix Europe Ltd, 2003 Page: 18

You might also like