BCOM ITM - Principles of Software Engineering

Bachelor of Commerce
in Information and Technology

Management
PRINCIPLES OF SOFTWARE
ENGINEERING
Module Guide
Copyright© 2024
MANCOSA
All rights reserved, no part of this book may be reproduced in any form or by any means, including photocopying
machines, without the written permission of the publisher. Please report all errors and omissions to the following email
address: [email protected]
Bachelor of Commerce
in Information and Technology Management
PRINCIPLES OF SOFTWARE ENGINEERING
Preface ..................................................................................................................................................... 2
Unit 1: Introduction to Software Engineering ............................................................................................ 10
Unit 2: Software Processes ..................................................................................................................... 21
Unit 3: Agile Software development ......................................................................................................... 41
Unit 4: Requirements engineering ........................................................................................................... 57
Unit 5: System modelling......................................................................................................................... 74
Unit 6: Design and implementation .......................................................................................................... 87
Unit 7: System Development ................................................................................................................... 99
Conclusion............................................................................................................................................ 113
i
Principles of Software Engineering
Preface
A. Welcome
Dear Student
It is a great pleasure to welcome you to Principles of Software Engineering (PRSE7). To make sure that you
share our passion about this area of study, we encourage you to read this overview thoroughly. Refer to it as often
as you need to since it will certainly be make studying this module a lot easier. The intention of this module is to
develop both your confidence and proficiency in this module.
The field of Principles of Software Engineering is extremely dynamic and challenging. The learning content,
activities and self- study questions contained in this guide will therefore provide you with opportunities to explore
the latest developments in this field and help you to discover the field of Principles of Software Engineering as
it is practiced today.
This is a distance-learning module. Since you do not have a tutor standing next to you while you study, you need
to apply self-discipline. You will have the opportunity to collaborate with each other via social media tools. Your
study skills will include self-direction and responsibility. However, you will gain a lot from the experience! These
study skills will contribute to your life skills, which will help you to succeed in all areas of life.
The modern world is practically run by computers to the extent that to imagine a life without computers is
extremely difficult. From transport and logistics, to food production, communications, education and
entertainment, we depend on computers more than any other generation. But computers themselves are only
as good as the software which powers them – and developing that software is a complex process which
requires skilled, intelligent, creative and dedicated people.
Around the world there is tremendous need for good software engineers and project managers. This course
is intended to help you, as a future IT professional, to gain a sound understanding of the software engineering
processes from a theoretical as well as practical perspective.
We hope you enjoy the module.
MANCOSA does not own or purport to own, unless explicitly stated otherwise, any intellectual
property rights in or to multimedia used or provided in this module guide. Such multimedia is
copyrighted by the respective creators thereto and used by MANCOSA for educational purposes only.
Should you wish to use copyrighted material from this guide for purposes of your own that extend
beyond fair dealing/use, you must obtain permission from the copyright owner.
2 MANCOSA – Bachelor of Commerce in Information and Technology Management

B. Module Overview
• The module is a 15 credit module at NQF level 7.
This study guide comprises of 7 Units:
Unit 1: Introduction to Software Engineering
In this unit you will be introduced to the concept of software engineering, and why it is a very important field
in the modern world.
Unit 2: Software Processes

In this unit you will become familiar with all the processes that go into the production of a software product,
from inception through deployment.
Unit 3: Agile Software Development

In the modern world, change is inevitable. Software teams need to be able to respond to changes by
adopting software development methodologies which are built to handle change. No software development
methodologies can handle change as effectively as Agile methods.
Unit 4: Requirements Engineering

Before a system can be designed and developed, it is essential to know exactly what the client requires;
any misunderstanding in that regard will certainly lead to disaster. This unit will equip you with the
knowledge, skills and methods to solicit the software requirements from the client and to express them in a
clear, unambiguous manner.
Unit 5: System Modelling

You have gathered the requirements, and the client has verified them. Like the architectural plans for a
house, the system models will aid the development team in building the software system.
Unit 6: Design and Implementation

The system has been designed and modelled – the next step is to build it. At this stage the software team
have to make decisions regarding the architecture of the system, decisions which will have a profound effect
on the development process and the system. In this unit you will be introduced to concepts like UML
diagrams, architectural design, design models and design patterns – all of which are used in the
development of the system
Unit 7: System Development

By this stage you have gained all the knowledge and skills to identify, analyse and design a complete
software system. In this chapter you will practically build a small but complete business software system.
MANCOSA – Bachelor of Commerce in Information and Technology Management 3

Conclusion
This unit provides a quick look into what is in store in Software Engineering Practice.
C. Exit Level Outcomes and Associated Assessment Criteria of the Programme
Exit Level Outcomes (ELOs) Associated Assessment Criteria (AACs)
• The structure of data, information and • Structure of data, information and knowledge is
knowledge in an organisational setting reviewed within an organisational setting to
emphasize data processes
• The application of information and knowledge • Information and knowledge management

management principles and theories in a principles and theories are applied in a variety of
variety of organisational settings organisational settings to eliminate disarray
• The application of information and knowledge • Information and knowledge management

management principles in the different principles is applied in different functional units of
functional units of an enterprise an enterprise to maintain consistency
• The architecture, platforms and configuration • Architecture, platforms and configuration of

of systems to generate information and systems is examined to generate information and
knowledge for decision making knowledge for decision making
• Utilisation of information and knowledge • Information and knowledge management is

management as a strategic tool for applied as a strategic tool for competitive
competitive advantage advantage to promote organisational information
and knowledge management skills
• Analysis, evaluation and representation of • Financial, quantitative and functional information
financial, quantitative and functional and knowledge is analysed, evaluated and
information and knowledge for meaningful presented for meaningful interpretation to
interpretation establish organisational information
and knowledge management needs
• Proposal of business solutions through • Business solutions are proposed utilising
information and knowledge management information and knowledge management
techniques techniques to enhance organisational
performance

D. Learning Outcomes and Associated Assessment Criteria of the Module
LEARNING OUTCOMES OF THE MODULE ASSOCIATED ASSESSMENT CRITERIA OF THE

MODULE
• Explain the principles of software • Principles of software engineering is examined to
engineering understand the steps for development of an IT
business system
• Indicate the steps in the development of an • Steps in the development of an IT business system
IT business system are indicated to set processes of how tasks should be
completed
• Develop an object oriented client/server • Development of an Object oriented client/server
system for the Internet system is explored to reveal some objectives
involving the Internet
• Analyse and develop a prototype of a • Prototype of a business systems is analysed in a
business system in a team relationship team relationship to demonstrate how the real system
will operate once completed
E. Learning Outcomes of the Units

You will find the Unit Learning Outcomes on the introductory pages of each Unit in the Module Guide. The
Unit Learning Outcomes lists an overview of the areas you must demonstrate knowledge in and the practical
skills you must be able to achieve at the end of each Unit lesson in the Module Guide.

F. Notional Learning Hours
Notional Learning Hour Table for the Programme
Learning time
Types of learning activities
%
Lectures/Workshops (face to face, limited or technologically mediated) 15
Tutorials: individual groups of 30 or less 0
Syndicate groups 0
Practical workplace experience (experiential learning/work-based learning etc.) 0
Independent self-study of standard texts and references (study guides, books, journal 27
articles)
Independent self-study of specially prepared materials (case studies, multi-media, etc.) 40
Other: Online 18
TOTAL 100
G. How to Use this Module

This Module Guide was compiled to help you work through your units and textbook for this module, by
breaking your studies into manageable parts. The Module Guide gives you extra theory and explanations
where necessary, and so enables you to get the most from your module.
The purpose of the Module Guide is to allow you the opportunity to integrate the th eoretical concepts from
the prescribed textbook and recommended readings. We suggest that you briefly skim read through the entire
guide to get an overview of its contents. At the beginning of each Unit, you will find a list of Learning Outcomes
and Associated Assessment Criteria. This outlines the main points that you should understand when you
have completed the Unit/s. Do not attempt to read and study everything at once. Each study session should
be 90 minutes without a break
This module should be studied using the prescribed and recommended textbooks/readings and the relevant
sections of this Module Guide. You must read about the topic that you intend to study in the appropriate
section before you start reading the textbook in detail. Ensure that you make your own notes as you work
through both the textbook and this module. In the event that you do not have the prescribed and
recommended textbooks/readings, you must make use of any other source that deals with the sections in t his
module. If you want to do further reading, and want to obtain publications that were used as source documents

when we wrote this guide, you should look at the reference list and the bibliography at the end of the Module
Guide. In addition, at the end of each Unit there may be link to the PowerPoint presentation and other useful
reading.
H. Study Material
The study material for this module includes tutorial letters, programme handbook, this Module Guide, a list of
prescribed and recommended textbooks/readings which may be supplemented by additional readings.
I. Prescribed and Recommended Textbook/Readings

There is at least one prescribed and recommended textbooks/readings allocated for the module.
The prescribed and recommended readings/textbooks presents a tremendous amount of material in a simple,
easy-to-learn format. You should read ahead during your course. Make a point of it to re -read the learning
content in your module textbook. This will increase your retention of important concepts and skill s. You may
wish to read more widely than just the Module Guide and the prescribed and recommended
textbooks/readings, the Bibliography and Reference list provides you with additional reading.
The prescribed and recommended textbooks/readings for this module is:

Prescribed Readings/Textbook(s)
• Sommerville, I. (2021). Engineering Software Products: An Introduction to Modern Software
Engineering, Global Edition. First Edition. Publisher: Pearson.
Recommended Reading(s)
• Sommerville, I. (2021). Engineering Software Products: An Introduction to Modern Software

Engineering, Global Edition. First Edition. Publisher: Pearson.
• Jacobson, I., Lawson, H., Ng, Pan-Wei, McMahon, P.E. and Goedicke, M. (2019). The Essentials of
Modern Software Engineering: Free the Practices from the Method Prisons! First Edition. Publisher:
ACM Books

J. Special Features
In the Module Guide, you will find the following icons together with a description. These are designed to help you
study. It is imperative that you work through them as they also provide guidelines for examination purposes.
Special Feature Icon Explanation
The Learning Outcomes indicate aspects of the particular Unit you have
LEARNING to master.
OUTCOMES
The Associated Assessment Criteria is the evaluation of the students’

ASSOCIATED
understanding which are aligned to the outcomes. The Associated
ASSESSMENT
Assessment Criteria sets the standard for the successful demonstration
CRITERIA
of the understanding of a concept or skill.
A Think Point asks you to stop and think about an issue. Sometimes you
THINK POINT are asked to apply a concept to your own experience or to think of an
example.
You may come across Activities that ask you to carry out specific tasks.
In most cases, there are no right or wrong answers to these activities.
ACTIVITY
The purpose of the activities is to give you an opportunity to apply what
you have learned.
At this point, you should read the references supplied. If you are unable
READINGS to acquire the suggested readings, then you are welcome to consult any
current source that deals with the subject.
PRACTICAL Practical Application or Examples will be discussed to enhance
APPLICATION understanding of this module.
OR EXAMPLES
KNOWLEDGE You may come across Knowledge Check Questions at the end of each
CHECK Unit in the form of Knowledge Check Questions (KCQ’s) that will test
QUESTIONS your knowledge. You should refer to the Module Guide or your
textbook(s) for the answers.
You may come across Revision Questions that test your understanding
REVISION
of what you have learned so far. These may be attempted with the aid
QUESTIONS
of your textbooks, journal articles and Module Guide.

Case Studies are included in different sections in this Module Guide.
CASE STUDY This activity provides students with the opportunity to apply theory to
practice.
You may come across links to Videos Activities as well as instructions
VIDEO ACTIVITY on activities to attend to after watching the video.

Unit
1: Introduction to Software
Engineering

Unit Learning Outcomes
CONTENT LIST LEARNING OUTCOMES OF THIS UNIT
1.1 Introduction to Software • Understand what software engineering is and why it is

Engineering important
• Understand the basic principles of software engineering
1.2 Professional Software • Understand that the development of different types of

Development software systems may require different software engineering
techniques
• Understand some ethical and professional issues that are

important for software engineers
1.3 Summary • Summarise topic areas covered in unit
Prescribed and Recommended Textbooks/Readings
Prescribed Reading/Textbook(s)
• Sommerville, I. (2021). Engineering Software Products: An Introduction

to Modern Software Engineering, Global Edition. First Edition. Publisher:
Pearson.

Pearson.
• Jacobson, I., Lawson, H., Ng, Pan-Wei, McMahon, P.E. and Goedicke,
M. (2019). The Essentials of Modern Software Engineering: Free the
Practices from the Method Prisons! First Edition. Publisher: ACM Books.

1.1 Introduction to Software Engineering

Many aspects of the modern world have been made possible by computers and information technology.
Without the modern computer technology, we see around us, many of the things which make our lives easier
and more streamlined would not have been possible. Computers are being used in diverse applications, like
business, communication, education, research, industry, agriculture, transport and even space travel. In
essence, the modern world is made possible by computers.
Think Point 1.1
A world without computers

Can you imagine a world without computers? Think about the ways in which
your professional and personal life would be impacted if all the computers in
the world suddenly disappeared.
But computers are just machines, and not too different from our household appliances. What differentiates
them from other machines is software. It is the software which gives an otherwise unintelligent machine its
immense capabilities and usefulness. It is because of the software that a computer which is made for ge neric
purposes can be used in highly specialized situations. It is truly remarkable that a single computer may at the
same time be used for accounting, education, surfing the internet, graphic designing, entertainment and
myriad other uses; no other machine or tool created by man could come close to this – and all this is made
possible by software. So it goes to reason that a computer is only as good as the software which it runs.
It comes as no surprise then that software can be really complex, and really difficult to create. Depending on
the type of software system, it could take large teams of people many years to build a single software system.
What makes it even harder is the constant change in the information technology hardware landscape: on an
almost weekly basis, new, faster processors are being developed; computers with ever-increasing memories
and internal storage capacities are being built; smaller computers are being pro duced – and software
developers have to play ‘catch up’ by building software which can take advantage of these technological
advancements.
What is software? Software comprises of computer programs and associated documentation.
What are the Good software should deliver the required functionality and performance to the
attributes of good user and should be maintainable, dependable, and usable.
software?

What adds to the complexity of software is that it is abstract and intangible. You cannot touch or fe el a
software system – it lives and functions within a computer. As a result, software systems are not bound by
the natural constrains which other type of products are; for example, a normal, tangible product like a structure
may be constrained in terms of how large it can be, or by the type of materials that may be used to create it,
and by numerous other limitations. With software none of this applies; a software product is potentially
unlimited in size and complexity. This makes planning and developing a software product very difficult.
The complexity of software, along with the difficulties encountered in building a software system highlight the
need for proper planning, developing and quality management systems to be in place in the software
development process. In other words, there is a strong need for software engineering. Software engineering
is a field of engineering which is concerned with all aspects of software production. Software enginee ring is
the “application of a systematic, disciplined, quantifiable approach to the design, development, operation,
and maintenance of software. Software engineers are people who are trained and skilled in the optimal use
of software engineering practices to produce high quality software. Software engineers, therefore, are not
just computer programmers; they may be programmers, but they also have a thorough understanding of the
principles of software engineering, and the complete life-cycle activities of a software development project,
such as software specification, software development, software validation, and software evolution.
Software Engineering as a career
Working on a large, complex software system is indeed very challenging, but it is also very
enjoyable. Working on a software development team is a very fulfilling and rewarding experience
especially when you consider the teamwork and camaraderie which is built up in the process. It
is a great experience to be an integral part of a team which is focused on a common goal, which
is to produce a quality product.
It is also extremely gratifying to see the product that you and your team have worked so hard to
build is finally put into daily use, and is helping to make people’s lives easier.

In this module we will cover, in great detail, some of the major principles of software engineering, as well as
the stages and activities in the software development life cycle (SDLC). The knowledge and skills gained
from this module will prove extremely valuable in the workplace, where you may find yourself involved in one
of many roles from programmer through project manager, on various soft ware development projects.
1.2 Professional Software Development

In software engineering, there are basically two kinds of software products that are developed:
1. Generic software: these are stand-alone systems that are produced and sold to any customers. In
generic products, the organization that develops the software controls the software specification.
Examples of these are Microsoft Word and Microsoft Excel.
2. Customized software: these are, as the name suggests, customized for a particular target customer’s
needs, specialized market.
An importance difference between these two types of products, for software engineers in particular, is that in
the case of generic software, the company that builds the software controls the software specification; that
is, they determine the functions and features of the system. The customer purchases the software uses the
system as-is, and tries to find ways to adapt to the parts of the software which are not quite to his
requirements. On the other hand, for custom product the specification is controlled by the client. In this case
the software engineers have to get a firm understanding of the client’s requirements, and build the system
accordingly.
Building custom software can be very challenging. In many instances the client himself is not very clear about
the specifications of the system, so it is the responsibility of the software team to fill in the blanks using
various requirements-gathering techniques to get the exact system requirements. In other cases, the client
may understand what he requires, but due to external factors, the specification of the software keeps
changing. In this case, the software engineers have to specify and build the system in such a way that it
embraces the changes as they occur.
The distinction between these two types of system products is becoming increasingly blurred, with many
custom systems now being built with a generic product as a base. An example of this is SAP, which is an
enterprise resource planning (ERP) software system. Many companies purchase SAP and then customize it
to more loosely suit their own needs.
1.2.1 Software engineering

Software engineering, according to Sommerville, can be described as an engineering discipline that is
concerned with all aspects of software production from the early stages of system specification through
designing, developing, operating, and maintaining the system after it has gone into use. By using the term

“engineering discipline” Sommerville alludes to the fact that software engineering is the science and the skill
of acquiring and applying scientific, economic, social and practical knowledge in order to design and build
software applications make them work. Software engineering covers all aspects of software production,
which includes not just development of software, but also the project management of a software throughout
its lifecycle, the tools used in the development stage of these software application, as well as the methods
and theories to support software production. The ultimate aim of software e ngineering is to produce good
software.
What is good software?

The essential attributes of good software are:
• Maintainability: software should be written so it can be easily extended or modified to meet the
changing needs of customers
• Dependability: software dependability means that the software is reliable, secure, and safe
• Efficiency: software should optimize the use of system resources such as memory and processor
cycles and storage space
• Acceptability: software must, most importantly, be acceptable to the clients and the users
Why is software engineering important?

Software engineering is important for two reasons:
1. As mentioned earlier in this chapter, the modern world relies very heavily on software in order to
function. As a result, more than ever we need methods of producing reliable, error -free software
quickly and cheaply.
2. In modern times, with computer systems being more advanced than ever, software systems are
also more advanced, complex and large than before. Whereas in the past it was possible for a
person to sit and type out a program without which planning, in modern times this is just not
possible. We need a more scientific and systematic approach to produce modern software.
The systematic approach that is used in software engineering is called a software process because it is a
sequence of activities that leads to the production of a software product.
The four fundamental activities common to all software processes are:
1. Specification: where customers and engineers define the software that is to be produced and the
constraints on its operation. The specification details the purpose for developing a soft ware
product. The specification is the first thing to be done before starting a project.
2. Development: where the software is designed and programmed. In the development phase, the
design of a product can be modelled to what the product will look like and what the product is to
do.

3. Validation: where the software is checked to ensure that it is what the customer requires. Here is
where the customer makes their final decision. The final product is tested by the customer to
ensure that the product meets all their set requirements as specified at the beginning of the
project.
4. Evolution: where the software is modified to reflect changing customer and market requirements.
The product can be modified to meet another customer’s requirements.
Different types of systems need different development processes. For example, a computer game is quite
different from an accounting package; not surprisingly, the approach to building each one will also be quite
different. Each of the above processes is described in far greater detail throughout this module and the next.
Software Engineering versus Computer Science
The terms “software engineering” and “computer science” are often used interchangeably, but this
isn’t correct. Both computer science and systems engineering are related to software engineering.
Computer science is concerned with the theories and methods that underlie computers and
software systems, whereas software engineering is concerned with the practical problems of
producing software. Software engineering is concerned with all aspects of the development and
evolution of complex systems where software plays a major role.
Although there is no universal software engineering method or technique that is applicable for all software
types, a few general issues affect all:
1. Heterogeneity: a heterogeneous system is one which is required to run on a number o f different
platforms. The following are examples of this:
a. A software may be required to work on a mobile device as well as on a computer
b. A software system may be required to run equally well on various operating systems, such
as Windows, MAC and Linux.
c. A software may be required to integrate with other systems which may be written in a
different language
2. Business and social change: in the modern world, businesses and society are constantly changing,
and these changes are taking place very rapidly. In order for the software to keep up, it needs to
be produced as quickly as possible otherwise it may become outdated before it is even completed!

3. Security and trust: as we become more reliant on software, we tend to place more of our personal
or business-related sensitive information onto these systems. As a result we need secure systems
which can keep this information safe from malicious users.
1.2.2 Software diversity

Software engineering is a systematic approach to the production of software that takes into account practical
cost, schedule, and dependability issues, as well as the needs of software customers and producers. This
approach varies dramatically depending on the organization developing the software, the type of software,
and the people involved in the development process. There are no universal software engineering methods
or techniques. The most significant factor which determines the approach to development is the type of
application.
The following is a list of types of applications:
1. Stand-alone applications: application systems that run on a local computer, such as a PC.
2. Interactive transaction-based applications: applications that execute on a remote computer and
that are accessed by users from their own PCs or terminals.
3. Embedded control systems: software control systems that control and manage hardware devices.
Embedded systems may be found in devices such as MP3 players.
4. Batch processing systems: business systems designed to process data in large batches.
5. Entertainment systems: systems primarily for personal use and which are intended to entertain the
user, such as DVD players and gaming consoles like the Xbox and the PlayStation.
6. Modelling and simulation systems: systems developed by scientists and engineers to model
physical processes or situations. Such systems are CAD (Computer Aided Design) applications.
7. Data collection systems: systems that collects data from their environment using a set of sensors
and send that data to other systems for processing.
8. Systems of systems: systems composed of a number of other software systems.
Naturally, different software engineering techniques will be used for each type of system because each type
of software has quite different characteristics. For example, an embedded control system in an automobile is
safety-critical and is burned into ROM when installed in the vehicle. In such a system, extensive planning
needs to take place in order to ensure that the software has absolutely no defects, otherwise this could lead
to disastrous consequences like accidents and factory recalls.


When software malfunctions
There are many instances in recent history where software flaws have led to
major disasters. Search the internet and read up about a few such incidents.
Although there are different approaches to different types of software, there are software engineering
fundamentals that one must consider no matter what the type of software:
• They should be developed using a managed and understood development process
• Dependability and performance are critical for all systems. Systems should perform efficiently and
should not waste resources
• Understanding and managing the software specification and requirements are important. The end
product should be a useful system that can be delivered within budget and to schedule
• The development team should make effective use of existing resources. As far as possible, they
should reuse software that has already been developed rather than reinventing the wheel
These fundamental notions of process, dependability, requirements, management, and reuse underlie all
professional software development.
1.2.3 Software engineering and the Web

The web has dramatically changed how software is developed and used. Whereas traditional stand -alone
software systems were deployed on a single computer, web-based systems are deployed on a server, and
accessed over the Web with browsers. Web-based software is available for use by any number of people, on
a global scale. It can also be accessed by the developers from anywhere in the world. This made it cheaper
to change and upgrade and also reduced costs.
Web services are software components that deliver specific, useful functionality and which are accessed over
the Web by other software systems. Applications can be constructed by connecting multiple web services,
each of which may be provided by different companies. Depending on the extent to whic h the web services
are used, there may not be a need to write any code at all.
The web has also led to the advent of software as a service; that is, software that does not run on local
computers, but will run on servers and accessed over the Internet. Companies and individuals may use this
software for a pay-per-use fee or a monthly fee – there is no need to purchase the software. The major
advantage of this is that all upgrades to the system are done on the server, and the clients benefit from the
upgrades instantly, and without being required to perform any upgrades on their computers.

Cloud computing and big data

Two of the latest trends in information technology are cloud computing and big
data. Research each of these concepts and write at least ten lines on each of
them. The internet will be your most valuable source of information.
1.3 Summary
• Many aspects of the modern world have been made possible by computers and information
technology, which in turn is powered by software
• Software can be really complex, and really difficult to create, and thus needs proper planning,
developing and quality management systems to be in place in the software development process –
this is the function of software engineering
• Software engineering can be described as an engineering discipline that is concerned with all
aspects of software production from the early stages of system specification through designing,
developing, operating, and maintaining the system after it has gone into use
• There are basically two kinds of software products that are developed:
o Generic software
o Customized software
• The essential attributes of good software are:
o Maintainability
o Dependability
o Efficiency
o Acceptability
• Four fundamental activities common to all software process are:
o Specification
o Development
o Validation
o Evolution
• There are many different type of software, and each type requires a different approach to
development:
o Stand-alone applications:
o Interactive transaction-based applications:
o Embedded control systems
o Batch processing systems
o Entertainment systems
o Modelling and simulation systems

o Data collection systems

o Systems of systems
• The web has dramatically changed how software is developed and used.
1.4 Revision Questions

1. Explain why professional software is not just the programs that are developed for a customer.
2. List and explain the essential attributes of good software.
3. What is the most important difference between generic software product development and custom
software development? What might this mean in practice for users of generic software products?
4. List and describe the four fundamental activities common to all software processes.
5. What are the four important attributes that all professional software should have? Suggest any other
attributes that may sometimes be significant.
6. Explain how the universal use of the Web has changed software systems.

Unit
2: Software Processes

2.1 What is a Software Process • Understand the concepts of software processes and
software process models
2.2 Software Process Activities • Have been introduced to three generic software process
models and when they might be used
2.3 Types of Process • Know about the fundamental process activities of software
requirements engineering, software development, testing,
and evolution
2.4 Software Process Models • Understand the software process models
2.5 Managing Change in Software • Understand why processes should be organized to cope
Processes with changes in the software requirements and design

Pearson.

Pearson.
Practices from the Method Prisons! First Edition. Publisher: ACM Books

Software Processes
2.1 What Is a Software Process?

A software process is a set of related activities that leads to the production of a software product. A process
essentially defines a step by step “recipe” for successfully building a software product which is bug -free, fulfils
all requirements, and is within budget and within the allocated time. This may seem simple enough, but when
you consider the large number of software development projects which fail, or go beyond budget and over
time, it becomes very clear that a software development project is far more complex than most people think.
Practical Application or Examples 2.1
What went wrong?

In one of the biggest software errors in banking history, Chemical Bank mistakenly
deducted about $15 million from more than 100 000 customer accounts. The problem
was the result of a single line of code which resulted in each transaction done at an
ATM machine being recorded twice by the bank’s system. In other words, if a person
withdrew $100 at an ATM, the system would record 2 withdrawals of $100.
There are many such incidents, all of which go to prove that a tiny problem in software
could cause major problems.
What makes software development even more complex is that software is very diverse. There are dozens of
different types of software, from a basic fun app on a mobile device to the controlling system on an airplane.
Because the types of software are so diverse, they cannot all be created using the same processes; each of
these types of software is developed in a different way because they have different scopes, different sizes,
different requirements etc.
As a result of this complexity, it is necessary to have a systematic approach to building a software product,
without which there is a very strong chance that the project will fail. A good system will take into consideration
all factors which need to be considered, such as user requirements, budgets, availa ble resources and, very
importantly, change management.
But a complete software product includes more than just a computer program; it includes the program plus
associated documentation and configuration data which are required to make the program operate correctly.
As a result of this, a software process will include more than just programming; it will also include the
preparation of documentation, testing, communicating with the client, and a whole array of other activities.

Although there are many software development processes, all processes include four fundamental steps
which are fundamental to software engineering:
1. Software specification: this describes what exactly the software should do, and what are the
internal as well as external requirements for the software to run effectively
2. Software design and implementation: Based on the specification given, the software is designed
and created, and deployed into its working environment
3. Software validation: The software must be tested to see that it is bug free, and that it does what it
was intended to do
4. Software evolution: The software must be constantly improved to meet the changing needs of the
environment in which it is used
The above is a highly simplified description of a software process. In reality, each of the above steps is in
itself a very complex activity, with numerous sub-activities. Besides activities, a process will also include the
following:
1. Products: what will be produced at the end of each step in the process?
2. Roles: who will be the people involved in the project, and what will each person’s part be in the
process?
3. Pre- and post-conditions: What are necessary conditions that need to be fulfilled prior to
commencing a step? What are the conditions which must be fulfilled by the end of the step?
As you can see, software processes are quite complex, intellectual and creative processes. At each stage,
challenges are encountered, thus various ideas have to be thrown in, and decisions have to be made on
which would be the best way to overcome the challenges. Unlike other engineering fields, in software

engineering there really is no ideal process that can be followed ‘step-by-step’ to ensure success. Over time,
software engineers have introduced various processes which may be used in different circumstances, based
on the type of system being developed.
2.2 Software Process Activities

The software development process is quite complex, and each of the four steps mentioned in the previous
Unit can be further broken down into smaller activities. In this Unit we will look at each of the four fundamental
software engineering steps in more detail.
2.2.1 Software specification

Software specification, or requirements engineering, is the process of clearly understanding and explicitly
defining what services are required from the system to be developed, and identifying the constraints on the
system’s operation and development. It is at this stage that the system is described. It is for this reason that
this is a critical stage in the development process, since any mistakes or omissions at this stage will be carried
forward to the following steps.
There are usually two views of the requirements of a system:

1. High-level view: this is an overview, without any technical details. The end users and customers
need a high level view of the specifications. They are primarily concerned with what the system
should do, not how it will do it.
2. Detailed view: The development team needs to have a much more detailed view of the system, as
they will be the ones who will be building it. They are the concerned with how the system functions.
The requirements engineering step has four main activities:

1. Feasibility study: Does the organization really need a new software application, or can the existing
system be modified to do the job? Will developing a new system be a financially viable option? Is
there enough money to build it? Are there cheaper options available, like purchasing a n off-the-shelf
package? These are some of the questions which are answered during this activity. The outcome of
this activity is a clear direction on whether the software project should proceed or not.
2. Requirements elicitation and analysis: once feasibility of the system is established, the next logical
step is to get a better understanding of the system requirements. In this activity the team will use
various methods such as observation, discussions with stakeholders and users, task analysis,
system modelling and prototyping to get a good understanding of the system.
3. Requirements specification: In this activity the findings of the previous activity are formalized and
presented in the form of a document.

4. Requirements validation: during this activity the requirements document is thoroughly checked by all
stakeholders to see that the requirements are realistic, consistent and complete. Any errors or
omissions must be corrected before moving on to the next step.
In practice the above activities need not necessarily be completed in sequence; the team may go back and
forth between them.
2.2.2 Software design and implementation

In this stage the hard core programming of the software system begins. This stage is concerned with
converting the specifications into a usable system. The inputs, activities and outputs of this step are shown
in the following diagram:
Aside from the requirements statement, the other inputs for the design step are the platform information and
data description. Platform refers to the underlying hardware and software which are required by the system
in order for it to run. Will the system run on a local machine or on the web? Will it run on a Linux -based system
or a Windows based system or some other operating system? Will the system integrate with existing systems,
and if so, which systems? These are all platform-related issues which need to be addressed before
development of the system.

If the system is going to work with data, then the specifications of the data should be included with th e
requirements specification.
As with all other steps in the development process, in practice the activities in this step are not performed in
a sequential manner as shown in the diagram. There is usually a lot of back -and-forth between the activities,
as errors and omissions are detected.
In general, the design and implementation step comprises of four activities:

1. Architectural design: here the overall structure of the system is determined, along with all the
components which will be required.
2. Interface design: this activity determines how the various components will interact with one another.
Software components such as classes interact via their interfaces. An interface is a set of rules which
a component exposes to other components, which state exactly what the component can do, and
how other components may interact with it.
3. Component design: each component of the system is designed
4. Database design: if an existing database is to be used, then this activity will determine exactly how
the new system will interact with it. If a brand new database is to be created for the new app, then
during this activity the team will be concerned with the data structures which will be utilized by the
system, as well as how the data will be stored in the database.
The outputs of this step are shown in the diagram, although these may vary depending on the type of
system being developed.
2.2.3 Software validation

The primary task during the software validation step is to ascertain two things:
1. That the system fulfils its requirements
2. That the system meets the expectations of the client
This stage is also known as verification and validation (V & V). There are many ways of testing a system,
such as program testing, where the system is run using simulated data. Other ways of testing are code
inspections and reviews.
If any defects are found in the system, the program is debugged and testing is repeated until no more bugs
are found. The process is an iterative one.
Testing of a system generally occurs in three stages:
1. Development testing: this type of testing is typically done by the programmers, and is where each
component is tested individually. Development testing is normally done during the implementation
stage, as each component is developed.

2. System testing: after individual components have been created and independently tested, they are
integrated to form a complete system. Even though each component may be bug free, it is highly
possible that certain bugs may arise when they attempt to interact with each other as parts of the
greater system. At this level system testing takes place. System testing is concerned with finding
errors which may occur as a result of the interactions between components of the system.
3. Acceptance testing: at this stage the system is tested by the client with real data, not simulated data.
Acceptance testing is concerned with detecting errors and omissions in the system requirements. It
is possible that the system is completely bug-free, but has totally left out certain required functionality
– this will be detected at this stage.
2.2.4 Software evolution

Once a software system is deployed, it enters a new phase: software evolution. This stage is primarily
concerned with two activities: bug fixing and software upgrading.
Once a system has been deployed into the working environment, certain errors may be fo und which somehow
slipped through during the testing stages. The system then needs to be debugged and retested.
Over time the software system may require upgrades due to a number of factors, such as changing business
requirements and changing hardware specifications. If the system integrates with other systems, then
changes in the external systems may necessitate changes to the in-house system.
No matter what the case, software evolution is an inevitable process in the life of any software system.
2.3 Types of Process

Although there are numerous software processes available, each may be categorized as one of the following:
1. Plan-driven process: these are processes where all the activities are planned in advance, and
progress is measured in terms of this plan. Plan-driven processes closely resemble a construction
project, where the plans are drawn up, material s and costs are estimated, time scope is worked out,
etc. before commencement of the actual project.

2. Agile processes: as the name suggests, these processes are very flexible. There is a minimal amount
of initial planning, and the project is carried out in an incremental manner, which means that it is
completed in small steps.
3. As mentioned earlier, there is no ideal “one size fits all” process, and each type of process is suitable
for a different type of project.
Process Standardization
There are literally dozens of different processes which a software team may follow when
developing a software system. As a result of the vast number of processes a vailable,
organisations may become overwhelmed with the choices, and disagreements may arise. In order
to eliminate this, an organisation may adopt a handful of processes, and build all its software
around its adopted processes. The organization may also improve the processes by customizing
them according to its own needs. This is known as standardization.
Standardization is a good software engineering practice, and leads to greater economy, for a
number of reasons:
1. No time is wasted in deciding which process to use

2. There is improved communication
3. Training time is reduced
2.4 Software Process Models
Software process models

Study Sommerville to get a good understanding of software process models.
A software process model is a simplified representation of a software process. There are various different
software process models, and each looks at the process from a different perspective. For example, a process
activity model will show all the activities and their sequence, but not the roles of the people involved.
In this Unit we will look at three such models. Bear in mind, though, that these model are not definitive
descriptions of process models. Rather, they present various ways to approach the software process, and
each may be adapted and extended to suit the needs of a project.

1. The Waterfall Model: This presents a linear and sequential process. That is, each of the software
process steps of specification, development, validation, and evolution are done one after the
other, and each one is completely done before moving on to the next. This model is typically
used in large software projects, and in projects where the requirements are well-understood.
2. Incremental Development: In this approach the system is developed as a series of versions, with
each version adding more functionality than the previous version.
3. Reuse-oriented software engineering: In this system, rather than building an app from scratch,
existing components are combined together to form a new system, very much like Lego bricks.
The components may even be complete apps in themselves.
Each of these systems may be used exclusively, but a more common approach is to use them together. For
example, the Waterfall model may be combined with the re-use oriented approach in certain projects.
2.4.1 The Waterfall Model
The waterfall model

Study Sommerville.
The Waterfall Model is an example of a plan-driven process, which means that each step needs to be planned
prior to working on it. The steps in the Waterfall Model can be represented as follows:
Requirements
Analysis and
Definition
System and
Software Design
Implemenation
and Unit Testing
Integration and
System Testing
Operation and
Maintenence

Each of the above steps is explained below:

1. Requirements analysis and definition: The system specification is produced in this stage. The system
specification outlines what the system is going to do, what its constraints are, etc.
2. System and software design: Where the requirements step above is concerned with what the system
needs to do, this step is concerned with how the system is going to do what it does. The overall
system architecture is established in this step.
3. Implementation and unit testing: The software goes from design to development. Each separate unit
of the system is tested to check that it is bug free.
4. Integration and system testing: The individual parts of the system are integrated together, and the
system is tested as a whole.
5. Operation and maintenance: The system is placed into normal use, and on-going maintenance takes
place. Maintenance comprises of fixing bugs which may not have been picked up during
development, as well as improvements to the system which became necessary due to changes in
the operational environment.
Disadvantages of the Waterfall Model

Theoretically the Waterfall Model may seem ideal, but in reality software the development process cannot
work in the way required by this model. In practice, it is difficult to round off one step completely before
moving on to the next one. There is always an overlap between the stages. For example, if during design
errors are found with the requirements, it is necessary to go back into the requirements step and fix those
errors. In a realistic software project, there is a lot of back-and-forth movement between stages.
Another problem with the waterfall model is that the cost of producing and approving the documents is quite
high, and involves significant work. The documentation required for each stag can amount to hundreds of
pages, and could take weeks if not months to complete.
The waterfall model is quite inflexible, and cannot handle changes very effectively. Any change that is
introduced into a step after the team has moved on to the next step will be very expensive to implement.
The waterfall model should only be used where the requirements are well-understood, and no change
whatsoever is expected.
2.4.2 Incremental development
Incremental development
Study Sommerville to get a deeper understanding of incremental development.

In incremental development, an initial implementation of the system is developed, and this is presented to
the users for feedback; and based on feedback received from the users, the system is continuously evolved
until it reaches perfection. This results in rapid and timely feedback from the user. Specification, development
and validation are all performed in an overlapping manner.
The incremental development process is illustrated in the following diagram:
The previous diagram is explained as follows:

Once the initial outline description of the software application is received, the team goes through the first
iteration, stepping through the specification, development and validation stages to produce that iteration.
Usually, the first iteration will incorporate the most important functionality. The outcome of the first iteration
is the initial version of the app, which is presented to the user for feedback.
Based on the feedback received, the team then goes through the next iteration, implementing those i tems
which were recommended by the user at the end of the first iteration. The next version of the application is
then produced, which is then presented to the user.
In this way the application goes through multiple versions until the final version is pro duced.
The incremental development model has three important benefits compared to the waterfall model:
1. Change is cheaper: because the software is developed iteratively, in relatively small stages, if there
are any changes required in the previous stages, the cost of redoing the analysis and documentation
is much lower.
2. Customer feedback: because the software is presented to the user at each the end of iteration, the
user has something tangible to evaluate, rather than just documentation. As a result, the u ser can
provide important feedback.
3. Rapid delivery and deployment: with each iteration, the customer receives a fully -functional version
of the software which, although it has limited functionality, is something the customer can use.
Customers are happy with this, as they can see progress and gain value from their investment at a

very early stage, as compared to the waterfall model, where the customer has to wait until the very
end to see anything at all, which could take weeks or months.
Think Point 2.1
Problem solving in everyday life

Think about the ways in which we as humans solve general problems on a daily
basis – that is, when we encounter a problem, how do we go about solving it?
Do we use an approach which is similar to the waterfall approach, or one which
is similar to the incremental approach?
Disadvantages of the Incremental Model

Despite its advantages, the incremental model has a few drawbacks, but this is primarily due to bureaucracy
in organizations. Many organizations have implemented bureaucratic procedures which require a more formal
approach to all projects, including software projects.
From a management perspective, the incremental approach presents two problems:
1. System degradation: as more and more increments are added, and the system becomes bigger and
bigger, the overall structure of the system degrades.
2. Process is invisible: managers require the documentation to be delivered early in the process. With
incremental development, this will mean producing new documentation every couple of weeks, which
will be very difficult and costly to do, and is hence left out.
The incremental approach is not very well suited for large, complex, long-lifetime projects where different
teams develop different parts of the system. Systems of those types typically require a more stable framework
for development.
2.4.3 Reuse-oriented software engineering

Reuse-oriented software development focuses on using ready-made components to build a software
application. Sometimes these components may have been written in-house for some other project and reused
by the team for the current project. At other times, the team may acquire the required components from third-
party sources. These components may be available for free, or may be purchased.
There are three types of reusable software components:
1. Stand-alone software systems: the team may purchase a commercially available software application
(COTS or commercial off-the-shelf systems) and extend these systems to suit the needs of the client.
This is very common.

2. Collections of objects: programmers often acquire classes which have been written by other
programmers, and then integrate those classes into their own programs. There are literally thousands
of such classes available for download.
3. Web services: these are software components which live and function on the web. They do not need
to be downloaded and integrated into the system to be used. They typically expose a set of functions
which are invoked via the web.
Software reuse has the major advantage of reducing time and thereby costs incurred in developing a system.
Like a pre-fabricated building, the components need not be built from the ground up, but are merely joined
together, saving a lot of time and money.
Software reuse is most often used with other development processes such as the waterfall model and
incremental development.
2.5 Managing Change in Software Processes

In the world of business, change is a fact of life; and as a business changes, its requirements for the software
system will naturally change. As a result, the software development teams have to prepare for change to t he
requirements at any stage during or after the development process.
Some software development methods adapt well to change, while others resist it. For example, the waterfall
model does not respond well to change. Any changes which need to be made down t he line are complex and
expensive due to the rigidity of the model. It is for this reason that the waterfall model is suited only to those
projects where the requirements are well-known, and no change is anticipated.
In realistic projects, though, the requirements are almost never well-defined, and in many cases the client is
not even certain about what is required out of the system. Furthermore, there is almost always a possibility
of shifting requirements – things which are added, removed or modified later in the game. In order to respond
to such environments, the software team needs to choose a software development method which makes it
possible to easily adapt to change. In this Unit we will look at two such models:
1. System prototyping: this involves building a crude but functional prototype of the actual system,
and presenting it to the users to evaluate.
2. Incremental delivery: the system is developed and delivered to the users in multiple small
increments in order to facilitate quick user feedback.

2.5.1 Prototyping
Prototyping
Study Somerville to get a good understanding of prototyping.
A prototype, according to Sommerville, is an initial version of a software system that is used to demonstrate
concepts, try out design options, and find out more about the problem and its possible solutions. Prototypes
are particularly useful in scenarios where even the client is not fully certain of the system requirements. By
creating a prototype and having the user experiment with it, the team provides the client with something real
and tangible to use and evaluate, rather than just documentation.
Prototypes can be built for just about any part of the system, such as the user interface and the database. In
the case of the user interface in particular, prototypes are an extremely useful way to “home in” on what the
user wants. In certain cases the prototype is developed not for the client’s benefit, but for that of the team.
This will occur in situations where the team needs to evaluate multiple possible implementation options, and
are not sure which is the most appropriate. In such cases, creating and running a prototype of each possible
option will give the team a much better idea of which option is the most suitable.
Some of the benefits of prototyping are listed below:
1. By using a prototype, users may get new ideas for requirements

2. A prototype helps users determine the strengths and weaknesses of the system
3. A prototype may reveal errors and omissions in the system requirements
4. A function described in a specification may seem useful and well defined, but when that function is
combined with other functions, users often find that their initial view was incorrect or incomplete.

The following diagram illustrates the process model for prototyping:
The process activities are explained below:

1. Establish prototype objectives: why is the prototype being created? What does the team hope to
achieve by it? These questions need to be answered clearly prior to the prototype being built;
otherwise the process may be futile.
2. Define prototype functionality: this stage is a bit tricky. It is important to remember that the prototype
is not the real system, and in all probability is going to be discarded once the system is developed.
As such, the prototype should include only so much functionality as is necessary to fulfil its
objectives, not more, not less.
3. Develop prototype: this may be done using rapid prototyping tools
4. Evaluate prototype: the prototype is evaluated against the initial objectives which were laid out. The
prototype is then exposed to the user, and training is provided to the user on usage of the prototype.
Like all development methods, prototyping does have its drawbacks, which are listed below:
1. The prototype may not be used in the same way as the real system
2. The user who tests the prototype may not be a typical user of the system
3. The time taken to train the user on usage of the prototype may not be sufficient.
4. If the prototype is slow, the users may adjust their way of working with it, and when the final system
is implemented, they may use it in the way they did the prototype.
5. In some cases, managers may demand that the development team keep the prototype and
implement it as part of the system, rather than discarding it.

2.5.2 Incremental delivery
Incremental delivery
Study Sommerville to get a better understanding of incremental delivery..
Incremental delivery, according to Sommerville, is an approach to software development where some of the
developed increments are delivered to the customer and deployed for use in an operational environment.
The following diagram illustrates the process model for incremental development:
The diagram is explained below:

1. Define outline requirements: at the beginning of the process, the client prepares a prioritized list of
the required functionality of the system. This list is then used to define the outline requirements,
and these requirements are listed in priority order.
2. Assign requirements to increments: next, the team will determine which functionalities from the
client’s list will be implemented in each increment. The functionality with the highest priority will be
implemented in the earlier increments.
3. Design system architecture: the architecture of the overall system is determined.
4. Develop system increment: the increment is developed
5. Validate new increment: the new increment is validated in isolation
6. Integrate increment into system: once the new increment has been validated, it is integrated into
the larger system

7. Validate system: the natural next step is to validate the entire system with the new increment
added on.
8. Deploy increment: if all goes well with the validation, the increment is deployed into the client’s
working environment.
From this stage forward, the process is repeated until the system is completed.
Some of the advantages of incremental delivery are mentioned below:

1. Customers can use early increments in very much the same way that prototypes are used: to get a
better idea of the requirements. The advantage over prototypes, however, is that they are parts of
the actual system, and are not thrown away.
2. It is relatively easy to incorporate changes into the system, because the system is developed in small
increments.
3. Customers receive value at an early stage – they do not have to wait until the entire system is
developed. They can begin using the system from the first iteration
4. The highest priority functions of the system are developed first, and are tested and re -tested with
each subsequent iteration until the system is completed. As a result, these high-priority functions are
tested more than other parts of the system.
There are, however, certain problems with incremental delivery:

1. Most companies require a full set of specifications to be drawn up pri or to commencement of work
on a system, for budgetary and other reasons. In incremental delivery, the specs are drawn up as
the system is developed, so there is no up-front specification document. This may be difficult for
these companies to accept.
2. In cases where a new system is being built to replace an older one, users may not be happy to move
gradually from iteration to iteration: they will be happier to receive another fully -functional system in
place of the old one.
3. There are certain parts of a system which are required by many other parts. In incremental delivery
it may be difficult to implement such parts of the system.

Activity 2.1
Prototyping, incremental delivery or neither?

Consider the following scenario: You are the head of a software development team,
and you have been given the task of creating following software products for different
clients:
1. An ecommerce system for a retail business
2. A student management system for a university
3. An on-board flight control system on an aircraft
Explain in each of the above cases, which of the processes you will use: prototyping
or incremental. Provide a detailed explanation on your choice. If you feel that neither
will be suitable, then too, provide a detailed explanation.
You will find suitable guidance on this in Sommerville
There is also ample information available on the internet.
2.6 Summary
• A software process is a set of related activities that leads to the production of a software product
• Although there are many software development processes, all processes include four fundamental
steps:
o Software specification
o Software design and implementation
o Software validation
o Software evolution
• Software specification, or requirements engineering, is the process of clearly understanding and
explicitly defining what services are required from the system to be developed, and identifying the
constraints on the system’s operation and development
• In the software design and implementation stage the task of programming of the software system
begins
• The main task during the software validation step is to ascertain two things:
o That the system fulfils its requirements
o That the system meets the expectations of the client
• Once a software system is deployed, it enters the software evolution phase, which is primarily
concerned with two activities:
o Bug fixing
o Software upgrading

• Although there are numerous software processes available, each may be categorized as one of the
following:
o Plan-driven process, for example the waterfall model
o Agile processes, for example incremental development
• Reuse-oriented software development focuses on using ready-made components to build a
software application
• In environments where the requirements of the system are continuously changing, a development
approach which is suited to change should be used, such as:
o System prototyping
o Incremental delivery
• A prototype is an initial, trial version of a software system that is used to demonstrate concepts, try
out design options, and find out more about the problem and its possible solutions
• Incremental delivery is an approach to software development where the software is developed and
delivered to the customer in small increments and deployed for use in an operational environment

1. List and briefly explain the four fundamental steps which are part of every software engineering
process.
2. Describe the two views of the requirements of a software system.
3. Explain why incremental development is the most effective approach for developing business
software systems.
4. List the four activities which make up the design and implementation stage
5. What is software validation? What are its primary tasks?
6. List the three stages of software testing.

Unit
3: Agile Software
Development

3.1 Introduction • Introduce topic areas for the unit
3.2 Agile Methods • Understand the rationale for agile software development
3.2 Plan- Driven and Agile methods, the agile manifesto, and the differences between
Development agile and plan-driven development
3.4 Extreme Programming • Know the key practices in extreme programming and how
these relate to the general principles of agile methods
• Be aware of the issues and problems of scaling agile
development methods to the development of large software
systems

Pearson.

Pearson.

3.1 Introduction
Agile Software Development
In the previous chapter we looked at various approaches to developing software. In the course of that
discussion we came across incremental development methods, which are ideally suited to the ever -changing
modern information technology landscape, which led to their widespread popularity globally. Among the family
of incremental development approaches, none is as widely accepted and favoured by software developers
worldwide as the Agile approach. In this chapter you will learn what the agile app roach is, and why it is so
popular.
Think Point 3.1
Why software engineering is much more complex than other forms of engineering
It is common knowledge that the information technology landscape is constantly changing and
evolving; in accordance to Moore’s law, computers are becoming faster, more powerful and
cheaper to build on a monthly basis. All the time new types of hardware are emerging, which
render previous types null and void.
This constant change makes life much more difficult for software engineers, as compared to
engineers who are involved in other fields. As an example, consider a hypothetical scenario
where structural engineers have to build a bridge in a fictitious world which is as volatile and ever-
changing as the information technology world.
The engineers would almost impossible challenges, like the following:

a. Every few months, the consistency of the ground changes. Sometimes it becomes
softer, and sometimes harder
b. The landscape also changes quite regularly – the ground under the bridge increases
and decreases in altitude
c. The materials which are used to build the bridge go through constant upgrades – every
few months a new type of concrete is released, and older types become outdated
d. The client decides half way through the project that they will require six traffic lanes on
the bridge, rather than the previously planned four.
e. The types of vehicles which will use the bridge keep getting smaller, requiring
adjustments to the lane widths
Can you imagine how difficult it would be for the engineers to build a bridge under such
circumstances? You may be thinking at this stage that it may just be impossible to do so.
However, in the field of software engineering, similar changes are taking place all the time, and
software engineers are expected to deal with them!

With the rapidly changing world of today, rapid development and delivery is a most critical requirement for
software systems.
What do we mean by “Agile”? Agile or agility is the ability to appropriately respond to change. Change is
what software development is very much about. Changes in the software being b uilt, changes to the team
members, changes because of new technology, changes of all kinds that may have an impact on the product
they build or the project that creates the product. This is what can be referred to as Rapid system/software
development.
There are different approaches to rapid software development, but all share a set of fundamental
characteristics:
1. The processes of specification, design, and implementation are interleaved. In other words, there is
no set specification that a software development team sticks to. The user requirements document
only defines the most important characteristics of the system. This development is a continuous
process.
2. A system is developed in a series of versions, in which end-users and all stakeholders are involved
in specifying and evaluating of each version.
3. System user interfaces are often developed using an interactive development system, such as
allowing the interface design to be quickly created by drawing and placing icons on the interface.
Agile development is an increment development method. The increments are usually small, and new releases
of the system are created and made available to customers every two or three weeks. Customers and
relevant stakeholders are involved in this development process to get rapid feedback on the changing
requirements. This type of informal communication minimizes documentation and formal meetings with
written documents.
3.2 Agile methods

Agile software development is an approach that came to be defined by the published Manifesto of Agile
Software Development; a manifesto that came into existence by a group of software developers.

The philosophy behind agile methods is reflected in the Agile Manifesto:
The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others to do it. Through
this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The manifesto explains the meaning of each of the previous four items as follows:
1. Individuals and interactions: while self-organization and motivation are important, interactions with
team members, or other stakeholders, members of the project are as well important. Pair
programming is a common interaction in agile development.
2. Working software: this is more advantageous and more welcoming over many, many pages of a thick
document that the end-user may never read when time to implement and over presenting documents
to clients in meetings.
3. Customer collaboration: all the requirements that should generally go into developing a software
product cannot be fully collected at the beginning of the software development lifecycle as there will
always be something that the customer may have forgotten to mention at the beginning of the
lifecycle and only thinks about it half way through the lifecycle process. For this purpose, continuous
involvement with customers and stakeholders is very important.
4. Responding to change: this is what agile development is all about; quick response to change and
continuous development.
The best known agile method is Extreme programming. Others include Scrum, Crystal,

Adaptive Software Development and Feature Driven Development.
Agile methods
Research and write a detailed description of each of the following agile
methods:
1. Scrum
2. Crystal
3. Adaptive Software Development
4. Feature Driven Development
Agile methods have become very successful in recent years, but they are particularly useful in the following
types of projects:
1. Small or medium-sized products
2. Off-the-shelf products
3. Custom products which are being developed for a specific client, but where there is clear commitment
from the user, and the software is not constrained by many external rules.
The principles of agile methods are:

1. Customer involvement: it is essential to involve the customer closely throughout the development
process, to provide and prioritize requirements and evaluate the iterations of the system.
2. Incremental delivery: the software is delivered in small increments rather than as a complete product.
Each increment will include a small number of new functions and features. It is the client’s
responsibility to state which functions and features will be included in each increment.
3. People not process: the focus is on people. Each team member brings his or her own talents and
skills to the table, and this is recognized and leveraged for the good of the project. All members are
hence left to develop in their own ways and there are no prescriptive processes.
4. Embrace change: rather than avoiding change, agile methods take it for granted that there will be
changes in the project, and so forces the team to design the system in such a way that it
accommodates change.
5. Maintain simplicity: focus on simplicity in both the software being developed and in the development
process.

Customer
Simplicity Incremental
Agile
Change People
Disadvantages of Agile methods

Whereas agile methods have numerous advantages, they do present certain challenges, as described below:
1. Customer involvement is not always possible: while involving customers in the development process
is indeed an attractive idea, its success depends on having a customer who is willing and able to
spend time with the development team and who can represent all system stakeholders. This is not
always possible, because the customer representatives are frequently subjected to other pressures
and cannot take full part in the software development process.
2. Incompatible personalities: individual team members may not have suitable personalities for the
intense involvement that is typical of agile methods, and therefore may not interact well with other
team members.
3. Prioritization difficulties: prioritizing changes can be extremely difficult, especially in systems for
which there are many stakeholders, with each stakeholder typically giving different priorities to
different changes. Maintaining simplicity would require extra work.
4. Culture clash: it can difficult for many companies to move from their culture of following and defining
processes to a working model in which processes are informal and defined by development teams.
5. Costing and contractual issues: as mentioned previously, an agile method, there is no detailed
requirements document which is prepared from the outset; rather, the document is prepared
incrementally throughout the lifetime of the project. But the requirements document is usually an
important part of a contract agreement between the customer and the supplier because it outlines
exactly what is to be done by the development team.
The way agile organizations overcome this is to rely on contracts in which the customer pays for the
time required for system development rather than the development of a specific set of requirements.

Agile is often criticized for its lack of formal documentation, which some may state as a disadvantage of agile
methods. This is not an issue according to agile proponents, who sta te that agile has an answer to formal
documentation:
1. Formal documentation describes the system and makes it easier for people changing the system to
understand; however, in practice, formal documentation is often not kept up to date and so does not
accurately reflect the program code.
2. Agile practices emphasize the importance of writing well-structured code and investing effort in code
improvement
3. Hence it is better to implement maintainable software by producing high -quality, readable code,
rather than to depend on documentation which may be incomplete.
Therefore, the lack of documentation should not be a problem in maintaining systems developed using an
agile approach.
Advantages and disadvantages of agile methods

Write a 150-word essay describing the advantages and disadvantages of agile
methods
3.3 Plan-Driven and Agile Development

As we have seen in the previous Unit, agile approaches to software development do not consider the
processes of requirements elicitation, design and development to be separate processes; rather they all
incorporated, and take place together.
In contrast to the agile approach, a plan-driven approach to software engineering separates the stages in the
software process, and specifies outputs which are associated with each stage. In other words, the activities
all take place in a sequential manner, and the outputs from one stage are used as a ba sis for planning the
following process activity. In a plan-driven approach, iteration occurs within activities, with formal documents
used to communicate between stages of the process.
Plan-driven and agile development

Study Sommerville.

To decide on the balance between a plan-based and an agile approach, you have to answer a range of
technical, human, and organizational questions:
1. Is it important to have a very detailed specification and design before moving to implementation?
You might find a customer that knows exactly what they want, and specified everything that is
required. If that is the case, a plan-drive approach would suit well.
2. Is an incremental delivery strategy realistic?

If you foresee possible future changes in the development process that could increment over time
during its life cycle, an agile approach will be best.
3. How large is the system being developed?

Agile methods are most effective when the system can be developed with a small co-located team
who can communicate informally.
4. What type of system is being developed?

If a system that requires a lot of analysis, then a plan-driven approach may be best.
5. What is the expected system lifetime?

Long-lifetime systems may require more design documentation to communicate the original
intentions of the system developers to the support team. However, supporters of agile methods will
argue that documentation is frequently not kept up to date and it is not of muc h use for long-term
system maintenance.
6. What technologies are available to support system development?

Agile method tools to keep track of an evolving design; latest technologies today include AJAX and
.NET.
7. How is the development team organized?

If development teams are distributed or outsourced, design documents are needed to communicate
across the development teams.
8. Are there cultural issues that may affect the system development?
Traditional engineering organizations have a culture of plan-based development, however, if they
were to move over to agile processes, compromising and understanding is required. They may still
require the use of their extensive design documentation.

9. How good are the designers and programmers in the development team?
It is argued that agile methods require higher skill levels than plan-based approaches in which
programmers simply translate a detailed design into code. So, with agile methods, you will n eed to
use the best people to develop the design, with others responsible for programming.
10. Is the system subject to external regulation?

For software which is constrained by external regulation, such as those outlined by the FAA (Federal
Aviation Authority) in the United States, or the South African Revenue Services, a plan -driven
approach will be more suitable because detailed documentation may be required by the regulating
body.
Agile methods versus Plan-driven development
Prepare an essay outlining the differences between plan-driven development

and agile methods.
3.4 Extreme Programming

Extreme programming (XP) is one of several popular agile processes. It is perhaps the best known and most
widely used of the agile methods. It has already been proven to be very successful at many companies of
all different sizes and industries worldwide. The name ‘extreme’ was given because the approach was
developed by pushing recognized good practices, such as iterative development (mentioned earlier in this
chapter), to ‘extreme’ levels.
Extreme programming is successful because it stresses customer satisfaction. Instead of delivering

everything you could possibly want on some date far in the future this process deliv ers the software you need
as you need it.
Some of the benefits of extreme programming are listed below:
1. Change management: XP empowers developers to confidently respond to changing customer
requirements, even late in the life cycle.
2. Teamwork: XP emphasizes teamwork. Managers, customers, and developers work together
collaboratively in a team as equal partners.
3. Increased productivity: XP implements a simple, yet effective environment enabling teams to become
highly productive.

XP emphasizes the following values:

1. Communication: extreme programmers constantly communicate with their customers and fellow
programmers
2. Simplicity: designs are kept simple and clean
3. Feedback: the team gets constant feedback by testing the software from day one
4. Respect: every small success deepens their respect for the unique contributions of each and every
team member
5. Courage: extreme programmers are able to courageously respond to changing requirements and
technology
3.4.1 Extreme programming principles

In extreme programming, the following principles are adhered to:
1. Requirements are expressed as scenarios (called user stories)
2. Programmers work in pairs and develop tests for each task before writing any code
3. All tests must be successfully executed
4. Short time gap between releases of the system

Extreme programming involves a number of practices, which reflect the following principles of agile methods:
1. Incremental development is supported through small, frequent releases of the system.
Requirements are based on simple customer stories or scenarios. These stories or scenarios are
used as a basis for deciding what functionality should be included in a system increment.
2. Customer involvement is supported through continuous engagement of the customer in the
development team. The customer representative takes part in the development and is responsible
for defining acceptance tests for the system.
3. People, not processes, are supported through pair programming, collective ownership of the system
code, and a sustainable development process.
4. Change is embraced through regular system releases to customers, test -first development,
refactoring to avoid code degeneration, and continuous integration of new functionality.
5. Maintaining simplicity is supported by constant refactoring that improves code quality.
Extreme programming practices
Study Sommerville.

3.4.2 The XP Process

The XP Process has four phases:
1. Planning
2. Design
3. Coding
4. Testing
The four phases are executed as follows:

In the planning phase, story cards are the main inputs. Once the story cards are developed, the development
team breaks these down into tasks and determines the effort and resources required for implementation. The
customer then prioritizes the stories for implementation.
A story card is a use case tool for simple story telling, or comprehension of a particular topic. This is where
the user of a system captures what they do or need to do as part of their job function. They capture the ‘who’,
‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be hand -written
on a small paper note card. For example, if a customer wanted a tablet to do things like a typical computer,
then the customer must write the scenario into a story in order for the developing team to extract out the
necessary requirements.
The client will select the stories which will be developed in the next iteration. The client should be careful not
to select too many stories; he should only choose enough stories which the development team will be able to
complete within two weeks. The developers then take one card at a time and implement the functionality
which it indicates. By the end of the two week period, the development team will release the next iteration of
the system to the user, and the user will test it thoroughly.
During the planning phase, many other things happen. Sometimes, additional work comes about from
questions not answered easily previously, and this required exploration of possible solutions. To find these
possible solutions, prototyping or trial development is done to understand the problem and solution. In XP
terms, this is known as a ‘spike’, an increment where no programming is done.
3.4.3 Prototypes
A prototype is a model built to test and trial a new design of a product to enhance precision by system analysts
and users. Prototyping serves to provide specifications for a real, working system rather than a theoretical
one.
Extreme programming takes an ‘extreme’ approach to incremental development. New versions of software
can be built several times a day, with each release delivered to customers roughly every two weeks.

Release deadlines are never slipped; if there are development delays, the customer is consulted and
functionality is removed from the planned release. The programmer must run all existing automated tests as
well as the tests for the new functionality.
A fundamental precept of traditional software engineering is that one should design for change. Extreme
programming, however, has discarded this principle on the basis that designing for change is often a wasted
effort.
3.4.4 Refactoring in XP
The general problem with incremental development is that it tends to degrade the software structure.
Therefore, changes to the software become harder and harder to implement.
Extreme programming tackles this problem by constant refactoring. Refactoring is a technique used for
restructuring an existing body of code by altering its internal structure without changing its external behaviour.
This is undertaken in order to improve some of the non-functional attributes of the software.
In practice, this is not always the case, as sometimes development pressure means that refactoring is delayed
because of time devoted to implementation of new functionality. Some new features and changes cannot
readily be accommodated by code-level refactoring and require the architecture of the system to be modified.
One of the most important differences between incremental development and plan-
driven development is in the way that the system is tested. To avoid some of the
problems of testing and system validation, XP emphasizes the importance of program
testing.
3.4.5 Pair programming

Pair programming means that all code to be sent into production is created by two people working together
at a single computer. Pair programming increases software quality without impacting time to deliver. With
two people working at a single computer will add as much functionality as two working separately, except that
it will be much higher in quality. With increased quality comes big savings later in the project.

Pair programming has the following advantages:
1. It supports the idea of collective ownership and responsibility for the system.
2. It acts as an on-going, informal review process.
3. It helps support refactoring, which is a process of software improvement.
Pair programming promotes the idea of ‘egoless’ programming where the software is owned by the team as
a whole and individuals are not held responsible for problems with the code. The team has collective
responsibility for resolving these problems. In the pair programming process, each line of code is looked at
by at least two people. Code inspection and reviews are very successful in discovering a high percentage of
software errors. The code is thoroughly refactored rigorously to keep the design simple to avoid needless
clutter and complexity. The code is kept clean and concise so it is easier to understand, modify, and extend.
Some antagonists of XP state that pair programming is a waste of time and resources because two
programmers have to do what it I possible for one person to do. However, in numerous studies which were
carried out, in was found that with pair programming, productivity is comparable with that of two people
working independently. Pair programming provides the sharing of knowledge between the two programmers.
Pair programming is a social skill that takes time to learn, striving for a cooperative way to work that includes
give and take from both partners regardless of corporate status.

Pair programming
Read Sommerville to get a deeper understanding of the concept of pair

programming.
3.5 Summary
• The most widely accepted and favoured incremental software development method worldwide is
the Agile approach
• Agile development is an increment development method where increments are small, and new
releases of the system are created and made available to customers every two or three weeks
• Agile software development is defined in the Manifesto of Agile Software Development
• There are various agile approaches, such as Scrum, Crystal, Adaptive software development and
Feature-driven development
• Agile methods are particularly useful in the following types of projects:
• Small or medium-sized products

• Off-the-shelf products
• Custom products which are being developed for a specific client, but where there is clear
commitment from the client
• The principles of agile methods are:
• Customer involvement
• Incremental delivery
• People not process
• Embrace change
• Maintain simplicity
• Agile does have its disadvantages, and there are situations where a plan -driven approach to
software development will be more suitable
• Extreme programming (XP) is one of several popular agile processes; the name ‘extreme’ was
given because the approach was developed by pushing recognized good practices, such as
iterative development to ‘extreme’ levels
• The XP process has four phases:
• Planning
• Design
• Coding
• Testing
• XP emphasizes the following practices:
• Refactoring
• Prototyping
• Test-first development
• Pair programming

1. Differentiate between Agile and Plan-driven development approaches.
2. List and explain the principles of Agile methods.
3. List the four phases of the XP process, and explain how they are executed.
4. Explain why test-first development helps the programmer to develop a better understanding of the system
requirements. What are the potential difficulties with test-first development?
5. Many people criticize the concept of pair-programming, saying that it is a waste of time and resources.
How would you respond to these criticisms?

Unit
4: Requirements Engineering

• Understand the concepts of user and system requirements

and why these requirements should be written in different
ways
4.2 Functional and Non-Functional • Understand the differences between functional and non-
Requirements functional software requirements
4.3 The Software Requirements • Understand how requirements may be organized in a

Document software requirements document
4.4 Requirements Engineering • Understand the principal requirements engineering

Processes activities of elicitation, analysis and validation, and the
relationships between these activities
4.5 Feasibility Study • Illustrate an understanding of software feasibility study
4.6 Requirements Elicitation and • Understand the processes of Requirements elicitation and
Analysis analysis, Requirements specification, Requirements
Validation, and requirements management
4.7 Requirements Specification
4.8 Requirements Validation
4.9 Requirements Management


Pearson.

Pearson.
Practices from the Method Prisons! First Edition. Publisher: ACM Books..

4.1 Introduction
Requirements Engineering
The requirements for a system are the descriptions of what the system should do, the services that it provides
and the constraints on its operation. The customer may require a system to handle the accounting functions
of his business, for example; or another customer may require a system to manage her company’s assets. In
each case, there are core functions of the system as well as peripheral functionality which is required in order
for the core functions to work. For example, the asset-tracking software may need additional functionality to
keep a record of the people to whom the assets are entrusted.
Constraints on a system may come in different forms, such as the cost and time limits, the type of operating
system on which the software will function, the type of hardware it will run on, etc.
The process of finding out, analyzing, documenting and checking these services and constraints is called
Requirements Engineering (RE). In this chapter we will look at requirements engineering in detail.
Requirements engineering is a systems and software engineering process which covers all of the activities
involved in discovering, documenting and maintaining a set of requirements for a computer -based system.
The requirements engineering phase of the project is probably the most important phase, since this is the
phase in which the plans for the system to be built are laid out. If there are any errors or misunderstandings
with regard to the requirements of the system, then these will be carried forward to every phase which follows;
and fixing these errors down the line can be extremely expensive, and can potentially derail the project.
Sommerville identifies two types of requirements: user requirements and system requirements. He defines
them as follows:
1. User requirements are statements, in a natural language plus diagrams, of what services the system
is expected to provide to system users and the constraints under which it must operate.
2. System requirements are more detailed descriptions of the software system’s functions, services,
and operational constraints. The system requirements document (sometimes called a functional
specification – a document that describes the requested behavior of an engineering system.) should
define exactly what is to be implemented. It may be part of the contract between the system buyer
and the software developers.
Activity 4.1
User Requirements and System Requirements
Study Sommerville. Make sure you understand the differences between user
requirements and system requirements.

Requirements analysis
Now that you have a much better understanding of user requirements and system
requirements, consider a simple computer program which takes in a set of numbers, and
calculates their average. What sort of user and system requirements will such a system have?
The project manager or analyst needs to write requirements at different levels of detail because different
readers use them in different ways. For example, the cashier at the store where a point -of-sale system is
being developed never needs to know any technical details about the system, such as the type of architecture
it uses, the language it is developed in, the type of database it uses, etc. – so there is no need for her to see
the highly technical part of the document.
On the other hand, the software developers who will be building the system need to know the system in
intimate detail – it will hence be necessary to show them high-level details which the cashier will see, as well
as low level, highly technical details.
The diagram below shows who the readers of different types of requirements will be:
Because the requirements of a system are extremely important, and affect e very subsequent phase of the
project, they should be:
1. Documented: the requirements should be well-documented, and in a clear, precise, unambiguous
manner
2. Actionable: requirements should be practical and doable
3. Measurable: the requirements should not be expressed in such a way that it is difficult or impossible
to measure – for example, if a user merely states that a system needs to be ‘effective’, this is not
good enough. He will need to clarify exactly what he means by ‘effective’.

4. Testable/traceable: once the system or parts of it have been implemented, will it be possible to weigh
it against the requirements statement to see if it meets the requirements? Only if the requirements
are expressed in a clear, objective manner, rather than a way which is amb iguous, will this be
possible.
5. Related to identified business needs or opportunities: from the outset, the team as well as the client
need to clearly identify the ‘must haves’ and the ‘nice to haves’ in the system.
6. Defined to a level of detail sufficient for system design: too much detail, as with too little, may be
counterproductive.
4.2 Functional and Non-Functional Requirements

The requirements of a system may be classified as functional requirements or non -functional requirements:
1. Functional requirements: Explains what has to be done by identifying the necessary task, action or
activity that must be accomplished.
2. Non-functional requirements: Requirements that specify criteria that can be used to judge the
operation of a system, rather than specific behaviors.
The distinction between different types of requirements is not as clear-cut as these simple definitions
suggests.
4.2.1 Functional requirements

The functional requirements for a system describe what the system should do. These indicate what 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. 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 requiremen ts. Functional
requirements are described in a way that can be understood by system users.
The functional requirements need to be expressed in a clear, unambiguous way, because ambiguity in the
requirements specification is the cause of many software engineering problems. It has been practically
proven that if a statement is ambiguous, a system developer will almost always interpret in a way that
simplifies its implementation – but this may not necessarily be the correct interpretation.
The functional requirements specification of a system should be both complete and consistent.
1. Completeness means that all services required by the user should be defined.
2. Consistency means that requirements should not have contradictory definitions.
In practice, for large, complex systems, it is very difficult to achieve requirements consistency and
completeness.


Functional requirements
Read Sommerville.
4.2.2 Non-functional requirements

Non-functional requirements are requirements that are not directly concerned with the specific services
delivered by the system to its users, but are needed to make the core functions possible, more effective or
more user-friendly. These are additional constraints on the services or functions offered by the system. They
include things like timing constraints, constraints on the development process, and constraints imposed by
external standards. Non-functional requirements often apply to the system as a whole, rather than individual
system features or services. Sometimes the non-functional requirements may be more critical than individual
functional requirements.
Non-functional requirements can be quite challenging for the following reasons:

1. Difficult to identify and describe: although it is quite easy to identify and describe functional
requirements it is often more difficult to relate components to non -functional requirements.
2. Users express them as goals: users or customers often propose these requirements as general
goals, such as ease of use, the ability of the system to recover from failure, or rapid user response.
This may cause problems for system developers as they leave scope for interpretation and
subsequent dispute once the system is delivered.
3. Affect entire system: these requirements may affect the overall architecture of a system rather than
the individual components. This makes it difficult to plan and partition the work.
4. Generate other requirements: a single non-functional requirement, such as a security requirement,
may generate a number of related functional requirements that define new system services that are
required.
Non-functional requirements arise through user needs, because of budget constraints, organizational
policies, the need for interoperability with other software or hardware systems, or external factors such as
safety regulations or privacy legislation.
Whenever possible, non-functional requirements should be written quantitatively so that they can be
objectively tested. The following table shows metrics that can be used to specify non-functional system
properties:

Property Measure
Speed Processed transactions per second
User/event response time
Screen refresh time
Size Megabytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
It is difficult, in practice, to separate functional and non-functional requirements in the requirements

document. If the non-functional requirements are stated separately from the functional requirements, the
relationships between them may be hard to understand. However, non-functional requirements such as
performance or reliability should be explicitly highlighted.

Types of non-functional requirements
Study Sommerville and read the explanations that follow.

4.3 The Software Requirements Document

The software requirements document (sometimes called the software requirements specification or SRS) is
an official statement of what the system developers should implement. It should include both the user
requirements for a system and a detailed specification of the system requirements. Sometimes, the user and
system requirements are integrated into a single description. In other cases, the user requirements are
defined in an introduction to the system requirements specification.
The software requirements document in agile methods
Agile development methods argue that requirements change so rapidly that a requirements
document is out of date as soon as it is written. Rather than a formal document, approaches such
Extreme Programming collect user requirements incrementally and write these on cards as user
stories. The user then prioritizes requirements for implementation in the next increment of the
system. For business systems where requirements are unstable, this approach is a good one.
4.3.1 Users of the software requirements document

The requirements document has a diverse set of users, from senior management of the organization, through
the users, to the engineers responsible for developing the software. Possible users of the document are:
• System customers and users: Specify the requirements and read them to check that they meet
their needs. They may even specify changes to the requirements
• Managers: Use the requirements document to plan the system development process
• System engineers: Use the requirements to understand what system is to be developed
• System test engineers: Use the requirements to develop validation tests for the system
• System maintenance engineers: Use the requirements to understand the system and the
relationships between its parts
Because the requirements document has such a wide audience, it has to be a compromise between
communicating the requirements to customers, defining the requirements in precise detail for developers and
testers and including information about possible system evolution.
The level of detail that is included in a requirements document depends on the type of system being
developed and the development process. Critical systems need to have very detailed requirements.

4.3.2 Structure of the software requirements document

One possible organization for a requirements document that is based on an IEEE standard for requirements
documents is a generic standard adapted to specific uses.
The structure of a requirements document is divided into ten chapters:

1. Preface: should describe who the document is intended for, state its version, and describe the
rationale for the creation of a new version; it should also include a summary of the changes made in
each version.
2. Introduction: should describe the need for the system. It should briefly describe the system’s
functions and explain how it will work with other systems. It should also describe how the system
fits into the overall business or strategic objectives of the organization commissioning the software.
3. Glossary: should define the technical terms used in the document. It is incorrect to make
assumptions about the experience or expertise of the readers.
4. User requirements definition: describes the services provided by the system for the user. The non -
functional system requirements should also be highlighted in this Unit. This description may use
natural language, diagrams, or other notations that are understandable to customers. Product and
process standards that must be followed should be specified.
5. System architecture: should present a high-level overview of the anticipated system architecture,
showing the distribution of functions across system modules. Architectural components that are
reused should be highlighted.
6. System requirements specification: should describe the functional and non-functional requirements
in more detail. If necessary, further detail may also be added to the non-functional requirements.
Interfaces to other systems may be defined.
7. System models: include graphical system models showing the relationships between the system
components, and the system and its environment. Examples of models are object models, data -flow
models, or semantic data models.
8. System evolution: should describe any anticipated changes due to hardware evolution, changing
user needs, and so on.
9. Appendices: should provide detailed, specific information that is related to the application being
developed; for example, hardware and database descriptions.
10. Index: like the index of any book, it can be a normal alphabetic index, or an ind ex of diagrams, or an
index of functions and so on.
If an evolutionary approach is adopted, the requirements document will leave out many of detailed chapters.
When the software is part of a large system project that includes interacting hardware and sof tware systems,
it is usually necessary to define the requirements to a fine level of detail.

4.4 Requirements Engineering Processes

Requirements engineering processes include four high-level activities:
1. Feasibility study: assesses whether the system is useful to the business or not
2. Elicitation and analysis: determines the requirements of the proposed system
3. Specification: convert the requirements into a standard form that can be understood by everyone
involved in the project
4. Validation: check that the requirements really define the system that the customer wants
Feasibility Elicitation
Specification Validation
study and analysis
Requirements engineering is an iterative process. The amount of time and effort given to each activity in each
iteration of the process depends on which stage of the process is being managed. It also depends on what
type of system is being developed. Early in the process, most effort will be spent on understanding high-level
business and non-functional requirements for the system. In the later stages of the process, more attention
and focus is given to determining and understanding the detailed system.
In the next few chapters, we will look at the above activities in greater detail.
4.5 Feasibility Study

The purpose of a feasibility study is to determine whether the software system which is proposed is worth
building or not. Generally speaking, the objective of a feasibility study is not to solve a problem, but to
determine whether the problem is worth solving; this is true for software feasibility studies as well.

A software feasibility study will generally concentrate on the following areas:

• Operational feasibility study: tests the operational scope of the software to be developed. In other
words, will the proposed software solve real problems within the organization?
• Technical feasibility study: compares the level of technology available with the level of technology
required for the development of the product. Is the available technology capable of supporting the
system?
• Economic feasibility study: evaluate the cost of developing the software sys tem against the
projected income or benefits which it will deliver. Will it be affordable for the organization to build
the system?
4.6 Requirements Elicitation and Analysis

Requirements elicitation and analysis is the next stage of the requirements engineeri ng process after
performing the feasibility study. System analysts and software engineers work with customers to find out
about the application domain, what services the system should provide, the required performance of the
system, hardware constraints, etc. Many different people in an organization work together during
requirements elicitation and analysis.
The activities within the requirements elicitation and analysis process are illustrated in the following diagram,
and explained below:

1. Requirements discovery: involves interacting (working with) the stakeholders of the system to find
out their requirements. During this activity, domain requirements and documentation are also
determined.
2. Requirements classification and organization: involves taking the unstructured (unorganized)
collection of requirements, groups them and arranges them into suitable classes.
3. Requirements prioritization and negotiation: involves prioritizing (arranging from most important to
least important) requirements. It also involves finding and solving requirements conflicts by
negotiating with the people concerned.
4. Requirements specification: involves documenting the requirements and using it as input for the next
stage of the process.
Requirements elicitation and analysis is an iterative process with continual feedback from each activity to
other activities. The analyst’s understanding of the requirements improves with each round of the cycle.
Eliciting and understanding requirements from stakeholders is difficult for the following reasons:
1. Stakeholders usually don’t know what they want from a computer system.
2. Stakeholders in a system express requirements in their own terms and they cannot describe their
work clearly.
3. Different stakeholders have different requirements and they express this in different ways.
4. Political factors could influence the requirements of a system.
5. The economic and business environment where the analysis takes place is dynamic. It changes
constantly, and there is no accurate way of controlling or predicting this change.
Knowledge Check Questions 4.1
Requirements discovery techniques
Numerous methods are used by software engineers to gather requirements for a system which
is being built, some of which are:
• Viewpoints
• Interviewing
• Scenarios
• Use cases
• Ethnography
Write a detailed explanation of each technique, along with its advantages and disadvantages.
Your explanations should demonstrate a good understanding of the concepts. The prescribed
book and the internet will prove to be valuable resources.

4.7 Requirements Specification

Requirements specification is the process of writing down the user and system requirements in a
requirements document. The user and system requirements should be clear, unambiguous, easy to
understand, complete, and consistent. The language should always be such that it is understandable for
users who don’t have detailed technical knowledge. Software jargon, structured notations and formal
notations should be avoided; rather, natural language with simple tables, forms, and intuitive diagrams should
be used.
System requirements should specify the external behavior of the system, and should not include details of
the system architecture or design. System requirements are used by software engineers as the starting po int
for the system design - they ad detail and explain how the user requirements should be provided by the
system. Therefore, it should be a complete and detailed specification of the whole system. They should not
be concerned with how the system should be designed or implemented.

Natural language specification and Structured specifications
Read Sommerville
4.8 Requirements Validation

Requirements validation is the process of checking that requirements actually define the system that the
custom really wants. It is critically important because errors in a requirements document can cause huge
rework costs when these problems are discovered during development or after the system is in service.
During this process, different types of checks should be performed on the requirements in the requirements
document.
These checks include:

1. Validity checks: Additional or different functions may be identified after further thought and
analysis.
2. Consistency checks: Requirements should not conflict. Fulfilling one requirement should not cause
problems for another requirement.
3. Completeness check: The requirements document must include requirements that define all
functions and constraints desired by the system user.

4. Realism check: Requirements should be checked to confirm that they can actually be
implemented. These checks must also consider the budget and schedule for the system
development.
5. Verifiability: System requirements should always be written so that they can be verified. You should
be able to write a set of tests that can demonstrate that the delivered system meets each specified
requirement.
There are many requirements validation techniques. They can be used alone or together with each other.
These techniques include:
1. Requirements reviews: The requirements are analysed systematically by a team of reviewers. This
team checks for errors and inconsistencies.
2. Prototyping: Uses an executable (working) model of the system to allow end-users and customers
to experiment with this model to see if it meets their real needs.
3. Test case generation: If the tests for requirements are part of the validation process, it may reveal
requirements problems.
In practice the requirements specification will undergo numerous changes and additions before a final version
is agreed on.
Validation error leads to disaster

On June 4th 1996 the Ariane 5 rocket launcher, which was a European rocket designed to launch
commercial satellites, failed on its maiden voyage due to a software error. After investigations it was
found that had the requirements for the software system on board the Ariane been thoroughly
validated, the disaster could have been averted.
4.9 Requirements Management

Requirements for large software systems are always changing.
Change is inevitable for the following reasons:
1. The business and technical environment of the system always changes after installing the newly
developed system.
2. People who pay for the system are rarely the same people who use the system.
3. Large systems have a varied (i.e. many different people with many different needs) user
community.
Requirements management is the process of understanding and controlling changes to system requirements.
Individual requirements must be monitored and links between requirements that depend o n each other must
be maintained. This allows the team to assess the impact of requirements changes. A formal process must
be used for making change proposals and linking these to system requirements.

Agile development processes, such as extreme programming, were designed to manage requirements that
change during the development process. The user must prioritize the change. If it is a high priority change,
the user must decide what system features that were planned for the iteration should be excluded.
4.10 Summary
• Requirements engineering is a systems and software engineering process which covers all of the
activities involved in discovering, documenting and maintaining a set of requirements for a computer -
based system
• The requirements for a system are the descriptions of what the system should do, the services that
it provide
• There are essentially two types of requirements:
o User requirements are statements, in a natural language plus diagrams, of what services
the system is expected to provide to system users and the constraints under which it must
operate
o System requirements are detailed descriptions of the software system’s functions, services,
and operational constraints
• The requirements of a system may be classified as functional requirements or non -functional
requirements:
o Functional requirements: Explains what has to be done by identifying the necessary task,
action or activity that must be accomplished. Functional requirements state what the system
should do
o Non-functional requirements: Requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behaviours. Functional requirements state
what the system should be
• The software requirements document is an official statement of what the system developers should
implement. It should include both the user requirements and the system requirements.
• Requirements engineering processes include four high-level activities:
o Feasibility study
o Elicitation and analysis
o Specification
o Validation
• The purpose of a feasibility study is to determine whether the software system which is proposed is
worth building or not
• Requirements elicitation and analysis the stage of the requirements engineering process where
system analysts and software engineers work with customers to find out about the applica tion
domain, what services the system should provide, the required performance of the system, hardware
constraints, etc

• Requirements specification is the process of writing down the user and system requirements in a
requirements document
• Requirements validation is the process of checking that requirements actually define the system that
the custom really wants

1. Identify and briefly describe two types of requirements that may be defined for a computer based system.
2. Differentiate between functional and non-functional requirements.
3. List and explain in detail the four high-level activities in the requirements engineering processes.
4. Who should be involved in a requirements validation? Explain what can happen if the requi rements are
not validated properly.
5. List and describe the different types of checks which are done during requirements validation.
6. List and describe the activities which take place within the requirements elicitation stage.

Unit
5: System Modelling

• Understand how graphical models can be used to

represent software systems
5.2 Types of System Models • Understand why different types of models are required
and the fundamental system modelling perspectives of
context, interaction, structure, and behaviour
5.3 Context Models • Have been introduced to some of the diagram types in the
Unified Modelling Language (UML) and how these
diagrams may be used in system modelling
5.4 Interaction Models • Understand the use of interaction models
5.5 Structural Models • Be aware of the ideas underlying model-driven
5.6 Behavioural Models engineering, where a system is automatically generated

from structural and behavioural models

Pearson.

Pearson.

5.1 Introduction
System modelling
The previous chapter dealt with requirements engineering, where the requirements for a proposed system
are identified and documented. Although there are numerous ways to discover the requirements of a system
and to communicate them, few methods are as effective as system modelling.
System modelling, according to Sommerville, is the process of developing abstract, graphical models of a
system, with each model presenting a different view or perspective of that system. In system modelling, a
graphical notation is used to represent a system in a way which is simple to express and understand.
System Models
System modelling is the process of developing abstract, graphical models of a system, with each
model presenting a different view or perspective of that system.
System models can be likened to the architectural plans for a building or blueprints for a machine.
Graphical modelling provides multiple benefits:

1. As a means of facilitating discussion about an existing or proposed system – diagrams make it easier
for people to visualize the system and offer a good way to stimulate discussion.
2. As a way of documenting an existing system – diagrams can be used along with textual descriptions
to describe a system, and to clarify any ambiguities or hard-to-understand concepts.
3. As a detailed system description that can be used to generate a system implementation – the
development team can base their development work entirely on the diagrams because they present
a detailed, structured view of the system.
The trouble with natural-language descriptions is that they always have the possibility of being ambiguous,
and hence of being misunderstood. In order to reduce these ambiguities, and to help everyone to get a clear
and accurate understanding of the system, models are required.
A picture says a thousand words
The old adage that “a picture says a thousand words” can be applied to system models. It has
been proven from experience that a single system model can covey more information more
effectively than tens of pages of textual descriptions.

5.2 Types Of System Models

Many different models can be created for a single system – each model will depict the system from a different
perspective. As an example, think about a set of plans for a building: there will be various blueprints for
various aspects of the building, such as the electrical system, plumbing system, air -conditioning ducts,
network cables, etc. In the same way, a software system needs to be looked at from different perspectives.
Different models are developed to represent the system from different perspectives:
Perspective Model Description
An external perspective Context Models Where you model the context or environment of
the system.
An interaction perspective Interaction Models Where you model the interactions between a
system and its environment or between the
components of a system.
A structure perspective Structural Models Where you model the organization of a system
or the structure of the data that is processed by
the system.
A behavioural perspective Behavioural Models Where you model the dynamic behaviour of the
system and how it responds to events.
We will look at each of the above models in greater detail in this chapter.
• How systems are modelled: Unified Modelling Language (UML)

Although there are many ways to model a system, the preferred way to do so these days is the UML (Unified
Modelling Language). In certain systems, particularly those in which the requirements need to be extremely
precise, such as the control system on an airplane, a formal mathematical model of a system may be used
to detail the specification of the system.
The Unified Modelling Language is used to specify, visualize, modify, construct and document the artefacts
of an object-oriented system under development. What makes it attractive to development teams is that it
offers a standard way to visualize a system’s architectural blueprints, including elements such as activities,
actors, business processes, database schemas, logical components, programming language statements and
reusable software components. This standard is accepted almost universally, so a system blueprint which is
created by one team can be understood by another team relatively easily.

The UML has many diagram types and so supports the creation of many different types of system models.
The following five diagram types can be utilized to represent the essentials of a sy stem:
1. Activity diagrams – shows the activities involved in a process or in data processing.
2. Use case diagrams – shows the interactions between a system and its environment. The image
below shows a very simple use case diagram.
3. Sequence diagrams – shows interactions between actors and the system and between system
components.
4. Class diagrams – shows the object classes in the system and the associations between these
classes.
5. State diagrams – shows how the system reacts to internal and external events.
One or more of the above diagram types may be used to model each of the five perspectives of the system.

The Unified Modelling Language
The UML is a critically important aspect of software engineering, and is something no
software engineer can do without. It is, without a doubt, something which you as a
software engineer, systems analyst or IT manager will encounter on an almost daily
basis, so it will make sense to learn as much about the UML as possible.
There is a vast amount of content available on the internet on the topic of the UML. Read
up about the UML and its various notations and diagram types..
System modelling is a vast field, and really a subject on its own. Complete coverage of the various models
and their development is beyond the scope of this module; the purpose of this chapter is to familiarize you
with the different types of models and their functions.

5.3 Context Models

A context diagram is a diagram that represents the actors outside a system that would interact with
that system. External actors may be people or even other systems which will interact with the existing system
by producing data which the new system will need, or by consuming data produced by the new system. The
context diagram is the highest level view of a system.
A context model will typically show the following information:

• The system boundaries: what will the system do, and what it will not do
• Overall functionality: a high level view of the functionality of the system
• What is provided by the system’s environment: for example, what data will other systems provide
• Automation: which processes will be automated, and which will be manual
• Overlaps with existing systems: where will the new system perform similar functions to existing
systems? Sometimes overlap may be unavoidable
To design a context model, you need to have the specifications and the requirements of the system being
developed. Without this information, it will not be possible to create a context model.
The following diagram is a very simple context diagram for an ecommerce system:
As is clear from the diagram above, a simple ecommerce system cannot operate in isolation. It needs to
integrate with other systems within the organization, such as the inventory system, the accounting system,
etc. This information is clearly represented in the context diagram above. Contex t models normally show that
the environment includes several other automated systems. However, what you cannot see from the above
diagram is the types of relationships between the systems in the environment and the system that is being
specified.

External systems might produce data for or consume data from the system. They might share data with the
system or they might be connected directly, through a network or not connected at all. They might be
physically co-located or located in separate buildings. All of these relations may affect the requirements and
design of the system being defined and must be taken into account. Therefore, simple context models are
used along with other models, such as business process models, to describe human and automated
processes in which particular software systems are used.
The following diagram, reproduced from Sommerville (Figure 5.2, page 123) is a UML activity diagram:
Activity diagrams are intended to show the activities that make up a system process and the flo w of control
from one activity to another.
The filled circle at the top left of the diagram indicates the start of a process and the filled circle inside another
circle indicates the end of a process. Rectangles with round corners represent activities. The arrows
represent the flow of work from one activity to another. A solid bar is used to indicate activity coordination.
When the flow from more than one activity leads to a solid bar then all of these activities must be complete
before progress is possible. When the flow from a solid bar leads to a number of activities, these may be
executed in parallel.

Activity 5.1
Process modelling
A person goes to an ATM machine to withdraw cash. Based on your experience
with an ATM machine, list all the steps which take place from the moment the
account holder inserts his card into the machine, until the cash is dispensed.
Then, illustrate the process via a simple process diagram similar to the one
shown above.
5.4 Interaction Models

All systems involve interactions of some kind; these interactions can be:
1. User interactions, which involve user inputs and outputs
2. Interactions between the system being developed and other systems
3. Interactions between the components of the system.
Modelling user interaction is important as it helps to identify user requirements. Modelling system to system
interaction highlights the communication problems that may arise. Modelling component interactions helps
to understand if a proposed system structure is likely to deliver the required system performance and
dependability.
There are two related approaches to interaction modelling:

1. Use case modelling – mostly used to model interactions between a system and external actors
(users or other systems).
2. Sequence diagrams – used to model interactions between system components, although external
agents may also be included.
Use case models and sequence diagrams present interaction at different levels of detail, so they may be
used together. Use case models generally depict the system interactions at a high level, while sequence
diagrams show the details of the interactions.
5.4.1 Use case modelling

Use case models were originally developed by a computer scientist named Ivar Jacobson in the 1990s. Use
case models are widely used to support requirements elicitation. A use case can be a sim ple scenario that
describes what a user expects from a system. Each use case represents a discrete task that involves external
interaction with a system.

The following diagram is a simple use case between a user (actor 1) and a system (actor 2).
The one actor is the user, who is transferring data and the second actor is the system.
Use case diagrams give a fairly simple overview of an interaction, so it becomes necessary to provide more
detail to understand what is involved. This detail can either be a simple textual description, a structured
description in a table, or a sequence diagram. You choose the most appropriate format depending on the
use case and the level of detail that you think is required in the model.
5.4.2 Sequence diagrams

In the UML, sequence diagrams are primarily used to model the interaction between the actors and the objects
in a system and the interactions between the objects themselves. A sequence diagram shows the details of
the interactions that take place during a particular use case. The following diagram depicts a simple sequence
diagram of a person doing a balance inquiry at an ATM machine.
Unless the developers intend to use the sequence diagrams for code generation or detailed documentation,
it is not necessary to include every interaction in these diagrams.

5.5 Structural Models

The structural model of a system is a description of the structure of the components in a system including the
component's identity, relation to other components, its attributes, and the operations which it performs.
The structural model, which is also known as a static model, can be built as soon as enough of the business
requirements are understood to start identifying the domains or major components to be defined at the
enterprise level. Model is then iteratively refined at the conceptual and logical levels.
The primary artefact of structural modelling is a structural model of the system represented using a class
diagram.
5.5.1 Class diagrams

Class diagrams are used when developing an object-oriented system model to show the classes in a system
and the associations between these classes. An object class can be thought of as a general definition of one
kind of system object. An association is a link between classes that indicates that there is a relationship
between these classes.
Class diagrams in the UML can be expressed at different levels of detail. When developing a model, the first
stage is usually to look at the world, identify the essential objects, and represent these as classes. The
simplest way of writing these is to write the class name in a box. The existence of association is indicated
by drawing a line between these classes.
5.6 Behavioural Models

Behavioural models are models of the behaviour of the system as it is executing. Behavioural models are
sometimes referred to as ‘dynamic models’. They show, in a step-by-step manner, what happens or what is
supposed to happen when a system receives some sort of stimulus from its environment.
These stimuli can be of two types:

1. Data: when a system receives a particular set of data, it will need to respond in a specific way. For
example, when a login system on a website receives data in the form of a user’s username and
password; it then needs to respond to this by validating the user.
2. Events: triggers system processing. For example, when a user clicks on a specific button, such as
the “close” button, the system needs to close the app.

Things which stimulate a system
Provide two examples each of data and event stimuli..
Many business systems are data processing systems that are primarily driven by data. They are controlled
by the data input to the system with relatively little external event processing. Their proce ssing involves a
sequence of actions on that data and the generation of an output.
5.6.1 Data-driven modelling

Data-driven models show the sequence of actions involved in processing input data and generating a required
output. Data-driven models are useful during the requirements analysis phase to show end-to-end processing
in a system.
Data-flow diagrams (DFDs) were introduced as a way of illustrating the processing steps in a system. Data -
flow models are useful in helping the analysts and designers to understand how the data associated with a
particular process is tracked and document as it moves through the system. DFDs focus on system functions
and do not recognize system objects.

Readings
Data-driven modelling
Read Sommerville to get a deeper understanding of data-driven modelling.
5.6.2 Event-driven modelling

Event-driven models show how a system responds to external and internal events. It is based on the
assumption that a system has a finite number of states and that events (stimuli) may cause a transition from
one state to another.
The UML supports event-based modelling using state diagrams, which were based on state charts.
State diagrams show system states and events that cause transitions from one state to another. They do not
show the flow of data within the system but may include additional information on the computations carried
out in each state.

In UML state diagrams, rounded rectangles represent system states. They may include a brief description of
the actions taken in that state. The labelled arrows represent stimuli (events) that force a tran sition from one
state to another. The start and end states are indicated the same as in activity diagrams.
Event-driven modelling
Read Sommerville to get a deeper understanding of event-driven modelling.
Activity 5.2
Microwave ovens
Although microwave ovens are appliances which we use on a daily basis, we
never take time to consider the inner functions of the software processes which
make it possible to operate them. Sommerville uses a microwave oven as a
case study to explain the concept of event-driven modelling. Study Sommerville
and write an essay of no less than 200 words describing event-driven modelling
in your own words. Create a simple state diagram of a DVD player as a part of
your essay.

5.7 Summary
• System modelling can be defined as the process of developing abstract, graphical models of a
system, with each model presenting a different view or perspective of that system.
• Graphical models are normally used to supplement textual descriptions of a system, very much like
architectural plans for a building
• Graphical models provide many benefits, such as:
o They provide a means of facilitating discussion
o They serve as a way of documenting an existing system
o They can be used to generate a system implementation
• A system needs to be modelled from many different but related perspectives, such as: an external
perspective, an interaction perspective, a structural perspective and a behavioural
perspective
• The external perspective can be modelled using Context Models
• The interactions can be modelled using Interaction Models
• The structure of a system may be modelled using Structural Models
• The system may be modelled from a behavioural perspective using Behavioural Models
• There are many ways to model a system, but the most widely-used system is the universal
modelling language, or UML
• The UML provides many different types of models, such as: activity diagrams, use case diagrams,
sequence diagrams, class diagrams and state diagrams

1. Define the term “System Modelling”.
2. Explain why it is important to model the context of a system that is being developed.
3. Draw a use case diagram for a bank ATM system. The ATM machine should provide for the
following operations which may be done: check balance, deposit funds, withdraw cash and transfer
funds.
4. Design an activity diagram for the order processing function of a business. The process is a simple
one:
a. The order comes in
b. It is invoiced
c. Payment is received
d. The order is dispatched

Unit
6: Design and implementation

6.1 Introduction • Understand why the architectural design of software is

important
6.2 Object-Oriented Design Using The • Understand the decisions that have to be made about the
UML system architecture during the architectural design process
6.3 Design Patterns • Have been introduced to the idea of architectural patterns,
well-tried ways of organizing system architectures, which
can be reused in system designs
6.4 Implementation Issues • Know the architectural patterns that are often used in
different types of application system, including transaction
processing systems and language processing systems
6.5 Open-Source Development • Understand open source development and its licensing

Pearson.

Pearson.

6.1 Introduction
Design and implementation
The software design and implementation stage can be seen as a culmination of the previous stages: it is the
stage in software engineering at which an executable software system is developed. Software design and
implementation is only one of a set of processes (requirements engineering, verification and validation, etc.)
involved in software engineering. Software design is a creative activity in which you identify software
components and their relationships, based on a customer’s requirements. Implementation is the process of
realizing the design as a program.
The aim of this unit is not to show any specific implementation details – this will be done in the next unit.
Rather, in this unit we will cover two important things:

1. To show how system modelling and architectural design (covered in Chapters 5 and 6) are put into
practice in developing an object-oriented software design.
2. To introduce important implementation issues that are not usually covered in programming books.
These include software reuse, configuration management, and open source development.
6.2 Object-Oriented Design Using The UML

An object in object-oriented terminology is a data structure which has a state and a set of behaviours. The
state of an object is represented by the data it holds, while the behaviour is represented by the functions
which work on that data. For example, an object which is designed to hold information about a person will be
called a Person object, and might have the following states and behaviours:
States:
Name
Surname
Age
Behaviours
Set Name
Get Name
Set Surname
Get Surname
Set age
Get age

An object-oriented system is made up of interacting objects. Object-oriented design processes involve

designing object classes and their relationships between these classes. These classes define the objects in
the system and their interactions
Object-oriented systems are extremely popular these days because easier to develop and change than
systems developed using functional approaches. Objects include both data and operations to manipulate
that data. Objects are ideally created and integrated in such a way that changing the implementation o f an
object or adding services should not affect other system objects. To develop a system design from concept
to detailed, object-oriented design, there are several things that need to be done:
1. Understand and define the context and the external interactions with the system.
2. Design the system architecture.
3. Identify the principal objects in the system.
4. Develop design models.
5. Specify interfaces.
We will look at each of these in the following Units.
The UML
The Unified Modelling Language (UML) is a standardized general-purpose modelling language
which is used to model object-oriented systems. The standard was created and is managed by
the Object Management Group, and has become the industry standard for modelling object-
oriented systems. UML includes a set of graphic notation techniques to create visual models of
object-oriented systems. UML is used to specify, visualize, modify, construct and document the
artefacts of an object-oriented system.
UML offers a standard way to visualize a system's architectural blueprints, including elements
such as:
• activities
• actors
• business processes
• database schemas
• programming language statements
• reusable software components

6.2.1 System context and interactions

The first stage in any software design process is to develop an understanding of the relationships between
the software that is being designed and its external environment. This is essential for deciding how to provide
the required system functionality and how to structure the system to
communicate with its environment. Understanding of the context also lets you establish the boundaries of
the system.
System context models and interaction models present complementary views of the relationships between a
system and its environment:
1. A system context model is a static structural model that demonstrates the other systems in the
environment of the system being developed (see chapter 5)
2. An interaction model is a dynamic model that shows how the system interacts with its environment
as it is used (see chapter 5)

System context and interactions
Read Sommerville.
6.2.2 Architectural design

Once the interactions between the software system and the system’s environment have been clearly defined,
the next step is to use this information as a basis for designing the system architecture. You identify the
major components that make up the system and their interactions, and they may organize the componen ts
using an architectural pattern, which is not essential at this stage. The following diagram shows the high -level
architecture for a standard web application:

Architectural design
Study Sommerville.
6.2.3 Object class identification

By this stage the team will have a fairly good idea of what the proposed system will be like, and what the
major objects will be in the system. What will be required at this stage is to refine their understanding of the
system to the extent that they are able to identify all the objects and interactions within the system, which will
in turn enable them to start building the system
To identify the objects in an object-oriented system, there are various methods:

1. The use case description helps to identify objects and operations.
2. Use of grammatical analysis of the description of the system to be constructed. Objects and
attributes are nouns (names of things, such as ‘person’ and ‘bank account’); operations or services
are verbs (doing-words such as ‘store’, ‘sort’ and ‘transfer’).
3. Use of tangible entities (things) in the application domain such as aircraft, roles such as manager
or doctor, events such as requests, interactions such as meetings, locations such as offices,
organizational units such as companies and so on.
4. Use of scenario-based analysis where various scenarios of system use are identified and
analysed, the team responsible for the analysis must identify the required objects, attributes and
operations.

6.2.4 Design models

Design models (also known as system models, which were covered in chapter 5) show the objects in a system
as well as the associations and relationships between these objects. These models are the bridge between
the system requirements and the implementation of a system, as illustrated in the following diagram:
Specific design decisions may be made as the system is implemented, with problems resolved through
informal discussions.
The UML supports 13 different types of models, however, you don’t necessarily need all of them as minimizing
the number of models that are produced reduces the costs of the design and the time required to complete
the design process.
There are two kinds of design models that UML can be used to develop a design:
1. Structural or Static models – describes the static structure of the system using object classes and
their relationships.
2. Dynamic models – describes the flow of the system and show the interactions between the system
objects.
In the early stages of the design process, there are three models that are useful for adding detail to use case
and architectural models:
1. Subsystem models – shows logical groupings of objects into coherent subsystems. They show how
a design is organized into logically related groups of objects. Object models may also be designed
to show all of the objects in the systems and their associations, such as inheritance, gen eralization,
aggregation
2. Sequence models – shows the sequence of component interactions for each significant interaction
within a system. In other words, a sequence model shows how various components of s system will
work together to perform the require functionality of the system. The components may be individual
objects or groups of objects.

3. State machine models – shows how individual objects change their state in response to events.
These are useful high-level models of a system or an object’s operation. However, a state diagram
isn’t required for all the objects in the system.
6.2.5 Interface specification

An important part of the design process is the specifying the interfaces between the components in the
system. Interface design is concerned with specifying how an object will allow other objects to interact with
it. In essence, an interface is a kind of contract which an object exposes to others, where it says to them that
‘I can perform these tasks, and I can store this data. You may use me in this way.’ However, an interface
does not show how the objet does what it does; the data and functionality are all encapsulated (hidden) within
the object.
With data and implementation details of the object being hidden, the object can be easily changed or re placed
without affecting the objects that use the data. This leads to a design that is more maintainable.
6.3 Design Patterns

As developers worked on more and more software projects, it was found that even though the types of
software are quite diverse, they all fall into a few groups which follow similar patterns of development. In other
words, many different software products could be developed using the same approach because of similarities
between the architectures of the software types.
The pattern is essentially a solution to a problem which may be reused in different settings, but it is not a
detailed specification. It is a set of guidelines rather than a prescription. Design patterns are usually
associated with object-oriented design. Patterns are a way of reusing the knowledge and experience of other
designers.
The essential elements of design patterns are:

1. A meaningful name.
2. A description of the pattern which explains when the pattern may be applied.
3. A solution description of the parts of the design solution, their relationships, and their
responsibilities. This solution is a template for a design that can be instantiated in different ways.
4. A statement of the consequences – the results and trade-offs – of applying the pattern.
The solution can also be expressed graphically in a way which shows the relationships between the objects
and object classes in the solution. These supplement the pattern description and add detail to the solution
description.

To use patterns in your design, you need to recognize that any design problem you are faced with may have
an associated pattern that can be applied.
The following table lists a few common design patterns and explains their uses:
Observer pattern Tell several objects that the state of some other object has changed
Façade pattern Tidy up the interfaces to a number of related objects that have often been developed
incrementally
Iterator pattern Provide a standard way of accessing the elements in a collection, irrespective of how
that collection is implemented
Decorator pattern Allow for the possibility of extending the functionality of an existing class at run-time
Design patterns
Search the web and research 3 more design patterns. Display these patterns
as well as their uses in a table, as shown in the previous table.
6.4 Implementation Issues

6.4.1 Reuse
Reuse of existing components is now a common trend with companies having similar functionalities but either
wants to add or remove certain aspects of the common software application that is not needed for their use.
Instead of just reinventing the wheel, reuse of existing components of a system is encouraged to meet clients’
project timelines.
Software reuse is possible at a number of different levels:

1. At the abstraction level, you don’t reuse software directly but rather use knowledge of successful
abstractions in the design of your software.
2. At the object level, you directly reuse objects from a library rather than writing the code yourself.
To implement this type of reuse, you have to find appropriate libraries and discover if the objects
and methods offer the functionality that you need.
3. At the component level, components are collections of objects and object classes that operate
together to provide related functions and services. You can adapt and extend the component by
adding some code of your own.

4. At the system level, you reuse entire application systems. This usually involves some kind of
configuration of these systems, by adding and modifying code or by using the system’s own
configuration interface.
. In principle, any contributor to an open source project may report and fix bugs and propose new featu res
and functionality. However, in practice, open source systems still rely on a core group of developers who
control and moderate changes to the software. The best-known open source product is the Linux operating
system which is widely used as a server and increasingly as a desktop environment, and has many developed
distributions.
By reusing existing software, you can develop new systems more quickly, with fewer development risks and
also lower costs. However, there are costs associated with reuse:
1. The cost of the time spent on looking for the software and its assessment.
2. The cost buying.
3. The cost of adapting and configuring.
4. The costs of integration
Consideration should be taken in researching the possibilities of reusing of existing components and so ftware
before designing the software in detail.
6.4.2 Configuration management

Change happens all the time, let alone in software development, so change management is absolutely
essential. Configuration management is the general process of managing a cha nging software system. The
aim of configuration management is to support the system integration process so that all developers can
access the project code and documents in a controlled way, find out what changes have been made, and
compile and link components to create a system. Due to this change, there are three fundamental
configuration management activities:
1. Version management – support is provided to keep track of the different versions of software
components.
2. System integration – support is provided to help developers define what versions of components are
used to create each version of a system.
3. Problem tracking – support is provided to allow users to report bugs and other problems, and to allow
all developers to see who is working on these problems and when they are fixed.
6.5 Open-Source Development

Open source software is developed software with source code that is publicly available, under an open source
license, and is open for anyone to study, change, and improve its design. Examples of such open source
software are the generally well known and established Mozilla Firefox, Google Chromium, Android, to name
a few.

Open source development is an approach to software development in which the source code of a software
system is published and volunteers are invited to participate in the development process
Some advantages of open source development are:

1. It is fairly cheap or free to acquire as well as to download.
2. Very reliable.
A large population of users are willing to fix problems themselves rather than report these problems to the
developer and wait for a new release of the system. Bugs are discovered and repaired more quickly than is
usually possible with proprietary software.
Many companies believe that adopting an open source approach will reveal confidential business knowledge
to their competitors and so are reluctant to adopt this development model. However, if you are w orking in a
small company and you open source your software, this may reassure customers that they will be able to
support the software if your company goes out of business.
6.5.1 Open source licensing

A question often arises that if open-source means that the source is publicly available, then why bother with
a license? Though open-source development means that source code should be freely available, this does
not mean that anyone can do as they wish with that code. Legally, the developer of the code (e ither a
company or an individual) still owns the code. They can place restrictions on how it is used by including
legally binding conditions in an open source software license.
Most open source licenses are derived from one of three general models:
1. The GNU General Public License (GPL)
2. The GNU Lesser General Public License (LGPL)
3. The Berkley Standard Distribution (BSD) License
6.6 Summary
• The software design and implementation is the stage in software engineering at which an executable
software system is developed
• Software design and implementation is only one of a set of processes (requirements engineering,
verification and validation, etc.) involved in software engineering
• Most software systems these days are developed using the object oriented programming.
• An object is a data structure which has a state and a set of behaviours
• The state of an object is represented by the data it holds, while the behaviour is represented by the
functions which work on that data

• To develop a system design from concept to detailed, object-oriented design, there are several things
that need to be done:
o Understand and define the context and the external interactions with the system.
o Design the system architecture.
o Identify the principal objects in the system.
o Develop design models.
o Specify interfaces.
• The first stage in any software design process is to develop an understanding of the relationships
between the software that is being designed and its external environment
• The next step in the development process is to use the system context information as a basis for
designing the system architecture
• What will be required at the next stage is to identify all the objects and interactions within the system
• Based on the type of system being developed, and the specific requirements, a design pattern needs
to be chosen
• A design pattern is a solution to a problem which may be reused in different settings, but it is not a
detailed specification
• The last stage in the software development process is the implementation stage, where the working
software product is created
• Open source software is developed software with source code that is publicly available, under an
open source license, and is open for anyone to study, change, and improve its design

1. Define the term ‘object’
2. Define the UML
3. How do the system context models and interaction models present complementary views of the
relationships between a system and its environment?
4. List four methods which may be used to model the objects in an object-oriented system.

Unit
7: System Development

7.1 Introduction - System Development • Understand the concept of architectural patterns
7.2 Architectural Patterns • Be familiar with four popular architectural patterns
7.3 Developing A Prototype Application • Develop an object-oriented client/server system for the
with A Client-Server Architecture Internet
• Analyse and develop a prototype of a business system

Pearson.

Pearson.

7.1 Introduction
System Development
After the processes of systems analysis and design, comes the actual development of the software. As we
have seen in the previous chapters, there are many different types of software, and each type has its own
approach for analysis as well as design and implementation. The process of designing and implementing the
system, also known as architectural design, is concerned with understanding how a system should be
organized and designing the overall structure of that system.
During the architectural design stage, the system architects have to make a number of decisions about the
structure of the system to be built; these decisions will impact the system and its development proces s. The
architects will have to consider the following fundamental questions about the system:
1. Is there a generic application architecture that can act as a template for the system that is being
designed?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements of the
system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?
7.2 Architectural Patterns

In modern day development, idea of architectural patterns as a way of presenting, sharing, and reusing
knowledge about software systems has become widely used in order to expedite the software development
process. An architectural pattern is a stylized, abstract description of good practice, which has been tried and
tested in different systems and environments. It is, in essence, a way to organize and develop a system which
has proven successful in previous systems which were developed by the same or other teams. This results
in large savings in time and money, and leads to systems which are well -designed, robust, scalable and
maintainable.

Some of the most commonly used architectural patterns are shown below:
1. Layered architecture: this is a type of architecture where the system is organized in separate
layers, each of which is independent of the others, but work together. An example of a layered
architecture is the Model-View-Controller architecture.
2. Repository architecture: a type of architecture where the system is organized around a database or
data repository which contains a large amount of data.
3. Client–server architecture: In a client–server architecture, the software system is organized into
services, with each service delivered from a separate server. Clients are other software systems
which are users of these services and access servers to make use of them.
4. Pipe and filter architecture: This is a type of architecture where the system is designed such that data
flows from one to another and is transformed as it moves through the sequence.
Architectural patterns
Study Sommerville to get a deeper understanding of architectural patterns
7.3 Developing A Prototype Application With A Client-Server Architecture

In this Unit we will create a prototype of an app which implements the client-server architecture. Software
developers use a variety of prototyping tools in order to create prototypes, among them Microsoft Access.
For the current project we will use Access 2010.
Prototyping tools
Research and evaluate two more prototyping tools besides Microsoft Access
2010 .
The application we are going to build is a simple asset tracking system to track a fleet of vehicles owned by
the client. The client has roughly 50 vehicles, of which some may be:
• In use by staff members
• At the garage for a service
• In any one of the client’s 3 branches in Durban, Johannesburg and Cape Town

The client needs to know where each vehicle is at any point in time. Currently there is no system in place,
and everything is done using a white board in the client’s office. The client wishes to create an application
software to handle the tracking, because as the fleet grows, it is becoming increasingly difficult to use the
existing white board system. However, the client is not exactly sure about the specifications of the system,
other than the following:
1. The system should track his vehicles
2. Each vehicle will be identified by its registration number. Other information about each vehicle
which should be on the system are the make, model and colour of the vehicle.
3. Whenever the status of a vehicle changes, the system must be updated at any one of the client’s
branches in Durban, Johannesburg and Cape Town.
4. The status of the vehicle will be any one of the following:
a. Durban branch
b. Johannesburg branch
c. Cape Town branch
d. On loan to staff
e. Garage
Activity 7.1
Requirements analysis and specification

As you can see, the client’s requirements are quite vague, but this is almost a norm in software
engineering. Remember that your clients will typically be business people and not technical
people, so you cannot expect them to have a very good understanding of software systems.
It is your job as the systems analyst or project manager to solicit these requirements from the
client, and to fill in the blanks using the various requirements-gathering techniques discussed
in this module.
Because the client is uncertain about anything beyond the above information, it was decided
to build a prototype which he can use to see if it meets his requirements. In a group, analyse
the client’s needs and write down a requirements specification for the prototype system.

7.3.1 Developing the prototype in Access 2010
Activity 7.2
System development
Now that you have analysed the client’s needs, and have specified the system
to be built, the next step is to build the actual system.
Since the prototype will be built using Microsoft Access 2010, you will need to
acquire a copy of the software. Microsoft offers a free 60-day trial on their Office
Professional 2010 product, which contains Access as part of the package. You
may download it at the following link:
http://www2.buyoffice.microsoft.com/usa/product.aspx?family=o14_officepro_try&country_id=US&
WT.mc_id=ODC_enUS_Pro_Try
1. Open Access 2010 and create a new blank database.

2. In the new table which appears, click on ‘Click to Add’ to add a new database field. Select the ‘Text’ option
from the list, and name the field ‘Registration number’.
3. Repeat the above process to create the following fields:

a. Vehicle make
b. Model
c. Colour

4. Now we will add the field for the status. We will implement the status field as a dropdown list, from
which the users may select a status to set a vehicle. To do this, click on the ‘Click to Add’ option, and
then select the ‘Lookup & Relationship’ option:
5. The ‘Lookup Wizard’ will appear:
Click on the second radio button, as shown above. Click ‘Next’

6. In the next screen, type in the lookup values into the space provided, as shown below, and then click
‘Next’
7. Type in the name of the field, which is ‘Status’ in this case, and click ‘Next’

8. Save the table as ‘Vehicle’
By this stage we have created the database table for the application. In the next step we will create a
form for easy data entry.
1. Click on the ‘Create’ tab in the Access ribbon, and then click on the ‘Form Wizard’ button, as shown
below:
The ‘Form Wizard’ will appear. Click on the ‘>>’ button to get all the fields onto the left box, as shown
below, and the click ‘Next’

2. At the next screen, click ‘Next’
3. Set the name of the form as Vehicle, as shown below, and then click ‘Finish’

4. The following form will be created:
The form represents the ‘front-end’ of the app, the part of the app which the users will interface with. The database
represents the ‘back-end’ of the app which, as the name suggests, is what operates behind the scenes of the app.
In the existing app, the front-end and the back end are all bundled into one single package. The problem with the
current architecture is that only one person can update the database at a time, and the application can only reside
and function on a single computer. However, in a client-server architecture, the front-end
and back-end are separated, and may live on the same machine or on different machines. The following diagram
illustrates this:

As a result, more than one front end, or client, can access the back-end, as shown below:
Each client may reside on a separate computer within the same network, or even on another network which is
connected to the server’s network.
7.2.2 Implementing a client-server architecture

We are now going to convert the app into a client-server architecture.
1. To begin the process, ensure that your table and form are both saved and closed. Then click on
the ‘Database Tools’ tab, and then click on the ‘Access Database’ button:

2. The ‘Database Splitter’ dialogue box will appear. Click on the ‘Split Database’ button:
3. Select a name and location for the Back-end database, and then click ‘Split’
Your application will now be split. If you look at the file structure, where there was just a single file, your app
will now comprise of two files – one is the front-end, and the other the back-end. Technically, you can move
the back-end to a shared folder or a server, and allow anyone you wish to gain access to it via the front end
which you may distribute to others. Any changes made by other users will appear on your app too, because
the database is a shared database which resides on a common server.

7.4 Summary
• After the processes of systems analysis and design, comes the actual development of the software
• During the architectural design stage, the system architects have to make a number of decisions
about the structure of the system to be built
• The system architects will have to consider a number of fundamental ques tions about the system.
• These days’ architectural patterns are used to plan and develop systems
• An architectural pattern is a stylized, abstract description of good practice, which has been tried and
tested in different systems and environments
• Some of the most commonly used architectural patterns are:
o Layered architecture
o Repository architecture
o Client–server architecture
o Pipe and filter architecture
• Software engineers use a number of tools for system prototyping, among them Microsoft Access

1. What are the benefits of using an architectural pattern in designing and developing a software
system?
2. What are some of the questions which system architects need to answer prior to commencing work
on a system?
3. Name and describe four architectural patterns.
4. What are the advantages of implementing a client-server architecture in a software system?

Answers To Revision Questions and Activities
Unit 1
Answers to Revision Questions
1. Professional software comprises of more than just the computer program – it contains all related
documentation such as user manuals and specification documents.
2. The essential attributes of good software are:
• Dependability: software dependability means that the software is reliable, secure, and safe.
• Efficiency: software should optimize the use of system resources such as memory and processor
cycles and storage space
• Acceptability: software must, most importantly, be acceptable to the clients and the users
3. An importance difference between generic software products and custom software products, for
software engineers in particular, is that in the case of generic software, the company that builds the
software controls the software specification; that is, they determine the functions and features of the
system. The customer purchases the software uses the system as-is, and tries to find ways to adapt
to the parts of the software which are not quite to his requirements. On the other hand, for custom
product the specification is controlled by the client. In this case the software engineers have to get
a firm understanding of the client’s requirements, and build the system accordingly.
Building custom software can be very challenging. In many instances the client himself is not very
clear about the specifications of the system, so it is the responsibility of the software team to fil l in
the blanks using various requirements-gathering techniques to get the exact system requirements.
In other cases, the client may understand what he requires, but due to external factors, the
specification of the software keeps changing. In this case, the software engineers have to specify
and build the system in such a way that it embraces the changes as they occur.
4. The four fundamental activities common to all software processes are:

1 - Specification: where customers and engineers define the software that is to be produced and the
constraints on its operation. The specification details the purpose for developing a software
product. The specification is the first thing to be done before starting a project.
2 - Development: where the software is designed and programmed. In the development phase, the
design of a product can be modelled to what the product will look like and what the product is to
do.
3 - Validation: where the software is checked to ensure that it is what the customer requires. Here
is where the customer makes their final decision. The final product is tested by the customer to

ensure that the product meets all their set requirements as specified at the beginning of the
project.
4 - Evolution: where the software is modified to reflect changing customer and market
requirements. The product can be modified to meet another customer’s requirements.
5. The four essential attributes of good software are:

• Dependability: software dependability means that the software is reliable, secure, and safe.
• Efficiency: software should optimize the use of system resources such as memory and
processor cycles and storage space
• Acceptability: software must, most importantly, be acceptable to the clients and the users.
Other significant attributes may be user-friendliness and attractive, intuitive interfaces
6. The web has dramatically changed how software is developed and used. Below are some of the
ways in which this has happened:
• Whereas traditional stand-alone software systems were deployed on a single computer, web-
based systems are deployed on a server, and accessed over the Web with browsers
• Web-based software is available for use by any number of people, on a global scale
• It can also be accessed by the developers from anywhere in the world
• This made it cheaper to change and upgrade and also reduced costs
Unit 2
1. The four fundamental steps which are fundamental to software engineering are:
• - Software specification: this describes what exactly the software should do, and what are
the internal, as well as external, requirements for the software to run effectively
• - Software design and implementation: Based on the specification given, the software is
designed and created, and deployed into its working environment
• - Software validation: The software must be tested to see that it is bug free, and that it
does what it was intended to do
• - Software evolution: The software must be constantly improved to meet the changing
needs of the environment in which it is used
2. There are usually two views of the requirements of a system:

• - High-level view: this is an overview, without any technical details. The end users and
customers need a high level view of the specifications. They are primarily concerned with
what the system should do, not how it will do it
• - Detailed view: The development team needs to have a much more detailed view of the
system, as they will be the ones who will be building it. They are the concerned with how
the system functions
3. Businesses are constantly undergoing changes, and this change is inevitable. As a result of this,
software systems which the business depends on need to change accordingly. The incremental
approach to programming respond and embraces change much better than most other approaches,
because the software is delivered in small increments rather than as a whole system. If there are
business changes after an increment is released, then these changes can be incorporated into the
new increment of the system. This makes incremental development ideal for business systems.
4. The design and implementation step comprises of four activities:
• - Architectural design: here the overall structure of the system is determined, along with all
the components which will be required
• - Interface design: this activity determines how the various components will interact with one
another. Software components such as classes interact via their interfaces. An interface is
a set of rules which a component exposes to other components, which state exactly what
the component can do, and how other components may interact with it
• - Component design: each component of the system is designed
• - Database design: if an existing database is to be used, then this activity will determine
exactly how the new system will interact with it. If a brand new database is to be created for
the new app, then during this activity the team will be concerned wit h the data structures
which will be utilized by the system, as well as how the data will be stored in the database
5. Software validation is the process of checking that the software being developed to see that it is bug
free, and that it does what it was intended to do
The primary task during the software validation step is to ascertain two things:
• - That the system fulfils its requirements
• - That the system meets the expectations of the client
6. Testing of a system generally occurs in three stages:
• - Development testing: this type of testing is typically done by the programmers, and is
where each component is tested individually. Development testing is normally done during
the implementation stage, as each component is developed
• - System testing: after individual components have been created and independently tested,
they are integrated to form a complete system. Even though each component may be bug
free, it is highly possible that certain bugs may arise when they attempt to interact with each

other as parts of the greater system. At this level system testing takes place. System testing
is concerned with finding errors which may occur as a result of the interactions between
components of the system
• - Acceptance testing: at this stage the system is tested by the client with real data, not
simulated data. Acceptance testing is concerned with detecting errors and omissions in the
system requirements. It is possible that the system is completely bug -free, but has totally
left out certain required functionality – this will be detected at this stage
Unit 3
1 Difference between Agile and Plan-driven development approaches.
a. Agile approaches to software development do not consider the processes of requirements elicitation,
design and development to be separate processes; rather they all incorporated, and take place
together.
b. A plan-driven approach to software engineering separates the stages in the software process, and
specifies outputs which are associated with each stage. In other words, the activities all take place
in a sequential manner, and the outputs from one stage are used as a basis for planning the following
process activity. In a plan-driven approach, iteration occurs within activities, with formal documents
used to communicate between stages of the process.
2 The principles of agile methods are:
a. - Customer involvement: it is essential to involve the customer closely throughout the
development process, to provide and prioritize requirements and evaluate the iterations of the
system.
b. - Incremental delivery: the software is delivered in small increments rather than as a complete
product. Each increment will include a small number of new functions and features. It is the
client’s responsibility to state which functions and features will be included in each increment.
c. - People not process: the focus is on people. Each team member brings his or her own talents
and skills to the table, and this is recognized and leveraged for the good of the project. All
members are hence left to develop in their own ways and there are no prescriptive processes.
d. - Embrace change: rather than avoiding change, agile methods take it for grante d that there will
be changes in the project, and so forces the team to design the system in such a way that it
accommodates change.
e. - Maintain simplicity: focus on simplicity in both the software being developed and in the
development process.

3 The four phases of the XP Process are:

a. Planning
b. Design
c. Coding
d. Testing
The four phases are executed as follows:

In the planning phase, story cards are the main inputs. Once the story cards are developed, the development
team breaks these down into tasks and determines the effort and resources required for implementation. The
customer then prioritizes the stories for implementation.
A story card is a use case tool for simple story telling, or comprehension of a particular topic. This is where
the user of a system captures what they do or need to do as part of their job function. They capture the ‘who’,
‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be hand -written
on a small paper note card. For example, if a customer wanted a tablet to do things like a typical computer,
then the customer must write the scenario into a story in order for the developing team to extract out the
necessary requirements.
The client will select the stories which will be developed in the next iteration. The client should be careful not
to select too many stories; he should only choose enough stories which the development team will be able to
complete within two weeks. The developers then take one card at a time and implement the func tionality
which it indicates. By the end of the two-week period, the development team will release the next iteration of
the system to the user, and the user will test it thoroughly.
4 In test-first development, the programmers have to thoroughly understand the specification so that they
can write tests for the system. This forces them to clarify ambiguities and omissions in the specification
before implementation begins. There are three potential problems with test-first development:
a. Programmers prefer programming to testing and sometimes they take shortcuts when
writing tests.
b. Some tests can be very difficult to write incrementally.
c. It difficult to judge the completeness of a set of tests.
5 In numerous studies which were carried out, in was found that with pair programming, productivity is
comparable with that of two people working independently. Pair programming provides the sharing of
knowledge between the two programmers. Pair programming is a social skill that takes time to learn,
striving for a cooperative way to work that includes give-and-take from both partners regardless of
corporate status

Unit 4
1. The two types of requirements which may be defined for a system are: user requirements and system
requirements. These are defined as follows:
a. - User requirements are statements, in a natural language plus diagrams, of what services
the system is expected to provide to system users and the constrai nts under which it must
operate.
b. - System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document should define
exactly what is to be implemented.
2. The requirements of a system may be classified as functional requirements or non-functional

requirements:
a. - Functional requirements: Explains what has to be done by identifying the necessary task,
action or activity that must be accomplished.
b. - Non-functional requirements: Requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behaviours.
3. The requirements engineering process includes four high-level activities:

a. - Feasibility study: assesses whether the system is useful to the business or not
b. - Elicitation and analysis: determines the requirements of the proposed system
c. - Specification: convert the requirements into a standard form that can be understood by
everyone involved in the project
d. - Validation: check that the requirements really define the system that the customer wants.
4. The requirements validation is conducted by the stakeholders, the validation team and the
development team.
If the requirements are not validated, or if there are errors in the validation, then these errors will
carry forward through every subsequent stage in the development process, leading to a product
which does not meet the correct specifications. This may lead to high cos ts of re-planning and
redoing the system, or it may result in disastrous consequences if the incorrect requirements are not
detected prior to deployment.
5. The checks done during requirements validation include:
a. - Validity checks: Additional or different functions may be identified after further thought and
analysis.
b. - Consistency checks: Requirements should not conflict. Fulfilling one requirement should not
cause problems for another requirement.

c. - Completeness check: The requirements document must include requirements that define all
functions and constraints desired by the system user.
d. - Realism check: Requirements should be checked to confirm that they can actually be
implemented. These checks must also consider the budget and schedule for the sy stem
development.
e. - Verifiability: System requirements should always be written so that they can be verified.
6. The activities which take place during the requirements elicitation phase are:
Requirements discovery: involves interacting (working with) the stakeholders of the system to find
out their requirements. During this activity, domain requirements and documentation are also
determined.
Requirements classification and organization: involves taking the unstructured (unorganized)

collection of requirements, groups them and arranges them into suitable classes.
Requirements prioritization and negotiation: involves prioritizing (arranging from most important to
least important) requirements. It also involves finding and solving requirements conflic ts by
negotiating with the people concerned.
Requirements specification: involves documenting the requirements and using it as input for the next
stage of the process.
Unit 5
1. System modelling is the process of developing abstract, graphical models of a system, with each
model presenting a different view or perspective of that system. In system modelling, a graphical
notation is used to represent a system in a way which is simple to express and understand.
2. Context modelling identifies the actors outside a system that would interact with that system.
It is important to model the context of a system because the following critical information is revealed
in the process:
• The system boundaries: what will the system do, and what it will not do
• Overall functionality: a high level view of the functionality of the system
• What is provided by the system’s environment: for example, what data will other systems
provide
• Automation: which processes will be automated, and which will be manual

• Overlaps with existing systems: where will the new system perform similar functions to
existing systems? Sometimes overlap may be unavoidable
3. The use case diagram for a bank ATM machine will be as follows:
4. The activity diagram for processing an order is as follows:

Unit 6
1. An object is a data structure which has a state and a set of behaviours. The state of an object is
represented by the data it holds, while the behaviour is represented by the functions which work on
that data.
2. The Unified Modelling Language (UML) is a standardized general-purpose modelling language which
is used to model object-oriented systems. The standard was created and is managed by the Object
Management Group, and has become the industry standard for modelling object-oriented systems.
UML includes a set of graphic notation techniques to create visual models of object -oriented systems.
UML is used to specify, visualize, modify, construct and document the artefacts of an object-oriented
system.
3. System context models and interaction models present complementary views of the relationships
between a system and its environment: A system context model is a static structural model that
demonstrates the other systems in the environment of the system being developed (see chapter 5)
An interaction model is a dynamic model that shows how the system interacts with its environment
as it is used
4. To identify the objects in an object-oriented system, there are various methods:

1 - The use case description helps to identify objects and operations.
2 - Use of grammatical analysis of the description of the system to be constructed. Objects and
attributes are nouns (names of things, such as ‘person’ and ‘bank account’); operations or servi ces
are verbs (doing-words such as ‘store’, ‘sort’ and ‘transfer’).
3 - Use of tangible entities (things) in the application domain such as aircraft, roles such as manager
or doctor, events such as requests, interactions such as meetings, locations such as offices,
organizational units such as companies and so on.
4 - Use of scenario-based analysis where various scenarios of system use are identified and
analysed, the team responsible for the analysis must identify the required objects, attributes and
operations.
Unit 7
1. Using an architectural pattern two immediate benefits:
a. Using a style allows you to select a proven, well-understood solution to your problems and
defines the organizing principles for the system.

b If developers know that the architecture is based on a familiar style, it helps them
understand its important characteristics.
2. The architects will have to consider the following fundamental questions about the system:
• Is there a generic application architecture that can act as a template for the system that is being
designed?
• How will the system be distributed across a number of cores or processors?
• What architectural patterns or styles might be used?
• What will be the fundamental approach used to structure the system?
• How will the structural components in the system be decomposed into subcomponents?
• What strategy will be used to control the operation of the components in the system?
• What architectural organization is best for delivering the non-functional requirements of the
system?
• How will the architectural design be evaluated?
• How should the architecture of the system be documented?
3. Some of the most commonly used architectural patterns are shown below:
1 - Layered architecture: this is a type of architecture where the system is organized in separate
layers, each of which is independent of the others, but work together. An example of a layered
architecture is the Model-View-Controller architecture.
2 - Repository architecture: a type of architecture where the system is organized around a database
or data repository which contains a large amount of data.
3 - Client–server architecture: In a client–server architecture, the software system is organized into
services, with each service delivered from a separate server. Clients are other software systems
which are users of these services and access servers to make use of them.
4 - Pipe and filter architecture: This is a type of architecture where the system is designed such that
data flows from one to another and is transformed as it moves through the sequence.
4. The benefits of the client-server architecture are as follows:

Distribution of Resources: resources, such as databases, are available to use by many people on
the network.
Centralized Network Access Security: security is managed centrally, and security information, such
as user account names, passwords and computer names, are all stored in a database on a server
Ease of Management: software and security updates can be done at one location, which is the server.
If a client-server situation does not exist, then IT staff would have to update each machine in the
organization.

Conclusion
In this module you’ve covered the software engineering processes and practices which are required to build
good computer software systems. You have come to appreciate the fact that software development consists
of much more than merely sitting at a computer and hacking out some code; rather, due to the vastness and
complexity of modern software systems you have to follow a systematic, scientific approach to software
development.
You have been introduced to universal software development processes which are used to create all kinds
of software from critical business systems to computer games. You have been introduced to software
engineering practice like Agile methods which are in use in software development teams globally. You have
also learnt how software systems are modelled, designed and implemented.
You have also developed your own client-server business application.
In the Software Engineering Practice module you will be introduced to aspects of software engineering which
are not directly related to the system being built, but are necessary for the success of the overall software
project. Concepts like project quality management, people management and project planning are vital skills
ever project manager and IT manager should be very familiar with. We cover these and other concepts in
Software Engineering Practice.


BCOM ITM - Principles of Software Engineering

Uploaded by

Copyright:

Available Formats

BCOM ITM - Principles of Software Engineering

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

BCOM ITM - Principles of Software Engineering

Uploaded by

Copyright:

Available Formats

Bachelor of Commerce

in Information and Technology

Unit 1: Introduction to Software Engineering ............................................................................................ 10

Unit 2: Software Processes ..................................................................................................................... 21

Unit 3: Agile Software development ......................................................................................................... 41

Unit 4: Requirements engineering ........................................................................................................... 57

Unit 5: System modelling......................................................................................................................... 74

Unit 6: Design and implementation .......................................................................................................... 87

Unit 7: System Development ................................................................................................................... 99

We hope you enjoy the module.

2 MANCOSA – Bachelor of Commerce in Information and Technology Management

Unit 2: Software Processes

Unit 3: Agile Software Development

Unit 4: Requirements Engineering

Unit 5: System Modelling

Unit 6: Design and Implementation

Unit 7: System Development

MANCOSA – Bachelor of Commerce in Information and Technology Management 3

C. Exit Level Outcomes and Associated Assessment Criteria of the Programme

Exit Level Outcomes (ELOs) Associated Assessment Criteria (AACs)

• The application of information and knowledge • Information and knowledge management

• The application of information and knowledge • Information and knowledge management

• The architecture, platforms and configuration • Architecture, platforms and configuration of

• Utilisation of information and knowledge • Information and knowledge management is

4 MANCOSA – Bachelor of Commerce in Information and Technology Management

D. Learning Outcomes and Associated Assessment Criteria of the Module

LEARNING OUTCOMES OF THE MODULE ASSOCIATED ASSESSMENT CRITERIA OF THE

E. Learning Outcomes of the Units

MANCOSA – Bachelor of Commerce in Information and Technology Management 5

F. Notional Learning Hours

Notional Learning Hour Table for the Programme

Lectures/Workshops (face to face, limited or technologically mediated) 15

Tutorials: individual groups of 30 or less 0

Practical workplace experience (experiential learning/work-based learning etc.) 0

Independent self-study of specially prepared materials (case studies, multi-media, etc.) 40

G. How to Use this Module

6 MANCOSA – Bachelor of Commerce in Information and Technology Management

I. Prescribed and Recommended Textbook/Readings

The prescribed and recommended textbooks/readings for this module is:

• Sommerville, I. (2021). Engineering Software Products: An Introduction to Modern Software

MANCOSA – Bachelor of Commerce in Information and Technology Management 7

Special Feature Icon Explanation

The Associated Assessment Criteria is the evaluation of the students’

PRACTICAL Practical Application or Examples will be discussed to enhance

APPLICATION understanding of this module.

8 MANCOSA – Bachelor of Commerce in Information and Technology Management

Case Studies are included in different sections in this Module Guide.

You may come across links to Videos Activities as well as instructions

VIDEO ACTIVITY on activities to attend to after watching the video.

MANCOSA – Bachelor of Commerce in Information and Technology Management 9

10 MANCOSA – Bachelor of Commerce in Information and Technology Management

Unit Learning Outcomes

CONTENT LIST LEARNING OUTCOMES OF THIS UNIT

1.1 Introduction to Software • Understand what software engineering is and why it is

• Understand the basic principles of software engineering

1.2 Professional Software • Understand that the development of different types of

• Understand some ethical and professional issues that are

1.3 Summary • Summarise topic areas covered in unit

Prescribed and Recommended Textbooks/Readings

• Sommerville, I. (2021). Engineering Software Products: An Introduction