1. REQUIREMENT
ENGINEERING
The requirement engineering process
can be described in five distinct steps
•Requirement elicitation
•Requirement analysis
•Requirement specification
•System modeling
•Requirement validation
•Requirement management
2. REQUIREMENT ELLICITATION
• 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
day basis.
3. Requirement elicitation
Sawyer suggests a set of detailed
guidelines for requirement elicitation
• Assess the business and technical feasibility for the
proposed system
• Identify the people who will help to specify
requirements.
• 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
(interviews, meetings)
• Solicit participation from many people so that
requirements are define from different points of view.
4. Requirement analysis
• 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.
5. Requirement analysis
• 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
requirement?
• Is requirement testable, once implemented?
• Is each requirement is achievable in the technical
environment?
6. Requirement specification
• In the context of computer based systems , the
term specification means different things to
different people.
• 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
engineering.
• It describe the function and performance of a
computer based system and the constraints that
will govern its development.
7. System modeling
• 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
,maintenance.
8. Requirement validation
• 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
interpretations.
9. Requirement validation
• Are requirement stated clearly?
• Is the requirement bounded in
quantitative terms?
• Does the requirement violate any
domain constraint?
• Is the requirement is testable?
• Is the requirement traceable to
overall system / product objectives?
10. Requirement management
• 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
project proceeds.
• traceability tables
– Features traceability table
– Source traceability table
– Dependency traceability table
– Subsystem traceability table
– Interface traceability table
11. traceability tables
– Features traceability table: shows how
requirement relate to important customer
observable system features
– Source traceability table: identifies source of
each requirement.
– 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
interfaces.
12. Requirement analysis
• 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
software.
13. Analysis principles
• The information domain of a problem must be
represented and understood.
• The function that the software is to perform must
be defined.
• The behavior of the software must be
represented.
• 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.
14. Analysis principles
Davis suggests a set of guiding principles for
requirement engineering.
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
will occur.
3. Record the origin of and reason for every
requirement.
4. Use multiple view of requirements (building
data, functional and behavioral model).
5. Rank requirements
6. Work to eliminate ambiguity.
15. Information domain
• The information domain contains
three different views of the data
1. Information content and
relationships (data model)
2. Information flow
3. Information structure.
16. Information content
• 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
,employee etc)
17. Information flow
• Information flow represents the
manner in which data and control
change as each move through a
system.
• 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
store.
Transform
1
Transfor
m2
Data
18. Information structure
• 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?
19. FEASIBILITY STUDY
• 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
system.
• It helps to obtain an overview of the problem and
to get rough assessment of whether feasible
solution exist.
20. NEED FOR FEASIBILITY
STUDY
• 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
system.
• Define the problems and objectives involved in a
project.
• 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. )
21. FEASIBILITY STUDY
• Steering committee .
• System analyst, rep from dept,
chairman of that organization.
• Technical feasibility.
• Economical feasibility.
• Operational feasibility.
22. Technical 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.
23. Economic feasibility
• Firstly identifies the alternatives.
• Determines saving and expected cost of
each alternatives.
• One time cost
– Feasibility study cost
– The cost for converting present system to new
system.
– Construction or remodeling computer room.
– Cost involved in software packages.
24. Economic feasibility
• Recurring cost
– Rental
– Purchase of equipments
– Salaries of personnel.
-Equipment maintenance.
Return on investment analysis
ROI = net earnings/ total investment
ROI clearly indicates whether you are
working on aright problem or not.
25. Operational feasibility
• Will the system is useful , if it is
implemented?
• 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
proposed.
• If their voice are not considered at this
stage, the problem will be magnified at
the implementation stage.
