Requirement

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

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.

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.

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.

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?

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.

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.

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.

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?

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

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.

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.

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.

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.

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.

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)

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. Transfo rm2

Transform 1

Data

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?

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.

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. )

FEASIBILITY STUDY • Steering committee . • System analyst, rep from chairman of that organization. • Technical feasibility. • Economical feasibility. • Operational feasibility.

dept,

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.

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.

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.

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.