Requirement Management – controlling quality at the upstream incommercial software project management

By Sanjay Mohapatra, Associate Professor, Information System,

Xavier Institute of Management, BhubaneswarEmail: sanjay_mohapatra@yahoo.com, sanjaym@ximb.ac.in

Phone: +91 94370 00659, Fax: +91 674 2300995

Abstract

Requirement Management in commercial software application development notonly talks of gathering requirements from the customer it also highlights theneed for a scientific step by step approach for eliciting requirement. Withoutthorough understanding of the requirements from customer point of view at thisstage will lead to a cascading effect later on as it would involve rework and extracost. Hence a complete scientific management approach is needed for this stagewhich is known as requirement management. Requirement Management takesthe accountability of not only meeting the technical specifications of thecustomers but also involves defining an approach to take care of any change inthe requirement needed later on. In addition to that requirement managementtakes care of tracing back each and every functionality requirement to the finaldelivered output. In this paper, based on experience, tools and techniques thatcan be used to gather requirements for commercial software applicationdevelopment have been presented. The process needed for managing changerequests have also been discussed. Using this approach, the author has beensuccessful in meeting customer requirements and reducing rework effort due toless defects being injected during project life cycle.

Subject Area & Key Words: Requirement Management, commercialsoftware, traceability

IntroductionRequirement engineering is an age old topic and is astarting point for any software project. It is an importantcomponent in effective software engineering. However this isthe most difficult tasks to be carried out (Brooks, 1987;Berry et al, 2005). A good requirement management at thebeginning of the software engineering is thus a necessityfor executing projects successfully (Brooks, 1987;Procaccino et al., 2002). This improves quality ofdeliverables, reduces risks associated with softwaredevelopment. The study conducted by Standish group indicatedthat there has been a failure of 78 percent of projectsbecause of ineffective requirement management(www.Standishgroup.com, 2003). This failure has beenattributed to lack of understanding of requirements, unclearrequirement input, incomplete and changing requirements. Ifthe requirements are not understood properly or if notrecorded correctly, will definitely lead to serious issueslater in project which will lead to higher cost, rework, andlate delivery of the software. This also has a potentialrisk of dissatisfied customer. However this study is limitedto past projects and does not relate to (i) commercialsoftware and (ii) does not talk of practices that can befollowed to improve requirement management. A goodrequirement management is necessary to prevent cascadingeffect later on. Controlling quality at requirement stagewill help us see a good quality of output at the end. As aresult requirement management assumes an important role. Ina study Kaindl et al., 2002 indicated that even though ithas been accepted that requirement management plays animportant role in the success of software applicationdevelopment, still available literature does not talk abouta systematic approach for requirement management.

The participants in this stage also play a great role insuccessful execution of the project later on. To understandcustomer’s requirement, it is imperative that the persongathering requirements (called analyst) is knowledgeable in

the domain area that the customer is working in. He shouldbe able to grasp the business process that the customer isfollowing and should be able to see a higher picture of thecustomer’s approach to business with respect to domainknowledge. In addition the analyst should be comfortablewith technical concepts relating to hardware and software,language and any such relevance to system being developed.Also familiarity with any particular tool used by thecustomer will be necessary.

As evident above there are some important activities at therequirement stage and hence there is a need for a systematicapproach. In this paper the author has given a real lifeexperience. The paper is based on experience that the authorhas in implementing various projects and the author hasgiven various issues that he had faced and the systematicapproach that he has been choosing in requirementmanagement.

Literature ReviewStudies have indicated that software quality, projectmanagement and software development activities arepositively influenced by good requirement management (Berryet al, 2005; Brooks, 1987; Weigers, 2003; Stevens, 1994).Literature available from studies (Opdahl, 1994; Mar, 1994;and Macaulay, 1996) reveal that efforts spent on structuredrequirement management at the beginning of the project willreduce defects being injected during the project executionlife cycle thus improving quality of deliverables. Differentliteratures available through studies conducted by Yu(1997), Spanoudakis et al. (1997), Playle et al. (1996),Krogstie et al. (1995), Kosman (1997) have shownimprovements made in reducing risks associated with softwareprojects, reduction in rework effort, reduction in delivereddefects at the customer site through improved requirementmanagement. These improvements have been possible throughdifferent initiatives carried out by these researchers intheir respective studies. This improvement in quality andother aspects of software engineering are also possible for

a product development organization (Vartiainen et al., 2004;Kauppinen et al., 2002; Kujala et al., 2001). Theseimprovements were achieved through different initiativescarried out to improve effectiveness of requirementmanagement. Improvement in requirement management also hadeffects on the culture (also reported by Holtzblatt, 1995),supporting processes and technology and the level ofmotivation among the employees involved in projectexecution. One of the improvement initiatives taken byJacobs (1999) emphasized on breaking requirements intosmaller requirements. This helped in understandingrequirements into smaller comprehensible requirements whichcould then be easily converted to specifications bydesigners. This also helped in understanding customerrequirements and improved communication with customers.Subsequent reviews and defect detections became easier inthe downstream life cycle stages. This inference has alsobeen drawn by Wyder (1996), Wiley (1999), Robinson et al.(1994), Regnell (1995), and Brien (1996) where theseresearchers have used use cases to break requirements intosmaller use cases and then develop the applications based onuse cases.

The conclusion drawn from these studies is that requirementmanagement plays a vital role in software applications. Inthe case of commercial applications, it plays a larger roleas defects and effort spent on inspection or formal reviewsand subsequent reworks extends completion of timeline forcompletion. These results in customer dissatisfaction, delayin final delivery and also quality of the deliverablessuffer. In this paper an attempt has been made todemonstrate tools and techniques that would force theproject team to follow a systematic approach to gatherrequirements from customer.

Requirement ManagementRequirement Management consists of two major activities:gathering requirement analysis and specifications andrequirement change management (www.standishgroup.com).

Gathering requirement specifications are done at the startof any project where as change management is done throughout the project. A related sub activity for gatheringrequirement specification is defining requirementtraceability (MacFarland, 1995). Requirement traceabilityensures that all specifications and functional requirementsgathered at the start have a direct relationship with thefinal design and code being delivered. As a result we canalways say that the final software always meet therequirements as desired by the customer (Ramesh, 1995; Gotelet al., 1997). And this process also takes care of anychange in requirement as desired by the customer at anystage of the project. This will be explained later on inanother section.

Gathering Requirement SpecificationThe output of this stage is to produce a document that willcontain all requirements that the final software will have.Usually this document is termed as System RequirementSpecification (SRS) even though the nomenclature can varydepending on naming convention followed by the customer.The steps followed are: Gather requirements and analysis Documenting requirements Review requirements Obtain customer sign-off for SRS

The activities shown above look quite simple but in realitythey need a lot of preparation and deal with not only domainexpertise but also technical knowledge and inter personalskill. Since an analyst needs to go through a lot ofpreparation and then finally come up with desired output, itis highly recommended a checklist be prepared before handwhich will guide the analyst through requirement gatheringphase. The checklist explained below is the checklist thatthe author has developed based on his own experience in thisfield over last 14 years. However one can modify this

checklist to suit one’s needs. The pre assumption of thismodel is that the analyst has expertise in domain knowledge.

Requirements Analysis Activity Checklist

Understand the present business model – As Is business modelDiscuss with various users/customers to get a grasp on thepresent business model. Even if the analyst has expertise indomain knowledge it is imperative that he understands thepresent business model that the customer has adopted. Hencedraw the present business flow as understood by the analystand present the model to the user. This model should haveall entities, their relationship with each other and ifpossible map to organization structure. This presentationshould be backed up with data. Above presentation in apictorial form is recommended as this will bridgecommunication gap, if any.Once the user accepts the presentation the analyst should gofor defining business requirements. In this phase theobjective is to develop To-Be business process model. Thismodel should contain requirements/functionalities as desiredby the customer. If required all required changes withimplementation time frame be noted down. A checklist is shown below to explain the process describedfor To-Be model.

Develop To-Be business process modelReview any documented future business requirementsCreate To-Be business process flowsDefine integration points of processesObtain end-user agreement on the To-Be Process modelIdentify changes in processesDefine detailed requirementsDetermine future business requirementsDetermine technical architecture requirementsDetermine audit and control requirementsDetermine data security requirements

Define To-Be data modelDefine key data entities by applicationDefine data access by entity for each organization typeDefine data timeliness requirements for major dataentities shared by different organizationsDefine candidate data registries and shared entitiesDefine target data flows between business functionsGather volumes and frequencies for data flows

After defining To-Be model, perform gap analysis. Thisanalysis will consist of finding gaps between the presentsystem and the required system. This analysis will also tryto find the feasibility of adopting available hardware andsoftware configuration to the required To-Be model. At thispoint of time the analyst needs to discuss with the customerregarding the budget for the new system as that willdetermine conversion and integration feasibility ofavailable hardware and software configuration to the desiredfunctionalities. However there would be various issuesrelated to gathering requirements. These are explained inthe next section.

ISSUES in requirements elicitationAttention to the following issues is recommended, during thepreparation of the Requirements Specification documenti. Deciding a time frame between current and future needs ii. Assessing future requirements for building it into the

designiii. Ensuring participation from key members on the

customer’s side, as their normal work takes priority.It is recommended that persons from the customer ISdepartment and end user group are involved as a teamduring requirement analysis.

iv. Conducting comprehensive interviews covering boundaryconditions, error conditions, manual and automaticprocedures, and information flow in the system.

v. Handling conflicting customer needs and getting aclarification in such cases without any prejudice.

vi. Resolving pending issues that depend on policydecisions by the customer

vii. Methods for agreeing on requirements and approvingchanges

viii. Anticipating enhancements and future life-cycleissues

ix. Anticipating maintainability/portability issues inapplication’s life-cycle

x. Pro-actively consult with latent and importantopportunities from technology (e.g. Client/server) tothe customer’s business.

Underlying Difficulties of Requirements ElicitationThe author has experience in doing a detailed requirementstudy across different countries as well across differentcultures. These requirements were also carried out fromdifferent language speaking groups. He (the author) hasworked for customers from India, from USA, Ireland andChina. As a result he has experienced cultural as well aslanguage issues while eliciting requirements. However ascientific approach has always helped in gatheringrequirements and implementing the project successfully.Hence the following points will help in minimizing error atthe time of eliciting requirements.

Articulation Problems These include problems both the user’s expression of

needs and the analyst’s understanding. The users may be aware of their needs, but they are

neither able to articulate them nor understand howtechnology can help them. Even they may be afraid toarticulate it. This behaviour is commonly seen whileexecuting projects in Far East (including China) and inIndia.

There could be a misunderstanding in the concepts andterminology between the users and the designers.

No single person has the complete picture. This isespecially true for complex systems where each user mayhave only a limited perspective of the system to bebuilt.

The analyst may have preconceived idea about the systembeing followed. As a result he fails to appreciate allinformation that the user is providing. This usuallyhappens when the designers believe that they have alreadyunderstood the user’s needs.

Communication Barriers The users and the developers come from different worlds

and have different vocabularies. This is particularlytrue for software applications being outsourced to Indiafrom US and Europe.

Problems due to the medium of communication. Incompatible styles of interaction can lead to a

breakdown of communication. (e.g. some are assertive,some are not assertive, some deal with details and somewith abstraction)

There are different personality types and different valuesystems among people.

A typical problem occurs while reading body language.Where as a person from USA nods his head in agreement toa point being discussed, a person from Far East willshake his head for saying ‘yes’. Differences in bodylanguage sometimes lead to wrong conclusion from theanalyst.

Knowledge and Cognitive Limitations The team of users and analysts don’t have adequate domain

knowledge, so make wrong decisions. No person has perfect memory. Further more, the oral and

written communication may be misinterpreted. People sometimes have difficulty with the scale and

complexity of the system. Some try to simplify theproblem, but not always in the valid way.

The users tend to state the problem in terms of thefavoured solution.

Human Behaviour Issues There are sometimes conflicts and ambiguities in the

roles that the users and the customer IS department playin the elicitation process.

There could be a fear that the new system would result inautomation which would lead to retrenchment in thefuture.

The development of the software system may result in afear in individuals that the system will necessitate allkinds of changes in behaviour of individuals and groups.

Review Requirements Analysis Document with the User GroupOnce the requirement elicitation is complete, SystemRequirement Specification (SRS) document is prepared andreviewed. Review of SRS is important as the analyst needs totake care of proposed architecture, identify required customsupport systems, judge if there could be any issues with theperformance of the system and finally to make businesstransition smooth if there is a transition from presentbusiness model to a new one.

Propose ArchitectureDevelop conceptual application and database architecture

Identify business policies affecting the applicationarchitectureSchedule and conduct meetings on critical applicationdecisionsDefine the baseline to target application replacementmappingDefine the conceptual application architectureDefine the proposed enterprise support systemsDefine the conceptual database architecture

Identify required Custom Support SystemsDetermine requirements for enterprise reporting anddecision support systemsIdentify other sub systems required for production

Assess performance risksIdentify critical processing requirements by theOrganization

Gather throughput capability information forapplications and hardwareInitiate performance assurance tests if necessaryIdentify all perceived risks on performance

Determine business transition requirementsDetermine the resources, business systems, software andhardware to be migratedDetermine the migration priority and sequence forresources and business systemsDetermine implementation contingency situationsDefine an initial transition planDecide on the training needs of the users for thistransition At the end obtain approval for Requirements AnalysisDocument

A sign-off from the customer is needed to start on the nextphase of work.A sample checklist for requirement gathering is shown below:Project Code:Subsystem :Doc Number :Version of requirementsDate of review :Prepared By:Reviewed By : Checked Y/NChecklist Remark

sCheck whether the system objectives are statedclearlyCheck whether the system boundaries areclearly specifiedCheck whether key business events are clearlylistedCheck whether inputs and outputs to each eventdescribed clearlyCheck whether required precedence relationships amongevents a e clearly statedCheck whether all screens are clearly

specifiedCheck whether standards for reports areclearly statedCheck whether periodicity of report generationhas been mentioned Check if security and access control to reports andscreens have been definedCheck if layout has been accepted by the userCheck if delivery to printer is neededintegrating external print matter is neededPublishing (Style sheets, graphics) isaccepted by end userDistribution of reports has been definedCheck whether interfaces with other systemsare describedCheck whether the required hardware isdescribedCheck whether specific software requirementsare documentedIs there a need for any other softwareincluding networking softwareCheck whether networking Issues and connectivityrequirements are documentedCheck whether specific performancerequirements, if any, are documentedCheck whether user interface standards, ifavailable, are documentedCheck whether detailed design standards, ifavailable, are documentedCheck if coding standards, if available, aredocumentedCheck if document standards, if available, aredocumentedCheck whether the required security checks aredocumentedCheck whether system availability requirements aredocumented with respect to following: Seasonal requirement

acceptable down time limits Reliability Transaction Volume &Data Volume Backup &RecoveryIs Data Migration needed?Are the constraints/issues to data migrationbeen definedCheck whether any possible designconstraints/standards are documentedSpecific recommendations or Concurrency issueshave been mentionedBuild up of referential integrity through programs ofusing possible facilities in theCheck if prototyping requirements, if any, aredocumentedCheck whether requirements are traceablethrough downstream processesRequirements are numberedRequirements are stated such that changes canbe tracked

REQUIREMENTS CHANGE MANAGEMENT PROCESS

Need for change ManagementRequirements will change. This is normal, frequent, andgood! The only systems for which requirements will notchange are those that have no users, no customers, and nostakeholders. The fact that requirements are changing onyour project means that people care. There are three tricksto managing the inevitable changes to requirements: (1)reduce the development life cycle time, (2) maintain listsof requirements, and (3) handle each change in anintelligent manner.

Requirements do not remain frozen but change during thecourse of the project. Hence proper methods for handlingrequirement changes are essential. In this paper the authorsuggests a change management procedure to record all thechange requests.This procedure is used after the analyst has received sign-off from the customer. Any request for a change in therequirement after sign-off will be recorded as changerequest. As soon as a change request is received it will befirst logged. A detailed impact analysis is carried out atthis stage. This analysis will calculate the extra effortneeded to accommodate this change request. In addition itwill also find the possible impact on the schedule – i.e. ifthere could be a delay in delivery the final output that waspromised to the customer. This analysis then needs anapproval from the customer as the change request has animplication on initial estimates on cost as well as deliveryschedule. All such change requests are then maintained in aspreadsheet which can be used to find the overall effect allchange requests received.

Requirements change management log templateThe following is a simple change request log template forchange specification. This is used to track the entirechange request received. More elaborate templates can bedesigned by individual projects according to their specificneeds.The simplicity of the template makes it suited for deployment as anExcel spreadsheet.

ChangeRequest#

Request By

Requestraiseddate

Function

OffshoreResp

OnsiteResp

TotalEffort (inPersonHrs)

StartDate

EndDate

FinishByDate

Status

Remarks

Notes:1. A change request can fall into one or more categories

such as Business changes, Design changes, Schedulechanges, Budget changes, or Contract changes.

2. Each change request can typically be in one of the fivefollowing status: Pending, Approved, Rejected, Work inProgress, Completed or Abandoned.

3. It is recommended that the “Impact” clause be exploded toindicate the specific work products that will beimpacted, and the effort involved for each. When this isdone, it becomes easier to track the changes to each ofthese work products.

In performing an impact analysis, it is convenient to have adetail checklist of work product types (such as programs,detailed design specs, UI specs, etc.) that need to be runthrough. Such a checklist is best arrived at by looking atthe list of items under configuration control, as documentedin the configuration management plan of the project.

Traceability ManagementThe basic objective a software project is to deliver asoftware that would match functionalities as desired by thecustomer. Hence it is imperative that there should be amechanism to check or trace back these requirements to thedelivered software. That means we should be able to linkeach of requirement to the work product that is beingdelivered (entity name in the sample below). This will alsohelp design test cases needed for the project. This kind oftracing will also validate that each and every requirementhas been met and also has been tested for allfunctionalities. In their study, Lalioti et al. (1995),Bruno et al. (1995), Lultz et al. (1996) and Rosenberg(1998) consider this approach as a validation technique usedfor making sure that all the requirements have beenconverted into design specifications and developed by theproject team.

There could be two types of traceability – forward andbackward (www.sei.cmu.edu). In forward traceability as shown

in the sample below each and every requirement is traced tothe final output where as in backward traceability theoutput is traced back to the original requirement. Backwardtraceability is needed for debugging during integration andfinal phase of testing.

A sample traceability matrix Requirement#

FunctionalSpecification

FuncSpec Section Location

EntityName

Type Status

FrmMDIMain VB Delivered Global.bas VB Delivered

Mainline.bas VB DeliveredFrmSeparatePerson VB DeliveredNonAgtSearchResults.cls VB Delivered

1 Requirement#1

4.1

NonAgent

NonAgent.cls VB Delivered

PersonWinsign.cls VB DeliveredPesronWinsigns.cls VB DeliveredAdPersonForSeparateByAgyRet

TSQL Delivered

AdPersonForSeparateByNameRet

TSQL Delivered

AdEntrprsSecurityUpdate TSQL DeliveredCombinePeople.frm VB DeliveredNonAgent.cls VB DeliveredNonAgentSearchResult.cls VB DeliveredNonAgentSearchResults.cls VB Delivered

2 Requirement#2

4.2

NonAgent

AdPersonForMergeByAgyRet TSQL Delivered

AdPersonForMergeByNameRet TSQL Delivered

AdMergeNonAgent TSQL DeliveredFrmMDIMain VB Delivered

3 Requ 4 NonAg Global.bas VB Delivered

irement#3

.3

ent

Mainline.bas VB DeliveredPersonWinsign.cls VB DeliveredPesronWinsigns.cls VB Delivered

4 Requirement#4

4.4

NonAgent

Person.cls VB Delivered

NonAgentView.frm VB DeliveredPrintNonAgtPersonalInfo VB DeliveredAdEntrprsSecurityRetrieve TSQL DeliveredNonAgentView.frm VB DeliveredTelephone.cls VB DeliveredTelephones.cls VB DeliveredAgentView.frm VB DeliveredCustomizeAgentView.frm VB DeliveredPrintNonAgtPhone.bas VB DeliveredPrintLocation.bas VB DeliveredPrintPhone.bas VB DeliveredPrintAddress.bas VB Delivered

5 Requirement#5,6

4.5

NonAgent

PrintOptions.frm VB Delivered

4.6

FIMS.INI VB Delivered

Main.bas VB DeliveredTelephoneAddChange.frm VB DeliveredAdTelephoneUpdate TSQL DeliveredAdTelephoneRetrieve TSQL DeliveredAdTelephoneInsert TSQL DeliveredAdLocationContextRetrieve TSQL DeliveredAdLocationContextInsert TSQL DeliveredAdLocationContextUpdate TSQL DeliveredAdLocationInsert TSQL Delivered

The description in the above table is self explanatory.Functional name refers to the requirement number in SRSdocument where as the entity name refers to the name of the

final work product. Function name refers to theclause/section number in SRS.

BenefitsBenefits of following the tools and techniques, as mentionedabove, have been evident for customers as well as for theteam engaged in developing software. While customer got hisrequired deliverables with less defects, the team spent lesstime in reworking requests as well as on defects. Customerscould meet the business objectives of their organizationswhich deployed the software. This also helped them to usethe error free software deliverables as a strategic sellingproposition and gained higher market share. The projectteam, on the other hand, had to spend less time in reworkingdefects and hence their productivity, moral of employees andwork life balance improved. Thus, the tools and techniquesdescried here can be practiced in other similarorganizations engaged in developing software in IT industry.

ConclusionSoftware quality implies that the software is reliable,maintainable, usable, and that it satisfies customerexpectations, user needs, and developer goals. Requirementsspecifications serve as the reference point for customerexpectations and user needs during and after development.The requirements specification therefore plays a crucialrole in the achievement of software quality. If therequirements do not exhibit quality, it is highly unlikelythat the software product based on those requirements willexhibit quality. Requirements Management is an integral partof this process wherein requirements serve as livingentities which are at the center of development activity.Once elicited, requirements are documented and managed withthe same degree of care that we provide to our code workproducts. This process puts the team in control of theirproject and helps them manage both the project and itsscope. Lastly, actively managing changing requirements keepsthe project under control and helps assure the reliable,repeatable production of high quality software products.

Requirement Management is an important activity in softwaredevelopment project. Since the quality and success of theproject depends on this stage of the project. Hence it isrecommended that experience senior and experienced resourcesin an organization should take up the tasks of requirementmanagement. These senior personnel are not only areexperienced in project management, they are also well versedwith process or model that an organization follows. Thisalong with their domain knowledge will help the analyst teamto elicit a good response from the customer. Their expertisein dealing with human nature and overcoming communicationdifference will help result in a good starting point for asoftware project.References

A. Opdahl, “Requirements Engineering for SoftwarePerformance,” presented at International Workshop onRequirements Engineering: Foundations of SoftwareQuality, 1994.

B. Mar, “Requirements for Development of SoftwareRequirements,” presented at Fourth InternationalSymposium on Systems Engineering, 1994.

B. Ramesh, “Implementing Requirements Traceability: ACase Study,” presented at Second International Symposiumon Requirements Engineering, 1995.

B. Regnell et al., “Improving the Use Case DrivenApproach to Requirements Engineering,” presented atSecond IEEE International Symposium on RequirementsEngineering, 1995.

B. Wiley, Essential System Requirements: A PracticalGuide to Event-Driven Methods, Addison- Wesley, 1999.

D. Berry, D. Damian, A. Finkelstein, D. Gause, R. Hall,and A. Wassyng, “To Do or Not to Do: If the RequirementsEngineering Payoff Is So Good, Why Aren’t More CompaniesDoing It?” Proc. Requirements Eng., 2005.

E. Yu, “Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering,” presented at IEEEInternational Symposium on Requirements Engineering,1997.

F. Brooks, “No Silver Bullet: Essence and Accidents ofSoftware Engineering,” Computer, vol. 20, no. 4, pp. 10-19, Apr. 1987.

G. Playle and C. Schroeder, “Software RequirementsElicitation: Problems, Tools, and Techniques,” Crosstalk:The Journal of Defense Software Engineering, vol. 9, iss.12, December 1996, pp. 19-24.

G. Spanoudakis and A. Finkelstein, “ReconcilingRequirements: A Method for Managing Interference,Inconsistency, and Conflict,” Annals of SoftwareEngineering, vol. 3, 1997.

H. Beyer and K. Holtzblatt, “Apprenticing with theCustomer,” Communications of the ACM, vol. 38, iss. 5,May 1995, pp. 45-52.

H. Kaindl, S. Brinkkemper, J.A. Bunenko, B. Farbey, S.Greenspan, C. Heitmeyer, J.C. Leite, N. Mead, J.Mylopolous, and J. Siddiqi, “Requirements Engineering andTechnology Transfer: Obstacles, Incentives and anImprovement Agenda,” Requirements Eng. J., vol. 7, pp.113-123, 2002.

I. McFarland and I. Reilly, “Requirements Traceability inan Integrated Development Environment,” presented atSecond International Symposium on RequirementsEngineering, 1995.

J. Krogstie et al., “Towards a Deeper Understanding ofQuality in Requirements Engineering,” presented atSeventh International Conference on Advanced InformationSystems Engineering (CAiSE ’95), 1995.

J. Procaccino, J. Verner, S. Overmyer, and M. Darter,“Case Study: Factors for Early Prediction of Software

Development Success,” Information and SoftwareTechnology, vol. 44, pp. 53-62, 2002.

K. Holtzblatt and H. Beyer, “Requirements Gathering: TheHuman Factor,” Communications of the ACM, vol. 38, iss.5, May 1995, pp. 31-32.

K. Weigers, Software Requirements, second ed., MicrosoftPress, 2003.

L. Macaulay, Requirements Engineering, Springer-Verlag,1996.

L. O’Brien, “From Use Case to Database: Implementing aRequirements Tracking System,” Software Development, vol.4, issue. 2, February 1996, pp. 43-47.

L. Rosenberg, T.F. Hammer, and L.L. Huffman,“Requirements, testing and metrics,” presented at 15thAnnual Pacific Northwest Software Quality Conference,1998.

Mohapatra. S, Maximising productivity by controllinginfluencing factors in commercial software development,International Journal of Information and CommunicationTechnology, 2011, Vol.3, Issue No. 2.

Mohapatra. S, Gupta. D.K, Finding factors impactingproductivity in software development project usingstructured equation modelling, International Journal ofInformation Processing and Management, 2011, Vol. 2,Issue 1. 

Mohapatra. S, Mohanty. B, Defect prevention throughdefect prediction: A case study at Infosys, IEEEInternational Conference on Software Maintenance, ICSM,2011

Mohapatra. S, Improvised process for quality throughquantitative project management: An experience fromsoftware development projects, International Journal ofInformation and Communication Technology, 2010

M. Kauppinen, S. Kujala, T. Aaltio, and L. Lehtola,“Introducing Requirements Engineering: How to Make aCultural Change Happen in Practice,” Proc. IEEE JointInt’l Requirements Eng. Conf. (RE ’02), pp. 43-51, 2002.

M. Vartiainen , M. Kauppinen, J. Kontio, S. Kujala, andR. Sulonen, “Implementing Requirements EngineeringProcesses throughout Organizations: Success Factors andChallenges,” Information and Software Technology, vol.46, no. 14, pp. 937-953, 2004.

O. Gotel and A. Finkelstein, “Extending RequirementsTraceability: Lessons Learned from an Industrial CaseStudy,” presented at IEEE International Symposium onRequirements Engineering, 1997.

Rath. A, Kumar. S, Mohapatra. S, Thakurta. R, Decisionpoints for adoption cloud computing in small, mediumenterprises (SMEs), International Conference for InternetTechnology and Secured Transactions, ICITST 2012, 2012

R. Kosman, “A Two-Step Methodology to Reduce RequirementsDefects,” Annals of Software Engineering, vol. 3, 1997.

R. Lutz and R. Woodhouse, “Contributions of SFMEA toRequirements Analysis,” presented at Second IEEEInternational Conference on Requirements Engineering,1996.

R. Stevens, “Structured Requirements,” presented atFourth International Symposium on Systems Engineering,1994.

S. Jacobs, “Introducing Measurable Quality Requirements:A Case Study,” Proc. Fourth Int’l Symp. RequirementsEng., pp. 172-179, 1999.

S. Kujala and M. Kauppinen, “Starting Improvement ofRequirements Engineering Processes: An ExperienceReport,” Proc. Third Int’l Conf. Product Focused SoftwareProcess Improvement (Profes), pp. 196-209, 2001.

T. Wyder, “Capturing Requirements With Use Cases,”Software Development, vol. 4, iss. 2, February 1996, pp.36-40.

T.S. Group, “The CHAOS Report,” The Standish GroupInternational, 2003, ww.standishgroup.com.

V. Lalioti and B. Theodoulidis, “Visual Scenarios forValidation of Requirements Specification,” presented atSeventh International Conference on Software Engineeringand Knowledge Engineering, Knowledge Systems Institute,1995.

W. Robinson and S. Fickas, “Supporting Multi-PerspectiveRequirements Engineering,” presented at IEEEInternational Conference on Requirements Engineering,1994.

www.sei.cmu.edu