复制成功
  • 图案背景
  • 纯色背景
  •   |  注册
  • /
  • 批注本地保存成功,开通会员云端永久保存 去开通
  • 网上数字图..

    上传于:2015-05-31

    粉丝量:1171

    所发布亚博足球app下载来源于互联网和个人收集,仅用于分享交流和学习使用,请下载后于24小时内删除,版权为原作者所有,请支持购买原版。因上传亚博足球app下载受大小限制,部分亚博足球app下载拆分上传,请浏览确认后下载。如有侵犯您的版权,请通过站内信息告知,将立即删除相关资料.如有其它问题也欢迎联系,谢谢!

    

    计算机书籍 计算机书籍 Artech.House.The.Requirements.Engineering.Handbook

    下载积分:600

    内容提示: The Requirements EngineeringHandbook For a listing of recent titles in the Artech House Technology Management andProfessional Development Library, turn to the back of this book. The Requirements EngineeringHandbookRalph R. YoungArtech HouseBoston • Londonwww.artechhouse.com Library of Congress Cataloging-in-Publication DataA catalog record for this book is available from the U.S. Library of Congress.British Library Cataloguing in Publication DataA catalog record for this book is available from the Br...

    亚博足球app下载格式:PDF| 浏览次数:3| 上传日期:2015-05-31 08:31:24| 亚博足球app下载星级:
    The Requirements EngineeringHandbook For a listing of recent titles in the Artech House Technology Management andProfessional Development Library, turn to the back of this book. The Requirements EngineeringHandbookRalph R. YoungArtech HouseBoston • Londonwww.artechhouse.com Library of Congress Cataloging-in-Publication DataA catalog record for this book is available from the U.S. Library of Congress.British Library Cataloguing in Publication DataA catalog record for this book is available from the British Library.Cover design by Igor Valdman© 2004 ARTECH HOUSE, INC.685 Canton StreetNorwood, MA 02062The following are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University: CapabilityMaturity Model, CMM, and CMMI.All rights reserved. Printed and bound in the United States of America. No part of this book may be reproducedor utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by anyinformation storage and retrieval system, without permission in writing from the publisher.All terms mentioned in this book that are known to be trademarks or service marks have been appropriatelycapitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should notbe regarded as affecting the validity of any trademark or service mark.International Standard Book Number: 1-58053-266-7A Library of Congress Catalog Card number is available from the Library of Congress.10 9 8 7 6 5 4 3 2 1 For youLet’s improve requirements engineering! . ContentsForeword ..............xiPreface...............xvAcknowledgments ...........xix1The Importance of Requirements .......1What Are Requirements and Why Are They Important?Why Plan?A Suggested StrategyRequirements Activities in the System Life CycleInvestment in the Requirements ProcessA Process ApproachThe Requirements PlanFactors Affecting Your Career DecisionsA Comment Concerning Small ProjectsSummaryCase StudyReferences133356710111112132The Roles of the RA ...........15Suggested Roles of the RASummaryCase StudyReferences15232425vii 3Skills and Characteristics of an Effective RA ...27Skills of the RACharacteristics of an Effective RASummaryCase StudyReferences27344243444Types of Requirements..........45Views of Requirements TypesDefinitions and Descriptions of Requirements TypesBusiness Requirements454849Stated Requirements Versus Real Requirements50User Requirements50High-Level or System-Level Requirements50Business Rules50Functional Requirements51Nonfunctional Requirements52Derived Requirements52Design Requirements and Design Constraints52Performance Requirements53Interface Requirements53Verified Requirements53Validated Requirements53Qualification Requirements53The “Ilities” and Specialty Engineering Requirements53Unknowable Requirements54Product Requirements54Process Requirements54Logistics Support Requirements54Environmental Requirements55System, Subsystem, and Component RequirementsTerminologies to AvoidSource or Customer Requirements555555Nonnegotiable Versus Negotiable Requirements55Key Requirements56Originating Requirements56Other GuidelinesExamples of Requirements TypesSummaryCase StudyReferences5656575760viiiContents 5Gathering Requirements .........61Plan the ApproachSummaryCase StudyReferences621041041056Best Practices for Requirements Developmentand Management ...........109SummaryCase StudyReferences1231231267The RA’s Specialty Skills .........127SummaryCase StudyReferences1591631648An Integrated Quality Approach......169Business Drivers for QualityManagement’s RoleGuiding PrinciplesPriority ManagementThe Components of an Integrated Quality ApproachQuality Improvement TechniquesThe PDCA CycleHow to Design a ProcessTeamworkSummaryCase Study: An Example of Quality Improvement SidetrackedReferences1701701711721721731791801871891891919A Vision for Requirements Engineering ....193How Should We Support PMs?How Should We Support Customers?How Should We Support Developers?SummaryCase StudyReferences197198198199200202Contentsix 10Moving Forward: Knowable Requirements,Manageable Risk ...........205Where to Go from HereMoving ForwardA Requirements MandalaSummaryCase StudyReferences207209212213213215Glossary ..............217List of Acronyms...........227Bibliography............233About the Author ...........243Index ...............245xContents ForewordSracks of electronics equipment, and a sophisticated set of remote radios andcomputers. Development disciplines included software engineering, digitalelectronics, communications electronics, and mechanical engineering.Customer acquisition and user groups knew what operational capabilitythey wanted, but there had yet been no technical requirements. Early in theproject, the company developed and delivered a technical specification.Customer reviewers provided dozens of changes, including six additionalrequirements that they interpreted from the loose operational capabilitystatements. In later discussion, however, customer people agreed that theseadditional requirements, although nice to have, were too expensive to add.Time passed. The project had political and funding problems, bouncingup and down over a period of four years like a short-hop shuttle airplane.Personnel changed several times; in one such change, the project apparentlyterminated and the entire acquisition group was reassigned. After twomonths of hiatus, a new acquisition group resumed the project.The technical specification went through several more revisions. Some-how, the record of those six requirements remained. The record of theagreement, however, was repeatedly lost. They were reinserted repeatedlyby customer reviewers. After each revision, those six requirements wereagain deemed too expensive to add. But the specification was never quiteapproved to reflect the agreement. In the throes of responding to the fre-quent upheavals, the developers focused on completing the design and pro-duction. The specification faded onto a dusty shelf.Things on a dusty shelf have a way of coming back to haunt. Those sixrequirements came to light one last time. During system acceptance testing,customer monitors blew the dust off the specification and started a formalverification.The result of six missing requirements was a three million dollar overrun.Ralph Young’s book provides the tools that company needed and did nothave. Building on Effective Requirements Practices and on his years of practicalexperience, Ralph offers a set of tools and techniques that are essentialfor modern requirements analysis, written into a handbook format forome years ago, a successful company won a contract for a fifty milliondollar project. The product system had six operator consoles, another sixxi continued reference. This book describes both the philosophy and practiceof requirements analysis, with down-to-earth pragmatism that can help todo the job in the face of today’s complex system challenges.Human communications are imprecise. It is one aspect of nature ofhumanity that we fail to understand each other completely.Recall the campfire games of your childhood. In the game “Whispers,”someone starts a short statement around the campfire circle by whisperingto his neighbor. In turn, each player passes on the statement, always in awhisper. After only a few transfers, the original statement is modifiedbeyond recognition. In the game, the differences are so astonishing as tobring laughter to all.Recall the last time you went to a restaurant and ordered from a menu.Written in front of you is a full description of the entree you want. Confi-dently, you tell the waiter the entree. The waiter silently sighs and starts theperennial sequence of questions about side items. “Salad or soup, ma’am?”“New potatoes or French fries?” “Green beans or succotash?” All theseoptions were clearly written on the menu, but somehow you missed them.Requirements are also a form of human communications, an attempt toconvey complex ideas from one mind to another. Requirements are also asparse form of communications, using bare written words to strive for preci-sion. Like menu descriptions, requirements always fall short. It is literallyimpossible to write any requirement, no matter how simple, that cannot bemisconstrued honestly by some recipient.Even the word “requirement” is itself a miscommunication, for individ-ual requirements are frequently flexible rather than required. If a trade-offpromises a significant benefit to a key performance parameter, specifiers willgladly change lesser “requirements” to accommodate the trade-off.And yet requirements are still the best method we know to convey thecomplexity of a technical idea. To handle this complexity, we use require-ments to perform three important roles, all of which are enhanced by thetools and techniques in this book.First, requirements are a contractual tool. This is the most commonlyunderstood purpose. In this role, a specification defines the technical scopeof a development contract. The legal impact of this role is far from small.One recent lawsuit between a prime contractor and a subcontractor hingedon the grammar of a single requirements statement, resulting in a multimil-lion dollar settlement. For the protection of both acquirers and suppliers,contractual requirements must be as clear as they can be.Second, requirements are a configuration management tool. The exactform and relationship of the requirements statements uniquely define a con-figuration of the system. They embody the valid system functionality andbounds. By controlling the requirements, we control the configuration defi-nition. We see the importance of configuration definition each time a newsoftware tool fails to operate with our “open system” personal computer.Third, requirements are an engineering tool. This essential role is fre-quently not understood, being overshadowed by the contractual andxiiForeword configuration management roles. Yet it is in engineering that requirementshave their power. We use requirements during the engineering processes todo the following:◗ Communicate among development team members, acquirers, users,and others;◗ Describe and understand the operational need;◗ Capture decisions about the technical solution;◗ Define the product architecture;◗ Check completion of the product elements;◗ Verify completion of the product.The problem of those six requirements happened due to many fac-tors—the political changes to the program, the competing ideas among thecustomer factions, the unusual pressures of start-and-stop development,and the development team’s focus on completion. That problem also hap-pened, however, because of the lack of the requirements management (RM)methods that this book contains. A modern RM effort for the entire projectwould have cost a fraction of the three million dollars of overrun experi-enced. Even better, many other expenses would also have been avoided.Like the children around the campfire, informality leads to miscommu-nications. As a campfire game, we laugh at the problems. In building today’scomplex system products, though, we are no longer laughing.Eric HonourFormer President, International Council on Systems EngineeringForewordxiii . PrefaceTmentsforplannedsystemsandsoftware,bothincomputingandengineering.It is a desk guide/handbook that focuses on how RAs can best perform theirwork.The requirements are key to the success or failure of technical projects.They are the basis of all of the follow-on work. It’s been my experience thatmost projects and organizations fail to use effective requirements practicesand a documented requirements process, and also that those assigned asRAs are cast into the needed work without proper preparation, experienceand training, and without a good handbook that advises them on how toperform their roles and what to do.RAs are in a strategic position to influence the activities performed on asystems or software engineering task or project:hisbookisintendedasaconcisebutthoroughreadyreferenceforrequire-ments analysts (RAs)—those who are assigned to determine the require-◗ The requirements are vital to the initiation, conduct, and completionof the needed work.◗ They are of great importance in achieving the objectives of customersand users.◗ Trained, experienced RAs are valued advisors to the program, project,or task manager and invaluable resources for other members of theteam.This book addresses all of the areas that you will need to know about inyour work. Key topics include the following:Topic◗ The importance of requirements.◗ Leveraging requirements-related activities to benefit your project.◗ Identifying the real requirements.xv ◗ Controlling changes to requirements and new requirements.◗ Use effective requirements practices, processes, methods, techniques,and tools.◗ Invest in the requirements process.◗ Evaluateyourrequirementsagainstthecriteriaofagoodrequirement.◗ Document the rationale for each requirement.◗ Plan requirements-related activities.◗ Use an industrial strength automated requirements tool.◗ Work to improve communications. Use a project glossary and acro-nyms list.◗ Incollaborationwiththetaskorprojectleaders,selectasetofbestprac-tices, and then implement them effectively.◗ Develop a personal professional development plan, and enhance yourskills and capabilities.◗ Learn and apply needed requirements analyst’s specialty skills.◗ Define and use an integrated quality approach.◗ Evolve your own personal vision for requirements engineering.◗ Address requirements risks.Chapter 2 describes nine roles of the RA and identifies where in the sys-tem life cycle each should be applied. Requirements work requires a lot ofknowledge and skills—perhaps more than most people think. Chapter 3identifies and describes skills that you may need to use and provides a refer-ence in this book where you can learn more about each skill.It’s important for the RA and others assigned to the task or project tounderstand the different types of requirements. These are described in detailin Chapter 4 and are broken down as follows:◗ Business requirements;◗ User requirements;◗ Product requirements;◗ Environmental requirements;◗ Unknowable requirements.Customer needs and expectations are analyzed and described in the fol-lowing ways:◗ High-level (or system-level) requirements;◗ Functional requirements (what the system must do);xviPreface ◗ Nonfunctional requirements:◗ System properties (e.g., safety);◗ The “ilities/specialty engineering requirements”;◗ Derived requirements and design constraints;◗ Performance requirements (e.g., how fast?);◗ Interface requirements (relationships between system elements).Then the system requirements are allocated into the following:◗ Subsystems (logical groupings of functions);◗ Componentsdocumentation).ofthesystem(hardware,software,training,Checks are done to ensure the system does what it is supposed to do,incorporating the following:◗ Verified requirements;◗ Validated requirements;◗ Qualification requirements.The following are evident from this description of requirements activities:◗ A common, shared understanding is needed on the task or project;◗ Requirements-related training should be provided to three groupswith somewhat different needs, so that all can benefit from industryexperience and become aware of the methods, techniques, and toolsthat work best: (1) RAs, (2) the members of the development team,and (3) the customers and users.These topics are addressed in Chapter 5.The requirements gathering activities are complex and can easilybecome ineffective, as you likely are already aware from your experience!See Table 5.1 for a checklist that will help you in your vital roles.Chapter 5 provides a discussion of each activity, explaining why it’simportant and how to get it done. References enable you to access moreinformation, should you want it. The intent of the book is to empower you tomake a valued contribution and also to be fulfilled in your work activities.We hear and read a lot about “best practices.” Unfortunately, they aretoo infrequently deployed, implemented, and institutionalized on real proj-ects, for a variety of reasons, but most importantly, because it’s hard work.Chapter 6 provides information concerning best practices for RAs, based onmy own and industry experience. Obviously, one can’t do everything, atleast not at one time. The information in Chapter 6 will enable you to initi-ate discussions with your task or project team and to select the best practicesPrefacexvii that best support your project’s or your organization’s needs, activities, andobjectives.There is a set of specialty skills of the RA that are required at differenttimes in your work. Chapter 7 describes these specialty skills and directs youto the section in this book where each is discussed.Chapter 8 explains the importance of an integrated quality approach.An effectively implemented requirements process is necessary in order tohave an integrated quality approach, and an integrated quality approach isrequired for the requirements process to work best. Chapter 8 explains whatis meant by these terms and, also, how to achieve them.Chapter 9 provides a vision for requirements engineering. You willbecome aware (if you are not already) that progress in requirements engi-neering has been slow. This book is dedicated to you, with the challenge toimprove the practice of requirements engineering! This book is full of practi-cal ideas, suggestions, approaches, and recommendations and will serve youwell as a handbook in your daily work. But, only if (1) you use it, and (2)you are determined to work to make things better. This suggests that youneed to be committed to making changes that improve the way we developsystems and software. Too often we don’t practice what we preach. Weknow what we should do, but we don’t do it. The bottom line is that yourcommitment and that of your peers and managers is required if we are tomake improvements. Use this book to guide you in your vital work. Further, youwill be able to create and implement your own professional-developmentplan based on the characteristics and traits you choose to further strengthenand improve. I encourage you to work in concert with your manager toevolve a plan of action to enable you to understand comprehensively yourroles and, through experience and study, develop the expertise needed toimpact project success rates significantly and positively.Chapter 10 provides a summary of the book and suggestions for movingforward. The subtitle, “Knowable Requirements, Manageable Risk” suggeststhat we really can do a commendable job when we are empowered andapply the guidelines provided in this book. By doing so, you will be helpingthe computing and engineering professions to improve.Let’s acknowledge that we have a long way to go. But guidance is avail-able concerning how to make improvements (in our policies, practices,processes, methods, techniques, and tools, for example). In order for the pro-fession to improve, practitioners need to take actions in their daily work that are dif-ferent from what we are doing today. Only through gradual, but committed,incremental actions will the profession advance to achieve a positive visionof requirements engineering.Are you ready?Please share any of your own reactions to this book, ideas, suggestions,and constructive criticisms with me at ryoungrr@aol.com. I will no doubt behard at work on another project, and your feedback will improve any con-tributions I may make.Good luck, and remember to have fun while you are doing all of this!xviiiPreface AcknowledgmentsI continue to be very thankful to my wife, Judy, for her incredible patience,understanding, and love throughout the book writing process. Family andfriends are sometimes amazed at the joy and energy I derive from writ-ing—for me, it’s as Maryanne Radmacher-Hershey characterizes it:Writing is the process one follows to learn what is already known deepwithin: it sharpens the spirit, disciplines the mind, and leads to solutions. Inthe spaces between words and solitude observe what happens when wordsand silence meet. Words matter. Pay attention. Write to learn what youknow.As for those who have supported me, how can I appropriately acknowl-edge reviewers and contributors who have given so generously and so muchto make this a better book? Suffice it to say that many people have becomeclose friends and valued advisors.Speaking of advisors, there is one whose name I do not even know!Artech House Publishers engaged an advisor to review my final drafts. Thisperson, obviously an expert in requirements engineering, chose to remainanonymous and provided constructive and helpful comments on eachchapter.Speaking of requirements-engineering experts, Ian Alexander gener-ously provided thoughtful comments and insights in countless areas,responding in almost real time to questions, inquiries, and requests forreview comments. Randall Iliff, engineering and project management men-tor, also provided great insights in several areas. Jeff Grady, Earl Hoovler,Capers Jones, John Moore, Rich Raphael, and Doug Smith contributedthoughtful and useful ideas and wording.Requirements analysts who are members of the Northrop GrummanInformation Technology Defense Enterprise Solutions Requirements Work-ing Group provided valued review comments, contributions, and lent theirexperiences and expertise—Terry Bartholomew, Michael Davis, DavidEbenhoeh, Bob Ellinger, Jim Faust, Graham Meech, Dick Pederson, Richxix Raphael, Dave Reinberger, Ron Rudman, Charlie Rynearson, and JohnWaters, in particular.Other requirements analysts who made valued contributions includeDorothy Firsching, Chris Fowler, Heather Gray, Skip Jensen, WayneO’Brien, Joy van Helvert, Charlie Wight, and Don Young.The graphics, illustrations, tables, and figures are critical components ofany work because they convey ideas and summarize information. Thanks toRich Raphael for creating many of those in this book, for his expertise incrafting and refining them, and for his constant willingness to help in anyway possible. Olga Rosario also contributed greatly.Many of the “artifacts” in the book benefited from additions, corrections,and review comments contributed by participants in my requirements engi-neering courses, tutorials, presentations, and workshops that I love to pres-ent. Thanks to all of you, particularly Pat Little.Other friends and associates who lent a hand and mind include BarryBoehm, Grady Booch, Dennis Buede, Pete Carroll, Tom Gilb, Ellen Gottes-diener, Eric Honour, Alice Hill-Murray, Craig Hollenbach, Ivy Hooks, RayHuber, Charles Markert, Andy Meadow, Larry Pohlmann, Olga Rosario,Penny Waugh, and Beth Werner.Reviewers, including many of those previously mentioned, havestrengthened my writings. Other reviewers include Randy Allen, Jim Hay-den, and Karl Wiegers. Writing a book is clearly a team effort!Our President of Northrop Grumman Information Technology DefenseEnterprise Solutions, Kent R. Schneider, and my manager, Alan Pflugrad,have gifts for creating and maintaining a TEAMWORKS environment (readabout this in Chapter 8!). It is very fulfilling and energizing to be a memberof several high-performance teams through Northrop Grumman. I amthankful to Kent and Al for their leadership, support, and guidance.I continue to be aware from my faith journey that prayer works. Thanksto treasured friends Art Banks, Tom Foss, Craig Hollenbach, and JoeMatney.Thanks to family for their support, too—Kimberly and Mike Wallace,Ann and Jeff Young, Matt Young, and Jan and Don Hoffer.xxAcknowledgments The Importance of RequirementsTficult. It’s not just a simple matter of writing down what the cus-tomer says he wants. A fundamental problem in business is thatrequirements are inherently dynamic; they will change overtime as our understanding of the problem we are trying to solvechanges.Theimportanceofgoodrequirementsandtheunderly-ingdynamicnatureoftheprocessmeanthatwemustbeasaccu-rate as possible, and yet be flexible. Flexible does not mean“weak,”butratherthanwehaveaprocessfordevelopingrequire-ments and accommodating changed requirements as we clarifythe real requirements of customers. Ineffective requirementspractices are an industrywide problem. This is an area in whichyou can have a major positive impact. A more disciplinedapproach to requirements development and management isneeded in order to improve project success rates. An alarming53% of industry’s investment in technical development projectsis a casualty of cost overruns and failed projects.This chapter defines the term “requirement,” explains whyrequirements are important, and advocates planning to definethe requirements strategy and activities. It suggests use ofa defined and documented requirements process, that investingmore in the requirements process will have a large payback,and that requirements serve a crucial role in business in manag-ing risk. It recommends that you consider certain factors inmaking your career decisions. It suggests that much of theadvice provided in the book is applicable to projects of all sizes.hepurposeofthisbookistohelpyouimprovethepracticeofrequirementsengineering.Requirementsengineeringisdif-What Are Requirements and Why AreThey Important?A requirement is a necessary attribute in a system, a statementthat identifies a capability, characteristic, or quality factor of a11ContentsWhat are Requirements andWhy Are They Important?Why Plan?A Suggested StrategyRequirements Activities in theSystem Life CycleInvestment in theRequirements ProcessA Process ApproachThe Requirements PlanFactors Affecting Your CareerDecisionsA Comment Concerning SmallProjectsSummaryCase StudyReferencesCHAPTER system in order for it to have value and utility to a customer or user. Require-ments are important because they provide the basis for all of the develop-ment work that follows. Once the requirements are set, developers initiatethe other technical work: system design, development, testing, implementa-tion, and operation.Too often, there is a tendency to want to start what is often referred to as“the real work” (developing, or programming, the software) too quickly.Many customers and project managers (PMs) seem to believe that actualprogramming work (“coding”) indicates that progress is being made.According to industry experience, insufficient time and effort are spent onthe requirements-related activities associated with system development.Industry experience confirms that a better approach is to invest more timein requirements gathering, analysis, and management activities. The reasonis that, typically, coding work is started much sooner than it should bebecause additional time is needed to identify the “real” requirements and toplan for requirements-related activities (described below).There is a significant difference between “stated” requirements and “real”requirements. Stated requirements are those provided by a customer atthe beginning of a system or software development effort, for example,in a request for information, proposal, or quote or in a statement ofwork (SOW). Real requirements are those that reflect the verified needsof users for a particular system or capability. There is often a huge differ-ence between the stated requirements and the real requirements. Analy-sis of the stated requirements is required to determine and refine realcustomer and user needs and expectations of the delivered system. Therequirements need to be filtered by a process of clarification of their mean-ing and identification of other aspects that need to be considered. To cite asimple example, requirements analysts (RAs) are more familiar with the needto state requirements clearly (see the criteria for a good requirement pro-vided below). There are many ways in which the capability, understanding,and communication of the meaning of each and every requirement may bedifferent to a user than to a developer. Therefore, it is vital (and time saving)that all requirements be clarified through the mechanism of a joint cus-tomer/user and RA effort. Customers and users need the support of techni-cally trained and experienced professionals, and vice versa, to ensureeffective communication. Developers need to have that same understandingso that the solution they define addresses the needs in the way everyoneexpects. Misunderstandings of requirements result in wasted effort andrework. Another important insight is that sometimes the requirements areunknowable at the outset of a development effort because they are affectedby the new capabilities to be provided in the new system. This suggests theneed to plan for new and changed requirements—to provide a degree offlexibility.Identifying the real requirements requires an interactive and iterative re-quirements process, supported by effective practices, processes, mecha-nisms, methods, techniques, and tools. This book provides a description ofhow the RA can use these in performing the needed work. In a previous2The Importance of Requirements book, Effective Requirements Practices [1], I describe what should be done andprovide an extensive set of references to many of the best publications in theindustry literature. This book is intended to provide a concise handbook thatserves as a desk reference guide for the RA or engineer and requirementsmanager in engineering and computing. It also provides updated references.The requirements process need not be complicated or expensive. How-ever, a requirements process is required for a project of any size. It’s mostimportant that a project or organization have a defined and documentedrequirements process. The nature of the specific components of the definedprocess can be improved based on experience.Why Plan?It’s well known and understood by most people that a bit of planning goes along way. For example, before leaving on an automobile trip, checking amap to locate the destination and, perhaps, even planning a route may betime well spent. Yet, we frequently charge ahead with the doing with littleor no planning, don’t we? It’s human nature to want to get on with theneeded work without doing much planning.Systems development and software development managers and practi-tioners are familiar with several types of plans: project plan, systemsengineering management plan (SEMP), quality assurance (QA) plan, con-figuration management (CM) plan, software development plan (SDP), testplan, and so on. However, the concept of a requirements plan may be new toyou. Leveraging requirements-related activities has great power and effect.Writing a requirements plan maximizes value. A requirements plan defineshow the real requirements will evolve and how the requirements activitieswill be addressed.Writing a requirements plan (RP) facilitates an understanding of theactivities and efforts that need to be undertaken to implement an effectiverequirements process for a particular development effort. Additional detailsconcerning the requirements plan are provided below.A Suggested StrategyI suggest a strategy that includes (1) writing a requirements plan, (2) design-ing or tailoring a requirements process for your project, (3) investing in therequirements-related activities in the system life cycle, and (4) utilizing theeffective requirements practices, mechanisms, methods, techniques, tools,and training that are described in this book.Requirements Activities in the System Life CycleManagers often think of requirements-related activities as consistingprimarily of gathering requirements and managing changes to thoseWhy Plan?3 requirements throughout the life cycle. In reality, there are several otherrequirements-related activities that need to be addressed in the system lifecycle:◗ Identifying the stakeholders: This includes anyone who has an interest inthe system or in its possessing qualities that meet particular needs.◗ Gaining an understanding of the customers’ and users’ needs for the plannedsystem and their expectations of it: This is often referred to as requirementselicitation. Note that the requirements can include several types. Typesof requirements are discussed in Chapter 4. Requirements gatheringtechniques are discussed in Chapter 5.◗ Identifying requirements: This involves stating requirements in simplesentences and providing them as a set. Business needs or requirementsare the essential activities of an enterprise. They are derived from busi-ness goals (the objectives of the enterprise). Business scenarios may beused as a technique for understanding business requirements. A keyfactor in the success of a system is the extent to which i...

    关注我们

  • 新浪微博
  • 关注微信公众号

  • 打印亚博足球app下载
  • 复制文本
  • 下载计算机书籍 计算机书籍 Artech.House.The.Requirements.Engineering.Handbook.XDF
  • 您选择了以下内容