Requriements definition& managment for Dummies

7/29/2019 Requriements definition& managment for Dummies

1/67


2/67

These materials are the copyright of John Wiley & Sons, Inc.and any dissemination, distribution, or unauthorized use is strictly prohibited.


3/67

RequirementsDefinition &Management



4/67



5/67

RequirementsDefinition &Management

by Robert D. Schneider,Tony Higgins and

Keith Barrett



6/67

Requirements Definition & Management For Dummies

Published byJohn Wiley & Sons Canada, Ltd.

6045 Freemont Blvd.Mississauga, ON L5R 4J3

www.wiley.com

Copyright 2013 by John Wiley & Sons Canada, Ltd.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in anyform or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, withouteither the prior written permission of the Publisher. Requests to the Publisher for permissionshould be addressed to the Permissions Department, John Wiley & Sons Canada, Ltd., 6045Freemont Blvd., Mississauga, ON L5R 4J3, or online atwww.wiley.com/go/permissions. Forauthorization to photocopy items for corporate, personal, or educational use, please contact in

writing The Canadian Copyright Licensing Agency (Access Copyright). For more information, visitwww.accesscopyright.ca or call toll free, 1-800-893-5777.

Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Restof Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, Making EverythingEasier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc.and/or its affiliates in the United States and other countries, and may not be used without writtenpermission. All other trademarks are the property of their respective owners. John Wiley & Sons,Inc. is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKENO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETE-NESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES,

INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE.NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS.THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITU-ATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOTENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PRO-FESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONALPERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLEFOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE ISREFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHERINFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THEINFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS ITMAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED INTHIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRIT-TEN AND WHEN IT IS READ.

For general information on our other products and services, or how to create a custom For Dummiesbook for your business or organization, please contact our Business Development Department at877-409-4177, contact [email protected] , or visitwww.wiley.com/go/custompub. For informa-tion about licensing the For Dummies brand for products or services, contactBrandedRights&[email protected].

For technical support, please visitwww.wiley.com/techsupport.

Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some materialincluded with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version youpurchased, you may download this material at http://booksupport.wiley.com. For more infor-

mation about Wiley products, visitwww.wiley.com.ISBN 978-1-118-64113-2 (pbk); ISBN 978-1-118-64114-9 (ebk)

Manufactured in the United States

1 2 3 4 5 DP 17 16 15 14 13

http://www.wiley.com/http://www.wiley.com/go/permissionshttp://www.wiley.com/go/permissionshttp://www.accesscopyright.ca/http://www.accesscopyright.ca/mailto:[email protected]://www.wiley.com/go/custompubmailto:[email protected]://www.wiley.com/go/custompubmailto:BrandedRights&[email protected]:BrandedRights&[email protected]://www.wiley.com/techsupporthttp://booksupport.wiley.com/http://www.wiley.com/http://www.wiley.com/http://booksupport.wiley.com/http://www.wiley.com/http://www.wiley.com/http://booksupport.wiley.com/http://www.wiley.com/techsupportmailto:BrandedRights&[email protected]://www.wiley.com/go/custompubmailto:[email protected]://www.accesscopyright.ca/http://www.wiley.com/go/permissionshttp://www.wiley.com/


7/67

About the AuthorsRobert D. Schneideris a Silicon Valleybased technology con-sultant and author. He has provided database optimization,distributed computing, and other technical expertise to a widevariety of enterprises in the financial, technology, and govern-ment sectors. He has written six books and numerous articleson database technology and other complex topics such ascloud computing, big data, developing and testing high qualitysoftware, and service oriented architecture (SOA). He is a fre-

quent organizer and presenter at technology industry eventsworldwide. Robert blogs at rdschneider.com.

Tony Higgins is the vice president of Product Management atBlueprint Software Systems. He has over 28 years experiencein the software industry in a variety of technical and businessroles in the development of space and defense systems, IT sys-tems, and commercial software products. For the last nineyears Tony has focused specifically on solutions for softwarerequirements definition and management and the business

analyst role.

Keith Barrett is a senior systems engineer at BlueprintSoftware Systems and co-host of the Requirements Unpluggedpodcast series fromwww.requirements.net. Keith is a22-year veteran of the software industry. Prior to joiningBlueprint Software Systems, Keith served in the roles of busi-ness development manager, director of professional services,development manager, and practice manager for various soft-

ware organizations. Keith has also been a project manager,developer, data modeler and business analyst in large financialand telecommunications corporations. Keiths background insoftware development, reuse, and requirements uniquely posi-tions him as a leading industry advocate for business analysisbest practices. His work on requirements and component-based design has been featured in Business Analyst Times,Application Development Trends, ComputerWorld, and ObjectMagazine and he has spoken at numerous conferences globally.

http://rdschneider.com/http://rdschneider.com/http://www.requirements.net/http://www.requirements.net/http://www.requirements.net/http://rdschneider.com/


8/67



9/67

Publishers AcknowledgmentsWere proud of this book; please send us your comments at http://dummies.

custhelp.com. For other comments, please contact our Customer Care Departmentwithin the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002.

Some of the people who helped bring this book to market include the following:

Acquisitions and Editorial

Associate Acquisitions Editor:Anam Ahmed

Production Editor: Lindsay Humphreys

Copy Editor: Jeremy Hanson-Finger

Editorial Assistant: Kathy DeadyReviewer: Jennifer Bentley

Composition Services

Sr. Project Coordinator: Kristie Rees

Layout and Graphics:Joyce Haughey, Andrea Hornberger

Special Art: Tony Higgins

Proofreaders: John Greenough,Jessica Kramer

John Wiley & Sons Canada, Ltd.

Deborah Barton, Vice President and Director of Operations

Jennifer Smith, Vice-President and Publisher, Professional Development

Alison Maclean, Managing Editor, Professional Development

Publishing and Editorial for Consumer Dummies

Kathleen Nebenhaus, Vice President and Executive Publisher

David Palmer, Associate Publisher

Kristin Ferguson-Wagstaffe, Product Development Director

Publishing for Technology Dummies

Andy Cummings, Vice President and Publisher

Composition Services

Debbie Stailey, Director of Composition Services

http://dummies.custhelp.com/http://dummies.custhelp.com/http://dummies.custhelp.com/http://dummies.custhelp.com/http://dummies.custhelp.com/


10/67



11/67

Table of ContentsI n t r o d u c t i o n 1

Foolish Assumptions ................................................................. 1How This Book Is Organized .................................................... 2

Chapter 1: Meeting the Business Analyst ..................... 2Chapter 2: Conquering the Challenges of Business

Analysis ......................................................................... 2Chapter 3: Building a Better Business AnalysisExperience .................................................................... 2

Chapter 4: Introducing Blueprint ................................... 3Chapter 5: Ten Tips to Improve Business Analyst

Productivity .................................................................. 3Icons Used in This Book ............................................................ 3Where to Go from Here ............................................................. 4

Chapter 1: Meeting the Business Analyst 5

Boldly Exploring the Dynamic Business Environment .......... 6Engaging the Stakeholders........................................................ 7Analyzing the (Business) Analyst ............................................ 9

Education .......................................................................... 9Work background ............................................................ 9Place in the organization .............................................. 10Responsibilities .............................................................. 10Career trajectory ........................................................... 11

Software developmentenvironments ............................................................. 12

Imagining the Future ................................................................ 13

Chapter 2: Conquering the Challenges of BusinessAnalysis 15

Coping with Diverse Software DevelopmentMethodologies ...................................................................... 16

Coordinating teams ....................................................... 17

Sprinting to milestones ................................................. 18Clearing the backlog ...................................................... 18

Managing Convoluted Business Processes .......................... 19Overcoming Inadequate Tooling............................................ 20

Writing when you could be drawing ........................... 21Typing when you dont need to ................................... 22Doing clerical work thats not your job ...................... 22



12/67

x Requirements Definition & Management For Dummies

Conquering Cumbersome Review Cycles ............................. 22Exploring the Economic Risks of Inefficient

Business Analysis................................................................. 24

Chapter 3: Building a Better Business AnalysisExperience 27

Taking Strategies from Other Industries ............................... 27Getting Visual ........................................................................... 28Getting Social ............................................................................ 31Getting Going ............................................................................ 34

Reengineering processes .............................................. 34

Rolling out software ...................................................... 34Forecasting the Future ............................................................ 35

Chapter 4: Introducing Blueprint 37

Highlighting the History of Blueprint .................................... 37Sorting through Blueprint Solutions ..................................... 38

Authoring requirements ............................................... 38Validating requirements ............................................... 39

Managing requirements ................................................ 40Collaborating with team members .............................. 41Integrating with other technologies ............................ 42

Watching Blueprint at Work ................................................... 43Banking industry solutions ........................................... 43Legal industry solutions ............................................... 44Health industry solutions ............................................. 44Legacy modernization solutions .................................. 44

Chapter 5: Ten Tips to Improve Business AnalystProductivity 45

Leveraging Visual Models ....................................................... 45Expressing Your Requirements.............................................. 46Setting the Stage for Effective Collaboration ........................ 47Analyzing Stakeholders ........................................................... 47Getting the Right Tool for the Job ......................................... 48Avoiding Being a Slave to the Document .............................. 49Creating a Traceability Strategy ............................................ 50

Embracing the Rationale ......................................................... 50Planning Your Integration with Development

and Testing ........................................................................... 51Starting Small and Evolving Over Time ................................. 51



13/67

IntroductionW

elcome toRequirements Definition & Management ForDummies!Enterprises of all shapes and sizes have

become increasingly reliant on software to manage and opti-mize every phaser er, phase of their operations. In fact,

software often provides a competitive edge that translatesinto enhanced profitability for the company.

Project teams that design and deliver business applicationsserve the needs of a broad range of stakeholders, includingthe business, user communities, and IT itself. Within theseprojects the business analyst plays a critical role as the maindriver of requirements definition and management. Yet theposition of business analyst is relatively new and many people

still misunderstand what it entails.

In this book, we introduce you to the position of the businessanalyst, explain what they do, and describe their typical back-ground. We also describe some of the major challenges facingthese talented professionals, as well as how employing a com-bination of targeted technology and best practices can makebusiness analysts more effective. And if business analysts aremore effective, the entire organization can realize the full ben-

efits of its software assets.

Foolish AssumptionsAlthough its never a good idea to take anything for granted,we do have some beliefs about our readers. First, we expectthat you work in either IT or the line of business, and thatyour job somehow involves specifying, designing, develop-ing, or testing business software. We also assume that youreinterested in improving the way your organization deliversthese critical systems.



14/67

Requirements Definition & Management For Dummies2

How This Book Is OrganizedWe designed the five chapters of this book to give you a com-prehensive understanding of requirements definition andmanagement, business analysts and the challenges and oppor-tunities that they face, and how modern technology can cometo the rescue.

Chapter 1: Meeting the

Business AnalystThis chapter illustrates several business realities that haveled enterprises to give increasing responsibility to businessanalysts. We also introduce the people who perform thisessential role; we describe their education, professionalbackgrounds, daily responsibilities, and career paths.

Chapter 2: Conquering theChallenges of Business AnalysisBusiness analysts must overcome many hurdles in order toachieve maximum productivity and effectiveness. In thischapter, we look at each of the following challenges:

Diverse software development methodologies

Intricate business processes

Inadequate tooling

Cumbersome review cycles

Chapter 3: Building a BetterBusiness Analysis ExperienceLife doesnt need to be so difficult for the business analyst.Follow these three simple guidelines to dramatically improvethe effectiveness of defining and managing requirements, andachieve project success:



15/67

Introduction 3

Get visual

Get social

Get going

Chapter 4: Introducing BlueprintBlueprint is the preeminent vendor dedicated to deliveringsolutions that help define and manage software require-ments. In this chapter, you find out more about Blueprint, its

products, and how it has helped its customers improve theirrequirements definition and management.

Chapter 5: Ten Tips to ImproveBusiness Analyst ProductivityHere you can find a helpful collection of general-purposesuggestions that you can use to make the life of a businessanalyst more pleasant and productive.

Icons Used in This BookEvery For Dummies book features small illustrations, calledicons, sprinkled throughout the margins. We use the followingicons in this book.

The Tip icon guides you to right-on-target information to helpyou become a better business analyst.

The Remember icon highlights information that is especiallyimportant for you to know as you evaluate how to improvebusiness analysis procedures at your organization. To deter-mine the most important information in each chapter, look forparagraphs marked with this icon.

Seek out the On the Web icon if you want to find out evenmore about effective business analysis.



16/67


Where to Go from HereYou can read this book in any order that you want. What wemean is that we dont force you to start with Chapter 1 andread straight through Chapter 5. If you want to discover moreabout Blueprint, head to Chapter 4 first. Instead, if you wantto explore the role of the business analyst, read Chapters 1, 2,and 3. Want some quick tips on how to improve the businessanalyst experience? Check out Chapter 5. How you use thisbook is entirely up to you.

You can also check out additional information online atwww.blueprintsys.com/RDMforDummies.

http://www.blueprintsys.com/RDMforDummieshttp://www.blueprintsys.com/RDMforDummieshttp://www.blueprintsys.com/RDMforDummies


17/67

Chapter 1

Meeting theBusiness Analyst

In This Chapter Understanding todays business environment

Determining major stakeholders

Characterizing the business analyst

Predicting the evolution of the business analyst

Enterprises have never found software more indispens-able, whether firing photon torpedoes, raising deflector

shields, beaming up Scotty or just conducting regular busi-ness operations.

The importance of specifying, developing (or acquiring), andimplementing business applications correctly has increased in

recent years. The heightened emphasis companies have placedon designing and rolling out software, combined with diversefactors such as competitive pressures, mergers and acquisi-tions, globally distributed teams, and technological advance-ments, all contribute to growing demands and responsibilitiesfor a relatively new type of professional: the starship captain.No, were kidding: this new professional is called the businessanalyst.

In this chapter, we tell you all about the trends in the strangenew world of business and describe the vital role that thebusiness analyst plays.



18/67


Boldly Exploring the DynamicBusiness Environment

No matter what type of business you work in, your organizationmost likely relies on software to drive just about every aspectof daily operations. For decades, automation initiatives havefocused on back-office software, such as applications dedicatedto sales and marketing, accounting, human resources, andother internal functions. However, in recent years companies

have also increased emphasis on customer-facing enterprisesoftware solutions, such as websites, e-commerce portals, andself-service customer support, just to name a few.

Todays heterogeneous, multifaceted software inventoriesdeveloped over many years. As a result, businesses must nowmaintain a hodgepodge collection of software assets from dif-ferent origins and time periods. The company may have builtsome solutions in-house, external contractors may have built

others, and the company may have purchased still others offthe shelf from outside vendors. Lastly, some software mayhave arrived through mergers and acquisitions.

Given the ad-hoc way that systems come into being, they varywidely in terms of technology, design, quality, and maintain-ability. Regardless of the exact composition of your softwareportfolio, how well applications function both as stand-alone products and when working together as part of a larger

solution heavily impacts your business.

Though the technology landscape has transformed overthe years, the amount of change it has undergone pales incomparison with what has taken place in the overall businessenvironment:

Economic realities: Recent macroeconomic conditionsplace businesses under intense pressure to generate rev-

enue, reduce cost, and at the same time deliver outstand-ing customer value.

Competitive pressures: Businesses face a daily struggleagainst rivals new and old in much more dynamic andcompetitive marketplaces than ever before.



19/67


Outsourcing and distributed teams: In reaction totodays shrinking margins and competitive pressures,

many businesses turn to innovative cost-control andtime-to-market strategies.

Regulatory requirements: Governments and industryagencies alike are now much more energetic in theirdemands on business for governance and accountability.

Mergers and acquisitions: The challenging businessenvironment both forces and creates opportunities forbusiness restructuring in the form of selling off business

units or divisions, or of merging or acquiring entirecompanies.

As we describe in the introduction, the business analyst sitsat the very heart of the enterprises business software endeav-ors. Because software applications are now completely indis-pensable to business success, and because they operate insuch dynamic environments, the role of business analyst hasbecome essential and prominent. Before we look at who busi-

ness analysts are and what they do, however, we first detailthe other major players on a software project.

Engaging the StakeholdersWhether youre building software from scratch, or implement-ing a packaged software product that you bought from a vendor,more participants each with a highly diverse background may be attached to your project than you first realize.

As the primary party accountable for the delivery of the newor enhanced business application, the IT organization enlistsmany different types of people on a software project, includ-ing the following:

Project manager: Oversees all aspects of the initiative,right up to deployment into production.

Architect/Designer: Establishes and maintains a solidtechnical foundation across the portfolio, ensuring thelong-term viability of the new solution.

Developer: Develops the application from the ground up,or integrates a third-party solution into the overall tech-nology portfolio.



20/67


Tester: Ensures the developed application fulfills itsrequirements and seeks out and identifies any flaws in

the new system that may impact its ability to work asadvertised.

IT operations: Ensures that the solution is available andoperational for everyone who needs access, after thesolution has been built (or bought).

The business division also recruits a diverse talent roster:

Sponsoring executive: Business owner of the overall ini-tiative, and the person who usually signs the checks.

Client: Person representing the needs of the business ona daily basis.

End-user: Person, either internal to the organization orexternal, depending on the application, who will interactwith the new solution.

Partner: Internal employees and customers arent the

only stakeholders who participate on a new softwareproject. In todays collaborative world, many firms relyon tight-knit relationships with external partners.

Government and regulatory agencies: With so manyenterprises coping with externally imposed constraints,these parties sometimes have seats at the table as well.

Any given project can involve 10 or more unique types ofstakeholder, each of whom has a very different background,skillset, set of expectations, and obligations.

Although a modern software project involves so many play-ers, each of the roles mentioned in the preceding list has beenrecognized as a distinct and separate job for many years bymanagement, professional organizations, and vendors thatdesign and sell specialized solutions to help each execute hisor her role.

Yet one title is conspicuously missing from most roll calls: thebusiness analyst. In fact, management has only recently recog-nized this role and designated a formalized title. A significantnumber of organizations still dont even use this label. Whatmakes this state of affairs particularly ironic is that the busi-ness analyst plays a central role in coordinating the efforts ofeach of the different stakeholders on a project.



21/67


Business analysts did not have their own professional orga-nization until fairly recently: the International Institute of

Business Analysts (IIBA) didnt form until 2003.

To find out more about the IIBA, head to their website athttp://www.iiba.org.

In response to the newfound attention organizations arepaying to business analysts, vendors now market specializedsolutions to them as well. As we explain in Chapter 2, thesespecialized solutions are essential to helping business

analysts and their projects succeed.

Analyzing the (Business)Analyst

Although business analysts arent all identical, they do tend

to share a number of traits, characteristics, and commonbackgrounds.

EducationBusiness analysts are highly educated professionals and manyhold university degrees. A notable percentage of businessanalysts go on to earn advanced degrees in fields such ascomputer science, engineering, and business administration.

Work backgroundBusiness analysts often transfer into their roles from otherjob categories. According to a recent survey, the five mostcommon origins for business analysts are

Software development

IT operations

Line of business

Quality assurance

User community

http://www.iiba.org/http://www.iiba.org/


22/67


Place in the organizationIn general, about half of the surveyed business analysts reportto the IT division, with the remainder serving the line of busi-ness. Often those reporting to IT have a more technical skill-set (and sometimes have the title business systems analyst,or BSA) whereas those reporting to the business often havemore domain knowledge and experience.

Given that business analysis is such a new and developingfield, business analysts work on a diverse collection of teamswithin IT and business, such as:

Centralized business analyst team

Project/Program management office (PMO)

Quality assurance and testing


ResponsibilitiesEvery day, the business analyst collaborates with a broad col-lection of stakeholders from the IT organization, the line ofbusiness, and outside participants such as customers, part-ners, and governmental entities. To succeed, the businessanalyst must be capable of understanding the distinct needsof each stakeholder and communicate with them in language

that they understand.

At first glance, you may imagine that the business analystfocuses solely on defining and managing requirements, butthis aspect forms only part of the story. In fact, many busi-ness analysts are also responsible for ancillary tasks relatedto these requirements, such as program and project manage-ment, testing, and profit and loss outcomes.

Although in some cases stakeholders are concentrated inone location, more often they are distributed across multiplelocations. Dispersed stakeholders introduce additional com-plexities and challenges to the job of a business analyst, as weillustrate in Chapter 2.



23/67


Regardless of where the stakeholders operate, the businessanalyst must gather all relevant information, analyze it to

produce a set of requirements, validate these requirementswith the original stakeholders and sometimes other stake-holders as well, and then coordinate distribution of require-ments information across a wide audience, such as:

External customers

IT operations

Line of business

Quality assurance and testing

Software developers

Technical architecture team

In many ways the role of a business analyst parallels that of anauthor writing a story or screenplay either way, you couldcall it The Voyages of the Enterprise. Indeed, the businessanalyst must tell the story of the application that the businessneeds and do so in such a way that the business stakeholderscan easily consume the story and confirm that it meets theirneeds, and that the technology stakeholders (that is, testers,architects, and developers) can read it and understand whatthey need to test, design, and develop. As with any goodstory, the business analyst must use appropriate language,add in clear illustrations, and provide good visual imagery.

Because many organizations have only recently identifiedbusiness analysis as a separate and distinct job, businessanalysts often struggle with a lack of clearly defined and well-understood tasks, not to mention a scarcity of supportingtechnology.

Career trajectoryOrganizations are now starting to recognize the importance of

business analysis, and because of this development, new andexciting opportunities for advancement are opening up. Asmore companies adopt a business analyst center of excellence(CoE) or requirements management office (RMO) structure, theycreate well-defined career paths with manager- and director-level positions.



24/67



environmentsEnterprises employ an assortment of software developmentmethodologies. Common labels for these approaches includethe following:

Waterfall: In this approach, a project flows througha series of rigidly defined, sequential phases such asrequirements, design, development, testing, implementa-

tion, and deployment.

Incremental: This approach starts out with a relativelysmall set of project features, and then builds upon thisfoundation by integrating new parts as they becomeavailable.

Spiral: This is an incremental-based developmentapproach with a heavy reliance on prototyping toreduce risk.

Unified process: In this approach, a project relies heavilyon use cases to drive incremental software delivery.

Agile: This populist, developer-focused, highly iterativeapproach focuses on deliverable value versus interimwork products.

Hybrid: Enterprises can also create their own, site-specificblends of all of the above approaches. In particular, adapta-

tions of agile for larger organizations are rapidly evolving;these are sometimes referred to as enterprise agile, amongother monikers.

In the past several years, organizations have been more andmore drawn to the agile approach to developing software.Agile usually incorporates three traits:

Emphasis on speed, instead of time-consuming require-

ments definition Frequent software build/test/deploy cycles

Constant feedback and adjustments

As we explain in Chapter 2, agile software development tech-niques can add to the pressure on business analysts.



25/67


Imagining the FutureThe role of business analyst is continually changing. After all,the position is still relatively young compared to others in theorganizational landscape.

Business analysts operate in an environment of great confu-sion and uncertainty, but this environment also yields tremen-dous opportunity to create a demonstrable, positive impacton the entire business.

For example, organizations increasingly expect businessanalysts to be able to understand, explain, and justify howthe requirements that they help gather and organize delivertangible value to the business. This trend alone will definitelyhave major impacts on the responsibilities of the businessanalyst. Business-level accountability will soon be an integralcomponent of the business analyst job description, but satis-fying these responsibilities will be particularly difficult given

the obstacles business analysts already face each day.

In short the job of the business analyst is certainly a chal-lenging one, but one that is rapidly increasing in importance,has lots of room to grow and innovate, and looks to providetremendous opportunities. We are interested to see how thebusiness analysts role will change in the next generation ofenterprise!



26/67




27/67

Chapter 2

Conquering the Challengesof Business Analysis

In This Chapter Dealing with different development strategies

Keeping complicated business processes under control

Switching to specialized tools

Making review cycles more efficient

Seeing how inefficient business analysis affects real-world companies

As we describe in Chapter 1, enterprises, professionalorganizations, and vendors have long accepted and

understood most of the assignments on any given technologyproject. They have, however, only recently recognized theseparate and distinct job of the business analyst.

The challenges business analysts face are even more formi-dable because their daily responsibilities are in continualflux and undergoing ceaseless transformations. Why aretheir roles so fluid? Well, the answer lies in some soberingstatistics about IT projects: end-users take advantage of only45 percent of delivered features (according to the StandishChaos Report),and rework consumes 4050 percent of proj-ect budgets (Boehm and Basili). Issues that the project team

could have addressed when defining requirements are keycontributors to these unfortunate numbers. In fact, faultyrequirements form the root cause for 7585 percent of rework(Leffingwell). With the business analyst at the center of therequirements process, no wonder this role is attracting somuch attention!



28/67


Mainly due to the pivotal nature of the business analyst roleand its recent designation as a separate job responsibility,

business analysts struggle to overcome numerous impedi-ments. Some of the more pressing issues include:

Diverse software development methodologies

Intricate business processes

Inadequate tooling

Cumbersome review cycles

In the following section, we look at each of these obstacles inmore detail, and then connect the dots to comprehend whathappens to the entire organization when the business analystcant surmount these roadblocks.

Coping with Diverse Software

Development MethodologiesBusinesses constantly search for the most modern andefficient techniques for designing, developing, testing, anddeploying software. This focus isnt a surprise, especiallygiven the strategic nature of information assets such as soft-ware and data: well-designed systems deliver demonstrablecompetitive advantages that directly translate to marketshare and profitability.

Over the years, many organizations have sought out, selected,and then implemented numerous different and oftencontradictory approaches to creating software, all in afrenetic attempt to seize the often-elusive strategic edge.

This has led to an abundance of incompatible techniques thatthe business analyst must find a way to reconcile. Businessanalysts often encounter fragmented teams using their

own methods that can range from waterfall to incrementalto highly iterative agile, not to mention internally createdhybrids.



29/67

Chapter 2: Conquering the Challenges of Business Analysis 17

In recent years, the agile development approach has gainedconsiderable ground, and now many organizations consider it

a highly productive technique for delivering software. As youmay expect from its name, agile means responding quickly tochanges. Agile arose from developer dissatisfaction with rig-orous, prescriptive, heavy processes that, in the view of thesedevelopers, focused on the wrong elements.

Agile is not just one methodology but a family of methodolo-gies that sprung from a common set of principles called theManifesto for Agile Software Development, written by a group

of 17 developers in 2001 (see agilemanifesto.org). Themanifesto states the following:

We are uncovering better ways of developing software bydoing it and helping others do it. Through this work wehave come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, wevalue the items on the left more.

Coordinating teamsAgile teams are typically comprised of four to nine peoplewho play specific roles, although who plays each role canchange. These teams control planning and prioritization fortheir area of work, and they connect on a daily basis in aninteractive session called a scrum to coordinate and synchro-nize their efforts.

One of the most popular agile methodologies is called scrumand its traits are consistent with theManifesto for AgileSoftware Development.

http://agilemanifesto.org/http://agilemanifesto.org/


30/67


Sprinting to milestonesDevelopment proceeds in well-defined time periods calledsprints, which typically last two or three weeks and the resultof each sprint is a functioning, demonstrable portion of theproduct.

Clearing the backlogThe essence of an agile approach like scrum is its ability to

respond effectively to changes in priorities during the project.The project backlog is a prioritized list of the work to be done.The end of every sprint presents the opportunity to changedirection. In other words, you can start developing the nextsprint to a revised set of priorities as defined in the backlog.You can see an overhead view of this process in Figure 2-1.

Figure 2-1: Agile at work.

Agile is particularly daunting for the business analyst becauseof the marked reduction in the amount of time spent on and attention paid to the job of authoring, understanding,reviewing, and approving requirements before the scrumteams begin to develop the system. In fact, many cite the



31/67


alleged efficiencies this reduction causes as the best reasonto switch to an agile approach. Yet advocates of agile often

fail to recognize that paying less attention to these importantareas can cause havoc and chaos, waste time, and squandermoney.

Good requirements and agile are absolutely compatible inprinciple. Requirements are authored in agile prior to build-ing iterations of the system. These requirements are detailedfor each iteration individually to a level consistent with othermethods just before implementation.

Check out the Agile Alliance, an agile advocacy group, onlineatwww.agilealliance.org.

Managing ConvolutedBusiness Processes

The business analyst can properly and thoroughly author anddocument requirements for any new software solution onlyby fully comprehending the underlying and often extremelycomplex business processes that will be supported by thenew system. Because a project is full of unknowns, the busi-ness analyst must stay on top of these processes throughoutthe project. Speaking of rapids, in waterfall methodologieswhere the project team creates a more exhaustive and

detailed set of requirements up front, the lessons learnedalong the way are incorporated later in the form of enhance-ment requests. Agile, however, follows more of a learn-as-you-go approach. The business analyst position is dauntingenough when you examine it at face value, but a number offactors combine to make it even trickier:

Business processes are always evolving: Given how fastoperational procedures can change, the initially defined

requirements may quickly go stale.

IT and line-of-business stakeholders are dispersed:Conducting effective research is hard enough when allstakeholders each with his or her own set of needsand agendas can gather around a single conference

http://www.agilealliance.org/http://www.agilealliance.org/


32/67


room table. The task is much more imposing when thestakeholders are distributed around the world, where

they often work for different organizations. You can see avisual depiction of distributed teams in Figure 2-2.

The business itself may undergo rapid change: Verylittle is permanent today; regulatory changes, mergers,acquisitions, and sudden demands for more rigorouscost control can affect every enterprise.

Figure 2-2: Business analysts are at the heart of distributed team

collaboration.

Not only are business analysts confronted with agile softwaredevelopment techniques that devalue their work, and highlyinvolved business processes that change continuously, butsubpar supporting technology also hampers many businessanalysts which is what we describe next.

Overcoming Inadequate ToolingAccording to the voke Market Snapshot Report: The Role ofthe Business Analyst, 80 percent of business analysts still carryout their highly challenging jobs using generic, non-specializedpersonal productivity tools:



33/67


Primary requirements authoring: Microsoft Word

Principal communication channel: E-mail

Dependency tracking tool: Microsoft Excel

Read the full voke report to find out more about the businessanalyst position:www.vokeinc.com/research/topic/

market-snapshots.html.

From start to finish, the business analyst constantly has tofind ways to overcome each of the following difficulties intro-

duced by using general-purpose tools.

Writing when you couldbe drawing

Many people are most effective when they think and com-municate visually, especially about complex subjects like

creating a comprehensive software solution. Text is often apoor substitute to well-thought-out graphical representations(check out Figure 2-3 to see what we mean). If text is the onlyform of conveying information, the business analyst must gen-erate volumes that could be conveyed more effectively with asingle picture . . .

Figure 2-3: The contrast of using Text versus Images

http://www.vokeinc.com/research/topic/market-snapshots.htmlhttp://www.vokeinc.com/research/topic/market-snapshots.htmlhttp://www.vokeinc.com/research/topic/market-snapshots.htmlhttp://www.vokeinc.com/research/topic/market-snapshots.htmlhttp://www.vokeinc.com/research/topic/market-snapshots.htmlhttp://www.vokeinc.com/research/topic/market-snapshots.html


34/67


Typing when you dont need toThe act of writing a document consumes an unnecessaryamount of time, especially for a detail-oriented proceduresuch as designing a software solution. Ironically, as the reviewcycles plod on, business analysts feel compelled to write addi-tional text to provide more clarity, which makes the require-ments document even bigger, takes more time, and furtherexpands the review cycle.

Doing clerical work thatsnot your jobShepherding and organizing documents and review commentsis primarily a non-creative and time-consuming set of rotechores. Focusing on these tasks doesnt leave a lot of time forthe primary, strategic value of the business analyst: criticaland analytical thinking. Getting better at your job is nearly

impossible when youre busy putting out fires and workingwith inefficient tools.

On top of all these headaches, the true implications of subpartooling really become evident during the review cycle, par-ticularly when team members use general-purpose tools thatare not aimed at supporting the distinct needs of businessanalysts.

Conquering CumbersomeReview Cycles

After the first pass at creating a requirements document isdone, other project participants often give review cycles a lowpriority. They dont push the review process aside because

they are purposely ignoring their job responsibilities; they doso because the act of reviewing a massive document is tediousat best. Indeed, reviewing a massive document sets their facesto stunned. Furthermore, they may not even notice thedocument: if you email vital requirements documents theycompete with all sorts of other email clutter for reviewersattention.



35/67


The review-and-edit cycle consumes an incredible amount oftime, which can grow exponentially as the size of the docu-

ment increases. In fact, the bigger the document, the morelikely that the reviewers simply sign off without reading it.These blind approvals can create serious problems later on.

When reviewers actually do examine documents, the trackchangescapability of word processors doesnt encouragecollaboration. Instead, reviewers examine requirements docu-ments in isolation and clutter them even more with multi-colored markups. See Figure 2-4 for an example.

Figure 2-4: The inefficiencies of using track changes.



36/67


When it comes to dependencies and relationships among therequirements (traceability), business analysts must track

them using spreadsheets, which are notoriously inefficient forperforming these types of tasks. Compounding the problemfurther, spreadsheets dont include an automatic history ofchanges or evolution of the requirements.

Design documents, emails, and dependency tracking spread-sheets arent linked together, which means that team memberscan easily lose the thread and forget how the final designcame together.

Exploring the Economic Risks ofInefficient Business Analysis

Aside from making the business analysts job much moredifficult, significant financial and operational risks directly

result from the inefficient ways that organizations create andmanage requirements definitions. Risks include not only wast-ing money on the project itself, but also the economic impactof not solving the problem that the project is supposed toaddress. Often this latter risk is orders of magnitude worsethan the expenditures on the project.

For example, consider these real-world crises that failed soft-ware projects caused directly:

Ford Motor Company: Ford abandoned a $400-million-dollar purchasing system. To find out more, visit http://trunc.it/n0qf7.

New York City: The CityTime payroll system balloonedsignificantly over budget. It began as $63 million dollarproject, but ended up costing $760 million. You canread all the details at http://trunc.it/mji48.

Internal Revenue Service: The IRS abandoned a highlytouted electronic fraud detection system after a totalexpenditure of $185 million. This cost makes up onlypart of the damage, because the lack of a solution tofraud issues led to more than $800 million worth offraudulent refunds in the first year alone. Visit simplearchitectures.blogspot.ca/2009/09/cost-of-

it-failure.html and search for Fraud on the page.

http://trunc.it/n0qf7http://trunc.it/n0qf7http://trunc.it/n0qf7http://trunc.it/n0qf7http://trunc.it/mji48http://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://simplearchitectures.blogspot.ca/2009/09/cost-of-it-failure.htmlhttp://trunc.it/mji48http://trunc.it/n0qf7http://trunc.it/n0qf7


37/67


UK Electronic Health Records: The Department ofHealth abandoned the entire program after a $12-bil-

lion expenditure. You can find a brief overview here:www.ihealthbeat.org/articles/2011/8/5/uk-

health-system-expected-to-abandon-ehealth-

network.aspx.

U.S. Air Force Expeditionary Combat Support System:The Air Force cancelled the project after cost projectionsfor the project rose from $1-billion to $2.1 billion anddelivery projections climbed to eight years beyond theoriginal date. Investigators cited requirements as one ofthe root causes. Read the full story here: http://www.bloomberg.com/news/2013-01-24/senators-

to-probe-air-force-s-1-billion-failed-

software.html.

http://www.ihealthbeat.org/articles/2011/8/5/uk-health-system-expected-to-abandon-ehealth-network.aspxhttp://www.ihealthbeat.org/articles/2011/8/5/uk-health-system-expected-to-abandon-ehealth-network.aspxhttp://www.ihealthbeat.org/articles/2011/8/5/uk-health-system-expected-to-abandon-ehealth-network.aspxhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.bloomberg.com/news/2013-01-24/senators-%20to-probe-air-force-s-1-billion-failed-%20software.htmlhttp://www.ihealthbeat.org/articles/2011/8/5/uk-health-system-expected-to-abandon-ehealth-network.aspxhttp://www.ihealthbeat.org/articles/2011/8/5/uk-health-system-expected-to-abandon-ehealth-network.aspxhttp://www.ihealthbeat.org/articles/2011/8/5/uk-health-system-expected-to-abandon-ehealth-network.aspx


38/67




39/67

Chapter 3

Building a Better BusinessAnalysis Experience

In This Chapter Borrowing tactics from other disciplines

Making information visual

Collaborating with your team

Overcoming misconceptions that block progress

Predicting changes in business analysis

In Chapters 1 and 2 of this book, we describe all the nega-tive circumstances that business analysts must transcend.

But neither hodgepodge software assets nor convoluted busi-ness practices can stay these professionals from the swiftcompletion of their appointed duties: proven techniques can

make the business analysis process much smoother, moreefficient, and more pleasant for every stakeholder whichbenefits the entire organization, not just the business analyst.

The first step on the road to this happy destination is to real-ize that business analysts arent the only professionals whomust define complex systems. In fact, you can discover a lotby examining how other trades do it.

Taking Strategies fromOther Industries

The failures and abandoned projects that are so common-place in IT just arent tolerated in other endeavors, such as:



40/67


Architecture

Construction

Manufacturing

Transportation

After all, how often do you hear of an abandoned, half-constructed skyscraper?

How do designers and implementers in each of these tradescommunicate? Heres a hint: they dont generally write50-pound specifications to get their ideas across. Instead, theyuse visual representations whenever they can. These blue-prints and models communicate highly complex concepts inas streamlined a manner as possible.

They must be making some good choices, because buildingstake shape and remain standing, and airplanes roll out ontothe tarmac and fly.

IT organizations may not get to smash champagne bottles onthe front of a new software release, but who says they cantadopt these time-tested approaches to generating and dis-seminating blueprints?

Three major (yet surprisingly simple to follow) strategiesmake the job of creating software requirements easier:

Getting visual

Getting social

Getting going

Getting VisualAs we point out in Chapter 2, enormous text-based specifica-

tions are not the most effective way of communicating the



41/67

Chapter 3: Building a Better Business Analysis Experience 29

complex concepts that underlie modern software solutions.In fact, these massive documents may be the worst way

to present this type of information, especially becauseline-of-business and IT organizations dont commonly use thesame vocabularies to describe the same concepts. You cansee a sample of the types of terms used by business and ITstaff in Figure 3-1. (But keep in mind that the words in the leftcolumn dont match the words in the right column. Dont startcasually dropping the word widgetinto discussions withITstaff believing that its a synonym for earnings per share.)

Figure 3-1: Example vocabulary differences between business and IT



42/67


Instead of writing the next great novel, why not use theproven power of pictures, diagrams, flowcharts, user inter-

face mockups, and other well-regarded graphical techniquesto help arrive at a consensus about how you want the newsystem to work?

Switching from heavy reliance on text to a more balancedapproach using visual images delivers a number of attractivebenefits:

Clerical work doesnt take over: Business analysts no

longer perform the largely clerical role of maintaining anunwieldy text document. Instead, they can apply theircritical thinking and analytical skills to help deliverbetter solutions.

Language barriers disappear: Visual representationsarent burdened by perplexing cross-department orspoken language differences and are thus far easier tounderstand. A common visual language helps bring theproposed system to life.

Review cycles go faster: Clear, more visual representa-tions help to greatly reduce the amount of time spentduring the review cycle, and make reviewers more likelyto actually want to engage.

Bottlenecks expand: When the business analyst nolonger has to perform meticulous document mainte-nance, he or she is no longer the main impediment toprogress in the review cycle.

Taken together, all of these improvements bring clarity andefficiency to the software process including agile. Examplesof these visualizations are shown in Figure 3-2.



43/67


Figure 3-2: Taking a visual approach

Getting SocialThe most effective efforts arise when diverse and talentedteams collaborate, yet many software development projectsdo the opposite.

We can understand why team members find it hard to collabo-

rate; look at all the barriers they must overcome:

Distributed teams across separate time zones, languages,and cultures

Insufficient tooling, reflected by enormous specifica-tions that are assembled in documents and emailedeverywhere

Many different job functions

Never-ending review cycles

User resistance to endless review sessions



44/67


Despite what word processorsoftware vendors tell you,employing the track changes feature (shown in Figure 3-3) on

thick, heavy documents doesnt facilitate well-integrated, pro-ductive, and harmonious team collaboration, especially whenyour work incorporates complex and interrelated concepts.

Instead of continuing to suffer alone being tied to trackchanges, why not incorporate some proven social-based tech-niques to get people working together?

Historically, requirements definition efforts have generally gone

onward with relatively little interaction primarily because thesupporting tools werent mature enough, resulting in practitionersspending all their time with their heads down working in silos.

Figure 3-3: The inefficiencies of using track changes



45/67


But now solutions are available on the market that blend thevisual approaches we describe earlier in this chapter with

sophisticated yet easy-to-use collaboration features such as:

Inline discussions that traverse departments and timezones

Easy online self-service review and approve

See the inline discussions of a streamlined review cycle inFigure 3-4.

Figure 3-4: Inline discussions in a streamlined review cycle.



46/67


A streamlined review cycle lets stakeholders decide how,when, and from where they want to participate, instead of

being caught and dragged into meetings.

Getting GoingTwo perceptions among IT organizations have formed barri-ers to business analysis progress.

Reengineering processesTo begin with, many organization members believe they mustfirst reengineer all of their processes before bringing in sup-porting technology. This belief just isnt accurate its amyth that must be busted.

With such little investment made in business analysis toolingin the past, the new crop of products represents a huge leap

forward in capability. These capabilities make possible pro-cesses that organizations otherwise may not even consider,so crafting a process without regard for the tools can result inmissing these opportunities. Instead of waiting for the perfectprocesses to arrive, why not employ technology up front tohelp improve these critical processes in a more evolutionaryfashion? Having the right tool allows organizations for thefirst time to make specific process improvements that theycan then use to drive further refinements and new process

definitions. Thus, deploying the right tooling serves as a cata-lyst for many future optimizations.

Rolling out softwareThe other misconception IT organizations have is that ifthey implement powerful new technology they must makewholesale changes to the way they conduct daily operations.

Many new solutions aimed at the business analyst, however,are perfectly capable of rolling adoption: certain features areenabled up front, and others are incorporated as time andbusiness needs require.



47/67


After all, most users of Microsoft Excel employ only about 5percent of its full capability, yet they still derive tremendous

value from it.

You can find out more details about the Blueprint softwaresolution in Chapter 4, but see Figure 3-5 for the possibilitiesof a phased rollout of a requirements definition and manage-ment solution.

Figure 3-5: Sample steps in a phased rollout from Blueprint.

Forecasting the FutureBy now you can see that the business analyst performs ahighly dynamic, subjective job to say the least! Where isthe business analyst role heading? We see at least four trendsthat will continue to impact the business analyst:

The role will become even more formalized and influentialas companies realize its importance to the organization.

More will be expected of business analysts as they will

increasingly take responsibility not only for feature-ladennew solutions, but also for the business value realizedfrom them.

Business analysis centers of excellence (CoEs) and require-ments management offices (RMOs) will emerge and grow inprominence as they increasingly prove their value.

Business analysts will become pivotal for large enter-prises currently struggling to adopt agile practices as

they recognize the key role requirements play in larger,distributed initiatives.



48/67




49/67

Chapter 4

Introducing BlueprintIn This Chapter Checking out the companys background

Exploring the solutions Blueprint offers

Observing Blueprint in action

As we depict in Chapter 1, management, professionalorganizations, and vendors are finally giving business

analysts the recognition and respect they deserve. Blueprintis one of the most prominent solution providers to servicethese previously ignored professionals.

In this chapter, we introduce you to Blueprints product, alsonamed Blueprint, which was designed specifically for busi-ness analysts. We begin by describing the background andfounding philosophy of Blueprint, followed by an overview ofits product. We pay particular attention to how you can put

Blueprint to work to overcome the barriers to success thathave been frustrating business analysts for years. We thenshowcase several examples of Blueprint delivering tangiblebenefits to its clients.

Highlighting the History

of BlueprintBlueprint was founded in 2004 and was a pioneer in theemerging discipline of requirements definition. Since thattime, Blueprint has focused entirely on providing solutions toeliminate the problems associated with defining and managingsoftware requirements.



50/67


According to industry data, creating or enhancing businessapplications is fraught with budget and schedule overruns.

This process also heavily influences application quality. Manyof the issues organizations experience stem from poor orinadequate levels of interaction between business stakehold-ers and the IT professionals developing the software.

Blueprint can transform this business-IT relationship intoa visual and engaging collaboration. Errors and omissionssurface earlier, team members deliver a higher-quality set ofapplication requirements sooner, and requirements-related

rework which studies show consumes 4050 percent ofproject budgets on average shrinks. Blueprints unifiedapproach improves the probability of delivering applicationson time and on budget. Predictable project schedules com-bined with faster time to market is critical to the competitivesuccess of Blueprints global customer base, and these cus-tomers depend on Blueprint to achieve their goals.

Find out more about Blueprint here:www.blueprintsys.com.

Sorting through BlueprintSolutions

In this section, we tell you more about how Blueprint solvesthe difficult requirements definition and management prob-

lem. To help bring the discussion to life, we examine theimpact of Blueprint on several of the most essential jobresponsibilities of the business analyst.

Authoring requirementsAs we describe in Chapter 3, business analysts must continu-ally strive to replace words with visual representations whencreating requirements. Doing so helps to remove ambiguityand make the resultant requirements more engaging andeasier to understand.

http://www.blueprintsys.com/http://www.blueprintsys.com/http://www.blueprintsys.com/http://www.blueprintsys.com/


51/67


Blueprint provides a broad range of rich, visual requirementseditors, as shown in Figure 4-1. You can choose the format

thats perfectly suited to each type of requirement, whichpromotes consistency and ensures that you dont miss anyimportant elements.

Figure 4-1: Blueprint provides a wide range of visual requirement editors.

Validating requirementsCreating a well-defined set of requirements is just the start:

making sure that they are correct is equally important. Blueprintengages stakeholders and helps them confidently drive a setof requirements to final approval. Blueprints online reviewand approve interface makes reviewing requirements fast andeasy for stakeholders, while review dashboards let the busi-ness analyst control, coordinate, and conclude large-scalerequirements reviews among the diverse set of stakeholdersthat are so common on todays software projects.

Blueprints rich visual requirements simulations keep stake-holders engaged and let them understand the true meaningof the requirements a fundamental prerequisite for obtain-ing better feedback. Blueprint also automatically generates



52/67


requirements documents that support existing companyprocesses and provide the hard-copy artifacts that are

often needed for official sign-off. To get a better idea of theBlueprint softwares approach to interactive online review,approvals, and requirements simulations, see Figure 4-2.

Figure 4-2: Blueprints visual and interactive requirements simulation.

Managing requirementsEven after youve authored and validated your requirements,you must still maintain them, track their histories, and keeptabs on how they evolve over time. Blueprint was designed

with the entire requirements lifecycle in mind.

To begin, Blueprint automatically versions every requirement,which makes it possible to examine each requirements entirehistory beginning with the baseline. Next, Blueprint quicklycreates traceability thats visible while working and is easyto analyze through a suite of powerful tools. Traceabilityhelps you assess the impact of change, confirm coverage, andmanage scope. Figure 4-3 shows the fine-grained traceability

features of Blueprint.



53/67


Blueprint also encourages requirements reuse, which savestime while promoting consistency. Finally, seamless integra-

tion with enterprise directories aids in bringing new usersonboard and simplifies the job of project maintenance.

Figure 4-3: Traceability with Blueprint.

Collaborating with team membersAs we depict in Chapter 3, teamwork forms the foundationfor successful software projects. Blueprint helps users stay intune with whats happening across multiple projects througha wide range of social features, including a personal activity

centerand threaded discussions with @mention see it inaction in Figure 4-4. These capabilities are pervasive through-out the product, which helps draw people into the conversa-tion and encourages interaction.

Meanwhile, Blueprint employs visual requirements formatsand rich simulation to foster collaboration by removingambiguity and making complex requirements easier to under-stand. In addition, instead of getting vital stakeholder feed-

back later in the lifecycle, with Blueprint you have access tothe features you need to engage stakeholders early and oftenduring the project.



54/67


Figure 4-4: Threaded discussions with @mention.

Integrating with other

technologiesIn Chapter 2 we demonstrate that the business analyst sits atthe center of the entire software project lifecycle. Therefore,for maximum effectiveness, any business analysis tools musttie in with technologies used by other stakeholders.

Blueprint incorporates practical integrations with the mostpopular tools project team members use on application devel-

opment projects. It automatically generates a comprehensiveset of tests from the requirements, and then populates appli-cation lifecycle management(ALM) solutions with those testsand the underlying requirements including complete trace-ability. Figure 4-5 shows Blueprint generating test cases.

Blueprint also provides integration with Microsoft Excel thatlets users directly leverage the spreadsheet softwares manyfeatures, or use it as a conduit to other third-party toolsets.

These integrations help ensure alignment of all groups whocollaborate on application projects.



55/67


Figure 4-5: Generating test cases with Blueprint.

Watching Blueprint at WorkIn this section, we take you through a few examples of whatBlueprint has been up to. We detail some real customerexamples, and show you how Blueprint has transformed therequirements definition and management process, along withdemonstrating the meaningful impact this transformationhas had on overall business performance. Getting blue isnt

always so bad!

Banking industry solutionsA large global banking institution embarked on a multiyearprogram to upgrade their core banking systems. All of theover 1,000 people (distributed across 26 countries) in the pro-gram who are authoring or collaborating on requirements are

using Blueprint. To enable such a large group of users, andsustain them as staff and outsourcers change over time, theinstitution is leveraging the online e-learning component ofBlueprint, allowing any number of users to learn at their ownpace and their supervisors to track their progress.



56/67


Legal industry solutionsA prominent solution provider to the legal industry had totransition its flagship software product to a more modernplatform and enhance it with significant new capabilities. Theorganization turned to Blueprint as the requirements applica-tion to define and manage this business-critical effort. Due tothe success of this initiative, the company has since standard-ized on Blueprint as the requirements application used on allIT software projects, enterprise-wide.

Health industry solutionsOne of the largest health insurance organizations in theUnited States recognized it was experiencing too muchrework, and reengineering, as well as poor requirements, andorganization members knew they were not taking advantageof reuse opportunities in the area of requirements. In thisenvironment, the organization had a mandate to update their

systems to be ICD-10 compliant, a major undertaking acrosstheir systems, before October 2013. After extensive researchthey selected and deployed Blueprint, and formalized theirrequirements processes around it as their standard require-ments platform. Today their development projects are farmore predictable, reuse and efficiency has increased, andthey are well on their way to attaining ICD-10 compliance.

Legacy modernization solutionsA very large pension-provider organization needed to mod-ernize a business-critical application hosted on a mainframesystem. The application had to adhere to strict pension legis-lation or risk substantial penalties. The organizations existingrequirements processes didnt provide good visibility into theas-is state of the system, putting all modernization work athuge risk and processes were so onerous that people regu-

larly subverted them to get their jobs done. After deployingBlueprint, communications and collaboration around require-ments improved to the extent that stakeholders now seevalue in business analysis where before they had seen onlyoverhead. The as-is state of the system is now modeled for allto analyze and understand. As a result, the application wasdelivered on time and now operates in full compliance.



57/67

Chapter 5

Ten Tips to ImproveBusiness Analyst

ProductivityIn This Chapter Putting the power of pictures to work for you

Including your stakeholders every step of the way

Making life easy for your developers, your testers, and yourself

Throughout this book, we tell you about the ever-changingrole of the business analyst, the challenges business

analysts face, and how they can take steps to make projectsgo more efficiently. This chapter puts all of this information towork by presenting you with a series of field-tested guidelines

and best practices.

We begin by offering some suggestions about requirementsauthoring, followed by several recommendations about howto more effectively work with all of your stakeholders. Finally,we provide a collection of our thoughts regarding smooth col-laboration with the people charged with bringing your visionto life: architects, developers and testers.

Leveraging Visual ModelsIn Chapter 3 we describe how diverse professions rangingfrom architecture to mechanical engineering all use visualiza-tions wherever possible. Visual models are absolutely critical



58/67


if youre going to do good analysis, and especially when defin-ing complex solutions such as software. Get into the habit of

turning to visual representations whenever you can.

Want more details? Check out Joy Beattys and AnthonyChens book Visual Models for Software Requirements, here:http://trunc.it/n5x28.

Expressing Your RequirementsEvery business analyst has the potential to do a great jobworking with their stakeholders to create very expressivevisual models, but thats only part of the story. These graphi-cally rich artifacts are also superb for quickly and cleanly get-ting information across to others such as developers, testers,support and operations staff, and more, as you fully definethe requirements for your new solution. See an example inFigure 5-1.

Figure 5-1: Expressing requirements visually.

You can use these models by themselves, or reference themin requirements.

http://trunc.it/n5x28http://trunc.it/n5x28


59/67

Chapter 5: Ten Tips to Improve Business Analyst Productivity 47

Setting the Stage for EffectiveCollaboration

Healthy partnerships dont happen by accident. Instead, theyresult from establishing the communication channels that youwant people to use, and then making sure these conduits areaccessible and efficient. If you fail to take these steps, peopleget frustrated and simply bypass your painstakingly createdinfrastructure. The end result is a flood of inefficien

Requriements definition& managment for Dummies

Documents

Transcript of Requriements definition& managment for Dummies