Requirements for Managing Requirements

Requirements for ManagingRequirements

by Suzanne Robertson, Senior Consultant, Cutter Consortium

This Executive Report discusses how managers can use consistent

and understandable requirements knowledge as input to making

decisions and steering a project down its most agile path.

Agile Product & Project Management

Vol. 8, No. 9

http://www.cutter.com

About Cutter ConsortiumCutter Consortium is a unique IT advisory firm, comprising a group of more than 150 internationally recognized experts who have come together to offer content,consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, ground-breaking work in organizations worldwide, helping companies deal with issues inthe core areas of software development and agile project management, enterprisearchitecture, business technology trends and strategies, enterprise risk management,business intelligence, metrics, and sourcing.

Cutter delivers what no other IT research firm can: We give you Access to theExperts. You get practitioners’ points of view, derived from hands-on experience withthe same critical issues you are facing, not the perspective of a desk-bound analystwho can only make predictions and observations on what’s happening in themarketplace. With Cutter Consortium, you get the best practices and lessons learnedfrom the world’s leading experts, experts who are implementing these techniques at companies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats includingprint and online advisory services and journals, mentoring, workshops, training,and consulting. And by customizing our information products and training/consultingservices, you get the solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for allenterprises, or all departments within one enterprise, or even all projects within adepartment. Cutter believes that the complexity of the business technology issuesconfronting corporations today demands multiple detailed perspectives from which acompany can view its opportunities and risks in order to make the right strategic andtactical decisions. The simplistic pronouncements other analyst firms make do nottake into account the unique situation of each organization. This is another reason topresent the several sides to each issue: to enable clients to determine the course ofaction that best fits their unique situation.

For more information, contact Cutter Consortium at +1 781 648 8700 [email protected].

Cutter Business Technology Council

Access to the

Experts

Rob Austin Ron Blitstein Christine Davis Tom DeMarco Lynne Ellyn Jim Highsmith Tim Lister Lou Mazzucchelli Ken Orr Ed Yourdon



mailto:[email protected]

Requirements for ManagingRequirementsAGILE PRODUCT & PROJECT MANAGEMENTADVISORY SERVICEExecutive Report, Vol. 8, No. 9

Progressive organizations recog-nize that well-understood require-ments are at the root of deliveringrelevant products. These organiza-tions commit resources to improveskills for discovering and commu-nicating requirements and for inte-grating these techniques with agiledevelopment. When requirementsat all levels are consistently com-municable, the project managercan use them as input for makingdecisions. Factors about thecurrent state of requirementsincluding their number, level ofcompletion, priority, and depen-dencies enable managers tomake better estimates, monitorprogress, allocate responsibilities,and respond to change. ThisExecutive Report focuses on howproject managers can use require-ments knowledge to steer projectsdown an agile path.

Project teams that can talk consis-tently about requirements at dif-ferent levels of detail are in thedriver’s seat. In this scenario,team members can communicatewith each other and with otherstakeholders and make relevantdecisions about what they know,what they don’t know, and whereto put the effort to get to wherethey want to go. These individualsknow that requirements are notjust a list of statements saying,“The product shall do x or y.”Instead they recognize thatrequirements knowledge existsat a number of levels of detailand that, most importantly, allthe details are traceable betweenlevels. The knowledge modelpresented in this report representsa scheme for keeping track ofall the requirements-related sub-ject matter. Suppose you have aconsistent way of stating and

linking your business goals, stake-holders, project scope, terminol-ogy, constraints, assumptions,functional requirements, nonfunc-tional requirements, and othertypes of requirements knowledge.The appealing thing about this isthat once you have a scheme fororganizing knowledge, you alsohave the freedom to decide whichparts of that knowledge — and towhat level of detail — need to beinvestigated and communicatedfor each of your projects. In otherwords, some degree of formalityfrees you to make the choicesappropriate for accelerating eachparticular project.

During the past 10 years, therehave been significant improve-ments in techniques for dis-covering and communicatingrequirements. Instead of limitingrequirements-trawling techniques

by Suzanne Robertson, Senior Consultant, Cutter Consortium


VOL. 8, NO. 9 www.cutter.com

22 AGILE PRODUCT & PROJECT MANAGEMENT ADVISORY SERVICE

The Agile Product & Project Management Advisory Service Executive Report is published by the Cutter Consortium, 37 Broadway, Suite 1, Arlington,MA 02474-5552, USA. Client Services: Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America, +1 800 888 1816; E-mail: [email protected]; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: [email protected] Editor: Cindy Swain, E-mail: [email protected]. ISSN: 1536-2981. ©2007 Cutter Consortium. All rights reserved. Unauthorized reproductionin any form, including photocopying, faxing, image scanning, and downloading electronic copies, is against the law. Reprints make an excellent trainingtool. For more information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or e-mail [email protected].

to interviewing, people are usingapprenticing, simulation, stories,scenarios, collaborative software,creativity workshops, integratedmodeling, family therapy, andmany other techniques to dis-cover the relevant requirementsmore quickly.

The most effective requirementspractitioners discover require-ments by choosing the trawlingtechnique that fits each particularsituation and express their find-ings by integrating a wide rangeof modeling techniques with nat-ural language techniques. Thesespecialists also have a structurefor determining the appropriatelevel of detail in each case. Agile

requirements specialists are wellaware that the primary concern isto have an accurate understand-ing of the requirements and toensure that understanding is com-municated throughout the projectteam. The degree of formalitynecessary to communicate thatunderstanding depends on projectfactors such as geographical prox-imity of the team, experience ofthe team, location and experienceof all the stakeholders, size ofthe project, involvement of otherorganizations, and the impact ofgetting it wrong.

The earlier you have some consis-tent way of expressing require-ments, the earlier you can quantifythe size of the project. Along withthis you can identify the areas ofcertainty and uncertainty as well asthe parts that will benefit from fur-ther investigation and the parts thatare already well understood. Inother words, you are in a positionto use the high-level requirements(but this does not mean vague) todo a risk and benefit analysis andto decide on an appropriate strat-egy for your project.

This Executive Report looks athigh, medium, and low levelsof requirements and the connec-tions between them. The gradualbuildup of a class diagram iden-tifies classes of requirementsknowledge and the relationships

among them. An example is pre-sented in the report to help youconsider different ways of com-municating the requirementswithin your own projects. Specifi-cally, the report begins with adiscussion of how to build arequirements knowledge model.It then guides you through makingestimates for your project that aretraceable to the requirementsknowledge. It next offers a primeron using early requirementsknowledge to count functionpoints. The report concludes byhelping you consider the agilitypotential for your project.

EARLY COUNTABLES

A good starting point for quicklytaking stock of your requirementsknowledge is to do a stakeholder,goals, and scope (SGS) analysis.Each of these areas is shown asa different class of requirementsknowledge in Figure 1 (we’ll bebuilding on this figure throughoutthe report). The relationshipbetween these classes of knowl-edge is identified as “business rel-evancy.” In other words, the scopethat you study has to be sufficientand relevant to the goals, and thestakeholders you are concernedwith need to be relevant and suffi-cient for the goals you intend tomeet and the scope you need tounderstand. Asterisks (*) in thefigure indicate many; for instance,

*

1..*

1

Work

Scope

Project

Goal

Stake-

holder

Business

relevancy

Figure 1 — These three pieces ofrequirements knowledge provide thefirst project management countables.





there are many stakeholders,whereas there is just one workscope.

When you do an SGS analysis,your aim, as quickly as possible,is to identify the following require-ments knowledge:

For each stakeholder:

— The role you expect thestakeholder to play (e.g.,engineer, domain expert,tester).

— The knowledge you expectthe stakeholder to contribute(e.g., order taking, payrollrules, insurance calculation).

— The specific person who willsupply this knowledge.

For each project goal:

— A one-sentence descriptionof the goal.

— A one-sentence statement ofthe advantage the businessseeks to achieve if the goalis met.

— A measurement of how youwill know if the goal hasbeen met.

For the work scope:

— The people, organizations,and other systems thatare outside the detailedwork/business that youintend to investigate(referred to as adjacentsystems).

— The inputs and outputsbetween the adjacent sys-tems and the work/businessthat you intend to study. Inmost cases, these inputs andoutputs are data, although,depending on the domain,they might also be materialor control signals.

Questions to Ask

The requirements knowledgeyou get from a quick SGS analysisprovides input for raising earlyproject management questions.

Look for gaps in your stakeholderanalysis. If you have any types ofknowledge for which you do nothave a stakeholder, then you needto determine how you will get thatknowledge. If you have any roleswithout specific people to fillthem, then chances are thatnobody will take responsibilityfor that knowledge. What aboutpeople who do not have a role/knowledge assigned to them? Ifyou truly have this situation, thenyou have stakeholders who areunnecessary and will probablyslow the project down. Also, iden-tify potential conflicts by lookingfor stakeholders who are inter-ested in the same type of knowl-edge. Address each conflict bymaking an agreement on howdecisions will be made if/whenthe conflict occurs.

One of the most common causesfor project failure is the lack of a

quantified goal. Do you havea description/advantage/measurement of each goal? Ifyou do not, then you have nothingto guide you in choosing optionsand priorities. Do you really havea project goal that acts as a guidefor the whole project? Or do youhave detailed requirements mas-querading as goals? If you havemore than three to five projectgoals, then chances are you havedescended into detail without stat-ing the overall business problem.

Use the work scope to help ana-lyze the size of the project. Howmany input data flows are there?How many outputs? How manystores of data are there within thescope? How many adjacent sys-tems are there? Given your his-tory, how long do you estimatethat it will take you to understandthe requirements for an input flowand its related output flows? Giventhe budget — time and money —for your project, can you deal withall these inputs and outputs in thetime available? Can you put priori-ties on the inputs and outputs?Which ones contribute most tothe project goals?

When using the SGS approach1

people ask, “Should we first findthe stakeholders, analyze thegoals, or try to define the workand product scope?” You will getthe fastest results if you do not doany one of these things before theother; instead, do them in parallel.

©2007 CUTTER CONSORTIUM VOL. 8, NO. 9

EXECUTIVE REPORT 33

1The SGS approach is part of the Volere requirements techniques from Cutter Senior Consultants Suzanne Robertson and James Robertson [1].Volere is a set of techniques and templates for discovering, communicating, tracing, and managing requirements. The techniques are widelyused on commercial, scientific, and engineering projects.

Take an iterative approach as illus-trated in Figure 2. This makes a lotof sense because discoveriesabout one lead you to questions

and answers about another. Youare looking for a balance amongthe sources of the subject matter(stakeholders), the businessreasons for doing the project(goals), and the subject matteryou need to investigate (scope).

Other questions that you can raiseas a result of doing an SGS analy-sis are:

Is the benefit of doing this proj-ect worth the investment?

Given our resources, is this aviable project?

Failure to face up to these ques-tions often results in projects that

either do not deliver business ben-efit or stumble along until they areeventually cancelled after havingwasted resources that could havebeen better used elsewhere.

Bear in mind that these arequestions that are driven by the“highest-level” requirementsknowledge. You are using thatknowledge to identify uncomfort-able issues early so that you canchoose projects that provide realbenefits, quantify what you intendto manage, and give the projects aflying start.

LEVELS OF KNOWLEDGE

The team will use many and var-ied approaches for discoveringand capturing the requirementsat a more detailed level. Therequirements can be in manyforms — models, prototypes, orscenarios; the form does not mat-ter. However, if you want to beable to manage the project andrespond to change, there is onething that does matter: it is vitalthat you are able to trace therequirements at lower levels backto the high-level requirements andvice versa. This section discusseshow you can use a requirementsknowledge model to ensure trace-ability, keep track of progress, andimprove your potential for agility.

In Figure 3, four more classesof knowledge are added to theknowledge model:

1. Business event

2. Business use case



Scope

StakeholdersGoals

Figure 2 — The stakeholder, goal,and scope cycle iteratively explores

and defines the requirements space.

*

1..*

1

*1

1

1

Work

Scope

Project

Goal

Stake-

holder

Business

relevancy

Business

boundary

Business

responding

Naming

Convention

Business

Event

Fact/

Assumption

Business

Use Case

Figure 3 — Business events and business use cases (BUCs) provide a functional partitioning of the work scope.


3. Naming convention

4. Fact/assumption

All of these give the project man-ager input for making decisions.Notice that the work scope hasbeen partitioned into a number ofbusiness events, and the relation-ship states that each businessevent must be traceable back tothe work scope so that, at thelower level of detail, the businessboundary is consistent with thehigher level. How do you verifythis consistency? Remember thedata inputs and outputs definedon the work scope during thestakeholder, goals, and scopeanalysis? Each one of those inputsand outputs is attached to a busi-ness event.

At this stage, it is useful to focuson a specific example so that wecan discuss how a project man-ager can benefit from the addi-tional classes of knowledge. Inthis discussion, we’ll be examin-ing the four classes of knowledgediscussed above, shown in Figure3, as well as additional classes ofknowledge to be introduced laterin the report.

Business Events

Figure 4 is a context diagramshowing the work scope of aproject concerned with the workof managing the stocking andloaning of books in a library. Thecircle in the center represents thework to be investigated in order tounderstand the requirements. Thesquares around the periphery rep-resent adjacent systems (in this

case, book borrower and pub-lisher) that are connected to thework by named interfaces. Thediagram defines the scope of thework to be investigated by declar-ing and naming four input dataflows and five output data flows.Each of the interfaces eithercomes from or goes to one ofthe adjacent systems.

The knowledge model shows thatthe business boundary declared bythe work scope is partitioned into anumber of business events. Table 1illustrates how the business eventswould look in our example.

So what does this event partition-ing do for the project manager?

He or she can see that the work isbroken up into five pieces, each ofwhich can be traced back (usingthe input and output names) tothe declared scope. The projectmanager can use this understand-ing to talk to the team andaddress questions like:

Which of the business eventshas the highest priority accord-ing to the project goals?

Which event(s) should weconcentrate on first?

Has any investigation workalready been done on any ofthese events? We don’t wantto repeat anything when wecan reuse.


EXECUTIVE REPORT 55

LoanExtensionApproval

Book

Borrower

Publisher

The Work of

Managing Library

Loans

LoanExtensionRequest

Refused LoanExtension

ChosenBook

Book LoanAgreement

New BookAvailability

New BookDelivery

New BookOrder

New BookPayment

Figure 4 — This context diagram shows the business boundary forinvestigating the work of managing library loans.

Which members of the teamwill work on which events?

How long does it normally takeus to deliver product for eventsof this size? It might be tooearly to ask this question, butmaybe some member of theteam has a gut feeling ormaybe it would be worth tak-ing one event and prototyping itto come up with a feel for thecomplexity.

Which events do you anticipatewill be the most difficult giventhe stakeholder involvementthat you need?

These questions are all concernedwith the project manager beingable to keep track of the pieces ofthe project and identify problemareas as early as possible. Thenthe manager can help the team tobalance its resources and do asmuch as possible to anticipateand address problems. All of thesequestions are possible early in theproject if the project manager andthe team have a shared way oftalking about their requirementsknowledge.

Business Use Cases

Suppose that the team decidesthat Business Event 2 (borrowerwants to extend loan), shown inTable 2, is the one that has thehighest priority.

The team then takes that eventand does some requirementstrawling to understand the detailsof the business response to theevent. This response is called thebusiness use case (often referredto as a BUC).

The BUC can be expressed inmany different ways including as:

An activity diagram

Interview notes

A business use case scenario

A story card

A tape or video recording

A sequence diagram

A process model

A prototype

Suppose that the analyst decidedto write a BUC scenario that goessomething like this:

Business Use Case Scenariofor Event 2: Borrower Wantsto Extend Loan

The borrower gives the loanextension request to the dutylibrarian.

The librarian looks up thebook loan agreement for therequested extension.

The librarian looks up anyother books that are currentlyloaned to the borrower.

If the due return date on eachof the books is later thantoday’s date

then …

— The librarian tells theborrower there is a loanextension approval.

— The librarian records theloan extension.

otherwise …

— The librarian tells the bor-rower there is a refusedloan extension.

— The librarian records therefused extension.



OutputNo. Event Name Input

1

2

3

4

5

Borrower chooses book

Borrower wants to extend loan

Publisher has new book available

Publisher delivers new book

Time to pay for new books

Chosen Book

Loan Extension Request

New Book Availability

New Book Delivery

None

Book Loan Agreement

• Loan Extension Approval• Refused Loan Extension

New Book Order

New Book Payment

None

Table 1 — Business Events in Library Example


— The librarian asks theborrower to return theoverdue books.

In capturing the BUC for a busi-ness event, the analyst has cap-tured the business rules that mustbe carried out whenever thatevent takes place. In other words,the analyst has captured thebusiness requirements. With anunderstanding of the business usecase, the analyst has the basis foridentifying the most relevant andadvantageous product.

It does not matter how the BUCis expressed providing that thebusiness responding relationship(refer back to Figure 3) betweenbusiness event and business usecase is traceable. Once again, itis the input and output flows ofdata that preserve that traceability.Often when studying the details ofa business use case, the require-ments analyst discovers anotherflow of data around the peripheryof the business use case. Whenthat happens, the analyst addsthat flow to the business eventboundary as well as to the overallwork scope.

Naming Conventions and Factsand Assumptions

In the growing knowledge modelin Figure 3, there are two moreclasses of knowledge: naming

conventions and facts and assump-tions. As you start to understandmore about the terminology usedin the project, you can trap a lotof requirements knowledge byadding the definitions of terms tothe naming conventions. For exam-ple, while you are investigatingthe BUC for the business event of“borrower wants to extend loan,”you learn more details about whatis meant by a “loan extensionrequest.” If you define the meaningof the term, then the whole teamwill have the same understanding.

We can define the loan extensionrequest as follows:

Loan extension request:This flow of informationcontains the details of aborrower’s request toextend an existing loanfor a library book.

The data contents are: borrowername, borrower number, booktitle, return due date, requestedextension date.

The other class of knowledge —facts/assumptions — is there tohelp the project team bringdependencies, issues, and deci-sions out into the open. For exam-ple, if there is a dependency onanother parallel project, then thatshould be stated. And if there isa decision to exclude some

functionality, then that decisionshould be written down alongwith its rationale; otherwise, itwill surface again later and causeconfusion and wasted time.

Notice that naming conventionsand facts/assumptions do nothave relationship links connectingthem to other classes of knowl-edge. The reason for this is thatthey are potentially connected toall the other classes of knowledge.As an example, loan extensionrequest shows up on the workscope; it is also input to Event 2,and it will show up in BUC 2 andeventually in some of the detailedrequirements. The point is thatwherever the term is referenced,it should carry the same meaning— the one defined in the namingconventions.

Product Use Cases

The next class of knowledge toadd to the model is the productuse case (often referred to as aPUC), as seen in Figure 5. ThePUC is the part of the businessuse case that will be implementedas a product. The analyst investi-gates the BUC to a level of detailthat makes it possible to decide,given the constraints and goals,which parts of the BUC should becarried out by the product.


EXECUTIVE REPORT 77

OutputNo. Event Name Input

2 Borrower wants to extend loan

Loan Extension Request

• Loan Extension Approval• Refused Loan Extension

Table 2 — Business Event 2

The reason for spending time onthe BUC is to ensure that there isan understanding of the real busi-ness problem before trying tocome up with ways of solving it.Analysts can test whether theyhave a good enough understand-ing of a BUC by determiningwhether they can identify a bene-ficial corresponding PUC. In otherwords, given the understandingof the business problem, what arethe parts of it that would benefitmost from help? When asking thisquestion, the analyst is exploringthe options for a particular BUCtaking into account the projectgoals and the constraints, asshown in Figure 5.

Continuing with the BUC forEvent 2 (borrower wants toextend loan), the analyst can lookat each detail and ask: Wouldthere be a business benefit if theproduct does this, and do the con-straints allow us to do this?

Suppose that the analyst anno-tates the BUC with ideas for whatthe product will do as follows:

Business Use Case Scenariofor Event 2: Borrower Wantsto Extend Loan (Annotated withideas for the PUC)

The borrower gives the loanextension request to the duty

librarian. (borrower andlibrarian)

The librarian looks up thebook loan agreement forthe requested extension.(librarian and product)

The librarian looks up anyother books that are currentlyloaned to the borrower. (librarian and product)

If the due return date on eachof the books is later thantoday’s date (product)

then …

— The librarian tells theborrower there is a loanextension approval. (borrower and librarian)

— The librarian records theloan extension. (librarianand product)

otherwise …

— The librarian tells the bor-rower there is a refusedloan extension. (librarianand borrower)

— The librarian recordsthe refused extension.(librarian and product)

— The librarian asks theborrower to return theoverdue books. (librarianand borrower)

Bear in mind that this is only oneof potentially many ideas for whatthe PUC could be for this BUC. Forexample, in one alternative PUC,the borrower could have a directinterface with the product, which



*

1..*

1

*1

1..*

1

*

1 1

1..*

Work

Scope

Project

Goal

Stake-

holder

Naming

Convention

Business

Event

Fact/

Assumption

Business

relevancy

Business

boundary

Business

responding

Product

partitioning

*Product

Use Case

Business

Use Case

Product

Scope

Figure 5 — The addition of the product use case (PUC) to the knowledgemodel highlights the distinction between the business rules and the parts

of those business rules that will be carried out by the product.


would mean that more of thefunctionality of the BUC would beincluded in the PUC. The chosenPUC depends on the best mixbetween the goals and constraintsand is often best settled on bybuilding a quick version of thePUC to test out the ideas. For thepurpose of this example, let’s sup-pose that you have decided to gowith the ideas on the annotatedBUC. Then the resulting PUC sce-nario would be as follows:

Product Use Case Scenariofor Event 2: Borrower Wantsto Extend Loan

PUC name: Extend Loan

The librarian enters the loanextension request.

The product finds all outstand-ing loans for that borrower.

The product identifies loansthat are overdue: those witha return due date beforetoday’s date.

The product informs thelibrarian of overdue loans.

The librarian enters the loanextension or the refused loanextension.

Suppose that you determined thePUCs for each of the BUCs on thelist of events, then, as you see inFigure 5, the summary of all thePUCs defines the product scope.Notice how the product scope isrelated to a number of PUCs by theproduct partitioning relationship.

Atomic Requirements

The next level of detail is themeasurable atomic requirementsthat you derive from the PUCs.The knowledge model in Figure 6contains a number of new classesof requirements knowledge. Itshows the atomic requirementand subtypes (S) of the atomicrequirement: functional require-ment, nonfunctional requirement,and technological requirement(along with constraint, mentioned

above). In other words, thesesubtypes are all different sorts ofatomic requirements. The producttracing relationship between theatomic requirement and the PUCshows that for each product usecase there can be many (*)atomic requirements and thateach atomic requirement mightbe related to many (*) productuse cases. In other words, an indi-vidual atomic requirement mightbe duplicated in a number ofparts of the product.


EXECUTIVE REPORT 99

1..*

1

*1

1..*

1

*

1 1

1..*

** *

* *1

S

Work

Scope

Project

Goal

Naming

Convention

Business

Event

Fact/

Assumption

Constraint

Business

relevancy

Business

boundary

Business

respondingProduct

partitioning

Business

Use Case

*Product

Use Case

Product

Scope

Business

tracingProduct

tracingOwning

Atomic

Require-

ment

Are types of

Functional

Require-

ment

Non-

Functional

Require-

ment

Techno-

logical

Require-

ment

*Stake-

holder

Figure 6 — Functional, nonfunctional, constraint, and technologicalrequirements are all types of atomic requirements.

The functional requirements areconcerned with what functionsthat product is required to carryout (e.g., find overdue loans orrecord loan extension date). Ifyou are working in an agile envi-ronment, then you are unlikely toneed to write functional require-ments as they will be taken careof by your scenarios.

The nonfunctional requirements2

deal with how well the product isrequired to carry out the function-ality. What look-and-feel, usabil-ity, performance, operational,

maintainability, security, cultural,and legal requirements does theproduct have?

The technological requirementsare requirements that do not relateto the business problem and arenot the concern of the businessspecialist. These requirements arethere because the designer hasmade a decision about how toachieve the functional and non-functional requirements by usingparticular technologies.

Notice also that the constraintsmentioned in conjunction withthe earlier discussion about PUCsare also classified as a type ofatomic requirement. It helps tothink of a constraint as a require-ment that does not have anynegotiability (e.g., the productshall be implemented using ourexisting network of personal com-puters; the product shall interfacewith the existing library loansdatabase).

An atomic requirement has anumber of attributes (see Figure 7



© Atlantic Systems Guild

Volere

Requirement #: Unique ID

Description: A one-sentence statement of the intention of the requirement

Requirement Type: Event/Use Case #:

Rationale: A justification of the requirement

Originator: Who raised this requirement?

Fit Criterion: A measurement of the requirement such that it is possible

to test if the solution matches the original requirement

Customer Satisfaction: Customer Dissatisfaction:

Priority: The relative urgency of

this requirement

Supporting Materials:

History: Creation, changes

deletions, etc.

Conflicts:

Functional,

Nonfunctional,

Constraint,

Technological

List of business

events/product

use cases that

have this equipment

Other requirements

that cannot be

implemented if

this one is

Degree of stakeholder happiness

if this requirement is successfully

implemented; scale from 1 = uninterested

to 5 = extremely pleasingMeasure of stakeholder unhappiness if this

requirement is not part of the final product;

scale from 1 = really matters to 5 = extremely

displeased

Pointer to

documents that

illustrate and explain

this equipment

Figure 7 — An atomic requirement is a collection of attributes that together make the requirement testable andtraceable. It is useful to have a checklist (such as the Volere requirements shell illustrated in this figure) to help you

think of all the attributes that might be relevant to each of your requirements.

2Refer to the Volere Requirements Template [3] for a detailed discussion of nonfunctional requirements.


for an example) that provide fur-ther input to making decisions.The project manager can use theatomic requirements to get a feelfor the size, complexity, andprogress of the project. How manyatomic requirements are therefor each PUC? How many of therequirements have a defined fitcriterion (this is what makesthem testable)? Do we have anyrequirements without a rationale?Are the terms used in the atomicrequirements defined in the nam-ing conventions?

If you are working in a small, colo-cated team, then you have a highpotential for agility. In this case, aPUC scenario supported by well-maintained naming conventionsand nonfunctional requirementsmight provide enough require-ments input for building yourproduct. In other words, youmight not need to write atomicfunctional requirements. However,the larger, more distributed, andmore fragmented your team, thelower your potential for agilityand the more you need to defineunambiguous and measurablerequirements at all levels.

Testing and Implementation

The requirements knowledgemodel that we have built up con-tains requirements at a numberof levels of detail, and each levelis traceable both upward anddownward. We have discussedhow the project manager canuse the classes of requirementsknowledge to monitor the com-pleteness of the requirements,

raise questions, and make strate-gic decisions. In Figure 8, threeadditional classes of knowledge— test case, system architecturecomponent, and implementationunit — provide the project man-ager with additional input.

Test case is a class of knowledgethat belongs to the testers. If youlook inside it, you find attributesthat keep track of the descriptionof the tests that have been run

together with the results. Noticethat each test case has a testingrelationship with many (*) atomicrequirements and also with manyPUCs. It is these relationships thatensure that the testers are in factdesigning and running tests thatmatch the specified requirements.If you look back at the atomicrequirement in Figure 7, you seean attribute called fit criterion.The fit criterion is the meas-urement of the requirement, and


EXECUTIVE REPORT 1111

1..*

1

*1

1..*

1

*

1 1

1..*

** *

* *1

*

*

*

*

*

** *

1

*

S

Work

Scope

Project

Goal

Naming

Convention

Business

Event

Fact/

Assumption

Constraint

Business

relevancy

Business

boundary

Business

responding

Business

tracingProduct

tracingOwning

Are types of

Functional

Require-

ment

Non-

Functional

Require-

ment

Techno-

logical

Require-

ment

System

Architecture

Component

Product

partitioning

Design

guiding

Supporting

Testing

Testing

Implemen-

tation Unit

Test

Case

Product

Scope

*Product

Use Case

Imple-

ment-

ing

Business

Use Case

Atomic

Require-

ment

*Stake-

holder

Figure 8 — The test cases belong to the testers, but they have a traceablerelationship to the atomic requirements and the PUCs. Similarly, to deal with

change, the PUCs need to be traceable to the implementation units.

it is precisely this that the testerneeds to test. In other words,by writing the fit criteria for therequirements, the analyst is ensur-ing that the tester has preciseinput and does not need to makehis or her own interpretation ofwhat the requirement means. Ifa tester designs a test for a PUC,then he or she designs the testcase to test the fit criteria for all ofthe atomic requirements relatedto that PUC. If the tester decidesto test an alternative grouping ofrequirements, then once again heor she designs the test case to testeach of the atomic requirementsin that grouping. This traceabilitybetween test cases and therequirements provides the projectmanager with status statisticsabout the number of PUCs andatomic requirements that havebeen successfully/unsuccessfullytested.

The implementation unit added inFigure 8 represents a unit of codeand belongs to the developers. Itmight be a system use case, amodule, an object, a class — itdepends on how the developersare working. From the require-ments point of view, the importantthing is the implementing relation-ship between PUCs and imple-mentation units. In other words,however the developers are work-ing, it must be possible to traceeach PUC to one or more imple-mentation units. If you are notworking with PUCs, then youwould have a relationship betweenimplementation unit and atomicrequirement. The point is that if

there is a change in an implemen-tation unit, then you need to beable to see which requirementsare affected and vice versa.

The class of knowledge calledsystem architecture componentnaturally belongs to the systemsarchitect. The design guiding rela-tionship with the product scope isthere to remind the requirementsanalyst that it makes sense for thesystems architect to have earlyinvolvement in decisions aboutthe scope of the product. It is truethat you need to understand therequirements before you cancome up with a solution. But anunderstanding of the higher-levelrequirements, represented bybusiness events, is often enough tobe able to communicate the busi-ness problem to the architect andto get some guidance about whatis possible within the constraints.

If you do this early, you will savetime by identifying which parts ofthe business requirements needto be defined at a lower level ofdetail and which parts you do notneed to take any further.

Your Knowledge Model

The knowledge model discussedin this section represents ascheme for keeping track ofrequirements knowledge. Thinkof this as a filing scheme that, atthe start of your project, is madeup of a number of linked emptyfolders. The amount of require-ments information that you putinto each of the folders dependson the characteristics of your

project. For example, if you areworking closely with a colocatedgroup, then you might decide torepresent your PUCs with scenariocards that you pin on the wall ofyour office. Those, together withdefined naming conventions,might be enough for your pur-poses. A large, distributed teamwill need to formalize more of thedetailed requirements becausethe risk of being misunderstoodis much higher.

You can record your knowledgein any mixture of models, text,simulations, and prototypes thatyour team has agreed on. Theform does not matter. What doesmatter is that you can identify thedifferent classes of knowledgeand trace the relationshipsbetween them.

Keep in mind that the knowledgemodel we have been discussing isa generic filing system. We sug-gest that you use it as a startingpoint and then make changes andadditions progressively to fit it intoyour own environment. The sortsof changes that might be madeinclude changing the name ofclasses and/or relationships tomatch the company’s own termi-nology, adding new classes andrelationships, and adding newattributes to classes to captureother facts specific to theorganization.

The knowledge model providesa consistent way for the wholeteam to talk about requirementsknowledge. This means that you




greatly improve your potential foragility and iterative development.You know what you know andwhat you don’t know, and you canmake choices about where to getthe most benefit for your efforts.

The Volere RequirementsTemplate [3] provides detailedguidance on all the classes ofknowledge mentioned in theknowledge model. The first ver-sion of the template was releasedin 1995. The template has beenapplied on a wide variety of proj-ects in commercial, scientific, andengineering domains and is peri-odically updated to reflect newinsights. At the time of writing thisreport, the template is Version 11.

EARLY ESTIMATES

A common problem faced byproject managers is being askedto make an estimate of how longa project will take before know-ing how much effort is involved.People are often expected — onthe first day of a project — to stateprecisely and irrevocably howlong the project will take. If theonly thing you know is the nameof the project, then it is impossibleto make a meaningful estimate.Before you can know how longit will take to study a piece ofwork and derive a product toimprove that work, you need toknow the size of the piece ofwork. Obviously, the larger andmore complex the scope of thework, the more time it will take.

But in order to know its size, weneed to be able to quantify theamount and complexity of thework. Earlier in the report, wetalked about how the require-ments knowledge model orga-nizes requirements into traceablelevels of detail. Now let’s look athow we can use those high-levelrequirements as input to doinga meaningful estimate early inthe project.

Function point counting is a tech-nique that was originally devel-oped to measure the functionalityof software. In this section, youwill see a brief primer3 on howthe same technique can be usedto measure and estimate the sizeof the requirements activity.Carol Dekkers of Quality PlusTechnologies is a specialist infunction point counting and hashelped us to apply the techniqueto requirements. Dekkers pointsout that this is very similar to whatan architect does when you wantto know how much it will cost tobuild your house. The first rough“high-level” plan provides thearchitect with something to count.Suppose the architect tells youthat the area of the building willbe 3,000 square feet and that thisstyle of building costs $250 persquare foot. This provides youwith a reasonable idea of the esti-mated cost of your house. You canuse this technique to estimate thesize of the work scope that youintend to study; instead of meas-uring the square feet that the

building will occupy, you measurethe number of function pointswithin the work scope that youintend to study.

If you are not familiar with func-tion points, it might be helpfulto review some function pointcounts of established softwaresystems. Capers Jones of SoftwareProductivity Research countedthe function points of systems inthe following categories, after thesystems had been built:

Airline reservation: 25,000

Insurance claims: 15,000

Telephone billing: 11,000

Visual Basic: 3,000

Word 7.0: 2,500

Aircraft radar: 3,000

Unix v5: 50,000

Suppose you could estimate thenumber of function points deliv-ered in your last project. Then,given the total cost of your proj-ect, you could come up with theaverage cost for specifying andinstalling a single function point.Whilst you cannot rely on this costper function point being identicalfor all of your projects, at least itprovides you with a starting pointfor your own organization. Nowsuppose that, instead of waitinguntil the end of the project tocount your function points, youhave a way of estimating the num-ber of function points by using



3For more on how to use early requirements knowledge to count function points refer to Suzanne Robertson and James Robertson’s bookRequirements-Led Project Management: Discovering David’s Slingshot [2].

early requirements deliverables.This provides you with a tangibleinput to your estimating process.

This section uses the library loanexample introduced above toillustrate how you can do a func-tion point estimate early in theproject.

Stored Data

In Figure 4, you have a workcontext diagram that defines thescope of the work that we intendto study in order to understand thework of managing library loans.The context diagram shows theinput and output data that definesthe boundary of the study. As withany piece of work, if you lookinside, you will discover that itcontains stored data. This storeddata — databases, files, archives— that the work references andmaintains all adds to the work’sfunctionality. If you study thisstored data, you will learn enoughto be able to do a function pointcount.

It does not matter how the datais stored now or how it will bestored in the future. To do yourfunction point count, you need todo a rough business data model.If you do not know how to do this,then co-opt a data modeler tohelp you. In Figure 9, you see adata model for the work of man-aging library loans; these are theclasses of data you would expectto find.

The “borrower” has “loans,” andeach one is for a “book.” Thebooks are supplied by the “pub-lisher,” and each book has an“author” and a “payment” thatneeds to be made to the pub-lisher. Inside each of the classes,you will find attributes that belongto that class. For example, theclass “book” would have attrib-utes like:

Book title

Book ISBN number

Book category

Book published date

And more

The stored data contributes to thefunctionality of the work you arestudying, and you can use it in con-junction with the BUCs to come upwith the function point count.

Counting the BUCs

Earlier in this report, we discussedhow you can use business eventsto partition the work into function-ally related pieces. Each of thesepieces is a business use case.Referring back to Table 1, you seethat each event has a BUC thatcontains some processing andsome data stored and/or retrievedby its processing.

Looking through Table 1, you seethat there are two different typesof events: those that originateoutside the work (1. Borrowerchooses book) and those that aretriggered by time (5. Time to payfor new books). This difference isimportant to function point count-ing as this process counts theresulting BUCs slightly differentlydepending on whether they are aninput, an output, or an inquiry.

Counting Output BUCs

A BUC whose primary purpose isto deliver output is referred to infunction point terms as an output— or, to be absolutely precise, anexternal output. An example ofthis is the BUC for Event 2 (bor-rower wants to extend loan). Themain purpose of this BUC is togive the borrower a response to



Book

Publisher

Loan

Payment

BorrowerAuthor

* * *

*

*

*

Figure 9 — This data model shows the classes of business data that need tobe stored within the work. The asterisk (*) indicates cardinality, for example,

an author has potentially many (*) books.


his or her request to extend theloan for the book. Along with oneor more significant output flows,this sort of BUC will also containprocessing that makes somecalculations and/or decisions,updates stored data, or both. Asthis is classified as an output BUC,we start by counting the attributesof the two output flows — loanextension approval and refusedloan extension — as follows:

Loan extension approval

— Book title

— Loan extension date

— Loan extension conditions

Refused loan extension

— Book title

— Extension refusal reason

The analysis of these two outputflows gives a total of five data ele-ments. Just remember this for amoment: at this stage, it is notvital for you to know what thedata elements are; the importantissue is to know how many thereare. This is all happening veryearly in the project, and you mightnot know enough details to beprecise about the number of ele-ments; in that case, you can makean informed guess. Later you willsee why that is acceptable.

To continue with the count for thisBUC, we now need to look at thestored data. Look back at the datamodel in Figure 9 and ask whichof the business classes are refer-enced by this BUC. The BUCneeds to reference the borrower

so that it can find all his or herloans; also, it needs to referencethe book for each of the loans. Sothis means it needs to referencethree classes of data: borrower,loan, book.

These counts are converted tofunction points by referencing thebox in Table 3. The five data ele-ments of the output flows put usin the first column, and the threedata classes referenced meanswe are in the middle row. Theintersection gives us a total offour function points.

You can see now why it is permis-sible to guess a little about thenumber of data elements in thedata flow. Table 3 shows rangesfor the number of data elements.Providing you can guess withinthese ranges, it is not necessaryat this stage to do the detailedanalysis required to find theprecise number of elements.

Add the function point count forthis BUC to the accumulated func-tion point count for the work, andthen count the next BUC. Continuewith this process until you havecounted all the BUCs. Events 1and 3 (in Table 1) are also externaloutput events, so you would countthem using the table in Table 3.But Event 4 is classified as anexternal input and will be countedslightly differently. We also haveto discuss how to count Event 5,which is a temporal event.

Counting Input BUCs

Business Event 4 is “publisherdelivers new book.” This qualifiesas an external input because theprimary intention of its BUC is toupdate some internally storeddata. Output flows from this kindof BUC, if there are any, are trivial.In this example, the new bookdelivery causes changes to someof the classes of data within thework. We start by estimating the



1-5 20+

5<2

2-3

>3

Data Elements

Data

Cla

sses

Re

fere

nc

ed

6-19

44

4 5 7

5 5 7

This table shows function point counts for BUCs where the

primary intention is to provide an output. The correct terminology

for these is external outputs.

Table 3 — Counting External Output Events

number of data elements in theinput flow. Suppose we say thatthe elements in new book deliv-ery are something like: publishername, publisher address, booktitle, book ISBN, author name,book category, book publisheddate, and payment amount due.This gives a total of eight dataelements.

The next thing to do is to countthe number of classes of storeddata that are referenced by thisBUC. Looking back at the datamodel for some help, it looks asif this BUC is concerned with cre-ating and/or updating instances ofthe data classes of author, book,publisher, and payment. So thatgives us four classes.

All that remains is to referencethe table and find the intersectionbetween our eight data elementsand our four classes. The result isthat the function point count for

BUC Event 4 is six, as seen inTable 4.

These function points are addedto the aggregation, and you con-tinue to count the function pointsfor the rest of the BUCs.

Counting Temporal or Time-Triggered BUCs

In any piece of work that youstudy, there will be events thatare triggered by time. It might bethat it is time to report on weeklysales, time to renew a subscrip-tion, or time to pay a bill. There isone of these temporal businessevents in the work of managinglibrary loans: Event 5 (time to payfor new books).

The name that function pointcounters give to this type of BUC isinquiry. This is because the workof the BUC is to inquire aboutsome of the stored data within thework. Note that if the processing is

more than just the retrieval ofstored data — suppose it is alsoconcerned with making nontrivialcalculations and updating the data— then the BUC should be treatedas an output BUC to reflect thegreater complexity.

Let’s suppose that the work ofBUC Event 5 is to review the pay-ments due at the end of themonth and to produce a newbook payment that is sent to thepublisher. The question now ishow many data elements thereare in the flow that goes to thepublisher. It makes sense toinclude the publisher name, pub-lisher address, book title, bookreceipt date, payment amount,and payment date; this gives usan estimate of six data elements.

The next step is to look at the datamodel to identify how many of thebusiness classes are referencedby this BUC. The BUC certainlyinvolves book, publisher, and pay-ment, so we have three classes.Table 5 gives us the function pointcounts for inquiries, and the inter-section of six data elements andthree classes of data results infour function points. As before,you add the function points forthis BUC to the accumulated total.

Counting the Stored Data

In addition to counting the func-tion points for each BUC, you alsoneed to consider the stored data.The data needs to be maintained,and this requires an amount offunctionality that you can estimateby measuring the amount and



1-4 16+

4<2

2

>2

Data Elements

Data

Cla

sses

Re

fere

nc

ed

5-15

33

3 4 6

4 6 6

This shows the function point counts for an input BUC. Note

that the input must come from one of the adjacent systems on

the work context diagram. The correct function point counting

terminology for these is external inputs.

Table 4 — Counting External Input Events


complexity of the data. You canuse the data model as input todoing this count. This time, foreach class of data, estimate thenumber of data elements that itcontains. Take the data class“book” as an example. Earlier wecame up with book title, bookISBN number, book category, andbook published date — a total offour data elements — that belongto that class of data. Table 6 tellsus how many function points thatgives us.

However, there’s something a lit-tle bit different this time. We haveestimated that the data class con-tains four data elements, so thatleads us to the first column (1-19)in Table 6. The next count isrecord elements. This refers tosubclasses of the data. For exam-ple, suppose the class “book” hastwo subclasses: fiction book andnonfiction book. In function pointlanguage, we would say that bookhas two record elements, whichalong with the four data elementsgives a function point count ofseven for the data class book.

So you add five function points toyour accumulated count and thencount the remaining data classes.

If you have any externally storeddata — data that is used by yourwork but maintained by anothersystem — then you also count thatexternal stored data and look upthe function points using Table 7.The library loan managementexample does not have anyexternal stored data.



1-5 20+

41

2-3

>3

Data Elements

Data

Cla

sses

Re

fere

nc

ed

6-19

33

3 4 6

4 6 6

This table shows the function point counts for inquiries.

Table 5 — Counting Temporal Events

1-19 51+

10<2

2-5

>5

Data Elements or Attributes

Reco

rd E

lem

en

ts

20-50

77

7 10 15

10 15 15

These are the function point counts for internal stored data, or

internal logical files as they are called in function point terminology.

Table 6 — Counting Internal Stored Data

1-19 51+

7<2

2-5

>5

Data Elements or Attributes

Reco

rd E

lem

en

ts

20-50

55

5 7 10

7 10 10

These are the function point counts for data that is used by the

work but stored by another system. The function point terminology

is external interface files.

Table 7 — Counting External Stored Data

Using the Counts

If you did a function point countfor all of the BUCs and all of thestored data in the library loanswork, you would have a resultthat looks like Table 8.

You have used your high-levelrequirements knowledge, and youhave counted 67 function pointswithin the scope of the work. Nowyou need to convert the functionpoint count into effort needed togather the requirements by multi-plying the number of functionpoints by the time or effort neededby your organization to completethe analysis and requirements forone function point. If you do notknow this number for your organi-zation, then either derive it fromprevious projects or derive it bydoing a quick simulation to seehow much effort is necessary todiscover the requirements for oneof the BUCs in your project.

If you are outsourcing your devel-opment, then the traceability

between your levels of require-ments together with your functionpoint count will help you to com-municate with suppliers. And,most importantly, you have theability to manage change. If yourwork context produces a functionpoint count of 55, then addingextra interfaces or makingchanges will alter your functionpoint count. This provides youwith an objective way of dealingwith changes.

This discussion on how to countfunction points early in the projecthas illustrated how high-levelrequirements knowledge —assuming you have a consistentway of communicating it — pro-vides you with a valuable projectmanagement tool. The next sec-tion discusses how you can takeadvantage of a consistent way oftalking about requirements todecide how to profitably spendyour effort.

POTENTIAL FOR AGILITY

An agile requirements strategy isone where there is no wastedeffort. All the effort you spendon requirements (meeting, inter-viewing, modeling, reviewing,prototyping, documenting, testing— everything) brings you closer tobeing able to meet your project’sgoals. Think back to the require-ments knowledge model dis-cussed in the first part of thisreport. Remember that the modelrepresents a filing system forkeeping track of the classes ofknowledge you need to under-stand and the connectionsbetween them. The projects withthe greatest potential for agilitywould be ones that could incre-mentally discover and share allthat knowledge, and makechanges to it, without having toformalize how it is discoveredand how it is represented.

But not all projects have the samepotential for agility. Large num-bers of stakeholders, scattereddevelopment teams, varyinglevels of experience, and otherfactors that make it difficult to getanswers and make decisions allinfluence your potential for agility.To help make your requirementsstrategy as agile as it can possiblybe it is useful to consider theagility potential for your project.

Rabbit Projects

Rabbit projects, like their name-sake, are small and fast. If yourproject has the characteristics of arabbit, then you have the highest



Function

Points

BUC1 7

BUC2 4

BUC3 4

BUC4 6

BUC5 4

Data Class Author 7

Data Class Book 7

Data Class Borrower 7

Data Class Loan 7

Data Class Payment 7

Data Class Publisher 7

TOTAL ESTIMATED 67

Table 8 — Total Function Point Count


potential for agility. Rabbit projectstypically occur where close stake-holder participation is possible.The developers and the domainexperts are either physicallylocated in the same place or havedeveloped a way of workingwhere distance does not impedethe ability to share ideas andmake decisions. Rabbit projectsare iterative. They gather require-ments in small units (typically oneBUC at a time) and then imple-ment the solution piece by piece,using the implementation to getfeedback from the stakeholders.Rabbit projects are not focused ona process that delivers a require-ments specification; instead, theyhave a process that discovers andcommunicates requirements onelogical chunk at a time. Rabbitprojects benefit from having asketch of a requirements knowl-edge model on their whiteboardso that stakeholders have someconsistent way of talking to eachother. However, these projects willnot produce formal deliverablesfor each one of the classes ofknowledge. If these teams sketcha work context and come up witha list of business events, then theymight choose to do BUC scenariosfor the most complex ones andkeep a list of naming conventionsso that everyone can see them.

Rabbit projects benefit from pay-ing attention to all the classes ofrequirements knowledge, but theamount of time and effort that theteams spend in representing theknowledge is minimized because

they share their understanding bytalking to each other.

Horse Projects

Horse projects have less potentialfor agility. They are larger thanrabbit projects and hence moreconstrained by the size of theproject and the organization.There is more need to have aformal process for representingclasses of knowledge. Horse proj-ects are the most common corpo-rate projects. There is a need toformalize the documentation forsome of the classes of require-ments knowledge because it islikely that requirements must behanded from one department toanother. Another factor is thatthese projects usually involvemore than a few stakeholders,often in a number of locations.

Horse projects are working fromthe same knowledge model asrabbit projects, but they need amore formal process for howeach of the classes of knowledgeis discovered, who is responsiblefor it, and how it must be repre-sented both in terms of notationand documents. This extrabureaucracy is necessary in orderto exploit the potential for agilityby making communication ofunderstanding easier. But there isa trap here and that is that horseprojects often start to work by roteand stop questioning whether aparticular activity or deliverable isnecessary in all cases. To keep ahorse galloping, you need to keep

questioning whether everything inthe saddlebags is still necessary.

Elephant Projects

Elephant projects have the leastpotential for agility. These projectshave a long duration and hencelike elephants need a long mem-ory. Sometimes they are so longthat none of the people involvedat the start of the project are stillthere at the end. They involvemany stakeholders in many loca-tions at many levels of authorityand interest. Their technical infra-structure is diverse, and there aremany developers involved. Theseprojects often outsource partof their development, often toanother country. Owing to thishuge diversity, the elephant projecthas a need for a very formal andconsistent representation of therequirements knowledge — onethat is not open to interpretation.That representation is normally inthe form of a requirements specifi-cation document.

When elephant projects decidehow to represent their require-ments knowledge, the notationand format for how each classand relationship will be repre-sented is often mandated by orga-nizational or industry standards.

The truth is that even in the mostextreme of elephant projects thereis still potential for agility. You canexploit this potential if you have aconsistent way of partitioning theelephant and keeping track of theconnections between the pieces.



Within the large project, you candiscover a number of linkedsmaller projects, and some ofthese pieces — especially theones with colocated stakeholders— can be more agile than others.

CONCLUSION

This report discusses how man-agers can use consistent andunderstandable requirementsknowledge as input to makingdecisions and steering a projectdown its most agile path. Here’sa short checklist for putting theseideas into practice:

Agree with your team on therequirements knowledge youintend to manage and how youare going to talk about it. Thefirst section of this report givesan example of how to builda requirements knowledgemodel. You can use this exam-ple as a starting point, or youcan build your own. It does notmatter which you do providedit is consistent for your project.Keep your model visible, andchange anything that does notwork for you.

Use the early requirementsknowledge as input to makingestimates that are traceable tothe requirements knowledge.This report provides a primeron using early requirementsknowledge to count functionpoints.

Use your requirements knowl-edge as the vehicle for identify-ing releases and iterations andfor allocating tasks. For exam-ple, “We’ve agreed that BUCs 3and 10 are the highest value sowe’ll concentrate on deliveringthem in the first iteration.”

Use your requirements knowl-edge to monitor progress. Forexample, “How many of thePUCs in release 1 have all theirrequirements defined?”

Have your team analyze theadditional/changed require-ments knowledge for eachchange and then adjust thefunction point count and theestimate to reflect the change.

REFERENCES

1. Robertson, Suzanne, andJames Robertson. Mastering theRequirements Process, SecondEdition. Addison-WesleyProfessional, 2006.

2. Robertson, Suzanne, and JamesRobertson. Requirements-LedProject Management: DiscoveringDavid’s Slingshot. Addison-WesleyProfessional, 2005.

3. Volere. “Volere RequirementsSpecification Template,Edition 11” (www.volere.co.uk/template.htm).

RECOMMENDED READING

Alexander, Ian, Neil Maiden, et al. Scenarios, Stories, UseCases Through the SystemsDevelopment Life-Cycle. JohnWiley, 2004.

Davis, Alan M. Just EnoughRequirements Management.Dorset House, 2005.

DeMarco, Tom, and TimothyLister. Waltzing with Bears:Managing Risks on SoftwareProjects. Dorset House, 2003.

Garmus, David, and DavidHerron. Function Point Analysis:Measurement Practices forSuccessful Software Projects.Addison-Wesley Professional,2001.

Gottesdiener, Ellen. Requirementsby Collaboration: Workshopsfor Defining Needs. Addison-Wesley Professional, 2002.

Lauesen, Soren. SoftwareRequirements: Styles andTechniques. Addison-WesleyProfessional, 2002.

Weinberg, Gerald M. QualitySoftware Management, Volume 2: First-Order Measurement. DorsetHouse, 1993.

Wiegers, Karl E. SoftwareRequirements. MicrosoftPress, 2003.




ABOUT THE AUTHOR

Suzanne Robertson is aSenior Consultant with CutterConsortium’s IT Managementand Agile Product & ProjectManagement practices, a contrib-utor to the Agile Product & ProjectManagement advisory service,and is a principal and founder ofthe Atlantic Systems Guild. She iscoauthor of Requirements-LedProject Management, a book thatprovides project managers withguidance on how to use the workdone by requirements analystsas input to steering projects. Thebook defines the relationships

between effective requirementspractices and project success.This management book connectsto Mastering the RequirementsProcess, a guide for practitionerson finding requirements and writ-ing them so that all stakeholderscan understand them.

Current work includes researchand consulting on the manage-ment, sociological, and technol-ogical aspects of requirements.The product of this research isVolere, a complete requirementsprocess and template for assess-ing requirements quality and forspecifying requirements.

Ms. Robertson is the author ofmany papers on systems engi-neering. She also speaks atnumerous conferences and uni-versities. She is a member of IEEEand on the board of the BritishComputer Society’s RequirementsGroups. She was the foundingeditor of the requirements columnin IEEE Software. Other interestsinclude a passion for the opera,cooking, skiing, and finding outabout curious things. She canbe reached at [email protected].



Abou

t the

Pra

ctice Agile Product & Project

Management PracticeCutter Consortium’s Agile Product & Project Management practice provides you withinformation and guidance — from experienced, hands-on Senior Consultants — tohelp you transition (or make the decision to transition) to agile methods. Led byPractice Director Jim Highsmith, Cutter’s team of experts focuses on agile principlesand traits — delivering customer value, embracing change, reflection, adaptation,etc. — to help you shorten your product development schedules and increase thequality of your resultant products. Cutting-edge ideas on collaboration, gover-nance, and measurement/metrics are united with agile practices, such as iterativedevelopment, test-first design, project chartering, team collocation, onsite customers,sustainable work schedules, and others, to help your organization innovate andultimately deliver high return on investment.

Through the subscription-based publications and the consulting, mentoring, andtraining the Agile Product & Project Management Practice offers, clients get insightinto Agile methodologies, including Adaptive Software Development, ExtremeProgramming, Dynamic Systems Development Method, and Lean Development;the peopleware issues of managing high-profile projects; advice on how to elicitadequate requirements and managing changing requirements; productivitybenchmarking; the conflict that inevitably arises within high-visibility initiatives;issues associated with globally disbursed software teams; and more.

Products and Services Available from the Agile Product & ProjectManagement Practice

• The Agile Product & Project Management Advisory Service• Consulting• Inhouse Workshops• Mentoring• Research Reports

Other Cutter Consortium PracticesCutter Consortium aligns its products and services into the nine practice areasbelow. Each of these practices includes a subscription-based periodical service,plus consulting and training services.

• Agile Product & Project Management• Business Intelligence• Business-IT Strategies• Business Technology Trends & Impacts• Enterprise Architecture• Innovation & Enterprise Agility• IT Management• Measurement & Benchmarking Strategies• Enterprise Risk Management & Governance• Sourcing & Vendor Relationships

Senior ConsultantTeamThe Cutter Consortium Agile Product &Project Management Senior Consultant Teamincludes many of the trailblazers in the projectmanagement/peopleware field, from thosewho’ve written the textbooks that continueto crystallize the issues of hiring, retaining,and motivating software professionals, tothose who’ve developed today’s hottest Agilemethodologies. You’ll get sound advice andcutting-edge tips, as well as case studies anddata analysis from best-in-class experts. Thisbrain trust includes:

• Jim Highsmith, Director• Scott W. Ambler• Christopher M. Avery• Paul G. Bassett• Sam Bayer• Kent Beck• E.M. Bennatan• Tom Bragg• David R. Caruso• Robert N. Charette• Alistair Cockburn• Jens Coldewey• Ken Collier• Ward Cunningham• Rachel Davies• Doug DeCarlo• Tom DeMarco• Lance Dublin• Khaled El Emam• Kerry F. Gentry• Sid Henkin• David Hussman• Ron Jeffries

• Joshua Kerievsky• Bartosz Kiepuszewski • Brian Lawrence• Tim Lister• Michael C. Mah• Lynne Nix• Siobhán O’Mahony• Ken Orr• Patricia Patrick• Mary Poppendieck• Roger Pressman• James Robertson• Suzanne Robertson• Alexandre Rodrigues• Johanna Rothman• David Spann• Rob Thomsett• John Tibbetts • Colin Tully• Jim Watson• Robert K. Wysocki• Richard Zultner


Requirements for Managing Requirements

Documents

Transcript of Requirements for Managing Requirements