Chapter 9

Analyzing a System
Prepared by: Mr. KAY HENG
Objective

After complete the “Analyzing a System”, Student will be able

• Explain the Analyzing a system in the software development cycle

• Describe the differentiate between functional and nonfunctional

requirements in the system
• Build and design functionalities of the system according to requirements and
business rules
Outline

• Overview
• Key Concept of Analyzing a System
• Gathering the requirements
• Case study
• Functional requirement specification
• Use Case Analysis
• How do Business rules relate to Use Case?
• Nonfunctional requirements specification
• Defining Conceptual classes and relationship
• Question
Overview

• The phase is to address this basic question: what should the system
do?

• does not quite suffice for ‘real-life’ projects for a number of reasons

• such systems are typically much bigger in scope and size.

• They also have complex and ambiguously-expressed requirements.
• there is usually a large amount of money involved, which makes matters
quite serious.
• hard as it may be for a student to appreciate it, project deadlines for these
‘real-life’ projects are more critical.

• there are still two parties: the user community, which needs some
system to be built and the development people, who are assigned to
do the work
Overview

• The process could be split into three activities:

• Gather the requirements: this involves interviews of the user community,

reading of any available documentation, etc.

• Precisely document the functionality required of the system.

• Develop a conceptual model of the system, listing the conceptual classes and
their relationships
Key Concepts of Analyzing a
System
• System Use Case
• How to fine system use case in business diagram
• Type of requirements
Gathering the requirements

• Define what the new system should do. The importance of doing this
correctly cannot be overemphasized
• The system will be built based on the information garnered in this
step, any errors made in this stage will result in the implementation
of a wrong system
• Once the system is implemented, it is expensive to modify it to
overcome the mistakes introduced in the analysis stage
• Requirements for a new system are determined by a team of analysts
by interacting with teams from the company paying for the
development (clients) and the user community, who ultimately uses
the system on a day-to-day basis.
• This interaction can be in the form of interviews, surveys,
observations, study of existing manuals, etc.
Gathering the requirements

• The requirements can be classified into two categories:

• Functional requirements These describe the interaction between the system

and its users, and between the system and any other systems, which may
interact with the system by supplying or receiving data.

• Non-functional requirements Any requirement that does not fall in the

above category is a non-functional requirement. Such requirements include
response time, usability and accuracy. Sometimes, there may be
considerations that place restrictions on system development; these may
include the use of specific hardware and software and budget and time
constraints
Case study

The business processes of the library system are listed below.

• Register new members: The library receives applications from people who
want to become library members, whom we alternatively refer to as users
• Add books to the collection: When it is added to the collection, a book is
given a unique identifier by the clerk
• Issue a book to a member (or User): To check out books, a user (or member)
must identify himself to a clerk and hand over the books
• Record the return of a book: To return a book, the member gives the book to
a clerk, who submits the information to the system, which marks the book as
‘not checked out’
• Remove books from the collection: rom time to time, the library may
remove books from its collection
Case study

The business processes of the library system are listed below.

• Print out a user’s transactions : Print out the interactions (book checkouts,
returns, etc.) between a specific user and the library on a certain date
• Place/remove a hold on a book: The clerk then adds the user to a list of
users who wish to borrow the book. If the book is not checked out, a hold
cannot be placed
• Renew books issue to a member: The system must display the relevant
books, allow the user to make a selection, and inform the user of the result.
• Notify member of book’s availability: Customers who had placed a hold on a
book are notified when the book is returned.
Case study

In addition, the system must support three other requirements that

are not directly related to the workings of a library, but, nonetheless,
are essential

• A command to save the data on a long-term basis.

• A command to load data from a long-term storage device.
• A command to quit the application. At this time, the system must ask the
user if data is to be saved before termination
Functional Requirement
Specification

• It is important that the requirements be precisely documented

• The requirements specification document serves as a contract
between the users and the developer
• When it is time to deliver the system, there should be no confusion
as to what the expectations are
• It also tells the designers the expected functionality of the system.
• Moreover, as we attempt to create a precise documentation of the
requirements, we will discover errors and omissions
• An accepted way of accomplishing this task is the use case analysis
Use Case Analysis

• Case-based way of describing the uses of the system with the goal of
defining and documenting the system requirements

• It is a powerful technique that describes the kind of functionality that

a user expects from the system

• Use cases have two or more parties: agents who interact with the
system and the system itself

• In our simple library system, the members do not use the system
directly. Instead, they get services via the library staff.
Use Case Analysis

A menu with the following choices:

• Add a member
• Add books
• Issue books
• Return books
• Remove books
• Place a hold on a book
• Remove a hold on a book
• Process Holds: Find the first member who has
a hold on a book
• Renew books 10. Print out a member’s
transactions
• Store data on disk
• Retrieve data from disk
• Exit
Use Case Analysis: Register
New Member
Use Case Analysis: Add New
Book
Use Case Analysis: Book
Checkout
Use Case Analysis: Business
Rule for System
Use Case Analysis: Return Book
Use Case Analysis: Removing
Book
Use Case Analysis: Member
Transaction
Use Case Analysis: Place a Hold
Use Case Analysis: Remove a
Hold
Use Case Analysis: Process Hold
How do Business Rules Relate
to Use Cases?
Business analysts perform the task of gathering business rules, and
these belong to one of four categories

• Definitional rules: explain what is meant when a certain word is used in the
context of the business operations

• Factual rules: explain what is meant when a certain word is used in the
context of the business operations

• Constraints: are specific conditions that govern the manner in which terms
can be connected to each other

• Derivations: are knowledge that can be derived from the facts and
constraints
Nonfunctional Requirement
specification

• Nonfunctional requirements are not tasks neither use cases, but

constraints that may be linked to specific use cases of a system

• nonfunctional requirements may be generic, that is, not necessarily

attached to a function(e.g., “the application must work on a
smartphone with 32GB”)

• Constraints that are specifically related to a use case are called

nonfunctional requirements
Nonfunctional Requirement
specification

There are two kinds of nonfunctional requirements:

• Logical: Business rules attached to a use case. For example, the date in the
project registration must be the same date or before the project was
submitted

• Technological: Constraints and qualities related to the technology used to

perform the function, such as the user interface, the kind of communication
protocol, security constraints, and fault tolerance
Defining Conceptual classes and
relationship
• The last major step in the analysis phase involves the determination
of the conceptual classes and the establishment of their relationships

• We could justify the usefulness of this step in at several ways:

• Design facilitation: we determined the functionality required of the system
• Added Knowledge: The use cases do not completely specify the system.
Some of these missing details can be filled in by the class diagram.
• Error Reduction: In carrying out this step, the analysts are forced to look at
the system more carefully. The result can be shown to the client who can
verify its correctness
• Useful Documentation: The classes and relationships provide a quick
introduction to the system for someone who wants to learn it
Questions

• Build and Desing Functional and nonfunctional requirements on the

Banking System according to user requirements, business rules, and
program requirements (Use Case tool,….etc.)

• Build the Conceptual classes and relationship of Banking system by

using UML tools.
Q&A
Thank you