REQUIREMENT ENGINEERING: AN OVERVIEW

Transcription

1 Internatinal Jurnal f Research in Engineering & Technlgy (IJRET) ISSN Vl. 1, Issue 2, July 2013, Impact Jurnals REQUIREMENT ENGINEERING: AN OVERVIEW SHIPRA GUPTA 1 & MANOJ WADHWA 2 1 Assistant Prfessr, Wrld Institute f Technlgy, Shna, Haryana, India 2 Prfessr, Echlen Institute f Technlgy, Faridabad, Haryana, India ABSTRACT Sftware engineering as a discipline is still evlving and nt yet stable. The peple assciated with cmputer field ften face prblems with the sftware. Sftware Requirements and estimatin prvides sftware prfessinals the infrmatin they need t address requirements engineering and estimatin. Requirements frm the basis f the initial estimates and plans n which the sftware prduct is built and validated. This paper recapitulates the definitin f sftware requirement engineering. This paper discusses the basic cncepts and prvcatins fr requirement engineering and estimatin. KEYWORDS: Requirements, SRS, Functinal Requirements, Nn-Functinal Requirements, DFD INTRODUCTION Sftware prjects are subject t a multitude f prblems that lead t schedule and cst verruns and pr quality f delivered sftware. This becmes a hurdle in the prcess f sftware develpment fr the sftware prfessinals. The basic definitin f sftware engineering was given by Fritz Bauer as, the establishment and use f sund engineering principles in rder t btain, ecnmically, sftware that is reliable and wrks efficiently n real machines.ieee in its standard , defines sftware engineering as, the applicatin f a systematic, disciplined, quantifiable apprach t the develpment, peratin and maintenance f apprach; that is, the applicatin f engineering t sftware.[7] IEEE in its standard , defined requirements as, a cnditin r capability that must be met r pssessed by a system r a system cmpnent t satisfy a cntract, standard, specificatin r ther frmally impsed dcuments.[3] Zave[9] prvides ne f the clearest definitins f RE: Requirements engineering is the branch f sftware engineering cncerned with the real-wrld gals fr, functins f, and cnstraints n sftware systems. It is als cncerned with the relatinship f these factrs t precise specificatins f sftware behavir, and t their evlutin ver time and acrss sftware families. CLASSIFICATION OF REQUIREMENTS Requirements can be classified as Functinal Requirements: Functinal requirements describe an interactin between the system and its envirnment. They fcus n the what f the system and identify the functins and data related requirements. Nn-Functinal Requirements: These requirements fcus n hw well aspects f the system and identify attributes under which the system needs t perate.

2 156 Shipra Gupta & Manj Wadhwa Nn-functinal requirements can be further classified as Prduct Requirement: Requirements which specify that the delivered prduct must behave in a particular way e.g. executin speed, reliability Organizatinal Requirements: Requirements which are a cnsequence f rganizatinal plicies and prcedures e.g. prcess standards used, implementatin requirements External Requirements: Requirements which arise frm factrs which are external t the system and its develpment prcess e.g. interperability requirements, legislative requirements. Figure 1: Nn-Functinal Requirements Behaviral Requirements: These requirements include any and all infrmatin necessary t determine if the runtime behavir f a given implementatin is acceptable. The behaviral requirements define all cnstraints n the system utputs (e.g. value, accuracy, timing) and resulting system state fr all pssible inputs and current system state. Develpmental Quality Attributes: Develpmental Quality Attributes include any cnstraints n the attributes f the system s static cnstructin. These include prperties like testability, changeability, maintainability and reusability.[8] ACTIVITIES OF REQUIREMENT ENGINEERING Requirement can be divided int tw main set f activities: Requirement Definitin and Requirement Management. Requirement Definitin Cnsists f Requirement Elicitatin r Gathering f Requirements: Requirement elicitatin prtends discvery f all pssible requirements.[1]

3 Requirement Engineering: An Overview 157 Requirement Analysis r Mdeling: Requirement analysis starts in parallel with requirement elicitatin and invlves refining and mdeling the requirements t diagnse incnsistencies, errrs and ther defects. Requirement Dcumentatin: The requirements that are gathered and mdeled are put tgether in a dcument knwn as sftware requirement specificatin dcument. Requirement Review: The SRS is reviewed by all stake hlders. Requirement Management Cnsists f Requirement Change Management: This invlves systematic handling f changes t agreed requirements (SRS) during the curse f the prject. Requirement Traceability: Requirement traceability is a prcess f ensuring that ne r mre test cases address each requirement.[5] A sign ff by the representatives f the custmer, users and develpment team marks the end f the requirements definitin activities and the start f the requirement management activities. REQUIREMENT DOCUMENTATION The gal f requirement definitin and management phase is t clsely understand the custmer requirements and t systematically rganize the requirements int a specificatin dcument. [4] The requirement dcument is knwn as Sftware Requirement Specificatin Dcument (SRS). SRS frms the basis fr develpment as well as testing activities. The SRS has Three Main Parts: the intrductin t the dcument, the verall descriptin f the system fr which the SRS is written and the specific requirements. Intrductin includes statement f the purpse f the dcument, a statement f the system s scpe, a list f definitins and acrnyms used in the dcument. The verall descriptin prvides a cmplete abstract view. Sftware lifecycle is used t describe the perid f time that starts. SRS Dcument Shuld Have the Fllwing Characteristics Cmpleteness: Fr a sftware requirements specificatin t be cmplete, it must have the fllwing prperties: Descriptin f all majr requirements relating t functinality, perfrmance, design cnstraints and external interfaces. Definitin f the respnse f the sftware system t all reasnable situatins. Cnfrmity t any sftware standards, detailing any sectins which are nt apprpriate. Have full labelling and references f all tables and references, definitins f all terms and units f measure. Be fully defined, if there are sectins in the sftware requirements specificatin still t be defined, the sftware requirements specificatin is nt cmplete.

4 158 Shipra Gupta & Manj Wadhwa Cnsistency: A sftware requirement specificatin is cnsistent if nne f the requirements cnflict. There are a number f different types f cnflictin: Multiple Descriptrs - This is where tw r mre wrds are used t reference the same item, i.e. where the term cue and prmpt are used interchangeably. Oppsing Physical Requirements - This is where the descriptin f real wrld bjects clash, e.g. ne requirement states that the warning indicatr is range, and anther states that the indicatr is red. Oppsing Functinal Requirements - This is where functinal characteristics cnflict, e.g. perfrm functin X after bth A and B has ccurred, r perfrm functin X after A r B has ccurred. Traceability: A sftware requirement specificatin is traceable if bth the rigins and the references f the requirements are available. Traceability f the rigin r a requirement can help understand wh asked fr the requirement and als what mdificatins have been made t the requirement t bring the requirement t its current state. Traceability f references are used t aid the mdificatin f future dcuments by stating where a requirement has been referenced. By having frewrd traceability, cnsistency can be mre easily cntained. Unambiguus: One way f remving ambiguity is t use a frmal requirements specificatin language. The advantage t using a frmal language is the relative ease f detecting errrs by using lexical syntactic analyzers t detect ambiguity. The disadvantage f using a frmal requirements specificatin language is the learning time and lss f understanding f the system by the client. Verifiable: A sftware requirement specificatin is verifiable if all f the requirements cntained within the specificatin are verifiable. A requirement is verifiable if there exists a finite cst-effective methd by which a persn r machine can check that the sftware prduct meets the requirement. Nn-verifiable requirements include "The system shuld have a gd user interface" r "the sftware must wrk well under mst cnditins" because the perfrmance wrds f gd, well and mst are subjective and pen t interpretatin. If a methd cannt be devised t determine whether the sftware meets a requirement, then the requirement shuld be remved r revised. Requirement Review: The requirement review is a manual prcess that invlves peple frm bth client and cntractr rganizatin. They check the requirements dcument fr anmalies and missins.[6] Requirement verificatin is the prcess f checking at each stage whether the utput cnfrms t requirements fr that stage. The basis f verificatin is a apprach invlving tests, inspectins and analysis. Fr maximum effectiveness, review and verificatin shuld nt be treated as a discrete activity t be dne nly at the end f the preparatin f the SRS. Review shuld be treated as a cntinuus activity.[7] Cntinuus Review: Requirements cannt be captured crrectly at the first time, s several iteratins are required t define requirements accurately. This can be achieved by reviewing the requirements n a cntinuus basis. This repeated review is a part f an incremental apprach t elicitatin.

5 Requirement Engineering: An Overview 159 Figure 2: Incremental Life Cycle Mdel Phase End Review: After the SRS dcument is cmplete accrding t the analysts, the dcument underges a frmal review. Withut prper review, the requirements can be incmplete r incrrect. Phase end review invlves reading the SRS, verifying that the SRS is cmplete, clear, cnsistent, mdifiable, traceable, feasible and testable. PROBLEMS RELATED TO SRS Accrding t Ivy Hks [2] the fllwing are the prblems in SRS Writing Bad Assumptins: Bad assumptins typically ccur either because authrs f the SRS d nt have access t sufficient infrmatin r the infrmatin des nt exists. Writing Implementatins instead f Requirements: SRS shuld cntain what is needed and nt hw it is t be prvided. Stating implementatin details frces a design apprach when nt intended. Using incrrect terms: In a specificatin, there are terms t be avided and terms that must be used in a very specific manner. Using wrng Language: Requirements shuld be easy t read and understand. Requirement statements shuld nt be cmplicated by lng winded explanatin f peratins, design r ther related infrmatin. Unverifiable Requirements: Every requirement must be verified when writing the requirements. Requirements may be unverifiable due t the use f ambiguus terms. Missing Requirements: Detailed Requirement analysis is necessary t assure that all requirements are cvered. Over-specifying: Over specificatin is the primary cause f cst verruns n their prgrams. Overspecifying usually arises frm stating smething that is unnecessary r frm stating verly stringent requirements. CONCLUSIONS This paper defined the basic cncepts f sftware engineering. Selectin f apprpriate life cycle mdel is ne f the first step in any sftware prject. Prjects are essentially nn-rutine, planned set f activities, set up t achieve a well defined bjective in a specified time frame using a set f allcated resurces. Any sftware prject starts with requirement gathering. Fr this the brad scpe f the prpsed system shuld be identified. Accrding t the study f the system, the requirements are gathered. Requirement gathering is basically in terms f what is t be built. The gathered requirements are dcumented in a sftware requirement specificatin (SRS) dcument. The requirements are then evaluated by the end-users. Accrding t the gathered requirements a prject team is assigned. The prject manager

6 160 Shipra Gupta & Manj Wadhwa assigns the respnsibilities t the team members accrding t their skills. Anther respnsibility f the prject manager is t estimate the cst f develpment and the time frame within which the develpment will be cmpleted. REFERENCES 1. A.A Puntambaker, Sftware Engineering, Technical Publicatins Pune, Editin-I. 2. Hks, I, writing Gd Requirements, Prceedings f the Third Internatinal Sympsium f the NCSE- Vlume 2, KARL E. Weigers, Sftware Requirements, Editin -2, Micrsft 4. Rajib Mall, Fundamentals f Sftware Engineering, Editin-III, PHI 5. Rick D. Craig, Stefan P. Jaskiel, Systematic Sftware Testing, Editin-II, Artech Huse. 6. Smmerville, Sftware Engineering, Pearsn Editin 7. Swapna Kishre, Rajesh Naik, Sftware Requirements and Estimatin, Tata Mc-Graw Hill Educatin 8. Sftware Engineering Prject Management, Wiley India Editin 9. Zave, P. (1997). Classificatin f Research Effrts in Requirements Engineering. ACM Cmputing Surveys, 29(4):