White PapersSoftware requirements engineering is a communication-intensive activity, at a minimum involving analysts, developers,business stakeholders and end users. Effective communication demands skilled requirements analysts, effective practices for requirements definition and management and tools to assist with these critical activities. The many human interfaces involved with requirements can lead to a variety of communication problems, including miscommunication between users and analysts, misunderstandings between analysts and developers, ineffective decision-making and inaccurate tracking of requirements status, all of which add time and cost to software projects.
This paper describes some of the key requirements issues that affect nearly every software and systems development project. The paper also outlines practical strategies and an effective solution to help address many common problem areas.
EFFECTIVEREQUIREMENTSDEFINITION ANDMANAGEMENT IMPROVES SYSTEMS AND COMMUNICATIONUntitled DocumentEffective Requirements Definition and Management2ContentsExecutive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Requirements and rework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Key requirements issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Requirements processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Strategies for better requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Requirements elicitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Requirements analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Requirements specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Requirements validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Requirements management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Assessing return on investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Requirements definition and management: the Borland solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Untitled DocumentEffective RequirementsDefinition and Management3Software requirements engineering is a communication-intensive activity,at a minimum involving analysts,developers,business stakeholders and end users.Effective communication demands skilled requirements analysts,effective practices forrequirements definition and management and tools to assist with these critical activities.The many human interfacesinvolved with requirements can lead to a variety ofcommunication problems,including miscommunication between usersand analysts,misunderstandings between analysts and developers,ineffective decision-making and inaccurate tracking ofrequirements status,all ofwhich add time and cost to software projects.This paper describes some ofthe key requirements issues that affect nearly every software and systems development project.The paper also outlines practical strategies and an effective solution to help address many common problem areas.Requirements and reworkSoftwaredevelopment involves perhaps 50 percent computing and 50 percent communication.Unfortunately,most teamsarebetter at the computing part,and requirements are almost entirely about communication.There are many links in therequirements communication chain,as illustrated in Figures 1 and 2.A breakdown in any ofthese links leads to significantproblems.For example,ifan analyst misunderstands stakeholder input about requirements,ifimportant requirementsinformation does not surface or ifan analyst and developer do not share the same understanding about requirements,theresulting product will not satisfy customers.Figure 1. Typical requirements communication links in an information systems environmentExecutive summaryBy now,it is well known that shortcomings in requirements definition and management lead toexcessive rework on software projects and products that fail to achieve full customer satisfaction.Acloser look at their own software organizations can help managers at all levels identify painpoints related to how requirements are elicited,analyzed,specified,validated and managed.U serProductCham pionAnalystDeveloperTesterUntitled DocumentEffective Requirements Definition and Management4Figure 2. Typical requirements communication links in a commercial software environmentThe inevitable outcome of requirements errors is time consuming and costly rework. Analysts report that rework canconsume 30 to 40 percent of the total effort expended on a software project. Multiple studies have indicated that roughly 50percent of the defects identified on software projects can be traced back to errors in the requirements. One analysis of thepotential return on investment from better requirements suggests that requirements errors can consume between 70 and 85percent of all project rework costs.1As Figure 3 illustrates, it can cost up to 110 times more to correct a requirements defectfound in operation than it would if that same defect had been discovered during requirements definition.2Figure 3. Relative cost to correct a requirement defect depending on when it is discoveredD e v e l o p m e n t P h a s eR e q u i r e m e n t s1 2 0D e s i g nC o d eT e s tO p e r a t i o n1 0 08 06 04 02 001Leffingwell, Dean. 1997. Calculating the Return on Investment from More Effective Requirements Management. American Programmer 10(4): 13 16.2 Grady, Robert B. 1999. An Economic Release Decision Model: Insights into Software Project Management. In Proceedings of the Applications of Software MeasurementConference, 227 239. Orange Park, Fla.: Software Quality Engineering.S a l e s R e pM a r k e t i n gP r o d u c tM a n a g e rD e v e l o p e rT e s t e rC u s t o m e rUntitled DocumentEffective RequirementsDefinition and Management5Good requirements practices may have always been challenging,but the Internet has made the problem worse.A 2001 survey confirms that e-projects are time-compressed,intensive and mission-critical efforts with poorly defined requirements. 3According to survey respondents,the top three risks threatening the success ofthe e-projects surveyed were:"Unstable,constantly changing requirements (66 percent)"Poor requirements specification (55 percent)"Client behavior,such as approval delays,requirements changes and poor communication (42 percent)Even though project teams often do not think they have the time to effectively elicit and capture requirements,they alwaysseem to find the time,people and money to fix problems found in a delivered product.Therein lies the leverage forimproving any organization s requirements engineering approaches.Ifteams use better practices and better tools to facilitaterequirements communication,they will introduce fewer defects attributable to requirements errors.As a result,they willreduce rework,thereby improving delivery time and quality with products that better meet business objectives.Keyrequirements issuesOver the years,five universal truths have surfaced about software requirements engineering.The following statements arehelpful for software development organizations to keep in mind as they consider how best to improve the requirements and communication for their projects.4Ifteams don t get requirements right,it doesn t matter how well they execute the rest ofthe project.The goal ofevery software development project is to build a product that provides value to customers.Effective requirementsdefinition enables teams to determine the mix ofproduct capabilities and characteristics that will best deliver this customervalue.An understanding evolves over time as stakeholders provide feedback on the early work and refine their expectationsand needs.Adequately exploring and crafting requirements into a set ofproduct features and attributes helps to ensurecustomer needs are being met throughout the project lifecycle.Requirements definition is a discovery and invention process,not just a collection process.Teams often talk about gathering requirements. This phrase suggests that requirements are just lying around waiting to bepicked like flowers or to be sucked out ofusers brains by an analyst.In reality,requirements definition is an exploratoryactivity,and requirements elicitation is a more accurate description than requirements gathering.Elicitation includes somediscovery and some invention,as well as recording those bits ofrequirements information that various stakeholders presentto an analyst.Elicitation demands iteration.Participants in a requirements elicitation discussion will not think ofeverythingtheywillneedup front,and their thinking will change as a project progresses.Teams that prepare to iterate most often elicitthe most accurate requirements.Customer involvement is the most critical contributor to software quality.Various studies confirm that inadequate customer involvement is a leading cause ofthe failure ofsoftware projects.5Thedevelopment team will get the customer input it needs eventually even ifit is after a project ships.However,it is muchcheaper and much less painful to get customer input earlier,rather than after product release.Customer involvementrequires more than a workshop or two early in the project.It involves input from customers early and often in the3Rodrigues,Alexandre.2001. Project Goals,Business Performance,and Risk. Cutter Consortium e-Project Management Advisory Service Executive Update 2(7).4Wiegers,Karl E.2006.More About Software Requirements:Thorny Issues and Practical Advice.Redmond,Wash.:Microsoft Press.5The CHAOS Report,The Standish Group International,Inc.,1995.Untitled DocumentEffective Requirements Definition and Management6requirements process. Ongoing engagement by suitably empowered and enthusiastic stakeholders is a critical success factorfor software development.Change happens; managing change is critical.It is inevitable that requirements will change as business needs evolve, new users or markets are identified, business rules andgovernment regulations are revised and operating environments change. The objective of a change control process is not toinhibit change. Rather, the objective is to manage change to ensure that the project incorporates the right changes for the rightreasons. Teams that anticipate and accommodate changes minimize disruption and cost to the project and its stakeholders.Teams are never going to have perfect requirements.Requirements are never finished or complete. There is no way to know for certain that teams have not overlooked somerequirement, and there will always be some requirements that are not in the specification. It is also folly to think teams canfreeze the requirements and allow no changes after some initial elicitation activities. Rather than declaring requirements done at some point, effective teams define a baseline then follow a sensible change control process to modify requirementsonce a baseline is established.Requirements processesGood requirements practices can accelerate software development. The process of defining business requirements aligns thestakeholders with shared vision, goals and expectations. Substantial user involvement in establishing and managing changesto agreed upon requirements increases the accuracy of requirements, ensuring that the functionality built will enable users toperform essential business tasks.Software requirements engineering encompasses the two major sub domains of requirements definition and requirements management:Requirements Definition is the collaborative process of collecting, documenting and validating a set of requirementsthat constitute an agreement among key project stakeholders. Requirements definition is further subdivided intothe critical process areas of elicitation, analysis, specification and validation processes.From a pragmatic perspective, requirements definition strives for requirements that are good enough to allow theteam to proceed with design, construction and testing at an acceptable level of risk. As discussed, the risk is thethreat of having to do expensive and unnecessary rework.Requirements Management involves working with a defined set of product requirements throughout the product sdevelopment process and its operational life. It also includes managing changes to that set of requirementsthroughout the project lifecycle.In practice, requirements management includes selecting changes to be incorporated within a particular release andensuring effective implementation of changes with no adverse impact on schedule, scope or quality.An effective requirements definition and management solution creates accurate and complete system requirements, whilehelping organizations improve communications in an effort to better align IT with business needs and objectives. It includesa set of industry best practices for each category, as well as tools to enable and accelerate requirements activities.Untitled DocumentEffective Requirements Definition and Management7Strategies for better requirementsA variety of practices can help software teams bridge communication gaps and do a better job of understanding,documenting and communicating customer needs. Figure 4 illustrates, and process areas below describe, several bestpractices in the categories of requirements elicitation, analysis, specification, validation and management.6Figure 4. Best practices for each requirements catagoryRequirements elicitationDefine the product vision and project scope.The product vision is the long-term strategic concept underlying the ultimate purpose and form of the new system. Thevision could also describe the product s place among its competition in its market or operating environment. The projectscope is the portion of the product vision that the current project will address. The scope draws the boundary between whatis in and what is out for that project. Without a clearly defined project scope, the project is issuing an open invitation toscope creep. Prior to eliciting requirements, teams should have a clear understanding of both the product vision and theproject scope.6Wiegers, Karl E. 2003. Software Requirements, Second Edition. Redmond, Wash.: Microsoft Press.E l i c i t a t i o n" D e f i n e v i s i o n a n d s c o p e" I d e n t i f y s t a k e h o l d e r s" S e l e c t p r o d u c t c h a m p i o n s" C h o o s e e l i c i t a t i o n t e c h n i q u e s" E x p l o r e u s e r s c e n a r i o sM a n a g e m e n t" M a n a g e r e q u i r e m e n t s v e r s i o n s" A d o p t c h a n g e c o n t r o l" P e r f o r m i m p a c t a n a l y s i s" S t o r e r e q u i r e m e n t s a t t r i b u t e s" T r a c k r e q u i r e m e n t s s t a t u sA n a l y s i s" C r e a t e a n a l y s i s m o d e l s" B u i l d a n d e v a l u a t e p r o t o t y p e s" P r i o r i t i z e r e q u i r e m e n t sV a l i d a t i o n" R e v i e w t h e r e q u i r e m e n t s" C r e a t e t e s t c a s e s f r o m r e q u i r e m e n t sS p e c i f i c a t i o n" L o o k f o r a m b i g u i t i e s" S t o r e r e q u i r e m e n t s i n ad a t a b a s e" T r a c e r e q u i r e m e n t s i n t o d e s i g n , c o d e , t e s t sUntitled DocumentEffective Requirements Definition and Management8Identify stakeholders, customers and users.To software development groups, customers are a subset of stakeholders and users are a subset of customers. Teams canfurther subdivide user communities into multiple user classes that have largely distinct needs. Unrepresented user classestypically will be disappointed with the project outcome. It is essential to gain commitment from key stakeholders for theirparticipation throughout the requirements definition. Customer engagement is necessary during requirements management,as well. The customer perspective is required when making change decisions, assessing the impact of proposed changes andadjusting requirement priorities. Every software project should identify its key requirements decision makers and itsdecision-making process early on to ensure that the right people can make important and timely decisions.Select product champions.Teams must determine who will serve as the literal voice of the customer for each user class. These representatives are calledproduct champions. Ideally, product champions are actual users who represent their peers in a particular user class.Sometimes, though, surrogate product champions are needed. The product manager often performs this role in acommercial software development organization. When engaging product champions, it is important to agree on the level ofinvolvement. It is one thing to participate in a workshop or two, but sustained engagement with frequent contact pointsbetween product champions, analysts and developers adds far more value. Teams should take care to not only choose arepresentative, but to choose the right representative. Product champions must understand the business requirementsexpressed in the product vision and project scope which define the boundaries for the work the product champions do. Thebest product champions are collaborative partners in the requirements process and communicate with other members of theteam to request input, solicit feedback and resolve conflicts.Choose elicitation techniques.The methods an analyst uses for requirements elicitation depends on the extent of stakeholder involvement and how muchaccess the analyst has to the stakeholders. Workshops to explore scenarios and use cases work well when user representativesare locally available. Questionnaires and surveys might be necessary if there are many, geographically distributed stakeholders.Individual interviews with subject matter experts are also useful for capturing information, as are analysis models andbuilding interactive prototypes. These various elicitation techniques are not mutually exclusive. When the analyst can usemultiple communication channels with the sources of requirements information, the chance of getting high quality andcomplete information increases. Therefore, teams should be trained and proficient in a variety of elicitation techniques.Explore user scenarios.Requirements analysts have learned that elicitation discussions that focus on users and how they use a product or systemgenerally yield the best results. Users find it more natural to describe their business tasks and usage goals than to define all ofthe functionality they expect to see in a product. Use cases, scenarios and user stories are related terms that are usedfrequently to describe a system s user requirements. Use cases do not replace the need to define the detailed functionalrequirements that developers will implement. However, teams should explore use cases or user scenarios to help ensure thatthe requirements their developers implement will allow users to accomplish their goals.Untitled DocumentEffective Requirements Definition and Management9Requirements analysisCreate analysis models.The natural language requirements found in most specifications are full of ambiguities, redundancies and gaps. In mostcases, it is desirable to represent requirements in multiple ways, giving readers a richer, more holistic understanding of them.Analysis models present requirements information visually, in graphical diagrams. They allow reviewers to immediately spotmissing requirements by examining diagrams, rather than uncovering missing requirements by reading a dense textualspecification. Teams may have better results using models that communicate at a higher level of abstraction, so readers canget the big picture without getting mired in all of the details.Build and evaluate prototypes.A prototype is a partial, preliminary or possible solution to the requirements. Prototypes provide opportunities for productchampions to interact with a simulation or portion of the final system. Prototypes are more tangible than writtenrequirements specifications; they are a way to bring use cases to life. When creating a prototype, the development team istaking a tentative step into the solution space, which is a valuable way to validate and refine requirements, but it is not asubstitute for documenting detailed functional requirements. A prototype or set of screen designs does not show thebusiness logic happening behind the scenes. It does not illustrate the complete behavior of the product when the user takescertain actions under certain conditions. A prototype also does not indicate how all exceptions and error conditions aregoing to be handled, although this information is critical if teams want to build robust software. When used with the rightaudiences, prototypes are an effective way to help teams analyze existing requirements for a new system.Prioritize requirements.Every software development organization has limited resources and time. Therefore, every team needs to determine which ofits allocated requirements are most important and which are most urgent. Prioritizing requirements allows teams toimplement the right sets of user functionality in the right sequence. Prioritization should be a collaborative process thatinvolves both a customer and a technical perspective to balance customer value against cost and technical risk.Requirements specificationLook for ambiguities.Requirements written in natural language are fraught with ambiguity. Negative requirements, use of vague and subjectiveterms, complex logic, omissions, synonyms and adverbs lead to multiple interpretations by different readers. It is cheaper tocorrect ambiguities in the requirements than to deal with disappointed customers. As a result, teams should establish anagreed upon lexicon prior to writing requirements.Store requirements in a database.By storing requirements in a commercial requirements management tool, such as Borland Caliber Analyst, teams canovercome many of the limitations imposed by textual documents. Requirements management tools make it easy to storeadditional information attributes about different classes of requirements information. They facilitate trackingrequirements status. They provide a mechanism for retaining requirements that have been proposed, rejected or approved,and later deleted from a baseline. The tools also make it easier to work with groups of requirements that are intended formultiple future releases. In addition, organizations that keep requirements in a shared online database can better facilitatecommunication and collaboration among distributed teams.Untitled DocumentEffective Requirements Definition and Management10Trace requirements into design, code and tests.It is valuable to be able to link each software functional requirement back to its origin, possibly a use case or business rule.Teams should embrace traceability information that connects functional requirements to associated design elements, codesegments and tests to accelerate debugging and software maintenance. Requirements management tools are a great aid tomanaging traceability data.Requirements validationReview the requirements.The highest leverage quality practice available to software teams is formal peer review of requirements documents. Peerreview provides an indication of how well others understand the requirements. The requirements analyst should documentrequirements so as to ensure that they communicate clearly, effectively and efficiently to the various stakeholders. The analystshould create complementary views of the requirements selected from textual requirements, analysis models, scenarios,prototypes, tests and other representations all of which can be reviewed concurrently. All project stakeholders shouldreview the requirements to ensure accuracy, completeness, and the optimal level of detail to deliver software that truly meetsthe business needs.Create test cases from requirements.Teams should begin testing as soon as they have some requirements in hand. Deriving test cases from use cases andscenarios is a valuable way to find problems in the use cases themselves, in functional requirements derived from the usecases and in analysis models created from the requirements.Requirements managementManage requirements versions.As requirements evolve during the course of a project, it is important to track the different versions of requirementsspecification documents and even individual requirements. Teams that use version tracking help to ensure that all teammembers are working from the most current requirements baseline.Adopt a change control process.Once requirements have been baselined, proposed modifications in them should follow an established change controlprocess. This process provides consistency in the way requirement changes are proposed, evaluated, approved or rejected,communicated to stakeholders and implemented in affected work products. Teams should have formal written changecontrol processes in place before eliciting requirements.Perform requirements change impact analysis.To help the change control board (CCB) make appropriate business decisions about which proposed changes to approve,developers should assess the potential impact of each proposed change before committing to implement it.Store requirements attributes.Requirements attributes provide a richer understanding of each individual requirement. Potential attributes to track includepriority, status, author, origin, rationale, validation method, risk and version number. Teams should store attributes with therequirements to ensure the detail necessary to communicate and prioritize requirements.Untitled DocumentEffective Requirements Definition and Management11Track the status of each requirement.Tracking project status is facilitated if the team can report on the status of individual functional requirements in thebaseline. There are a number of possible requirements checkpoints, including proposed, approved, implemented, verified,rejected and deleted. Teams that track the status of each requirement can easily assess the health of the project and avoidunnecessary status meetings.Assessing return on investmentSoftware development managers want to know what return on investment (ROI) they can expect from the money theyspend on training, process improvement and tools for requirements definition and management. Although there are toomany variables to predict a specific ROI for a given organization, the following are some factors to consider when estimatingthe ROI organizations can expect from better requirements.In general, to determine the ROI from any new initiative, compare what was invested in the activity with the experiencedbenefits such as reduced costs, accelerated schedules or increased sales. For example, track what would be spent on thefollowing process improvement activities to determine your investment:Assess current practices.All process improvement should begin with an appraisal to learn how teams are dealing with requirements issues today andwhether current approaches are successful or struggling. Use Use the Borland Requirements and Definition Management selfassessment as an opportunity to quickly assess your organization s requirements definition and management maturity andsee an action plan for more effective and sustainable results.Develop new processes and templates.Once team members have identified specific requirements engineering practices for improvement, identify practices that willwork better. This may involve writing new processes, modifying current processes and selecting or adjusting the templatesfor key requirements deliverables.Train the team.All analysts and others who deal with project requirements should receive basic training in requirements concepts andpractices. Team members should also receive training in the effective use of specific organizational processes and templates.Acquire books and other resources.Analysts will benefit from having reference books and articles on hand to refresh their knowledge and uncover new ideas forhandling requirements challenges they encounter.Employ external consultants.Many software organizations require assistance from experienced consultants who have worked with a variety of companies.Consultants can help team members solve problems much faster than they might on their own.Invest in requirements definition and management tools.As requirements engineering activities become more sophisticated, teams should store requirements in a database, ratherthan in traditional word processing documents. Requirements management tools such as Borland CaliberRM have beencommercially available for several years. However, requirements management tools do not help teams scope projects, identifyUntitled DocumentEffective Requirements Definition and Management12and talk to the right users or write good requirements. More recently a new class of requirements tools has begun to appear,such as Borland Caliber Analyst, that support not only requirements management, but also requirements definition. Someof these tools assist with representing requirements in the form of use cases or scenarios, prototypes, graphical analysismodels or simulations. Other tools analyze requirements for quality by scanning for vague words or through linguisticanalysis to identify possible omissions in ambiguities.Define and manage project requirements.The best investment is the investment in time that team members spend defining and managing the requirements for theproducts they are creating. Multiple studies have confirmed that spending more time on requirements definition actuallyaccelerates the project by reducing late-stage rework.Estimate your return.To estimate the payback that better requirements can bring to your organization, consider these questions:" What fraction of your own development effort is expended on rework (due to miscommunication)? " How much does a typical customer-reported defect cost your organization? A defect found in system testing? " What fraction of user-reported defects and what fraction of defects discovered during system testing originate inrequirements errors? " How much of your organization s maintenance costs such as defect correction and unplanned enhancements can you attribute to missing requirements or other requirement defects?" How much do you think your organization could shorten its delivery schedules if your project teams could reducerequirement defects by 50 percent?Besides the obvious cost benefits, improving requirements approaches leads to other valuable but less tangible outcomes.Experiencing fewer miscommunications on a software project reduces the overall level of chaos. Less chaos lowers unpaidovertime, increases team morale, boosts employee retention and improves the team s chances of delivering on time. Best ofall, these benefits lead to higher customer satisfaction.Untitled DocumentEffective RequirementsDefinition and Management13Requirements definition and management:the Borland solutionBorland helps global organizations maximize the business value ofsoftware and accelerate the path to Software DeliveryOptimization (SDO) by transforming software development into a managed business process to increase control,predictability,visibility and efficiency over the entire software delivery process.One ofthe core processes critical to achievingSDO is effective requirements definition and management.The Borland Requirements Definition and Management Solution is the only scalable,integrated enterprise requirementsdefinition and management solution to appropriately align people skills,process improvements and award-winningtechnology to deliver essential capabilities that significantly increase the probability that a project is delivered right the firsttime.It is the most comprehensive enterprise solution available in all five ofthe key areas ofrequirements definition andmanagement,including:Elicitation:reduce rework by capturing better information.The process ofcapturing requirements in context,requirements elicitation includes identifying key business and technicalstakeholders,getting commitment to stakeholder involvement,selecting appropriate elicitation techniques and capturingrequirements and scenarios in a simple to understand form.To reduce rework,Borland helps organizations mature theirexisting requirements elicitation process by helping to define responsibilities and stakeholders,identify appropriateelicitationtechniques and train team members to use the right techniques.Borland also helps teams leverage Borland CaliberAnalyst technology to capture user scenarios in a simple,visual form that users readily understand.With the BorlandSolution,organizations enhance communication and collaboration among distributed teams throughout the projectlifecycle.Teams also improve alignment between business expectations and project deliverables,which increases end usersatisfaction and reduces rework from incorrect or incomplete requirements.Analysis:reduce time to market with more effective collaboration.Requirements analysis involves verifying,estimating and prioritizing newly captured requirements for remaining applicationlifecycle steps.To reduce time to market,Borland helps organizations mature their existing requirements analysis process byimplementing an effective approach to evaluate and prioritize requirements for specification,design,construction andtesting.The process is enhanced through the deployment oftools and techniques that increase efficiency and accuracy.Withthe Borland Solution,organizations gain better estimation and thus,improved predictability for software delivery.Specification:improve quality through more effective communications.Requirements specification includes adding detail to requirements incrementally to the optimal level for validation,design,coding,testing and documentation.To improve quality,Borland helps organizations mature and automate their existingrequirements specification process by defining a standard hierarchy ofrequirement types and developing standard templatestoensurecompleteness.Borland also helps teams identify various specification techniques (e.g.use case and business processmodels,prototypes and traditional requirements specifications),and apply technology such as Borland Caliber Analyst sothat requirements are captured in a meaningful,easy-to-understand way.Borland tools provide automated traceability acrossthe lifecycle so organizations are better able to predict the impact ofchange and proactively communicate those changes toall team members affected.With the Borland Solution,organizations reduce software defects because development teamshave a better understanding ofrequirements.Untitled DocumentEffective RequirementsDefinition and Management14Validation:improve accuracy and completeness to close development lifecycle gaps.Requirements validation involves verifying the specification is complete and clear enough for the development team tounderstand exactly what it needs to build.It also includes validating with key stakeholders that specified requirements areconsistent with the original need and intent ofthe business.To improve accuracy,Borland helps organizations mature theirexisting process by automating validation and verification to drive adoption and enforcement and improving consistency andquality through storyboard execution delivered in Borland Caliber Analysttechnology.Borland also helps organizationsdevelop team member skills using tools and education to improve quality and define and implement processes for validatingrequirements with stakeholders that ensures business and IT alignment.With the Borland Solution,organizations reducesoftware defects,increase satisfaction and alignment with business stakeholders and enhance business value.Management:reduce costs through improved change management.The process ofgathering and managing change requests during the application lifecycle,requirements management alsoincludes selecting changes to be incorporated within a particular release and ensuring effective implementation ofchangeswith no adverse impact on schedule,scope or quality.To reduce costs,Borland helps organizations mature their existingrequirements management process by establishing processes for defining and maintaining requirements baselines anddefining a standard process for requesting changes.Borland also helps teams establish a systematic approach to evaluate andapprove change requests so that scope changes and affected commitments are managed.With the Borland Solution,organizations improve ongoing change management,maximizing business impact,while minimizing schedule and scopeimpact.They also increase business stakeholder satisfaction.The Borland approach to transforming requirements definition & management.The Borland approach to requirements definition and management is unique in that it takes into account an organization sprocess maturity by leveraging industry best practices to evaluate current performance and identify specific areas forimprovement.Borland does this by using the proven Borland Accelerate Framework,a disciplined,four-phase improvementapproach that incorporates the five principles ofa successful transformation and effectively aligns people,process andtechnology to maximize results.Using the Framework and best practices process assets as a guide,Borland supports organizations at various stages in theirrequirements definition and management transformation."Phase I:Borland experts help define goals using executive workshops and other activities that result in clearlydefined objectives."Phase II:Borland experts help organizations architect their approach and prioritize the key solution components,including critical process modules,required technology configurations and skill development plans."Phase III:Borland helps organizations develop,pilot and deploy the enterprise-wide requirements definition andmanagement solution defined in Phase II,including implementing the process,installing and configuring thetechnology and training users."Phase IV:Borland helps organizations validate results against the goals defined in Phase I and identify gaps thatneed to be addressed in the next improvement cycle.Untitled DocumentEffective Requirements Definition and Management15With the Borland Solution, typical organizations will move from an ad hoc requirements process consisting of manualprocesses, word processing documents and ineffective requirements management systems to a requirements lifecycle focuswith a fully integrated system for managing each core process area described. As a result, organizations can more effectivelydefine requirements and better manage the constant barrage of requirements changes that occur within the application lifecycle.SummaryThe Borland Solution delivers everything organizations need to successfully implement the five critical requirementsdefinition and management processes into an organization for maximum impact, quickly and with a minimum of risk.The solution can be tailored to reflect an organization s maturity and goals, which is crucial to the ultimate success ofany initiative.The Borland Requirements Definition and Management Solution helps to ensure low-risk, rapid success at the lowest totalcost by including right sized processes, customizable technology and tailored training packages to enable users andempower customers to proceed with confidence.Copyright 2006 Borland Software Corporation. All rights reserved. All Borland brand and product names are service marks, trademarks or registered trademarks of BorlandSoftware Corporation in the United States and other countries. " 24401
