The requirement engineering process
can be described in five distinct steps
• Ask the customer , the user, and
others what the objectives for the
system or product ,what is to be
accomplished, how the system fit into
needs of the business and finally how
the system is to be used on a day to
Sawyer suggests a set of detailed
guidelines for requirement elicitation
• Assess the business and technical feasibility for the
• Identify the people who will help to specify
• Define technical environment( os ,system architecture,
tele comm) into which the system will be placed
• Identify “domain constraints” (characteristics of the
business environment specific to the application domain)
• Define one or more requirement elicitation method
• Solicit participation from many people so that
requirements are define from different points of view.
• Analysis categories requirements and
organize them into related subsets,
explore each requirement in
relationship to others, examine
requirements for consistency , and
rank requirement based on the need
s of customers.
• Is each requirement consistent with the overall
objectives for the system?
• Is the requirement really necessary or does it
represent an add – on feature that may not
essential to the objective of the system ?
• Do any requirement conflict with other
• Is requirement testable, once implemented?
• Is each requirement is achievable in the technical
• In the context of computer based systems , the
term specification means different things to
• A specification can be a written document , a
graphical mode , a formal mathematical model.
• The system specification is the final work product
by the system and requirement engineer. it
serves as the foundation for hardware
• It describe the function and performance of a
computer based system and the constraints that
will govern its development.
• To develop the system model, a
system model template is used. the
system engineer allocates system
elements into each of five processing
regions with in the template
• User interface, input , system
function and control ,output
• Requirement validation examines the
specification to ensure that all system
requirement have been stated unambiguously ;
that inconsistencies ,omissions, and errors have
been detected and corrected.
• the primary requirement validation mechanism is
the formal technical review. The review team
includes system engineers, customers ,users and
other stakeholders who examine the system
specification looking for errors in content or
• Are requirement stated clearly?
• Is the requirement bounded in
• Does the requirement violate any
• Is the requirement is testable?
• Is the requirement traceable to
overall system / product objectives?
• Requirement management is a set of
activities that help the project team to
identify, control, and track requirement
and changes to requirements at any time
• traceability tables
– Features traceability table
– Source traceability table
– Dependency traceability table
– Subsystem traceability table
– Interface traceability table
– Features traceability table: shows how
requirement relate to important customer
observable system features
– Source traceability table: identifies source of
– Dependency traceability : how requirement
are relate one another.
– Subsystem traceability requirement by the
subsystem that governs.
– Interface traceability table: how requirements
relate to both internal and external system
• Requirement analysis is a software
engineering task that bridges the gap
between system level requirement
engineering and software design.
• Requirement analysis allows the software
engineer to refine the software allocation
and builds models of data , functional and
behavioral domains that will be treated by
• The information domain of a problem must be
represented and understood.
• The function that the software is to perform must
• The behavior of the software must be
• The models that depict information, function and
behavior must be partitioned in a manner that
uncovers detail in a layered fashion.
• The analysis process should move from essential
information toward implementation detail.
Davis suggests a set of guiding principles for
1. Understand the problem before you begin to
create the analysis model.
2. Develop prototypes that enable a user to
understand how human / machine interaction
3. Record the origin of and reason for every
4. Use multiple view of requirements (building
data, functional and behavioral model).
5. Rank requirements
6. Work to eliminate ambiguity.
• The information domain contains
three different views of the data
1. Information content and
relationships (data model)
2. Information flow
3. Information structure.
• Information content represents the
individual data and control objects that
constitute some large collection of
information transformed by the software.
• For example , the data object , PAYCHECK ,
is a composite of a number of important
pieces of data: the payees name, the net
amount to be paid, the gross pay,
deductions , and so forth. Therefore , the
content of PAYCHECK is defined by the
attribute that are needed to create it.
• Data and control objects can be related to
other data and control objects.( the data
object PAYCHECK has one or more
relationship with the other objects timecard
• Information flow represents the
manner in which data and control
change as each move through a
• Input objects are transformed to
intermediate information, which is
further transformed to output.
• Along this transformation path ,
additional information may be
introduced from an existing data
• Information structure represents the
internal organizations of various data
and control items.
• Are data or control items to be
organized as an n – dimensional
table or as a hierarchical tree
structure? With in the context of the
structure, what information is related
to other information?
• Feasibility study is carried out whenever there is
a complex problem or opportunity.
• A feasibility study is undertaken to determine the
possibility or probability of either improving the
existing system or developing completely new
• It helps to obtain an overview of the problem and
to get rough assessment of whether feasible
NEED FOR FEASIBILITY
• Answer the question whether a new system is to
be installed or not ?
• Determine the potential of the existing system.
• Improve the existing system
• Know what should be embedded in the new
• Define the problems and objectives involved in a
• Avoid costly repairs at a later stage when the
system is implemented.
• Avoid crash implementation of a new system.
• Avoid the “hardware approach” (getting computer
first then deciding how to use it. )
• Steering committee .
• System analyst, rep from dept,
chairman of that organization.
• Technical feasibility.
• Economical feasibility.
• Operational feasibility.
• Can the work for the project be done with
the present equipment , current
procedures , existing software technology
and available personnel ?
• If new technology is needed what
alternatives will be needed in the present
structure and work ethos?
• Adequacy of available technology.
• Adequacy of hardware.
• Availability of computer.
• Support facilities and operating time etc.
• Firstly identifies the alternatives.
• Determines saving and expected cost of
• One time cost
– Feasibility study cost
– The cost for converting present system to new
– Construction or remodeling computer room.
– Cost involved in software packages.
• Recurring cost
– Purchase of equipments
– Salaries of personnel.
Return on investment analysis
ROI = net earnings/ total investment
ROI clearly indicates whether you are
working on aright problem or not.
• Will the system is useful , if it is
• Will there be resistance from users?
• “equipments do not cry but people do cry”
• The existing personnel normally worry
about job security ,changes in job context
and so on whenever new systems are
• If their voice are not considered at this
stage, the problem will be magnified at
the implementation stage.