Analyze Information System

Requirements and Specifications

 System Requirements
 The system requirements are description of features
and functionalities of the target system.
 Requirements are descriptions of the services that a
software system must provide and the constraints
under which it must operate
 Requirements convey the expectations of users from
the software product.
 A requirement is a vital feature of a new system
which may include processing or capturing of data,
controlling the activities of business, producing
information and supporting the management.
 What is Requirements Determination?
 Requirements determination involves studying the
existing system and gathering details to find out what
are the requirements, how it works, and where
improvements should be made.

Major Activities in requirement Determination

1. Requirements Anticipation
It predicts the characteristics of system based on
previous experience which include certain problems
or features and requirements for a new system.
2. Requirements Investigation
It is studying the current system and documenting its
features for further analysis
3. Requirements Specifications
It includes the analysis of data which determine the
requirement specification, description of features
for new system, and specifying what information
requirements will be provided.
 Requirement Engineering
 The process of gathering the software requirements
from client, analyze and document them is known as
requirement engineering.
 The goal of requirement engineering is to develop
and maintain sophisticated and descriptive ‘System
Requirements Specification’ document.
 Requirement Engineering Process, It is a four step
process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
 A. Feasibility Study
 Feasibility is the measure of how beneficial or practical the
development of an information system will be to an
organization.
 Feasibility should be measured throughout the life cycle.
 Feasibility analysis usually considers a number of
alternative solution to develop an information system, and
choose one of which is the most satisfactory solution.
 Feasibility Study is the preliminary investigation that helps
the management to take decision about whether study of
system should be feasible for development or not.
 The output of a feasibility study is a formal system
proposal act as decision document which includes the
complete nature and scope of the proposed system.
 Types of Feasibilities
 Feasibility analysis involves three key
considerations.
 These are :
Economic Feasibility
Technical Feasibility
Operational Feasibility
Behavioral Feasibility
 1. Economic Feasibility
 It is evaluating the effectiveness of candidate system
by using cost/benefit analysis method.
 Cost Benefit Analysis is done to determine the
benefits and savings that are expected from the
candidate system and compare them with cost.
 The main aim of Economic Feasibility Analysis (EFS)
is to estimate the economic requirements of
candidate system before investments funds are
committed to proposal.
 It is the alternative which will maximize the net worth
of organization by earliest and highest return of funds
along with lowest level of risk involved in developing
the candidate system.
 Cost/Benefit Analysis
 Cost and Benefit Categories
 Facility Costs : These are expenses incurred in the
preparation of the physical site where the application or the
computers will be in operation.
 Hardware : Costs related to the actual purchase or lease of
the computer and peripherals (e.g., printer, disk drives, tape
unit).
 Supply Costs : These are variable costs that increase with
increased use of paper, ribbons, disks.
 Training Costs : If the computer personnel or end-users
have to .be trained
 Operating Costs : It includes all costs associated with the
day-to-day operation of the system.
 Personnel Costs : It includes staff salaries as well as pay
for those involved in developing the system.
 Benefits
 The two major benefits of building Information
systems are :
Improving performance : The performance
category emphasizes improvement in the
accuracy of or access to information and easier
access to the system by authorized
Minimizing the cost of processing Minimizing
costs through an efficient system-error control or
reduction of staff is a benefit that should be
measured and included in Cost Benefit Analysis.
 2. Technical Feasibility
 It investigates the possibility that organization has
or can procure the necessary resources.
 This is demonstrated if the needed hardware and
software are available in the market place or can
be developed by the time of implementation.
 It analyzes and determines whether the solution
can be supported by existing technology or not.
 The analyst determines whether current technical
resources be upgraded or added it that fulfill the
new requirements.
 3. Operational Feasibility
 It determines whether the system will operating
effectively once it is developed and implemented.
 It ensures that the management should support the
proposed system and its working feasible in the
current organizational environment.
 It analyzes whether the users will be affected and they
accept the modified or new business methods that
affect the possible system benefits.
 It also ensures that the computer resources and
network architecture of candidate system are
workable.
 4. Behavioral Feasibility
 People are inherently resistant to change, and
computers have been known to facilitate change.
 So, introduction of candidate system requires
special effort to educate, sell and train the staff on
new ways.
 It evaluates and estimates the user attitude or
behavior towards the development of new system.
 It helps in determining if the system requires
special effort to educate, retrain, transfer, and
changes in employee’s job status on new ways of
conducting business.
 B. Requirements Gathering
Techniques
Interviewing
 Systems analyst collects information from individuals
or groups by interviewing.
 The analyst can be formal, legalistic, play politics, or
be informal; as the success of an interview depends
on the skill of analyst as interviewer.

Questionnaires
 This method is used by analyst to gather information
about various issues of system from large number of
persons.
Requirements gathering techniques
Review of Records, Procedures, and Forms
 Review of existing records, procedures, and forms
helps to seek insight into a system which describes
the current system capabilities, its operations, or
activities.

Observation
 This is a method of gathering information by
noticing and observing the people, events, and
objects.
 The analyst visits the organization to observe the
working of current system and understands the
requirements of the system.
 Requirements gathering techniques

Joint Application Development (JAD)

 It is a new technique developed by IBM which brings
owners, users, analysts, designers, and builders to define
and design the system using organized and intensive
workshops.
 JAD trained analyst act as facilitator for workshop who has
some specialized skills.

Secondary Research or Background Reading

 This method is widely used for information gathering by
accessing the gleaned information.
 It includes any previously gathered information used by the
marketer from any internal or external source.
 C. System Requirement Specification
(SRS)
 A system requirements specification (SRS) is a
description of a system to be developed. The
requirements received from client are written in
natural language.
 It lays out functional and non-functional
requirements, and may include a set of use cases
that describe user interactions that the software must
provide.
 SRS is a document created by system analyst after
the requirements have been collected from various
stakeholders.
 SRS documents are often quite detailed, and describe
what must be provided, not how it is to be provided. In
other words, they exclude implementation details.
 Ideal SRS Document should −
be complete, Unambiguous, and Jargon-free.
specify operational, tactical, and strategic
information requirements.
solve possible disputes between users and analyst.
use graphical aids which simplify understanding
and design.
 Purpose of SRS
 Requirements documents they appear in as legally
binding so the language used for them is very
specific.
 The requirements must be written so that several
contractors can bid for the contract, offering,
perhaps, different ways of meeting the client
organization's needs.
 Once a contract has been awarded, the contractor
must write a system definition for the client in more
detail so that the client understands and can validate
what the software will do.
 D. Software Requirement Validation
 After requirement specifications are developed, the
requirements mentioned should be validated.
 User might ask for illegal, impractical solution or
experts may interpret the requirements incorrectly.
This results in huge increase in cost.
 Requirements can be checked against following
conditions -
 If they can be practically implemented
 If they are valid and as per functionality and domain of
software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
 System Requirements categories
 Broadly software requirements should be
categorized in two categories:
1. Functional Requirements
Requirements, which are related to functional
aspect of software. They define functions and
functionality within and from the software system.
2. Non-Functional Requirements
Requirements, which are not related to functional
aspect of software. They are implicit or expected
characteristics of software, which users make
assumption of.
 1. Functional Requirements
 A functional requirement defines what the system
should do or provide for users. A function of a system
or its component. Any requirement which specifies
what the system should do.
 A function is described as a set of inputs, the
behavior, and outputs.
 Functional requirements may be calculations,
technical details, data manipulation and processing
and other specific functionality that define what a
system is supposed to accomplish.
 Behavioral requirements describing all the cases
where the system uses the functional requirements
are captured in use cases.
 Functional requirements
 In other words, a functional requirement will describe
a particular behavior of function of the system when
certain conditions are met, for example: “Send email
when a new customer signs up” or “Open a new
account”.
 Example: A functional requirement for an everyday object
like a cup would be: “ability to contain tea or coffee without
leaking”.
 Or that describes an operation, or activity.
 For example: Clicking the 'Add' button in the 'User Add
Window' will take the input data, and add it to the list of
users.
 Note that this requirement doesn't describe HOW that
activity will be done, only WHAT is to be done.
 Functional requirements
 Describe how the system should react to particular
inputs and how the system should behave in
particular situations
 EXAMPLES -
Search option given to user to search from various
invoices.
User should be able to mail any report to
management.
 Most requirements definition focuses mainly on
functional requirements, which are based upon the
expected functioning of the product or system to be
created. 
 2. Non-functional requirements
 A non-functional requirement is any requirement
which specifies how the system performs a certain
function.
 In other words, a non-functional requirement will
describe how a system should behave and what
limits there are on its functionality.
 Non-functional requirements generally specify the
system’s quality attributes or characteristics, for
example: “Modified data in a database should be
updated for all users accessing it within 2 seconds.”
 Example: A non-functional requirement for the cup
mentioned previously would be: “contain hot liquid without
heating up to more than 45 °C”.
 Non Functional Requirements
 Non-functional requirements are those requirements
which elaborate the performance characteristic of the
system and define the constraints on how the system
will do so.
 Defines the constraints, targets or control
mechanisms for the new system.
 Specified by technical peoples e.g. Architect,
Technical leaders and software developers.
 They are sometimes defined in terms of metrics
(something that can be measured about the system)
to make them more tangible.
 These include reliability, performance, service
availability, responsiveness, throughput and security.
 It is important to correctly state non-functional
requirements since they’ll affect your
users’ experience when interacting with the system.
 a non functional requirement elaborates a
performance characteristic of a particular system
 Example: a non functional requirement would be
the amount of time before an email confirmation is
sent out to a customer after he places his order: In
other words, “The customer shall receive an email
confirmation 5 minutes after his order has been
placed online.”
Types of Non-functional requirements
 Product requirements
Requirements which specify that the delivered product
must behave in a particular way, e.g. execution speed,
reliability etc.
 Organizational requirements
Requirements which are a consequence of
organizational policies and procedures, e.g. process
standards used, implementation requirements etc.
 External requirements
Requirements which arise from factors which are
external to the system and its development process,
e.g. interoperability requirements, legislative
requirements etc.
 Difference between Functional and
non-functional requirements
 A non-functional requirement is a
requirement that specifies criteria that can
be used to judge the operation of a system,
rather than specific behaviors.
  functional requirements define specific
behavior or functions.
 functional requirements define what a
system is supposed to do and non-
functional requirements define how a system
is supposed to be.
Difference…
 Functional requirements are usually in the form of
"system shall do <requirement>", an individual
action of part of the system, a black box description
input, output, process and control functional model.

 In contrast, non-functional requirements are in the

form of "system shall be <requirement>", an overall
property of the system as a whole or of a particular
aspect and not a specific function. The system's
overall properties commonly mark whether the
development project has succeeded or failed.
 Example
 If you are developing a Library system for
your college, then the functional requirements
can be listed as:
Membership facility, Issue of new books, Return
of books, Member’s data, Visiting Books status,
Pre booking of books
 And the non- functional requirements can
be listed as:
 Throughput,  Service availability,  Security of the
system and  Reliability of the system
 Domain requirements
 Describe system characteristics and features that
reflect the domain
 May be new functional requirements, constraints on
existing requirements or may define specific
computations
 If domain requirements are not satisfied, the system
may be unworkable
 Requirements that come from the application domain
of the system that reflect the characteristics of that
domain
 May be functional or non-functional
 Domain requirements
 Domain requirement issues
Understandability
Requirements are expressed in the language of
the application domain
this is often not understood by software engineers
developing the system
Domain specialists understand the area so well
that they do not think of making the domain
requirements explicit
Use Case and Data Flow
Diagram
 What is a Use Case Diagram
 A use case diagram is a dynamic behavior diagram used
to model the requirements.
 Dynamic behavior means the behavior of the system
when it is running/operating.
 Use case diagrams are used to gather the requirements
of a system including internal and external influences.
 It model the functionality of a system using actors and
use cases.
 Use case diagram does not show the detail of the use
cases: it only summarizes some of the relationships
between use cases, actors, and systems.
 They enable you to visualize the different types of roles
in a system and how those roles interact with the system.
 Purpose of Use Case Diagrams
 Use case diagrams are valuable for visualizing the
functional requirements of a system that will
translate into design choices and development
priorities.
 They also help identify any internal or external
factors that may influence the system and should be
taken into consideration.
 Use case diagrams specify how the system
interacts with actors without worrying about the
details of how that functionality is implemented
 It also demonstrate the different ways that a user
might interact with a system.
 Importance of Use Case Diagrams
 As mentioned before use case diagrams are used to
gather a usage requirement of a system.
 Below are few ways to use them.
To identify functions and how roles interact with
them – The primary purpose of use case diagrams.
For a high-level view of the system – Especially
You can highlight the roles that interact with the
system and the functionality provided by the system
without going deep into inner workings of the system.
To identify internal and external factors – This
might sound simple but in large complex projects a
system can be identified as an external role in
another use case.
 Use Case Diagram Components
 Before you draw usecase diagram you need to
first understand its building blocks.
 Common components include:
Actor
Use case
System
Package
 Actors
 Actors are the users of a system. Is any entity that
performs a role in a given system.
 An actor can be a person, an organization or an outside
system that interacts with your application or system.
 They must be external objects that produce or consume
data.
 This usually drawn like skeleton shown below.
 Use case
 Use cases are a set of actions, services, or functions
that the system needs to perform.
 We can say that use cases are system functionalities
written in an organized manner.
 You can describe each use case in details in SRS
documents. 
 Use cases deal only in the functional requirements
for a system.
 It is drawn as an oval and named with
the function.
 Label the usecase with verbs that represent the
system's functions.
 System
 A "system" is something being developed or
operated, such as a web site.
 The system is used to define the scope of the use
case and drawn as a rectangle.
 A system may also be referred to as a scenario.
 Draw your system's boundaries using a rectangle that
contains use cases.
 Place actors outside the system's
boundaries.
 Package (Optional)
 Packages enable you to organize model elements
(such as use cases) into groups.
 Packages are depicted as file folders
 The package is an optional element that is extremely
useful in complex diagrams.
 They are drawn like the image shown below.
 Relationships 
 There are five types of relationships in a use
case diagram.
Association between an actor and a use case
Generalization of an actor
Extend relationship between two use cases
Include relationship between two use cases
 Let’s take a look at these relationships in
detail.
 Associations between actors and
use cases
 Associations between actors and use cases are
indicated in use case diagrams by solid lines.
 An association exists whenever an actor is involved
with an interaction described by a use case.
 Associations are represented by a line between
actors and use cases.
 In a more complex diagram, it is important to know
which actors are associated with which use cases. In
the example above, the lines are simply drawn for
the sake of consistency.
 Few things to note.
An actor must be associated with at least one use
case.
An actor can be associated with multiple use
cases.
Multiple actors can be associated with a single
use case.
 Generalization of an Actor
 Generalization of an actor means that one actor can
inherit the role of the other actor.
 The descendant inherits all the use cases of the
ancestor.
 The descendant has one or more use cases that are
specific to that role.
 Let’s expand the previous
use case diagram to show
the generalization of an actor.
 Extend Relationship Between Two
Use Cases
 Many people confuse the extend relationship in use
cases.
 As the name implies it extends the base use case
and adds more functionality to the system.
 Few things to consider when using
the <<extend>> relationship
 The extending use case is dependent on the
extended (base) use case. E.g the “Calculate
Bonus” use case doesn’t make much sense without
the “Deposit Funds” use case.
 The extending use case is usually optional and
can be triggered conditionally. E.g you can see that
the extending use case is triggered only for deposits
over 10,000 or when the age is over 55.
 The extended (base) use case must be
meaningful on its own. This means it should be
independent and must not rely on the behavior of the
extending use case.
 Include Relationship Between Two Use
Cases
 Include relationship
show that the behavior
of the included use
case is part of the
including (base) use
case.
 The main reason for
this is to reuse the
common actions across
multiple use cases.
 In some situations, this
is done to simplify
complex behaviors.
Few things to consider when using the
<<include>> relationship.
 The base use case is incomplete without the
included use case.
 The included use case is mandatory and not
optional.
 Generalization of a Use Case
 This is used when there is common behavior
between two use cases and also specialized
behavior specific to each use case.
 The behavior of the ancestor is inherited by the
descendant.
 For example, in the previous banking example, there
might be a use case called “Pay Bills”. This can be
generalized to “Pay by Credit Card”, “Pay by Bank
Balance” etc.
 How to Create a Use Case Diagram
 Up to now, you’ve learned about objects,
relationships and guidelines that are critical when
drawing use case diagrams. I’ll explain the various
processes using a banking system as an example.
 Identifying Actors
 In a banking system, the most obvious actor is the
customer.
 Other actors can be bank employee or cashier depending
on the role you’re trying to show in the use case.
 An example of an external organization can be the tax
authority or the central bank.
 The loan processor is a good example of an external
system associated as an actor.
 How to Create a Use Case Diagram
 Identifying Use Cases
 A good way to identify what the actors need from the
system.
 In a banking system, a customer will need to open
accounts, deposit and withdraw funds, request check
books and similar functions. So all of these can be
considered as use cases.
 Top level use cases should always provide a
complete function required by an actor. You can
extend or include use cases depending on the
complexity of the system.
 Use Case Diagram Guidelines
 The following guidelines will help you to 
create better use cases that are appreciated by your
clients and peers.
 Actors -
Give meaningful business relevant names for
actors – For example if your use case interacts
with an outside organization it’s much better
name it with the function
rather than the organization
name. (Eg: Airline Company is
better than PanAir)
 Actor
Primary actors should be to the left side of the
diagram – This enables you to quickly highlight the
important roles in the system.
Actors model roles (not positions) – In a hotel both
the front office executive and shift manager can make
reservations. So something like “Reservation Agent”
should be used for actor name to highlight the role.
External systems are actors – If your use case is
send-email and if interacts with the email
management software then the software is an actor to
that particular use case.
Place inheriting actors below the parent actor –
This is to make it more readable and to quickly
highlight the use cases specific for that actor.
 Use Cases guideline
 Names begin with a verb – A use case models an action so
the name should begin with a verb.
 Make the name descriptive – This is to give more
information for others who are looking at the diagram. For
example “Print Invoice”  is better than “Print”.
 Highlight the logical order – For example if you’re
analyzing a bank customer typical use cases include open
account, deposit and withdraw. Showing them in the logical
order makes more sense.
 Place included use cases to the right of the invoking use
case – This is done to improve readability and add clarity.
 Place inheriting use case below parent use case – Again
this is done to improve the readability of the diagram.
 Relationships
 Arrow points to the base use case when using
<<extend>>
 <<extend>> can have optional extension
conditions
 Arrow points to the included use case when
using <<include>>
 Both <<extend>> and <<include>> are shown
as dashed arrows.
 Actor and use case relationship doesn’t show
arrows.
 Systems / Packages
 Use them sparingly and only when necessary
 Give meaningful and descriptive names to
these objects
 Following is a sample use case diagram representing
the order management system.
 The SpecialOrder and NormalOrder use cases are
extended from Order use case. Hence, they have
extended relationship.
 Another important point is to identify the system
boundary, which is shown
in the picture.
The actor Customer lies
outside the system as it
is an external user of the
system.