Unit – 3

Analysis

02/20/2021 1
a. System Requirements

02/20/2021 2
• A software requirement is a capability needed by the user to solve a problem or to achieve an objective.
• In other words, requirement is a software capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed documentation.
• Ultimately, what we want to achieve is to develop quality software that meets customers' real needs on
time and within budget.
• Perhaps the greatest challenge being faced by software developers is to share the vision of the final
product with the customer.
• All stakeholders in a project - developers, end users, software managers, customer managers - must
achieve a common understanding of what the product will be and do, or someone will be surprised when
it is delivered. Surprises in software are almost never good news.
• Therefore, we need ways to accurately capture, interpret, and represent the voice of customers when
specifying the requirements for a software product.

02/20/2021 3
• Activities for Requirement Analysis
• Requirements analysis is critical to the success or failure of a systems or software project.
• The requirements should be documented, actionable, measurable, testable, traceable, related
to identified business needs or opportunities, and defined to a level of detail sufficient for
system design. Conceptually, requirements analysis includes four types of activity:
• Eliciting requirements: the task of communicating with customers and users to determine what
their requirements are. This is sometimes also called requirements gathering.
• Analyzing requirements: determining whether the stated requirements are unclear, incomplete,
ambiguous, or contradictory, and then resolving these issues.
• Requirements modeling: Requirements might be documented in various forms, such as natural-
language documents, use cases, user stories, or process specifications.
• Review and retrospective: Team members reflect on what happened in the iteration and
identifies actions for improvement going forward.

02/20/2021 4
• Requirements analysis is a team effort that demands a combination of
hardware, software and human factors engineering expertise as well as skills
in dealing with people. Here are the main activities involve in requirement
analysis:
• Identify customer's needs.
• Evaluate system for feasibility.
• Perform economic and technical analysis.
• Allocate functions to system elements.
• Establish schedule and constraints.
• Create system definitions.
02/20/2021 5
Requirement Analysis Techniques

• Requirement analysis helps organizations to determine the actual needs of

stakeholders.
• At the same time, it enables the development team to communicate with stakeholders
in a language they understand (like charts, models, flow-charts,) instead of pages of
text.
• Once the requirements are gathered, we document the requirements in a Software
Requirements Specification (SRS) document, use cases or as User Stories, which are
shared with the stakeholders for approval.
• This document is easy to understand for both normal users and developers.
• Any changes in the requirements are also documented and go through a change control
procedure and finalized on approval.

02/20/2021 6
Business Requirement vs Software
Requirements
• A business plan or project requires a variety of requirements to help define goals and establish a scope for the work
that will be undertaken. Requirements also provide context and objective ways to measure progress and success.
Once business requirements are established, software requirements are defined and developed in order to move a
project forward.
• Business Requirements
Business requirements relate to a business' objectives, vision and goals. They also provide the scope of a business
need or problem that needs to be addressed through a specific activity or project. For example, if a trade association
has an objective to promote the services offered by its members, the business requirements for a project might
include creating a member directory that increases awareness of members. Good business requirements must be:
Clear and are typically defined at a very high level.
Provide enough information and guidance to help ensure that the project fulfils the identified need.
• Understanding an organization's mandate, objectives or goals, a specific business need or problem that is being tackled
• Should be clearly defined and understood before developing business requirements.
The need or problem can relate to the organization or business in general or focus on a stakeholder group, such as customers, clients,
suppliers, employees or another group.

02/20/2021 7
• Software Requirements
• Software requirements break-down the steps needed to meet the
business requirement or requirements. Whereas a business
requirement states the 'why' for a project, a software requirements
outline the 'what'.
• For example, if the business requirement is to create a member
directory for a trade association, the software requirements will outline
who has access to the directory, how member register with the
directory, who will have ownership of the data, what vehicle or vehicle
will be used such as a website or paper-based directory, and so on.

02/20/2021 8
• Techniques for Discovering Business Needs
• There are various requirement analyzing techniques that can be used as per the
business improvement and software development process. Listed below are some of
these techniques.
• Gap Analysis Using BPMN(Business Process modelling notation) or ArchiMate
• A gap is often said to be "the space between where you are and where you want to be".
Gap analysis is a comparison process between baseline and target business scenario. In
other words, gap analysis is the study of what a business is doing currently and where it
wants to go in the future, and is undertaken as a means of bridging the space between
them. The goal of the gap analysis is to identify gaps in optimizing performance. This
provides a business with insight into potential improvement. It answers questions like
what is the current state of the project? Where do we want to be? etc.

02/20/2021 9
• ArchiMate - Gap Analysis
• ArchiMate is an open and independent enterprise architecture modeling language to
support the description, analysis and visualization of architecture within and across
business domains in an unambiguous way. It's a perfect modeling tool and with the
required notation to perform gap analysis.
• BPMN(Business Process modelling notation) - As-is and To-be Analysis
• As-is Process
• The example to demonstrate is about current situation (as-is process) of an online shop
that sells goods. The process begins with the sales representative receives a purchase order
from a customer and proceeds to check the stock level. If there is enough stock on hand to
meet with the order, the sales representative will pack them. The process ends with
shipping them along with an invoice. In case of insufficient stock, the sales representative
will suggest the customer to amend the purchase order.

02/20/2021 10
02/20/2021 11
• To-be Process
• Let's just say that our business has grown so much that we now have
a warehouse to keep our stocks. So we are looking for ways to
improve our current (as-is) process to better allocate the new
resources. Furthermore, we will show an example of modeling the
enhancement below in a to-be process diagram.

02/20/2021 12
02/20/2021 13
• Business Motivation Model
• If an enterprise prescribes a certain approach for its business activity, it ought to be able to say
why and what result(s) is the approach meant to achieve. The Business Motivation Model (BMM)
 is modeling notation for support of business decisions about how to react to a changing world.
• An enterprise would use it by acquiring a BMM modeling tool and then creating its own BMM -
populating the model with business information specific to the enterprise. There are two broad
purposes:
To capture decisions about reaction to change and the rationale for making them, with the intent
of making them shareable, increasing clarity and improving decision-making by learning from
experience.
To reference the outcomes of the decisions to their effect on the operational business (e.g.
changes made to business processes and organization responsibilities), providing traceability from
influencer to operational change.

02/20/2021 14
02/20/2021 15
• End - define what an enterprise wants to be - the states it desires to
be in.
• Means - define what an enterprise has decided it needs to do to
achieve its ends.
• Influencer - is something that an enterprise decides might affect it.
• Assessment - When an influencer causes a significant change, the
enterprise makes an assessment of its impact, identifying risks and
potential rewards. There may be multiple assessments, perhaps from
different stakeholders.

02/20/2021 16
• Customer Journey Mapping
• Customer Journey Map is a powerful technique for understanding what motivates your customers - what
their needs are, their hesitations, and concerns. Although most organizations are reasonably good at
gathering data about their customers, data alone fails to communicate the frustrations and experiences
the customer experienced. A story can do that, and one of the best storytelling tools in business is the
customer journey map.
• Customer journey map uses storytelling and visuals to illustrate the relationship a customer has with a
business over a period of time. The story is being told from the perspective of customer, which provides
insight into the total experience of the customer.
• It helps your team better understand and address customer needs and pain points as they experience
your product or service.
• In other words, mapping out the customer journey offers your business the chance to see how your brand
first engages a potential customer, and then moves through the touch points of the entire sales process.
• Finally, the team can propose the improvement or actions to be taken against each of the touch points.
These proposed actions can be potential source of software requirements.

02/20/2021 17
02/20/2021 18
• Techniques for Identifying Software Requirements from Business Needs
• Data Flow Diagram
• A Data Flow Diagram (DFD) can be designed early in the requirement elicitation
process of the analysis phase within the SDLC (System Development Life Cycle) to
define the project scope. A DFD is often used as a preliminary step to create an
overview of the system without going into great detail, which can later be
elaborated.
• For instance, if there is a need to show more detail within a particular process, the
process is decomposed into a number of smaller processes in a lower level DFD. In
this way, the Content Diagram or Context-Level DFD is labeled a "Level-0 DFD"
while the next level of decomposition is labeled a "Level-1 DFD", the next is
labeled a "Level-2 DFD", and so on.
02/20/2021 19
02/20/2021 20
• Data flow diagram
Data flow diagrams are the most commonly used way of documenting the process of current & required
systems. As their name suggests they are a pictorial way of showing the flow of data into, around & out of a
system.
• Defining DFD
Graphical representation of a system’s data and how the processes transform the data is known as Data Flow
Diagram (or DFD). Unlike, flowcharts, DFDs do not give detailed descriptions of modules but graphically
describe a system’s data and how the data interact with the system.
• Components of DFD
DFDs are constructed using four major components
• external entries
• data stores
• processes and
• data flows

02/20/2021 21
(i) External Entities
External entities represent the source of data as input to the system.
They are also the destination of system data. External entities can be
called data stores out side the system. These are represented by
squares.
(ii) Data Stores
Data stores represent stores of data within the system. Examples,
computer files or databases. An open-ended box represents a
data/store – data at rest or a temporary repository of data.

02/20/2021 22
(iii) Process
Process represents activities in which data is manipulated by being stored
or retrieved or transferred in some way. In other words we can say that
process transforms the input data into output data. Circles stand for a
process that converts data into information.
(iv) Data Flows
Data flows represents the movement of data from one component to the
other. An arrow identifies data flow – data in motion. It is a pipeline
through which information flows... Data flows are generally shown as one-
way only. Data Flows between external entities are shown as dotted lines.

02/20/2021 23
• Physical & Logical DFD
• Consider the figure 1 It is clear from the figure that orders are placed,
orders are received, the location of ordered parts is determined and
delivery notes are dispatched along with the order.
• It does not however tell us how these things are done or who does
them. Are they done by computers or manually and if manually who
does them ? A logical DFD of any information system is one that
models what occurs without showing how it occurs.

02/20/2021 24
• A physical DFD shows, how the various functions are performed? Who
does them? Consider the following figure:

02/20/2021 25
• The figure 2 is opposite, it shows the actual devices that perform the
functions. Thus there is an "order processing clerk", an "entry into
computer file" process and a "run locate program“ process to locate
the parts ordered.
• DFD(s) that shows how things happen, or the physical components
are called physical DFD(s).
• Typical processes that appear in physical DFDs are methods of data
entry, specific data transfer or processing methods.

02/20/2021 26
• Use Cases
• A UML(unified modeling language) use case diagram is the primary form of system/software
requirements for a new software program under developed. Use cases specify the expected
behavior (what), and not the exact method of making it happen (how).
• Use cases once specified can be denoted both textual and visual representation (such as UML). A
key concept of use case modeling is that it helps us design a system from end user's perspective.
It is an effective technique for communicating system behavior in the user's terms by specifying
all externally visible system behavior.
• A use case diagram is usually simple. It does not show the detail of the use cases.
• It only summarizes some of the relationships between use cases, actors, and systems.
• It does not show the order in which steps are performed to achieve the goals of each use case.
• A standard form of use case diagram is defined in the Unified Modeling Language as shown in
the Use Case Diagram example below:

02/20/2021 27
02/20/2021 28
• User Stories
• A user story is a note that captures what a user does or needs to do as part of
his/her work. Each user story consists of a short description written from user's
point of view, with natural language.
• Unlike the traditional requirement capturing, user story focuses on what the
user need instead of what the system should deliver.
• This leaves room for further discussion of solutions and the result of a system
that can really fit into the customers' business workflow, solving their
operational problems and most importantly adding value to the organization.
• User stories are well compatible with the other agile software development
techniques and methods, such as scrum and extreme programming.
02/20/2021 29
User Stories vs Use Cases - The Similarity
• If we consider the key component in both approaches:
• User Stories contain, with user role, goal and acceptance criteria.
• Use Cases contain equivalent elements: an actor, flow of events and post conditions
respectively (a detailed Use Case template may contain many more other elements).
User Stories vs Use Cases - The Difference
• The details of a User Story may not be documented to the same extreme as a Use Case.
• User Stories deliberately leave out a lot of important details. User Stories are meant to
elicit conversations by asking questions during scrum meetings.
• Small increments for getting feedback more frequently, rather than having more
detailed up-front requirement specification as in Use Cases.

02/20/2021 30
The Agile Approach

Business analysis is so important to agile development projects that we're prepared to do it

every day throughout the lifecycle, it's not just a phase that we go through early in the project.
Agile Model Driven Development (AMDD) includes several best practices [1] which are pertinent
to understanding how business analysis fits into an agile project. These practices are:
• Active stakeholder participation. Stakeholders should provide information in a timely manner,
make decisions in a timely manner, and be as actively involved in the development process
through the use of inclusive tools and techniques.
• Prioritized requirements. Agile teams implement requirements in priority order, as defined by
their stakeholders, so as to provide the greatest return on investment (ROI) possible.
• Model a bit ahead. Sometimes requirements that are nearing the top of your priority stack are
fairly complex, motivating you to invest some effort to explore them before they're popped off
the top of the work item stack so as to reduce overall risk. This should be a rare event, but does
occur from time to time.

02/20/2021 31
• Requirements envisioning. At the beginning of an agile project you will need to invest some time to identify the
scope of the project and to create the initial prioritized stack of requirements. This effort should take a few days,
up to two weeks, assuming you can overcome the logistical challenges associated with getting the right people
involved.
• Iteration modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration
planning activities.
• Model storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to
explore the details behind a requirement or to think through a design issue.
• Test-driven development (TDD). Write a single test, either at the requirements or design level, and then just
enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory
approach to testing.
• AMDD promotes an approach to analysis activities which is a highly iterative,  highly collaborative, and very
flexible while still addressing the inherent risks associated with requirements. An interesting philosophy within
the agile community is that a changed or new requirement late in the lifecycle can be turned into a competitive
advantage if you're able to readily act on it. The agile approach to requirements and analysis activities can be
very different, and uncomfortable at first, to people with more traditional backgrounds.

02/20/2021 32
• Why does Agile play a big role in requirements?
• Debatably, one of the biggest challenges in software projects is producing effective requirements.
When the requirements aren’t done the right way, there is a high chance of having an unstable
foundation in the product lifecycle, which often leads to an unsatisfactory end product. In most
traditional projects, the requirements team has a mental barrier between them and other teams.
This mental barrier isn’t intentionally created, in-fact, it is more of a cultural issue. Agile techniques
play a key role in transforming that closed culture.
• Software projects fail when the act of creating requirements becomes solely the requirements
teams’ burden. Commercial software products or systems typically evolve at an exceedingly fast pace
due to highly competitive markets. A side effect of this fast pace is that the 
requirements documentation often seems out of date and irrelevant if created using traditional
methods that simply can’t keep up the pace. One of the worst feelings as a project team member is
seeing your requirements struggle to keep up with the pace of the changing environment. It can be
pretty demotivating for the entire team. Agile techniques in requirements gathering can not only
help overcome these issues but can also help build a higher quality end product.

02/20/2021 33
• At the heart of Agile requirements is…
• The aforesaid conundrum is a substantial one but before we jump into discussing the solutions, it is
important to understand the basics of Agile requirements.
• Agile requirements come in many shapes and forms, but the most common form is a User Story. Let’s
understand what a User story is all about.
• User Stories, or stories as some might call it (or them), represent customer requirements in a simple
written narrative rather than a tedious comprehensive document. It drives forward conversations within
Agile teams for planning and estimation. They contain a number of criteria that can be used to
determine when a User Story is considered to be complete. A good narrative for a User Story would be
something that adds value for the customer, partner, consumer, or stakeholder.
• Several stories make a Product Backlog and ideally the whole Agile team is responsible for the health of
the Product Backlog. However, a Product Owner (PO) is appointed to serve as the single wring-able neck
if something goes wrong with the end product. A dangerous yet common misconception in the Agile
world is that the PO is the only person responsible for the Product Backlog which I’m afraid is the root
cause of many failed products.

02/20/2021 34
5 Agile Techniques to Improve Requirements Documentation:
• 1. Compliment User stories with supporting artifacts
In cases where a User story does not have enough detail you may attach use cases, traditional requirements or decision tables. In
some situations, a client may demand for more documentation, especially while dealing with organizations that get audited for
process compliance for e.g. CMMI. This approach may work out well in that scenario.
• 2. Create requirements that slice the cake
The best way to do this is by writing end to end User Stories which include smaller feature sets, rather than writing stories that are
split across technical boundaries. Splitting stories along technical boundaries creates dependent stories which fails the INVEST
principle, which is described below. When writing stories, think of slicing a multilayered cake where each layer represents a
functional area of the product. For e.g. front end, middleware, backend, database and so on.
• 3. INVEST in your User Stories
An ideal User Story would have the following characteristics: Independent, Negotiable, Valuable, Estimable, Small and Testable.
This is called the INVEST principle. Make stories as independent as possible. Avoid using stories as written contracts, they should
be negotiable. Make User Stories valuable to the user and consumers. A story may not be estimable if the implementers lack
domain knowledge or technical knowledge. POs and technical leads need to help the implementers gain the domain and technical
knowledge by writing effective user stories which follow the INVEST principle that cause conversations focused towards
implementing the User Story. Predefined test criteria should be mentioned in the done criteria of an ideal User Story. POs should
take testers’ guidance for this and testers should be proactive in guiding the product owners.

02/20/2021 35
• 4. Groom your User Stories often
Conduct User Story grooming workshops daily or weekly depending on how soon you
need results. I remember being a part of these workshops during my career as a
software developer and I can’t tell you how valuable it was. It can be implemented
by following these steps. First, brainstorm stories on a whiteboard, then organize
them into their user themes, prioritize the stories into high, medium and low and
lastly improve high priority stories and make them follow INVEST principle.
• 5. Don’t be afraid to create prototypes
It is better to spend a small amount of time in building prototypes to just test out the
waters. This really helps in bringing ideas to reality and encourages healthy
discussions. However, make sure the prototype does not turn into a bulky project
and build it so that it can be used in some useful way in the actual  product.

02/20/2021 36
• What if I have a rigid traditional requirements gathering process?
• If you write your requirements using the guidelines mentioned above you should definitely
see good results even if you are following a fairly traditional requirements gathering process.
The key is to introduce these techniques one step at a time and be patient. However, if you
feel it’s highly challenging to create change in your organization, no worries, it is never too
late to start casual conversations about Agile techniques.
• Let’s assume there is no User Story grooming process occurring in your project. In this
scenario you would want to bring in the grooming process gradually. Before you organize a
full blown grooming session have an informal conversation with your team about conducting
a User Role Modelling session with your Agile team.
• If you explain the benefits clearly and implement it in a lightweight manner there is no
reason why they would resist. After the initial set of User Roles are identified, your team can
start rewriting the existing requirements using INVEST principle for the identified User Roles.

02/20/2021 37
• Recap
• Ineffective Agile Requirements most often lead to failed products
• The most common form of Agile requirements are User Stories
• Compliment User stories with supporting artifacts, write well rounded User Stories by slicing
the cake, INVEST in User Stories, conduct User Story grooming sessions weekly or daily
depending on your needs and create prototypes to compliment your requirements
• If these processes are new to your team you can start by talking to your team about the
benefits of these processes and then introduce these processes gradually.
• It is never too late to implement these Agile Requirements best practices. If you fear that this
would slow down your team then implement these processes in smaller chunks until you see
actual valued results.
• Remember that introducing these changes may seem risky but the biggest risk is not trying at
all!

02/20/2021 38
b. System Process Requirements
• The primary goal of this phase is to create a detailed Functional
• Specification defining the full set of system capabilities to be
• implemented, along with accompanying data and process models
• illustrating the information to be managed and the processes
• to be supported by the new system. The Functional Specification
• will evolve throughout this phase of the SDLC as
• detailed business requirements are captured, and as supporting
• process and data models are created, ensuring that the
• eventual solution provides the Customers with the functionality
• they need to meet their stated business objectives.
02/20/2021 39
• This phase consists of the following processes:
• Prepare for System Requirements Analysis, where steps are taken to ensure
that the project environment and Project Team members are adequately
prepared to both capture and analyze the system requirements;
• Determine Business Requirements, where in-scope and out-of-scope
business requirements are identified, business rules are defined and
documented, and interfaces to and from the new application are discussed;
• Define Process Model, where a pictorial top-down representation of the
major business processes that interact with the system is diagrammed and
decomposed into manageable functions and sub-functions until no further
breakdown is feasible;
02/20/2021 40
• Define Logical Data Model, where data that supports the processes
and business rules is logically modeled, identifying entities and their
relationships to other entities, and defining attributes with their
business definitions;
• Reconcile Business Requirements With Models, where the Project
Team ensures that the Process and Logical Data Models accommodate
all requirements and business rules;
• Produce Functional Specification, where interfaces, processes and data
are merged to describe systematically how the Consumer will use the
application, and how data will be retrieved, processed and stored.

02/20/2021 41
• Information Gathering Techniques To develop an information system, we first must
be able to correctly identify, analyze, and understand what the users’ requirements
are or what the user wants the system to do.
• To know users’ requirements, we use information gathering techniques. Information
gathering techniques are also called requirements discovery techniques or fact
finding techniques or data collection techniques.
• Information gathering includes those techniques to be used by system analysts to
identify or extract system problems and solution requirements from the user
community.
• Systems analysts need an organized method for information gathering. Some
information gathering techniques are discussed below:
02/20/2021 42
• Sampling of Existing Documentation, Forms, and Files When we are studying an existing
system, we can develop a good feel for the system by studying existing documentation, forms,
and files.
• A good analyst always gets facts from the existing documentation rather than from people.
Because it would be impractical to study every occurrence of every form or record in a file or
database, system analysts normally use sampling techniques to determine what can happen
in the system.
• Sampling is the process of collecting a representative sample of documents, forms, and
records. The most commonly used sampling techniques are randomization and stratification.
• Randomization is a sampling technique in which there is no predetermined pattern or plan
for selecting sample data. Stratification is a systematic sampling technique that attempts to
reduce the variance of the estimates by spreading out the sampling.

02/20/2021 43
• Research and Site Visits In this technique, we perform site visits at
systems they know have experienced similar problems.
• If these systems are willing to share, valuable information can be obtained
that may save tremendous time and cost in the development process.
• Computer trade journals and reference books are also a good source of
information.
• They can provide us with information how others have solved similar
problems. Also, through the Internet we can collect immeasurable
amounts of information.

02/20/2021 44
• Observation of the Work Environment Observation is an effective data-colle ction
technique for obtaining an understanding of a system. In this technique, the systems analyst
either participates in or watches a person performing activities to learn about the system.
Advantages:
→ Data gathered can be highly reliable. Sometimes observations can be conducted to check
the validity of data obtained directly from individuals.
→ The systems analyst is able to see exactly what is being done.
→ It is relatively inexpensive compared to other fact-finding techniques, because other
techniques usually require more employees.
→ It allows the system analyst to do work measurement.

02/20/2021 45
Disadvantages:
→ People usually feel uncomfortable when being watched to their
work.
→ Some system activities may take place at odd times, causing a
scheduling inconvenience for the system analyst.
→ It may cause interruption.
→ Some tasks may not always be performed by observation.

02/20/2021 46
• Questionnaires This technique is used to conduct surveys through questionnaires.
• Questionnaires are special purpose documents that allow the analyst to collect
information and opinions from the respondents. The document can be mass-
produced and distributed to respondents, who can then complete the questionnaire
on their own time. Questionnaires allow the analyst to collect facts from a large
number of people.
• Types of Questionnaires There are two formats of questionnaire, free-format and
fixed-format.
• Free-format questionnaire offer the respondent to record the answer in the space
provided after the questionnaire.
• Fixed-format questionnaire contain questions that require selection of predefined
responses. In this format, the respondent must choose from the available answer.

02/20/2021 47
There are three types of fixed-format questions:
→ Multiple Choice Questions: - The respondent is given several
answers of a question. The respondent should be told if more than one
answer can be selected.
→ Rating Questions: - The respondent is given a statement and asked
to use supplied responses to state an opinion.
→ Ranking questions: - The respondent is given several possible
answers, which are to be ranked in the order of preference or
experience.

02/20/2021 48
Advantages
→ Most questionnaires can be answered quickly.
→ Inexpensive for gathering data from a large number of individuals.
→ Responses can be tabulated and analyzed quickly.
Disadvantages
→ There is no guarantee that an individual will answer or expand on all the questions.
→ Questionnaires tend to be inflexible.
→ It not possible for the systems analyst to observe and analyze the respondent’s body language.
→ There is no immediate opportunity to clarify a vague or incomplete answer to questions.
→ Good questionnaires are difficult to prepare.
→ The number of respondents is often low.

02/20/2021 49
• Interviews The personal interview is generally recognized as the most often used fact-finding
technique. Interviews are the fact-finding techniques whereby the systems analysts collect
information from individuals through face-to-face interaction. There are two roles assumed in
an interview.
• The systems analyst is the interviewer, responsible for organizing and conducting the
interview. The system user or system owner is the interviewee, who is asked to respond to a
series of questions.
• Types of Interviews
• There are two types of interviews: unstructured and structured.
• Unstructured interviews are conducted with only a general goal or subject in mind and with
few, if any, specific questions.
• Structured interviews on the other hand are conducted with a set of specific questions to ask
the interviewee.

02/20/2021 50
• Types of Questions There are two types of questions in interview: open-ended and closed-ended.
• Open- ended questions allow the interviewee to respond in any way that seems appropriate. But,
closed-ended questions restrict answers to either specific choices or short, direct responses.
Advantages
→ Interviews give the analyst an opportunity to motivate the interviewee to respond freely and
openly to questions.
→ Interviews allow more feedback from the interviewee.
→ Interviews give the analyst an opportunity to observe the interviewee’s nonverbal communication.
Disadvantages
→ Interviewing is a very time-consuming and therefore costly fact-finding approach.
→ Success of interviews is highly dependent on the systems analyst’s human relational skills.
→ Interviewing may be impractical due to the location of interviewees.

02/20/2021 51
• Discovery Prototyping
• Discovery prototyping is the act of building a small-scale, representative or working model of the users’ requirements to discover
or verify the requirements.
• Usually only the areas where the requirements are not clearly understood are prototyped. Creating discovery prototypes
enables the developers as well as the users to better understand and refine the requirements involved with developing the
system.
Advantages
→ Allows users and developers to experiment with the software and develop an understanding of how the system might work.
→ Aids in determining the feasibility and usefulness of the system before high development costs are incurred.
→ Serves as a training mechanism for users.
→ Aids in building system test plans and scenarios to be used last in the system testing process.
→ May minimize the time spent for fact-finding and help to define more stable and reliable requirements.
Disadvantages
→ Users and developers may need to be trained in the prototyping approach.
→ Doing prototyping may extend the development schedule and increase the development costs
→ Users may develop unrealistic expectations.

02/20/2021 52
• Joint Requirements Planning (JRP)
• It is a process whereby highly structured group meeting is conducted to analyze problems and define requirements. JRP is a subset of a
more comprehensive joint application development (JAD).
• The JRP participants are:
→ Sponsor: - This person is normally an individual who is in top management and has authority that spans the different departments and
users who are to be involved in the systems project.
→ Facilitator: - The JRP facilitator or leader is usually responsible for leading all sessions that are held for a systems project.
→ Users and Managers: - Users devote themselves to the JRP sessions to effectively communicate business rules and requirements, review
design prototypes and make acceptance decisions. Managers approve project objectives, establish project priorities, approve schedules and
costs, and approve identified training needs and implementation plans.
→ Scribe(s): - Scribes are responsible for keeping records pertaining to everything discussed in the meeting.
→ IT Staff: - IT personnel listen and take notes regarding issues and requirements voiced by the users and managers. Normally, IT personnel
do not speak unless invited to do so.
Benefits
→ It actively involves users and managers in the development project.
→ It reduces the amount of time required to develop systems.
→ When JRP incorporates prototyping as a means for conforming requirements and obtaining design approvals, the benefits of prototyping
are realized.

02/20/2021 53
• Structured Analysis Tools Structured analysis includes different tools
like DFD (data flow diagram), ERD (entity relationship diagram), data
dictionary, structured English, decision table, and decision tree.
• Feasibility Study Feasibility is the measure of how beneficial or
practical the development of information system will be to an
organization.
• Feasibility study is the process by which feasibility is measured.
Feasibility analysis is appropriate to the systems analysis phase.

02/20/2021 54
• Four Tests for Feasibility During systems analysis phase, the system analyst identifies different alternate solutions and analyzes
those solutions for feasibility. To analyze different alternative solutions, most analysts use four categories of feasibility tests:
• Operational feasibility
• Technical feasibility
• Schedule feasibility and
• Economic feasibility

1. Operational Feasibility: It is a measure of how well the solution will work in an organization. It is also a measure of how
people feel about the system/project. So, this feasibility is people oriented.
• Operational feasibility addresses two major issues:
a. Is the problem worth solving, or will the solution to the problem work?
b. b. How do end users and management feel about the problem (solution)?
When determining operational feasibility, usability analysis is often performed with a working prototype of the proposed
system. Usability analysis is a test of system’s user interfaces and is measured in how easy they are to learn and to use and how
they support the desired productivity levels of the users. Usability is measured in terms of ease of learning, ease of use, and
satisfaction.

02/20/2021 55
2. Technical Feasibility: It is a measure of practically of a specific technical solution and availability
of technical resources and expertise. Technical feasibility is computer oriented.
This feasibility addresses three major issues:
a. Is the proposed technology or solution practical?
b. Do we currently possess the necessary technology?
c. Do we possess the necessary technical expertise, and is the schedule reasonable?
3. Schedule Feasibility: It is a measure of how reasonable the project timetable is.
Schedule feasibility is the determination of whether the time allocated for a project seems accurate.
Projects are initiated with specific deadlines.
It is necessary to determine whether the deadlines are mandatory or desirable.
If the deadlines are desirable rather than mandatory, the analyst can propose alternative schedules.

02/20/2021 56
4. Economic Feasibility: It is the measure of the cost-effectiveness of a
project or solution.
This feasibility deals with costs and benefits of the information system.
The bottom-line in many projects is economic feasibility.
During the early phases of the project, economic feasibility analysis
amounts to little more than judging whether the possible benefits of
solving the problem are worthwhile.
However, as soon as specific requirements and alternative solutions have
been identified, the analyst can determine the costs and benefits of each
alternative.
02/20/2021 57
Some other feasibility tests are also possible. These are legal and
contractual feasibility and political feasibility.
Legal and contractual feasibility is the process of assessing potential
legal and contractual ramifications due to the construction of a system.
Political feasibility is the process of evaluating how key stakeholders
within the organization view the proposed system.

02/20/2021 58
Cost-Benefit Analysis Techniques
Economic feasibility has been defined as a cost-benefit analysis. Most
schools offer coerces like financial management, financial decision
analysis, and engineering economics and analysis for cost benefit
analysis.
The cost benefit analysis techniques include:
• How much will the system costs?
• What benefits will the system provide?
• Is the proposed system cost-effective?

02/20/2021 59
How much will the system costs?
Costs fall into two categories: costs associated with developing the system and costs
associated with operating the system.
The former costs can be estimated from the start of the project and should be refined at
the end of each phase of the project.
The later can be estimated only after specific computer-based solution has been defined.
System development costs are usually onetime costs that will not recur after the project has
been completed.
Many organizations have standard cost categories that must be evaluated. In the absence
of such categories, we use the following list:
• Personnel cost – The salaries of systems analysts, programmers, consultants, data entry
personnel, computer operators, secretaries, and the like who work on the project.

02/20/2021 60
• Computer usage – The cost in the use of computer resources.
• Training – Expenses for the training of computer personnel or end-users.
• Supply, duplication, and equipment costs.
• Cost of any new computer equipment and software. The operating costs tend to recur
throughout the lifetime of the system. The costs in this case can be classified as fixed or
variable.
• Fixed costs – Fixed costs occur at regular intervals but at relatively fixed rates. Some
examples include: lease payments and software license payments, salaries of IS operators
and support personnel etc.
• Variable costs – Variable costs occur in proportion to some usage factor. Some examples
include: costs of computer usage (e.g., CPU time used, storage used), supplies (e.g., printer
paper, floppy disks), overhead costs (e.g., utilities, maintenance, and telephone service) etc.

02/20/2021 61
• What benefits will the system provide?
• Benefits normally increase profits or decrease costs. Benefits can be classified into two categories: tangible
and intangible.
• Tangible benefits – Tangible benefits are those that can be easily quantified.
These benefits are usually measured in terms of monthly or annual savings or of profit to the firm.
Alternatively, these benefits might be measured in terms of unit cost savings or profit.
Some examples of tangible benefits are: fewer processing errors, increased throughput, decreased response
time, elimination of job steps, increased sales, reduced credit losses, and reduce expenses.
• Intangible benefits – Intangible benefits are believed to be difficult or impossible to quantify.
Unless these benefits are at least identified, it is entirely possible that many projects would not be feasible.
Some examples of intangible benefits are: improved customer goodwill, improved employee morale, better
service to community, and better decision making.
Unfortunately, if a benefit cannot be quantified, it is difficult to accept the validity of an associated cost-
benefit analysis that is based on incomplete data.

02/20/2021 62
• Is the proposed system cost-effective?
There are three popular techniques to assess economic feasibility, also called cost- effectiveness: payback
analysis, return to investment, and net present value.
One concept that is shared by all three techniques is the time value of money – a dollar today is worth more
than a dollar one-year from now. Some of the costs of the system will be accrued in after implementation.
Before cost- benefit analysis, these costs should be brought back to the current dollars.
Present value is the current value of a dollar at any time in the future. It is calculated using the formula: PVn =
1/(1 + i)n Where PVn is the present value of $1.00 n years from now and i is the discount rate.
Payback analysis – It is a technique for determining if and when an investment will pay for itself. Because
system development costs are incurred long before benefits begin to occur, it will take some time for the
benefits to overtake the costs. After implementation, there will be additional operating expenses that must be
recovered.
Payback analysis determines how much time will lapse before accrued benefits overtake accrued and
continuing costs. This period of time is called payback period, that is, the period of time that will lapse before
accrued benefits overtake accrued costs.

02/20/2021 63
• Return-on-investment analysis – This technique compares the lifetime
profitability of the solution.
It is a percentage rate that measures the relationship between the amounts
the business gets back from an investment and the amount invested.
It is calculated as follows:
Lifetime ROI = (Estimated lifetime benefits – Estimated lifetime
costs)/Estimated lifetime costs
• Net present value – It is an analysis technique that compares costs and
benefits for each year of the system’s lifetime. Many managers consider it
the preferred cost-benefit analysis technique.

02/20/2021 64