Running Head: COMP 8731 Software Engineering 1GE

Software Requirement Change Management

Name of Student

Name of Institution
COMP 8731 Software Engineering 1GE

Table of Contents

Introduction (Importance and Challenges of Software Configuration and Change Management). 3

Overview of the Requirement Change Management Best Practices...............................................4

Simple Requirement Change Management Process........................................................................6

Requirement Change Management Tools........................................................................................8

IBM® Rational® ClearQuest®.......................................................................................................8

IBM® Rational® DOORS®........................................................................................................9

Human Factors.................................................................................................................................9

Conclusion.....................................................................................................................................10

References......................................................................................................................................11

Appendix........................................................................................................................................12
COMP 8731 Software Engineering 1GE

Introduction (Importance and Challenges of Software Configuration and Change

Management)

It is common practice for companies and organizations to want the delivery of highly

superior products at the end of the production cycle. Organizations have found themselves

building highly complex software due to factors such as changing of instructions and

requirement changes. Requirement changes is perhaps one of the most unavoidable aspects of

modern software development. The client may introduce new changes or the product may have

to be redesigned to fit a newer scenario. When properly implemented, adjustment of the

requirements can result in even better software products and when not done appropriately, it can

result in devastating returns.

The changes in the requirements are critical in ensuring that the effects that could affect

the performance of the end product are eliminated on time. The product developed will therefore

not just be more customized to the user needs and specifications, they are also significant in

ensuring high efficiency and productivity. The mistakes that would have affected the product’

performance are eliminated on time. There are many advantages that can be harnessed through a

properly managed change process as will be seen later in this discussion.

Some of the fundamental reasons that lead to requirement change adjustments include the

existence or perceived existence of ambiguities in the requirements. Ambiguities can result in

not-so-well developed products and the client may need to clarify. At the same time, the client

may decide to do an overhaul of the needs or the product desired. This may be attributed to

changes in the business goals or other similar changes. The development of the product may

have to adjust due to issues such as the need to comply with legal and ethical requirements,

especially when they were not taken care of in the initial instance.
COMP 8731 Software Engineering 1GE

There are different approaches that have been put forward to address the aspect of

requirement change management. The functional principle behind all of them is the same:

Documenting each and every stage of the change process for future reference is fundamental and

implementing an iterative approach that ensures that all the facets of the change process are

addressed. An example of the most used frameworks is that proposed by CMMI which takes in

consideration each and every critical component of the process in effecting change. In addition to

the models proposed, there are many best practices that have been applied in the wide software

development fraternity to address the change process meaningfully as will be seen in this

discussion.

Overview of the Requirement Change Management Best Practices

Best practices are those behaviors or good procedures that are widely accepted or

regarded as being correct in the management of a scenario. There are many best practices

adopted in the software requirement management domain and the focus has mainly been to

maintain the completeness, accuracy and the adjustments in such a way that they do not cause

jeopardizing outcomes. One of the most regarded best practices is the configuration management

model which entails the identification, the tracking and the management of all the assets in a

project and the changes as they happen. The configuration management model is highly regarded

by both the Capability Maturity Model (CMMI) and the Project Management Book of

Knowledge (PMBOK®) which is developed by the Project Management Institute.

The configuration model details several best practices to managing the change process. It

first proposes that before the changes are effected, a certain level known as the baseline should
COMP 8731 Software Engineering 1GE

be drawn and this should contain a documentation of the different items that entail the project at

that particular time: the software artefacts such as the source core, the matrices and the

documentation at that particular level. It is therefore important to first identify all the items that

are due for configuration at the earliest instance possible, done even before the development of a

system for configuration management for the specific project. The significance of the

identification process arises from the need to pre-plan the number of products due to be delivered

to the customer, and managing the internal works. The baseline can be described as the very

lowest minimum of the project; just when the project has been established but it is still at that

level where changes could be effected easily in accordance with the user needs or other emerging

needs.

A versioning frameworks comes next after the baseline. Indeed, the baseline can be seen

to serve as the very minimum version of the software product and that other versions will be

built based on it in future and in accordance with the changing user specifications. For instance

when the client needs a change to be effected to add a functionality to the product, or that a

certain functionality is deemed necessary or useful to the users, it is effected and versioned as so.

The execution of further changes have to be done in respect to the versioning approach being

implemented. There are many approaches to implementing a versioning mechanism and in most

cases, the users are free to choose whatever works best for them and that which can be tracked

easily. A key best practice in harnessing the power of versioning is ensuring that there is

consistency, and that mutual consensus is put in place before a new version of the product is

rolled out.

Each and every stage of the change process is fundamental and there is need to track

everything and hence implementing a mechanism of tracking the change requests is fundamental.
COMP 8731 Software Engineering 1GE

A change request mechanism can be implemented based on a wide range of approaches. In a

better known approach, the client or any other person who wants a certain change to be effected

first sends a formal request to the entire project stakeholder. The changes and their descriptions

are then logged in for closer scrutiny on their significance, when they they are relevant or not;

and whether they are of high priority or they can wait for a later stage of the project. The changes

are then implemented on the source code, if the project is still at that level, or the current level of

the project copy, and the same is properly versioned.

Reviewing and continuous analysis of the changes is significant. The changes are

documented and filed with the versions clearly clarified. This is essential for future analysis and

for debugging processes in case a problem arises in the future. Allowing the works to be audited

by other experts is significant in determining the veracity or completeness of the project.

Following the changes to the latter is significant to realizing a complete product. These best

practices are based on the CMMI model although they relate closely to the approaches proposed

by both the Project Management Book of Knowledge and the IEEE and that it is important that

they are incorporated when effecting change.

Simple Requirement Change Management Process

There are many ways in which the model described above can be implemented in real

life. in the case of a small project such as a class project involving the development of an online

learning portal, the above steps applies. The main activities of the project entails bringing

together the requirements and development of a portal that can be used for eLearning. The portal

is developed using PHP, JavaScript and other languages, and also entails integration with

databases. The main tools that will be used include WAMP and others. These key requirements

are documented and understood. The development first proceeds with the set instructions until a
COMP 8731 Software Engineering 1GE

base project is developed. A closer analysis or examination of the project can then be carried out.

The base project forms the baseline and then the very minimum version, and the naming

convention can be varied from user to user but the key thing is that concurrency and consistency

have to be characteristic.

As the development is due for changes, the configuration items such as the databases and

the internal states of the project including the source code and the databases have to be

documented. In the case of a formal request by the client, say to add functionalities to allow for

live online streaming of classes, the development team analyses the change to ensure that it can

be implemented and that it won’t cause further problems. The previous version of the project has

to be locked and stored awaiting for the further changes to be built onto it. The team further

ascertains that the change is appropriate and determines how urgent it is before it is

implemented. The change can only be implemented through mutual consensus; some paradigms

such as the SWEBOK proposes voting on it before the change is implemented. When the change

is effected, a set version number is assigned, the changes communicated and applied such that

the teams have only the very latest version of the project. Before the change is rolled out, it has

to be tested to ensure that its functionality is as expected. After all this, the change is documented

in detail and the documentation stored. The change’s performance is tracked for improvement

thereafter. The descriptions and the documentation are stored for future reference. Auditing is

fundamental as it ensures that other concerned parties evaluate the change process for

effectiveness or relevance, and can propose changes involving up to scaling down of a particular

change if it is deemed less relevant.

In the project described, there are many other changes that could be implemented and the

many reasons behind that are defined above. As noted, the changes, if well implemented, have
COMP 8731 Software Engineering 1GE

the significance of adding the needed value to the project hence making it more usable. The

change process described above will be fundamental in adding to the successful implementation

of the project.

Requirement Change Management Tools

With the many internal and external factors to change such as the ones mentioned above,

requirement change is an inevitable subject especially to software development. There are many

tools that have been developed to manage the change process. One organization that has focussed

on developing tools for requirement change management is IBM although there exists many

other vendors that have focused on developing digital requirement change management tools.

Some of the tools that have been developed by IBM for requirement change include:

IBM® Rational® ClearQuest®

This is an enterprise level tool that is focused on the automation of the workflow that has

been developed by the Rational Software arm of IBM. It is a tool that was designed for

tracking of bugs, tracking of changes to the software, automation of processes and

managing the traceability of the lifecycle. It is a renowned tool, adored for its high level of

consistency in the developer world. The tool is best suited for tracking changes to software

as it is able to track defects and the implementation of changes. It is one of the most used

tools in the management of changes in the requirements due to its immense power and

scalable functionality.

IBM® Rational® ClearCase®

IBM® Rational® ClearCase® is a tool that is also widely used in configuration management and

the change processes that happen during such times. The tool has a superior characteristic of
COMP 8731 Software Engineering 1GE

being able to give the expected functionality in formulation and management of the different

versions of the software. It is specifically applied in versioning management, giving the user

optimum control of the files and other assets during the change process. The tool is further

developed to be used for debugging and roll-over processes, to determining the effectiveness of a

change, and for general control over the change process.

IBM® Rational® DOORS®

This is one of the most common software change requirement tools in place today. It was

initially developed to be used for proper work flow management. The tool has functionalities to

flexibly manage and track changes as they happen during the development process and allow for

easy and robust traceability of the processes. The tool is designed to track, capture the changes,

analyse the changes, and allow for proper decision-making. The tool is also significant in the

sense that it ensures that the development is in close observance of the necessary regulations that

are currently in place.

The tool has in the recent past been known to integrate seamlessly with IBM® Rational®

ClearQuest® and the outcome has been a tool that has even more superior functionalities as it

combines the functionalities of the two superior tools. The combination provides a better way to

manage the changes. While there are many more tools available today, the combination of the

IBM® Rational® ClearQuest® and IBM® Rational® DOORS® as mentioned would be the best

bet to change management especially to the case described in the above analysis.

Human Factors

Humans and human error are unavoidable aspects of the change process. Humans are at

the heart of the project creation and oversee the many stages of change that have to be
COMP 8731 Software Engineering 1GE

undertaken. As they work as a team, the way the software developers perceive the different

changes and the way the same is carried out can mean a lot to the outcomes. The level of

openness and communication in the team is also significant to the change process. Effecting the

human factor in the change process is significant to improving the outcomes. Errors in the

execution of the requirements lead to a direct fail in the system, and can therefore not be

overlooked. Humans are the key cause of errors. The above discussion has incorporated the

description of digital tools that are used in the requirement change management process. The

main underlying of the use of automated digital tools has been to ensure high levels of

consistency in service delivery.

Conclusion

Inasmuch as changes are an inevitable occurrence to the development process, it is

important to note that handling the changes in an efficient and holistic manner has the advantage

of ensuring minimal effect on the cost or schedule of delivery of the software. The

implementation of a robust requirement change process is the answer to realizing proper

management of the process as seen in the discussion above. Organizations and teams should

therefore focus on implementing change the right way, taking advantage of the many best

practices that are in place to deliver unmatched value to the stakeholders of the project through

proper change management.

COMP 8731 Software Engineering 1GE

References

Becker, J., Knackstedt, R., & Pöppelbuß, J. (2009). Developing maturity models for IT

management. Business & Information Systems Engineering, 1(3), 213-222.

Team, C. P. (2010). CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software

Engineering Institute.
COMP 8731 Software Engineering 1GE

Appendix

IBM® Rational® ClearQuest® more information can be accessed on:

http://www-03.ibm.com/software/products/en/clearquest

IBM® Rational® DOORS® more information can be accessed on:

http://www-03.ibm.com/software/products/en/ratidoor

IBM® Rational® ClearCase® more information can be accessed on:

https://www.ibm.com/software/products/en/clearcase