Wolaita Sodo University

School of Informatics
Department of Information Systems

Course Title: System Analysis and Design

Prepared and Compiled by: Eyuel G.

Reviewed By: Admasu D.

April, 2023

Wolaita Sodo University, Ethiopia

i
Contents
Chapter 1: System Development: ...................................................................................................................................... 1
1.1. Introduction to Information System development ............................................................................................. 1
1.2. System development methodologies, / Software life cycle and process model and phase ................................ 5
1.2.1. SDLC Model ............................................................................................................................................ 11
1.3. Problem Identification, Selection and Planning Phase: ................................................................................... 17
1.3.1. Gant and PERT Chart .............................................................................................................................. 24
Chapter 2: Object Orientation the new software paradigm.............................................................................................. 27
2.1. The potential benefits of object orientation ..................................................................................................... 27
2.2. The potential drawbacks of object orientation ................................................................................................. 28
2.3. Object standards............................................................................................................................................... 29
2.4. The object orientation software process and models ....................................................................................... 30
Chapter 3: Understanding the Basics Object oriented concepts ...................................................................................... 33
3.1. OO concepts from structured point of view ..................................................................................................... 33
3.2. Abstraction, Encapsulation and information hiding ........................................................................................ 34
3.3. Inheritance ....................................................................................................................................................... 35
3.4. Association....................................................................................................................................................... 38
3.5. Aggregation ..................................................................................................................................................... 40
3.6. Collaboration ................................................................................................................................................... 42
3.7. Persistence ....................................................................................................................................................... 43
3.8. Coupling........................................................................................................................................................... 43
3.9. Cohesion .......................................................................................................................................................... 44
3.10. Polymorphism .............................................................................................................................................. 45
3.11. Interfaces ...................................................................................................................................................... 45
3.12. Components ................................................................................................................................................. 46
3.13. Patterns......................................................................................................................................................... 46
Chapter 4: Gathering user requirements .......................................................................................................................... 48
4.1. Putting together requirements gathering team ................................................................................................. 49
4.2. Fundamental requirements gathering techniques ............................................................................................. 49
4.2.1. Essential Use Case Modeling................................................................................................................... 56
4.2.2. Essential User Interface Prototyping........................................................................................................ 65
4.2.3. Domain modeling with class responsibility collaborator (CRC) cards .................................................... 68
4.2.4. Developing a supplementary Specification.............................................................................................. 69
4.2.5. Identifying Change Cases ........................................................................................................................ 71
4.3. Ensuring Your Requirements Are correct: Requirement validation Techniques ............................................. 71

ii
 4.3.1. Testing Early and Often ........................................................................................................................... 74
4.3.2. Use Case Scenario Testing....................................................................................................................... 74
Chapter 5: Determining What to Build: OO Analysis .................................................................................................... 75
5.1. System Use Case Modeling ............................................................................................................................. 76
5.2. Sequence Diagrams: From Use Cases to Classes ............................................................................................ 80
5.3. Conceptual Modeling: Class diagrams ............................................................................................................ 84
5.4. Activity diagramming ...................................................................................................................................... 96
5.5. User interface prototyping evolving your supplementary specification .......................................................... 98
5.6. Applying Analysis patterns effectively ............................................................................................................ 99
5.7. User Documentation ........................................................................................................................................ 99
5.8. Organizing your models with packages ......................................................................................................... 100
Chapter 6: Determining How to Build Your System: OO Design ................................................................................. 101
6.1. Layering your models: Class Type Architecture ........................................................................................... 101
6.2. State chart modeling ...................................................................................................................................... 102
6.3. Collaboration Modeling ................................................................................................................................. 105
6.4. Component Modeling .................................................................................................................................... 105
6.5. Deployment Modeling ................................................................................................................................... 106
6.6. Rational Persistence Modeling ...................................................................................................................... 109
6.7. User Interface Design .................................................................................................................................... 110
Chapter 7: Object Oriented Testing and Maintenance ................................................................................................... 112
6.1. An overview of testing ................................................................................................................................... 112
6.1.1. Testing concepts .................................................................................................................................... 113
6.1.2. Testing activities .................................................................................................................................... 113
6.1.3. Managing testing.................................................................................................................................... 117
6.1.4. Impact of object-oriented testing ........................................................................................................... 120
6.1.5. Types of Testing .................................................................................................................................... 121
6.2. Types and procedures of system maintenance; .............................................................................................. 130

iii
 Chapter 1: System Development:
1.1. Introduction to Information System development

Fundamentals of Information System

Information is very important part of any business, which helps the managers to take decisions. The data
flows throughout the organization and makes it active. There are lot of data available in the business, at every
time a transaction takes place ( Ex. a sale ), some data is recorded. It could be recorded on paper or in a
computer system.
The difference between data and information
 Data are raw (unprocessed) facts about people, objects, events in an organization
(Ex. all the sales orders for the year)
 Information is data that have been processed and presented in a form suitable for human
interpretation. (how many of each product were ordered in each month, may be shown on a graph)
System
A System is an interrelated set of business procedures (or components) used within one business unit,
working together for some purpose.
For Ex. an inventory system in the materials department keeps track of the raw materials supply.
The system takes input from outside, processes it, and sends the resulting output back to its environment.
A system can also defined as collections of people using information technology and processes that define
how people carry out their work. The system also includes informal interactions that take place in an
organization Ex. emails, phone calls.
Characteristics of a System
A System has nine characteristics
1. Components – A component is either an irreducible part or an aggregate of parts , also called as a
subsystem
Figure-1: Characteristics of System
2. Interrelated Components – The function of one component is tied to the functions of the others. Output
from one is input for another, the dependence of a part on one or more other parts.
3. Boundary – A system has boundary, within which all of its components are contained and which
establishes the limits of a system, separating it from other systems. Components within the boundary can
be changed whereas systems outside the boundary cannot be changed.
4. Purpose – All components work together to achieve the overall purpose of the system.
5. Environment – A system exist within an environment, everything outside the system‘s boundary that
influences and / or interacts the system.
6. Interfaces – The points at which the system meets its environment and there are also interfaces between
subsystems.
7. Input – System takes input from its environment
8. Output - System returns output to its environment as a result of its functioning to achieve the purpose.
Output from individual subsystems may be inputs to other subsystems.

1
9. Constraints – There are limits to what the system can do (capacity, speed, and capability), some of these
constraints are imposed inside the system and others are imposed by the environment.

Some important Systems concepts

 Decomposition – is the process of breaking down a system into its smaller components, decomposing
a system also allows us to focus on one particular part of a system, making it easier to think of how to
modify that one part independently of the entire system.
 Modularity is a direct result of decomposition which divides a system into modules of a relatively
uniform size. This makes it easier to understand the system.
 Coupling means that subsystems are dependent on each other, messages are passed between
subsystems. A good system will have very independent subsystems with minimal flows of data
between them. This makes the system simpler and easier to change just one part of the system
without affecting the other parts.
 Cohesion is the extent to which a subsystem performs single functions. Generally coupling must be
reduced and cohesion increased, so that it performs only one function.
Introduction to Information System
Information System
An Information System is an arrangement of people, data, processes, interfaces, networks and technology
that interact for the purpose of supporting and improving both day-to-day operations in a business (data
processing) as well as supporting the problem solving and decision making needs of management
(information services).

2
 Information Techonology

Documents
People Database

Informal Computer

Interactions Network

Processes

The basic components of a computer based information system- People, Processes, Information technology and
informal interactions

The Information System includes the following

 Hardware – Computers, servers and printers
 Software- System software‘s and application software‘s
 Documentation and training materials – The materials created by Systems Analyst to help users to
use the software
 Specific job roles – The roles associated with the overall system, such as the people who run the
computers and the software operating.
 Controls- which are the parts of the software written to prevent fraud and theft
 People- Who uses the software in order to do their job.

3
 Components of IS Application

Types of Information Systems

The main types of IS are
 Transaction Processing Systems
 Management Information Systems
 Decision Support Systems
 Expert Systems
Transaction Processing Systems (TPS)
 TPS automates the handling and capture of data about transactions or business activities
 For each transaction, the system must capture the data, verify that it is valid transaction and accept or
reject it
 Accepted transactions are stored in the system database
 Reporting provides summaries of transactions (ex. daily, weekly)
 The analysis and design of a TPS requires focusing on the firm‘s current procedures for processing
transactions. How the organization tracks, capture, process and output data?
 The goal of TPS development is to improve transaction processing by speeding it up, using fewer
people, improving efficiency and accuracy, integrating it with other organizational information
systems, or providing information not previously available.
Management Information System (MIS)
 MIS takes the raw data available through a TPS and converts them into a meaningful aggregated
form.
 It provides reports of this information to managers
 Developing MIS calls for good understanding of what kind of information mangers require and how
managers use information in their jobs.
 Thus, the System Analyst must develop a good understanding of the business and the transaction
processing systems that provide data for an MIS

4
 Figure-4: Types of Information Systems

Decision support System (DSS)

 Helps the manager to take decisions by analyzing the data
 It provides an interactive environment in which decision maker can quickly manipulate data and
models of business operations
 DSS has three parts, the first part is composed of a database, extracted from a TPS or MIS
 The second part consists of mathematical or graphical models of business processes. The third part is
made up of a user interface that provides a way for the decision maker to communicate with the DSS.
 System Analyst is to concentrate on the three main components database, model base and user
dialogue.

Expert Systems (ES)

 An Es is different from other information systems, it replicates the decision making process by
applying rules to information in the way that an expert would
 An ES is developed for a particular area of knowledge or domain, Ex Medical diagnosis, Weather
forecasting, etc.
 The ES asks questions, and the end user supplies the answers, rules applied on the answers and the
ES provides a recommendation.
 The focus on developing and ES is acquiring the knowledge of the expert in the particular problem
domain. Knowledge engineers perform knowledge acquisition.

1.2. System development methodologies, / Software life cycle and process model and phase
Systems Analysis and Design – core concepts
Systems Analysis: Systems Analysis is the study of a business problem domain for the purpose of
recommending improvements and specifying the business requirements for the solution.
Systems Design: Systems Design is the specification or construction of a technical, computer based solution
for the business requirements identified during systems analysis.
Systems Analysis and Design (SAD)
 Information systems analysis and design is a method used by companies to create and maintain
information systems that perform basic business functions.
 The main goal of SAD is to improve organizational systems through developing or acquiring
application software that can help employees accomplish key business tasks more easily and
efficiently.
5
  An application software is designed to support a specific organizational function or process, such as
inventory management, payroll. The goal of application software is to turn data into information.
 An Information System is developed by following Software Engineering Process, which consists of
proven methodologies, techniques and tool. These three process work together to form an
organization approach to SAD

Methodologies

Techniques Tools

Software Engineering Process

 Methodologies are sequence of step by step approaches that helps to develop the final product. The
methodologies incorporate techniques like, direct observations and interviews with users.
 Techniques provide support for a wide range of tasks including conducting interviews with users,
planning and managing the activities of a project and designing the reports.
 Tools are computer programs, such as computer aided software engineering (CASE) tools, that make
it easy to use specific techniques.

Approaches to Systems Analysis and Design

Every Information System consists of three key components that anyone who analyzes and designs must
understand, they are data, data flows and processing logic.

Data: are raw facts that describe people, objects and events in an organization.
Example: customers account no, account type, balance amount
Dataflow: are groups of data that move and flow through a system
Example: customers account number is captured when he uses a credit card for purchase

Data Flow Account no and trans. date

6
 Valid account no. and
transaction data
Validate

Credit

Transaction

Account no. and

transaction

Prepare
statement

Data flow

Processing Logic describes the steps that transform the data and the events that trigger these steps
Ex. processing logic in a credit card bill preparation

Process Oriented approach

Traditionally, Systems Analysts designed an Information System based on what the system was meant to do,
such as billing or inventory control.
 The focus was on outputs and processing logic, in other words, on the flow, use and transformation of
data.
 The data used as inputs were seen as important also, but secondary to the application
 Each system would contain its own files and data storage areas
 The data in each system would match the specifications for that system only
 Each systems was considered ( looked at) separately
 The analysis involved in creating drawings / diagrams that show how the data moves around the
system and where it is stored in between flows.
 The problems with this approach are, first the existence of several files of data each locked with
different applications and programs. Second, many of the files in different applications contain same
data, updating the data becomes tedious process, it also difficult to combine data files created for
specific applications.

Registration Class

system Scheduling

Student DB Courses DB Courses DB Staff DB

Process Oriented Approach

7
Data Oriented approach
Over time the approach changed to being a more data-oriented. This was a response to the problems above
 This approach tends to focus on how the data should be represented independently of where and how
data are used in the system
 A data model is produced, which describes the data and relationships between the data. Business rules
define how the organization deals with the data
 Databases are designed around the subjects such as customers, suppliers, parts. This lets use the dame
databases for many different applications
 This means that the application is independent of data and data definitions it is called as application
independence
Systems Integration approach
Today, systems development focuses on systems integration. Systems integration allows hardware and
software from different vendors to work together in an application.

Registration Class

system Scheduling

Student DB Courses DB Staff DB

Figure-4: Data Oriented Approach

Role of the System Analyst

 A system analyst bridges the communication gap between those who need the information system and
those who understand the technology
 A system analyst facilitates the study of the problems and needs of a business to determine how the
business systems and information technology can best solve the problem and accomplish improvements
for the business.
 Involving End users – it is important to include the people (users or end users) who are involved in the
system. Since,
- They use the system, or will use the new system
- They know about the data and / or processes in the system
- They require reports from the system
 Involving mangers – managers in the business also need to be considered, since
- They define the business goals for projects
- They need to know what resources are required for a project
- They need to know how long the project will take
- They make the decisions
 To succeed as a systems analyst, the skills needed are analytical, technical, managerial and
interpersonal.
 Analytical skill enables to understand the organization and its functions, to identify opportunities and
problems and to analyze and solve problems

8
 Technical skill helps to understand the potential and the limitations of information technology. Must be
able to work with programming languages and operating systems.
 Managerial skill helps to manage project, resources, risk and changes.
 Interpersonal skill enables to work with end users as well as other analysts and programmers. Effective
written and oral communication skills : a system analyst plays a major role as liaison among users,
programmers and other analyst. Hence effective written and oral communication skill, including
competence in leading meetings, interviewing end users, and listening are very much required.

Systems Development Life Cycle – SDLC

System development life cycle (SDLC)
 The series of steps used to mark the phases of development for an information system. It is a common
methodology for systems development

Software Development Life Cycle

 Like any other processes, the development of information system is too follows a life cycle Example: a
commercial product such as a Maruthi car follows a life cycle: It is created, tested and introduced to the
market. Its sales increase, peak and decline. Finally the product is removed from the market and replaced
by something else.
 The life cycle of an information system may as follows. Someone has idea for an information system and
what it should do. A careful study is done of how the organization currently handles the work the system
will support.
 Professionals develop a strategy for designing the new system, which is then either built or purchased.
Once complete, the system is installed in the organization, and after proper training, the users begin to
incorporate the new system into their daily work.
 The common four SDLC steps are
1) Planning and selection
2) Analysis
3) Design and
4) Implementation and operation.
 The specific steps and their sequence are meant to be adapted as required for a project, if necessary the
project can return to an earlier phase.
 Some activities in one phase in parallel with some activities of another phase. Sometimes the life cycle is
iterative.
 Each phase has specific outcomes and deliverables that feed important information to other phase. These
deliverables are reviewed by parties outside the project team, including managers and executives.

The SDLC is a structured approach; it uses data-oriented approach.

Planning and Selection

 Identify needs
 Feasibility study 9
 Define Scope and
Constraints
 Implementation & Analysis
Operation
 Describe the current
 Coding, testing, system
installation  Determine
 Documentation, requirements
Training and support  Initial design model
 Fixes of new system
Design
 Enhancements
 Logical Design
 Physical Design

Software Development Life Cycle- Detailed

Systems Planning and Selection

The first phase in the SDLC has two primary activities

 Identifying the need for a new or enhanced system

Information needs of the organization are examined and projects to meet these needs are identified
from
- Requests to deal with problems in current procedures
- The desire to perform additional tasks
- The realization that information technology could be used to improve the organization
The Systems analyst prioritizes and translates the needs into a written plan including a schedule for
developing new systems.
The organization may decide whether or not the resources devoted for the project and a careful
feasibility study is conducted to determine the economic and organizational impact of the system

 The second task is investigating the system and determining the proposed system’s scope. Then a
specific plan for the proposed project for the team to follow is produced. This Baseline Project Plan
customizes the standardized SDLC and specifies the time and resources needed for its execution

Systems Analysis
It has three sub phases,

 First sub phase involves the systems analyst to determine the requirements of the system, i.e., what
the users want from a proposed system
 Next, the requirements gathered are structured (DFD, ERD) according to their interrelationships,
eliminating the redundancies
 Third, system analyst has to generate alternative initial designs to match the requirements, best suited
design is selected for the development after the comparison of all alternative designs

Systems Design
 The system analyst converts the description of recommended solution into logical and physical
designs

10
  Logical design involves in designing the user interface, databases and compute processes, irrespective
of the programming languages ( Algorithms, input and output forms, reports, table normalization)
 During the Physical design, the analyst team decides the programming language, database systems to
be used, hardware platform, operating systems and network environment.
 The final outcome of the design phase is the physical system specifications, presented in the form
such as a diagram or written report ready to be turned over to programmers and other system builders
for construction.

Systems Implementation and operation

 In this phase the information system is coded, tested and installed in the organization, and in which
the information system is systematically repaired and improved
 Planning for both testing and installation is to be done as early as the project planning and selection
phase, because they both require extensive analysis in order to develop exactly the right approach.
 This phase also includes the initial training to the users and documentation of the system documented
throughout the life cycle.
 During operation part, the problems faced by the users should be solved, and changes and
enhancements (new versions) is to be made as per the users‘ desire to reflect changing business
conditions.
 There inevitably comes a time, when an information system is no longer performing as desired, when
the costs of keeping a system running become prohibitive, or when an organization‘s needs have
changed substantially. Such problems indicate that it is time to begin designing the system‘s
replacement, thereby completing the loop and starting the life cycle over again.

Approaches for Development

Prototyping, rapid application development (RAD), Joint application design (JAD) and Participatory design
(PD) are four approaches that streamline and improve the systems analysis and design process.
Prototyping
 Designing and building a scaled-down version of the desired information system with the help of
CASE tools
 Prototyping is a key tool that supports rapid application development. RAD involves gaining user
acceptance of the interface and developing key system capabilities as quickly as possible.
Joint Application Design
 A structured process in which users, managers and analysts work together for several days in a series
of intensive meetings to specify or review system requirements.
Participatory design
 PD involves users in the development process, they have an equal voice in determining system
requirements and in approving system design.

1.2.1. SDLC Model

Waterfall Model
11
The simplest process model is the waterfall model, which states that the phases are organized in a linear
order. In this model, a project begins with feasibility analysis. Upon successfully demonstrating the
feasibility of a project, the requirements analysis and project planning begins.
The design starts after the requirements analysis is complete, and coding begins after the design is complete.
Once the programming is completed, the code is integrated and testing is done. Upon successful completion
of testing, the system is installed. After this, the regular operation and maintenance of the system takes place.
The requirements analysis phase is mentioned as "analysis and planning." Planning is a critical activity in
software development. A good plan is based on the requirements of the system and should be done before
later phases begin. Linear ordering of activities has some important consequences. First, to clearly identify
the end of a phase and the beginning of the next. This is usually done by some verification and validation
means that will ensure that the output of a phase is consistent with its input (which is the output of the
previous phase), and that the output of the phase is consistent with the overall requirements of the system.

The consequence of the need for certification is that each phase must have some defined output that can be
evaluated and certified. That is, when the activities of a phase are completed, there should be some product
that is produced by that phase. The outputs of the earlier phases are often called work products and are
usually in the form of documents like the requirements document or design document.
For the coding phase, the output is the code. Though the set of documents that should be produced in a
project is dependent on how the process is implemented, the following documents generally form a
reasonable set that should be produced in each project:

12
Advantages:

 One of the main advantages of this model is its simplicity.

 It is conceptually straightforward and divides the large task of building a software system
into a series of cleanly divided phases, each phase dealing with a separate logical
concern.
 It is also easy to administer in a contractual setup as each phase is completed and its work
product produced, some amount of money is given by the customer to the developing
organization.

Limitations are:

1. It assumes that the requirements of a system can be frozen before the design begins. But
for new systems, determining the requirements is difficult as the user does not even know
the requirements.
2. Freezing the requirements usually requires choosing the hardware, may become obsolete
over a period of time.
3. The entire software is delivered in one shot at the end. This entails heavy risks, as the
user does not know until the very end what they are getting.

Prototyping

The goal of a prototyping-based development process is that instead of freezing the requirements
before any design or coding can proceed. This prototype is developed based on the currently
known requirements. Development of the prototype obviously undergoes design, coding, and
testing, but each of these phases is not done very formally or thoroughly. By using this
prototype, the client can get an actual feel of the system; because the interactions with the
prototype can enable the client to, better understand the requirements of the desired system.
Prototyping is an attractive idea for complicated and large systems for which there is no manual
process or existing system to help determine the requirements. In both situations, the risks
associated with the projects are being reduced through the use of prototyping. After the prototype
has been developed, the end users and clients are given an opportunity to use the prototype.
Based on their experience, they provide feedback to the developers. Based on the feedback, the
prototype is modified to incorporate some of the suggested changes that can be done easily, and
then the users and the clients are again allowed to use the system. Based on the feedback, the
initial requirements are modified to produce the final requirements specification, which is then
used to develop the production quality system. The focus of the development is to include those
features that are not properly understood. And the development approach is with the focus on
quick development rather than quality.

13
Advantages of Prototyping

1. Users are actively involved in the development

2. It provides a better system to users, as users have natural tendency to change their mind
in specifying requirements and this method of developing systems supports this user
tendency.
3. Errors can be detected much earlier as the system is made side by side.

Limitations of Prototyping

1. This Model Leads to ‗implementing and then repairing‘ way of building systems.
2. This may increase the complexity of the system as scope of the system may expand
beyond original plans.
3. Cost of implementing this method for larger or complex systems is more.

Iterative Development

The iterative development process model tries to combine the benefits of both prototyping and
the waterfall model. The basic idea is that the software should be developed in increments, each
increment adding some functional capability to the system until the full system is implemented.
At each step, extensions and design modifications can be made. An advantage of this approach is
that it can result in better testing because testing each increment is likely to be easier than testing
the entire system as in the waterfall model. The prototyping, the increments provide feedback to
the client that is useful for determining the final requirements of the system.

Iterative Enhancement Life Cycle Model

This model counters the second limitation of the waterfall model and tries to combine the
benefits of both prototyping and the waterfall model. The basic idea is that the software should
be developed in increments, where each increment adds some functional capability to the system
until the full system is implemented. At each step extensions and design modifications can be
made. An advantage of this approach is that it can result in better testing, since testing each
increment is likely to be easier than testing entire system like in the waterfall model. The
increments provide feedback to the client which is useful for determining the final requirements
of the system.

14
Spiral Model

The spiral model is another iterative model that has been proposed. As the name suggests, the
activities in this model can be organized like a spiral that has many cycles. Each cycle in the
spiral begins with the identification of objectives for that cycle, the different alternatives that are
possible for achieving the objectives, and the constraints that exist. The focus of evaluation in
this step is based on the risk perception for the project. The next step is to develop strategies that
resolve the uncertainties and risks. Each cycle in the spiral begins with the identification of
objectives for that cycle, the different alternatives that are possible for achieving the objectives,
and the constraints that exist. The focus of evaluation in this step is based on the risk perception
for the project. The next step is to develop strategies that resolve the uncertainties and risks.

15
Agile model

Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In Agile, the tasks are divided to time
boxes (small time frames) to deliver specific features for a release. Iterative approach is taken
and working software build is delivered after each iteration. Each build is incremental in terms of
features; the final build holds all the features required by the customer.

The Agile thought process had started early in the software development and started becoming
popular with time due to its flexibility and adaptability. The most popular Agile methods include
Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996),
Adaptive Software Development, Feature Driven Development, and Dynamic Systems
Development Method (DSDM) (1995). These are now collectively referred to as Agile
Methodologies, after the Agile Manifesto was published in 2001.

Following are the Agile Manifesto principles

 Individuals and interactions − In Agile development, self-organization and motivation are

important, as are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of just
depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
 Responding to change − Agile Development is focused on quick responses to change and
continuous development.

16
Time boxing Model

In this model to speed up development, parallelism between the different iterations can be
employed. That is, a new iteration commences before the system produced by the current
iteration is released, and hence development of a new release happens in parallel with the
development of the current release. By starting iteration before the previous iteration has
completed, it is possible to reduce the average delivery time for iterations. In the time boxing
model, the basic unit of development is a time box, which is of fixed duration. Since the duration
is fixed, a key factor in selecting the requirements or features to be built in a time box is what
can be fit into the time box. Each time box is divided into a sequence of stages, like in the
waterfall model. Each stage performs some clearly defined task for the iteration and produces a
clearly defined output. The model also requires that the duration of each stage, that is, the time it
takes to complete the task of that stage, is approximately the same. Furthermore, the model
requires that there be a dedicated team for each stage. This is quite different from other iterative
models where the implicit assumption is that the same team performs all the different tasks of the
project or the iteration. Having time boxed iterations with stages of equal duration and having
dedicated teams renders itself to pipelining of different iterations. (Pipelining is a concept from
hardware in which different instructions are executed in parallel, with the execution of a new
instruction starting once the first stage of the previous instruction is finished.) As an example,
consider a time box consisting of three stages: requirement specification, build, and deployment.
The requirement stage is executed by its team of analysts and ends with a prioritized list of
requirements to be built in in this iteration along with a high level design. The build team
develops the code for implementing the requirements, and performs the testing. The tested code
is then handed over to the deployment team, which performs pre deployment tests, and then
installs the system for production use. These three stages are such that they can be done in
approximately equal time in iteration.

1.3. Problem Identification, Selection and Planning Phase:

Systems Planning and Selection
This first phase of the systems development life cycle deals with the process of identifying,
selecting, initiating, planning projects and assessing project feasibility.

Project Identification and Selection

The first step is to identify the need for a system, which can be the result of
o Problems in existing system or process
o New feature required in an existing system
o A new idea for which in Information System is required
o A requirement to improve efficiency in the organization
o Compulsory standards or bench marks by an external organization Ex.
Government
o The need to keep up with competitors

17
 During this activity a senior manager, a business group, an Information System manager
or a steering committee identifies and assess all possible systems development projects,
which are all may yield significant organizational benefits.

Key Sources for IS projects

The requests for developing information system can come from three key sources
 Managers and business units who want to replace or extend and existing system in
order to gain needed information or to provide a new service to customers.
 Information Systems mangers who want to make a system more efficient, less
costly to operate or want to move a system to a new operating environment.
 Formal planning group that want to improve an existing system in order to help
the organization meet its corporate objectives, such as providing better customer
service.
The Selection Process may vary in different organizations, but the general process is
discussed below.

General Process of Identifying and Selection Information Systems development Projects

Process of identifying and selection consists of three activities : Identifying potential
development projects, classifying and ranking projects and selecting projects for
development
Identifying potential development projects: This process may be performed by a key
member of top management, or a steering committee composed of a cross section
managers, or User departments, or the development group
Projects identified by top management have a strategic organizational focus, by the
steering committees have a cross functional focus, by the individual departments have a
narrow, tactical focus. The development group identifies projects based on the ease with
existing hardware and systems.
Hence, projects may be identified by both top-down and bottom-up initiatives.
The systems analyst should support these groups, to describe their information needs.
Classifying and ranking IS development projects: Done by top managers, a steering
committee, business units or the IS development group.
The criteria commonly used to evaluate projects are
 Value chain analysis: Extent to which activities add greatest benefits

18
  Strategic alignment: Extent the projects achieves the long term goals
 Potential benefits: Extent to which the project helps to improve profits,
Customer service, etc and the duration of the benefits
 Resource availability: Amount and type of resources required for the
Project
 Project size / duration: Number of individuals and duration to complete
 Technical difficulty / risk: Level of technical difficult to complete.
Selecting IS development Project: The short and long term projects most likely to achieve the
business objectives are considered. As business conditions change over time, the relative
importance of any single project may change.

Factors to be considered during the project selection

The factors must be considered when selecting a project are

 Perceived needs of the organization
 Existing systems and ongoing projects
 Resource availability
 Evaluation criteria
 Current business conditions
 Perspective of the decision makers
Deliverables and outcomes
The primary deliverable or end product form the project identification and selection phase is
a schedule of specific IS development projects.
These projects may come from both top down and bottom up sources
The selected project move into the second activity called Project initiation and planning

19
 Deliverables from Project Identification and selection phase

Project Initiation and Planning

 The objective of project initiation and planning is to transform a vague system
requirements into a tangible project description
 Proper project initiation and planning can reduce the time consumption of further phases
 Activities performed in this phase could also be completed during the next phase, System
analysis
 A rule of thumb is that 10 – 20 % of the entire effort should be expended in this phase
General Process of Initiating and Planning Systems development Projects

 Project Initiation focuses on activities that will help to organize a team to conduct
project planning
 During initiation, one or more analysts are assigned to work with a customer to establish
work standards and communication procedures.
 Project Planning focuses on defining clear, discrete tasks and the work needed to
complete each task
 The objective of the project planning is to produce two documents : a Baseline Project
Plan (BPP) and the Statement of Work (SOW).
 The BPP is an internal document used by the development team but not shared with
customers
 The BPP contains all information collected and analyzed during the project initiation and
planning activity.
 The BPP reflects the best estimate of the project‘s scope, benefits, costs, risks and
resource requirements.
 The BPP specifies detailed project activities for the next life cycle phase- Systems
analysis and less detail for subsequent phases.
 The SOW is a short document prepared for the customers that describes what the project
will deliver and outlines all work required to complete the project
 The SOW is a useful communication tool that assures that both system analysts and
customers have a common understanding of the project.

20
 Statement of Work – an example

Feasibility Study

 Most Information System projects have budgets and deadlines; the analysis of factors for
feasibility forms the business case (analysis of the assumptions like resource availability
and potential problems and system cost and benefits) that justifies the expenditure of the
resources on the project. The feasibility factors are in six categories
 Economic Feasibility
- Concerned with assessing the financial benefits and costs associated with the
project. To do this, it is necessary to quantify the monetary value of the costs and
benefits of the project. This is also called a cost-benefit analysis.
- Benefits and costs can be tangible or intangible
- Tangibles are items which can be quantified in monetary terms and with certainty.
Ex. equipment costs, staff/personnel costs, materials costs, conversion costs,
training costs.
- Intangibles are items for which a value cannot be precisely determined, and where
the value may be the result of subjective judgment. Ex. Customer goodwill,
employee morale. Operational efficiency
- The sum value of all costs identified for the project gives the cost of the system
- The sum value of all the benefits identified for the project gives the benefit of the
systems
- These are then used to determine if the project is economically feasible. There are
two methods for doing this are work sheet method and present value method

21
  Operational Feasibility
- This process examines whether the new project will attain its desired objectives.
- The goal of this study is to understand the degree to which the proposed system
will likely solve the business problems or take advantage of the opportunities
specified in the Systems requirement documents.
 Technical Feasibility
- The goal of this study is to understand the organization‘s ability to construct the
proposed system.
- This analysis also includes an assessment of the development group‘s
understanding of the possible target hardware, software and operating
environments as well as the size, complexity and the group‘s experience with
similar systems
 Schedule Feasibility
- The process of assessing the degree to which the potential time frame and
completion dates for all major activities within a project meet organizational
deadlines and constraints for affecting change.
 Legal and Contractual Feasibility
- The process of assessing potential legal and contractual ramification due to the
construction of a system
- Considerations may include copyright or nondisclosure violation, labor laws,
antitrust legislation, foreign trade regulations and financial reporting standards as
well as current or pending contractual obligations.
 Political Feasibility
- The process of evaluating how key stakeholders within the organization view the
proposed system

Building the Baseline Project Plan

o All the information collected during project initiation and planning is collected and
organized into a document called the Baseline Project Plan.
o Once the BPP is completed, a formal review of the project can be conducted with
customers.
o BPP contains four major sections
1. Introduction
2. System Description
3. Feasibility assessment
4. Management issues
o Introduction section provides a brief overvk2iew of the entire document and outline a
recommended course of action for the project
o It provides an executive summary that specifies the project‘s scope, feasibility,
justification, resource requirements and schedules. Additionally, a brief statement of the
problem, the environment in which the system is to be implemented and constraints that
affect the project are provided
o Recommendation provides a summary of important findings from the planning process
and recommendations for subsequent activities
o System Description section provides a list of alternatives system configuration
o It provides a description of the selected configuration and a narrative of input
information, tasks performed and resultant information

22
 o Feasibility Assessment outlines project costs and benefits and technical difficulties.
High level project schedules are specified using PERT and Gantt charts. The greatest
amount of project planning effort is typically expended on feasibility assessment
activities.
o Management Issues
- Team Configuration and Management: Provides a description of the team
member roles and reporting relationships
- Communication plan: Provides a description of the communication procedures
to be followed by management, team members and the customer
- Project standards and procedures: Provides a description of how deliverables
will be evaluated and accepted by the customer
- Other project-specific topics: Provides a description of any other relevant
issues related to the project uncovered during planning.

Reviewing the Baseline Project Plan

 Before submitting the BPP to some project approval body, it is to be reviewed by the
users, management and development groups.
 The objectives of this review is to assure that the proposed system conforms to
organizational standards and to make sure that all relevant parties understand and agree
with the information contained in the BPP.
 A common method for performing this review is called a structured walkthrough, a peer
group review of any product created during the systems development process.
 The walkthrough may have specific agenda that highlights what is to be covered and the
expected completion time.
 Individuals attending the meeting have specific roles
- Coordinator
- Presenter
- User
- Secretary
- Standard-bearer
- Maintenance oracle
 In addition to reviewing the BPP, the walkthrough can be used for the following
activities
- System specifications
- Logical and physical designs
- Code or program segments
- Test procedures and results
- Manuals and documentation
 The key advantage of using a structured review process is to ensure that found review
points occur during the project. At each phase of the project, a formal review should be
conducted to make sure that all aspects of the projects are satisfactory accomplished
before assigning additional resources to project
 This conservative approach of reviewing each major activity with continuation contingent
on successful completion of the prior phase is called incremental commitment.

23
1.3.1. Gant and PERT Chart
Program Evaluation Review Technique (PERT)

What Is a Program Evaluation Review Technique (PERT) Chart?

A program evaluation review technique (PERT) chart is a graphical representation of a project's timeline
that displays all of the individual tasks necessary to complete the project. As a project management tool,
the PERT chart is often preferred to the Gantt chart because it identifies task dependencies. However, a
PERT chart can be more difficult to interpret. A PERT chart uses circles or rectangles called nodes to
represent project events or milestones. These nodes are linked by vectors, or lines, that represent various
tasks and their dependencies. A PERT chart allows managers to evaluate the time and resources necessary
to manage a project. A PERT Chart Work A project manager creates a PERT chart in order to analyze all
of a project's tasks while estimating the amount of time required to complete each one. Using this
information, the project manager can estimate the minimum amount of time required to complete the
entire project. This information also helps the manager develop a project budget and determine the
resources needed to accomplish the project. A PERT chart uses circles or rectangles, called nodes, to
represent project events or milestones. The nodes are linked by vectors or lines that represent various
tasks. Dependent tasks are items that must be performed in a specific manner. For example, if an arrow is
drawn from Task No. 1 to Task No. 2 on a PERT chart, Task No. 1 must be completed before work on
Task No. 2 begins. Items at the same stage of production but on different task lines within a project are
referred to as parallel tasks. They're independent of each other, and occur at the same time.1 A well-
constructed PERT chart looks like this:

24
Gant chart

A Gantt chart, commonly used in project management, is one of the most popular and useful ways of
showing activities (tasks or events) displayed against time. On the left of the chart is a list of the activities
and along the top is a suitable time scale. Each activity is represented by a bar; the position and length of
the bar reflects the start date, duration and end date of the activity. This allows you to see at a glance:
Gantt chart used for Build and manages a comprehensive project Gantt charts visualize the building
blocks of a project and organize it into smaller, more manageable tasks. The resulting small tasks are
scheduled on the Gantt chart's timeline, along with dependencies between tasks, assignees, and
milestones.

Determine logistics and task dependencies

Gantt charts can be employed to keep an eye on the logistics of a project. Task dependencies ensure that a
new task can only start once another task is completed. If a task is delayed (it happens to the best of us),
then dependent issues are automatically rescheduled. This can be especially useful when planning in a
multi-team environment.

Monitor progress of a project

As teams log time towards issues in your plan, you can monitor the health of your projects and make
adjustments as necessary. Your Gantt chart can include release dates, milestones, or other important
metrics to track your project‘s progress.

The benefits of using a Gantt chart

There are two main reasons Gantt charts are loved throughout the project management world. They make
it easier to create complicated plans, especially those that involve multiple teams and changing deadlines.
Gantt charts help teams to plan work around deadlines and properly allocate resources.

Project planners also use Gantt charts to maintain a bird‘s eye view of projects. They depict, among other
things, the relationship between the start and end dates of tasks, milestones, and dependent tasks.

Modern Gantt chart programs such as Jira Software with Roadmaps and Advanced Roadmaps synthesize
information and illustrate how choices impact deadlines.

How to use Gantt charts?

Jira Software comes with two different road mapping features, each with a slightly different focus. Jira
Roadmaps is designed to track work assigned to a single team while Advanced Roadmaps is designed for
larger, cross-organization project planning.

Elements of basic Gantt chart

By default, a Gantt chart is plain and rudimentary. That doesn‘t mean, however, that this type of project
management tool lacks substance. Gantt charts are typically configured with task names listed along the y
axis, and the project timeline represented on the x axis. Even a simple Gantt chart should include the
following 7 critical elements:

 The list of tasks needed for this project: what are the activities required for project completion?

25
 The start date and end date of each task
 The progress made toward the completion of each task: is the task on track, at risk, or delayed?
 The dependencies across tasks: how do the tasks relate to one another?
 The start date and end date for the entire project
 Important milestone dates within the project‘s timeline
 The project‘s critical path: i.e., the set of tasks that take the longest time to complete in a project
and so provide an estimate of project duration

26
 Chapter 2: Object Orientation the new software paradigm
2.1. The potential benefits of object orientation
Structured Paradigm

The structured paradigm is a development strategy based on the concept that a system should be
separated into two parts: Data and functions/procedures (modeled using a process model). Using
the structured approach, you develop applications in which data is separated from behavior in
both the design model and in the system implementation (that is, the program).

Example: Consider the design of an information system for a university. Taking the structured
approach, you would define the layout of a data initially as a separate system and the design of a
program to access that data as another. The programs have the ability to change the data states.

Object Oriented Paradigm

The main concept behind the object oriented paradigm is that instead of defining systems as two
separate parts (data and functions), system is defined as a collection of interacting objects. It
describes and builds a system that consists of objects. An object oriented system comprises a
number of software objects that interact to achieve the system objective.

The object-oriented paradigm took its shape from the initial concept of a new programming
approach, while the interest in design and analysis methods came much later. The first object–
oriented language was Simula (Simulation of real systems) that was developed in 1960 by
researchers at the Norwegian Computing Center. In 1970, Alan Kay and his research group at
Xerox PARK created a personal computer named Dynabook and the first pure object-oriented
programming language (OOPL) - Smalltalk, for programming the Dynabook. In the 1980s,
Grady Booch published a paper titled Object Oriented Design that mainly presented a design for
the programming language, Ada. In the ensuing editions, he extended his ideas to a complete
object–oriented design method. In the 1990s, Coad incorporated behavioral ideas to object-
oriented methods. The other significant innovations were Object Modeling Techniques (OMT)
by James Rumbaugh and Object-Oriented Software Engineering (OOSE) by Ivar Jacobson.

Increased Reusability

The object oriented paradigm provides opportunities for reuse through the concepts of
inheritance, polymorphism, encapsulation, coupling and cohesion. OO paradigm provides more
opportunities for reuse than the structured paradigm.

Increased Extensibility

Because classes have both data and functionality, when you add new features to the system you
need to make changes in one place – the class.

Improved Quality

27
Quality systems are on time, on budget and meet or exceed the expectations of their users.
Improved quality comes from increased participation of users in systems development. OO
systems development techniques provide greater opportunity for users to participate in the
development process.

Financial Benefits

Reusability, extensibility, and improved quality are all technical benefits. Object orientation
enables you to build systems better, faster and cheaper. The benefits OO are realized throughout
the entire development life cycle, not just programming.

Increased Chance of Project Success

A project is successful if it is on time, on budget and meets the needs of the users. Users are
expert at business and they are the only ones who can tell you what they need. You need to know
the right question to ask, know the business very well. You need models that communicate the
required information and that users understand. You need to work closely with users; Time
invested in defining requirements and modeling pays off in the long run.

Reduce Maintenance Burdon

Software organizations currently spend significant resources (80%) maintaining and operating
software, and because of the long waiting list of work to be done, it takes significant time to get
new projects started. These two problems are respectively called the maintenance Burdon and the
application backlog. These are problems that object orientation can help you to overcome.

2.2. The potential drawbacks of object orientation

Nothing is perfect including OO. While many exiting benefits exist to OO, they come at a price:

 OO requires greater concentration on requirements analysis and design:

 You cannot build a system that meets users‘ needs unless you know what those needs are (you
need to do requirements)
 You cannot built a system unless you know how it all fit together (you need to do analysis and
design)
 But this fact is often ignored by many developers
 Developers must closely work with users
 Users are the experts but they have their own jobs to do (busy)
 OO requires a complete change in the mindset on the part of individuals
 They should understand the benefits of OO
 OO requires the development culture of the IS dept. to change
 The change in the mind set of individual developers actually reflect an overall change in the
development culture
 Do more analysis and design but (less programming) and working with users
 OO is just more than programming
 Many OO benefits are long term
 OO truly pays off when you extend and enhance your system

28
  OO demands up front investments in training education and tools
 Organizations must train and educate their development staff.
 Buy books, development tools and magazines
 OO techniques do not guarantee you will build the right system
 While OO increases the probability of project success, it still depends on the ability of individuals
involved.
 Developers, users, mangers must be working together to have a good working atmosphere.
 OO necessitates increased testing
 OO is typically iterative in nature, and probably developing complex system using the objects, the
end result is you need to spend more time in testing.
 OO is only part of the solution
 You still need CASE tools
 Need to perform quality assurance (QA)
 You still need usable interface so the users can work with the systems effectively

2.3. Object standards

Object orientation today becomes the significant part of the software development. Objects are
the primary enabling technology for components. It defines requirements for the information,
geometry, behavior, and presentation of objects, to give reassurance of quality that will enable
greater collaboration and efficient information exchange across construction industry for the
system. By standardizing objects, you can consistently use, compare, analyze, and share
information to make informed decisions quickly and confidently. The standard is paramount, not
just for some objects as we can create objects to a common data set. Since the lack of structure
and data consistency recognized across all objects, object standard is required to achieve data
consistency and better structure with recognizable set of criteria, to which all objects can be
created.

 CORBA (Common object request broker architecture) – the standard architecture for
supporting distributed objects.
 UML (Unified modeling language)-the standard modeling language for the object oriented
software.
 ANSI (Americans National Standards Institute)-Defined standards for C++.
 Sun Microsystems, actively maintains, enhances and supports a de facto standard definition
for java and related standards such as Enterprise Java Beans (EJB).
 The Object Database Management group (ODMG)- actively maintains, enhances and
supports a standard definition for object oriented databases and object query language
(OQL).
 ANSI (Americans National Standards Institute)-Defined standards for C++.
 Sun Microsystems, actively maintains, enhances and supports a de facto standard definition
for java and related standards such as Enterprise Java Beans (EJB).
 The Object Database Management group (ODMG)- actively maintains, enhances and
supports a standard definition for object oriented databases and object query language
(OQL).

29
2.4. The object orientation software process and models

A software process is a set of related activities that leads to the production of a software
product.
There are many different software processes but all must include four activities that are
fundamental to software engineering:
1. Software specification :The functionality of the software and constraints on its
operation must be defined
2. Software design and implementation: The software to meet the specification must be
produced
3. Software validation: The software must be validated to ensure that it does what the
customer wants
4. Software evolution: The software must evolve to meet changing customer needs
In Object-Oriented Software Process (OOSP), once we understand our needs we can put together
a process to meet them. To understand the requirements for an OOSP, we must look at the
environment for which we are developing these applications. Users and developers must work
closely together in order to correctly define, design, and build OO applications Timely
development of mission-critical applications. Users want all this to happen as inexpensively as
possible. Not a single technique that meets all of our needs. The OOSP process pattern,
indicating that it is comprised of four serial phases: Initiate Construct, Deliver, and Maintain and
Support. Each phase are iteratively performed stages. The OOSP is serial in the large and
iterative in the small, delivering incremental releases over time. OOSP easily supports the
delivery of incremental releases of an application as well as parallel development activities.

The OOSP is fundamentally serial in nature

You must first get the project started by;
 Identifying the initial requirements.
 Justifying that the project is viable.
 Determining the tools and techniques that you will use to deliver your application.
Once these tasks are more or less complete, you actually begin to build the application by
developing:-
 Models,
 Writing code,
 Generalizing your work, and
 Testing it in units
Once construction is complete, you will freeze your code so you can test the entire application
and release it to your users. Once the application is released, you maintain and support the
application.
The OOSP is serial in the large, and is comprised of four serial project phases:
Initiate : Definition and validation of the initial requirements and management documents

The project justification - produces a feasibility study

The definition of the project infrastructure
 describe the tools that the project team will use
 how they will use them
 the standards that the team will follow
 how their work will be evaluated
 the deliverables that they must produce during the project

30
Construct:

 Modeling the application via OO techniques such as Class, Responsibilities, and

Collaborators (CRC) modeling/card, use cases, class diagrams, sequence
diagrams, etc.
 Build the application in such a way that it is easy to maintain and to enhance
 Testing in the small, and generalization are all occurring iteratively
Deliver: High-quality, well documented application in the hands of your users. Perform testing in
the large on the application by using techniques. such as :

 system testing
 installation testing
 stress testing
 user acceptance testing
Release the application by making it available to users including user training
Maintain and Support:

 Keep the application running and as up-to-date as possible

 Providing training, answering their questions, and by fixing any problems that
they may encounter
 Identify Defects and Enhancements
 defines and prioritizes new requirements for future releases
Software process is a set of project phases, stages, methods, techniques, and practices that people
employ to develop and maintain software and its associated artifacts. It enables organizations to
increase productivity when developing software. Any modern object-oriented approach to
develop software process must have objectives, a focus of activity over the workflows, and
incremental deliverables. Each of the phases is described as follows:
Inception

In this phase, a business case is made for the proposed system. This includes feasibility analysis
that should answer questions such as the following:

 Do we have the technical capability to build it?

 If we build it, will it provide business value?
 If we build it, will it be used by the organization
 To answer these questions, the development team performs work related primarily to the
business modeling, requirements, and analysis workflows. This implies that the design,
implementation, and test workflows also could be involved. The primary deliverables
from the inception phase are:
 A vision document that sets the scope of the project, identifies the primary requirements
and constraints, sets up an initial project plan, and describes the feasibility and risks
associated with the project
 The adoption of the necessary environment to develop the system

31
Elaboration

The analysis and design workflows are the primary focus during this phase. This phase continues
with developing the vision document, including finalizing the business case, revising the risk
assessment, and completing a project plan in sufficient detail to allow the stakeholders to be able
to agree with constructing the actual final system. It deals with gathering the requirements,
building the UML structural and behavioral models of the problem domain, and detailing the
how the problem domain models fit into the evolving system architecture. The primary
deliverables of this phase include:

 The UML structure and behavior diagrams

 An executable of a baseline version of the evolving information system

Construction

The construction phase, as expected by its name, is heavily focused on programming the
evolving information system. As such, it is primarily concerned with the implementation
workflow. However, the requirements, analysis, and design workflows also are involved with
this phase. It is during this phase that missing requirements are uncovered, and the analysis and
design models are finally completed. At times, an iteration may have to be rolled back. The
primary deliverable of this phase is an implementation of the system that can be released for beta
and acceptance testing.

Transition

Like the construction phase, the transition phase addresses aspects typically associated with the
implementation phase of SDLC approach. Its primary focus is on the testing and deployment
workflows. Depending on the results from the testing workflow, it is possible that some redesign
and programming activities on the design and implementation workflows could be necessary, but
they should be minimal at this point in time. From a managerial perspective, the project
management, configuration and change management, and environment are involved. The other
deliverables include user manuals, a plan to support the users, and a plan for upgrading the
information system in the future.

32
 Chapter 3: Understanding the Basics Object oriented concepts
3.1. OO concepts from structured point of view
Object Oriented (OO) paradigm is the development strategy based on the concept that systems should be
built from a collection of reusable components called objects. Instead of separating data and functionality,
as is done in the structured paradigm.

The structured paradigm says system should be separated into two parts:

 data (modeled using a data/persistence model)

 functionality (modeled using a process model)

In short, using the structured approach, you develop applications in which data is separate from behavior
in both the design model and in the system implementation (program)

The object-oriented paradigm is that instead of defining systems as two separate parts (data and
functionality), you now define systems as a collection of interacting objects. Objects do things (that is,
they have functionality) and they know things (they have data). Consider the design of an information
system for a university. Taking the structured approach:

In the database would be information about students, instructors, rooms, and courses. The program would
enable users to enroll students in courses, assign instructors to teach courses, schedule courses in certain
rooms, and so on.

Now consider the university information system from an object oriented perspective.

In the real world, there are students, instructors, rooms, and courses.

All of these things would be considered objects. In the real world, students know things .they have
Names, addresses, birth dates, telephone numbers, and so on. They do things such as :-

 enroll in courses, drop courses and pay tuition or cost-sharing

 Instructors also know things such as:- the courses they teach and their names , they do things
such as :-input marks and make schedule requests
 From a systems perspective, rooms know things. Such as :- the building they‘re in and their room
number. Should be able to do things. Such as:- tell you when they are available and enable you to
reserve them for a certain period of time.
 Courses also know things such as: - Their title, description and who is taking the course and
should be able to do things. Such as letting students enroll in them or drop them.

To implement this system, we would define a collection of classes. a class is a generic representation of
similar objects that interact with each other. For example, we would have ―Course,‖ ―Student,‖
―Instructor,‖ and ―Room‖ classes. The collection of these classes would make up our application, which
would include both the functionality (the program) and the data.

33
Four basic OO concepts structured terminology

1. Attribute
 Equivalent to a data element in a record
 From a programming point of view, it also makes sense to think of an attribute as a local variable
applicable only to a single object.
2. Method
 A method can be thought of as either a function or procedure
 Methods access and modify the attributes of an object
 Some methods return a value (like a function), whereas other methods cause side effects, like
printing (display) and persisting (save) data.
3. Object
 Data and operations are defined as a single unit
 Object :=
 encapsulated state (attributes)
 methods that exclusively control access to the state
4. Class
 Each object is an instance of a class
 A class serves as a blueprint(a design plan)
 It defines the attributes and methods for the object
 Thus, each object of a class has exactly the same interface and set of attributes
 each object can have different values for its attributes

3.2. Abstraction, Encapsulation and information hiding

Instead of saying we determined what a class knows and does, we say we "abstracted" the class Instead of
saying we designed how the class will accomplish these things, we say we "encapsulated" them Instead of
saying we designed the class well by restricting access to its attributes, we say we have "hidden" the
information.

Abstraction

The world is a complicated place. To deal with that complexity we form abstractions of the things in it.
For example, consider the abstraction of a person. From the point of view of a university, it needs to
know the person‗s name, address, telephone number, social security number, and educational background.
From the point of view of the police, they need to know a person‗s name, address, phone number, weight,
height, hair color, eye color, and so on. It is still the same person, just a different abstraction, depending
on the application at hand. Abstraction is an analysis issue that deals with what a class knows or does.
Your abstraction should include the responsibilities, the attributes, and the methods of interest to your
application—and ignore the rest. That is why the abstraction of a student would include the person‗s
name and address, but probably not his or her height and weight. OO systems abstract only what they
need to solve the problem at hand. People often say abstraction is the act of painting a clear box around
something: you are identifying what it does and does not do. Some people will also say that abstraction is
the act of defining the interface to something. Either way, you are defining what the class knows and
does.

34
Encapsulation

Although the act of abstraction tells us that we need to store a student‗s name and address, as well as be
able to enroll students in seminars, it does not tell us how we are going to do this. Encapsulation deals
with the issue of how you intend to modularize the features of a system. In the object-oriented world, you
modularize systems into classes, which, in turn, are modularized into methods and attributes. We say that
we encapsulate behavior into a class or we encapsulate functionality into a method.

Encapsulation: is a design issue that deals with how functionality is compartmentalized within a
system. You should not have to know how something is implemented to be able to use it. The implication
of encapsulation is that you can build anything anyway you want, and then you can later change the
implementation and it will not affect other components within the system (as long as the interface to that
component did not change). People often say encapsulation is the act of painting the box black: you are
defining how something is going to be done, but you are not telling the rest of the world how you are
going to do it. In other words you are hiding the details of the implementation of an item from the users of
that item. For example, consider your bank. How does it keep track of your account information, on a
mainframe, a mini, or a PC? What database does it use? What operating system? It does not matter,
because it has encapsulated the way in which it performs account services. You just walk up to a teller
and initiate whatever transactions you want. By hiding the details of the way it has implemented accounts,
your bank is free to change that implementation at any time, and it should not affect the way services are
provided to you.

Information Hiding

To make your applications maintainable, you want to restrict access to data attributes and some method.
The basic idea is this: if one class wants information about another class, it should have to ask for it,
instead of taking it. If you want to learn somebody's name, what would you do? Would you ask the person
for his name, or would you steal his wallet and look at his ID? By restricting access to attributes, you
prevent other programmers from writing highly coupled code. When code is highly coupled, a change in
one part of the code forces you to make a change in another, and then another, and so on.

3.3. Inheritance
Similarities often exist between different classes. Two or more classes often share the same attributes
and/or the same methods. Because you do not want to have to write the same code repeatedly, you want a
mechanism that takes advantage of these similarities. Inheritance is that mechanism. Inheritance models
―is a‖, ―is kind of‖, and ―is like‖ relationships, enabling you to reuse existing data and code easily. For
example, students have names, addresses, and telephone numbers, and they drive vehicles. At the same
time, professors also have names, addresses, and telephone numbers, and they drive vehicles. Without a
doubt, you could develop the classes for student and professor and get them both running. In fact, you
could even develop the class Student first and, once it is running, make a copy of it, call it Professor, and
make the necessary modifications. While this is straightforward to do, it is not perfect. What if there was
an error in the original code for student? Now you must fix the error in two places, which is twice the
work. What would happen if you needed to change the way you handled names (say, you go from a
length of 30 to a length of 40)? Now you would have to make the same change in two places again, which

35
is a lot of dull, boring, tedious work (and costly). Would it not be nice if you had only one copy of the
code to develop and maintain? This is exactly what inheritance is all about.

With inheritance, you define a new class that encapsulates the similarities between students and
professors. This new class would have the attributes name, address, and phoneNumber, and the method
driveVehicle. Because you need to name all our classes, you need to ask yourself what this collection of
data and functionality describes. In this case, the name Person is fitting. Once you have the class Person
defined, you then make Student and Professor inherit from it. You would say Person is the superclass of
both Student and Professor, and Student and Professor are the subclasses of Person. Everything that a
superclass knows or does, the subclass knows or does free without writing extra code. Actually, for this
example, you would need to write two lines of code, one saying Student is a subclass of Person, and
another saying Professor is a subclass of Person; therefore, it is almost free. Because Person has a name,
address, and telephone number, both Student and Professor also have those attributes. Because Person has
the ability to drive a vehicle, so do the classes Student and Professor.

Modeling Inheritance

The following figure depicts the modeling notation for inheritance, a line with a closed arrowhead. The
way you would read the diagram is ―B inherits from A.‖ In other words, B is a direct subclass of A and
A is the direct superclass of B.

The below figure presents how you would model the Person inheritance class hierarchy, often simply
called a class hierarchy. Notice how the name of the Person class is in italics, indicating it is abstract,
whereas Professor and Student are concrete classes. Abstract and concrete classes are discussed in the
following Section.

36
Single and Multiple Inheritance

When a class inherits from only one other class, we call this single inheritance. When a class inherits from
two or more other classes, we call this multiple inheritance. Remember this: the subclass inherits all the
attributes and methods of its superclass(es). Not all languages support multiple inheritance. C++ is one of
the few languages that does, whereas languages such as Java, Smalltalk, and C# do not. The point to be
made is if your target implementation language does not support multiple inheritance, then you should not
use it when you are modeling.

In the below figure, you see several similarities between airplanes and cars. They both have a number of
passengers, a maximum fuel level, and they can either increase or decrease their speed. To take advantage
of these similarities, you could create a new class called Vehicle and have Airplane and Car inherit from
it. We say the classes Vehicle, Airplane, and Car form an inheritance hierarchy, also called a class
hierarchy. The topmost class in a class hierarchy (in this case Vehicle) is called the root or root class.
Notice how there is the method Turn for Car and Bank for Airplane. Turning and banking are exactly the
same thing. You could have defined a Turn method in Vehicle, and had Airplane and Car inherit it (then
you would remove Bank and Turn from the subclasses). This would imply that you would require users of
airplanes (probably pilots) to change the terminology they use to work with airplanes. Realistically, this
would not work. A better solution would be to define Turn in Vehicle and have the method Bank invokes
it as needed.

In the following diagram, the class Vehicle is marked as abstract (the name is in italics; in previous
versions of the UML you could also indicate with the constraint {abstract}), whereas Airplane and Car
are not. We say Vehicle is an abstract class, whereas Airplane and Car are both concrete classes. The
main difference between abstract classes and concrete classes is that objects are instantiated (created)
from concrete classes, but not from abstract classes. For example, in your problem domain, you have
airplanes and cars, but you do not have anything that is just a vehicle (if something is not an airplane or a
car, you are not interested in it). This means your software will instantiate airplane and car objects, but
will never create vehicle objects. Abstract classes are modeled when you need to create a class that
implements common features from two or more classes.

37
In the above picture you might want to create a new class called Dragon. You already have the classes
Bird and Lizard. A dragon is like a bird because they both fly. A dragon is also like a lizard because they
both have claws and scales. Because dragons have the features of both birds and lizards, in the after
picture we have the class Dragon inheriting from both Bird and Lizard. This is an example of an ‗is like‘
relationship: a dragon is like a bird and a dragon is (also) like a lizard.

3.4. Association
Relationships

In the real world, objects have relationships with other objects. The relationships between objects are
important because they help us to define how they interact with each other.

38
For example, students take courses, professors teach courses, and criminals rob banks e.t.c. Take, teach
and rob are all verbs that define associations between objects. An association is a persistent relationship
between two or more classes or objects.

Association: refers to the relationship between multiple objects. It refers to how objects are related to
each other and how they are using each other's functionality. Composition and aggregation are two types
of association.

The common items to model for an association

1. Directionality
 The open arrowheads indicate the directionality of the association
 When there is one arrowhead the association is unidirectional
 When there is either zero or two arrowheads the association is bi-directional: it can be traversed
in both directions
2. Label
 The label, which is optional, is typically one or two words describing the association
 Reading one class, the label, and then the other class should produce a sentence fragment that
describes the relationship, e.g., Professor teaches Seminars
3. Multiplicity
The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for
each direction
Models a semantic connection among classes

39
3.5. Aggregation
Aggregation: is a weak association. An association is said to be aggregation if both Objects can exist
independently. For example, a Team object and a Player object. The team contains multiple players but a
player can exist without a team.

Aggregation and Composition

 Sometimes an object is made up of other objects

 For example, an airplane is made up of a wings, engines, landing gear and so on.
 A project team consists of two or more employees
 These are all examples of the concept of aggregation, which represents "is part of" relationships.
 An engine is part of a plane and an employee is part of a team.

Composition : is a strong form of aggregation in which the "whole" is completely responsible for its parts
and each "part" object is only associated to the one whole object. For example, at any given time, an
engine is part of one and only one airplane. Furthermore, no object other than the airplane will directly
collaborate with an engine object; for example, passenger objects on the airplane cannot directly request
that an engine increase its speed.

Aggregation is simply a type of association; therefore, you still need to model the multiplicity and roles,
just as you would with associations.

40
The aggregation/composition associations represented in previous figure are read in a similar manner

 An item is part of one and only one shipment;

 A shipment is composed of one or more items;
 An engine is part of one and only one airplane;
 An airplane has one or more engines;
 An employee may be part of one or more teams;
 A team is made up of one or more employees;
 Any given team may be part of a larger team; and
 A team may be made up of smaller sub teams

Tips and techniques should help us to model composition effectively

1. Apply the sentence rule

 The first test is that it should make sense to say "the part is part of the whole. ―. For example, it
makes sense to say an engine is part of an airplane.
 However, it does not make sense to say an employee is part of a position or a position is part of
an employee.
 If the sentence does not make sense, then composition is most likely not appropriate.
2. The whole should manage the part
 The second test, assuming the sentence rule passes, is whether the whole manages the part.
 For example, an airplane should manage its engines; you would not want a passenger on the plane
to be able to manipulate the engines.
3. You should be interested in the part
 An object may actually be a part in the real world, but if you are not interested in keeping track of
it, then do not model it .For example, an airplane maintenance system would be interested in
keeping track of engines because it needs to record maintenance information about each engine.
 On the other hand, an air-traffic control system is not interested in tracking engines, just
airplanes. Therefore, an engine would not appear as a class in an air-traffic control system.

41
4. Show multiplicity and roles
 Just as you show the multiplicity and roles for an association, you need to do the same for a
composition association.
5. Composition is inherited
 Composition associations, like ordinary associations, are maintained by a combination of
attributes and methods that can be inherited.

3.6. Collaboration
 Classes often need to work together to fulfill their responsibilities
 Actually, it is typically the objects and the instances of the classes that are working together
 Collaboration occurs between objects when one object asks another for information or to do
something.

A UML communication diagram showing messaging

Tips and techniques should help us to model collaborations effectively

1. There must be some sort of relationship

 There must be an association, or an aggregation association, between the two classes for their
instances (objects) to be able to collaborate.
2. There must be a corresponding method in the target object
 Collaborations are implemented as method invocations, implying the method must exist in the
target for it to be invoked.
3. There might be a return value
 If the collaboration is a request for information, then there must be a return value (the requested
information)
4. There may or may not be parameters
 Some messages have parameters and some do not.
5. Each method should do something

42
  It is important that each object being collaborated with should always do something not just
forward the message to another object, something called a pass through.
6. An object can collaborate with itself
 Objects will often send themselves messages to obtain information and/or to have itself get
something done

3.7. Persistence
Persistence focuses on the issue of how to make objects available for future use of your software. In other
words, how to save objects to permanent storage. To make an object persistent, you must save the values
of its attributes to permanent storage as well as any information needed to maintain the relationships
(aggregation, inheritance, and association) with which it is involved. In addition to saving objects,
persistence is also concerned with their retrieval and deletion.

From a development point of view, there are two types of objects: persistent and transient objects. For
example, a Customer is a persistent class. You want to save customer objects into some sort of permanent
storage so you can work with them again in the future. A customer editing screen, however, is a transient
object. Your application creates the customer-editing screen object, displays it, and then gets rid of it once
the user is done editing the data for the customer with whom he or she is currently dealing.

Tips and techniques should help us to understand and apply persistence concepts better

1. Business/domain classes are usually persistent

 You are naturally going to need to keep a permanent (persistent) record of the instances of real-
world classes like Student, Instructor, and Course
2. User-interface classes are usually transitory
 User-interface classes (screens and reports) are usually transitory
3. You need to store both attributes and associations
 When an object is written to disk, you obviously need to store the value of its attributes.
However, you must also store information about any relationships/associations with which the
object is involved.

3.8. Coupling
Definition

The degree of dependence such as the amount of interactions among components

Coupling is a measure of how two items, such as classes or methods, are interrelated. When one class
depends on another class, we say they are coupled. When one class interacts with another class, but does
not know any of the implementation details of the other class, we say they are loosely coupled. When one
class relies on the implementation that is, it directly accesses the data attributes of the other, we say they
are tightly coupled.

The basic problem is when two classes are tightly coupled; a change in one often requires a change in the
other. This, in turn, could require a change in another class, and then another, and then another, and so on.
Tight coupling is one of the main reasons such a large maintenance burden exists.

43
No dependencies loosely coupled Highly coupled

3.9. Cohesion
Definition

 The degree to which all elements of a component are directed towards a single task.
 The degree to which all elements directed towards a task are contained in a single component.
 The degree to which all responsibilities of a single class are related.
 Internal glue with which component is constructed
 All elements of component are directed toward and essential for performing the same task.

Cohesion is a measure of how much an item, such as a class or method, makes sense. A method is highly
cohesive if it does one thing and one thing only. For example, in the class Student you would have
methods to enroll a student in a seminar and to drop a student from a seminar. Both of these methods do
one thing and one thing only. You could write one method to do both these functions, perhaps called
changeSeminarStatus. The problem with this solution is the code for this method would be more complex
than the code for the separate enrollInSeminar or dropSeminar methods.

Type of Cohesion

1. Functional
 Every essential element to a single computation is contained in the component.
 Every element in the component is essential to the computation.
 Ideal situation
 What is a functionally cohesive component?
 One that not only performs the task for which it was designed but it performs only that function
and nothing else.
2. Sequential
 The output of one part is the input to another.
 Data flows between parts (different from procedural cohesion)
 Occurs naturally in functional programming languages
 Good situation
3. Communicational
 Functions performed on the same data or to produce the same data.
4. Procedural
 Elements of a component are related only to ensure a particular order of execution.
 Actions are still weakly connected and unlikely to be reusable.
5. Temporal
 Elements are related by timing involved

44
  Elements are grouped by when they are processed.
6. Logical
 Elements of component are related logically and not functionally.
 Several logically related elements are in the same component and one of the elements is selected
by the client component.
7. Coincidental
 Parts of the component are unrelated (unrelated functions, processes, or data)
 Parts of the component are only related by their location in source code.
 Elements needed to achieve some functionality are scattered throughout the system.
 Accidental
 Worst form

3.10. Polymorphism
An individual object may be one of several types. For example, a ‗Dawit Alemayehu‘ object may be a
student, a registrar, or even a professor. The concept of polymorphism says we can treat instances of
various classes the same way within our system.

Example of polymorphism by exploring the design of how the university handles the hiring of new staff,
shown in next Figure.

If the hire method has been implemented in the Employee class, it would implement the behavior needed
to add the person into the university pension plan and print an employee card for them. The hire method
has been overridden in the Professor class. It would invoke the hire method in the Employee class because
that behavior is still applicable for professors, plus it would add the functionality needed to reserve a
parking space

3.11. Interfaces
An interface is the definition of a collection of one or more methods, and zero or more attributes.
Interfaces ideally define a cohesive set of behaviors. Interfaces are implemented by classes and
components. To implement an interface, a class or component must include the methods defined by the
interface. For example, the below figure indicates the class Student implements the Serializable interface

45
and the Searchable interface. To implement the Searchable interface, Student must include a method
called find, which takes criteria as a parameter.

Interfaces are a powerful method for ensuring loose coupling. They allow a class to participate in a
common set of functionality without another class having to know anything about it except that it
supports that interface. A GUI object, for example, could present a list of students that meet a set of
criteria without knowing anything about the Student class except that it implements the Searchable
interface and the name of a single method to get a presentation name, which could perhaps be part of a
Description interface. That same GUI could perform the exact same action with professors if the
Professor class also implemented those two interfaces. If the Seminar class implemented those interfaces,
the GUI could display them, too, and anything else that implemented those interfaces. The GUI knows
nothing about these classes except that they implement two interfaces; this promotes loose coupling
between the GUI and those classes.

3.12. Components
 Components are deployable entities. That is, they are not compiled into an application program but
are installed directly on an execution platform. The methods and attributes defined in their interfaces
can then be accessed by other components.
 Components do not define types. A class definition defines an abstract data type and objects are
instances of that type. A component is an instance, not a template that is used to define an instance.
 Component implementations are opaque. Components are, in principle at least, completely defined by
their interface specification. The implementation is hidden from component users. Components are
often delivered as binary units so the buyer of the component does not have access to the
implementation.
 Components are language-independent. Object classes have to follow the rules of a particular object-
oriented programming language and, generally, can only interoperate with other classes in that
language. Although components are usually implemented using object-oriented languages, such as
Java or C#, you can implement them in non-object-oriented programming languages.
 Components are standardized unlike object classes that you can implement in any way; components
must conform to some component model that constrains their implementation.

3.13. Patterns
Doesn‘t it always seems as if you are solving the same problems repeatedly? If you personally have not
solved a given problem before, then chances are pretty good you could find somebody who had tackled

46
the same or, at least, a similar problem in the past. Sometimes the problem you are working on is simple,
sometimes it is complex, but usually it has been worked on before. Wouldn‘t it be nice to be able to find a
solution easily, or at least a partial solution, to your problem? Think how much time and effort could be
saved if you had access to a library of solutions to common system development problems. This is
what patterns are all about. A pattern is a solution to a common problem taking relevant forces into
account, effectively supporting the reuse of proven techniques and approaches of other developers.
Several flavors of patterns exist, including analysis patterns, design patterns, and process patterns.
Analysis patterns describe a solution to common problems found in the analysis/business domain of an
application, design patterns describe a solution to common problems found in the design of systems, and
process patterns address software process related issues. Analysis patterns, design patterns and process
patterns are discussed in the coming chapters.

UML Diagram

Although there is far more to modeling than just the UML, as you will see throughout this module, the
reality is that the UML defines the standard modeling artifacts when it comes to object technology. There
are three classifications of UML diagrams:

 Behavior diagrams. This is a type of diagram that depicts behavioral features of a system or
business process. This includes activity, state machine, and use case diagrams as well as the
interaction diagrams. Interaction diagrams. This is a subset of behavior diagrams that emphasize
object interactions. This includes collaboration, sequence diagrams.
 Structure diagrams. This is a type of diagram that depicts the static elements of a specification
that are irrespective of time. This includes class, component, deployment, and package diagrams.

47
 Chapter 4: Gathering user requirements
Requirements identify the objective of a product. It is features of system or system function used to fulfill
system purpose. It focuses on customer‗s needs and problem, not on solutions. Before anything is done to
develop a product, we must identify what the system must do. Therefore, understanding what
requirements are, what they are not, and how best to identify them is crucial to the success of the system.
Development of a system must follow a set of practices, procedures, rules, and techniques called
methodology. A requirement gathering is also called requirements elicitation. It is a process of collecting
the user needs to solve a problem or issues and to achieve an objective. If the requirement gathering is not
done properly/ completely, all the subsequent phase is incomplete, no matter how best the design, until
and unless requirements are complete. So, we should carefully plan and carry out the requirements
gathering with a systematic approach. Gathering user requirements is the first step in software
development.

Requirement Types (Functional and Non-Functional)

1. Functional Requirements: It specifies the software functionality that the developers must build into
the product to enable users to accomplish their tasks, thereby satisfying the business requirements. It
is a state what the system must do. In fact, it is usually stated by using the ―shall‖ statement.
 A process the system has to perform.
 Information the system must contain.

Example: The website shall notify the administrator via email when a user register with it.

2. Non-Functional: describe aspects of the system that are not directly related to the functional
behavior of the system. Nonfunctional requirements include a broad variety of requirements that
apply to many different aspects of the system, from usability to performance.
 Refer to behavioral properties that the system must have,
 Such as performance and usability
 Are primarily used in the design phase when decisions are made about

Nonfunctional requirements include a broad variety of requirements that apply to many different aspects
of the system, from usability to performance. These requirements are discussed below:

 Usability: is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs
of a system or component. Usability requirements include, for example, conventions adopted by the
user interface, the scope of online help, and the level of user documentation. Often, clients address
usability issues by requiring the developer to follow user interface guidelines on color schemes,
logos, and fonts.
 Reliability: is the ability of a system or component to perform its required functions under stated
conditions for a specified period of time. Reliability requirements include, for example, an acceptable
mean time to failure and the ability to detect specified faults or to withstand specified security attacks.
 Robustness: the degree to which a system or component can function correctly in the presence of
invalid inputs or stressful environment conditions.
 Safety: a measure of the absence of catastrophic consequences to the system.
 Performance: requirements are concerned with quantifiable attributes of the system, such as response
time (how quickly the system reacts to a user input).

48
 Supportability: requirements are concerned with the ease of changes to the system after deployment,
including for example, adaptability (the ability to change the system to deal with additional
application domain concepts), maintainability (the ability to change the system to deal with new
technology or to fix defects), and internationalization (the ability to change the system to deal with
additional international conventions, such as languages, units, and number formats).
 Portability: (the ease with which a system or component can be transferred from one hardware or
software environment to another)

4.1. Putting together requirements gathering team

1. Choosing Good Subject Matter Experts
 A subject matter expert (SME) provides the knowledge and expertise in a specific subject for a
project
 An SME has proficiency (a high degree of skill; expertise) in his or her subject and guides other
professionals on the project to ensure the content is accurate.
 The proficiency generally comes from education and experience.
 SMEs come from academic, technical, and vocational fields.
 They may work on different types of projects and have slightly different duties, but their role is
essentially to ensure the facts and technical details are correct.
2. Choosing Good Facilitators
 Facilitator/Session Leader: Chairs the meeting and directs traffic by keeping the group on the
meeting agenda.
 The facilitator is responsible for identifying those issues that can be solved as part of the meeting
and those which need to be assigned at the end of the meeting for follow-up investigation and
resolution
3. Choosing Good Scribes
 Scribe/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and
they does not contribute information to the meeting.

4.2. Fundamental requirements gathering techniques

Primary information gathering techniques

This chapter covers twelve effective requirements gathering techniques. They will be presented roughly
in the order in which they normally appear in the requirements gathering process. It is not necessary to
use all of them for every project, but a healthy mix of these techniques, chosen based on the needs of your
specific project, will likely improve your requirements coverage and help you reduce requirements-
related problems during software.

A. Interviews
B. Questionnaires or Surveys
C. User Observation
D. Document Analysis
E. Interface Analysis
F. Workshops
G. Brainstorming
H. Role-Play
I. Use Cases and Scenarios

49
 J. Focus Groups
K. Prototyping
L. Conduct JAD sessions

A. Interviewing
 When interviewing someone you have several potential goals to accomplish:
 Broaden your understanding of the business domain;
 Determine whom to invite to become active stakeholders; and
 Identify new or existing requirements directly for the application
 Effective way to understand business functions and rules
 Time-consuming and resource-expensive.
 May require multiple sessions to:
 Meet all users
 Understand all processing requirements
 Can meet with individuals or groups of users
 List of detailed questions prepared.
1. Sample Checklist to Prepare for User Interviews

2. Selecting Interviewees
List all of the people who will be interviewed.
 People at different levels of the organization will have different perspectives on the system
 Include both manager and staff who actually perform the process
3. Designing Interview Questions

Closed-ended

 Enable analyst to control the interview and obtain information they need

50
  Don‘t uncover ―why‖

Open-ended

 Leave room for elaboration on the part of the interviewee

 Design to gather rich information
 Give the interviewee more control over the information that is revealed during the interview
4. Probing(Study well) question
 Follow up on what has just been discussed in order to learn more
 Use when the interviewer is unclear about an interviewee‘s answer
 Encourage the interviewee to expand on or to confirm information from a previous response.
 Should not ask questions about information that is available from other sources (documents,
reports, forms).\
5. Organizing the Interview Questions

Top-down interview

 The interviewer starts with broad, general issues and gradually work towards more specific ones

Bottom-up interview

 The interviewer starts with very specific questions and move to broad questions
6. Conducting the Interview
 Build rapport (being friendly) with the interviewee, so that he/she trusts and willing to tell the
whole truth.
 Should appear to be professional and an unbiased, independent seeker of information
 Should start with an explanation of why you are there and why you have chosen to interview the
person, then move into your planned interview question
 Record all the information that the interviewee provides take notes
 Don‘t afraid to ask the person to slow down or to pause while you write, because this is a clear
indication that the interviewee‘s information is important to you
 Look for exception and error conditions.
 Probe (examine) for details.
 Close the interviewee
7. Post-Interview
 Prepare an interview report

8. Follow up
 To explain and verify information

51
  List new questions based on areas that need further elaboration or that are missing information
 This list will prepare you for the next interview.
B. Questionnaires or Surveys

Individual interviews present several challenges. They can be tricky to schedule and time-consuming for
the interviewers. Plus, the requirements you gather may only scratch the surface; not every interviewer is
skilled at asking follow-up questions in real time. Questionnaires (or surveys) can provide an efficient
alternative. They allow follow-up with multiple stakeholders at the same time. A well-thought-out
questionnaire—one that asks probing questions—is a good tool for getting at those underlying
requirements of which stakeholders may not be fully conscious, but which are essential to a successful
design.

A set of written questions, often sent to a large number of people

 Mostly closed-ended questions

 May be paper-based or electronic
 Select participants using samples of the population
 Design the questions for clarity and ease of analysis
 Administer the questionnaire and take steps to get a good response rate
 Questionnaire follow-up report

Administering Questionnaires

 Choosing respondents
 Should be representative of all users
 Use samples like
 Random sample
 Purposeful sample
 Stratified sample

Good Questionnaire Design

 Begin with non-threatening and interesting questions

 Group items into logically coherent sections
 Do not put important items at the very end of the questionnaire
 Do not crowd a page with too many items
• Avoid abbreviations
• Avoid biased or suggestive items or terms
• Number questions to avoid confusion
• Pretest the questionnaire to identify confusing questions
C. User Observation

One of the problems with interviewing people is they leave out important details, details that you may not
know to ask about because they know their jobs so well. Another advantage of observing your users is
you see the tools they use to do their jobs Perhaps they use a key reference manual or use a notepad to
write reminder notes for themselves and/or their co-workers Often they do things differently than the
official manual tells you it should be done. Taking the time to observe users doing their work can give.
Your insight into the requirements for the application you are building.

52
  One of the best ways to understand what users truly need is to observe them performing their
daily tasks.
 User observation can be either passive or active.
 Active observation—asking questions of users while observing them—is the best approach for
gaining an understanding of an existing process.
 Passive observation is more effective when gathering user feedback on a design prototype (see
technique #11).

When observing users, record the actions and activities that take place. What already works well? What
causes users difficulty? Note the obstacles users must routinely overcome. By observing end users in the
real context in which they perform their tasks, you‘ll gain a true understanding of what they are up against
and what improvements they need so they can perform better. You‘ll then be better able to specify a
system that successfully reinvents users‘ processes and grants them far greater productivity and usability.

A. Document Analysis

Frequently overlooked, document analysis is another highly effective technique for gathering
requirements. Reviewing the documentation of the current system you‘re seeking to replace can help you
in performing AS-IS process analysis and gap analysis. The former helps you see where you can improve
the user‘s process. The latter will aid you in determining where the business needs revealed earlier—
through your interviews, questionnaires, and user observation—are not being met.

Naturally, you‘ll want to analyze the system‘s requirements documents, if available, but you should also
look at other system-level documentation, such as users‘ manuals and problem reports. Nuggets (a
valuable idea or fact) of information on why the existing system works as it does are often considered
within the specifications and design documentation. The insights gained from document analysis can help
you formulate further questions and evaluate the completeness of your requirement set.

D. Interface Analysis

Analyzing a system‘s interfaces, both human and machine, is vitally important to ensure requirements are
complete and the system will be usable. Interfaces for a software product will include those with:

 End users
 System components the software interacts with (e.g., sensors or other peripherals)
 External systems the software interacts with
 Thorough interface analysis—really understanding the interactive context of the system will
frequently uncover requirements not readily visible to users.
E. Workshops

When gathering requirements from a broad spectrum of stakeholders, it‘s only natural that you‘ll get
conflicting opinions. You will need to resolve these issues, however, before implementation begins.
Requirements workshops are a good method for resolving such conflicts. Once you have a broad set of
candidate requirements defined and organized, convene your stakeholders and hash through these
candidates together. Gather additional detail. Give a fair hearing to opposing views. Grant everyone
ample (large and accommodating.) opportunity to provide the rationale for their positions. Seek to resolve
discrepancies (difference) and conflicts, gain consensus, and validate your requirements. These activities

53
are vital to ensuring your system will best meet the needs of all users and stakeholders, not just the most
vocal groups.

F. Brainstorming

Brainstorming is a technique where groups of people discuss a topic and say anything that comes into
their minds about it

The rules are simple; all ideas are:

 Good ideas are not judged by the group;

 Owned by the group, not by the individual; and
 Immediately public property: anybody is allowed to expand upon them

The facilitator starts by explaining the rules of brainstorming and explaining what issues are to be
discussed. A good idea is to give everyone a copy of the brainstorming rules before a brainstorming
session so they are aware of them. When someone suggests an idea, it should be immediately recorded
onto a publicly visible area, such as a flip chart paper or a white board. Brainstorming can be performed
as part of a workshop which follows or on its own, in either large or small groups. In your brainstorming
session, consider different parts of the system individually. Explore various what-if scenarios and blue-
sky ideas (creative ideas that are not limited by current thinking or belief). The general idea is to break
away from existing conventions. Consider visionary ideas for pushing current boundaries. Useful tools for
brainstorming sessions include whiteboards, mind mapping software (create a diagram or flowchart of
your ideas), and empathy maps (the latter for exploring user needs).

G. Role-Play

Some systems—certain kinds of enterprise software, like ERP, for example: must meet the needs of a
variety of user types. Role-play can help to ensure that the needs of all users are being met. Enterprise
resource planning (ERP) refers to a type of software that organizations use to manage day-to-day business
activities such as accounting, procurement, project management, risk management and compliance, and
supply chain operations.

In a role-play session, different people take the roles of the different user types. Having the various roles
interact with one another helps examine individual system requirements from different perspectives and
generates discussions and new ideas. In effect, role-play is an additional brainstorming technique. It is a
good way to gain a solid understanding of how the various parts of the system need to function to support
the overall process.

H. Use Cases and Scenarios

Once you have high-level functional requirements in place, it is a good idea to explore a variety of use
cases and scenarios. Use cases are the specific, individual business objectives the system must accomplish
and the various situations in which a given feature or functionality will be used. They describe the
various external entities that act on the system and the specific interactions they have with the system to
accomplish the business objective. Use cases are expressed as step-by-step lists of tasks performed during
a process. Scenarios, also called user stories, are similar to use cases in that they describe how the system
will carry out a process to fulfill a business objective. Their form, however, is a narrative, rather than an

54
enumerated list. They are essentially short stories with the user in the role of the protagonist (the leading
character).

Scenarios describe:

 Tasks users perform

 Information users see
 How users interact with the system
 Use cases and scenarios can be used to validate the features and functional requirements of the
system across a wide range of situations.
 They can also help you discover exceptions and boundary cases that need consideration.
I. Focus Groups
 A focus group (or user group) is a gathering of customers or user representatives who meet with you
to
 Provide feedback on your product
 Express their needs
 Help guide your software development
 Focus groups can be convened to either:
 Gather information for the development of requirements, or
 Gain feedback aimed at validated previously elicited requirements

Focus groups are different from brainstorming. Brainstorming is a managed process that generally
involves internal stakeholders. Focus groups typically involve external stakeholders. Many systems
engineers and business analysts are skeptical of using focus groups to gather requirements. Meetings can
be dominated by vocal individuals with narrow agendas. Strong disagreements on needs and features can
make these meetings unproductive. Focus groups can, however, be extremely useful in certain situations.
One of these is the evaluation of design prototypes (see technique #K) to help validate and finalize
requirements.

J. Prototyping
Often, end users and other stakeholders don‘t have a clear idea of what they truly want. In most cases,
they don‘t have a good grasp of what‘s possible. If you can give them something to try, however, they
can usually tell you what they like and don‘t like about it. That‘s where prototyping comes in.
Prototyping gives users a chance to try out ideas on what their next solution could look like. Today‘s
rapid prototyping tools allow developers to quickly put together any number of interactive mock-ups
for users to try.
Once the initial mock-up is built, the process is an iterative one:
 Trial of the prototype by users
 Feedback from users
 Modification of the prototype
 Modern prototyping tools make it easy for developers to modify the prototype on the fly, so
users can help you quickly discover what will satisfy them. From that working model, it‘s
then a relatively simple matter to reverse engineer the requirements that describe the accepted
functionality.

55
K. Conduct JAD sessions
A JAD is a Joint Application Development (or Design) session. It is an opportunity for stakeholders
with different points of view to come together to understand business requirements and brainstorm
what the best technical approach might be for meeting the customer's needs.
A JAD is a challenging environment because it is a meeting or workshop that brings together people
from a number of different disciplines. They could include business or product owners, systems
analysts, enterprise architects, solution architects, software developers, and managerial staff. Each
will come with their own points of view and may at times resort to lingo specific to their focus area.
The Business Analyst (BA) frequently stands front and center as the facilitator of a JAD and as the
presenter of what the business needs, objectives, and requirements are. The BA may also further elicit
requirements as needed. As facilitator, the BA's job is to ensure the meeting keeps running smoothly.
That requires setting the agenda, making sure the agenda items are being met, help brainstorm when
discussions become snagged, and bring order when discussion gets heated or defensive. The BA
should come prepared with copies of the agenda and business requirements documents. If asked to
serve as the representative of the business, the BA must be fully informed of what the business needs
are and be prepared to discuss and explain them. That may mean responding to questions from the
technical staff with regards to how the business would like to see something implemented. If other
business stakeholders are present, the discussion between them and the other JAD members may
cause them to realize that additional business requirements need to be captured. The BA would elicit
and capture those requirements. If technical requirements come to light, the BA may capture those if
they have the necessary expertise, or else rely on a systems analyst to do so at the meeting. A JAD is
successful, and therefore the Business Analyst is successful, when there is a "meeting of the minds"
among all of the individuals present with agreement on what kind of solution needs to be developed
to fully address business needs, with all requirements put in writing to facilitate development.

We can say that JAD session includes:

 Brainstorming
 Focus groups
 Workshops
 Role-play

4.2.1. Essential Use Case Modeling

It is a diagram of all the use-cases, actors and use case-actor association used to describe a particular
system. It is semantically closed abstraction of a subject system. Use case diagrams are one of the
standard Unified Modeling Language (UML) artifacts. Essential use case model often referred to as a task
case model or an abstract use case model models a technology independent view of your behavioral
requirements, whereas system use case models also known as concrete use case models or detailed use
case models, model your analysis of your behavioral requirements, describing in detail how users will
work with your system, including references to its user-interface aspects.

Essential use-case modeling is:

 A fundamental aspect of usage-centered designs, an approach to software development.

56
 Intended to capture the essence of problems through technology-free, idealized, and abstract
descriptions.
 More flexible, leaving open more options and more readily accommodating changes in technology.
 More robust than concrete representations, simply because they are more likely to remain valid in the
face of both changing requirements and changes in the technology of implementation
 Ideal artifacts to capture the requirements for your system. Therefore, when you are using an essential
use case modeling, you develop a use case diagram, identify essential use cases, and identify potential
actors that interact with your system. The use case diagrams depict the core elements:

Use Case(s) – describes a sequence of actions that provide something of measurable value to an actor. It
describes the typical ways (or cases) of using the system. Each use case expresses the goal of the actors
involved and describes the task that the system, with the assistance of appropriate actors, will perform.
You can get the idea of use case‗s goal simply by observing its name and associations. It is drawn as a
horizontal ellipse as follows:

Actor(s) – is a person, organization, or external system that plays a role in one or more interactions with
your system. A list of actors would be a list of all the different roles that people or other systems could
play while interacting with the system. Actors in other term we can say users. Few systems operate
without interacting with other systems, and many systems interact only with other systems. Actors are
outside the system and usually outside the control of the system. Actors are drawn as stick figures as
shown below:

System Boundary (optional) – is used to indicate the scope of your system. It is drawn by a rectangle
around the use cases. Anything within the box represents functionality that is in scope, and anything
outside the box is not. The symbol looks the following:

57
Use case diagram also depicts the core relationships:

Association(s) – it is a relationship between actors and use cases. It is indicated in use case diagrams by
solid lines. It exists whenever an actor is involved with an interaction described by a use case. It can also
exist between use cases and even between actors, although this is typically an issue for system use case
models. A use case has at most one communicates association to a specific actor and an actor has at most
one communicates association to a specific use case, no matter how many interactions there are. It is
modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end
of the line. The arrowhead is often used to indicate the direction of the initial invocation of the
relationship and/or to indicate the primary actor within the use case. It is shown below:

Extend: a relationship from the extension use case to a base use case specifying how the behavior of
extension use case can be inserted into the behavior defined for the base use case. It is represented as
follows:

Include: a relationship from a base use case to inclusion use case specifying how the behavior of the
inclusion use case can be inserted into the behavior defined for the base use case. It is represented as
follows:

58
Generalization: a taxonomic relationship between a more general use case and a more specific use case.
It is represented as follows:

Use Case Modeling:

 An important goal of requirements modeling is to come to an understanding of the business

problem that your system is to address in order to understand its usage requirements
 Use case models focus on exactly this issue
 A use case model comprises zero or more use case diagrams, although most have at least one
diagram, and one or more use case specifications often simply called use cases
 Use case diagram is one of the standard modeling language artifacts

A use case diagram: A collection of use cases, actors, their associations, a system boundary box,
packages (optional)

a. Use cases: A use case describes a sequence of actions that provide something of measurable value to
an actor and is drawn as a horizontal ellipse
b. Actors: An actor is a person, organization, or external system that plays a role in one or more
interactions with your system and actors are drawn as stick figures
c. Associations: Associations between actors and use cases are indicated in use case diagrams by solid
lines
d. System boundary boxes: You can draw a rectangle around the use cases, called the system boundary
box, to indicate the scope of your system. Anything within the box represents functionality that is in
scope, and anything outside the box is not.
e. Packages (optional)
Packages are UML constructs that enable you to organize model elements (such as use cases) into
groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including
both use case diagrams and class diagrams

59
You should NOT use UCDs to represent exception behavior (when errors happen) or to try to illustrate
the sequence of steps that must be performed in order to complete a task. Use Sequence diagrams to show
these design features.

Example

 Students are enrolling in courses with the potential help of registrars

 Instructors input the marks students earn on assignments and registrars authorize the distribution
of transcripts (report cards) to students
 Moreover, note how some associations have arrowheads any given use case association will have
a zero or one arrowhead
 The association between Student and Enroll in Seminar indicates this use case is initially invoked
by a student and not by a registrar (the Registrar actor is also involved with this use case)

 The arrow head don‘t show information flow but shows initial invocation of relationship
 The line between the Enroll in Seminar use case and the Registrar actor has no arrowhead,
indicating it is not clear how the interaction between the system and registrars start
 Actors are always involved with at least one use case and are always drawn on the outside edges
of a use case diagram
 You often draw a use case diagram while you are identifying use cases, actors, and the
associations among them
 Your goal is to model the behavioral requirements for your system, how your users will work
with your system to fulfill their needs, not what the developers think they should build

The Difference between Include and extends

Probably the best way to think about these diagram elements is as follows:

 "X uses/include Y" indicates that the task "X" has a subtask "Y"; that is, in the process of
completing task "X", task "Y" will be completed at least once.
 "X extends Y" indicates that "X" is a task for the same type as "Y", but "X" is a special, more
specific case of doing "Y". That is, doing X is a lot like doing Y, but X has a few extra processes
to it that go above and beyond the things that must be done in order to complete Y.

60
Identifying Actors

An actor represents anything or anyone that interfaces with your system. This may include people (not
just the end user), external systems, and other organizations. Actors are always external to the system
being modeled; they are never part of the system

 Who is the main customer of your system?

 Who obtains information from this system?
 Who provides information to the system?
 Who installs the system?
 Who operates the system?
 Who shuts down the system?
 What other systems interact with this system?
 Does anything happen automatically at a preset time?
 Who will supply, use, or remove information from the system?
 Where does the system get information?

Recommendations:

When you are essential use case modeling, your goal is to use actors to model roles and not the physical,
real-world people, organizations, or systems. To describe an actor you want to give it a name that

61
accurately reflects its role within your model. Actor names are usually singular nouns, such as Grade
Administrator, Customer, and Payment Processor.

Identifying Use Cases

A use case is described in terms of a sequence of interactions between some actors and the system by
which the system provides a service to the actors. One way to identify essential use cases is to identify
services by assessing your SMEs the following questions

 What are users in this role trying to accomplish?

 To fulfill this role, what do users need to be able to do?
 What are the main tasks of users in this role?
 What information do users in this role need to examine, create, or change?
 What do users in this role need to be informed of by the system?
 What do users in this role need to inform the system about?

For Example: from the point of view of the student actor, you may discover that student:

 Enroll in, attend, fail and pass seminars

 Need a list of available seminars
 Need to determine basic information about a seminar, such as its description and its prerequisites
 Need to obtain a copy of their transcript, their course schedules and the fees due.
 Pay fees, pay late changes, receive reimbursement for dropped and cancelled courses, receive
grants and receive student loans.
 Graduate from school or drop out of it.
 Need to be informed of changes in seminars, including room changes, time changes even
cancellations.
 Similarly, another way to identify use cases is to ask your SMEs to brainstorm the various
scenarios
 Often called use case scenarios that your system may or may not support
 A use case scenario is a description of a potential business situation that may be faced by the
users of a system

For example, the following would be considered use case scenarios for university information:

 A student wants to enroll in a seminar, but the registrar informs him that he does not have the
prerequisite for it.
 A student wanted to enroll in a seminar that she does have the prerequisites for and seats are still
available in the seminar.
 A professor requests a seminar list for every course he teaches.
 A researcher applies for a research grant, but only receives partial funding for her project.
 A professor submits student marks to the system. These marks may be for exams, tests or
assignments.
 A student want to drop a seminar the day before the drop date
 A student requests a printed copy of his transcript, so he can include copies of it with his resume.

Documenting a Use Case

62
The following points will be included when we document use cases:

Example-1 on Documenting Use Cases

63
.

64
4.2.2. Essential User Interface Prototyping
 User-Interface prototype
 To your users, the user interface is the system
 The UI is the portion of software with which a user directly interacts
 If you build an ineffective user-interface (UI) to your system then it really does not matter
how good the rest of your system is:
 Your users are going to hate what you have built for them
 Effective developers understand, and then apply, at least the fundamentals of UI
development
 The implication is that you will need techniques helping you to explore the UI with your
stakeholders, both to analyze their needs and then to design a UI that meets those needs

65
User-Interface Development Artifacts: An artifact is a byproduct of software development that helps
describe the architecture, design and function of software.

Essential UI Prototyping

 It represents the general ideas behind the UI, but not the exact details.
 Essential UI prototypes represent UI requirements in a technology-independent manner
 You should be focused on requirements, not design; therefore, you do not currently want to use
technology-based prototyping tools
 Just as essential use case models do for behavioral requirements
 It models UI requirements, requirements evolved through analysis and design to result in the final
user interface for your system
 Two basic differences exist between essential UI prototyping and traditional UI prototyping
1. Essential UI modeling the goal is to focus on your users and their usage of the system,
not system features
2. Prototyping tools are simple, including whiteboards, flip chart paper, and sticky notes.

When a team is creating an essential UI prototype, it iterates between the following tasks:

1. Explore system usage: Likely work together on a whiteboard to discuss ideas, work on initial
drawing together, and generally take advantage of the dynamic nature of whiteboards to come to
an understanding quickly of the portion of the system you are discussing
2. Model major UI elements: Potential screens and reports, can be modeled using flip chart paper
3. Model minor UI elements: Input fields, lists, and containers (minor UI elements that aggregate
other minor UI elements) are modeled using sticky notes
4. Explore the usability of your UI: Highly usable systems are learnable, they enable user
productivity, their use is easy to remember, and they are supportable

66
User-interface flow diagrams also called storyboards, interface flow diagrams, Windows navigation
diagrams, and context-navigation maps. Enable you to model the high-level relationships between major
user-interface elements. The boxes represent major user interface elements and the arrows represent the
possible flow between them, modeled as you would transitions in activity diagrams.

Initial UI flow diagram for the university system

When you are on the Desktop screen, you can use the Students Icon to take you to the Search for Students
screen. Once you are there, you can either go back to the desktop (going back is always assumed) or go to
the Student Profile screen.

UI flow diagrams are typically used for one of two purposes

1. They are used to model the interactions that users have with your software, as defined in a single
use case
 You can develop a UI flow diagram that reflects the behavioral view of the single use
case.
2. They enable you to gain a high-level overview of the UI for your application
 The high-level overview approach, also referred to as the architectural approach
 You can quickly gain an understanding of how the system is expected to work.

UI flow diagrams can be used to determine whether the user interface will be usable.

Five factors affect the usability of your software

 Access. Your system should be usable, without help or instruction

 Efficacy. Your system should not with or impede use by a skilled user who has substantial
experience with the system
 Progression. Your system should facilitate continuous advancement in knowledge, skill, and
facility, and accommodate progressive change in use as the user gains experience with the system
interferes.
 Support. Your system should support the real work users are trying to accomplish by making it
easier, simpler, faster, and accommodate progressive change.

67
  Context. Your system should be suited to the real conditions and actual environment of the
operational context.

User-Interface Design Strategies

All developers have an understanding of the basic principles of UI design. These principles are:

1. The structure principle. Your design should organize the UI purposefully, in meaningful and
useful ways based on clear, consistent models and concerned with your overall UI architecture
2. The simplicity principle. Your design should make simple, common tasks simple to do,
communicating clearly and simply in the user's own language, and providing good shortcuts that
are meaningfully related to longer procedures
3. The visibility principle. Your design should keep all needed options and materials for a given task
visible without distracting the user with extraneous or redundant information.
4. The feedback principle. Your design should keep users informed of actions or interpretations,
changes of state or condition, and errors or exceptions relevant and of interest to the user through
clear, concise, and unambiguous language familiar to users
5. The tolerance principle. Your design should be flexible and tolerant, reducing the cost of mistakes
and misuse by allowing undoing and redoing, while also preventing errors wherever possible by
tolerating varied inputs and sequences and by interpreting all reasonable actions as reasonable
6. The reuse principle. Your design should reuse internal and external components and behaviors,
maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the
need for users to rethink and remember

4.2.3. Domain modeling with class responsibility collaborator (CRC) cards

A collection of standard index cards that have been divided into three sections.

1. A class represents a collection of similar objects

2. A responsibility is something that a class knows or does
3. A collaborator is another class that a class interacts with to fulfill its responsibilities

An example CRC card

68
The Advantages of CRC Modeling

 The experts do the analysis:- The people who understand the problem domain, the business
domain experts (BDEs)
 User participation increased:-Because users are actively involved in defining the model their
satisfaction with the work will be much greater
 Breaks down communication barriers:-Users and developers work together side-by-side to create
the CRC model.
 It‘s simple and straightforward:-You get a group of people together in a room and fill out a bunch
of index cards.
 It goes hand-in-hand with prototyping:-CRC modeling and prototyping are both iterative
processes in which users are greatly involved
 It leads directly into class diagramming:- CRC models and class diagrams show many of the
same concepts

The Disadvantages of CRC Modeling

 It‘s threatening to some developers:-Too many developers do not recognize the need for working
closely with users, thinking that because they know the technology they also understand the
business domain
 It‘s hard to get users together:-Scheduling people for meetings is always hard to do

4.2.4. Developing a supplementary Specification

A supplementary specification is a document that contains requirements not contained directly in your use
cases. Often includes business rules, technical requirements, and constraints

69
Business Rules (BR)

 Often focus on access control issues

For example, professors are allowed to input and modify the marks of the students taking the
seminars they instruct, but not the marks of students in other seminars.
 May also pertain to business calculations
For example, how to convert a percentage mark (for example, 91 percent) that a student receives
in a seminar into a letter grade (for example, A-)
 Some are focus on the policies of your organization
For example, the university policy is to dismiss for one year anyone who fails more than two
courses in the same semester
 Each has a unique identifier such as BR#, but you are free to set your own numbering approach

Identifying Nonfunctional Requirements and Constraints

70
Non-Functional Requirements are often referred to as technical requirements (TR):

 Pertains to the technical aspects that your system must fulfill

 Example, TR34 The system shall be unavailable for no less than 2 minutes in a 24-hour period

Constraints (C) are effectively global requirements, such as limited development resources or a decision
by senior management that restricts the way that you develop a system.

 Can be economic, political, technical, or environmental and pertain to your project resources,
schedule, target environment, or to the system itself.

4.2.5. Identifying Change Cases

Change cases are used to describe new potential requirements for a system or modifications to existing
requirements. Change cases are often the result of brainstorming by your SMEs, where questions such
as:-

 How can the business change?‖

 What technology can change?
 What legislation can change?
 What is your competition doing?
 What systems will we need to interact with?
 Who else might use the system and how?

Change in your business environment

Change case: The University will open a new campus

Likelihood: Certain. It has been announced that a new campus will be opened it two years across town.

Impact: Large Students will be able to register in classes at either campus. Some instructors will teach at
both campuses

 Some departments, such as the Computer Science and Philosophy departments are scheduled to
move their entire programs to the new campus
 It is likely that most students will want to schedule courses at only one of the two campuses so we
will need to make this easy to support

I like to consider the potential changes when making architecture and design decisions when all things
are equal I will pick a design alternative that fulfills one or more potential changes

4.3. Ensuring Your Requirements Are correct: Requirement validation

Techniques
Requirements documents serve both as a contract between us and the customer, detailing what we
are to deliver, and as guidelines for the designers, detailing what they are to build. Thus, before the
requirements can be turned over to the designers and system analysts, we and our customers must be
absolutely sure that each knows the other‘s intent, and that our intents are captured in the requirements
documents. To establish this certainty, we validate the requirements and verify the specification.

Requirements checking (quality criteria)

71
 1. Validity: Does the system provide the functions which best support the customer‘s needs?
2. Consistency:
 Are there any requirements conflicts?
 The requirements must be compatible with each other.
3. Completeness: Are all functions required by the customer included?
4. Realism: Can the requirements be implemented given available budget and technology
5. Adequacy: The requirements must address the actual needs of the system.
6. Unambiguity: Every requirement must be described in a way that precludes different
interpretations.
7. Comprehensibility: The requirements must be understandable by the stakeholders.
8. Verifiability: Can the requirements be checked?
9. Importance: Each requirement must indicate how essential it is for the success of the project.
10. Necessity: The requirements must all contribute to the satisfaction of the project goals.
11. Viability: All requirements can be implemented with the available technology, human resources
and budget.
12. Traceability: The context in which a requirement was created should be easy to retrieve.

Note:

 Validation is the process of checking whether the specification captures the customer's needs.
 Verification is the process of checking that the software meets the specification.

Validation denotes checking whether inputs, performed activities, and created outputs (requirements
artifacts) of the requirements engineering core activities fulfill defined quality criteria. Concerned with
demonstrating that the requirements define the system that the customer really wants. Requirements error
costs are high so validation is very important. Fixing a requirements error after delivery may cost up to
100 times the cost of fixing an implementation error Validation is performed by involving:

 relevant stakeholders,
 Other requirement sources (standards, laws, etc.)
 External reviewers, if necessary.

72
Requirements validation techniques

1. Requirements reviews: Systematic manual analysis of the requirements

2. Prototyping: Using an executable model of the system to check requirements: allow the
stakeholders to try out the requirements for the system and experience them thereby.
3. Test-case generation :Developing tests for requirements to check testability
4. Automated consistency analysis: Checking the consistency of a structured requirements
description
5. Inspection: an organized examination process of the requirements.
6. Walkthrough: A walkthrough does not have formally defined procedure and does not require a
differentiated role assignment.
 Checking early whether an idea is feasible or not.
 Obtaining the opinion and suggestions of other people.
 Checking the approval of others and reaching agreement.

73
4.3.1. Testing Early and Often
All tests are made up of at least 4 basic components.

1. Testing Procedure: What are the steps that need to be carried out in order to complete the test

2. Testing Facilities: A list of what are the equipment, the laboratory setting, and the other resources you
will need to carry out the testing procedure.

3. Entry Condition: What is the state of the project required in order for the test to begin

4. Exit Condition: What criteria must be met in order for the test to be considered a success or for the
test to earn a ―passing‖ score?

Requirements reviews

 Regular reviews should be held while the requirements definition is being formulated
 Both client and contractor staff should be involved in reviews
 Reviews may be formal (with completed documents) or informal.
 Good communications between developers, customers and users can resolve problems at an early
stage

Advantages

 Effective (even after considering cost)

 Allow finding sources of errors (not only symptoms)
 Requirements authors are more attentive when they know their work will be closely reviewed
 Encourage them to conform to standards
 Familiarize large groups with the requirements (buy-in)
 Diffusion of knowledge

Risks

 Reviews can be dull and draining (need to be limited in time)

 Time consuming and expensive (but usually cheaper than the alternative)
 Personality problems
 Office politics…

4.3.2. Use Case Scenario Testing

A scenario test is a test based on a scenario. An ideal scenario test has several characteristics:

 The test is based on a story about how the program is used: including information about the
motivations of the people involved.
 The story is motivating: A stakeholder with influence would push to fix a program that failed this
test.
 The story is credible: It not only could happen in the real world; stakeholders would believe that
something like It probably will happen..
 The story involves a complex use of the program or a complex environment
 The test results are easy to evaluate: This is valuable for all tests, but is especially important for
scenarios because they are complex.

74
Types of scenario testing

Type 1 – scenarios used as to define input/output sequences. They have quite a lot in common with
requirements elicitation.

Type 2 – scenarios used as a script for a sequence of real actions in a real or simulated environment

Why Use Scenario Tests?

 Learn the product

 Connect testing to documented requirements
 Expose failures to deliver desired benefits
 Explore expert use of the program
 Bring requirements-related issues to the surface, which might involve reopening old requirements
discussions (with new data) or surfacing not-yet-identified requirements.

12 ways to create Good Scenarios

1. Write life histories for objects in the system.

2. List possible users, analyze their interests and objectives.
3. Consider disfavored users: how do they want to abuse your system?
4. List ―system events "How does the system handle them?
5. List "special events. ―What accommodations does the system make for these?
6. .List benefits and creates end-to-end tasks to check them.
7. Interview users about famous challenges and failures of the old system.
8. Work alongside users to see how they work and what they do.
9. Read about what systems like this are supposed to do.
10. Study complaints about the predecessor to this system or its competitors.
11. Create a mock business. Treat it as real and process its data.
12. Try converting real-life data from a competing or predecessor application.

Chapter 5: Determining What to Build: OO Analysis

Your requirements model, although affective for understanding what your users want to have built, is not
as effective at understanding what will be built. Object-oriented analysis techniques, such as system use-
case modeling, sequence diagramming, class modeling, activity diagramming, and user-interface
prototyping are used to bridge the gap between requirements and system design. Requirements
engineering focuses on understanding users and their usage, whereas analysis focuses on understanding
what needs to be built. Therefore, the purpose of analysis is to understand what will be built which is an
iterative process. OO Analysis is the process that groups the items that interact with one another, typically
by class, attributes, or operations, to create a model that accurately represent the intended purpose of the
system as a whole.

75
5.1. System Use Case Modeling
During analysis, your main goal is to evolve your essential use case into system use cases. The main
difference between an essential use case and a system use case is, in the system use case, you include
high-level implementation decisions. A system use case model is composed of a use case diagram and the
accompanying documentation describing the use cases, actors, and associations.

Use Case Documentation (Use Case Description)

The use case has a basic course of action, which is the main start-to-finish path the user will follow. When
you document your use case, the following sections are included:

 Name- the name of the use case. The name should implicitly express the user‗s intent of the use
case
 Description- several sentences summarizing the use case
 Actors [optional]-list of actors associated with the use case
 Status [optional] – an indication of the status of the use case like work in progress, ready for
review, passed review, or failed review
 Preconditions- a list of conditions, if any, that must be met before a use case may be invoked
 Post conditions- a list of conditions, if any, that will be true once the use case finishes
successfully
 Extension points [optional]- list of the points in a use case from which other use cases extend
 Include use cases [optional] a list of use cases this one includes
 Basic Course of Action- the main path of logic an actor follows through a use case. Often referred
to as ―happy path‖ or the ―main path‖, because it describes how the use case works when
everything works as it normally should
 Alternative Course of Action- the infrequently used paths of logic in a use case a result of
exceptions.

There are two common styles exist for writing use cases:

76
A. Narrative Style – it is used to write the basic and alternative courses of action are written one step at
a time. Example:

77
78
B. Action-Response Style – it is used to present use case steps in columns, one column for each actor
and a second column for the system. The advantage of the action-response style is, it is easier to see
how actors interact with the system and how the system responds. The disadvantage is, it is little
harder to understand the flow of logic of the use case.
Example:

79
5.2. Sequence Diagrams: From Use Cases to Classes
It is an interaction diagram that shows how the objects and classes involved in the scenario operate with
one another and the sequence of messages exchanged. It is used to model the logic of usage scenarios. A
usage scenario is exactly what its name indicates – the description of a potential way your system used.
The logic of a usage scenario may be part of a use case. It may also be one entire pass through a use case
or the logic contained in several use cases. The boxes across the top of the diagram represent classifiers or
their instances, typically use-cases, objects, classes, or actors. Because, you can send messages to both
objects and classes, objects respond to messages through the invocation of an operation, and classes do so
through the invocation of static operations, it makes sense to include both on sequence diagrams. Because
actors initiate and take an active part in usage scenarios, they are also included in sequence diagrams.
Objects have labels in the standard UML format ―ObjectName: ClassName,‖ where ‗ObjectName‘ is
optional (objects that haven‗t been given a name on the diagram are called anonymous objects). Classes
have labels in the format ‗ClassName,‘ with an indication of <> and actors have names in the format
‗ActorName‘ with an indication of <> and for major user-interfaces should be stereotyped as <> and the
use-case with <> stereotype.

The dashed lines (vertical lines) hanging from the boxes are called object lifelines representing the life
span of the object during the scenario being modeled. The long, thin boxes on the lifelines are method-
invocation boxes indicating that processing being performed by the target object/ class to fulfill a
message. The X at the bottom of a method-invocation box is a UML convention to indicate that an object
has been removed from memory, typically the result of receiving a message with the stereotype of <>.
Messages are indicated as labeled arrows, when the source and target of a message is an object or class
the label is the signature of the method invoked in response to the message. However, if either the source
or target is a human actor, the message is labeled with brief text describing the information being
communicated. Return values are optionally indicated as using a dashed arrow with a label indicating the
return value. Messages fulfill the logic of the steps of the use-case, summarized down the left-hand side
of the diagram or on the label.

Generally, there are basically five types of actions explicitly used in a UML sequence diagram.

 create – is used to create an object. It tells a class to create an instance of itself.

 call – invokes an operation on an object.
 send – is used to send a message to an object.
 return – is the return of a value to the caller, in response to a call action.
 destroy – is used to destroy an object. Represented with X Example:

Elements of a sequence diagram

1. Objects:
 Represented by boxes at top of diagram.
2. Lifeline
 Notations that should be arranged horizontally across the top of the diagram.
 No two lifeline notations should overlap each other. They represent the different objects or parts
that interact with each other in the system during the sequence.
 A lifeline notation with an actor element symbol is used when the particular sequence diagram is
owned by a use case.

80
3. Activation Bars
 Activation bar is the box placed on the lifeline. It is used to indicate that an object is active (or
instantiated) during an interaction between two objects.
 The length of the rectangle indicates the duration of the objects staying active.
 In a sequence diagram, an interaction between two objects occurs when one object sends a
message to another.
 The use of the activation bar on the lifelines of the Message Caller (the object that sends the
message) and the Message Receiver (the object that receives the message) indicates both are
active/is instantiated during the exchange of the message.

4. Message Arrows from the Message Caller to the Message Receiver specifies a message in a sequence
diagram. A message can flow in any direction; from left to right, right to left or back to the Message
Caller itself.

 Return message: is used to indicate that the message receiver is done processing the message
and is returning control over to the message caller.
 Return messages: are optional notation pieces, for an activation bar that is triggered by a
synchronous message always implies a return message.

81
  Reflexive message: When an object sends a message to itself, it is called a reflexive message. It
is indicated with a message arrow that starts and ends at the same lifeline like shown in the
example below.

The sequence of actions performed for ATM system. In this case, Client, and ATM are actors and
Controller and Database are anonymous object of the concrete classes. The diagram is shown below:

82
How to Draw Sequence Diagrams

The following steps describe the fundamental tasks of sequence diagramming, tasks we perform in an
iterative manner

1. Identify the scope of the sequence diagram

 Begin by identifying what we are modeling
 Is it the basic course of action for a single use case?
 A single alternate course?
 The combination of the basic course of action and one or more alternate courses?
 we should add a label at the top, using a note, indicating an appropriate title for the diagram and a
unique identifier for it
2. List the use case steps down the left-hand side
 Start a sequence diagram by writing a summary of the original use case text in the left-hand
margin
3. Introduce boxes for each actor
 Introduce a box for each actor across the top of our diagram
 Label each box with the <<actor>> stereotype
4. Introduce controller/ checker class(es)
 Whose purpose is to facilitate the logic described by the use case steps
 Label each box with the <<controller>> stereotype
5. Introduce a box for each major UI element
 Major user interface elements, and minor ones for that matter, are implemented as classes in
object-oriented systems
 Label each box with the <<UI>> stereotype
6. Identify appropriate messages for each use case step
 Going one step at a time, walk through the process logic for the scenario
 Starting at the top-left corner of the diagram
7. Add a method-invocation box for each invocation of a method

83
  Every time an object or class receives a message, a method is invoked
8. Add destruction messages where appropriate
 At the end of a method invocation, the target object may be destroyed
 An X at its bottom
 Sometimes an object will destroy itself

5.3. Conceptual Modeling: Class diagrams

Class models are the mainstay of the OO analysis and design. Class models show the classes of the
system, their interrelationships (including inheritance, aggregation, and association) and the operations
and attributes of the classes. The conceptual models are used to depict your detailed understanding of the
problem space and solution for your system. The easiest way to begin conceptual modeling is to convert
the CRC (as a base) directly to UML class diagram. While a CRC model provides an excellent overview
of a system, it doesn‗t provide the details needed to actually build it. A class diagram depicts classes and
their interrelationships.

 Used for describing structure and behavior in the use cases

 Provide a conceptual model of the system in terms of entities and their relationships
 Used for requirement capture, end-user interaction
 Detailed class diagrams are used for developers

A class is a description of a set of objects that share the same attributes, operations, relationships, and
semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and
operations in separate, designated compartments. Classes are depicted as boxes with three sections: the
top one indicates the name of the class, the middle one lists the attributes of the class, and the third one
lists the methods/operations.

The name of the class is the only required tag in the graphical representation of a class. It always appears
in the top-most compartment.

84
Operations describe the class behavior and appear in the third compartment.

Modifiers are used to indicate visibility of attributes and operations.

 ‘+’ is used to denote Public visibility (everyone)

 ‘#’ is used to denote Protected visibility (friends and derived)
 ‘-’ is used to denote Private visibility (no one)
 ‘/ ’ is used to denote derived attribute visibility (computed from other attributes)

Note: By default, attributes are hidden and operations are visible.

Relationships

There are two kinds of Relationships

 Generalization (parent-child relationship)

 Association (student enrolls in course)

Associations can be further classified as

 Aggregation
 Composition

A generalization connects a subclass to its super class. It denotes an inheritance of attributes and behavior
from the super class to the subclass and indicates a specialization in the subclass of the more general
super class.

85
UML permits a class to inherit from multiple super classes, although some programming languages (e.g.,
Java) do not permit multiple inheritances.

Association Relationships

If two classes in a model need to communicate with each other, there must be link between them. An
association denotes that link.

We can indicate the multiplicity of an association by adding multiplicity adornment to the line denoting
the association. The example indicates that a Student has one or more Instructors:

We can also indicate the behavior of an object in an association (i.e., the role of an object) using role
names.

We can also name the association.

86
Model objects that contain other objects by way of special associations called aggregations and
compositions.

An aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part,
where the part can exist independently from the aggregate. Aggregations are denoted by a hollow-
diamond adornment on the association.

A composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live
and die as a whole). Compositions are denoted by a filled-diamond adornment on the association.

87
CRC model: is show the initial classes of a system, their responsibilities, and the basic relationships (in
the form of a list of collaborators) between those classes for each card in the CRC model, you create a
concrete class in the class diagram, with the exception of cards that represent actors (actors exist in the
real world). The CRC model for the University represented here below:

Notice how the names stayed the same (spaces were removed from the names to follow the naming
convention of class name). The collaborators on the CRC cards indicate the need for an association,
aggregation, association, or dependency between classes. Dependencies are modeled between UI classes
and the business classes with which they collaborate because UI classes are transitory in nature, implying
the associations they are involved with are transitory. The diagram consists of the association and
dependency between classes. Implying the associations they are involved with is transitory, and hence
should be modeled as dependencies. The corresponding class model of the CRC model:

88
The class models contain a wealth of information and can be used for both analysis and design of
systems. To create and evolve a class model, you need to model:

 Classes
 Methods or operations
 Attributes
 Associations
 Dependencies

A class is a representation of an object and is simply a template from which objects are created. Classes
form the main building blocks of an object-oriented application. Classes are a collection of similar
objects. Attributes are the information stored about an object (at least information temporarily maintained
about an object), while methods are the things an object or class does. Here below, the concrete classes
that made class diagrams:

Modeling Methods during Design

During design, we should consider indicating these items:-

1. Visibility (optional)
 This is the level of access that external objects have to a method, on our class diagrams
2. Name
 Strategies for naming methods are described in bellow
3. Parameters (optional)

89
  The names of parameters, and optionally their types and default values (if any), should also be
indicated for each method
4. Return value type (optional)
 The type of the return value, if any, should be indicated

Method Visibility

 How a method is accessed by objects is defined by its visibility

 In the UML, we have our choice of four levels of visibility such as public, protected, and private.

Naming Methods

In most C-based languages, such as Java and C#, it is common to name methods with a full description,
using mixed case with the first letter of any non-initial word capitalized in the format methodName()

Techniques for Methods

During design, what factors lead to high-quality methods?

1. Develop consistent method signatures

 The greater the consistency within our designs, the easier they are to learn and to understand
 get-FirstName () VS. fetchLastName()
 theFirstName, firstName, VS. firstNm
2. Define pre-conditions and post-conditions for our methods
 A precondition describes something that must be true before a method may be invoked
 A post condition describes something that will be true once a method has completed

Modeling Attributes during Design

Attributes are the data aspects of objects and during design we should indicate these items:

 Visibility (optional)
 Initial value (optional)
 Name

90
  Type (optional)
1. Attribute Visibility
 Describes the three types of attribute visibility supported by the UML: public, protected and
private.
 As we can see, the rules and notation for attribute visibility are consistent with those for method
visibility
 All fields should be declared private for purposes of information hiding and encapsulation
2. Naming Attributes
 Like classes and methods, we should use full descriptions to name our attributes
 Attributes that are collections, such as arrays or vectors in Java, should be given names that are
plural to indicate they represent multiple values

Inheritance Techniques

We have found the following techniques to be valuable for ensuring that we apply inheritance properly:

1. The subclass should not be far from superclass

 If it does not make sense to say "the subclass is a superclass" or at least "the subclass is a kind of
superclass," then we are likely misapplying inheritance
2. Beware of implementation inheritance
 Implementation inheritance, often called convenience inheritance, occurs when a class inherits
from another class simply to reuse part.
3. Beware of inheritance based on common data attributes
4. A subclass should inherit everything
 Similarities often exist between different classes
 Very often two or more classes will share the same attributes and/or the same methods
 Inheritance models relationships, enabling we to reuse existing data and code easily

91
Example:

Association and Dependency Techniques

The following tips and techniques should help us when modeling associations and dependencies:

1. Multiplicity must be shown

 The multiplicities of an association should be modeled, one on each end of the association line
2. Question multiplicities involving minimums and maximums
 The problem with minimums and maximums is they change over time
 It is interesting to know about any minimums and maximums
3. Associations and dependencies are inherited
 Because associations and dependencies are implemented as a combination of attributes and
methods, and because attributes and methods are inherited, by implication, associations are also
inherited
4. Model a unidirectional association when collaboration is only one way
 If instances of A send messages to instances of B, but instances of B do not send messages to
instances of A, then we need a unidirectional association from A to B
 Objects are often associated with, or related to, other objects
 Students are on waiting list for seminars,
 Instructors instruct seminars,
 Seminars are an offering of courses,
 An Instructor lives at an address, and soon
 Class normalization: The process by which we refactor the behavior within a class diagram in
such a way as to increase the cohesion of classes while minimizing the coupling between them
 Getter: A method to obtain the value of a data attribute, or to calculate the value, of an object or
class
 Setter: A method that sets the value of a data attribute of an object or class. Also known as a
mutator

Composition Techniques

During design, several considerations are specific to composition:

1. The advice for associations applies to composition

 Composition associations are merely specializations of the concept of association and, as a result,
the experimental for associations apply to them

92
2. The sentence rule should make sense for composition
 It should make sense to say that one object "is part of" or "composed of" another object
3. We should be interested in both the whole and the part
 For composition associations we should be interested in both the whole and the part separately
4. Do not confuse inheritance with composition
 It is easy to get confused about when to use inheritance and when to use composition.
 Remember this: inheritance models "is a" or "is kind of" relationships, while composition models
"is part of" relationships

A restricted form of Aggregation in which two entities (or you can say classes) are highly dependent on
each other. A human needs a heart to live and a heart needs a human body to function on. In other words
when the classes (entities) are dependent on each other and their life span are same (if one dies then
another one does too) then it‘s a composition.

Class Modeling Design Tips

1. Minimize Coupling
 When one class interacts with another class, but does not know any of the implementation details
of the other class, we say they are loosely coupled
 When one class relies on the implementation (that is, it directly accesses the data attributes of the
other), we say they are tightly coupled
 When Class A is coupled to Class B, a change in B could necessitate a change in A
2. Maximize Cohesion
 We want to design methods and classes that are highly cohesive. In other words, it should be
completely clear what a method or class is all about
 Classes should represent only one kind of object, and methods should do one thing and one thing
well
3. Methods Should Do Something
 Each method of a class should either access or modify the attributes of the class

In object-oriented designs, several sources of coupling exist:

1. Coupling via associations

 Whenever an association exists between two classes, they are coupled
 For example the class Person is coupled to Address via the lives at association: a person object
knows at what address it lives
2. Coupling via composition
 Because composition is simply a specialized type of association it also indicates coupling.

93
3. Direct coupling via inheritance
 Subclasses are highly coupled to the implementations of their super-classes (a subclass knows
and does everything its superclass does)
4. Indirect coupling via inheritance
 Because a class inherits all the relationships and collaborations of its superclass(es), it also
inherits any coupling with which the super-classes are involved

Two types of class diagram

1. Normal class diagram(class diagram)

 Basic 3 parts are found(class name, attributes and methods)
 The association type
 Inheritance
2. Detail class diagram
 In addition to the above parts this detail class diagram will have:
 The association name
 Multiplicity
 And return types of methods and attributes data type

Example

94
95
5.4. Activity diagramming
Activity diagrams are used to document the logic of a single operation/ method, a single use case, or the
flow of logic of a business process. In many ways, it is the object-oriented equivalent of flow charts and
data-flow diagrams (DFD) from structured development. An activity is trigged by one or more events and
activity may result in one or more events that may trigger other activity or processes. Events start from
start symbol and end with finish marker having activities in between connected by events. The activity
diagram represents the decisions, iterations and parallel/random behavior of the processing. They
capture actions performed. They stress on work performed in operations (methods).

General skeleton of Activity Diagram

Example, the activity diagram for how someone new to the university would enroll for the first time:

96
The filled circle represents the starting point of the activity diagram – effectively a placeholder – and the
filled circle with a border represents the ending point. The rounded rectangles represent processes or
activities that are performed. The activities map reasonably closely to use-cases. The diamond represents
decision points. The decision point had only two possible outcomes. The arrows represent transitions
between activities, modeling the flow order between the various activities. The text on the arrows
represent conditions that must be fulfilled to proceed along the transition and are always described using
the format [condition]. The thick bars represent the start and end of potentially parallel processes – after
you are successfully enrolled in the university, you must attend the mandatory overview presentation and
others.

Elements of activity diagram

1. Initial node: the filled circle is the starting point of the diagram. An initial node is not required
although it does make it significantly easier to read the diagram.

2. Activity final node: the filled circle with a border is the ending point. An activity diagram can have
zero or more activity final nodes.

3. Activity: - An action state represents the non-interruptible action of objects. You can draw an action
state in Smart Draw using a rectangle with rounded corners such as Display Create Student Screen.

4. Flow/edge: Action flows, also called edges and paths, illustrate the transitions from one action state
to another. They are usually drawn with an arrowed line.

5. Fork: a black bar with one flow going into it and several leaving it. This denotes the beginning of
parallel activity.
6. Join: a black bar with several flows entering it and one leaving it. This denotes the end of parallel
processing.

97
7. Condition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in
order to traverse the node.
8. Decision: a diamond with one flow entering and several leaving.

To draw activity diagram consider the following points:

1. Identify the scope of the activity diagram: Begin by identifying what you are modeling. Is it a
single use case? A portion of a use case? A business process that includes several use-cases? A single
method of a class?
2. Add start and end points: Every activity diagram has one starting point and one ending point, so
you might as well add them right way.
3. Add activities. If you are modeling a use-case, introduce an activity for each major step initiated by
an actor.
4. Add transitions from the activities: It is always to exit from the activity, even if it is simply to an
ending point. Whenever there is more than one transition out of an activity, you must label each
transition appropriately.
5. Add decision points: Sometimes the logic of what you are modeling calls for a decision to be made.
6. Identify opportunities for parallel activities: Two activities can occur in parallel when no direct
r/ship exists between them and they must both occur before a third activity can.

5.5. User interface prototyping evolving your supplementary specification

It is an iterative analysis technique in which users are actively involved in the mocking-up of the UI for a
system. There are four high-level steps are in the UI prototyping process:

A. Determine the needs of your users

B. Build the prototype
C. Evaluate the prototype
D. Determine if you are finished.

98
The following are prototyping Tips and Techniques:

 Work with the real users.

 Use a prototyping tool.
 Get your SMEs (Small-Medium Enterprise) to work with the prototype.
 Understand the underlying business.
 Don‗t spend a lot of time making the code good.
 Only prototype features that you can actually build.
 Get an interface expert to help you design it.

5.6. Applying Analysis patterns effectively

Analysis pattern describe solutions to common problem found in the analysis/ business domain of a
system. It is typically more specific than design patterns, because they describe a solution for a portion of
a business domain. This doesn‗t mean an analysis pattern is applicable only to a single line of business,
although it could be. The basic analysis patterns are:

1. The Business Entity Analysis Pattern: The basic idea of this pattern is to separate the concepts of a
business entity, such as a person or company, from the roles it fulfills. Example: Suppose
Mr. Hosty may be a customer of your organization, as well as an employee. Furthermore, one day he
may also sell services to your company, also making him a supplier. The person doesn‗t change, but
the role(s) he has with your organization does, so you need to find a way to model this, which is what
this pattern does. Each business entity has one or more roles with your organization and each role has
a range during which it was applicable (the ―start‖ and ―end‖ attributes). Each role implements the
behavior specific to it.
2. The Contact Point Analysis Pattern: It describes an approach for keeping track of the way your
organization interacts with business entities. The basic idea behind this pattern is that surface
addresses, email addresses, and phone numbers are really the same sort of thing – a means by which
you can contact other business entities.

Some Potential Advantages of Patterns:

 Patterns increase developer productivity.

 Patterns describe proven solutions to common problems.
 Patterns increase the consistency between applications.
 Patterns are potentially better than reusable code.
 More and more patterns are being developed every day.

5.7. User Documentation

User documentation, also known as end-user documentation, is any form of documentation intended for
the end-user of a product or a service. The purpose of this documentation is to guide the users on how to
properly install, use, and/or troubleshoot a product.

 Requirements Documentation – sheds light on what is required from the product, including the
basic and advanced features, functionality, resources, and goals, among other things. This is
meant for the software development teams and testers.
 Architecture/Design Documentation – these sketch out the overall design of the software product
and describe the design principles for the development teams.

99
  Process Documentation – these break down the product journey in properly structured formats for
the product team.
 Market Strategy – this is created by the product marketing team to provide a north-star and a
game plan to bring a new product to the market.

5.8. Organizing your models with packages

Packages are UML constructs that enable you to organize model elements into groups, making your UML
diagrams simpler and easier to understand. Packages are depicted as file folders and can be used on any of
the UML diagrams, although they are most common on use case diagrams and class diagrams because
these models have tendency to grow.

100
 Chapter 6: Determining How to Build Your System: OO Design
6.1. Layering your models: Class Type Architecture
A common architectural strategy, some might call it a pattern, is to layer the architecture of a system into
several layers/strata. Some strategies simply define N layers stacked on top of each other where layer J
interacts only with layers J-1 and J+1. That's an interesting theory, and it clearly makes sense from a
logical point of view, but in practice I've found that it isn't quite so simple. Figure 1 presents a high-level
layering strategy for a software application. The various layers are represented by the rectangles and
collaboration between layers by the arrows. The primary name of a layer is indicated first, and other
common names in parenthesis.

Object-oriented (OO) technology, although since then have used it for component-based architectures,
service oriented architectures (SOAs), and combinations thereof. Throughout this article I still refer to
classes within the layers, although there is absolutely nothing stopping you from using non-OO
technology to implement the layers. The five layers are summarized in Table 1, as are the skills required
to successfully work on them (coding is applicable to all layers so it's not listed).

101
Collaboration within a layer is allowed. For example, UI objects can send messages to other UI objects
and business/domain objects can send messages to other business/domain objects. Collaboration can also
occur between layers connected by arrows. As you see in Figure 1, interface classes may send messages
to domain classes but not to persistence classes. Domain classes may send messages to persistence
classes, but not to interface classes. By restricting the flow of messages to only one direction, you
dramatically increase the portability of your system by reducing the coupling between classes. For
example, the domain classes don't rely on the user interface of the system, implying that you can change
the interface without affecting the underlying business logic. All types of classes may interact with system
classes. This is because your system layer implements fundamental software features such as inter-
process communication (IPC), a service classes use to collaborate with classes on other computers, and
audit logging, which classes use to record critical actions taken by the software. For example, if your user
interface classes are running on a personal computer (PC) and your domain classes are running on an EJB
application server on another machine, and then your interface classes will send messages to the domain
classes via the IPC service in the system layer. This service is often implemented via the use of
middleware. It's critical to understand that this isn't the only way to layer an application, but instead that it
is a very common one. The important thing is that you identify the layers that are pertinent to your
environment and then act accordingly.

5.1. Applying Design Patterns effectively

While designing applications, some commonly accepted solutions are adopted for some categories of
problems. These are the patterns of design. A pattern can be defined as a documented set of building
blocks that can be used in certain types of application development problems. Some commonly used
design patterns are:

 Façade pattern
 Model view separation pattern
 Observer pattern
 Model view controller patter
 Publish subscribe pattern
 Proxy pattern

6.2. State chart modeling

A state chart diagram shows a state machine that depicts the control flow of an object from one state to
another. A state machine portrays the sequences of states which an object undergoes due to events and
their responses to events. State Chart Diagrams comprise of:

 States: Simple or Composite

 Transitions between states
 Events causing transitions
 Actions due to the events

State-chart diagrams are used for modeling objects which are reactive in nature. Example: In the
Automated Trading House System, let us model Order as an object and trace its sequence. The state
machine diagram is also called the State chart or State Transition diagram, which shows the order of
states underwent by an object within the system.

102
  It captures the software system's behavior.
 It models the behavior of a class, a subsystem, a package, and a complete system.
 It tends out to be an efficient way of modeling the interactions and collaborations in the external
entities and the system.
 It models event-based systems to handle the state of an object.
 It also defines several distinct states of a component within the system.
 Each object/component has a specific state.

Purpose of State chart Diagrams

 State chart diagram is used to model the dynamic nature of a system.

 They define different states of an object during its lifetime and these states are changed by events.
 State chart diagrams are useful to model the reactive systems.
 To model the dynamic aspect of a system.
 To model the life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model the states of an object.

How to Draw a State chart Diagram?

Before drawing a State chart diagram we should clarify the following points −

 Identify the important objects to be analyzed.

 Identify the states.
 Identify the events.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram which are listed below:

The following figure shows the corresponding state chart diagram:

1. Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled
circle.
2. Final state: It represents the final state (end) of a system. It is denoted by a filled circle present within
a circle.

103
3. Decision box: It is of diamond shape that represents the decisions to be made on the basis of an
evaluated guard.
4. Transition: A change of control from one state to another due to the occurrence of some event is
termed as a transition. It is represented by an arrow labeled with an event due to which the change has
ensued.
5. State box: It depicts the conditions or circumstances of a particular object of a class at a specific
point of time. A rectangle with round corners is used to represent the state box.

Example

An example of a top-level state machine diagram showing Bank Automated Teller Machine (ATM) is
given below. Initially, the ATM is turned off. After the power supply is turned on, the ATM starts
performing the startup action and enters into the Self-Test state. If the test fails, the ATM will enter into
the Out Of Service state, or it will undergo a triggerless transition to the idle state. This is the state where
the customer waits for the interaction. Whenever the customer inserts the bank or credit card in the
ATM's card reader, the ATM state changes from Idle to Serving Customer, the entry action readCard is
performed after entering into Serving Customer state. Since the customer can cancel the transaction at any
instant, so the transition from Serving Customer state back to the Idle state could be triggered
by cancel event.

Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction. Customer Authentication and Transaction are the
composite states itself is displayed by a hidden decomposition indication icon. After the transaction is
finished, the Serving Customer encompasses a triggerless transition back to the idle state. On leaving the
state, it undergoes the exit action ejectCard that discharges the customer card.

104
6.3. Collaboration Modeling

6.4. Component Modeling

A component diagram is used to break down a large object-oriented system into the smaller components,
so as to make them more manageable. It models the physical view of a system such as executable, files,
libraries, etc. that resides within the node. It visualizes the relationships as well as the organization
between the components present in the system. It helps in forming an executable system. A component is
a single unit of the system, which is replaceable and executable. The implementation details of a
component are hidden, and it necessitates an interface to execute a function. It is like a black box whose
behavior is explained by the provided and required interfaces.

Notation of a Component Diagram

Component and nodes

105
Purpose of a Component Diagram

 It visualizes the physical components inside the system. The components can be a library,
packages, files, etc.
 The component diagram also describes the static view of a system, which includes the
organization of components at a particular instant.
 The collection of component diagrams represents a whole system.
 To model the components of the system.
 To model the schemas of a database.
 To model the applications of an application.
 To model the system's source code.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is helpful in visualizing the structure
and the organization of a system. It describes how individual components can together form a single
system.

Following are some reasons, which tells when to use component diagram:

 To divide a single system into multiple components according to the functionality.

 To represent the component organization of the system.

6.5. Deployment Modeling

In UML, deployment diagrams model the physical architecture of a system. Deployment diagrams show
the relationships between the software and hardware components in the system and the physical

106
distribution of the processing. Deployment diagrams, which you typically prepare during the
implementation phase of development, show the physical arrangement of the nodes in a distributed
system, the artifacts that are stored on each node, and the components and other elements that the artifacts
implement. Nodes represent hardware devices such as computers, sensors, and printers, as well as other
devices that support the runtime environment of a system. Communication paths and deploy relationships
model the connections in the system.

Purpose of Deployment Diagrams

 Deployment diagrams are used for describing the hardware components, where software
components are deployed.
 Component diagrams and deployment diagrams are closely related.
 Component diagrams are used to describe the components and deployment diagrams shows how
they are deployed in hardware.
 UML is mainly designed to focus on the software artifacts of a system.
 However, these two diagrams are special diagrams used to focus on software and hardware
components.
 Deployment diagrams can be used −
 To model the hardware topology of a system.
 To model the embedded system.
 To model the hardware details for a client/server system.
 To model the hardware details of a distributed application.

Nodes in UML models

In UML models, nodes are model elements that represent the computational resources of a system, such
as personal computers, sensors, printing devices, or servers. Nodes can be connected by communication
paths to describe network structures.

1. Node instances
 In UML modeling, a node instance is a model element that represents an instantiation, or actual
occurrence, of a node. Node instances are based on existing nodes.
2. Execution environments
 In UML modeling, an execution environment is a type of node that represents a particular
execution platform, such as an operating system or a database management system. You can use
execution environments to describe the context in which the execution of a model takes place.
3. Artifacts
 In UML models, artifacts are model elements that represent the physical entities in a software
system. Artifacts represent physical implementation units, such as executable files, libraries,
software components, documents, and databases.
4. Artifact instances
 In UML modeling, an artifact instance is a model element that represents an instantiation, or
actual occurrence, of an artifact. Artifact instances are based on existing artifacts.
5. Devices
 In deployment diagrams, a device is a type of node that represents a physical computational
resource in a system, such as an application server.
6. Deployment specifications

107
  A deployment specification is essentially a configuration file, such as an XML document or a text
file that defines how an artifact is deployed on a node.
7. Relationships in deployment diagrams
 In UML, a relationship is a connection between model elements. A UML relationship is a type of
model element that adds semantics to a model by defining the structure and behavior between
model elements.

How to Draw a Deployment Diagram?

A deployment diagram consists of nodes. Nodes are nothing but physical hardware used to deploy the
application. Deployment diagrams are useful for system engineers. The application is assumed to be a
web-based application, which is deployed in a clustered environment using server 1, server 2, and server
3. The user connects to the application using the Internet. The control flows from the caching server to the
clustered environment. The following deployment diagram has been drawn considering all the points
mentioned above

108
6.6. Rational Persistence Modeling
If a system wants to have the data irrespective of a single execution instance, there will be a need to have
a facility to put the data permanently. The persistent objects are often extracted from the application
domain. For example, for a sales system you need to keep the customer, sales items, sales invoices, and
similar domain objects persistently. One of the options to store data is through the use of relational
databases which needs transformation of the class diagrams (from class diagrams to RDBs). Rules
to transform/convert class diagrams to the relational database:

1. Classes are converted/mapped to tables. The attributes become columns

2. Inheritance:
 Map in to a single table(type attribute could be used to differentiate the two classes)
 Map the sub classes in to tables
 Map all classes in to tables
3. Mapping relationship:
 One-to-one: Maintain through a foreign key in either of the table
 One-to-many: Maintained through a foreign key on the many side
 Many-to-Many: Maintain it through another intermediate associate table

109
6.7. User Interface Design
User interface prototyping is an iterative analysis technique in which users are actively involved in the
mocking-up of the UI for a system.

UI prototyping has two purposes:

First, it is an analysis technique because it enables we to explore the problem space our system addresses.
Second, UI prototyping enables us to explore the solution space of our system, at least from the point-of-
view of its users, and provides a vehicle for we to communicate the possible UI design(s) of our system.

Four high level steps are in the UI prototyping process:

1. Determine the needs of our users

 User interface modeling moves from requirements definition into analysis at the point we
decide to evolve all or part of our essential user interface
 Prototype into a traditional UI prototype
 This implies that we convert our hand drawings, flip-chart paper, and sticky notes into
something a little more substantial
 we begin this process by making platform decisions: For example, do we intend to deploy
our system so it runs in an Internet browser, as an application with a Windows based
graphical user interface (GUI)
 we discover the need to update other models as our UI prototype evolves
2. Build the prototype
 Using a prototyping tool or high-level language, we develop the screens , pages, and
reports needed by our users

110
  The best advice during this stage of the process is not to invest a lot of time in making the
code ―good‖ because chances are high we will scrap large portions of our prototype code
when portions or all of our prototype fail the evaluation
 With the user interface platform selected, we can begin converting individual aspects of
our essential UI prototype into our traditional UI prototype
 For example, with a browser-based platform, our major UI elements become HTML
pages whereas, with a Windows based platform, they would become windows or dialog
boxes
 Minor UI elements would become buttons, list boxes, custom list boxes, radio buttons,
and so on as appropriate
3. Evaluate the prototype
 After a version of the UI prototype is built, it needs to be evaluated by our SMEs to
verify that it meets their needs
 We've always found we need to address three basic questions during an evaluation:
 What is good about the UI prototype?
 What is bad about the UI prototype?
 What is missing from the UI prototype?
4. Determine if we are finished
 After evaluating the prototype, we may find we need to scrap parts of it, modify parts,
and even add brand-new parts
 we want to stop the UI prototyping process when we find that the evaluation process is no
longer generating any new ideas or it is generating a small number of not so important
ideas Otherwise, back to step one

Example for UI

111
 Chapter 7: Object Oriented Testing and Maintenance
6.1. An overview of testing
Testing: is the process of evaluating a system or its component(s) with the intent to find whether it
satisfies the specified requirements or not. In simple words, testing is executing a system in order to
identify any gaps, errors, or missing requirements in contrary to the actual requirements. According to
ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a software item to detect
the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the
features of the software item.

Testing is a group of techniques to determine the correctness of the application under the predefined script
but, testing cannot find all the defect of application. The main intent of testing is to detect failures of the
application so that failures can be discovered and corrected. It does not demonstrate that a product
functions properly under all conditions but only that it is not working in some specific conditions. Testing
furnishes comparison that compares the behavior and state of software against mechanisms because the
problem can be recognized by the mechanism. The mechanism may include past versions of the same
specified product, comparable products, and interfaces of expected purpose, relevant standards, or other
criteria but not limited up to these. Testing includes an examination of code and also the execution of
code in various environments, conditions as well as all the examining aspects of the code. In the current
scenario of software development, a testing team may be separate from the development team so that
Information derived from testing can be used to correct the process of software development.

The success of software depends upon acceptance of its targeted audience, easy graphical user interface,
strong functionality load test, etc. For example, the audience of banking is totally different from the
audience of a video game. Therefore, when an organization develops a software product, it can assess
whether the software product will be beneficial to its purchasers and other audience.

Who does Testing?

It depends on the process and the associated stakeholders of the project(s). In the IT industry, large
companies have a team with responsibilities to evaluate the developed software in context of the given
requirements. Moreover, developers also conduct testing which is called Unit Testing. In most cases, the
following professionals are involved in testing a system within their respective capacities −

 Software Tester
 Software Developer
 Project Lead/Manager
 End User

Different companies have different designations for people who test the software on the basis of their
experience and knowledge such as Software Tester, Software Quality Assurance Engineer, QA Analyst,
etc. It is not possible to test the software at any time during its cycle. The next two sections state when
testing should be started and when to end it during the SDLC.

When to Start Testing?

An early start to testing reduces the cost and time to rework and produce error-free software that is
delivered to the client. However in Software Development Life Cycle (SDLC), testing can be started from

112
the Requirements Gathering phase and continued till the deployment of the software. It also depends on
the development model that is being used. For example, in the Waterfall model, formal testing is
conducted in the testing phase; but in the incremental model, testing is performed at the end of every
increment/iteration and the whole application is tested at the end.

Testing is done in different forms at every phase of SDLC −

 During the requirement gathering phase, the analysis and verification of requirements are also
considered as testing.
 Reviewing the design in the design phase with the intent to improve the design is also considered
as testing.
 Testing performed by a developer on completion of the code is also categorized as testing.

When to Stop Testing?

It is difficult to determine when to stop testing, as testing is a never-ending process and no one can claim
that software is 100% tested. The following aspects are to be considered for stopping the testing process −

 Testing Deadlines
 Completion of test case execution
 Completion of functional and code coverage to a certain point
 Bug rate falls below a certain level and no high-priority bugs are identified
 Management decision

6.1.1. Testing concepts

Software testing is a procedure of implementing software or the application to identify the defects or
bugs. For testing an application or software, we need to follow some principles to make our product
defects free, and that also helps the test engineers to test the software with their effort and time. Here, in
this section, we are going to learn about the seven essential principles of software testing.

 Testing shows the presence of defects

 Exhaustive Testing is not possible
 Early Testing
 Defect Clustering
 Pesticide Paradox
 Testing is context-dependent
 Absence of errors fallacy

6.1.2. Testing activities

The procedure of software testing is also known as STLC (Software Testing Life Cycle) which includes
phases of the testing process. The testing process is executed in a well-planned and systematic manner.
All activities are done to improve the quality of the software product.

Software testing life cycle contains the following steps:

 Requirement Analysis
 Test Plan Creation
 Environment setup

113
 Test case Execution
 Defect Logging
 Test Cycle Closure

114
 1. Requirement Analysis:

The first step of the manual testing procedure is requirement analysis. In this phase, tester analyses
requirement document of SDLC (Software Development Life Cycle) to examine requirements stated by
the client. After examining the requirements, the tester makes a test plan to check whether the software is
meeting the requirements or not.

Entry Criteria Activities Deliverable

For the planning of test plan Prepare the list of all requirements and List of all the necessary
requirement specification, application queries, and get resolved from tests for the testable
architecture document and well- Technical Manager/Lead, System requirements and Test
defined acceptance criteria should be Architecture, Business Analyst and environment details
available. Client.
Make a list of all types of tests
(Performance, Functional and security)
to be performed.
Make a list of test environment details,
which should contain all the necessary
tools to execute test cases.

2. Test Plan Creation:

Test plan creation is the crucial phase of STLC where all the testing strategies are defined. Tester
determines the estimated effort and cost of the entire project. This phase takes place after the successful
completion of the Requirement Analysis Phase. Testing strategy and effort estimation documents
provided by this phase. Test case execution can be started after the successful completion of Test Plan
Creation.

3. Environment setup:

Setup of the test environment is an independent activity and can be started along with Test Case
Development. This is an essential part of the manual testing procedure as without environment testing is
not possible. Environment setup requires a group of essential software and hardware to create a test
environment. The testing team is not involved in setting up the testing environment, its senior developers
who create it.

115
Entry Criteria Activities Deliverable

Test strategy and test Prepare the list of software and hardware by analyzing Execution
plan document. requirement specification. report.
Test case document. After the setup of the test environment, execute the smoke test Defect report.
Testing data. cases to check the readiness of the test environment.

4. Test case Execution:

Test case Execution takes place after the successful completion of test planning. In this phase, the testing
team starts case development and execution activity. The testing team writes down the detailed test cases,
also prepares the test data if required. The prepared test cases are reviewed by peer members of the team
or Quality Assurance leader. RTM (Requirement Traceability Matrix) is also prepared in this phase.
Requirement Traceability Matrix is industry level format, used for tracking requirements. Each test case is
mapped with the requirement specification. Backward & forward traceability can be done via RTM.

Entry Criteria Activities Deliverable

Requirement Creation of test cases. Test execution result.

Document Execution of test cases. List of functions with the detailed explanation
Mapping of test cases according to of defects.
requirements.

5. Defect Logging:

Testers and developers evaluate the completion criteria of the software based on test coverage, quality,
time consumption, cost, and critical business objectives. This phase determines the characteristics and
drawbacks of the software. Test cases and bug reports are analyzed in depth to detect the type of defect
and its severity. Defect logging analysis mainly works to find out defect distribution depending upon
severity and types. If any defect is detected, then the software is returned to the development team to fix
the defect, then the software is re-tested on all aspects of the testing. Once the test cycle is fully
completed then test closure report, and test metrics are prepared.

116
Entry Criteria Activities Deliverable

Test case It evaluates the completion criteria of the software based on test coverage, quality, Closure
execution report. time consumption, cost, and critical business objectives. report
Defect report Defect logging analysis finds out defect distribution by categorizing in types and Test metrics
severity.

6. Test Cycle Closure:

The test cycle closure report includes all the documentation related to software design, development,
testing results, and defect reports. This phase evaluates the strategy of development, testing procedure,
possible defects in order to use these practices in the future if there is a software with the same
specification.

Entry Criteria Activities Deliverable

All document and Evaluates the strategy of development, testing procedure, possible defects to Test closure
reports related to use these practices in the future if there is a software with the same report
software. specification

6.1.3. Managing testing

Test Management is a process of managing the testing activities in order to ensure high quality and high-
end testing of the software application. The method consists of organizing, controlling, ensuring
traceability and visibility of the testing process in order to deliver the high quality software application. It
ensures that the software testing process runs as expected.

Test Management Process is a procedure of managing the software testing activities from start to the end.
The test management process provides planning, controlling, tracking and monitoring facilities
throughout the whole project cycle. The process involves several activities like test planning, designing
and test execution. It gives an initial plan and discipline to the software testing process.

There are two main Parts of Test Management Process: –

1. Planning
 Risk Analysis:
Risk is the potential loss (an undesirable outcome, however not necessarily so) resulting from a
given action or an activity.

117
 Risk Analysis is the first step which Test Manager should consider before starting any project.
Because all projects may contain risks, early risk detection and identification of its solution will
help Test Manager to avoid potential loss in the future & save on project cost.
 Test Estimation:
An estimate is a forecast or prediction. Test Estimation is approximately determining how long a
task would take to complete. Estimating effort for the test is one of the major and important tasks
in Test Management. Accurate test estimates lead to better planning, execution and monitoring of
tasks under a test manager‘s attention. Allow for more accurate scheduling and help realize
results more confidently.
 Test Planning:
A Test Plan can be defined as a document describing the scope, approach, resources, and
schedule of intended Testing activities. A project may fail without a complete Test Plan. Test
planning is particularly important in large software system development. In software testing, a
test plan gives detailed testing information regarding an upcoming testing effort, including: Test
Strategy, Test Objective, Exit /Suspension Criteria, Resource Planning, Test Deliverables
 Test Organization:
Test Organization in Software Testing is a procedure of defining roles in the testing process. It
defines who is responsible for which activities in testing process. Test functions, facilities and
activities are also explained in the same process. The competencies and knowledge of the people
involved are also defined however everyone is responsible for quality of testing process.
Generally speaking, you need to organize an effective Testing Team. You have to assemble a
skilled team to run the ever-growing testing engine effectively.
2. Execution
 Test Monitoring and Control:
What will you do when your project runs out of resource or exceeds the time schedule? You need
to Monitor and Control Test activities to bring it back on schedule. Test Monitoring and Control
is the process of overseeing all the metrics necessary to ensure that the project is running well, on
schedule, and not out of budget.
 Issue Management:
As mentioned in the beginning of the topics, all projects may have potential risk. When the risk
happens, it becomes an issue. In the life cycle of any project, there will be always an unexpected
problems and questions that crop up. For an example: The company cuts down your project
budget, your project team lacks the skills to complete project, and the project schedule is too tight
for your team to finish the project at the deadline. Risk to be avoided while testing: Missing the
deadline, Exceed the project budget, Lose the customer trust.
 Test Report and Evaluation:
The project has already completed. It‘s now time for look back what you have done. ―Test
Evaluation Report‖ describes the results of the Testing in terms of Test coverage and exit criteria.
The data used in Test Evaluation are based on the test results data and test result summary.

Benefits of Test Management:

 Enhances the software quality

 Helps in the development and maintenance of product metrics
 Identify areas of weakness

118
  It empowers the developers to ascertain that fewer coding or design errors are included in
the code.
 Checks if the software system is ‗fit for purpose and performs as it is expected to

Challenges in Test Management:

 Lack of adequate testing resources

 Insufficient testing time
 Schedule and budget constraints
 Complex requirements associated with testing and validating
 Absence of testing documents.

Test Management-Best Practices:

1. Use iterative tests:

 Using iterative testing practices is hugely beneficial and highly recommended. These approaches
help create test assets as well as save time.
2. Ensure that you begin testing activities as early as possible:
 Starting testing activities during the early SDLC stages is highly beneficial. However, most
people don‘t follow this practice despite knowing it. That eventually results in identifying bugs or
errors at later testing stages, leading to additional expenses for rectifying them. Moreover, this
delays the entire process because it increases the time spent to repair and retest it.
3. Try to improvise on time spent:
 Always try to work towards improving team efficiency and product quality. That could save you
immense effort and time.
4. Reutilize the test assets:
 Reutilizing the test assets, such as test cases, procedures, etc., can save effort and time. Hence, try
to reuse the testing assets whenever you can.
5. Ensure effective coordination between co-located test resources:
 Ensure there is effective coordination between co-located test resources as that helps control
problems associated with testing resources, mend timelines, and improve productivity, resulting
in a better ROI.
6. Use requirement-based testing strategies:
 Different kinds of testing procedures need different types of testing approaches. Therefore, a test
strategy based on your software testing requirement is always recommended. Such an approach
could help you reap better test results and quickly deliver a high-quality product. It also lowers
the testing time and effort.
7. Use DevOps:
 As the competition increases, new testing procedures are ruling the testing industry. DevOps can
be beneficial as it concentrates on the close association of the developers, operation team, and
testers. It helps maintain uniformity in upcoming releases, lower defects, facilitates rapid software
development, speeds up business growth, etc.
8. Leverage malleable testing process:

119
  Each project has a different requirement and therefore needs a different testing process. A
malleable testing process is essential to building an automated and easy workflow. This process
must also allow optimization and alteration of the overall workflow according to the need.
9. Effective communication is crucial for successful test management:
 To ensure smooth test management, effective communication of every appropriate information,
like status, goals, etc., to the stakeholders and clients is essential. That helps get their feedback
and input on the testing work and allows the Test Lead and the test team to make enhancements
accordingly.
10. Optimizing automated testing or tools for more excellent benefits:
 Achieving these tasks needs effort and time. Using automated test management tools will help
save your time and effort, reduce human errors, and enhance test coverage while providing better
and more effective test results.

6.1.4. Impact of object-oriented testing

Software typically undergoes many levels of testing, from unit testing to system or acceptance testing.
Typically, in-unit testing, small ―units‖, or modules of the software, are tested separately with focus on
testing the code of that module. In higher, order testing (e.g, acceptance testing), the entire system (or a
subsystem) is tested with the focus on testing the functionality or external behavior of the system. As
information systems are becoming more complex, the object-oriented paradigm is gaining popularity
because of its benefits in analysis, design, and coding. Conventional testing methods cannot be applied
for testing classes because of problems involved in testing classes, abstract classes, inheritance, dynamic
binding, message, passing, polymorphism, concurrency, etc.

Testing classes is a fundamentally different problem than testing functions. A function (or a procedure)
has a clearly defined input-output behavior, while a class does not have an input-output behavior
specification. We can test a method of a class using approaches for testing functions, but we cannot test
the class using these approaches.

According to Davis the dependencies occurring in conventional systems are:

 Data dependencies between variables

 Calling dependencies between modules
 Functional dependencies between a module and the variable it computes
 Definitional dependencies between a variable and its types.

But in Object-Oriented systems there are following additional dependencies:

 Class to class dependencies

 Class to method dependencies
 Class to message dependencies
 Class to variable dependencies
 Method to variable dependencies
 Method to message dependencies
 Method to method dependencies

Techniques of object-oriented testing are as follows:

1. Fault Based Testing:

120
  This type of checking permits for coming up with test cases supported the consumer specification
or the code or both. It tries to identify possible faults (areas of design or code that may lead to
errors.). For all of these faults, a test case is developed to ―flush‖ the errors out. These tests also
force each time of code to be executed.
 This method of testing does not find all types of errors. However, incorrect specification and
interface errors can be missed. These types of errors can be uncovered by function testing in the
traditional testing model. In the object-oriented model, interaction errors can be uncovered by
scenario-based testing. This form of Object oriented-testing can only test against the client‘s
specifications, so interface errors are still missed.
2. Class Testing Based on Method Testing:
 This approach is the simplest approach to test classes. Each method of the class performs a well-
defined cohesive function and can, therefore, be related to unit testing of the traditional testing
techniques. Therefore all the methods of a class can be involved at least once to test the class.
3. Random Testing:
 It is supported by developing a random test sequence that tries the minimum variety of operations
typical to the behavior of the categories
4. Partition Testing:
 This methodology categorizes the inputs and outputs of a category so as to check them severely.
This minimizes the number of cases that have to be designed.
5. Scenario-based Testing:
 It primarily involves capturing the user actions then stimulating them to similar actions
throughout the test.
 These tests tend to search out interaction form of error.

6.1.5. Types of Testing

As we know, software testing is a process of analyzing an application's functionality as per the customer
prerequisite. If we want to ensure that our software is bug-free or stable, we must perform the various
types of software testing because testing is the only method that makes our application bug-free.

121
The different types of Software Testing

The categorization of software testing is a part of diverse testing activities, such as test strategy, test
deliverables, a defined test objective, etc. And software testing is the execution of the software to find
defects. The purpose of having a testing type is to confirm the AUT (Application under Test). To start
testing, we should have a requirement, application-ready, necessary resources available. To maintain
accountability, we should assign a respective module to different test engineers.

The software testing mainly divided into two parts, which are as follows:

122
Manual Testing: Testing any software or an application according to the client's needs without using any
automation tool is known as manual testing. In other words, we can say that it is a procedure of
verification and validation. Manual testing is used to verify the behavior of an application or software in
contradiction of requirements specification. We do not require any precise knowledge of any testing tool
to execute the manual test cases. We can easily prepare the test document while performing manual
testing on any application.

Classification of Manual Testing

In software testing, manual testing can be further classified into three different types of testing, which are
as follows:

 White Box Testing

 Black Box Testing
 Grey Box Testing

White Box Testing

In white-box testing, the developer will inspect every line of code before handing it over to the testing
team or the concerned test engineers. Subsequently, the code is noticeable for developers throughout
testing; that's why this process is known as WBT (White Box Testing). In other words, we can say that
the developer will execute the complete white-box testing for the particular software and send the specific
application to the testing team. The purpose of implementing the white box testing is to emphasize the
flow of inputs and outputs over the software and enhance the security of an application. White box testing
is also known as open box testing, glass box testing, structural testing, clear box testing, and transparent
box testing.

Black Box Testing

Another type of manual testing is black-box testing. In this testing, the test engineer will analyze the
software against requirements, identify the defects or bug, and sends it back to the development team.
Then, the developers will fix those defects, do one round of White box testing, and send it to the testing
team. Here, fixing the bugs means the defect is resolved, and the particular feature is working according

123
to the given requirement. The main objective of implementing the black box testing is to specify the
business needs or the customer's requirements. In other words, we can say that black box testing is a
process of checking the functionality of an application as per the customer requirement. The source code
is not visible in this testing; that's why it is known as black-box testing.

Types of Black Box Testing

Black box testing further categorizes into two parts, which are as discussed below:

 Functional Testing
 Non-function Testing

Functional Testing

The test engineer will check all the components systematically against requirement specifications is
known as functional testing. Functional testing is also known as Component testing. In functional testing,
all the components are tested by giving the value, defining the output, and validating the actual output
with the expected value. Functional testing is a part of black-box testing as its emphases on application
requirement rather than actual code. The test engineer has to test only the program instead of the system.

Types of Functional Testing

Just like another type of testing is divided into several parts, functional testing is also classified into
various categories. The diverse types of Functional Testing contain the following:

 Unit Testing
 Integration Testing
 System Testing

124
1. Unit Testing
 Unit testing is the first level of functional testing in order to test any software. In this, the test
engineer will test the module of an application independently or test all the module functionality
is called unit testing.
 The primary objective of executing the unit testing is to confirm the unit components with their
performance. Here, a unit is defined as a single testable function of software or an application.
And it is verified throughout the specified application development phase.
2. Integration Testing
 Once we are successfully implementing the unit testing, we will go integration testing. It is the
second level of functional testing, where we test the data flow between dependent modules or
interface between two features is called integration testing.
 The purpose of executing the integration testing is to test the statement's accuracy between each
module.

Types of Integration Testing

Integration testing is also further divided into the following parts:

 Incremental Testing
 Non-Incremental Testing

Incremental Integration Testing

 Whenever there is a clear relationship between modules, we go for incremental integration

testing. Suppose, we take two modules and analysis the data flow between them if they are
working fine or not.

125
  If these modules are working fine, then we can add one more module and test again. And we can
continue with the same process to get better results.
 In other words, we can say that incrementally adding up the modules and test the data flow
between the modules is known as Incremental integration testing.

Types of Incremental Integration Testing

Incremental integration testing can further classify into two parts, which are as follows:

 Top-down Incremental Integration Testing

In this approach, we will add the modules step by step or incrementally and test the data flow
between them. We have to ensure that the modules we are adding are the child of the earlier ones.
 Bottom-up Incremental Integration Testing
In the bottom-up approach, we will add the modules incrementally and check the data flow
between modules. And also, ensure that the module we are adding is the parent of the earlier
ones.

Non-Incremental Integration Testing/ Big Bang Method

Whenever the data flow is complex and very difficult to classify a parent and a child, we will go for the
non-incremental integration approach. The non-incremental method is also known as the Big Bang
method.

3. System Testing
 Whenever we are done with the unit and integration testing, we can proceed with the system
testing.
 In system testing, the test environment is parallel to the production environment. It is also known
as end-to-end testing.
 In this type of testing, we will undergo each attribute of the software and test if the end feature
works according to the business requirement. And analysis the software product as a complete
system.

Non-function Testing

The next part of black-box testing is non-functional testing. It provides detailed information on software
product performance and used technologies. Non-functional testing will help us minimize the risk of
production and related costs of the software. Non-functional testing is a combination of performance,
load, stress, usability and, compatibility testing.

Types of Non-functional Testing

Non-functional testing categorized into different parts of testing, which we are going to discuss further:

 Performance Testing
 Usability Testing

126
  Compatibility Testing
1. Performance Testing

In performance testing, the test engineer will test the working of an application by applying some load. In
this type of non-functional testing, the test engineer will only focus on several aspects, such as Response
time, Load, scalability, and Stability of the software or an application.

Classification of Performance Testing

Performance testing includes the various types of testing, which are as follows:

 Load Testing
 Stress Testing
 Scalability Testing
 Stability Testing

Load Testing: While executing the performance testing, we will apply some load on the particular
application to check the application's performance, known as load testing. Here, the load could be less
than or equal to the desired load. It will help us to detect the highest operating volume of the software and
bottlenecks.

Stress Testing: It is used to analyze the user-friendliness and robustness of the software beyond the
common functional limits. Primarily, stress testing is used for critical software, but it can also be used for
all types of software applications.

Scalability Testing: To analysis, the application's performance by enhancing or reducing the load in
particular balances is known as scalability testing. In scalability testing, we can also check the system,
processes, or database's ability to meet an upward need. And in this, the Test Cases are designed and
implemented efficiently.

Stability Testing: Stability testing is a procedure where we evaluate the application's performance by
applying the load for a precise time. It mainly checks the constancy problems of the application and the

127
efficiency of a developed product. In this type of testing, we can rapidly find the system's defect even in a
stressful situation.

2. Usability Testing

Another type of non-functional testing is usability testing. In usability testing, we will analyze the user-
friendliness of an application and detect the bugs in the software's end-user interface. Here, the term user-
friendliness defines the following aspects of an application: The application should be easy to understand,
which means that all the features must be visible to end-users. The application's look and feel should be
good that means the application should be pleasant looking and make a feel to the end-user to use it.

3. Compatibility Testing

In compatibility testing, we will check the functionality of an application in specific hardware and
software environments. Once the application is functionally stable then only, we go for compatibility
testing. Here, software means we can test the application on the different operating systems and other
browsers, and hardware means we can test the application on different sizes.

Grey Box Testing

Another part of manual testing is Grey box testing. It is a collaboration of black box and white box
testing. Since, the grey box testing includes access to internal coding for designing test cases. Grey box
testing is performed by a person who knows coding as well as testing. In other words, we can say that if a
single-person team done both white box and black-box testing, it is considered grey box testing.

Automation Testing

The most significant part of Software testing is Automation testing. It uses specific tools to automate
manual design test cases without any human interference. Automation testing is the best way to enhance
the efficiency, productivity, and coverage of Software testing. It is used to re-run the test scenarios, which
were executed manually, quickly, and repeatedly. In other words, we can say that whenever we are testing
an application by using some tools is known as automation testing. We will go for automation testing
when various releases or several regression cycles goes on the application or software. We cannot write
the test script or perform the automation testing without understanding the programming language.

128
Some other types of Software Testing

In software testing, we also have some other types of testing that are not part of any above discussed
testing, but those testing are required while testing any software or an application.

 Smoke Testing
In smoke testing, we will test an application's basic and critical features before doing one round
of deep and rigorous testing. Or before checking all possible positive and negative values is
known as smoke testing. Analyzing the workflow of the application's core and main functions is
the main objective of performing the smoke testing.
 Sanity Testing
It is used to ensure that all the bugs have been fixed and no added issues come into existence due
to these changes. Sanity testing is unscripted, which means we cannot document it. It checks the
correctness of the newly added features and components.
 Regression Testing
Regression testing is the most commonly used type of software testing. Here, the term regression
implies that we have to re-test those parts of an unaffected application. Regression testing is the
most suitable testing for automation tools. As per the project type and accessibility of resources,
regression testing can be similar to Retesting. Whenever a bug is fixed by the developers and then
testing the other features of the applications that might be simulated because of the bug fixing is
known as regression testing. In other words, we can say that whenever there is a new release for
some project, then we can perform Regression Testing, and due to a new feature may affect the
old features in the earlier releases.

 User Acceptance Testing

The User acceptance testing (UAT) is done by the individual team known as domain
expert/customer or the client. And knowing the application before accepting the final product is
called as user acceptance testing. In user acceptance testing, we analyze the business scenarios,
and real-time scenarios on the distinct environment called the UAT environment. In this testing,
we will test the application before UAI for customer approval.
 Exploratory Testing
Whenever the requirement is missing, early iteration is required, and the testing team has
experienced testers when we have a critical application. New test engineer entered into the team

129
 then we go for the exploratory testing. To execute the exploratory testing, we will first go through
the application in all possible ways, make a test document, understand the flow of the application,
and then test the application.
 Adhoc Testing
Testing the application randomly as soon as the build is in the checked sequence is known as
Adhoc testing. It is also called Monkey testing and Gorilla testing. In Adhoc testing, we will
check the application in contradiction of the client's requirements; that's why it is also known as
negative testing. When the end-user using the application casually, and he/she may detect a bug.
Still, the specialized test engineer uses the software thoroughly, so he/she may not identify a
similar detection.
 Security Testing
It is an essential part of software testing, used to determine the weakness, risks, or threats in the
software application. The execution of security testing will help us to avoid the nasty attack from
outsiders and ensure our software applications' security. In other words, we can say that security
testing is mainly used to define that the data will be safe and endure the software's working
process.
 Globalization Testing
Another type of software testing is Globalization testing. Globalization testing is used to check
the developed software for multiple languages or not. Here, the words globalization means
enlightening the application or software for various languages. Globalization testing is used to
make sure that the application will support multiple languages and multiple features. In present
scenarios, we can see the enhancement in several technologies as the applications are prepared to
be used globally.

6.2. Types and procedures of system maintenance;

The life of your software does not begin when coding starts and end with the launch. Instead, it has an
ongoing lifecycle that stops and starts whenever necessary. The start of its lifecycle and a good portion of
the work begin at launch. Software is always changing and as long as it is being used, it has to be
monitored and maintained properly. This is partly to adjust for the changes within an organization but is
even more important because technology keeps changing. Your software may need maintenance for any
number of reasons – to keep it up and running, to enhance features, to rework the system for changes into
the future, to move to the Cloud, or any other changes. Whatever the motivation is for software
maintenance, it is vital for the success of your business. As such, software maintenance is more than
simply finding and fixing bugs. It is keeping the heart of your business up and running.

Here are four types of software maintenance:

 Corrective Software Maintenance

 Adaptive Software Maintenance
 Perfective Software Maintenance
 Preventive Software Maintenance
1. Corrective Software Maintenance

Corrective software maintenance is what one would typically associate with the maintenance of any kind.
Correct software maintenance addresses the errors and faults within software applications that could
impact various parts of your software, including the design, logic, and code. These corrections usually

130
come from bug reports that were created by users or customers – but corrective software maintenance can
help to spot them before your customers do, which can help your brand‘s reputation.

2. Adaptive Software Maintenance

Adaptive software maintenance becomes important when the environment of your software changes. This
can be brought on by changes to the operating system, hardware, software dependencies, Cloud storage,
or even changes within the operating system. Sometimes, adaptive software maintenance reflects
organizational policies or rules as well. Updating services, making modifications to vendors, or changing
payment processors can all necessitate adaptive software maintenance.

3. Perfective Software Maintenance

Perfective software maintenance focuses on the evolution of requirements and features that existing in
your system. As users interact with your applications, they may notice things that you did not or suggest
new features that they would like as part of the software, which could become future projects or
enhancements. Perfective software maintenance takes over some of the work, both adding features that
can enhance user experience and removing features that are not effective and functional. This can include
features that are not used or those that do not help you to meet your end goals.

4. Preventive Software Maintenance

Preventative Software Maintenance helps to make changes and adaptations to your software so that it can
work for a longer period of time. The focus of the type of maintenance is to prevent the deterioration of
your software as it continues to adapt and change. These services can include optimizing code and
updating documentation as needed. Preventative software maintenance helps to reduce the risk associated
with operating software for a long time, helping it to become more stable, understandable, and
maintainable.

For all businesses and organizations, software maintenance is an essential part of the software
development lifecycle. This isn‘t something that one can skip or avoid. It is absolutely necessary for the
success of your software and any evolution into the future. It is important to know that maintenance needs
to go much further than fixing issues or bugs – that is only one steps of the software maintenance process.
Updating software environments, reducing deterioration, and enhancing what is already there to help
satisfy the needs of all users are also included in the software maintenance examples.

131