Coping with change

Change is inevitable in all large software projects, thus as the system

requirements change, the business procuring the system responds to external
pressures and management priorities change. Also, as new technologies
become available, new design and implementation possibilities emerge.
Therefore whatever software process model is used, it is essential that it can
accommodate changes to the software being developed.
Change adds to the costs of software development because it usually means
that work that has been completed has to be redone, this is called “re-work”.
For example, if the relationships between the requirements in a system have
been analyzed and new requirements are then identified, some or all of the
requirements analysis has to be repeated. It may then be necessary to
redesign the system to deliver the new requirements, change any programs
that have been developed, and re-test the system.
There are two related approaches that may be used to reduce the costs of
rework i.e. change avoidance and change tolerance:
• Change avoidance
This is where the software process includes activities that can anticipate
possible changes before significant rework is required. For example, a
prototype system may be developed to show some key features of the system
to customers. They can experiment with the prototype and refine their
requirements before committing to high software production costs.

• Change tolerance
This is where the software process is designed so that changes can be
accommodated at relatively low cost. This normally involves some form of
incremental development. Proposed changes may be implemented in
increments that have not yet been developed. If this is impossible, then only
a single increment (a small part of the system) may have to be altered to
incorporate the change.
Also, there are two ways of coping with change and changing system requirements,
i.e. system prototyping and incremental delivery.
• System prototyping
This is where a version of the system or part of the system is developed quickly to
check the customer’s requirements and the feasibility of some design decisions.
This process supports change avoidance as it allows users to experiment with the
system before delivery and so refine their requirements. The number of
requirements change proposals made after final delivery is therefore likely to be
reduced.
• Incremental delivery
This is where system increments are delivered to the customer for comment and
experimentation. This process supports both change avoidance and change
tolerance. It avoids the premature commitment to requirements for the whole
system and allows changes to be incorporated into later increments at relatively
low cost.
Boehm’s spiral model

A risk-driven software process framework (spiral model) was proposed

by Boehm (1988). Here, the software process is represented as a spiral,
rather than a sequence of activities with some backtracking from one
activity to another. Each loop in the spiral represents a phase of the
software process. Thus, the innermost loop might be concerned with
system feasibility, the next loop with requirements definition, the next
loop with system design, and so on. The spiral model combines change
avoidance with change tolerance. It assumes that changes are a result of
project risks and includes explicit risk management activities to reduce
these risks.
Each loop in the spiral model is split into four sectors:
• Objective setting
Objectives for that phase of the project are defined. Constraints on the
process and the product are identified and a detailed management plan
is drawn up. Project risks are identified, and alternative strategies,
depending on these risks, may be planned.

• Risk assessment and reduction

For each of the identified project risks, a detailed analysis is carried out.
Steps are taken to reduce the risk. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.
• Development and validation
After risk evaluation, a development model for the system is chosen. For example,
throwaway prototyping may be the best development approach if user interface
risks are dominant. If safety risks are the main consideration, development based
on formal transformations may be the most appropriate process, and so on. If the
main identified risk is sub-system integration, the waterfall model may be the best
development model to use.

• Planning
The project is reviewed and a decision made whether to continue with a further
loop of the spiral. If it is decided to continue, plans are drawn up for the next phase
of the project.
The main difference between the spiral model and other software
process models is its explicit recognition of risk. A cycle of the spiral
begins by elaborating objectives such as performance and functionality.
Alternative ways of achieving these objectives, and dealing with the
constraints on each of them, are then known.
Each alternative is assessed against each objective and sources of
project risk are identified. The next step is to resolve these risks by
information-gathering activities such as more detailed analysis,
prototyping, and simulation.
Once risks have been assessed, some development is carried out,
followed by a planning activity for the next phase of the process.
Informally, risk simply means something that can go wrong.
Rational unified process
The Rational Unified Process (RUP) is an example of a modern process model that
has been derived from work on the UML and the associated Unified Software
Development Process. The RUP recognizes that conventional process models
present a single view of the process. In contrast, the RUP is normally described
from three perspectives:

• A dynamic perspective, which shows the phases of the model over time.
• A static perspective, which shows the process activities that are enacted.
• A practice perspective, which suggests good practices to be used during the
process.
The RUP is a phased model that identifies four discrete phases in the
software process. However, unlike the waterfall model where phases are
equated with process activities, the phases in the RUP are more closely
related to business rather than technical concerns. The phases of the
RUP are: Inception, elaboration, construction and transition.
• Inception
The goal of the inception phase is to establish a business case for the
system. You should identify all external entities (people and systems)
that will interact with the system and define these interactions. You then
use this information to assess the contribution that the system makes to
the business. If this contribution is minor, then the project may be
cancelled after this phase.
• Elaboration
The goals of the elaboration phase are to develop an understanding of
the problem domain, establish an architectural framework for the
system, develop the project plan, and identify key project risks. On
completion of this phase you should have a requirements model for the
system, which may be a set of UML use-cases, an architectural
description, and a development plan for the software.
• Construction
The construction phase involves system design, programming, and
testing. Parts of the system are developed in parallel and integrated
during this phase. On completion of this phase, you should have a
working software system and associated documentation that is ready for
delivery to users.
• Transition
The final phase of the RUP is concerned with moving the system from the
development community to the user community and making it work in a real
environment. This is something that is ignored in most software process models
but is, in fact, an expensive and sometimes a problematic activity. On completion
of this phase, you should have a documented software system that is working
correctly in its operational environment.
Iteration within the RUP is supported in two ways. Each phase may be enacted in
an iterative way with the results developed incrementally. In addition, the whole
set of phases may also be enacted incrementally, as shown in the diagram.
The static view of the RUP focuses on the activities that take place
during the development process. These are called workflows in the RUP
description. There are six core process workflows identified in the
process and three core supporting workflows. The RUP has been
designed in conjunction with the UML, so the workflow description is
oriented around associated UML models such as sequence models,
object models, etc.
The advantage in presenting dynamic and static views is that phases of
the development process are not associated with specific workflows. In
principle, all of the RUP workflows may be active at all stages of the
process. In the early phases of the process, most effort will probably be
spent on workflows such as business modelling and requirements and,
in the later phases, in testing and deployment.
Static work flows in RUP
• Business modelling: This is where the business processes are modelled using
business use cases.
• Requirements: This is where actors who interact with the system are identified
and use cases are developed to model the system requirements.
• Analysis and design: This is where a design model is created and documented
using architectural models, component models, object models, and sequence
models.
• Implementation: This is where the components in the system are implemented
and structured into implementation sub-systems if necessary.
• Testing: Testing is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the implementation.
• Deployment: A product release is created, distributed to users, and installed in
their workplace.
• Configuration and change management: This supporting workflow
manages changes to the system.
• Project management: This supporting workflow manages the system
development.
• Environment: This workflow is concerned with making appropriate
software tools available to the software development team.

The practice perspective on the RUP describes good software

engineering practices that are recommended for use in systems
development. Six fundamental best practices are recommended:
• Develop software iteratively: Plan increments of the system based on
customer priorities and develop the highest-priority system features early in
the development process.
• Manage requirements: Explicitly document the customer’s requirements
and keep track of changes to these requirements. Analyze the impact of
changes on the system before accepting them.
• Use component-based architectures: Structure the system architecture
into components.
• Visually model software: Use graphical UML models to present static and
dynamic views of the software.
• Verify software quality: Ensure that the software meets the organizational
quality standards.
• Control changes to software: Manage changes to the software using a
change management system and configuration management procedures
and tools.
Requirements engineering
The requirements for a system are the descriptions of what the system
should do i.e. the services that it provides and the constraints on its
operation. These requirements reflect the needs of customers for a
system that serves a certain purpose such as controlling a device, placing
an order, or finding information. The process of finding out, analyzing,
documenting and checking these services and constraints is called
requirements engineering (RE).
The term ‘requirement’ is not used consistently in the software industry.
In some cases, a requirement is simply a high-level, abstract statement
of a service that a system should provide or a constraint on a system. On
the other hand, it is a detailed, formal definition of a system function.
• Functional requirements
These are statements of services the system should provide, how the system
should react to particular inputs, and how the system should behave in particular
situations. In some cases, the functional requirements may also explicitly state
what the system should not do.

• Non-functional requirements
These are constraints on the services or functions offered by the system. They
include timing constraints, constraints on the development process, and
constraints imposed by standards. Non-functional requirements often apply to the
system as a whole, rather than individual system features or services.
In reality, the difference between the types of requirement is not as clear-cut as
these simple definitions suggest. A user requirement concerned with security, such
as a statement limiting access to authorized users, may appear to be a
nonfunctional requirement. However, when developed in more detail, this
requirement may generate other requirements that are clearly functional, such as
the need to include user authentication facilities in the system.

This shows that requirements are not independent and that one requirement often
generates or constrains other requirements. The system requirements therefore do
not just specify the services or the features of the system that are required; they
also specify the necessary functionality to ensure that these services/features are
delivered properly.
Functional requirements

The functional requirements for a system describe what the system

should do. These requirements depend on the type of software being
developed, the expected users of the software, and the general
approach taken by the organization when writing requirements. When
expressed as user requirements, functional requirements are usually
described in an abstract way that can be understood by system users.
Functional system requirements vary from general requirements
covering what the system should do to very specific requirements
reflecting local ways of working or an organization’s existing systems.
For example, the following can be functional requirements for a health care
system used to maintain information about patients receiving treatments for
mental health problems:
• A user shall be able to search the appointments lists for all clinics.
• The system shall generate each day, for each clinic, a list of patients who are
expected to attend appointments that day.
• Each staff member using the system shall be uniquely identified by his or her
eight-digit employee number.

These functional user requirements define specific facilities to be provided by

the system. These have been taken from the user requirements document and
they show that functional requirements may be written at different levels of
detail.
Non-functional requirements
Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific services delivered by the system to its users.
They may relate to emergent system properties such as reliability, response time,
and store occupancy. Alternatively, they may define constraints on the system
implementation such as the capabilities of I/O devices or the data representations
used in interfaces with other systems.
Non-functional requirements, such as performance, security, or availability, usually
specify characteristics of the system as a whole. Non-functional requirements are
often more critical than individual functional requirements. System users can
usually find ways to work around a system function that doesn’t really meet their
needs. However, failing to meet a non-functional requirement can mean that the
whole system is unusable. For example, if an aircraft system does not meet its
reliability requirements, it will not be certified as safe for operation; if an
embedded control system fails to meet its performance requirements, the control
functions will not operate correctly.
Types of non-functional requirements
The figure is a classification of non-functional requirements. You can see from this
diagram that the non-functional requirements may come from required
characteristics of the software (product requirements), the organization developing
the software (organizational requirements), or from external sources:
• Product requirements
These requirements specify or constrain the behavior of the software. Examples
include performance requirements on how fast the system must execute and how
much memory it requires, reliability requirements that set out the acceptable
failure rate, security requirements, and usability requirements.
• Organizational requirements
These requirements are broad system requirements derived from policies and
procedures in the customer’s and developer’s organization. Examples include
operational process requirements that define how the system will be used,
development process requirements that specify the programming language, the
development environment or process standards to be used, and environmental
requirements that specify the operating environment of the system.
• External requirements
This broad heading covers all requirements that are derived from factors
external to the system and its development process. These may include
regulatory requirements that set out what must be done for the system
to be approved for use by a regulator, such as a central bank; legislative
requirements that must be followed to ensure that the system operates
within the law; and ethical requirements that ensure that the system will
be acceptable to its users and the general public.