Chapter Seven

System Analysis and Design

Chapter 7: Object Oriented Testing and
Maintenance

Target Group 2nd Year IS students

Introduction
Implementation is a process of ensuring that the information
system is operational. It involves:
• Constructing a new system from scratch
• Constructing a new system from the existing one.
Implementation allows the users to take over its operation for
use and evaluation. It involves training the users to handle the
system and plan for a smooth conversion.
There are Six major activities System Implementation
– Coding – Documentation
– Testing – Training
– Installation – Support
– Maintenance
Con….
A. Coding Physical design specifications are turned into working
computer code

B. Testing is the totality of checking the personnel in the system

must know in detail what their roles will be, how they can use the
system, and what the system will or will not do. The success or
failure of well- designed and technically elegant systems can depend
on the way they are operated and used.

Categories of System testing

 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing SAD for IT 3rd Year students
Con…
Unit Testing

 Black Box Testing Focuses on whether the unit meets

requirements stated in specification

 White-Box Testing Looks inside the module at actual code

Integration Testing

 User interface testing  Tests each interface function

 Use-scenario testing Ensures that each use scenario works

correctly

 Data flow testing Tests each process in a step-by-step fashion

 System interface testing Ensures data transfer between systems

Con…
System Testing

 Requirements Testing Ensures that integration did not cause new errors

 Usability Testing  Tests how easy and error-free the system is in use

 Security Testing  Assures that security functions are handled properly

 Performance Testing  Assures that the system works under high volumes of activity

 Documentation Testing  Analysts check the accuracy of documentation

Acceptance Testing

 Alpha Testing  Performed by users to assure they accept the system; frequently repeats
earlier tests

 Beta Testing Uses real data, not test data. Actual users monitor for errors or needed
improvements.
Con…..
C. Installation Process during which the current system is replaced
by the new system

Four approaches of system implementation

1.Direct Installation

Changing over from the old information system to a new one by

turning off the old system when the new one is turned on

2. Parallel Installation

Running the old information system and the new one at the same
time until management decides the old system can be turned off.

SAD for IT 3rd Year students

Con…
3. Single location installation

Trying out an information system at one site and using the

experience to decide if and how the new system should be
deployed throughout the organization

4. Phased Installation

Changing from the old information system to the new one

incrementally, starting with one or a few functional
components and then gradually extending the installation
to cover the whole new system
Cont….
D. System documentation
 Detailed information about a system’s design specifications, its internal
workings and its functionality
 Internal documentation
 System documentation that is part of the program source code or is generated
at compile time
 External documentation
 System documentation that includes the outcome of structured diagramming
techniques such as data flow and entity relationship diagrams
 User Documentation
 Written or other visual information about an application system, how it
works, and how to use it

SAD for IT 3rd Year students

Con….
Types of Documentation
 System Documentation Intended to help programmers and
analysts understand and maintain the system after it is installed
 User Documentation  Intended to help users operate the
system
 Types of User Documentation
 Reference documents
 Procedures manuals
 Tutorials
 Training Manuals
 Help Disk

SAD for IT 3rd Year students

Con…
E. User Training

 End-user training is an important part of the computer-based

information system development, which must be provided to
employees to enable them to do their own problem solving.

 User training involves how to operate the equipment,

troubleshooting the system problem, determining whether a
problem that arose is caused by the equipment or software.

 Most user training deals with the operation of the system itself.
The training courses must be designed to help the user with fast
mobilization for the organization.
SAD for IT 3rd Year students
Con….
F. Support It is extremely important to users and it should be number
one principle contributing to user satisfaction with personal computing

 Most organizations provide support by two means

– Information center

– Help desk

 An organizational unit whose mission is to support users in exploiting

information technology.

 Two conditions necessary for a successful implementation

 Management support of the system under development

 Involvement of users in the development process

SAD for IT 3rd Year students

Con..
G. Conducting System Maintenance
Corrective maintenance
 Changes made to a system to repair flaws in its design, coding, or
implementation
Adaptive maintenance
 Changes made to a system to evolve its functionality to changing
business needs or technologies
Perfective maintenance
 Changes made to a system to add new features or to improve
performance
Preventive maintenance
 Changes made to a system to avoid possible future problems
Cont…
Training Information System Users
Potential training topics
– Use of the system
– Information system concepts
– Organizational concepts
– System management
– System installation
– How to interact with the system
Cont…
Conversion

 It is a process of migrating from the old system to the new one. It

provides understandable and structured approach to improve the
communication between management and project team.

Conversion Plan

 It contains description of all the activities that must occur during

implementation of the new system and put it into operation. It
anticipates possible problems and solutions to deal with them.

SAD for IT 3rd Year students

Cont…
System Implementation and Maintenance
• It includes the following activities:
Name all files for conversions.
Identifying the data requirements to develop new files during
conversion.
Listing all the new documents and procedures that are required.
Identifying the controls to be used in each activity.
Identifying the responsibility of person for each activity.
Verifying conversion schedules.

SAD for IT 3rd Year students

Cont…
System Implementation and Maintenance
For successful conversion, a conversion plan is required,
which includes:
 Knowledge of the target system and understanding of the present
system
 Teamwork
 Automated methods, testing and parallel operations
 Continuous support for correcting problems
 Updating systems/user documentation, etc

Many popular applications support opening and saving to other file

formats of the same type. For example, Microsoft Word can open

and save files in many other word processing formats.

SAD for IT 3rd Year students

Further Reading
Gary B. Shelly, Thomas J. Cashman and Harry J. Rosenblatt; System
Analysis and Design, Sixth Edition, Publisher: shelly cashman sewies

Senn; Analysis and Design of Information Systems, TMH.

Alan Dennis, Barbara Haley Wixom; Systems Analysis and Design,

2002, John Wiley & Sons.

Awad ;System Analysis and Design.

Whitten, Bentley; System Analysis and Design Methods

Joey George, J. Hoffer and Joseph Valacich; Modern Systems Analysis

and Design, Third Edition, 2001, Pearson Education.
Chapter Four

Understanding the Basics:

OO concepts
Definitions of Object Oriented
 Object-oriented (O-O) analysis and design is an approach that
is intended to facilitate the development of systems that must
change rapidly in response to dynamic business environments.
 Object-oriented techniques are thought to work well in situations
in which complicated information systems are undergoing
continuous maintenance, adaptation, and redesign.
 Object-oriented approaches use the industry standard for
modeling object-oriented systems, called the unified modeling
language (UML), to break down a system into a use case model.
Components of object oriented concepts

1. Inheritance
2. Polymorphism
3. Encapsulation
4. Abstraction
5. Coupling
6. Cohesion
7. Object
8. Class
9. Package
Inheritance
The ability to create new class from an existing class is called
inheritance.
Inheritance is the mechanism that permits new classes to be
created out of existing classes by extending and refining its
capabilities.
The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the
derived classes/child classes/subclasses.
The subclass can inherit or derive the attributes and methods
of the super-classes provided that the super-class allows so.
Types of Inheritance
Single Inheritance: A subclass derives from a single super-class
Multiple Inheritance: A subclass derives from more than one
super-classes.
Multilevel Inheritance: A subclass derives from a super-class
which in turn is derived from another class and so on.
Hierarchical Inheritance: A class has a number of subclasses
each of which may have subsequent subclasses, continuing for a
number of levels, so as to form a tree structure.
Hybrid Inheritance: A combination of multiple and multilevel
inheritance so as to form a lattice structure.
Polymorphism
 Polymorphism is derived by the combination of two words POLY and
MORPHISM.

 Poly means many and Morph means slight change.

 Polymorphism means having one name with many forms.

Example:

 Let us consider two classes, Circle and Square, each with a method
findArea. the procedure of calculating area is different for each class.

 When an object of class Circle invokes its findArea method, the

operation finds the area of the circle without any conflict with the
findArea method of the Square class.
Types Of Polymorphism
• There are two types of Polymorphism:
1. Overriding polymorphism
 Means a derived class is implementing a method of its super class.
 The call to overridden method is resolved at runtime, thus called
runtime polymorphism
 It is also called run time polymorphism. For overriding which method
will be used is determined at the run time only. The decision is made at
the time of compilation.
2. Overloading polymorphism
 in simple words means more than one method having the same
method name that behaves differently based on the arguments
passed while calling the method.
 This called static because, which method to be invoked is decided at
the time of compilation
 It is also called compile time polymorphism. Which method would
be executed will be determined by the compiler. This decision is
made when the code gets compiled.
Encapsulation and information hiding
 Encapsulation is the process of binding both attributes
and methods together within a class.
 It permits the elements of the class to be accessed from
outside only through the interface provided by the class.
 It means hiding data or implementation details of one
module from other modules. It can also be defined as
restricting access to certain properties.
 Encapsulation is a technique which is used for data
hiding. It is helpful in reducing system‟s complexity.
Abstraction
 Abstraction is a process where you show only
“relevant” data and “hide” unnecessary details of an
object from the user.
 It is a process of showing essential feature of the
entity by hiding certain important details.
 It reduces code complexity.
 It is another good feature of oops and used to show
the necessary details to the client of the object.
Association
Association is a group of links having common structure and
common behavior. Association depicts the relationship between
objects of one or more classes.
A link can be defined as an instance of an association.
Degree of an Association: Degree of an association denotes the
number of classes involved in a connection.
• Degree may be unary, binary, or ternary.
1. A unary relationship connects objects of the same class.
2. A binary relationship connects objects of two classes.
3. A ternary relationship connects objects of three or more
classes.
Cont’d….
 Cardinality Ratios of Associations: Cardinality of a binary
association denotes the number of instances participating in an
association. There are three types of cardinality ratios, namely:

 One–to–One: A single object of class A is associated with

a single object of class B.

 One–to–Many: A single object of class A is associated

with many objects of class B.

 Many–to–Many: An object of class A may be associated

with many objects of class B and conversely an object of
class B may be associated with many objects of class A.
Aggregation
Aggregation is a special form of association.

It is a relationship between two classes like association, however its a

directional association, which means it is strictly a one way
association. It represents a HAS-A relationship. the main advantage of
Aggregation to maintain code re-usability.

Example:
Student Has-A Address (Has-a relationship between student and
address)
College Has-A Address (Has-a relationship between college and
address)
Staff Has-A Address (Has-a relationship between staff and
address)
Coupling
Coupling is the measure of the independence of components.
It defines the degree of dependency of each module of system development on the other.
Coupling Measures
 Content Coupling − When one component actually modifies another, then the
modified component is completely dependent on modifying one.
 Common Coupling − When amount of coupling is reduced somewhat by
organizing system design so that data are accessible from a common data store.
 Control Coupling − When one component passes parameters to control the
activity of another component.
 Stamp Coupling − When data structures is used to pass information from one
component to another.
 Data Coupling − When only data is passed then components are connected by this
coupling.
Cohesion
Cohesion is the measure of closeness of the relationship between its
components.

It defines the amount of dependency of the components of a module on

one another.

In practice, this means the systems designer must ensure that

 They do not split essential processes into fragmented modules.

 They do not gather together unrelated processes represented as

processes on the DFD into meaningless modules.

 The best modules are those that are functionally cohesive.

 The worst modules are those that are coincidentally cohesive.

Object
An object is a real-world element in an object–oriented environment
that may have a physical or a conceptual existence.

Each object has:

 Identity that distinguishes it from other objects in the system.

 State that determines the characteristic properties of an object

as well as the values of the properties that the object holds.

 Behavior that represents externally visible activities

performed by an object in terms of changes in its state.
Class
A class represents a collection of objects having same characteristic
properties that exhibit common behavior.
It gives the blueprint or description of the objects that can be created from it.
Creation of an object as a member of a class is called instantiation. Thus,
object is an instance of a class.
The constituents of a class are:
 A set of attributes for the objects that are to be instantiated from the
class.
 Generally, different objects of a class have some difference in the values
of the attributes.
 Attributes are often referred as class data.
 A set of operations that portray the behavior of the objects of the class.
Operations are also referred as functions or methods.
Package
A package as the name suggests is a pack (group) of classes,
interfaces and other packages.

In object oriented system analysis and design we use packages to

organize our classes and interfaces.

We have two types of packages in object oriented system analysis

and design:

 built-in packages and

 user defined package.

Advantages of using a package
Reusability: While developing a project in java, we often feel
that there are few things that we are writing again and again in
our code.
Better Organization: it is always required to group the similar
types of classes in a meaningful package name so that you can
organize your project better and when you need something you
can quickly locate it and use it, which improves the efficiency.
Name Conflicts: We can define two classes with the same name
in different packages so to avoid name collision, we can use
packages
Chapter Five

OO the New Software Paradigm

Contents

The potential benefits of object orientation

The potential drawbacks of object orientation

Object standards

The object orientation software process

Introduction to Software Paradigm
Software "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.
We can distinguish between three different kinds of Software
Paradigms:
1. Programming Paradigm
2. Software Design Paradigm
3. Software Development Paradigm
Cont..

Object oriented
programing
Paradigms
1. Programming Paradigm
Programming paradigm is an approach to solve
problem using some programming language or also
we can say it is a method to solve a problem using
tools and techniques that are available to us following
some approach.
There are lots for programming language that are
known but all of them need to follow some strategy
when they are implemented and this
methodology/strategy is paradigms.
Con…
Con…
It describes the components of
 The language paradigm is a general principles that are used
by a programmer to communicate a task/algorithm to a
computer.
 The syntax of the language is a way of specifying what is
legal in the phrase structure of the language
 The semantics, or meaning, of a program in that language.
without a semantics, a programming language is just a
collection of meaningless phrases;
Cont’d….
The main purpose of programming language
paradigm is to support and facilitate the paradigm of .

 Scalability/modifiability

 Reusability

 Portability

 Performance

 Reliability

 Ease of creation
2. Software Design Paradigm
Is a model for implementing a group of applications sharing common
properties
The results of people‟s ideas on how to construct programs, combine
them into large software systems and formal mechanisms for how those
ideas should be expressed.
we can say that a Software Design Paradigm is a model for a class of
problems that share a set of common characteristics.
Software design paradigms can be sub-divided as:
I. Design Patterns
II. Components
III. Software Architecture
IV. Frameworks
Cont’d……
I. Design Patterns:
 is a proven solution for a general design problem.
 It consists of communicating „objects‟ that are customized to solve the
problem in a particular context.
II. Components:
 are binary units of independent production, acquisition, and
deployment that interact to form a functioning program.
III. Software Architecture:
• is the structure of the components of the solution.
• A particular software architecture decomposes a problem into smaller
pieces and attempts to find a solution (Component) for each piece.
IV. Frameworks:
• Frameworks can be seen as an intermediate level between components
and a software architecture.
3. Software Development Paradigm
 is often referred to as Software Engineering, may be seen as a
management model for implementing big software projects
using engineering principles.

 The software development cycle involves the activities in the

production of a software system.
 Generally the software development cycle can be divided into
the following phases:
 Requirements analysis and specification
 Design
o Preliminary design
o Detailed design
Cont’d……
Implementation
o Component Implementation
o Component Integration
o System Documenting
Testing
o Unit testing
o Integration testing
o System testing
Installation and Acceptance Testing
Maintenance
oBug Reporting and Fixing
oChange requirements and software upgrading
Advantages of Object Oriented Concepts
Improved software-development productivity

Improved software maintainability

Faster development

Lower cost of development

Higher-quality software.

Re-Usability
Disadvantages of Object Oriented Concepts
1. Steep learning curve: The thought process involved in object-oriented

programming may not be natural for some people, and it can take time to get

used to it. It is complex to create programs based on interaction of objects.

2. Larger program size: Object-oriented programs typically involve more

lines of code than procedural programs.

3. Slower programs: Object-oriented programs are typically slower than

procedure based programs, as they typically require more instructions to be

executed.

4. Not suitable for all types of problems: There are problems that lend

themselves well to functional-programming style, logic-programming style,

or procedure-based programming style, and applying object-oriented

programming in those situations will not result in efficient programs.

The object orientation software process
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:
Cont…
1. Inception:-In this phase, a business case is made for the
proposed system.
2. 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.
The primary deliverables of this phase include:
 The UML structure and behavior diagrams
 An executable of a baseline version of the evolving information system
Cont…
3. 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. The
primary deliverable of this phase is an implementation of the
system that can be released for beta and acceptance testing.

4. 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,
Software Development Process Models

2.Prototyping Model
3. Iterative Model
4.Spiral Model --------and other are part of your assignment
Chapter Six

Gathering user requirements

Contents
Gathering user requirements
Putting together requirements gathering team
Fundamental requirements gathering techniques
Essential Use Case Modeling
Essential User Interface Prototyping
Domain modeling with class responsibility
collaborator (CRC) cards
Developing a supplementary Specification
Identifying Change Cases
Introduction
A requirement is a statement about an intended product that
specifies what it should do or how to do it. For requirements
to be effectively implemented and measured, they must be
specific, unambiguous and clear.

Requirements gathering is the process of understanding

what you are trying to build and why you are building it.

Requirements gathering is frequently regarded as a part of

developing software applications (where specifications cover
both software and hardware).
Cont…
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.
Con…
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. Types of
requirements can be categorized as follows:
Requirements
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.
Non – Functional Requirements
 Non – functional requirements are Constraints or standards that the system must
have or comply with. It defines the system„s quality characteristics. As a rule of
thumb, non-functional requirements generally end with “ity”, although not all of
them do.
These requirements are discussed below:
Security
Scalability
Regulatory
Capacity
Manageability
Availability
Environmental
Reliability
Data Integrity
Recoverability
Usability
Maintainability
Interoperability
Serviceability
Performance
Con…
Gathering user requirements concerned on the following
activities
1. Putting together requirement gathering team
2. Fundamental requirements gathering techniques
3. Essential Use Case Modeling
4. Essential User Interface Prototyping
5. Domain modeling with class responsibility
collaborator (CRC) cards
6. Developing a supplementary Specification
7. Identifying Change Cases
Cont…
1.Putting together requirement gathering team
Choosing Good Subject-Matter Experts:- is a person who has
special skills or knowledge on a particular job or topic.

Choosing Good Facilitators:- is to make easy or ease a process.

Choosing Good Scribes:- a scribe is a person who copies

manuscripts or a pointed instrument used for marking where
something should be cut.
Cont…
2. Fundamental requirements gathering techniques
Interview
Direct Observation
Analyzing Documents
Questionnaires
3. 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. A use case model comprises zero or more use case
diagrams, although most have at least one diagram,
Use case diagrams are one of the standard Unified Modeling Language
(UML) artifacts.
There are two basic types of use case models:
 Essential use case models
 System use case models
Con…
Essential use-case modeling is:

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

development.

Intended to capture the spirit of problems through technology-free, idealized,

and abstract descriptions.

More flexible, leaving open more options and more readily accommodating
changes in technology.

More healthy 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.

Cont….
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 show the core elements:

UsecaseDescribes a sequence of actions, 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.

System Boundary (optional) – is used to indicate the scope of your system.

It is drawn by a rectangle around the use cases

Cont…
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.

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.

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.

Generalization: a taxonomic relationship between a more general use case and a

more specific use case.
Example 1
Students are enrolling in courses with the potential help of registrars. Professors
input the marks students earn on assignments and registrars authorize the
distribution of transcripts (report cards) to students. Note how for some use cases
there is more than one actor involved. Moreover, note how some associations have
arrowheads any given use case association will have a zero or one arrowhead.

Use case diagram

Example 2
4. Essential User Interface Prototyping
Prototyping is an important technique to reduce the cost and risk
involved in developing complex software systems,

It essentially involves building a small scale version of a complex

system in order to acquire critical knowledge required to build the
system.

Why UI Prototype ? Why not Straight to Code?

Leads to better designs

Iterative creativity

Explore design space

Facilitates communications
Con…
The main purpose of a prototype is to allow developers to acquire
the information needed to successfully build a system.
To build a successful interface developers need to acquire several
kinds of information about the system to be built. The required
information falls into the following categories.
Task specification
System functionality
Interface functionality:
Screen layouts and behavior
Design rationale:- reasons why the different design choices were
made
User feedback
Response times
Reusable code
5. Domain modeling with class responsibility collaborator (CRC) cards
It is a collection of standard index cards that have been divided into three
sections, as depicted in figure below:

A class represents a collection of similar objects, a responsibility is

something that a class knows or does, and a collaborator is another class
that a class interacts with to fulfill its responsibilities.
Example:- In a university system, classes would represent students,
tenured professors, and seminars.
6. Developing a supplementary Specification
It is a RUP (Rational Unified Process) document that contains
requirements not contained directly in your use cases. This often includes
business rules, technical requirements, and constraints.
In short, it is a container into which you place other requirements
It consists of: Business Rule (BR): that defines or constrains one aspect
of your business that is intended to declare business structure or influence
the behaviour of your business.
Example: Instructor are allowed to input and modify the marks of the
students taking the seminars they learn.
How to convert a percentage mark (for example, 91 percent) that a
student receives in a seminar into a letter grade (for example, A-).
So that, it has a unique identifier. By convention use the format of
BR#, but you are free to set your own numbering approach.
The unique identifier enables you to refer easily to business rules in
other development artifacts, such as class models and use cases.
7. Identifying Change Cases
Change cases are used to describe new potential requirements
for a system or modifications to existing requirements.
You describe the potential change to your existing requirements,
indicate the likeliness of that change occurring, and indicate the
potential impact of that change.
Example: Consider an existing University
Benefits of Gathering Requirements
A good requirement gathering process offers the following
benefits:

1. Greatly improves the chances that customers and users will

get what they wanted.

2. Decreases the chances of a failed project.

3. Reduces the overall cost of the project by catching

requirements problems before development begins.
 Requirements that are ambiguous or not fully understood often result
in costly scrap and rework.
Chapter Seven

Ensuring Your Requirements Are

correct
Contents

Requirement validation Techniques

Testing Early and Often

Use Case Scenario Testing

Introduction
Requirements Validation
Checking a work product against higher-level work products or
authorities that frame this particular product.

It is nothing more than checking whether the analysts have

understood the stakeholders‘ intention correctly and have not
introduced any errors when writing the specification.

Requirements are validated by stakeholders.

Cont…
It is shown graphically as follows:

A stakeholder is a party that has an interest in a company and can

either affect or be affected by the business.

Requirements elicitation is the practice of researching and

discovering the requirements of a system from users, customers,
and other stakeholders.
Con…
Negotiation is an open process for two parties to find an
acceptable solution to a complicated conflict.
Characteristics of Requirements Validation and Verification
Con…
Requirements Validation Techniques
The most common validation technique that can be performed manually
is called review. Three major types of reviews can be differentiated:
 Prototypes –Training of the stakeholders, Observation of prototype
usage, and Collect issues.
 Inspections – A static analysis technique that relies on visual
examination of development products to detect errors, violations of
development standards, and other problems.
 Walk-throughs – is a meeting where you gather all of your stakeholders
together and walk- through the requirements documentation, page-by-
page, line-by-line, to ensure that the document represents everyone„s
complete understanding of what is to be accomplished in this particular
project.
Testing Early and Often
Testing is the process of evaluating a system or its components
with the intent to find that whether it satisfies the specified
requirements or not.
It is executing a system in order to identify any gaps, errors, or
missing requirements to the actual desire or requirements.
Cont…
There are mainly three reasons why we should start testing early and often:
1. With early and regularly tests we have a much higher chance of catching
up with our due dates. If we start early, we have more time to resolve
discovered defects, and if we test more often, we have a better chance of
catching defects faster, and we are going to have more time to fix them.
2. Testing early and often saves us much effort. Testing early and often
can help us to catch errors in very first stages of development.
3. It is easier to get back on track. If we start testing soon and often, we
can catch the defects fast and in the early stages so if we want to change
our design and approaches to address the defect we have more time and
fewer complications ahead of us compare to our options in the later
stages.
Use Case Scenario Testing
It is simply called test documentation. A use case represents the actions
that are required to enable or abandon a goal

Scenario describes of how one or more people or organizations

interact with the system.

A Test Scenario is defined as any functionality that can be tested. As a

tester, you may put yourself in the end user‟s shoes and figure out the
real- world scenarios and use cases of the application under test.

Use case testing is defined as a software testing technique, that helps to

identify test cases that cover the entire system, on a transaction by
transaction basis from start to the finishing point.
…..The basic main test cases are:
Example 1: Suppose in a use case for ―Login functionality, to access a Gmail of a Web
Application.
An actor is represented by “A” and system by “S”. The UI is shown as follows:
Con…
Explanation of the test cases:
In the first step, the Actor enters email and password for end-to-end
scenario of login functionality.
In the next step, the system will validate the password.
Next, if the password is correct, the access will be granted.
There can be an extension of this use case. In case password is not
valid system will display a message and ask for re-try four times.
If Password, not valid four times system will ban the IP address.
Con…
Example 2:Suppose in a use-case for ―Login‖ functionality of an ATM, an actor is
represented by “A” and system by “S”. Here below, the test cases and description:
Con…
Advantages of Use Case Scenario Testing
It helps to capture the functional requirements of a system.
It is traceable.
It can serve as the basis for the estimating, scheduling, and
validating effort.
It can evolve at each iteration from a method of capturing
requirements, to development guidelines to programmers, to a
test case and finally into user documentation.
Disadvantages of Use Case Scenario Testing
Poor identification of structure and flow.
Time-consuming to generate.
Limited software tool support.
Still poor integration with established methods.
Chapter Eight

Determining What to Build: OO

Analysis
Introduction
Your requirements model, while 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.
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.
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. Example:

System Use case diagram

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. W/n you document use case, the FFg sections are included:
1. Name- the name of the use case. The name should implicitly express the user„s
intent of the use case
2. Description- several sentences summarizing the use case
3. Actors [optional]-list of actors associated with the use case
4. Status [optional] – an indication of the status of the use case like work in
progress, ready for review, passed review, or failed review
5. Preconditions- a list of conditions, if any, that must be met before a use case may
be invoked
6. Post conditions- a list of conditions, if any, that will be true once the use case
finishes successfully
7. Extension points [optional]- list of the points in a use case,other use cases
extend
Cont…
8. Include use cases [optional] a list of use cases this one includes

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

10. lternative 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:
a. Narrative Style – it is used to write the basic and alternative courses of
action are written one step at a time.
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.
Con…
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
Sequence Diagram
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 boxes across the top of the diagram represent classifiers or

their instances, typically use-cases, objects, classes, or actors.
Cont…
Generally, there are basically five types of actions explicitly used in a UML
sequence diagram.

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

b. call – invokes an operation on an object.

c. send – is used to send a message to an object.

d. return – is the return of a value to the caller, in response to a call action.

e. destroy – is used to destroy an object. Represented with X

Example:

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:
Cont…

Sequence diagram
Con…
To draw sequence diagram follow the following points:
1. dentify the scope of the sequence diagram.
2. List the use-case steps down the left-hand side.
3. Introduce boxes for each actor.
4. Introduce controller class (es).
5. Introduce a box for each major UI element.
6. Introduce a box for each included use-case.
7. Identify appropriate messages for each use-case step.
8. Add method-invocation box for each invocation of a method.
9. Add destruction messages where appropriate.
Conceptual Modeling: Class Diagram
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.
While a CRC model provides an excellent overview of a system, it
doesn„t provide the details needed to actually build it.
Con…

Class Diagram
Activity Diagram
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.
Example:The activity diagram for how someone new to the university would enroll
for the first time:

Activity Diagram
User Interface Prototyping Evolving Sour Supplementary Specification
It 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:
 It enables you to explore the problem space your system addresses.
 It enables you to explore the solution space of your 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.
Applying Analysis Patterns Effectively
Analysis pattern describe solutions to common problem found in the analysis/
business domain of a system.

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

Example:- Suppose Mr. Alemu 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.
Con…
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.

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.