Requirement engineering

Requirement engineering is the process of collecting, validating and managing the

requirements essential for the development of the software, specified by the clients
or the end-users. This task is performed at the initial stages of software
development.
The requirement engineering process involves a team of software developers or
engineers, business analysts, customers and end-users. Requirement engineering
provides the basic idea to the software developer of what the client or the end-user
wants the software to do.
Requirement engineering is a process that is performed in the initial stages of any
software development. It includes analyzing the customer’s requirement and
various tasks such as:
 Analyze the requirements gathered from the customer.
 Evaluate the feasibility of the operational system.
 Propose some unambiguous solutions.
 Validate the requirement provided by the customer.
 Manage the requirements as far as they are modeled into an operational
system.

Importance of Requirement Engineering

Requirement engineering is an important stage in any software development. It is
also believed if the requirement engineering is done appropriately then we can
expect that the final software developed doesn’t lag behind in terms of design or
functionality leading to successful and profitable software. The requirement
engineering provides a vision of the final software i.e. what the software would do?
This creates a sense of mutual understanding between the customer and the
software developer.
Requirement engineering also helps in defining the scope of the software i.e. what
will be the functionalities of the final software.
It also helps in perceiving the cost of the final software.
It also helps in perceiving the schedule up to which the software will be delivered
to the customer.
Qualities of Requirements
The requirements collected from the customer must be precise and must convey
the customer need to the software developer. Quality requirements possess the
following features:
Complete: The specified requirements must be complete, there must be nothing
missing that is important for the development of the software.
Consistent: If the software requirements are provided by more than one customer.
Then the software engineer must ensure that the requirements provided by an
individual must not contradict the requirements provided by another customer.
Unambiguous: Each specified requirement must be unambiguous i.e. it must
specify a single meaning.
Functions: The requirement must specify what functions or computations must the
software perform and not how they must be implemented.
Concise: Each requirement must be specified only once and there should not be
duplication of any requirement statement.
Minimum: The specified requirements must not carry unnecessary details.
Understandable: The specified requirements must be understandable by both
customer and software developer.
Achievable: The requirement must be technically feasible.
Testable: It can be verified that the requirements are collected completely.
Types of Requirements
Requirements can be classified into the following ways:

1. Business Requirements:
Business requirements specify the software’s business demand. The business
requirement identifies why the software is required, who will be the end-users of
the software, how the software will benefit its end users. The business requirement
does specify the technicality of the software i.e. how it should be implemented it
focuses only on what software must do for them.
2. Users Requirements:
The user requirements specify the need and expectations of the end-users of the
software. Although the user’s requirement is sometimes incorporated with the
business requirements. But sometimes requirements of software with more
complex functionality or more complex user interface must be documented
separately.
3. Software Requirements:
The software requirements specify what the software must do and it define how
the software is expected to perform. Type of software requirement are as follow:
Functional: The functional requirements describe what the software must deliver
and what it must not. How the software must respond to incorrect inputs. Thus, the
functional requirement describes the behaviour of the software.
Non-Functional: The non-functional requirements describe the non-behavioural
aspects of the system such as its scalability, reliability, performance, security, its
portability, reusability and flexibility.
Domain Requirements: The domain requirement describes the realm, area, group
for which the software is to be developed. Such as for college, office, military,
hospital, students, teachers, patients etc.

Requirement Engineering Process:

The requirement engineering process involver certain steps that must be followed
to collect the entire specifications about the project.
1. Inception:
In the inception phase we how the concept of the software has evolved. Does there
was any catalyst event that triggered the need for the software or its need has
evolved over time? Although there is no precise answer to this question the
conversation starts with these basic questions.
In the inception phase, the business requirements are identified where first the
business need is identified, the scope of the software in the market is analysed, a
rough feasibility analysis is done and the functioning of the software is discussed.
Though all these requirements are subject to change they are enough to start a
conversation between business analysts or customers or stakeholders and the
software developers.
2. Requirement Elicitation:
If the inception report is positive to undertake the project the next step is to gather
the requirement from the clients. This phase is the requirement elicitation phase
where the system analyst or the software developers communicate with the clients
or the end-users of the system to elicit more information.
There are many things that the software analyst comes across while eliciting the
requirements such as:
 The problem statement defined by the client or the end-user may have ill-defined
boundaries or the technical details provided by them might confuse the analyst or
the developer regarding the objective of the software to be developed.
Even the clients or the end-user of the software are not sure about what they want.
They are unaware of the potential of their computing environment and even find it
difficult to convey the problem statement to the software engineer.
In some cases, the client or end-user misses the most important information to
convey to the software engineer or provide ambiguous requirements.
Sometimes the requirements of the clients or users change with time which raises
confusion among the software developers.
3. Requirement Specification:
In terms of the software, the requirement specification can be a written document,
a mathematical model, graphical models, some usage scenarios, some sort of
sample model, some sort of code etc.
4. Negotiating Requirements:
Now each client associated with the same project might have different versions of
requirements and they think that their aspect is more useful to develop software.
Observing the conflicting requirements, the software engineer has to reconcile and
negotiate the facts with the clients and end-users.
Negotiation is an iterative process where each client is asked to rank the
requirement in terms of priority. Parallelly the software engineer also assesses the
cost associated with the project, risk factors.
While addressing the conflicting requirements they may eliminate, add, combine or
modify the conflicting requirements so that each client sense some sort of
satisfaction that their requirements are essential for the development of the
software.
5. Requirement Validation:
Whatever is gathered, understood during the process of the requirement of
engineering must be validated to ensure that all the software requirements are
specified. The software developer or engineer must also ensure that the
requirements are unambiguous, correct, consistent, and essential.
The requirement validation phase requires the presence of all like software
developers, clients, end-users and stakeholders. The specified requirements are
checked thoroughly for any missing, redundant, inconsistent information.

6. Requirement Management:
Requirements of any software keep on changing and the business and technical
change throughout the life of the software. Requirement management is subject to
keep track of the requirements and the changes that occur during the development
of the software.
So, these are the steps or tasks that must be performed in the requirement
engineering process. The efficient requirement engineering promises that
developed software satisfies each requirement specified and up to the standards.

Requirements analysis
Requirements analysis is a set of operations that helps define users' expectations of
the application you are building or modifying. Software engineering professionals
sometimes call it requirement engineering, requirements capturing or requirement
gathering. The process involves analyzing, documenting, validating and managing
system or software requirements. Requirements analysis involves various tasks that
help engineers understand stakeholder demands and explain them in simple and
visual ways. It is essential to a software or system project's success.

A software requirement is something a user needs to achieve an objective. It refers

to a system or component's ability to perform a task according to its contract or
formal documentation. Requirements help teams identify business opportunities
and facilitate system design. For a project to be successful, its requirements must
be:

 Testable
 Actionable
 Documented
 Measurable
 Traceable
Requirements analysis is a team effort that needs cooperation, time and
communication. It involves various stakeholders, such as project sponsors,
throughout the project as well as end users whose inputs are most important.

Project sponsors have expectations and want the system to meet certain business
objectives. The customers or users are the ones working with the delivered
product. They can explain their needs and help reduce project costs or save time by
giving feedback about the technical parts of the requirements. The best results
typically occur when all parties work together to develop a high-quality
requirements document.
Steps to complete a software requirements analysis:
1. Gather the requirements
Communicate with users to gather the requirements. This phase is also known as
"eliciting requirements." Analysts can use different techniques to gather the
requirements, including:
 Doing interviews
 Observing the workplace
 Holding focus groups or workshops
 Creating requirements lists
Customers should agree that the requirements document describes a product that
meets their needs.
2. Analyze the requirements
Evaluate system feasibility, and confirm with the quality assurance team that the
requirements are testable. The developers make sure the requirements are
achievable and understandable. Determine if the listed requirements are
contradictory, incomplete, unclear or ambiguous, and solve those problems. The
goal of this phase is to decompose, analyze and detail the requirements across the
system's design. Here are the attributes of good requirements to help you study and
define your list:

 Unique
 Necessary
  Consistent
 Clear and concise
 Able to be validated
 Complete
 Technically feasible
 Traceable
 Verifiable
 Quantifiable
 Verifiable
 Operationally effective
3. Improve the quality of the requirements
Improve the requirements' quality using these methods:
Visualization: Use tools such as visualization and simulation that allow
stakeholders to better understand the desired end product.
Document dependencies: Document relationships and dependencies among
requirements and any assumptions.
Consistent use of templates: Produce consistent templates and models to document
the requirements.
4. Model the requirements
Take the time to create models of the requirements. These figures help
stakeholders and customers visualize the potential system. Present requirements
using flowcharts, graphs or models to ensure the system corresponds to the
business's needs.
5. Document and review the requirements
Record the requirements in a document that is easy for both developers and users
to understand. Note the changes your team makes to the requirements throughout
the process. You can document the requirements in various formats, including:
 Software requirements specification (SRS)
 User cases
 Natural-language documents
 User stories
 Process specification
Then, review previous versions of the requirements analysis and connect objectives
with specific actions you can take to improve the process.
Types of requirements analysis
Common requirements analysis techniques include:
Gap analysis
Gap analysis involves comparing the desired business goal to the baseline. It
studies what the business is currently doing and what it wants to achieve. Analysts
perform this investigation to identify gaps in performance and find ways to
optimize it. A gap analysis defines things like the current state of the project and
where the company wants to be. It gives the business a better understanding of how
it can improve.
Business process modeling notation (BPMN)
Business process modeling notation is a popular method for improving processes.
The technique is similar to creating process flowcharts but with a set of elements
and symbols specific to BPMN. It allows teams to create graphs that simplify their
understanding of the business process.
Flowchart technique
The flowchart technique describes the sequential control logic and sequential flow
of a group of related activities. Flowcharts can represent system interactions or
data flow, for instance. They are easy for both technical and nontechnical team
members to understand. Flowcharts come in multiple formats, including top-down,
cross-functional and linear.
Unified modeling language (UML)
The unified modeling language is a set of diagrams that helps teams visualize,
specify, build and document a software system's characteristics. UML provides a
standardized method for visualizing a system's design. It uses diagrams that
represent data such as structural information, behaviors and interactions within the
software. The UML technique helps validate the architectural software design.
Role activity diagrams (RAD)
A role activity diagram is a modeling technique showing the roles people play in
each step of the development process. It uses diagrams to capture an organization's
structure and dynamics. RAD groups software development activities by the tasks
each role performs.
Integrated definition for function modeling (IDEF)
Integrated definition for function modeling uses a box to display a process's
functions. It also shows the relationships between parent and child systems. IDEF
creates a blueprint that helps stakeholders understand the organization's system.
Gantt charts
Gantt charts provide visual representations of scheduled tasks and timelines. This
technique allows teams to visualize the start and end dates of every project task in
one view. It helps team members know what to complete by what date.
Data flow diagram
This technique uses visuals to display processes and systems that are difficult to
explain in words. Data flow diagrams show the flow of information through a
system or method. It explains the relationships between tasks or items using
symbols and notations. By visualizing all the system's elements, teams can better
identify possible deficiencies.

Fact-Finding Techniques
Fact-finding techniques are a process of collection of data and information based
on techniques that contain a sampling of existing documents, research, observation,
questionnaires, interviews, prototyping, and joint requirements planning. System
analyst uses suitable fact-finding techniques to develop and implement the current
existing system. Collecting required facts are very important to apply tools in
System Development Life Cycle because tools cannot be used efficiently and
effectively without proper extracting from facts.
Fact-finding techniques are used in the early stage of the System Development
Life Cycle including the system analysis phase, design, and post-implementation
review. Facts included in any information system can be tested based on three
steps: data facts used to create useful information, process- functions to perform
the objectives, and interface- designs to interact with users.
Seven common fact-finding techniques are:
 A sampling of existing documentation, forms, and databases
 Research and Site visits
  Observation of the work environment
 Questionnaires
 Interviews
 Prototyping
 Joint requirements planning
A sampling of existing documentation, forms, and databases:
The best way to analyze the existing system is to collect facts from existing
documentation rather than from human sources. There are various kinds of
documents to collect facts from existing documents. These include e-mails,
customer complaints, suggestion box notes, and reports that document the problem
area problem performance reviews, samples of completed manual forms and
reports, and samples of completed computerized forms and reports various types of
flowcharts and diagrams, program documentation, and user training manuals.
System analyst uses sampling techniques in order to organize the above
documentation. The sampling technique is the process of combing a representative
sample of documents, forms, and records.
Research and Site visits:
Research and site visits, the second technique, is the process of examining the
problems which had previously solved by other sources that can be either human or
documents. To solve the requirements of the problem, the analyst visits other
organizations that had previously experienced similar problems. In addition, the
analyst can also find the information from the database, reference books, case
studies, and the Internet.
Observation of the work environment:
Another fact-finding technique is observation. In this technique, the system analyst
participates in the organization, studies the flow of documents, applies the existing
system, and interacts with the users. Observation can be a useful technique when
the system analyst has a user point of view. A sampling technique called work
sampling is useful for observation. By using this technique, system analysts can
know how employees spend their days.
Questionnaires:
Questionnaires are also one of the useful fact-finding techniques to collect
information from a large number of users. Users fill up the questions which are
given by the system analyst and then give the answers back to the system analyst.
Questionnaires can save time because the system analyst does not need to
interview each of the users and if the time of the interview is short, questionnaires
are more useful. To fulfill the requirements of the system objective, a system
analyst should have the ability to clearly define the design and frame of
questionnaires.
There are two types of questionnaires:
Free-format questionnaires
In free format questionnaires, users are allowed to answer questions freely without
an immediate response. The results are also useful in learning about the feelings,
opinions, and experiences of the respondents.
Fixed-format questionnaires
The purpose of fixed-format questionnaires is to gather information from the
predefined format of questions. Users are allowed to choose the result from the
given answers. There are three types of fixed-format questions: multiple-choice
questions (Yes or No type), rating questions (Strongly Agree, Agree, No opinion,
Disagree, Strongly disagree), ranking questions.
Interviews:
An interview is the most commonly used technique to collect information from the
face to face interviews. The purpose of the interview is to find, verify, clarify facts,
motivate end-users involved, identify requirements, and gather ideas and opinions.
The role of the interview includes the interviewer who is a system analyst and the
interviewee who is a system owner or user. The interviewing technique needs good
communication skills for interaction between system analysts and users.
There are two types of interviews.
Unstructured interviews
An interview that is conducted with only a general goal or subject in mind and with
few, if any, specific questions. The open-ended questions type is used in an
unstructured interview that allows the user to answer freely in an appropriate way.
Structured interviews
A structured interview is an interview that contains a predefined set of questions.
In a structured interview, close-ended questions type is used to limit answers to
specific choices, short and direct responses from the interviewees.
Prototyping:
Another fact-finding technique is known as prototyping which collects the
requirement facts of the system. Prototyping is sampling a small working model
and it is more related to the pre-design of the information system. The
implementation of prototyping can be developed in an earlier stage of the system
development life cycle when analyzing the facts. The process of prototyping facts
in order to specify the users’ requirements is also known as discovery prototyping.
Joint requirements planning:
JRP is the structured group work meeting to identify, analyze problems, and define
the requirements of the system. JRP is becoming increasingly common in systems
planning and systems analysis to obtain group consensus on problems, objectives,
and requirements. JRP can tabulate the facts efficiently in a short time and it can
also replace in the place of numerous and separate interviews. JRP contains
different participants with each specialized role to perform structured meetings.
JRP participants include sponsors, facilitators, users and managers, scribes, and IT
staff. The sponsor is an individual in top management, who has full authority to
decide who will be participants, the time, and location of the JRP session. The role
of a facilitator is to lead the JRP session, motivate participants, solve conflicts and
meet the requirements of meeting during the JRP session. Users in the JRP session
are responsible for the rules and requirements of a business, prototype, and
satisfactory decisions. And Managers are responsible for projects, schedules, and
costs, and training requirements. The scribe’s job is to record everything discussed
in the meeting. IT staff responsible for models and documentation concerning facts
during the discussion.

Feasibility Study
As the name implies, a feasibility analysis is used to determine the viability of an
idea, such as ensuring a project is legally and technically feasible as well as
economically justifiable. It tells us whether a project is worth the investment—in
some cases, a project may not be doable. There can be many reasons for this,
including requiring too many resources, which not only prevents those resources
from performing other tasks but also may cost more than an organization would
earn back by taking on a project that isn’t profitable.
Types of Feasibility Study
A feasibility analysis evaluates the project’s potential for success; therefore,
perceived objectivity is an essential factor in the credibility of the study for
potential investors and lending institutions. There are five types of feasibility
study—separate areas that feasibility study examines, described below.
1. Technical Feasibility
This assessment focuses on the technical resources available to the organization. It
helps organizations determine whether the technical resources meet capacity and
whether the technical team is capable of converting the ideas into working systems.
Technical feasibility also involves the evaluation of the hardware, software, and
other technical requirements of the proposed system. As an exaggerated example,
an organization wouldn’t want to try to put Star Trek’s transporters in their
building—currently, this project is not technically feasible.
2. Economic Feasibility
This assessment typically involves a cost/ benefits analysis of the project, helping
organizations determine the viability, cost, and benefits associated with a project
before financial resources are allocated. It also serves as an independent project
assessment and enhances project credibility—helping decision-makers determine
the positive economic benefits to the organization that the proposed project will
provide.
3. Legal Feasibility
This assessment investigates whether any aspect of the proposed project conflicts
with legal requirements like zoning laws, data protection acts or social media laws.
Let’s say an organization wants to construct a new office building in a specific
location. A feasibility study might reveal the organization’s ideal location isn’t
zoned for that type of business. That organization has just saved considerable time
and effort by learning that their project was not feasible right from the beginning.
4. Operational Feasibility
This assessment involves undertaking a study to analyze and determine whether—
and how well—the organization’s needs can be met by completing the project.
Operational feasibility studies also examine how a project plan satisfies the
requirements identified in the requirements analysis phase of system development.
5. Scheduling Feasibility
This assessment is the most important for project success; after all, a project will
fail if not completed on time. In scheduling feasibility, an organization estimates
how much time the project will take to complete.
When these areas have all been examined, the feasibility analysis helps identify
any constraints the proposed project may face, including:
Internal Project Constraints: Technical, Technology, Budget, Resource, etc.
Internal Corporate Constraints: Financial, Marketing, Export, etc.
External Constraints: Logistics, Environment, Laws, and Regulations, etc.
Need of Feasibility Study:
Feasibility study is so important stage of Software Project Management Process as
after completion of feasibility study it gives a conclusion of whether to go ahead
with proposed project as it is practically feasible or to stop proposed project here as
it is not right/feasible to develop or to think/analyze about proposed project again.
Along with this Feasibility study helps in identifying risk factors involved in
developing and deploying system and planning for risk analysis also narrows the
business alternatives and enhance success rate analyzing different parameters
associated with proposed project development.

Data Analysis
Data analysis is defined as a process of cleaning, transforming, and modeling data
to discover useful information for business decision-making. The purpose of Data
Analysis is to extract useful information from data and taking the decision based
upon the data analysis.
A simple example of Data analysis is whenever we take any decision in our day-to-
day life is by thinking about what happened last time or what will happen by
choosing that particular decision. This is nothing but analyzing our past or future
and making decisions based on it. For that, we gather memories of our past or
dreams of our future. So that is nothing but data analysis. Now same thing analyst
does for business purposes, is called Data Analysis.
If your business is not growing, then you have to look back and acknowledge your
mistakes and make a plan again without repeating those mistakes. And even if your
business is growing, then you have to look forward to making the business to grow
more. All you need to do is analyze your business data and business processes.
Data analysis tools make it easier for users to process and manipulate data, analyze
the relationships and correlations between data sets, and it also helps to identify
patterns and trends for interpretation. Here is a complete list of tools used for data
analysis in research.
Types of Data Analysis:
There are several types of Data Analysis techniques that exist based on business
and technology. However, the major Data Analysis methods are:

 Text Analysis
 Statistical Analysis
 Diagnostic Analysis
 Predictive Analysis
 Prescriptive Analysis
Text Analysis
Text Analysis is also referred to as Data Mining. It is one of the methods of data
analysis to discover a pattern in large data sets using databases or data mining
tools. It used to transform raw data into business information. Business Intelligence
tools are present in the market which is used to take strategic business decisions.
Overall it offers a way to extract and examine data and deriving patterns and
finally interpretation of the data.
Statistical Analysis
Statistical Analysis shows “What happen?” by using past data in the form of
dashboards. Statistical Analysis includes collection, Analysis, interpretation,
presentation, and modeling of data. It analyses a set of data or a sample of data.
There are two categories of this type of Analysis – Descriptive Analysis and
Inferential Analysis.
Descriptive Analysis
Analyses complete data or a sample of summarized numerical data. It shows mean
and deviation for continuous data whereas percentage and frequency for
categorical data.
Inferential Analysis
analyses sample from complete data. In this type of Analysis, you can find
different conclusions from the same data by selecting different samples.
Diagnostic Analysis
Diagnostic Analysis shows “Why did it happen?” by finding the cause from the
insight found in Statistical Analysis. This Analysis is useful to identify behavior
patterns of data. If a new problem arrives in your business process, then you can
look into this Analysis to find similar patterns of that problem. And it may have
chances to use similar prescriptions for the new problems.
Predictive Analysis
Predictive Analysis shows “what is likely to happen” by using previous data. The
simplest data analysis example is like if last year I bought two dresses based on my
savings and if this year my salary is increasing double then I can buy four dresses.
But of course it’s not easy like this because you have to think about other
circumstances like chances of prices of clothes is increased this year or maybe
instead of dresses you want to buy a new bike, or you need to buy a house!
So here, this Analysis makes predictions about future outcomes based on current or
past data. Forecasting is just an estimate. Its accuracy is based on how much
detailed information you have and how much you dig in it.
Prescriptive Analysis
Prescriptive Analysis combines the insight from all previous Analysis to determine
which action to take in a current problem or decision. Most data-driven companies
are utilizing Prescriptive Analysis because predictive and descriptive Analysis are
not enough to improve data performance. Based on current situations and
problems, they analyze the data and make decisions.
Data Analysis Process
The Data Analysis Process is nothing but gathering information by using a proper
application or tool which allows you to explore the data and find a pattern in it.
Based on that information and data, you can make decisions, or you can get
ultimate conclusions.
Data Analysis consists of the following phases:
 Data Requirement Gathering
 Data Collection
 Data Cleaning
 Data Analysis
 Data Interpretation
 Data Visualization
Data Requirement Gathering
First of all, you have to think about why do you want to do this data analysis? All
you need to find out the purpose or aim of doing the Analysis of data. You have to
decide which type of data analysis you wanted to do! In this phase, you have to
decide what to analyze and how to measure it, you have to understand why you are
investigating and what measures you have to use to do this Analysis.
Data Collection
After requirement gathering, you will get a clear idea about what things you have
to measure and what should be your findings. Now it’s time to collect your data
based on requirements. Once you collect your data, remember that the collected
data must be processed or organized for Analysis. As you collected data from
various sources, you must have to keep a log with a collection date and source of
the data.
Data Cleaning
Now whatever data is collected may not be useful or irrelevant to your aim of
Analysis, hence it should be cleaned. The data which is collected may contain
duplicate records, white spaces or errors. The data should be cleaned and error
free. This phase must be done before Analysis because based on data cleaning,
your output of Analysis will be closer to your expected outcome.
Data Analysis
Once the data is collected, cleaned, and processed, it is ready for Analysis. As you
manipulate data, you may find you have the exact information you need, or you
might need to collect more data. During this phase, you can use data analysis tools
and software which will help you to understand, interpret, and derive conclusions
based on the requirements.
Data Interpretation
After analyzing your data, it’s finally time to interpret your results. You can choose
the way to express or communicate your data analysis either you can use simply in
words or maybe a table or chart. Then use the results of your data analysis process
to decide your best course of action.
Data Visualization
Data visualization is very common in your day to day life; they often appear in the
form of charts and graphs. In other words, data shown graphically so that it will be
easier for the human brain to understand and process it. Data visualization often
used to discover unknown facts and trends. By observing relationships and
comparing datasets, you can find a way to find out meaningful information.

Cost/Benefit Analysis
Cost Benefit analysis is thing that everyone must do so as to think of a powerful or
an efficient system. But while thinking out on cost and benefit analysis, we also
need to find out factors that really affect benefits and costs of system. In
developing cost estimates for a system, we need to consider some of cost elements.
Some elements among them are hardware, personnel, facility, operating and supply
cost. The following are the cost factors:
Hardware cost –
Hardware cost includes actual purchase and peripherals (external devices) that are
connected to computer. For example, printer, disk drive etc. Actually, finding
actual cost of hardware is generally more difficult especially, when system is
shared by various users so as to compared to a system which dedicated stand alone.
In some case, best way is to treat it as operating cost.
Personnel costs –
Personnel costs includes EDP staff salaries and benefits as well as pay for those
who are involved in process of development of system. Cost occurred during
development of system which are one time costs and are also called development
cost. Once system is installed, cost of operating and maintaining system becomes
recurring cost that one has to pay very frequently based on requirement.
Facility cost –
Facility cost is amount of money that is spent in preparation of a site that is
physical where application or computer will be in operation. This includes wiring,
flooring, lighting and air conditioning. These costs are treated as one- time costs
and are included into overall cost estimate of candidate system.
Operating costs –
These includes all costs associated with day-to-day(everyday) operation of system
and amount depends on number of shifts, nature of applications. There are various
ways of covering operating costs. One approach is to treat operating costs as an
overhead. Another approach is to charge money from each authorized user for
amount of processing they require from system. Amount charged is based on
computer time or time they spend on system, staff time ad volume of output
produced .
Supply costs –
Supply cost are variable costs that increase with increased use of paper, disks and
like. They should be estimated and included in overall cost of system.
A system is also expected to provide health benefits. First task is to identify each
benefit and then assign some value to it for purpose of cost/ benefit analysis.
Benefits may be tangible and intangible, direct or indirect.
Benefits
Direct Benefits:
The measurable benefits in monetary value that you get from the project. In this
case, the revenue, sales and profit obtained from your product.
Indirect Benefits:
Benefits that you can perceive but not necessarily measure such as increased brand
awareness.
Tangible benefits
 Revenue increase
 Resource cost savings
 Increased productivity
 Process improvements

Intangible benefits
 Organizational strategy support
 Enhanced user experience
 Increased customer satisfaction
 Greater compliance
 Brand equity

Two major benefits are improving performance and minimizing cost of

processing of system. The performance category emphasizes improvement in
accuracy of or access to information and easier access to system by authorized
users. 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.

The determination of costs and benefit entails following steps:

 Identify the costs and benefits pertaining to given project.
 Categorize the various costs and benefits for analysis.
 Select a method of evaluation.
 Interpret the results of the analysis.
 Take action.