What is a Requirement?

Web Definition says “a requirement is a singular documented physical and functional need that a
particular product or service must be or perform”. It can be easily be defined as “a raw need which requires
external inputs or efforts to deliver a final product”. Let’s take an example to understand more, If a client
says that “they want a system to acquire feedback from their customers” then this can be termed as their
requirement which requires inputs from design team to design such platform and efforts from technical team
to convert the design into a product like feedback portal.
Thus Requirements Gathering is one of the most important task in deciding success of a
project. The type of requirements and techniques to capture them, depends on the given scenario and
need. A good domain knowledge coupled with tool usage helps in conveying the same communication
to stakeholders like designers, developers and testing team.
It is the first stage of information system development cycle. This gives a clearer picture of what
actually the existing system is. The preliminary investigation must define the scope of the project and the
perceived problems, opportunities and directives that triggered the project.

Requirements can be classified into two broad categories.

Functional Requirements : We develop projects/software to meet Functional requirements. These
requirements are the desired functionality that the client want us to build and delivered to them. A functional
requirement describes an interaction between the system and its environment. Let’s just say, decide the
inputs to the system and output from the system considering all internal and external factors involved. A
document is created logging all details which contains what a certain system has to do to achieve a certain
specific objective.
Non-Functional Requirements: Non-functional requirements are the untold part of the project
which are not communicated but readily understood as a Global standard. These can be understood as a
support system of functional requirements. These are the expectations of client to showcase the product as a
global product following global guidelines. A nonfunctional requirement can be described as a constraint on
the system that like page load speed which can be optimized up-to a certain extent. Non functional
requirements can be limited to Response time, security, reliability, accuracy, capacity and availability.
Clients have to decide on all these parameters and take a call to achieve a workable solution.

Requirements Analysis will identify and consider the risks related to how the technology will be integrated
into the standard operating procedures.  Requirements Analysis will collect the functional and system
requirements of the business process, the user requirements and the operational requirements (e.g., when
operational what is necessary to keep the system up and running). This is the process of discovering,
analyzing, defining, and documenting the requirements. It involves measuring each and every functional
requirement, non-functional requirement, technical, operational, and transitional requirements.
Requirements analysis involves regular interaction with client to determine their expectations, providing
visual representations, creating mappings between loose ends, defining boundaries of the system. It can be
described as a formal agreement between the client and the agency which clearly states as what will be in
scope and what is out of scope and also pen down understanding of each party over the end result.
 A critical part of any software development project is the requirements gathering. If you are unclear
about what is going to be delivered, how will you know when you get there? Good user requirements lead to
better estimates, improved customer satisfaction, reduced cost and a shorter duration. A few questions that
need to be asked before the start of any software development project are:
 Why are we building the system?
 What benefits are we expecting to get from it?
 What do we actually need it to do?
Benefits/Need of good users Requirements are as under:-
 Studying the existing system and Designing the new System.
Good requirements gathering provide a firm foundation from which to work. Customers need to
know what is being developed and that it will satisfy their needs. Developers need to know what to develop
and testers what to test. A quality requirements document can provide all of these things.
When creating a requirements document it is important to get everybody involved including the
customer, project manager, customer account manager, developers, testers and anyone else with a stake in
the project. Requirements gathering is a joint activity not solely the domain of business analysts and project
managers. We have to study existing system and design the new system with the customers consent.
A good set of requirements enables the project manager to plan and estimate the project effectively.
 Running Requirements Meetings
The Requirements Gathering Meeting is the time to get all the team members, customers and stakeholders
together to define the requirements for the system. Like all formal meetings, there should be an agenda. You
need to cover a number of specific things at this meeting:
1. Introduction of the people at the meeting.
2. The objectives of the meeting.
3. The purpose of the project.
4. The expected benefits.
5. The customer's requirements.
6. Next steps.
Ideally, a business analyst should lead an open meeting where all ideas are encouraged to draw out the
customer requirements. Customers are not always good at articulating their needs, so it is important to play
back your understanding of their requirements to ensure clarity. Several meetings may be needed to gather
all the requirements.
The requirements are written up by the business analyst in the Business Requirements Specification and
are shared with the customer. The document must be clear, concise and thorough. The customer should
review and agree the contents of the document. It is not advisable to ask them to physically sign it off, as
this could be interpreted as a lack of trust and get the project off on the wrong-foot.
• To find out various opportunities, constraints to understand the requirement and priorities of
system.
 To identify different roles in the process
Including use cases in the Business Requirements Specification can be very useful for documenting
business process and identifying different roles in the process. Customers often find the diagrams easier to
understand than just plain text.
These are some of the rules for writing requirements documents:
 Requirements are written in the language of the user.
  Avoid technical jargon.
 Confirm what the system will not do, as well as what it will do.
 Keep it clear, concise and thorough.
 Include a section for non-functional requirements.
 To group your thoughts and ideas in a logical way.
 To group someone else's thoughts and ideas in a logical way.
 To understand what a software package must do before making a selection.
 To decide whether to buy or build a solution.
 As a point of reference throughout the project.
 To provide a basis for testing.
 To utilize your time more efficiently and effectively.
 To develop critical thinking through the use of sifting/sorting techniques.
 Broaden your outlook and inform your subject understanding through the exploration of more
diverse sources.
 Achievement.

Critical Success Factors

To be successful at requirements gathering and to give your software development projects an increased
likelihood of success:
 Don't assume you know what the customer wants, ask.
 Involve the users from the start.
 Define and agree the scope of the project.
 Ensure requirements are specific, realistic and measurable.
 Obtain clarity if there is any doubt.
 Create a clear, concise and thorough requirements document and share it with the customer.
 Confirm your understanding of the requirements with the customer (play them back).
 Avoid talking technology or solutions until the requirements are fully understood.
 Get the requirements agreed with the stakeholders before the project starts.
 Create a prototype if necessary to confirm or refine the customers' requirements.
 Use a recognized notation, such as UML, for Modeling the software.
 Cross check the software design against the requirements and review regularly.
Common Problems
These are some of the reasons given for not carrying out requirements gathering:
 No time because of tight deadlines.
 Customer not available to meet and discuss requirements.
 Requirements gathering seen as a waste of time by the organisation.
 Assuming we know what the customer requires without asking.
 No way of effectively recording requirements.

Primary data is the data collected by the researcher themselves, i.e.

1.interview
2.observation
3.action research
4.case studies
5.life histories
6.questionnaires
 7.ethnographic research
8.longitudinal studies

Secondary sources are data that already exists

1.Previous research
2.Official statistics
3.Mass media products
4.Diaries
5.Letters
6.Government reports
7.Web information
8.Historical data and information

Document Analysis
Document Analysis is an important gathering technique. Evaluating the documentation of a present
system can assist when making AS-IS process documents and also when driving the gap analysis for
scoping of the migration projects. In today’s world, you will also be determining the requirements that drove
making of an existing system- a beginning point for documenting all current requirements. Chunks of
information are mostly buried in present documents that assist you in putting questions as a part of
validating the requirement completeness.
Document analysis is a social research method and is an important research tool in its own right and
is an invaluable part of most schemes of triangulation. Documentary work involves reading lots of written
material (it helps to scan the documents onto a computer and use a qualitative analysis package). A
document is something that we can read and which relates to some aspect of the social world. Official
documents are intended to be read as objective statements of fact but they are themselves socially produced.
 Sources of Documents:
1. Public records
2. The media
3. Private papers
4. Biography
5. Visual documents

System Analysis:-
"Systems analysis is a problem solving technique that decomposes a system into its component
pieces for the purpose of the studying how well those component parts work and interact to
accomplish their purpose".
According to the Merriam-Webster dictionary, systems analysis is "the process of studying a
procedure or business in order to identify its goals and purposes and create systems and procedures
that will achieve them in an efficient way". Analysis and synthesis, as scientific methods, always go
hand in hand. They complement one another. Every synthesis is built upon the results of a preceding
analysis, and every analysis requires a subsequent synthesis in order to verify and correct its results.
The terms analysis and synthesis stem from Greek, meaning "to take apart" and "to put together,"
respectfully. These terms are used in many scientific disciplines, from mathematics and logic to
economics and psychology, to denote similar investigative procedures. Analysis is defined as "the
procedure by which we break down an intellectual or substantial whole into parts," while synthesis
means "the procedure by which we combine separate elements or components in order to form a
coherent whole." Systems analysis researchers apply methodology to the systems involved, forming
an overall picture. System analysis is used in every field where something is developed. Analysis can
also be a series of components that perform organic functions together, such as system engineering.
 Systems engineering is an interdisciplinary field of engineering that focuses on how complex
engineering projects should be designed and managed.

There are a number of different approaches to system analysis. When a computer-based information
system is developed, systems analysis (according to the Waterfall model) would constitute the following
steps:
 The development of a feasibility study: determining whether a project is economically, socially,
technologically and organizationally feasible
 Fact-finding measures, designed to ascertain the requirements of the system's end-users (typically
involving interviews, questionnaires, or visual observations of work on the existing system)
 Gauging how the end-users would operate the system (in terms of general experience in using
computer hardware or software), what the system would be used for and so on
Another view outlines a phased approach to the process. This approach breaks systems analysis into 5
phases:
 Scope Definition: denoting an instrument for observing, viewing, or examining
 Problem analysis: analyzing the problem that arises
 Requirements analysis: determining the conditions that need to be met
 Logical design: looking at the logical relationship among the objects
 Decision analysis: making a final decision
Use cases are widely used systems analysis modeling tools for identifying and expressing the functional
requirements of a system. Each use case is a business scenario or event for which the system must provide a
defined response. Use cases evolved from object-oriented analysis.
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements.
The use case is made up of a set of possible sequences of interactions between systems and users in a
particular environment and related to a particular goal.
A use case shows the behavior or functionality of a system. It consists of a set of possible sequences of
interactions between a system and a user in a particular environment that are related to a particular goal. In
Software Engineering, a use case is used to describe the steps between an user and a software system which
guides the user to useful output. The user (also called an actor) could be a human user, an external hardware,
software systems, or other subjects.
In a broad sense, a general methodology (not a fixed set of techniques) that applies a 'systems' or 'holistic'
perspective by taking all aspects of the situation into account, and by concentrating on the interactions
between its different elements. It provides a framework in which judgments of the experts in different fields
can be combined to determine what must be done, and what is the best way to accomplish it in light of
current and future needs. Although closely associated with data or information processing, the practice of
SA has been in existence since long before computers were invented.
In a narrow sense, analysis of the current and future roles of proposed computer system in an organization,
The system analyst (usually a software engineer or programmer) examines the flow of documents,
information, and material to design a system that best meets the cost, performance, and scheduling
objectives.

Need and Importance of System Analysis:-

Systems Analysis is, as the name states, the analysis of systems! The systems that we are talking
about are the systems within organizations and businesses - systems of communication, financial systems,
manufacturing systems, etc. - basically the systems that make the organization or business work.
The biggest advantage of systems analysis is that it helps businesses and organizations assess their
various, interacting elements in order to make them more efficient. The term systems analysis often refers to
computer systems, but also applies more broadly to all aspects of a business or organization.
A person who analyses systems is known as a Systems Analyst. Often systems analysts are
employed by organizations of businesses to help them improve their systems and so become more efficient,
and for businesses, more profitable. The analyst understands the nature of the information and the functions
of the software which is required for the system. The analyst makes a brief survey of the requirements and
tries to analyze the performance of the system which is to be developed. He also makes sure that he gets
enough information and resources for building the appropriate system.
o The analysis phase of the SDLC involves end users and IT specialists working together
understand, and document the business requirements for the proposed system.
o The primary activity of this phase is to gather business requirements. Business requirements
are the detailed set of knowledge worker requests that the system must meet to be successful.
o One task to gather business requirements is to perform a joint application development (JAD)
session, knowledge workers and IT specialists meet to define and review business
requirements.
o Once all the business requirements are defined, the end-users sign off on them indicating that
they approve of all the business requirements .
o One of the keys to success in the analysis phase is to find errors in the business requirements
and the project plan. Errors are much cheaper to fix here than later in the SDLC.
 The goal of Systems Analysis is to capture an accurate representation of business processes and user’s
perceptions of them.
 The Business Processes we are interested in are those that encompass the flow of data (input, storing,
processing, output) throughout an organization.
 Problem: Even the best analysts in the world would come up with differing analyses of the same
problem.
 Systems Analysis applies a structured, formal method to model and improve upon business processes.
 A Systems Analyst can act as an outside consultant brought in to address a specific system design
problem; as a supporting expert; as an agent of change in an organization

Elements of Project Initiation

• Establishing the team and plan.
o Initiate. The initiation process authorizes the overall project or the next phase of a project. In
this phase, project objectives are established, scope is defined, and responsible parties and
deliverables are identified.
o Plan. The planning processes are precisely that--the defining and refining of the best courses
of action to take to attain the project objectives. Planning falls into two categories: core
planning processes and facilitating processes.
o Core processes are those that have clear dependencies that require them to be performed in
essentially the same order on most projects. Examples include scope planning, schedule
development, resource planning, and cost budgeting.
o Facilitating processes are entirely dependent on the nature of the project and are performed
intermittently and as needed--though they are not optional. Some of the facilitating planning
processes include quality planning, staff acquisition, and risk identification.

• Establishing the relationship with the customer

It is a company-wide business strategy designed to reduce costs and increase profitability by
solidifying customer satisfaction. If we can build a relationship where they know who we are, they
like what we can do, and give an example of how we can help them, then we can give them the trust
and that helps solidify relationships.
Focus on people, process and technology, and execute the plans made by the system analyst,
which involves coordinating resources, human and otherwise, to carry out the overall project plan.
Because of the ongoing role execution plays in project management, its processes are also divided
into core and facilitating subgroups. The central core process, project plan execution, oversees
facilitating processes such as team development, information distribution, and solicitation.
 • Establishing the Management Procedures
Establish Goals
The first step of the management planning process is to identify specific company goals.
Where possible, objectives should be described in quantitative or qualitative terms. An
example of a goal is to raise profits by 25 percent over a 12-month period.
Identify Resources
Each goal should have financial and human resources projections associated with its
completion. For example, a management plan may identify how many sales people it will
require and how much it will cost to meet the goal of increasing sales by 25 percent.
Establish Goal-Related Tasks and Prioritize
Each goal should have tasks or projects associated with its achievement. For example, if a
goal is to raise profits by 25 percent, a manager will need to outline the tasks required to
meet that objective. Examples of tasks might include increasing the sales staff or developing
advanced sales training techniques.
Create Assignments and Timelines and Establish Evaluation Methods

• Establishing the Project Management Environment

There is a growing awareness and concern for the impact of infrastructure and facility
construction on the physical environment. Fortunately, today's technological disciplines responsible
for such work. Today's project manager also needs to be attuned to the cultural, organizational and
social environments of the project. Understanding this environment includes identifying the project
stakeholders and their ability to affect its successful outcome. This means working with people to
achieve the best results, especially in the highly technical and complex environments such as those
involving modern day construction projects. Therefore, it is essential that the project manager and
his or her project team are comfortable with, and sympathetic towards, their cultural, organizational
and social surroundings.

• Establishing the Project Work Book

Project Management is usually applied to complex business situations and problems such as
managing and controlling the introduction of new initiatives or organizational changes. Indeed any
kind of project that requires a great deal of planning and that would benefit from a formal,
disciplined management approach. With this workbook, we'll introduce you to project management
and help you understand how this vital role helps companies make the changes needed to respond to
the environment. Managing projects well requires a great deal of time, skill, and finesse. There are
many sides to project management and this is what makes it so interesting and demanding. Project
managers are expected to take an uncertain event and make a certain promise to deliver. They are
also expected to do this within a specified time and within a limited budget.

Planning approach
• Apart from flexibility, reliability analyst must study the basic objective of the system.
The purpose of planning is to help achieve sustainable development. Sustainable
development is defined as under:-
• Sustainable means ensuring that better lives for ourselves don’t mean worse lives for future
generations.
• Development means growth. We must accommodate the new ways by which we will earn
our living in a competitive world. We must house a rising population, which is living longer
and wants to make new choices. We must respond to the changes that new technologies offer
us. Our lives, and the places in which we live them, can be better, but they will certainly be
worse if things stagnate.

• Breakdown the work or Work Breakdown Structure(WBS)

To identify the individual tasks in a project, it is useful to create a Work Breakdown
Structure. The WBS is the foundation for the detailed project plan. Get the team together and
 brainstorm all the tasks and subtasks in the project, in no particular order. Write them down
on sticky notes and put them on a whiteboard. Once everyone has thought of as many tasks
as they can, arrange the sticky notes into groups under the major areas of activity. Add,
change, remove and shuffle the sticky notes until the WBS is accurate, complete and logical.
The purpose of a WBS is to decompose the project into steps and sub steps.

• Roles and responsibilities of personals

Projects don't just happen they need planning. Involve the whole project team in developing the
plan, not just the project manager. This ensures team members experience is considered and each
person is fully committed to, and has ownership of the plan.

In Project development different persons have different responsibilities and roles as under

Project Manager
The Project Manager is also responsible for managing the work of consultants,
allocating and utilizing resources in an efficient manner and maintaining a co-operative, motivated
and successful team.
Project Sponsor The Project Sponsor is usually the one who has to negotiate a path through the
tricky diplomatic areas of the project although the Project Manager will most likely be involved in
such areas from time to time too!
Project Board:- This group, normally containing management grade personnel, is responsible for
overseeing the progress of the project and reacting to any strategic problems.
Project Administrator or Co-ordinator:- Responsible for maintenance of the project plan,
maintenance and updating of a project website (if appropriate). Provides administrative support to
the Project Manager. This role is most likely to be required in larger cross-functional projects.
Senior Consultant or Supplier side Project Manager:- The person responsible for managing
supplier-side input to the project.
Project Team Members:- The staff who actively work on the project, at some stage, during the
lifetime of the project.
Systems Developer:- To work with the Project Manager on defining and executing development
requirements.
System Administrator:- Management and support of the IT system environments
Program Manager:- This role is relevant if there are several related projects.

Structured Planning
A SWOT analysis (alternatively SWOT matrix) is a structured planning method used to
evaluate the strengths, weaknesses, opportunities and threats involved in a project or in a
business venture. A SWOT analysis can be carried out for a product, place, industry or person. It
involves specifying the objective of the business venture or project and identifying the internal and
external factors that are favorable and unfavorable to achieve that objective.

 Strengths: characteristics of the business or project that give it an advantage over others.
 Weaknesses: characteristics that place the business or project at a disadvantage relative to
others.
 Opportunities: elements that the project could exploit to its advantage.
 Threats: elements in the environment that could cause trouble for the business or project.

 Identification of SWOTs is important because they can inform later steps in planning to achieve the
objective.
 First, the decision makers should consider whether the objective is attainable, given the SWOTs. If
the objective is not attainable a different objective must be selected and the process repeated.
  Users of SWOT analysis need to ask and answer questions that generate meaningful information for
each category (strengths, weaknesses, opportunities, and threats) to make the analysis useful and find
their competitive advantage.

Objectives of Preliminary investigation/ Initial Investigation

• Examine what exactly the problem is and why we are developing the new system.
• Goals to be achieved by solution
• Changes are to be incorporated for implementing the new system.
• System analyst must remember two things
– All members of the project team should reassess the business conditions, detail
understanding of system’s costs, benefits, and risks.
– Make good project selection decisions and provide sound guidance.

Information Gathering Tools

Information Gathering Sources are categorized into two categories

Primary Source
Secondary Sources
Secondary sources provide information collected by other investigators. Such published materials as the
following are examples of secondary sources with which you should be familiar:
annual reports
Encyclopedias
articles (print and online)
books
newspapers
pamphlets and monographs
periodicals (magazines)
brochures
dictionaries
yearbooks
A search of secondary sources will reveal whether anyone had investigated a similar problem
previously and published the results. Libraries, online databases, and online search engines are the best
places to check for secondary sources. In addition to checking the library’s card catalog or database of
listings, consult with a reference librarian. Reference librarians are experts in locating print and electronic
secondary sources and may save you many hours of searching.
In the last few years, online secondary sources have proliferated. Much of the information that used
to be available in print only is now available online as well. Some online databases are proprietary: your
organization must be a member to use them. Many of these proprietary databases are available through
university and large public libraries. Check with your reference librarian to see what is accessible at your
location.
A great deal of information, however, is available through public sites on the Internet. To find it, you will
need to use one or more of the search engines designed to scour the web for documents, key terms, and their
web addresses (URL, or Uniform Resource Locator).
Regardless of how you find your secondary sources, especially those you might find on the Internet,
you need to be aware that not all of them are equally reliable and objective. Before you use a secondary
source, you need to make sure that the information is sufficiently current to be helpful and that the
information is unbiased. If you were working for a health care organization, for example, and needed to
write a report on the long-term effect of smoking on health, would you feel comfortable relying on studies
conducted by the tobacco industry? Because many organizations founded to support a particular view or
interests have neutral-sounding names, you need to check to make sure that the information is unbiased.
How much secondary research you need to do and how well you will need to document it will
depend entirely on the nature of the problem you are investigating. In general, secondary research is useful
for two reasons: First, it reduces the need for primary research, which is much more expensive to conduct.
Second, it provides you with external verification for your own primary research; if your own results are
similar to those of other investigators, you can be fairly confident that they are correct. On the other hand, if
your results are markedly different from those of others who have studied similar problems, you may wish
to continue your investigation before reporting your results.

Teleconferencing and productivity:- It is used for listing of all sites that included the words
teleconferencing and productivity, that is, both words would need to be present.

Internal Sources : - Information about the Firm/Organization Policies , Goals, Objectives , Organization
Structure. Rule Books, Reports on existing Systems.
 When secondary sources do not provide the answers, you will need to uncover the
information for yourself. Collecting data for yourself is known as primary research. The three principal
methods of collecting primary, or original, data are experimentation, observation, and surveys.
A search of secondary sources will reveal whether anyone had investigated a similar problem
previously and published the results. Libraries, online databases, and online search engines are the best
places to check for secondary sources. Reference librarians are experts in locating print and electronic
secondary sources and may save you many hours of searching.
Experimentation
Although experimentation was originally the tool of scientists, business and industry are now using
it more frequently. Of course, many business problems do not lend themselves to experimental research, but
those in business can use experimentation to determine the effects of one variable on another under certain
conditions. To test the marketing effectiveness of a new packaging concept, for example, an experimenter
would change the packaging (the independent variable) to see how the change influenced sales (the
dependent variable).
Observation
In research, observation means recognizing and noting facts. Unlike the experimenter, an observer
does not manipulate the environment. In a bookstore, for example, you could determine book preferences by
observing shoppers as they make their selections. Observation can also apply to certain kinds of studies of
published documents. You might be interested, for example, in examining annual reports for the use of
certain words and phrases, such as reengineering, to see when organizations first began using the
expressions and the way in which the frequency of use increased over time.
One disadvantage of observation is that because we have a tendency to interpret what we see or hear based
on our previous experience; information obtained by means of observation may not be totally accurate.
Although it is often used alone to record facts—raw data—observation is more often used in conjunction
with experimentation and surveys to help ensure accuracy and reliability and to help explain what the
observations mean.

Requirements gathering(Information Gathering) can be done using the following conventional

techniques/Methods/Tools. These are also called as Primary sources of information
The analyst must decide on the information-gathering tool and how it must be used. Although there
are no standard rules for specifying their use, an important rule is that information must be acquired
accurately, methodically, under the right conditions, and with minimum interruption to user personnel.
There are various information-gathering tools. Each tool has a special function depending on the
information needed.

 Review of Literature, Procedures and Forms :- When available, all documentation (in the form of
forms, records, reports, manuals, etc) is organized and evaluated. The procedures manuals contain
the requirements of the system. This helps in determining to what extent the goals are met by the
present system. Day to day problems may have forced changes that are not reflected in the manual.
Regarding existing forms, the analyst needs to find out how they are filled out, how useful they are
to the user, what changes need to be made and how easy they are to read. Very few system problems
are unique. The increasing number of software packages suggests that problem solutions are
becoming standardized. Therefore a search of the literature through professional references and
procedures manuals, textbooks, company studies, government publications or consultant studies may
prove invaluable.

Disadvantages:
  The primary drawback of this search is time.
   Sometimes it will be difficult to get certain reports.
  Publications may be expensive and the information may be out dated due to a time lag in
publication.
Procedures manuals and forms are useful sources for the analyst. They describe the format
and functions of the present system. Most of the manuals include system requirements, which helps
to determine how well various objectives are met. Up-to-date manuals save hours of information–
gathering time. Printed forms are widely used for capturing and providing information.

 Interviews: On-site observation is less effective for learning about people’s perceptions, feelings
and motivations. The alternative is the personal interview and the questionnaire. In both the methods
heavy reliance is placed on the interviewees report for information about the job, the present system,
or experience. The quality of the response is judged in terms of its reliability and validity.

Reliability means that the information gathered is dependable enough to be used for making decisions about
the system being studied. Validity means that the questions to be asked are worded in such a way as to elicit
(obtain) the intended information. So the reliability and validity of the data collected depends on the design
of the interview or questionnaire and the manner in which each instrument is administered.
The interview is a face-to-face interpersonal role situation in which a person called the interviewer asks a
person being interviewed questions designed to gather information about a problem area. The interview is
the oldest and most often used device for gathering information in system work. It can be used for two main
purposes
1) As an exploratory device to identify relations or verify information.
2) To capture information, as it exists.
In an interview, since the analyst (interviewer) and the person interviewed meet face to face, there is
an opportunity for flexibility in collecting information. The analyst is also in a position to observe the
subject. In contrast, the information obtained through a questionnaire is limited to the subject’s written
responses to predefined questions.
The advantages of interview are
1) Its flexibility makes the interview a superior technique for exploring areas where not much is known
about what questions to ask or how to formulate questions.
2) 2) It offers a better opportunity than the questionnaire to evaluate the validity of the information
gathered. The interviewer can observe not only what subjects say but also how they say it.
3) It is an effective technique for eliciting information about complex subjects and for probing the
sentiments underlying expressed opinions.
4) Many people enjoy being interviewed, regardless of the subject. They usually cooperate in a study when
all they have to do is talk. In contrast the percentage of returns to a questionnaire is relatively low.

The disadvantages of an interview are

1) The major drawback of the interview is the long preparation time.
2) Interview also takes a lot of time to conduct, which means time and money.

In an interview, since the analyst and the person interviewed meet face to face, there is an opportunity
for greater flexibility in eliciting information. The interviewer is also in a natural position to observe the
subjects and the situation to which they are responding. In contrast the information obtained through a
questionnaire is limited to the written responses of the subjects to predefined questions.
The art of interviewing:
Interviewing is an art. The analyst learns the art by experience. The interviewer’s art consists of creating a
permissive situation in which the answers offered are reliable. Respondent’s opinions are offered with no
fear of being criticized by others. Primary requirements for a successful interview are to create a friendly
atmosphere and to put the respondent at ease. Then the interview proceeds with asking questions properly,
obtaining reliable responses and recording them accurately and completely.

Arranging the interview:

The interview should be arranged so that the physical location, time of the interview and order of
interviewing assure privacy and minimal interruption. A common area that is non-threatening to the
respondent is chosen. Appointments should be made well in advance and a fixed time period adhered to as
closely as possible. Interview schedules generally begin at the top of the organization structure and work
down so as not to offend anyone.
Guidelines to a successful interview:
In an interview the following steps should be taken.

1) Set the stage for the interview.

2) Establish rapport: put the interviewee at ease.
3) Phrase questions clearly and succinctly
4) Be a good listener, avoid arguments.
5) Evaluate the outcome of the interview.

1) Stage setting: This is a relaxed, informal phase where the analyst opens the interview by focusing
on

a) The purpose of the interview

b) why the subject was selected and
c) the confidential nature of the interview.

After a favorable introduction, the analyst asks the first question and the respondent answers it and
goes right through the interview. The job of the analyst should be that of a reporter rather than a
debater. Discouraging distracting conversation controls the direction of the interview.

2) Establishing rapport: Some of the pitfalls to be avoided are

1.  Do not deliberately mislead the user staff about the purpose of the study. A careful briefing is
required. Too much of technical details will confuse the user and hence only information that is
necessary has to be given to the participants.
2.  Assure interviewees confidentiality that no information they offer will be released to
unauthorized personnel. The promise of anonymity is very important.
3.  Avoid personal involvement in the affairs of the users department or identification with one
section at the cost of another.
 4.  Avoid showing off your knowledge or sharing information received from other sources.
5.  Avoid acting like an expert consultant and confidant. This can reduce the objectivity of the
approach and discourage people from freely giving information
6.  Respect the time schedules and preoccupations of your subjects. Do not make an extended social
event out of the meeting.
7.  Do not promise anything you cannot or should not deliver, such as advice or feedback.
8.  Dress and behave appropriately for the setting and the circumstances of the user contact.
9.  Do not interrupt the interviewee. Let him/her finish talking.
3) Asking the questions: Except in unstructured interviews, it is important that each question is
asked exactly as it is worded. Rewording may provoke a different answer .The question must also be
asked in the same order as they appear on the interview schedule. Reversing the sequence that
destroys the comparability of the interviews. Finally each question must be asked unless the
respondent, in answering the previous question, has already answered the next one.
4) Obtaining and recording the response: Interviews must be prepared well in order to collect
further information when necessary. The information received during the interview is recorded for
later analysis.
5) Data recording and the notebook: Many system studies fail because of poor data recording.
Care must be taken to record the data, their source and the time of collection. If there is no record of
a conversation, the analyst won’t be remembering enough details, attributing to the wrong source or
distorting the data.
The form of the notebook varies according to the type of study, for the amount of data, the number
of analysts, and their individual preferences. The “notebook” may be a card file, a set of carefully
coded file folders. It should be bound and the pages numbered.
Types of Interview:-
Interviews range from highly unstructured to the highly structured alternative in which the questions and
responses are fixed.
The unstructured alternative: The Unstructured interview is non-directive information gathering
technique. It allows respondents to answer questions freely in their own words. The responses in this case
are spontaneous and self-revealing. The role of the analyst as an interviewer is to encourage the respondent
to talk freely and serve as a catalyst to the expression of feelings and opinions. This method works well in a
permissive atmosphere in which subjects have no feeling of disapproval.
The structured alternative: In this alternative the questions are presented with exactly the same wordings
and in the same order to all subjects. Standardized questions improve the reliability of the responses by
ensuring that all subjects are responding to the same questions. Structured interviews and questionnaires
may differ in the amount of structuring of the questions. Questions may be either closed or open-ended. An
open-ended question requires no response direction or specific response.
 Questionnaires: Questionnaires may be used for getting initial responses that can then be analyzed
to choose people to interview or to get a wider perspective on particular issues that have arisen
elsewhere. Or the questionnaire might be used to get opinions and views about specific suggestions
for the kind of help that would be most appreciated. Questionnaires are much more informal, and
they are good tools to gather requirements from stakeholders in remote locations or those who will
have only minor input into the overall requirements. Questionnaires can also be used when you have
to gather input from dozens, hundreds, or thousands of people.
 This tool has collection of questions to which individuals respond. The advantages of
questionnaire are
1. It is economical and requires less skill to administer than the interview.
2. Unlike the interview, which generally questions one subject at a time, a questionnaire can be
administered to large numbers of individuals simultaneously.
3. The standardized wording and order of the questions and the standardized instructions for
reporting responses ensure uniformity of questions.
4. The respondents feel greater confidence in the anonymity of a questionnaire than in that of an
interview. In an interview, the analyst usually knows the user staff by name, job function or other
identification. With a questionnaire, respondents give opinions without fear that the answer will be
connected to their names.
5. The questionnaire places less pressure on subjects for immediate responses. Respondents have
time to think the questions over and do calculations to provide more accurate data.

Procedure for questionnaire construction:

There are six steps for constructing a questionnaire
1. Decide on the data should be collected, that is used to define the problem to be investigated.
2. Decide the type of questionnaire should be used (closed or open ended).
3. Outline the topics for the questionnaire and then write the questions.
4. Edit the questionnaire for technical defect that reflect personal values.
5. Pretest the questionnaire to see how well it works
6. Do a final editing to ensure that questionnaire is ready for administration. This includes a close look
at the content, form and sequence of questions as well as the appearance and clarity of the procedure
for using the questionnaire.
Important thing in questionnaire construction is the formulation of reliable and valid questions. To do a
satisfactory job, the analyst must focus on question content, wording and format. The following criteria has
to be considered for constructing a questionnaire
 Question content (Is the question necessary?, does it cover the area intended?, does the participants
have proper information to answer the questions?, is the question biased?)
 Question wording (Is the question worked for the participant’s background and experience?, Can the
question be misinterpreted?, is the question clear and direct?)
 Question format ( How can the question be asked?, Is the response form easy or adequate for the
job?, Is there any contamination effect?)

Types of Questionnaires:-
Questionnaire is written with space provided for the response. Such questions are more often used in
interviews than in questionnaires because scoring takes time. Closed questions are those, in which the
responses are presented as a set of alternatives. There are five major types of closed questions.
1. Fill in the blanks: in which questions request specific information. These responses can be statically
analyzed.
2. Dichotomous (Yes/No type): in which questions will offer two answers. This has advantages
similar to those of the multiple-choice type. Here the question sequence and content are also
important
 3. Ranking scales questions: Ask the respondent to rank a list of items in order of importance or
preference
4. Multiple-choice questions: Offer respondents specific answer choices. This offers the advantage of
faster tabulation and less analyst bias due to the order in which the questions are given. Respondents
have a favorable bias toward the first alternative item. Alternating the order in which answer choices
are listed may reduce bias but at the expense of additional time to respond to the questionnaire.
5. Rating scales: These types of questions are an extension of the multiple-choice design. The respondent is
offered a range of responses along a single dimension. Open-ended questions are ideal in exploratory
situations where new ideas and relationships are sought.

Four alternative observation methods are considered:-

1) Natural or contrived:- A natural observation occurs in a setting such as the employee’s place of work,
the observer in a place like a laboratory sets up a contrived observation.
2) Obtrusive or unobtrusive:- An obtrusive observation takes place when the respondent knows he/she is
being observed; an unobtrusive observation take place in a contrived way such as behind a one-way mirror.

3) Direct or indirect:-
• Direct Observation: Observation of participants in their natural setting is used to understand the
nature of the tasks and the context in which they are performed. Sometimes the observation is
carried out by trained observers who record their findings and report them back to the design team,
and sometimes the observation is carried out by or with a member of the design team.
• Indirect Observation: Diaries and interaction logging are used less often within the requirements
activity. Interaction logging on an existing system may be used to provide some data about how a
task is performed currently, but the information is too tightly coupled with details of the existing
computer support to be particularly helpful if a completely new system is planned.

4) Structured or unstructured. In a structured observation, the observer looks for and records a specific
action. Unstructured methods place the observer in a situation to observe whatever might be pertinent at
the time. Any of these methods may be used in information gathering. Natural, direct, obtrusive and
unstructured observations are frequently used to get an overview of an operation. Electronic observation
and monitoring methods are becoming widely used tools for information gathering.
Electronic observation and monitoring methods :-
• Studying Documentation: Manuals and other documentation are a good source of data about the
steps involved in an activity and any regulations governing a task. Such documentation should not be
used as the only source, however, as everyday practices may augment them and may have been
devised by those concerned to make the procedures work in a practical setting. Taking a user-centered
view of development means that we are interested in the everyday practices rather than an idealized
account.
• Researching Similar Products: By observing and analyzing similar products, it is very easy to
establish the requirements of your own product
• Prototyping: Prototyping is a relatively modern technique for gathering requirements. In this
approach, you gather preliminary requirements that you use to build an initial version of the solution
— a prototype. You show this to the client, who then gives you additional requirements. You change
the application and cycle around with the client again. This repetitive process continues until the
product meets the critical mass of business needs or for an agreed number of iterations.
When the customer finds it difficult to articulate their requirements, prototyping provides a
low cost way to help them visualize a potential solution. Often customers are not entirely sure what
they want (particularly in software development projects) and a prototype can help tease out their
requirements.
A proof of concept may be required if the technology is innovative, or the project team are
unfamiliar with it. A proof of concept confirms the IT department's capability to deliver the required
solution.
• Following people around: This technique is especially helpful when gathering information on
current processes. You may find, for instance, that some people have their work routine down to such
a habit that they have a hard time explaining what they do or why. You may need to watch them
perform their job before you can understand the entire picture. In some cases, you might also want to
participate in the actual work process to get a hands-on feel for how the business function works
today.
• Brainstorming: On some projects, the requirements are not "uncovered" as much as they are
"discovered." In other words, the solution is brand new and needs to be created as a set of ideas that
people can agree to. In this type of project, simple brainstorming may be the starting point. The
appropriate subject matter experts get into a room and start creatively brainstorming what the solution
might look like. After all the ideas are generated, the participants prioritize the ones they think are the
best for this solution. The resulting consensus of best ideas is used for the initial requirements.
• Storyboards: Storyboards help developers visualize the sequence and interconnectedness of their
work. They allow for a "big picture" approach that may be very useful in requirements gathering.
• State transition diagrams: State transition diagrams allow developers and users to see how a
program might behave. This anticipation of events is useful when discussing requirements.

• Delphi Method:- It is used primarily for gaining consensus from several experts on a subject and
helps to reduce bias. The experts take part anonymously with the help of a facilitator.
The facilitator solicits ideas and comments from the experts with help of a questionnaire,
summarizing the responses and circulating for further comments.

o Advantages
 Is conducted in writing and does not require face-to-face meetings
 Helps keep attention directly on the issue:
 Is inexpensive.
• Research and Site Visits:- By surfing on internet and studying research papers and journals system
analyst have to collect the information. This will give the idea how others have solved similar
problems just by click.
• RAD(Mock forms and tables to simulate the implemented system):-In general, RAD systems
provide a number of tools to help build graphical user interfaces that would normally take a large
development effort. The most popular RAD system for Windows is Visual Basic.
So, which data-gathering technique should you choose? There is no right or wrong answer here. The
above techniques have their own pros and cons. For example, interviews are ideal in order to gather
 data from smaller groups while questionnaires are ideal to gather data from a geographically spread
user base. Other forces that come into play are the nature of the task, the participants, the analyst, the
resources that are available and a multitude of other factors. Thus, you may find yourself combining
more than one of the above techniques in order to be able to interpret data that is unclear.

Tools For Data Recording/ Structured Analysis Tools

Data Flow Diagram (DFD)

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. A DFD is often used as a preliminary step to create an
overview of the system, which can later be elaborated. DFDs can also be used for the visualization of data
processing (structured design).
A DFD shows what kind of information will be input to and output from the system, where the data
will come from and go to, and where the data will be stored. It does not show information about the timing
of process or information about whether processes will operate in sequence or in parallel which can be
shown on a flowchart.

Different symbols to construct the DFD are as under.

 External Entry - Square defines a source or destination of data.

 Data flow - Arrow identifies data flow, means the data in motion. It is a pipeline through which
information flows.

 Process - Circle or a bubble represents a process that transforms incoming data flow into
outgoing data.

 Data Store - Open rectangle is a data store, or data at rest, or a temporary repository of data
  Processes should be named and numbered for easy reference

 The direction of flow is from top to bottom and from left to right

 Data flow from the source to destination, although they may flow back to a source

 When a process is exploded into lower level details, they are numbered

 The names of data stores, sources, and destinations are written in capital letters. Process and data
flow names have the first letter of each word capitalized

Data Flow Diagrams (DFD) helps us in identifying existing business processes. It is a technique we
benefit from particularly before we go through business process re-engineering.
At its simplest, a data flow diagram looks at how data flows through a system. It concerns things like where
the data will come from and go to as well as where it will be stored. But you won't find information about
the processing timing (e.g. whether the processes happen in sequence or in parallel).
We usually begin with drawing a context diagram, a simple representation of the whole system. To
elaborate further from that, we drill down to a level 1 diagram with additional information about the major
functions of the system. This could continue to evolve to become a level 2 diagram when further analysis is
required. Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very common.
Please bear in mind that the level of detail asked for depends on your process change plan.

FD Example
 *Explain this example for each process

Data Dictionary

A Data Dictionary is a document that describes the basic organization of a database. Typically a
data dictionary will contain a list of variables in the database as well as the assigned variable names
and a description of each type of variable (e.g. character, numeric, dates). The data dictionary should
also include the values accepted for each variable and any helpful comment such as important
exclusions and skip patterns. The data dictionary is used primarily for data analysis.
A data dictionary is an integral part of a database. It holds information about the database and the
data that it stores, i.e., the meta-data. Any well designed database will surely include a data
dictionary as it gives database administrators and other users easy access to the type of data that they
should expect to see in every table, row, and column of the database, without actually accessing the
database. Since a database is meant to be built and used by multiple users, making sure that everyone
is aware of the types of data each field will accept becomes a challenge, especially when there is a
lack of consistency when assigning data types to fields. A data dictionary is a simple yet effective
add-on to ensure data consistency.

* Draw Data Description Hierarchy

Components of Data Dictionary

A data dictionary is a document that outlines your table designs, the data type for each
column and a brief explanation of each field.
 Data Elements- smallest unit of data that provides for no further decomposition.
For example: date consists of day, month and year
 Data Structure- a group of data elements handled as a unit.
For example: phone is a data structure consisting of four data elements: area-code-exchange-
number-extension.
 Data Flows and Data Stores- data flows are data structures in motion, whereas data stores are data
structures at rest. A data store is a location where data structures are temporarily located.
 Data Flows = Data Structures in Motion
 Data Stores = Data Structures at Rest

Example
 *Explain this example

Some of the typical Columns in a data dictionary entry are:

•    Name of the table

•    Name of the fields in each table
•    Data type of the field (integer, date, text…)
•    Brief description of the expected data for each field
•    Length of the field
•    Default value for that field
•    Is the field Nullable or Not Nullable?
•    Constraints that apply to each field, if any
Format and Storage
There exists no standard format for creating a data dictionary. Meta-data differs from table to table.
Some database administrators prefer to create simple text files, while others use diagrams and flow charts to
display all their information. The only prerequisite for a data dictionary is that it should be easily searchable.
Again, the only applicable rule for data dictionary storage is that it should be at a convenient location that is
easily accessible to all database users. The types of files used to store data dictionaries range from text files,
xml files, spreadsheets, an additional table in the database itself, to handwritten notes. It is the database
administrator’s duty to make sure that this document is always up to date, accurate, and easily accessible.
Creating the Data Dictionary
First, all the information required to create the data dictionary must be identified and recorded in the
design documents. If the design documents are in a compatible format, it should be possible to directly
export the data in them to the desired format for the data dictionary. For example, applications like
Microsoft Visio allow database creation directly from the design structure and would make creation of the
data dictionary simpler. Even without the use of such tools, scripts can be deployed to export data from the
database to the document. There is always the option of manually creating these documents as well.
Advantages of a Data Dictionary
The primary advantage of creating an informative and well designed data dictionary is that it exudes
clarity on the rest of the database documentation. Also, when a new user is introduced to the system or a
new administrator takes over the system, identifying table structures and types becomes simpler.  In
scenarios involving large databases where it is impossible for an administrator to completely remember
specific bits of information about thousands of fields, a data dictionary becomes a crucial necessity.

Decision Tree
Decision Trees provide a graphical representation of decision logic which non-technical people find
easy to understand. Once the data elements are defined in the data dictionary, we begin to focus on the
processes.

For example:
Bookstores get a trade discount of 25%; for orders from libraries and individuals, 5% allowed on orders of
6-19 copies per book title; 10% on orders for 20-49 copies per book title; 15% on orders for 50 copies or
more per book title

Advantages of Decision Tree

 To verify logic and resolving the problems that involves a few complex decisions.
 On the basis of condition action is represented sequentially.
 Helps the designer to visualize the current customers view.

Disadvantages of Decision Tree

 Difficult to construct and understand
 From analysis point of view It is a difficult task to generate a Decision Tree.

Structured English
 Structures English is like structured programming, it uses logical construction and sentences
designed to carry out instructions. Designs are made through IF, THEN, ELSE, and SO statements.
 WE can actually make structured English more compact by using terms defined by the data
dictionary
 Ex. The process ORDER may have the data element ORDER-SIZE which defines different values:
MINIMUM : - 5 or fewer copies per book title
SMALL : - 6 to 19 copies
An Example
IF order is from Bookstore
and-IF order is for 6 copies or more per book title
THEN: Discount is 25%
ELSE (order is for fewer than 6 copies per book title)
SO: no discount is allowed
ELSE (order is from libraries or individuals)
SO-IF order is for 50 copies or more per book title
Discount is 15%
ELSE IF order is for 20 to 49 copies per book title
Discount is 10%
ELSE IF order is for 6 to 19 copies per book title
Discount is 5%
ELSE (order is for less than 6 copies per book order)
SO: no discount is allowed

Decision Table
 It is a table of possibilities for defining a problem and the actions to be taken. It is a single representation
of the relationships between conditions and actions. It consists of two parts: stub and entry. The stub part
is divided into an upper quadrant called the condition stub and a lower quadrant called the action stub
The entry part is also divided into an upper quadrant, called the condition entry and a lower quadrant
called the action entry
It is a table of possibilities for defining a problem and the actions to be taken. It is a single
representation of the relationships between conditions and actions.
 It consists of two parts:
 The stub part is divided into an upper quadrant called the condition stub and a lower
quadrant called the action stub.
 The entry part is also divided into an upper quadrant, called the condition entry and a lower
quadrant called the action entry.

ELEMENTS of Decision Table

 Elements  Location  Definition

 Condition Stub  Upper Left  Sets forth in question from the condition that
Quadrant may exist
 Action Stub  Lower Left  Outlines in narrative form the action to be
Quadrant taken to meet each condition
 Condition Entry  Upper  Provides answers to questions asked in the
Right condition stub quadrant
Quadrant

 Action Entry  Lower  Indicates the appropriate action resulting from

Right the answers to the conditions in the condition
Quadrant entry quadrant.

Explain the above example.

Cost Benefit Analysis (CBA):-

Data Analysis
 It is a prerequisite to the Cost and Benefit Analysis.
  System investigation and data gathering lead to an assessment of current findings. Here we will
determine how efficiently certain steps are performed and how they contribute to achieving the
intended goals and cost of making improvements.
 The basic purpose of cost and benefit analysis is basically to determine if the project is economically
viable. The simplest way to do cost and benefit analysis is to list the costs (Hardware, consumables,
operating, personnel) associated with the projects and benefits that are expected.
Meaning of Cost-benefit analysis
 Cost-benefit analysis is used to determine the economic feasibility of a project.
 When new systems are proposed, the cost is a major consideration which impacts on the decision to
accept or reject the proposed system.
 The people funding the system want to know whether they will get a good return for the money they
invest in the system. In large companies there is often competition to get access to financial
resources for innovative projects. So, to win support for a project, estimates of costs and benefits
must be calculated. This is called a cost-benefit analysis.
 The CBA is also defined as a systematic process for calculating and comparing benefits and costs of
a project, decision or policy.

CBA has two purposes:

 To determine if it is a sound investment/decision (justification/feasibility)

 To provide a basis for comparing projects. It involves comparing the total expected cost of each
option against the total expected benefits, to see whether the benefits outweigh the costs, and by how
much.
Benefits
 Increase in activities that contribute to profit
 Reduction in any day to day operation cost
 Improving Performance
 Improved company image
 Staff efficiency increase
 Faster delivery of output
 Provides greater customer satisfaction
 More timely information
 Improved organizational planning
 Faster decision making capability
 Improved resource control
Types of costs
 One Time Costs
 Hardware costs
 Consumable like paper, printer ribbon etc. during development
 Office space for development team
 Training for the staff using the system(Operating Cost)
 Cost of preparing computer centre.
 Printing new forms
 Software development cost.
 Recurring Costs
 Personnel cost :- Salary for operators and staff
 Consumables like paper, printing ribbon, floppies etc.
 Office rent
 Electric Bill
 Telephone bill.
For example
A new automated customer invoicing system has been recommended for our organization by a firm
of consultants. The requirements are already known, and we now want to carry out a cost benefit
analysis. The system will cost £50,000 to develop, and will have a projected useful life of five years
from the time it is installed, one year from now. After five years, the system database can be
transferred to the replacement system, a saving of approximately £10,000.