For a listing of recent titles in the Artech House Technol Professional Development Library, turn to the back o

Ralph R. Young

Artech House

Boston London www.artechhouse.com

Norwood, MA 02062

The following are registered in the U.S. Patent and Trademark Office by Carnegie

.

Maturity Model, CMM, and CMMI

All rights reserved. Printed and bound in the United States of America. No part of or utilized in any form or by any means, electronic or mechanical, including phot information storage and retrieval system, without permission in writing from the All terms mentioned in this book that are known to be trademarks or service m capitalized. Artech House cannot attest to the accuracy of this information. Use of

be regarded as affecting the validity of any trademark or service mark.

International Standard Book Number: 1-58053-266-7

A Library of Congress Catalog Card number is available from the Library of Congr

10 9 8 7 6 5 4 3 2 1

Preface. . . . . . . . .

Acknowledgments . . . . . .

The Importance of Requirements .

What Are Requirements and Why Are They Im

Why Plan?

A Suggested Strategy

Requirements Activities in the System Life Cycl Investment in the Requirements Process

A Process Approach

The Requirements Plan

Factors Affecting Your Career Decisions

A Comment Concerning Small Projects

Summary

Case Study

References

The Roles of the RA . . . . .

Suggested Roles of the RA

Summary

Case Study

References

Stated Requirements Versus Real Requirements

User Requirements

High-Level or System-Level Requirements Business Rules

Functional Requirements

Nonfunctional Requirements

Derived Requirements

Design Requirements and Design Constraints

Performance Requirements

Interface Requirements

Verified Requirements

Validated Requirements

Qualification Requirements

The Ilities and Specialty Engineering Requirements

Unknowable Requirements

Product Requirements

Process Requirements

Logistics Support Requirements

Environmental Requirements

System, Subsystem, and Component Requirements

Terminologies to Avoid

Source or Customer Requirements

Nonnegotiable Versus Negotiable Requirements

Key Requirements

Originating Requirements

Other Guidelines

Examples of Requirements Types

Summary

Case Study

References

The RAs Specialty Skills . . . .

Summary

Case Study

References

An Integrated Quality Approach .

Business Drivers for Quality Managements Role Guiding Principles

Priority Management

The Components of an Integrated Quality Appr

Quality Improvement Techniques

The PDCA Cycle

How to Design a Process Teamwork

Summary

Case Study: An Example of Quality Improveme

References

A Vision for Requirements Engineer

How Should We Support PMs?

How Should We Support Customers?

How Should We Support Developers?

Summary

Case Study

References

Bibliography. . . . . . .

About the Author . . . . . .

Index . . . . . . . . . .

computers. Development disciplines included s electronics, communications electronics, and m Customer acquisition and user groups knew they wanted, but there had yet been no technica project, the company developed and delivere Customer reviewers provided dozens of chang

requirements that they interpreted from the statements. In later discussion, however, custom additional requirements, although nice to have,

Time passed. The project had political and f up and down over a period of four years like a Personnel changed several times; in one such ch terminated and the entire acquisition group months of hiatus, a new acquisition group resu

The technical specification went through se how, the record of those six requirements re agreement, however, was repeatedly lost. They by customer reviewers. After each revision, th again deemed too expensive to add. But the sp approved to reflect the agreement. In the thro quent upheavals, the developers focused on com duction. The specification faded onto a dusty s

Things on a dusty shelf have a way of comi requirements came to light one last time. Durin customer monitors blew the dust off the specif verification.

The result of six missing requirements was a t Ralph Youngs book provides the tools that c have. Building on Effective Requirements Practices experience, Ralph offers a set of tools and te for modern requirements analysis, written in

dently, you tell the waiter the entree. The waiter s perennial sequence of questions about side items. New potatoes or French fries? Green beans options were clearly written on the menu, but som Requirements are also a form of human comm convey complex ideas from one mind to another sparse form of communications, using bare writte sion. Like menu descriptions, requirements alwa impossible to write any requirement, no matter h

misconstrued honestly by some recipient.

Even the word requirement is itself a misco ual requirements are frequently flexible rather th promises a significant benefit to a key performanc gladly change lesser requirements to accommo And yet requirements are still the best metho complexity of a technical idea. To handle this co ments to perform three important roles, all of w

tools and techniques in this book.

First, requirements are a contractual tool. Th understood purpose. In this role, a specification d of a development contract. The legal impact of t One recent lawsuit between a prime contractor a on the grammar of a single requirements stateme lion dollar settlement. For the protection of bot contractual requirements must be as clear as the

Second, requirements are a configuration ma form and relationship of the requirements stateme figuration of the system. They embody the valid bounds. By controlling the requirements, we cont nition. We see the importance of configuration d software tool fails to operate with our open syst

Third, requirements are an engineering tool. quently not understood, being overshadowed

Verify completion of the product.

The problem of those six requirements h torsthe political changes to the program, the customer factions, the unusual pressures of s and the development teams focus on completi pened, however, because of the lack of the requi methods that this book contains. A modern RM would have cost a fraction of the three million enced. Even better, many other expenses woul

Like the children around the campfire, infor nications. As a campfire game, we laugh at the p complex system products, though, we are no l

Former President, International C

It is a desk guide/handbook that focuses on how work.

The requirements are key to the success or They are the basis of all of the follow-on work. I most projects and organizations fail to use effe and a documented requirements process, and RAs are cast into the needed work without pro and training, and without a good handbook th perform their roles and what to do.

RAs are in a strategic position to influence t systems or software engineering task or project

The requirements are vital to the initiatio of the needed work.

They are of great importance in achieving and users.

Trained, experienced RAs are valued advi or task manager and invaluable resource team.

This book addresses all of the areas that you your work. Key topics include the following:

Topic

The importance of requirements.

Leveraging requirements-related activitie

Identifying the real requirements.

In collaboration with the task or project lead tices, and then implement them effectively

Develop a personal professional developme skills and capabilities.

Learn and apply needed requirements anal

Define and use an integrated quality appro

Evolve your own personal vision for requir

Address requirements risks.

Chapter 2 describes nine roles of the RA and i tem life cycle each should be applied. Requireme knowledge and skillsperhaps more than most identifies and describes skills that you may need t ence in this book where you can learn more abo

Its important for the RA and others assigned understand the different types of requirements. Th in Chapter 4 and are broken down as follows:

Business requirements;

User requirements;

Product requirements;

Environmental requirements;

Unknowable requirements.

Customer needs and expectations are analyze lowing ways:

High-level (or system-level) requirements;

Functional requirements (what the system

Checks are done to ensure the system does incorporating the following:

Verified requirements;

Validated requirements;

Qualification requirements.

The following are evident from this descriptio

A common, shared understanding is nee

Requirements-related training should be with somewhat different needs, so that a experience and become aware of the met that work best: (1) RAs, (2) the member and (3) the customers and users.

These topics are addressed in Chapter 5. The requirements gathering activities are

become ineffective, as you likely are already a See Table 5.1 for a checklist that will help you Chapter 5 provides a discussion of each a important and how to get it done. References information, should you want it. The intent of make a valued contribution and also to be fulfilled i

We hear and read a lot about best practice too infrequently deployed, implemented, and in ects, for a variety of reasons, but most importa Chapter 6 provides information concerning best my own and industry experience. Obviously, least not at one time. The information in Chapt ate discussions with your task or project team an

improve the practice of requirements engineering! cal ideas, suggestions, approaches, and recommen well as a handbook in your daily work. But, only you are determined to work to make things bett need to be committed to making changes that im systems and software. Too often we dont pract know what we should do, but we dont do it. Th commitment and that of your peers and manage make improvements. Use this book to guide you in yo will be able to create and implement your own plan based on the characteristics and traits you ch and improve. I encourage you to work in conce evolve a plan of action to enable you to understa roles and, through experience and study, develo impact project success rates significantly and posi

Chapter 10 provides a summary of the book a forward. The subtitle, Knowable Requirements, that we really can do a commendable job when apply the guidelines provided in this book. By doi the computing and engineering professions to im Lets acknowledge that we have a long way to able concerning how to make improvements (i processes, methods, techniques, and tools, for exa fession to improve, practitioners need to take actions in ferent from what we are doing today. Only through incremental actions will the profession advance t

of requirements engineering. Are you ready?

Please share any of your own reactions to thi and constructive criticisms with me at ryoungrr@a hard at work on another project, and your feedb tributions I may make.

Good luck, and remember to have fun while

ingfor me, its as Maryanne Radmacher-Hers

Writing is the process one follows to learn wh within: it sharpens the spirit, disciplines the mind the spaces between words and solitude observe and silence meet. Words matter. Pay attention. know.

As for those who have supported me, how c edge reviewers and contributors who have given to make this a better book? Suffice it to say tha close friends and valued advisors.

Speaking of advisors, there is one whose Artech House Publishers engaged an advisor to person, obviously an expert in requirements e anonymous and provided constructive and h chapter.

Speaking of requirements-engineering exp ously provided thoughtful comments and i responding in almost real time to questions, review comments. Randall Iliff, engineering and tor, also provided great insights in several area Capers Jones, John Moore, Rich Raphael, an thoughtful and useful ideas and wording.

Requirements analysts who are members Information Technology Defense Enterprise Sol ing Group provided valued review comments, c experiences and expertiseTerry Bartholom Ebenhoeh, Bob Ellinger, Jim Faust, Graham M

ent. Thanks to all of you, particularly Pat Little. Other friends and associates who lent a hand

Boehm, Grady Booch, Dennis Buede, Pete Carrol diener, Eric Honour, Alice Hill-Murray, Craig Ho Huber, Charles Markert, Andy Meadow, Larry Penny Waugh, and Beth Werner.

Reviewers, including many of those prev strengthened my writings. Other reviewers inclu den, and Karl Wiegers. Writing a book is clearly Our President of Northrop Grumman Inform Enterprise Solutions, Kent R. Schneider, and my have gifts for creating and maintaining a TEAMW about this in Chapter 8!). It is very fulfilling and e of several high-performance teams through N thankful to Kent and Al for their leadership, sup I continue to be aware from my faith journey to treasured friends Art Banks, Tom Foss, Cr

Matney.

Thanks to family for their support, tooKim Ann and Jeff Young, Matt Young, and Jan and D

A Suggested Strategy

Requirements Activities in the

System Life Cycle

Investment in theRequirements Process

A Process Approach

The Requirements Plan

Factors Affecting Your Career

Decisions

A Comment Concerning Small

Projects

Summary

Case Study

References

tomer says he wants. A fundament requirements are inherently dyna time as our understanding of the pr changes. The importance of good re ing dynamic nature of the process m rate as possible, and yet be flexib weak, but rather than we have a p ments and accommodating change the real requirements of custome practices are an industrywide probl you can have a major positive i approach to requirements develo needed in order to improve projec 53% of industrys investment in tec is a casualty of cost overruns and f

This chapter defines the term requirements are important, and a the requirements strategy and a a defined and documented require more in the requirements process and that requirements serve a cruci ing risk. It recommends that you making your career decisions. It advice provided in the book is appli

What Are RequiremenThey Important?

A requirement is a necessary attrib that identifies a capability, charact

is that, typically, coding work is started much because additional time is needed to identify the plan for requirements-related activities (described There is a significant difference between state requirements. Stated requirements are those pr the beginning of a system or software develop in a request for information, proposal, or quo work (SOW). Real requirements are those that of users for a particular system or capability. Th ence between the stated requirements and the r sis of the stated requirements is required to d customer and user needs and expectations of t requirements need to be filtered by a process of c ing and identification of other aspects that need t simple example, requirements analysts (RAs) are m to state requirements clearly (see the criteria for vided below). There are many ways in which the and communication of the meaning of each and e different to a user than to a developer. Therefore, i that all requirements be clarified through the m tomer/user and RA effort. Customers and users n cally trained and experienced professionals, an effective communication. Developers need to hav so that the solution they define addresses the ne expects. Misunderstandings of requirements res rework. Another important insight is that someti unknowable at the outset of a development effort by the new capabilities to be provided in the new need to plan for new and changed requirement

flexibility.

Identifying the real requirements requires an quirements process, supported by effective pra nisms, methods, techniques, and tools. This book how the RA can use these in performing the ne

Its well known and understood by most people long way. For example, before leaving on an map to locate the destination and, perhaps, ev time well spent. Yet, we frequently charge ahe or no planning, dont we? Its human nature needed work without doing much planning.

Systems development and software develop tioners are familiar with several types of pl engineering management plan (SEMP), quality figuration management (CM) plan, software de plan, and so on. However, the concept of a requ you. Leveraging requirements-related activities Writing a requirements plan maximizes value. how the real requirements will evolve and how will be addressed.

Writing a requirements plan (RP) facilitate activities and efforts that need to be undertake requirements process for a particular developm concerning the requirements plan are provided

A Suggested Strategy

I suggest a strategy that includes (1) writing a re ing or tailoring a requirements process for your requirements-related activities in the system lif effective requirements practices, mechanisms, and training that are described in this book.

Requirements Activities in the System

Managers often think of requirements-relat primarily of gathering requirements and m

sentences and providing them as a set. Busin are the essential activities of an enterprise. T ness goals (the objectives of the enterprise). used as a technique for understanding busi factor in the success of a system is the exten business requirements and facilitates an them.

Clarifying and restating the requirements: This i describe the customers real needs and are in stood and used by developers of the system

Analyzing the requirements: This is done to defined and that they conform to the crite (provided below).

Defining the requirements in a way that means the holders: Note that each stakeholder group m ferent perspective of the system and th Sometimes this requires investing significa vocabulary or project lexicon. Often it requi time and effort to achieve a common unde

Specifying the requirements: This requires inclu of each requirement so that it can be includ ment or other documentation, depending o

Prioritizing the requirements: All requirement tance to the customers and users of the plann cal, some of relatively high priority, some of and some even of lower priority. It is imp the requirements because there is never en everything wed like to do in our developed requirements provides the opportunity to a first and possibly release a version of a pr

tems and components of the system. The a satisfied by just one subsystem or compo

Tracking requirements: We need the capabil the system each requirement is satisfied, s requirement is being addressed. This is through use of an automated requiremen

Managing requirements: We need to be abl requirements during all of the phases of s integration, testing, deployment, and o repository consists of a set of artifacts and Chapter 5.

Testing and verifying requirements: This is the ments, designs, code, test plans, and system requirements are met.

Validating requirements: This is the process requirements are implemented in the del validation of requirements should be pri ited amount of funding available.

Investment in the Requirements Proce

The industry average investment in the requir system is 2% to 3% of total project cost. It s

1. See A. M. Davis, The Art of Requirements Triage, Computer (March 2003) requirements triage. Davis defines requirements triage as the process of product should satisfy given the time and resources available. He provides e that help prioritize requirements. Three product development case stud provided.

A Process Approach

Over the past two decades, there has been cons value of a process approach. By a process app and using a documented descriptiona process fl nying process description (PD)of a set of act accomplishment of a task or achievement of an experience, there is great value to using a proces

Those who support the activity documen involved in getting something done.

Once documented, there is a common (shar is involved.

The documented process can be understood b

Those involved, having a common un improvements to the process (enabling co empowering those who are involved to co the process better).

Several general process models have been de

Capability Maturity Model (CMM ) [3] developed ing Institute (SEI) at Carnegie Mellon University in industry standard framework for assessing the mat opment process. The current version of this mod

Maturity Model Integration (CMMI ) [4]. Its suc capability to discern whether software is being d One can tell whether the development effort is be Some PMs may question the value of process imp diverts resources from their main responsibility needs and that process improvement costs too m maintained by the SEI reflect a 7:1 return on inve

with a development project or task. The purpose to determine and document how the real requi how the requirements-related activities in the described above) will be addressed. Following is this plan and a description of each topic:

Purpose (of the requirements plan): This w paragraph.

Contract/project summary: A high-level sum system or software should be provided. T from other documents such as a vision and been written previously to describe the o

Background: This section should describe decision to develop the system or software stakeholder groupsthose who have an in the customer (the person or organization p the project or its end products), various ca and major suppliers.

Evolution of the requirements: A mechanis between the customers/users and the deve stated requirements and evolve the real re resist this effort, believing that they alr requirements. The RA should be familiar w cerning how many projects have failed and seriously and negatively affected by a fai step [1, p. 48]. A mechanism is a way to get s

2. See B. K. Clarks Effects of Process Maturity on Development Effort, University of Southern California, 1999, at www. ralphyoung.net/goodart the benefits of process improvement.

should be designated to provide requiremen this training is described in Chapter 5). Anoth ble for the automated requirements tool. Yet responsibility for the key processes to be utili ing the requirements process. Still another may ing the architecture (the underlying str software). Since the requirements and the other, a recommended requirements practic ments and the architecture repeatedlythis ments and a more robust architecture [1, p

Table 1.1 Criteria of a Good Requirement

Each Individual Requirement Should Be

Necessary: If the system can meet prioritized real needs without the requi

Feasible: The requirement is doable and can be accomplished within budg

Correct: The facts related to the requirement are accurate, and it is techni

Concise: The requirement is stated simply.

Unambiguous: The requirement can be interpreted in only one way.

Complete: All conditions under which the requirement applies are stated, idea or statement.

Consistent: It is not in conflict with other requirements.

Verifiable: Implementation of the requirement in the system can be prove

Traceable: The source of the requirement can be traced, and it can be trac (e.g., to the design, code, test, and documentation).

Allocated: The requirement is assigned to a component of the designed sy

Design independent: It does not pose a specific implementation solution.

Nonredundant: It is not a duplicate requirement.

Written using the standard construct: The requirement is stated as an impera

Assigned a unique identifier: Each requirement shall have a unique identify

Devoid of escape clauses: Language should not include such phrases as if, unless, and although. Language should not be speculative or gener as usually, generally, often, normally, and typically).

of each category will be described throu some are more appropriate in some cases particularly useful in specific situations. methods, techniques, and tools should mented, and the project team should be fa and the rationale for their selection.

Integration of proven effective requirements pra that use of a set of proven effective requir huge difference on a project [1]. For exam time and effort to define the real customer ommended. Recommended best requ described throughout this book and are Select and document a set of requirements project well.

References: There will be a set of document the requirements process. Examples inclu system goals and objectives, lists of requ standards that the customer has specified applicable, and so forth. These references s tion where each can be accessed should

Recommended strategy: Based on analysis strategy should be developed and set f requirements-related aspects of the proje might include the following:

The partnering strategy;3

3. The term partnering is often used to suggest a close, coordinated, effectiv to a defined process of partnership effort in a project. I encourage you to fa and to consider use of the partnering process. You may find (as I have) that i success.

requirements process for your environm

Mechanisms to be utilized (e.g., the join recommended in this book);

Training concerning requirements for th the customer);

Selection of an appropriate automated req will be used;

Definition of the target architecture;

Plans to deal with new and changed re mechanism to control them, as well a builds);

Understanding of risks inherent to the r that lack of full understanding of some re project risks;

Definition of guidelines for system devel ments considerations.

Appendixes: These might include the followi

Requirements process (flowcharts and P

Partnering process approach [6];

Draft project requirements policy;

Action plans and timelines for needed e requirements tool).

Factors Affecting Your Career Decisions

I recommend that you meet with your PM very e your assignment to the project is finalized. Discuss tives concerning requirements. After digesting th

Is he or she concerned about personal an

Is he or she willing to delegate responsib

The point is that you are about to commit a life to a project. Take the time and effort to sat will be well spent. You should perceive that a n with learning experiences, opportunities to mak butions, to work with peers whom you respec and fulfillment, and to have fun at work.

A Comment Concerning Small Projects

Many people feel that the approach that is used ects is an inappropriate guide for small projects mechanisms, methods, techniques, and tools c ence is that professional judgment can be used t practices to achieve good results on small proje small projects, tasks, or teams to benefit from w experiences of larger projects by tailoring the smallness as an excuse for not taking advantage for additional insights.

Summary

This chapter has focused on the importance of an introduction to the critical role of the RA (th detailed in the next chapter, and the skills and c RA are described in Chapter 3). It should be presented already that there is great power requirements-related activities in engineering a 53% of industrys investment in technical devel

Case Study

This first case study reports on a workshop involv among a group of PMs concerning the top reaso and software projects had difficulties, based on t the top reasons that were reported by a set of PM

1. The requirements for the project are not

2. Requirements changes are made/accepte concomitant cost, schedule, and quality i

3. A requirements process is not used.

4. There is no mechanism (such as a joint tea the definition of the requirements and to through the project life cycle.

5. The real customer needs are not define

6. There is no mechanism to maintain com parties involved in the project.

7. Known, familiar, proven methods, tech utilized.

8. The customer is not involved as a partner cycle.

I recommend that you keep these reasons in book. Ascertain what you might be able to do o help overcome these problems.

4. The Standish Group, The CHAOS Report (Dennis, MA: The Standish Group In secure.standishgroup.com/reports/reports.php?rid=1.

Bar Association Publishing, 1999.

[7] See Paulk, M. C., Using the Software CMM

Software Quality Professional 1(3) (June 1999): publications/articles/paulk/judgment.html.

improve the practices in use on pReferencestion. The analyst can have a positi and also facilitate the organizatio performing in several roles. Makin tributes to a smoother process. T readily to business goals, such as i tion with the delivered work pro market of products; meeting cost, tives; and utilizing the human reso effectively. The RAs role needs to b the minds of PMs and the technic puting and engineering). Table 2 the RA, noting the life-cycle ph performed.

Suggested Roles of th

1. Work collaboratively with custome and designers to identify the real re or software development effort to de solved.

The concept of the real requir Chapter 1. Experience has shown lem in requirements engineering i real requirements prior to initi activities. Anyone who has had so systems or software will agree that ments is a significant problem. Wit needs to create an awareness of the

Table2.1 RARolesandLife-CycleActivities

SystemImplementatioAXXXXX

SystemComponentDesignAXXXXXX

SystemAnalysisand DesignXXXXXXX

SystemInitiattionXXXXBX

RA Role1. Work collaboratively with customers, users,andsystemarchitectsanddesignerstoidentifytherealrequirementsforaplannedsystemorsoftwaredevelopmentefforttodefinetheproblemthatneeds tobesolved.2. Work effectively with customers and usersto managenewandchangedrequirementssothattheprojectstaysundercontrol.Installamechanismtocontrolchanges.3. Be alert to new technologies that may help.4. Facilitate the project in reusing artifactsandachievingrepeatability.5. Assist the project and its customers in envisioningagrowthpathfromthefirstreleaseorversionofaproductthroughasetofstagedreleasestotheultimatesystemorproducts.6. Advise the project (and customer) of methods,techniques,andautomatedtoolsthatareavailabletobestsupportrequirements-relatedprojectworkandactivities.7. Use metrics to measure, track, and controlrequirements-relatedprojectworkactivitiesandresults.8. Be able to facilitate discussions and to mediate

Identifying the stated needs of custome reviewing things previously written about viewing customers and users, studying forth.

Studying the business objectives for the p

Collaborating with customers and users in ronment to analyze the stated requirem ments, and prioritize them (see the suggest

Involving system architects in requirement draft or proposed requirements will resul with better requirements and a more robu systems need to be able to accommodate c architecture should be designed and devel delivered system soon will be outdated.

Utilizing an industry-strength automated port this work.

The RA should work within the project orga of the PM in gaining commitment to investin evolve the real requirements. Here is a great op responsibility and, drawing upon industry ex management and developers to invest more tim ments process. Fortunately, data is available rather than by intuition or the way we have a

Effective Requirements Practices [1, p. 62] for thes Consider using collaborative requirements work well in group sessions. Examples of go techniques are requirements workshops, elec electronic collaborative development tools, hig high-level IDEF0 diagrams (especially for bus level use case diagrams (especially to disting

are identified after system development (progra requirements and changes to existing requirem between critical requirements (those that would schedule, or the development effort if changed) ments, such as a derived requirement that furthe built, but serves to clarify a higher-level require cost, schedule, or functionality. All stakeholders impact requirement that further clarifies the sys

Again, we have data from industry experie a 20% change in requirements will result in development costs [4]. Therefore, its critical tha place to evaluate and adjudicate changes to requir tive mechanism to control changes to requiremen out of control in terms of schedule and cost. Sev

The importance of controlling changes t explained to customers, users, and develop commitment to project success is maintain

Developers must be trained not to accept u changes. All requests for changes, no matter neled through the change control mechani

The change control mechanism should be empowered decision makers representing th oper. The joint team should meet frequently able number of change requests to conside requirements volatility is recommended to g joint team once a baseline of validated req lished.1 Whoa, you say, thats not muc

1. Chapter 10 of Effective Requirements Practices provides several ideas, suggesti controlling requirements changes.

the contract.

3. Be alert to new technologies that may help.

A role that is often underutilized is advising evolving technology. While this is not solel requirements analysts or engineers, many invo for customers would be well advised to spend learning about new technologies and how they Customers are typically focused on what the s serve them best by being familiar with evolvin how the needed system is designed. This suggest having system designers review their work p requirements elaboration, involve a small team real requirements for cost, schedule, technology studiesthe Decision Analysis Resolution (DA nologyto evolve alternatives. Keep the custo ties, so that when opportunities arise, the custo you in making recommendations for decisions. describes the process of utilizing new technologi fusion of Innovations (4th ed.) [5].

4. Facilitate the projects reuse of artifacts and achi

There has been a lot of discussion in the indu Reuse has two meanings: (1) to take object X (e COTS software) that was done by Y and use it and (2) to tailor2 a developed work product process, for example). Many organizations have only to conclude that they are not viable or p

2. By tailoring, we mean modifying, extracting pieces from, elaborating, or another use. Reuse of tailored artifacts saves time and money and is a approach.

reference or contact. An example work product y is a requirements plan. As emphasized in Chapt ment of a requirements plan for any system or sof This idea may be new to you, and it would be very review one developed previously in order to con your work. Another example from my experien processes. If the organization or another project for doing something, why not tailor it as needed than create ones own process? Others who have practice have incorporated their experience an learned using it. Related to this is the value of p peer review of every work product. (The extent number of people requested to review the wo invested to perform the peer review and report on tionsis a function of the importance of the work the peer review process and checklists of another a jump-start in getting the process designed, ac mented, and institutionalized.

An Example of Process Reuse

In teaching requirements courses and tutorials, learn how many of the participants are using a d process on their project or in their organization. T be 15% to 20% of the participants. A sample req vided in Effective Requirements Practices [1, pp. 11 been tailored, deployed, and implemented on m integration with the system architecture process book [1, pp. 136146].

Suggestion: Tailor this sample requirements pr organization. Involve the stakeholders to make th their needs. Provide both flowcharts and narrativ tive Requirements Practices. Periodically update the continuous improvement ideas and suggestions.

upon process for managing changes and determ projects. No matter how much discussion and some missing requirements that wont be disco production.

6. Advise the project (and customer) of methods, te that are available to best support requirements-re

This is an important role. Experience has sho niques vary in their applicability and effectivene tools purchased by projects and organizations ar ized. Chapter 11 of Effective Requirements Pract experience and provides several recommenda

Requirements Practices [1] recommends that the m are used by a project be familiar to the project their respective industry. Its not advisable to unproven, unfamiliar methods and techniques challenging enough without introducing the techniques that are not familiar and havent be vious projects in the organization. At the project with the tools, processes, and techniques with w iar. At the organizational level, the project s processes, and techniques that are known and When contractors are brought into an existing the tools that the customer already has in place effectively). If the last five projects were done satisfied with the usefulness of the tool, then good reasons to use it. Note that a resource issu an RA would be a leveraged resource, moving taking her experience with her. However, often built (or already exists) and someone from the knowledge is tasked with being the RA. Whil and tools exist, they may be unfamiliar to this and sometimes painful learning curve, with sign

7. Use metrics to measure, track, and control require tivities and results.

The industry literature concerning metrics is vast. 20% of it provides helpful counsel. Its easy to g forming measurement activities for their own s evaluate project work and take corrective actions. useful metrics. I have developed the following ax years:

The things that are measured and tracked and that

tion to are the ones that improve.

This suggests that its not sufficient to have a must be tracked, and they must be used by man decisions.

There is a set of measures or metrics that shou See Effective Requirements Practices [1, pp. 255261 There is another level of sophistication that s projects and organizations. As used here, matu have been defined, documented, implemented, u continuously improved over a period of at leas involves quantitative management (QM) of cos process metrics and baselines in support of specifi fulfilling to see projects and organizations move fr QM is not well understood to one in which QM is business objectives. This is especially satisfying to executives can see first hand the value of process

business needs.

8. Be able to facilitate discussions and to mediate con

This role stresses the people skills of the RA. We qualified technically is important, but that its also

Be able to grasp, abstract, and express ideas quic the RA does not understand the user domain al he risks limiting his role to that of an order t groups come and go whose specialty was comm ing, and so forth. Populating those groups wa trained facilitators, but who were not technic from project to project so frequently that the domain understanding. For example, what if, tions project, the only way an RA can explain a giving analogies with building military aircraft? ness and credibility.

Summary

The RA performs several important roles on a tion. Nine important roles were identified and d first two are paramount and essential to project these, become proficient in them, and assist you adopting, implementing, and institutionalizing tions should consider taking specific steps to dev such as (1) ensuring that experienced RAs are providing appropriate training for RAs; (3) as mentor new employees, junior RAs, and intern izational requirements working group to sha resource to the organization. The RA should be strong performer. Unfortunately, Ive seen m employee or the summer intern is dispatched t role of the RA needs to be understood and valu the technical community. At this point, you m your responsibilities, as Figure 2.1 suggests. Be experience, you will provide a very positive co you support!

Figure 2.1 The challenges of the RA.

Case Study

This is the story of a project that failed because nei contractor knew how to handle requirements. Although the people involved were profession tioned, things went horribly wrong because effect were not applied.

The project approach was one that is used w and can be characterized as get started program what they want as we proceed. The customer handed the contractor a shelf-load of rules and r These are the requirements. The programmers, contractor, were ready to start, and they did. Repr organization were aware of the project, but the until it was time to review the finished code.

While the code was being written, the contra the regs to a set of shall statements. This was fa done, but as the code emerged, it was found that t statementsmatching them to parts of the diffe virtually impossible. They simply did not map.

Another complication encountered was a com munication between the contractor and the sub code. It wasnt that they did not understand each communicate. The subcontractor viewed any inq in an atmosphere of hostility, communication sim

As the code came into review by the custome tives were heard to say again and again, No, tha

There was no partnership between the subcontractor.

There was no communication.

There was not an atmosphere of mutual

There was no workable requirements pla

There was no mechanism for joint resolu

The project was begun anew, on a different guage, by a different mix of subcontractors. A ments practices was used, which included the f

Mechanisms (similar to the joint team facilitate partnering, identifying real need oritization of requirements;

An approach that involved the users in t vided for collaboration with them, and gai the project approach;

Use of methods including use cases that fa effective communication of user needs a

Incorporating appropriate and updated te the customer and the users.

References

[1] Young, R. R., Effective Requirements Practices, Bost

[2] Leffingwell, D., and D. Widrig, Managing So Approach, Reading, MA: Addison-Wesley, 2000

[3] Hay, D. C., Requirements Analysis: From Business V

River, NJ: Prentice Hall, 2003.

Inc., 1995.

Summary

Case Study

References

an effective RA. As emphasized in t fulfills several critical project roles. a part-time individual who is othe uct manager, system engineer, d capacity. On other projects, there even several RAs and a requireme project and the perceived co requirements-related activities, as able, are the major determinants their needed skill levels. The roles among those available to do the ne current skills, interests, and desired ever the situation, RAs should resources, able to contribute to described in the previous chapter. blend of skills that reflects knowle tion, as well as the ability to inter users, and managements intent. S sic in the way an individual wor interpersonal skills) and others a skills).

Skills of the RA

As a framework for this chapter, r Matrix.1 A list of RA skills is provi shown:

1. With thanks to senior RA Michael Dav providing this artifact. The responsibility version is mine.

requirements (books, articles,Bibliography

standards)

8Requirements attributesCh. 5K

9Requirements baselineCh. 6K

10Training in systems engineeringCh. 5K

(e.g., life cycles, risk management)

11RequirementsCh. 5K

justification/rationale

12Requirements management toolsCh. 5K

(e.g., DOORS, RequisitePro)

13Requirements peerCh. 5K

review/inspection/walk-through

14Requirements syntaxWBR, Ch. 7K

15Requirements traceabilityCh. 5K

16Requirements verification andCh. 5K

validation (V&V)

17System/subsystem/software-levelCh. 5K

requirements

18Developing and using metrics forCh. 2K

requirements activities/processes

19Technical writing of requirementsCh. 4K

deliverables (RTM, SRS, IRS)

20 Development, implementation, and Ch. 5 use of requirements processes

21Familiarity with Microsoft ProjectTutorial

22QA of requirementsCh. 9

23Requirements allocation (toCh. 4

components, applications,

packages)

24Requirements change control andCh. 6

change notification

25Requirements repositoryCh. 5

26Requirements errors (missing,Ch. 6

incorrect, infeasible, out of scope)

27Requirements defect notificationCh. 6

28Requirements dissemination toCh. 4

customers/users/developers/testers

36Requirements prioritizationCh. 5

37Requirements review boardCh. 7

(RRB)/configuration review board

(CRB)/configuration control board

(CCB)

38RequirementsCh. 7

rough-order-of-magnitude (ROM)

costs

39Requirements specificationsCh. 7

40Evaluating requirements for risksCh. 7

41Training the requirementsCh. 5

processes

42Requirements impact estimationGilb

(IE) table

Knowledge of = K Experience with = X

References:

REH = Young, R. R., The Requirements Engineering Handbook, Norwood, MA: Artech House WBR = Alexander, I. F., and R. Stevens, Writing Better Requirements, Boston: Addison-Wesle SL = Lauesen, S. Software Requirements: Styles and Techniques, pp. 346347.

EG1 = Gottesdiener, E., Requirements by Collaboration: Workshops for Defining Needs, Rea pp. 122128.

EG2 = Gottesdiener, E., Requirements by Collaboration: Workshops for Defining Needs, Rea pp. 8994.

Gilb: See material at www.result-planning.com.

1. Entry/junior-level analyst;

2. Mid-level analyst;

3. Senior-level analyst.

A K is used in this table to suggest that kno at a particular level of analyst expertise. An X using the skill is needed at a particular level.

The types of requirements (described in de

The criteria of a good requirement (provide

Office automation tools [e.g., Microsoft (MS fect suite];

The concept of using a requirements proce

Some of the references concerning require

The purpose of requirements verification, a

She should understand that a rationale sho requirement (why the requirement is needed in A mid-level analyst (those with two to four ye have knowledge of more of the aspects and activi neering, coupled with additional experience in High on this list are requirements activities invol (such as the concept of a joint team), utilizing a r familiarity with an industry-strength requirement lyst should be proficient with peer reviews an ensure that all of her own work products are p understand the value of bidirectional traceability o learning how to develop a requirements traceabi A senior-level analyst (those with five or mor forming requirements-related activities) should and experience with using all of the skills in th familiar with all of the roles described in the pr well-developed interpersonal skills and character this chapter. She should understand the value and ent QA and have a thorough understanding of C able to recommend and use requirements metrics rics to requirements processes. She should be ab sions for more junior RAs and for other member should have a good familiarity with systems engin

that will enhance your skills with your manag

Senior-level analys

Has a good understanding of the roles

Is familiar with all roles described in C

Experienced in full life cycle activities

Well-developed interpersonal skills an

Has a through understanding of CM ac

Understands the value and importance QA;

Able to provide requirements-related t junior RAs and other project members.

Mid-level analyst

Is familiar with a requirements process and an RTM

Is familiar with automated requirements tools;

Is able to facilitate requirements definition activities developers and customers/users;

Applies peer reviews and/or inspections to require development efforts;

Understands the value of bidirectional requirement

Junior or entry-level analyst

Knows the types of requirements Knows the criteria of a good requirement

Understands how to provide rationale for a requirement

Has studied related references; Knows the purpose of requirements verification Is familiar with office automation tools

Figure 3.1 Professional growth of the RA is based o (Adapted from: Michael Davis.)

2. With thanks to Karl Wiegers for allowing me to participate in the develop

Skills Needed Interviewing skills to talk with individuals and group the right questions to surface essential requirements

Listening skills to understand what people say and to hesitant to say.

Analytical skills to evaluate critically the information sources, reconcile conflicts, decompose high-level inf abstract up from low-level information to a more gen distinguish presented user requests from the underly distinguish solution ideas from requirements.

Facilitation skills to lead requirements elicitation wo

Observational skills to validate data obtained via oth new areas for elicitation.

Writing skills to communicate information effectivel managers, and technical staff.

Organizational skills to work with the vast array of i elicitation and analysis and to cope with rapidly chan

Interpersonal skills to help negotiate priorities and to project stakeholders (such as customers, product man

Modeling skills to represent requirements informatio augment textual representations in natural language languages already established in the development or

Knowledge Needed An understanding of contemporary requirements elic specification, verification, and management practices them in practice.

Familiarity with requirements engineering tools and

An understanding of how to practice requirements e several software development life cycles in a team en

Knowledge of product management concepts and ho products are positioned and developed.

Application domain knowledge is a plus to have cred representatives and be able to work effectively with t

Responsibilities Work with the PM, product manager, or project spon products vision and scope.

Identify project stakeholders and user classes, docum characteristics, and identify appropriate representati negotiate their responsibilities.

are complete, consistent, concise, comprehensible, tra and verifiable and that they conform to standards.

Participate in requirements prioritization.

Participate in peer reviews and inspections of requirem

Participate in peer reviews of work products derived fr specifications to ensure that the requirements were in

Enter, manipulate, and report on requirements stored tool.

Define requirement attributes and facilitate their use t

Manage requirements traceability information and tra throughout the project.

Identify requirements errors and defects, and write req identification and notification reports.

Manage changes to baselined requirements through ef control processes and tools.

Establish and implement effective requirements practi continuous improvement of a requirements process.

Assist with the development of the organizations requ procedures, and tools.

Implement ways to reuse requirements across projects

Identify ways to assist product management in produc requirements development and analysis.

Propose new product features and updates.

Measures of Evaluation from product and project management on Performance effectiveness in the marketplace of the requirements a

developed.

Feedback from key customer or marketing representat requirements engineering process was conducted.

Customer satisfaction measures.

Satisfying or exceeding requirements development sch and quality goals.

Control of requirements creep attributable to missed r unofficial requirements into the project.

This job description needs to be tailored to match the experience level for the position.

Source: Karl Wiegers et al.

Characteristics of an Effective RA

In addition to learned, or hard, skills, there is a s tics that will serve the RA well. You may feel that tics are themselves really skills. I wont argue this all of the skills and characteristics noted are hel summarizes the desired characteristics described b you can apply to overcome barriers you are likel

Table 3.4 provides suggestions for how characteristics.

Consider the following characteristics, which tinue to refine, as well as the suggestions and res

1. Engage in continuing education to acq requirements engineering and requirem described the many components of the req activities that are performed throughout project. My earlier book [1] provides a c ences in the requirements literature as of references are provided in this book). F mended practices described in the earlier are provided at the end of each chapter, t mary of the information provided by the such as attending training seminars in assignment, and activities, is helpful. Jour

CrossTalk, Software Development Magazine, a mative articles and reviews of related book and study. These are both informative

[C] Management does not always understand what is being built and what resources are needed to achieve the end product.

[D] The requirements process does not support the projects needs.

[E] Strong personalities and strong opinions can derail the effectiveness of good requirements development and management.

[F] People often try to do more than is called for and to make ad hoc changes during work product development.

[G] Project personnel can become too vested in the work product solution to analyze and decompose requirements effectively.

[5] Be proactive in engaging coworkers, and project mana

[15] Desire to make a differe

[6] Develop the ability to com management.

[10] Develop the ability to es resources required to accomp

[8] Develop and maintain an improvement.

[14] Set achievable goals and describe methods to achieve t requirements plan.

[16] Develop your ability to c process.

[2] Be a good listener, comm document decisions and actio

[9] Take responsibility for yo relationships, and actions, an

[11] Maintain focus on keepi thing. Install a mechanism to and changes. Dont invent re avoid gold plating. Avoid req

[12] Develop the ability to th creative approaches that mig close to the problem and the

Source: Richard Raphael.

provide encouragement to strengthen Also, there are several Web sites that of related books (see for example Ian Al goodies (reusable requirements-relat Wiegers Web site [3]. Attending conf Institute of Electrical and Electronics ence on Requirements Engineering [4

communicate effectively with management.

7. Learn, apply and use effective practices.

8. Develop and maintain an attitude of continuous improvement.

9. Take responsibility for your views, attitudes, relationships, and actions.

10. Develop the ability to estimate work requirements.

11. Maintain focus.

12. Strengthen your ability to think outside the box.

13. Strengthen your knowledge of available technology.

14. Set achievable goals and meet them.

15. Strive to make a difference in your work situations.

manager and senior management. Write down y managements perspective. Work to understand your communications accordingly.

Select a practice that you believe will improve a support for trying it out (piloting it). Conside or organization can take to give the pilot the be Implement the practice. Follow through to ensu of implementing the practice after one month.

Practice the Plan-Do-Check-Act (PDCA) cycle at meetings. Document the suggestions that are of suggestions to the extent feasible and possible. I opportunities to inculcate an attitude of continu by documenting processes and improving them.

Make known to coworkers an error you have m contributing to doing things better. Convey that and that you have worked toward learning from recognize the value provided by all coworkers.

Estimate the time you think you will require to assigned to you. Track the actual time consume Consider changes you might make in your work productive. Over time, try to have estimates be

Embrace the concept of real requirements. Und different from stated requirements. Suggest prio your project, and evolve an approach to collabo requirements. Evaluate the impact of this appro

Meet with stakeholders to consider previously u solutions to vexing problems. Use the brainstor ideas from each participant. Multivote on the id potential value in seriously pursuing one or mo

Schedule a brown bag to consider technology p architect and other technologists. Discuss pos some system objectives by incorporating new te

Plan your work for the next month. Set a few s things that you believe are really important to a specific objectives foremost in mind over the ne specific objectives (i.e., ensure that you accomp

Explore with your manager how the tasks for w work might make a difference to the project or specific achievements, and then pursue them in coworkers and your managers support in achie

about the latest offerings available from a member and active participant in p societies such as INCOSE, IEEE, the A (ASQ), the Society for Software Quali Association of Facilitators (or associated Requirements Engineering Specialist G Often, professional organizations offer e sessions, or Saturday tutorials that pro and to meet colleagues. For example, th of INCOSE provides superb opportun glean lessons learned, and find sources other local and regional chapters [7]. A write articles and make presentations. learns more than the author, teacher, o

2. Be a good listener, communicator, and skills are important. It is important to expectations of different stakeholders. L to hear what users and customers are arent very good at expressing it. You ne standing by repeating back your interp need to be able to write clearly and co ments are documented according t requirement provided in Chapter 1. St his seminars have been valuable resou shops and materials available at his We

3. Have good facilitation and negotiation s tive requirements gathering techni workshop. See Ellen Gottesdieners Req for a thorough treatment of this import may find him- or herself facilitating gro Its important to be able to encourage while not allowing one or a few people Often, youll find yourself needing to ne

of course having the system rejected (with cial risks that result). Identifying the rea most important thing that the RA can do customers.

5. Be proactive in engaging customers and u ect management. Youll soon appreciate t go with the flow. The performance of th you be proactive. Customers and users ne sistence to help them evolve the real requ need your proactive support to help the processes, practices, methods, technique agement needs you to speak for approach project, for example, investing more in identifying the real requirements, and p control new requirements and changes t

6. Develop the ability to communicate effe Too often, differences in perspective prev Management views information techno achieve business objectives. Systems and their work in terms of work products requirements. As noted earlier, it furthe the project or organization to say yes, ments only guarantee failure in the fu offers suggestions in her article Six Tr ware-Speak and Management-Speak [1 sometimes RAs must concern themselve management, but also with the customer

7. Initiate learning and applying effective pr to project success. One needs to be willin practices. Learning comes from experie practices on projects requires training t them; mentoring people in their use; tr and ensuring that their deployment and

process improvement and our adoption at the end of each cycle of activities, co gather feedback concerning how things gestions generated to improve how the the process that is being used). Thes to providing good ideas) serve to help cedures used, because participants h improve that process!

9. Take responsibility for your views, a actions. By taking responsibility, one es ability. Youll tend to exhibit pride in personalities and individual characteri good relationships with everyone. You contribution. You will be setting an ex leader.

10. Develop the ability to estimate the time to accomplish technical work. One of th mates of technical work is that these e order to develop projections of the num plete the project. (The number of staff, t are required to develop an estimate of difficulty is compounded by the fact th not yet known. So, we often find ourse out an accurate basis for them. This can not productive and also to confusion ca stream to meet the estimates.

The RA can contribute to the estima with users in the joint team enviro

3. See Watts Humphreys Why Dont They Practice What We Preach for ins suggestions for how to deal with it. See www.sei.cmu.edu/publication preach.html.

management tools. See the discussion in management. As an RA gets more experi ments analysis, the RA should also be changed requirement for any risk that it projects get more complex and as custome specifying their needs, each new or ch adverse impact on the project. Note that introduction to the requirements mana area (PA), specifies that one should refe (RI) process area for more information a dling risks associated with requirements.

11. Maintain focus on keeping the main thing pitfalls in developing systems and softwa much; another is that we try to incorpo Customers and users will ask, Can you do do that? We dont like to say no. We parti tion that the new system will be all thing doing, we jeopardize our ability to fulfill t success of the effort.

The RA can serve a critical role here. facilitate establishing the concept that equally important and that its the respon to prioritize needs collaboratively and to f ect (to keep the main thing the main thi Whitten in Meet Minimum Requiremen Much [12], the RA should work to ide requirements required to accomplish the goal can be facilitated by doing the follow

4. Contact Dr. Moore at john.moore@ngc.com.

5. Contact Mr. Raphael at RRaphael@ngc.com.

should not invent requirements inde

gold plating, that is, adding features and software when they are not requir The RA or developer might think he k way cool for the users that could turn disruptive to the project (e.g., if incr provide it).

12. Develop the ability to think outside t approaches that might not occur to peop lem and the legacy system. One of the a new assignment is that he does not ha that a user or customer has and, therefo unbiased agent. The RA arrives withou essarily having much knowledge of the attached to any particular outcome. Un tion with a problem domain and unconf legacy system, you are free to think mor be done and how it can be addressed bes ties to think of new and different ways be addressed.

13. Maintain a good knowledge of evolvin be applied to meet customer needs. So that a strong technical background is ver tioned earlier, understanding current t responsibility of the RA, but we can con by involving architects in reviews of the ing them in developing technical solut important is that incorporating some n requirements that must be considere believe that a strong technical backgrou RA as the other characteristics, especi ments and understanding the real customers and users. These people bel

powerless to make a difference. For examp ect for a period of several months during an important, needed, and valued contri seemed to withdraw his support for my ro with him and was unable to change it. It w to a different project. Sometimes we nee for change and act on it.

16. Develop your ability to contribute to the p project should have a risk process to ide and mitigate existing or potential risks. your projects risk management team an related risks are important to the project. dialogue that will help your project deal

Summary

Suggested skills of the RA are listed and categoriz (Table 3.1) according to those needed by a j senior-level analyst. This matrix will help you eva specific project role. You may use it as a guide t improve your skills or as a reference to sources o each skill. Table 3.2 provided an RA job or positi help you clarify the many ways in which the role to benefit both your project and your organizati explicit helps a project to run more smoothly. T understood and valued in the minds of PMs a nitythis job description should help! Sixteen ch RA were presented and described. Suggestions how to strengthen these characteristics. Conside your own personal and professional development, assignments and responsibilities, and select one strengthen each year. Yes, being an effective RA

zation from the perspective of relevant industry there seemed to be a sincere desire on the part o the situation, although many issues existed. T these issues could be resolved. At the conclusio manager concluded that the situation could no other participants in the training were perplex felt they were off to a fresh start.

Analysis: The senior manager himself was t the situation from improving. Although there parties, management was willing to allow par overly bureaucratic development process, and p stakeholders to paralyze efforts and render im impossible. In Dr. Demings framework, there Users and the development organization were situation without managements support and for better results. Management must enable an the rest of us) in order for work to be prod try studies report that lack of appropriate sen a factor in most IT failures. This vignette has m ers. Industry experience is that senior managem port IT and systems/software development in successful. See the discussion in Chapter 8 an Review article, Six Decisions Your IT People Sh ther insights and specific suggestions. The RA ca these insights, suggestions, and industry experi ment team and by helping to clarify the specifi ment should provide.

6. Be sure to familiarize yourself with Dr. Demings teachings. See, for ex Management Method (New York: The Putnam Publishing Group, 1986). In C Deming used The Parable of the Red Beads in his seminars to driv organization [most of us] are powerless without managements support.

[7] INCOSE WMA Chapter, Web site, at www.incose-

[8] Gaffney, S., Web site, at www.StevenGaffney.com

[9] Gottesdiener, E., Requirements by Collaboration:

Reading, MA: Addison-Wesley, 2002.

[10] International Association of Facilitators, Web site,

[11] McKinney, D., Six Translations between Softwa Speak, IEEE Software 19(6) (2002): 5052. See w

[12] Whitten, N., Meet Minimum Requirements: Anyt Network (September 1998), p. 19.

[13] Ross, J. W., and P. Weill, Six IT Decisions Your

Harvard Business Review (November 2002): 8591.

Terminologies to Avoid

Examples of Requirements

Types

Summary

Case Study

References

on his project and in his organizati avoided by agreeing on a set of d certain terms. In this chapter, w requirements and suggest definiti why some terms shouldnt be use lines. One important reason for ag the types of requirements is to debates about terminology while Establish a project glossary that eve some definitions are not everyone your work. Consider the glossary p starting point, and tailor it as need

First, lets recall our simple requirement from Chapter 1. A req identifies a capability, characteristi tem in order for it to have valu requirement is well defined and which is a capability desired by a problem or achieve an objective. Engineering Capability Maturity M insightful when they created Pro Customer Needs and Expectations. area is to elicit, stimulate, analyze, and user needs and expectations an fiable set of requirements.

Views of Requiremen

Next, lets provide three different w types. These views will help you pu

Figure 4.1 provides a more detailed context ments types that are noted are production proce physical facilities needed), requirements of the p the system or software, the requirements of the duce the products (e.g., the testing process), and support requirements (e.g., equipment, training these requirements must be identified before wo design is started. While the product engineers are for the product elements, the manufacturing e manufacturing requirements, the logistics engin ments, and the verification engineers the qualific doing so, these engineers must communicate amo resolve the best aggregate expression of the requi and process perspective.

Its important to note that several steps or wa fied real requirements must be made1 to ensure, fo

Table 4.1 Requirements Ty

Hardware requirements:

Performance requirements

Constraints:

Interface requirements

Specialty engineering require

Environmental requirements

Software requirements:

Functional requirements

Nonfunctional requirements

Source: Jeffrey O. Grady. Used with permi

1. Industry practitioner and advisor Ellen Gottesdiener, president of EBG Consu four iterations of requirements development, each incorporating a formal or external customers. Her experience emphasizes the value and importance of i before starting other work.

The requirements are prioritized (there money to do everything).

Figure 4.2 provides a total requirements tax figure as follows:

ProcessProcess

interfacespecialty

requirementsrequireme

EnterprisemissionstatementProcess

functionalProcess performance re

requirements

Attributes

CustomerstatementProduct

functional

need

requirementsProcess performance r

ProductProductspecialtyinterfaceengineeringrequirementsrequiremen

Computer software functional requireme

Computer software nonfunctional requir Computer software attributes

Grand system and hardware requiremen

Verification requirements paired with product a

Figure 4.2 Total requirements taxonomy. (Source: J

specifications. The former kind drives design and

kind drives acceptance [8].

Another view with which the RA should in Electronic Industries Association (EIA) Stan (Requirements), and in IEEE Standard 12207 tem Requirements Analysis) and Section 5.3.4 Analysis). You should digest these standards an that are suggested.

Another approach is the Zachman Framewo describes the ZF in his book Requirements Analys Architecture [6]. Hay describes the RAs work as m two to row three on the ZF, and the book is dedi niques used in each column. A review may help standing the various types of requirements.

Also compatible with the ZF are the CMMI [ product, and product component requirements. B treat requirements analysis as a continuing pr needs and expectations to system specifications. T understanding what an RA does.

Definitions and Descriptions of Require

The remainder of this chapter provides definitions types of requirements. I reiterate my earlier sugg glossary of terms to be used on your project. Wor opers, add words and definitions of them that y proceed with your work. Dont spend a lot of tim the definitions: simply use the technique in projec indicating her or his agreement with a thumbs reach agreements that people can live with. Iv these terms (requirements types) provided bel because they tend to confuse people and creat

as a technique for understanding business requi success of a system is the extent to which the s requirements and facilitates an organization in tems and software do not support the business r efficiently, they have no reason for being. Busi

Table 4.2 An RAs View of Requirements T

Customer needs and expectations:

Business requirements;

User requirements;

Product requirements;

Environmental requirements;

Unknowable requirements.

These are analyzed by the requirements analyst and d

High-level (or system-level) requirements; Functional requirements (what the system must 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 sy

The system requirements are allocated into:

Subsystems (logical groupings of functions); Components of the system (hardware, software, t

Checks are done to ensure the system does what it is s

Verified requirements;

Validated requirements;

Qualification requirements.

identifying omitted requirements is a key t

User Requirements

Users are the individuals or groups that use a syst ronment. User requirements are their verified software.

High-Level or System-Level Requirement

To enable comprehending a needed system, we system-level requirements. This term relates to are foremost in importance, capture the vision defining the scope of the system, and allow estima required to build the system. (Some system ar requirements specification should contain every p Its recommended that a workable number of req 50 to 200) system-level requirements be identif Chapter 8, we will discuss a set of business drive high-level customer requirements, which often a

Business Rules

Business rules2 provide the basis for creating the They are as follows:

The policies, conditions, and constraints of t ported by the system;

The decision processes, guidelines, and cont requirements (e.g., procedures);

2. This discussion is summarized from materials developed by Ellen Gottesdiene Rules, The Value of Standardization of Business Rules, and Turning R materials are available at her Web site, www.ebgconsulting.com.

owner.

Business rules must be captured explicitly b ing requirements analysis. Focusing on business requirements speeds requirements analysis an verification. The RA should use the Document described in Figure 4.3 to select or tailor a tax template for any given business problem. The t syntax for writing business rules in natural lan

If you find yourself in a situation where help ing Ellen Gottesdiener (ellen@ebgconsulting.co rules requirements workshop.

Functional Requirements

Functional requirements is an important catego Functional requirements describe what the sys function is a useful capability provided by one o tem. Functional requirements are sometimes tional requirements because they specify the in the outputs (responses) from the system, an between them. The document used to commu customers, system, and software engineers is

The RA collaborates with:

Whom:Business domainOther businessExecutive

expertsdomain experts

To do:

DocumentValidateApprov

businessbusinessbusines

Steps:rulesrulesmodel

No

Figure 4.3 Documenting Business-Rules Process. (A

Gottesdiener.)

A derived requirement is one that is further re requirement or a requirement that results from mentation or system element. In a sense, all requ the system need; thus, the derived distinction te cance. However, many systems engineers distin identified requirements and requirements that ar trol of the engineer.

Design Requirements and Design Constra

For most system development efforts, design requir right at the beginning of the system formulation. its difficult to separate requirements engineering

New systems are often installed in enviro other systems. The other systems usually c new system. For example, a requirement ( that the system to be developed must ob an existing database. The database has al parts of its specification will usually be incl document.

For large systems, some architectural design tify subsystems and relationships. Identifyi the requirements engineering process for ea parallel.

For reasons of budget, schedule, or quality, to reuse some or all existing software system a new system. This constrains both the syst design.

If a system has to be approved by an extern in civil aircraft), it may be necessary to use that has been tested in other systems.

Another difficult challenge in system developm the interface requirements. Interface requireme cal and functional relationships among system tem elements and the system environment. should be assigned principal responsibility fo interface requirements. See [8, pp. 270297] fo face analysis and techniques.

Verified Requirements

Verified requirements are real requirements tha design solution.

Validated Requirements

Validated requirements are requirements that ar ered system. See Jeffrey O. Gradys System Vali clear definitions of these terms, detailed informa these fundamental problem-solving tools, and step of the process.

Qualification Requirements

Qualification refers to the verification or validati specific application and results from design re configuration audits.

The Ilities and Specialty Engineering

One often hears references to the ilities of quality attributes, such as the following:

Designability;

Efficiency;

Memory;

Timing constraints;

Modifiability;

Usability.

These are the nonfunctional or nonbehavioral or the software. See Alan Daviss Software Require States [10, pp. 307340] for a detailed discussion a

Unknowable Requirements

Experience has shown that there are requiremen the beginning of a system development effort. So apparent only as the system evolves. We discove ment that we could not envision previously.

Such unknowable requirements may be real r be included.

Product Requirements

These are requirements of the products that are

Process Requirements

There are requirements that exist because of th develop the system or software.

Logistics Support Requirements

These are requirements that exist because of suc procedures, facilities, and spares. One often hear the integrated logistics support (ILS) requirement

Terminologies to Avoid

Source or Customer Requirements

One sometimes hears people refer to source requirements. I prefer instead to specify th mentthat is, from whom or where the re fiedas an attribute3 of a real requirement. Hav each real requirement enables us to go to the pe tions and clarifications. I suggest avoiding use ments or customer requirements.

Nonnegotiable Versus Negotiable Requi

A nonnegotiable requirement implies that if it is tle use. Clearly, the requirement is a real require ment implies that its really okay if its not satis Clearly, negotiable requirements are not real r tion is not useful. Neal Whittens article, Me Anything More Is Too Much [11] is instructi requirements is in everyones best interests, be risk, cost, schedule, complexity, and so forth. Report [12] conclusion that 45% of system fea systems are never used once!

3. See Youngs Effective Requirements Practices [13, pp. 8587] for a discussion of a sample requirements attributes matrix one might use in a require Object-Oriented Requirements System (DOORS). Examples of attributes of ID, source, owner, rationale (why the requirement is needed), priority, st rejected, being reconsidered), cost, difficulty, stability, assigned to, locati traced-from, traced-to, root tag number, history, verification, validation, depend on the specific needs of your project. See also step 19 in Chapter 5

established by the systems stakeholders with engineering team. The term is not as clear as the therefore I suggest not using it.

Other Guidelines

Avoid using vague terminology, such as generally, user friendly, versatile, flexible, r in writing requirements.

Avoid putting more than one requiremen indicated by the presence of the word and

Avoid clauses like if that should be necess

Avoid wishful thinking: 100% reliability, pleasing all users, handling all unexpected

See Alexander and Stevenss Writing Better Requ guidelines based on extensive experience.

Examples of Requirements Types

The following scenario provides examples of th cussed above that will facilitate an understanding ABC, Inc. has experienced phenomenal growt due to mergers and acquisitions of companies th mentary in nature. To enhance ABCs competiti

4. Industry expert Ian Alexander advises that it is practice of the United King (MoD) to use very few key requirementsthere might be five for a warship, most strongly sought goals for the system: if all else fails, these goals remain, an evaluated in their light. It might not suit everybody but it contains something Personal communication to the author, January 18, 2003.

each local user will see the selected employee company in the same format as it would be if legacy system.

In addition, SATURN will be able to determ tems are available at the time a query is made system be unavailable for any reason, the use query can be made at a later time. Each query available information returned to the user withi system should be able to support up to 20 co degradation of performance.

The following Table 4.3(ad) provides examp the development of the SATURN system. Table examples for the hardware/software requireme Table 4.3(b) provides examples for the more d Figure 4.1. Table 4.3(c) provides examples from onomy view described in Figure 4.2. Finally Tab for the RA view of requirements described in T

Summary

Its apparent from this discussion that there ar requirements. It helps to agree to use a select your project team on the types that will be m glossary, which provides defined and agreed-up understandable words. Write requirements that requirement (see Chapter 1). Study the referen if you arent already familiar with them.

Case Study

We had a known requirement for Web site perf set of user scenarios that had to be execute

Software Requirements

Functional requirementThe SATURN system shall retrieve b

for all employees meeting the specif

Nonfunctional requirementThe SATURN system will generate e

fails to run to completion or a legac

within the allotted time.

Source: Terry Bartholomew. Used with permission.

Table 4.3(b) More Detailed Context Requirement Examples

Production process requirementThe SATURN system shall be availab

representatives at each company faci

Product requirementThe SATURN system shall retrieve ba

for all employees who meet the pred

training criteria.

Test process requirementTest HR records for verifying the SA

a special set of personnel records at

specifically created with artificial dat

Operational process requirementThe SATURN system will have the sa

company location that users of the s

familiar with and, therefore, shall re

Source: Terry Bartholomew. Used with permission.

Table 4.3(c) Total Taxonomy View Requirement Examples

Process functional requirementThe SATURN system shall be develo

companywide access to employee sk

information to all HR representative

Process interface requirementSkills and training information from

be available to all other company lo

Process specialty requirementTo ensure complete skills and traini

among the legacy systems, a data m

Process environmentalSATURN shall be developed using jo

requirementdevelopment (JAD) teams compose

representatives), developers, and sy

Process performance requirementThe SATURN system shall be ready

testing within 180 days of project in

Table 4.3(d) RA View Requirement Examples

Customer Needs and ExpectationsExamples

(Requirements Analysis Input)

Business requirementsManagers need access to timely an

in order to meet operational need

User requirementsThe user needs the capability to se

entire company by predefined skil

Product requirementsData formats shall be translated ac

into the format supported by the l

Environmental requirementsThere shall be no operational imp

impact on information retrieval ca

population of employees from whi

System Requirements Specifications (Requirements Analysis Output)

High-level (or system-level)The SATURN system shall maintai

requirementsinformation types contained in th

the field called education_level i

education in another.

The SATURN system shall convert

to the data expected by the local u

degree in one system might be ref

grade 17.

Functional requirementsThe local user shall be able to sear

predefined local, regional, or natio

personnel meeting a specified skill

Nonfunctional requirementsThe SATURN system shall make u

network (PSN) and not require de

communication.

Derived (or design) requirementsThe SATURN system shall use pub

and design constraintscommunications security.

Performance requirementsThe SATURN system shall support

without any noticeable degradatio

The SATURN system shall return a

user within 1 minute of initiating

Interface requirementsThe SATURN system shall present

with each local offices legacy syst

Source: Terry Bartholomew. Used with permission.

ments are understood.

References

[1] Engineering Process Improvement Collaboration

Capability Maturity Model, Version 1.1. Pittsburgh Institute, Carnegie-Mellon University, 1995, documents/95.reports/pdf/mm003.95.pdf.

[2] EIA Standard 632, Processes for Engineering a Sy

[3] IEEE Standard 12207, Software Life Cycle Proces

[4] Zachman Framework Web sites (e.g., see www.zif

[5] Inmon, W. H., J. A. Zachman, and J. C. Geiger, Dat the Zachman Framework: Managing Enterprise Knowle 1997.

[6] Hay, J., Requirements AnalysisFrom Business View

Cliffs, NJ: Prentice Hall, 2002.

[7] CMMI Web site, at www.sei.cmu.edu/cmmi.

[8] Grady, J. O., Systems Requirements Analysis, New Yo

[9] Grady, J. O., System Validation and Verification, Boca R

[10] Davis, A. M., Software Requirements: Objects, Functions

NJ: Prentice Hall, 1993.

[11] Whitten, N., Meet Minimum Requirements: Anyt Network (September 1998), p. 19.

[12] The Standish Group International, Inc., CHA West Yarmouth, MA: The Standish Group In www.standishgroup.com.

[13] Young, R. R., Effective Requirements Practices, Boston,

[14] Buede, D. M., The Engineering Design of Systems: M

John Wiley & Sons, 2000.

[15] Alexander, I. F., and R. Stevens, Writing Better Addison-Wesley, 2002.

an informal or formal inquiry deReferencesneeded. The request initiates a set activities. Its vital for the RA to h ing of these activities and to gain related tasks.

My experience has taught me t

A lot of time and effort is wasted and in performing requirements are a number of reasons for this

1. The project is just getting organi

2. There is no road map or check

3. Not all staff are present; some

4. There isnt much pressure to m

5. The customer and users are als get started.

6. The staff who will be working o may not fully understand the consequently, may not be able expectations.

7. An effective proven procedure ing steps is not available or use

If the requirements gathering eff is set for much additional time a technical work is initiated and p requirements. For example, at on company, 100% of planned deve

and designers to identify the real requirem or software development effort to de