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 Saved: 17 February 2003

Page: 1

Business Alignment

Working With Requirements

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. © Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 2

Business Alignment

Working With Requirements

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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 3

Business Alignment

Working With Requirements

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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 4

Business Alignment

Working With Requirements

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

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 5

Business Alignment

Working With 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 Decomposition Dependency

Impact

Description Structuring of requirements into a tree structure to show the decomposition of high-level requirements into finer-grained, more detailed sub-requirements. 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. 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 Sourced From

Implemented By

Target References

Description Indicates the non-requirement items in the model that are the source of the requirement to which they are related. Indicates the non-requirement items in the model that form the design or implementation of the related requirement. Indicates the project increment in which the requirement will be implemented Relationships with documents external to the model which contain source information for the requirement

Typical Model Items • Business processes • Exclusive arcs • Process transitions • Use cases • Service Interfaces • Service Operations • Classes • Increment • Any model item • Any 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 Intent

Description Summarize the objective or focus of the requirement

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 6

Applicability Functional requirements, or high-level requirements of all categories

Business Alignment

Working With Requirements

Name Description

Description Detailed description of the requirement

Constraints

Any constraints that operate on the requirement

Priority

Sets the priority of the requirement based on a standard scheme Unique identifier for the requirement The named owner of the requirement The named originator of the requirement Records the progress of the requirement based on a standard set of states

Reference Owner Originator Status

Applicability All requirements; high-level requirements will normally have brief descriptions, being elaborated by decomposition Any requirement; non-functional constraints can be modeled using dependencies on other, non-functional requirements Any requirement; most commonly used for behavioral requirements because of the dependencies that exist All requirements; often assigned by requirement or change management systems All requirements; supports the resolution of issues that arise All requirements; supports the clarification of the requirement All requirements; most commonly used for functional requirements because of the 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

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 7

Business Alignment

Working With Requirements

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 Rules Algorithms

Behavioral Use Cases

Non-Functional Constraints

Figure 3 - Integrated requirement model; use cases cases related to other requirements

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 8

Business Alignment

Working With 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 Categorization Decomposition

Starting Point The System must be Responsive The System must be Responsive

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 9

Result Non-functional Requirement (Speed) Fast Response Normal Response Administrative Response

Business Alignment

Working With Requirements

Activity Quantification

Starting Point Fast Response

Result 95% transactions complete in 5 seconds. 99% transactions complete in 10 seconds. Transactions timeout in 20 seconds. Less than .01% transactions timeout. 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. 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. Fast Response Rapid Timeout Normal Response Standard Timeout Administrative Response Slow Timeout Non-Functional Requirement (Timeout)

Normal Response

Administrative Response

Decomposition

Fast Response Normal Response Administrative Response

Categorization Aggregation

Rapid Timeout Standard Timeout Slow Timeout Fast Response Normal Response Administrative Response

Is dependent on Rapid Timeout Is dependent on Standard Timeout 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 nonfunctional requirements and the functional requirements that they will constrain.

“The system must be responsive.”

«references»

«references»

R «non-functional»

R

R

R

«non-functional» Speed

«non-functional» Timeout

R

R

R

R

R

«non-functional» Slow Timeout

«non-functional» Normal Timeout

«non-functional» Rapid Timeout

«dependent»

«non-functional» «non-functional» «non-functional» Fast Response Normal Response Administrative 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 nonfunctional 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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 10

Business Alignment

Working With Requirements

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

Browse Catalog

Customer Eligible To Buy Product

«sourced from»

«references» “The system must… • provide online access to the product catalog • fully support online ordering”

«sourced from»

«EBP» Add Item To Order

«sourced from»

R

R

«behavioral»

«algorithmic»

R

R

R

R

«behavioral» Online Product Catalog Access

«behavioral» Order Products Online

«non-functional» Speed

«algorithmic» Customer Product Eligibility

«references»

R

«dependent»

«behavioral» Add Products To Existing Order

R

«non-functional» Fast Response

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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 11

Business Alignment

Working With Requirements

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… • provide online access to the product catalog”

«references»

R

«sourced from»

«behavioral» Online Product Catalog Access

R

«EBP» Browse Catalog

«non-functional» Speed

«derived from»

«implements»

Browse Catalog

«implements»

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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 12

Business Alignment

Working With Requirements

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»

R

UI Standards Document

«non-functional» Standards «references»

«references»

«references»

R

R

R

«non-functional» HTML Standards

«non-functional» GUI Standards

«non-functional» ASP Standards

«implements» «HTML» HomePage

«implements» «form» frmLogin

«implements» «implements» «form» frmSubmitOrder

«asp» pgLogin

«implements» «asp» 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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 13

Business Alignment

Working With Requirements

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» Improve Online Catalog Access

«non-functional» Speed

«behavioral» Online Product Catalog Access

«behavioral» Order Products Online

«non-functional» Speed

R

R

R

R

«behavioral» Product Search By Keyword

«behavioral» Sort Search Results

«non-functional» Speed-up Fast Response

«behavioral» Add Products To Existing Order

«dependent»

R

«non-functional» Fast Response

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

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 14

Business Alignment

Working With 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»

Change Request

R

«implements»

«asp» pgSearchResult

«behavioral» 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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 15

Business Alignment

Working With Requirements

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»

R

R

«dependent»

«behavioral» Support Electronic Gift Vouchers

«sourced from»

«EBP» Take Payment Remotely

«behavioral» Process Payments Remote From Customer

«implements»

«implements» «derived from»

«added» Take Remote Payment by Gift Voucher

«extends»

Take Payment Remotely

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 © Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 16

Business Alignment

Working With Requirements

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»

R

«dependent»

R

«sourced from»

«EBP» Take Payment Remotely

«behavioral» Process Payments Remote From Customer

«behavioral» Support Electronic Gift Vouchers

«implements»

«implements»

«derived from» «added» Take Remote Payment by Gift Voucher

«extends»

Take Payment Remotely

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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 17

Business Alignment

Working With Requirements

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.

© Aonix Europe Ltd, 2003 Saved: 17 February 2003

Page: 18