Tag: Elicitation

Tools of the Trade Part II; Implementing a Requirements Management Tool

Written by Cynthia Low on April 14, 2009. Posted in Articles.

Part one in this series described how to prepare, plan, and select a requirements management tool. Selecting the tool is usually the easy part. Implementing the tool without causing mass chaos brings a greater challenge. Now that a tool has been selected, what is the best way to gain acceptance and adoption of the tool within your organization? Change rarely comes without some resistance. This article will address how to maneuver through the resistance in order to successfully implement a requirements management tool by recruiting early adopters, marketing the tool, and communicating the change early and often. Finally, I will address some lessons learned while implementing a tool at several organizations.

Implement a Tool

Production is not the application of tools to materials, but logic to work.
~ Peter F. Drucker

Form a Team

Once the tool is purchased, implementation will take some planning, training, and mentoring in order to effectively rollout the tool. If you haven’t already, start with forming an implementation team. This team will represent the tool and its benefits to the greater IT department. The team will also help plan, create guidelines and best practices, and mentor analysts in their given departments.

Treat this implementation just like you would any other IT project. Start with a project plan, determine implementation tasks, and assign resources. Then execute on the plan.

Once the project plan is in place, get the team members completely trained and comfortable with the tool. At one organization we brought in the tool vendor to train the team members and a few key QA folks. We gave the vendor some samples of use cases from our own projects and utilized these as examples during the training. Team members then began using the tool on their own projects. As we met together we learned from our own experiences and utilized these experiences to draft best practice guidelines for the organization. Best practices included how to structure requirements within the tool, creating templates for different types of projects, naming conventions, and tips and tricks for some of the tool’s quirks.

Recruit Early Adopters

Once the team has established some guidelines and tested the tool out on their own projects, it is time to branch out. Find a few experienced analysts who are willing to be early adopters of the tool. Have team members train and mentor the early adopters on how to use the tool. Early adopters should then go through a complete project lifecycle while using the tool. Periodically touch base with early adopters to apply what they learned from their experience to the best practice guidelines. Also, gather feedback from the developers and QA team members on their perceptions of the tool. Since these groups typically consume the output of requirements gathering, they will need to accept the tool and perhaps adapt their work habits to accommodate a new method for managing requirements. Don’t underestimate this change!

Communicate Early and Often

As with any change, there will always be nay-sayers and skeptics. Implementing a requirements management tool will be no different. In fact, writing requirements in a tool rather than a Microsoft Word document requires a change in mindset. This change is easy for some to make and difficult for others. The implementation team can smooth this transition through communication. Hold forums where the tool is demonstrated, the benefits and limitations are discussed, and early adopters’ experiences are shared. Hold these forums on a regular basis so that teams are kept informed as to the progress, and reminded of the tools benefits.

Word-of-mouth advertising will go a long way to help encourage other analysts to adopt the tool. Have the early adopters talk about their experiences and spread the good news throughout their teams. After trying the tool on a few development projects, one early adopter expressed his enthusiasm for the tool stating “I want to write all of my requirements in this tool.” By trying the tool out on a few simpler projects, he became comfortable with the tool, its limitations, and saw the benefits gained from utilizing the tool. We harnessed his enthusiasm to help sell the tool during an analyst open forum. He also spread the word to his immediate team members and more people signed up to use the tool on their next project.

An Excuse to Celebrate

Finally, use the tool as an excuse for a party! At one organization, to gather excitement for the event, we hosted online trivia questions on our SharePoint site. We posted daily questions and the top five winners received gift certificates to the event establishment. At the event we re-iterated the benefits of the tool, provided links to training simulations, demonstrated examples of successful projects, and distributed the best practice guidelines. Once the formalities were complete, we broke out the entertainment and used the opportunity to socialize with our peers.

When it was all said and done, the tool implementation was really a non-event. There was no loud outcry, no grumbling amongst peers, no mass chaos, and no wasted money. We methodically went about our task of implementing the selected tool, sought help from our peers, and repeatedly delivered the same message throughout the organization which resulted in an easy transition to tool adoption. The complete process took about a year. We steadily increased user adoption during that year and by the time we held our event, most people had already begun using the tool. Compared with the previous implementation of a tool mentioned in part one, where little thought went into the needs of the user community, this tool implementation went off without a hitch.

Final Thoughts

Wisdom too often never comes, and so one ought not to reject it merely because it comes late.
~Felix Frankfurter

Despite the claims of many vendors, no tool is perfect. It is better to discover early on in the process the limitations of the requirements management tool. Once you know the limitations, devise a plan on how to work around the limitations and minimize the impact to your organization.

Test the performance of the application prior to purchasing. One of the biggest frustrations of a tool I have personally used is its inability to perform when multiple users are accessing the repository. Loading some projects will take 10 minutes or longer, while working in other projects completely freezes the tool. If at all possible, learn this before you buy! It will save you great frustration and keep analysts productive.

Never underestimate an employee’s need to resist change. It’s only natural. We all do it. Plan for it, accept it, and continue to communicate the benefits of the tool even when met with organizational resistance. Eventually people come around and the use of the tool will become a part of daily life within the organization.

Finally, learn from your experiences. Have an open mind and listen to the experiences of early adopters and implementation team members. Tout your successes and learn from your failures. Success will, undoubtedly, follow.

Renee Saint-Louis is a Senior Systems Analyst with a subsidiary of The Schwan Food Company where she established and led an Analyst Center of Excellence. Prior to joining Schwan, Renee served as the Requirements Elicitation Practice Lead at a large insurance company. Renee has been a practicing analyst for more than 10 years.

Tools of the Trade Part 1; Selecting a Requirements Management Tool

Written by Cynthia Low on April 7, 2009. Posted in Articles.

Have you ever experienced this? Management attends a trade show and discovers the greatest requirements tool since the bread slicer. It will solve all your requirement issues and produce happy, satisfied business customers – or so the vendor claims. The manager purchases the tool and suddenly it’s your job to implement it throughout the organization. “Go forth and do great things.” your manager mandates. You walk away dumbfounded wondering, “Where do I go from here?” Experience tells you there is more to it than just purchasing the software; some analysis is necessary in order to successfully launch a new tool at your organization.

This two-part series describes a tried and true approach to selecting and implementing a new requirements management tool within an organization. Based on experience implementing tools at several organizations, this first article describes a method to successfully prepare, plan, and select a new requirements tool. Part two will describe how to successfully implement the selected tool as well as some lessons learned along the way.

Assess Tool Readiness

“Assessing is theory, facts, and art form.”
~ Jim Murphy

Through my years of experience I’ve seen the obsession some organizations have with implementing a tool in order to enforce a loose, poorly followed requirements gathering process – believing that a tool will solve all of the requirements management issues in an organization. However, if poorly implemented, a tool will only exacerbate a poor or non-existent process and wreak havoc on the organization.

As an example, one organization had little to no requirements processes in place. Management was determined to implement a tool in order to enforce a process across the organization. Elaborate rules and regulations were devised by teams of people who were not requirements practitioners. These rules did little but enforce the nomenclature utilized within the tool. Little thought went into the intent of capturing requirements, determining stakeholder goals and needs, and managing requirements over the development lifecycle. What ensued was mass chaos throughout the analyst organization. Analysts were angry at the need to capture requirements in the tool, saw little value in the process, and out-right refused to utilize the tool. The result: the use of the tool was discontinued. Thousands of dollars were wasted on license fees, training, and implementation. Analyst productivity declined and there was a feeling of ill-will throughout the organization!

Don’t let this happen to you! Before embarking upon a tool implementation, one should begin by understanding what is expected from the tool and then assess the organizational readiness for a tool. This can be as formal or informal as needed for your organization. The point is to actually look at your organization, determine why a tool is necessary, and asses the readiness for adopting a tool.

Know the Theory

First, have a clear understanding of what the expectations are of the tool and what problems your organization is looking to solve by purchasing a tool. It is a good idea to attack this project with the same analysis skills you would a typical IT project. Begin by writing the vision statement and problem statements. These will give you a clear direction for selecting a tool and guide the team when rolling out the tool across the organization. Some points to consider:

Determine what pain points you are trying to eliminate by implementing a tool. For example:
- Problem: Requirements are captured in disparate Word documents and continually change without stakeholders being alerted.
  Solution: Providing a repository to house all requirements
- Problem: Once a project is launched, requirements are difficult to find and rationales for requirements are often forgotten.
  Solution: Providing a tool which captures discussion, rationale, and decisions for project requirements.
- Problem: Projects are routinely launched with major re-work after the implementation due to poorly defined requirements.
  Solution: Providing a tool which illustrates requirements in a manner meaningful to stakeholders – through models, screen mock-ups, use cases etc.
Determine what goal the organization is trying to achieve by implementing a tool. For example:
- Reduce the amount of money spent on re-work after a project is installed by generating models and written use cases from screen mock-ups to aid in eliciting higher quality requirements from stakeholders.
- Increase speed to market by creating prototypes and generating requirements based on the prototype.
Document what the vendor has promised (if one has been selected for you).

Get the Facts

The next step is to assess the readiness of your organization. Consider not only how it will impact the analysts, but also the other stakeholders involved. Some points to consider when assessing your organization:

Is a tool necessary?
What impact will implementing a tool have on the organization?
What development methodology is utilized by analyst groups? Is it the same across the organization or do some follow waterfall while others follow agile development processes?
How mature is the requirements process across all analyst groups?
1. Are some stronger than others?
2. Are processes similar across groups?
3. How disparate are processes across groups?
Are there additional organizational changes occurring that may impact a successful tool implementation?
1. If so, what is the time frame for implementation? Will it interfere with a tool implementation?
What format are requirements typically gathered in? (e.g. Word document, Excel, e-mail, napkins, hallway conversations, dreams)
What is the maturity of the PM, Development, and QA organizations?
How will the stakeholders perceive the change? Are they open to receiving requirements in a new format? Will the process be seamless to them?

During this exercise, capture the risks and issues that may occur if a tool is implemented. Record the response to the risks and issues so that they may be resolved during the tool rollout.

Remember that a tool is exactly that – just a tool. Its implementation will have significant impact on the organization and any tool that is selected needs to be thoughtfully considered and carefully planned.

Based on your assessment, it may be necessary to recommend deferring the purchase of a tool until any process issues are shored up. It is fundamentally necessary to have solid requirements practices in place before implementing a tool. Get your facts in order and make recommendations on how to improve your processes before a tool is implemented. For example, if documenting requirements is sketchy (at best) in your organization, recommend to management that all of IT, not just analysts, be trained in best practices for correctly documenting requirements within your software methodology. Training all of IT sets expectations on what is acceptable requirements deliverables and holds analysts accountable for producing quality requirements.

Create a plan for addressing the issues encountered during the assessment and recommend a time frame for improving the requirements practice, including an appropriate time for implementing a tool. Generally, management will appreciate a well thought out plan, rather than a haphazard approach to implementation.

Select a Tool

A fool with a tool is still a fool.
~Anonymous

Hopefully you find yourself in the situation where you and your team have the ability to evaluate and select a tool, rather than management dictating which tool you must use (or worse yet, one they have already purchased.) If you are able to select a tool, then you are in luck. If not, know that most tools on the market offer sufficient improvement over capturing requirements in an ad hoc manner that some benefit of implementing the tool will certainly follow.

When beginning the selection process, start with the problem statements that were created during the assessment phase. Any tool that is selected will need to address the pain points of your organization. This will help ground you as you begin your search, and keep you from being distracted by the many bells and whistles that companies offer. When it comes to selecting a tool, the most important criteria is that it addresses the pain points you are experiencing. Bells and whistles will only encumber your process rather than enhance it. At its most basic, a tool should enhance your existing process, not detract from it.

As a part of your selection process, determine the criteria which are most important and evaluate the tool according to these criteria. A simple spreadsheet that ranks the criteria for each candidate vendor will help in objectively evaluating a tool. Have each team member rank the features/needs for each vendor which are determined necessary for the tool to succeed at your organization. A scale from 1-10 may be used, where 1 is least favorable and 10 is most favorable. Do the same for the priority column and calculate the total value for the features, and in turn, the vendor’s product. Here is a sample:

Feature/Need	Product Ranking	Priority	Total Value
Integration with MS Word	3	7	21
Visual depiction of requirements	1	9	9
Traceability	4	8	32
Integration with development tools	3	2	6
Integration with test suite	4	3	12
Ability to define custom properties	5	1	5
		Vendor total:	85

Once you have narrowed the field down to a few choice vendors, evaluate the products thoroughly. The best way to do this is to try before you buy. If at all possible, negotiate a trial period with each vendor where you can put the tool to the test on a real project. The only true test to tell if the tool will work in your organization is to try it out in real life. No demo projects, no smoke and mirrors, just good old fashioned writing your own requirements in the tool in order to learn its quirks and limitations. This may add some extra time and produce some redundancy in your project documentation as you will want to continue to store whatever you produce within your own directories, but the small pain up front will alleviate pain on the back end once the tool is implemented. Complete the ranking process again once you have completed the trial run. This should produce a clear winner.

Next up: Implementing a tool without causing mass chaos in your organization.

Authoring Requirements in an Agile World

Written by Tony Higgins on March 31, 2009. Posted in Articles.

Equipping and Empowering the Modern BA

The principles of agile development were proven before agile – as a defined approach – became vogue. Agile principles were being practiced to varying degrees in most organizations as a natural reaction to the issues surrounding a rigid waterfall approach.

Every individual task on a software project carries some degree of risk. There are many sources of these risks – some third party component may not function as advertised, some module your work is dependent on may not be available on time, inputs to the task were ambiguous and you made an incorrect assumption when ‘filling in the blanks’, the list is endless. All these risks in the individual tasks contribute to the overall project risk and, quite simply, risk isn’t retired until the task is done. Putting it another way, the risk associated with building something is really only retired when the thing is built. That’s the principle behind iterative and incremental development.

So instead of leaving the first unveiling of a new or enhanced application until toward the end of the project, break it down so that pieces (functional pieces) can be built incrementally. While this doesn’t always mean the portions are complete and shippable, stakeholders can see them working and try them out. This offers several advantages: it retires risk, as mentioned before. It often also exposes other hidden risks. These risks will surface at some point, and the earlier the better. Exposing hidden risk and retiring risk early makes the estimating process more accurate. This increases the probability of delivering applications of value that address the business needs in terms of capability as well as budget and schedule needs.

While agile is becoming main stream on small and mid-sized projects, challenges do exist elsewhere such as how to manage this approach on larger projects and in distributed development. Another challenge for many is how to apply a requirements lifecycle to agile projects. Many agile principles such as “just enough and no more”, to “begin development before all requirements are complete”, to “test first”, can be counter-intuitive. Also, what about non-functional requirements? What about testing independence? How can we cost something if we don’t know what the requirements are?

This article attempts to describe some ways to handle these challenges. It is based on an example of real, ongoing, and very successful product development that uses agile with a globally distributed team. It describes one set of techniques that is known to work.

Process Overview

There are many “flavors” of agile, but at a high level they all essentially adhere to the following basic principles:

PRINCIPLE	DESCRIPTION
Iterative	Both Requirements and Software are developed in small iterations
Evolutionary	Incremental evolution of requirements and software Just Enough “requirements details”
Time-Boxed	Fixed duration for requirements and software build Iterations
Customer Driven	We actively engage our customers in feature prioritization We embrace change to requirements/software as we build them
Adaptive Planning	We expect planning to be wrong

Requirements details as well as macro level scope are expected to change as we progress through our release.

For the purposes of this article, our example uses a Scrum-based Agile process1. In this approach the iterations (sprints) are two weeks in duration. A sprint is a complete development cycle where the goal is to have built some demonstrable portion of the end application. It should be noted that while the initial sprints do involve building a portion of the application, often this is infrastructure-level software that’s needed to support features to be developed in later sprints. This means there may not be much for stakeholders to “see”.

Each organization needs to determine the sprint duration that’s optimal for them. It needs to be long enough to actually build something, but not long enough for people to become defocused and go off track (thereby wasting time and effort). We found two weeks to be optimal for our environment.

Key during the first part of the process is to determine and agree on project scope, also known as the “release backlog”. Determining the release backlog itself could be a series of sprints where the product owner and other stakeholders iterate through determining relative priority or value of features along with high level costing of these features to arrive at a release backlog.

At the other end of the project, development of new code doesn’t extend to the last day of the last sprint. We typically reserve the last few sprints, depending on the magnitude of the release, for stabilization. In other words, in the last few sprints only bug fixing is done, and no net new features are developed. This tends to go against the agile purists approach to software development as each sprint should, in theory, develop production ready code. However, to truly achieve that requires significant testing and build automation that most organizations don’t have in place. This is always a good goal to strive towards, but don’t expect to achieve this right away.

Requirements Definition in this Process

There are several ways you could perform requirements definition in an agile process, but again our goal is to introduce an example that’s been tried and is known to work. This example begins with the assumption that you already have a good sense of the “business need”, either inherently in the case of a small and cohesive group, or by having modeled the business processes and communicating in a way that all understand. So we begin at the level of defining requirements for the application.

Requirements at the Beginning

Begin with a high-level list of features. Each feature is prioritized by Product Management or Business Analysts (depending on your organization). These features are typically then decomposed to further elaborate and provide detail and are organized by folder groupings and by type. If needed to better communicate you should create low-fidelity mockups or sketches of user interfaces (or portions) and even high-level Use Cases or abstract scenarios to express user goals. We sometimes do these and sometimes not, depending on the nature of what’s being expressed plus considering the audience we’re communicating with. For example, if we’re communicating a fairly simple concept (how to select a flight) and our audience is familiar with the problem space (they’ve built flight reservation applications before) then clear textual statements may be “just enough” to meet our goals at this stage. These goals are to establish rough estimates (variance of 50-100%) and based on these and the priorities, to agree on the initial scope of the release (what features are in and which are out).

Once reviewed, this list of features becomes the release backlog. The features are then assigned to the first several sprints based on priority and development considerations.

Click image for larger view
Example High Level Features with Properties

Requirements During the Sprint

With respect to the requirements, the principle of “just enough” is paramount. If the need has been expressed to a degree adequate enough to communicate and have it built as intended, then you’re done. Going further provides no additional value. This means you’ll have a varying level of detail for the requirements across the breadth of the product. For some parts of the product a high-medium level of detail may be “just enough”, while for other more complex areas a very fine level of detail may be needed.

In each sprint there are tasks of every discipline taking place. Requirements, design, coding, integration, and testing tasks are all being performed concurrently for different aspects of the system. The requirements being defined in one sprint will drive design and coding in a subsequent sprint. The net effect is that all these disciplines are active in every sprint of the lifecycle, but the relative emphasis changes depending on what stage you’re at in the project. For example, requirements tasks are being performed in all sprints, but they are emphasized more in the earlier sprints.

In each sprint, the high level features are elaborated into greater levels of detail. This more detailed expression of the requirements usually begins with usage scenarios/stories and/or visuals and it’s expressed in the form of a model. The models can emphasize user interface, use cases, scenarios, business rules, and combinations of these, depending upon the nature of what is being expressed. Sometimes these are created collaboratively but more often in our experience, one person creates an initial version and then holds a review with others for feedback. In our case it is typically the product managers and/or business analysts who create these models and usually between one to three reviews are held with the developers, testers and other stake holders. The review serves multiple purposes including:

To facilitate knowledge transfer to all stakeholders including architects, UE designers, developers, testers, and executive sponsors on what is needed
To allow the architects, UE Designers and developers to assess feasibility
To determine if there is sufficient detail in the requirements to allow development to proceed

With appropriate technology, tests are automatically generated from the requirements producing tests that are 100% consistent with the requirements and enable the immediate testing of code developed during sprints.

Continuous and Adaptive Planning

With this approach planning is continuous and adaptive throughout the lifecycle allowing resources to be redirected depending on new discoveries that come to light during each sprint. This ability to course correct in mid-flight is what gives projects their “agility”. At the end of each sprint we take stock of what was achieved during the sprint and record progress actuals. The work of the next sprint is adjusted as necessary based on this but also based on testing results, feedback from reviews of that sprint’s build, any new risks or issues that surfaced or others that were retired, and also any external changes in business conditions. Estimates and priorities are adjusted accordingly and any changes to release scope and sprint plans are made. In general we try not to make major mid-flight corrections during a sprint, which is one of the reasons why we like two week sprints. If sprints were, say, four weeks then we would lose agility. Also a two week sprint is easier and more accurate to estimate than a four week one.

Click image for larger view
Example Story with Tasks, and Estimates

With respect to the requirements, for those features assigned to the sprint along with any high-level requirements models, development creates high-level goals for the particular feature and estimates them. The goals express what aspects of the feature they will attempt to build during that sprint, recognizing that one sprint is often not enough time to implement an entire feature. The feature and its high-level goals become the content of the “story”. Once the story is defined the developer then details and estimates the tasks to be done for that story over the next two weeks (sprint) and proceeds with development, tracking daily progress against these tasks in an agile project management tool, and covering issues in the daily scrum.

What about the Non-functional Requirements?

The various agile approaches have evolved several techniques to express system functionality. These are things like user stories, use cases, or usage scenarios, that represent “observable system behaviors and artifacts that deliver value to users” like screens, reports, rules, etc. These functional requirements express “what” the system is to do. Examples of this could be things like “generate a stock-level report”, “make a car reservation”, “register for a webinar”, or “withdraw cash”.

Associated with the functionality of a system are its “qualities”. These express “how well” the system is supposed to do what it does – how fast, how reliably, how usable, and so on. Sometimes these non-functional requirements are associated with certain functional requirements and other times they apply to whole portions of the system or the entire system. So how do these very important requirements get accounted for in our agile process?

They are expressed at the high-level in the form of textual statements. For example: “Any booking transaction shall be able to be completed by a user (as defined in section a) in less than three minutes, 95% of the time”.

As functional requirements are decomposed and derived any associated non-functional requirements should similarly be decomposed, derived, and associated to lower levels. For example the above performance requirement is associated with all the “booking transaction” functional requirements (book a car, book a flight, book a hotel). If the functional requirements are decomposed into the lower level requirements “select a car”, “choose rental options”, and “check-out”, then the non-functional requirement may similarly be decomposed into requirements for selecting a car in less than 30 seconds, choosing options in less than one minute, and checking out in less than 1.5 minutes.

During review sessions the functional requirements take center stage. However, during these reviews any non-functional requirements that are relevant need to be presented and reviewed as well. Traceability is usually relied on to identify them. Any non-functional requirements relevant to the functional requirements of the story need to be expressed as part of the story, so the developer can take these into account during development.

QA needs to create tests to validate all requirements, including the non-functional requirements. Sometimes before a feature has been completely implemented, non-functional requirements can be partially tested or tested for trending, but usually cannot be completely tested until the feature is completely implemented (which can take several sprints).

What about Testing?

The high degree of concurrency in agile processes means that testing is performed in every sprint of the lifecycle. This can be a considerable change from traditional approaches and offers several benefits. First, it tends to foster a much more collaborative environment as the testers are involved early. It also, of course, means that items which wouldn’t have been caught until later in the lifecycle are caught early when they can be fixed much more cheaply.

In agile, Product Owners play a very big role in the testing process and they do so throughout the development lifecycle. Whereas many traditional approaches often rely on requirements specifications as “proxies” of the product owners, agile places much more reliance directly on the product owner effectively bypassing many issues that can arise from imperfect specifications. In addition to the product owners, developers also test. Test-driven development is a prominent technique used by developers in agile approaches where tests are written up-front and serve to guide the application coding as well as performing automated testing, which helps with code stability. To augment test driven development, which is primarily focused at the code level testing done by developers, new technologies that can auto-generate functional tests from functional requirements enable a QA team to conduct functional testing based on test cases that are not “out of sync” with the requirements specification. This enables the QA team to conduct testing on a continuous basis, since executable code and test cases are available throughout the lifecycle. In our example, all three are employed – product owner, development staff, and independent QA – on a continuous basis.

The requirements that we develop in our example are a decomposition of high-level text statements augmented by more detailed requirements models that give a rich expression of what is to be built. Requirements reviews are based on simulations of these models and they are incredibly valuable for a number of reasons. First, just as agile provides huge benefit by producing working software each sprint that stakeholders can see and interact with, simulation lets stakeholders see and interact with ‘virtual’ working software even more frequently. Second, people often create prototypes today trying to do much the same thing. The difference with prototypes, however, is that simulation engines built for requirements definition are based on use cases or scenarios and, therefore, guide the stakeholders in how one will actually use the future application, providing structure and purpose to the requirements review sessions. Prototypes, including simple interactive user interface mock-ups, on the other hand, are simply partial systems that ‘exist’ and provide no guidance as to how they are intended to be used. Stakeholders have to try to discover this on their own and never know if they’re correct or if something has been missed. It is important to note that the principle of “just enough” still applies when producing these models. We rely on the requirements review sessions held with designers/developers to determine when it is “enough.” This approach produces very high quality requirements and it is from these requirements that the tests are automatically generated. In fact, such thorough testing at such a rapid pace without automatic test generation is likely not possible.

Although we strive to have shipable code at the end of each sprint, this goal is not always achieved, and we may need to use the last sprint or two to stabilize the code. Since testing has already been taking place continuously before these final sprints, the application is already of considerably high quality when entering the stabilization phase, meaning risk is manageable and rarely is ship date missed.

What about Estimating?

Remember in agile it is typically ‘time’ that is fixed in the triad of time, features, and quality. In our approach also remember that, with continuous testing and the reserving of the final sprints for stabilization, quality tends to be fairly well known as well. This leaves the features as variable so what we’re actually estimating is the feature set that will be shipped.

As always, the accuracy of estimates is a function of several factors but I’m going to focus on just three

The quality of the information you have to base estimates on,
The inherent risk in what you’re estimating, and
The availability of representative historical examples that you can draw from.

In our approach, estimates are made throughout the development cycle, beginning in the initial scoping sprints. As mentioned earlier, once the list of candidate features is known and expressed at a high (scoping) level, they are estimated. Naturally at this point the estimates are going to be at their most “inaccurate” for the project lifecycle, since the requirements have not been decomposed to a detailed level (quality of information). This mean there is significant risk remaining in the work to be done. Similar projects done in the past may help mitigate some of this risk and help increase the accuracy of the estimates (e.g. we’ve done ten projects just like this and they were fairly consistent in their results).

The initial estimates are key inputs to the scoping and sprint-planning processes. As the project proceeds, with each sprint risks are exposed and dealt with, requirements are decomposed to finer levels of detail, and estimates naturally become more accurate. As you might guess, estimation is done toward the end of each sprint and is used in the planning of future sprints.

What about Distributed Teams?

Today distributed development is the norm. For reasons of efficiency, cost reduction, skills augmentation, or capacity relief, distributed development and outsourcing is a fact of life. There’s no free lunch however – there are costs associated with this approach, and much of these costs are borne in the requirements lifecycle. Chief among these is “communication”. There are practices and technologies that can mitigate this issue, so that the promised benefits of distributed development can be realized. The approach in this we’ve looked at here, for example, uses the following and has been very successful:

Concerted effort for more frequent communication (daily scrums, and other scheduled daily calls)
Liberal use of requirements simulation via web-meeting technology
Direct access to shared requirements models via a central server
Automated generation of tests and reviewing these in concert with the requirements to prove another perspective of what the product needs to provide.

Conclusion

“Have you heard that England is changing their traffic system to drive on the right-hand side of the road? But to ease the transition they’ve decided to phase it in – they’ll start with trucks”.

A common mistake of development organizations making the shift from waterfall to agile is that their organization mandates they still produce their big, heavy set of documents and have them reviewed at the same milestones, clinging to these familiar assets like security blankets. It doesn’t work. As scary as it might seem all significant aspects of the approach, like documentation, need to change in unison if it’s to be successful, and requirements are one of those significant aspects.

However if you still want that security blanket and you want to have some benefit of agile, at least generate your requirements specification in an agile manner (iterative, evolutionary, time boxed, customer driven, adaptive planning) that includes simulations integrated and driven by use cases traced to feature. This is one way to reap some agile benefits without making the leap all at once.

Risk is the ‘enemy’ on software projects. High risk profiles on projects drive uncertainty, render estimates inaccurate, and can upset the best of plans. One of the great things about agile is that its highly iterative nature continually ‘turns over the rocks’ to expose risk early and often so it can be dealt with.

On the other hand, one of the great challenges for larger and distributed teams is keeping everyone aligned as course-corrections happen sprint by sprint. A big part of this is the time and effort it takes to produce and update assets and the delays caused by imperfect and strained communication. The good news is that tools and technologies now exist to produce many of the assets automatically, and to also dramatically improve communication effectiveness, allowing agile to scale.

With the right approach, techniques and technology, distributed agile can be done. We’ve done it. So can you.

Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].

References

1 The Scrum Alliance http://www.scrumalliance.org/

2 Approaches to Defining Requirements within Agile Teams
Martin Crisp, Retrieved 21 Feb 2009 from Search Software Quality, http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310960,00.html

3 Beyond Functional Requirements on Agile Projects
Scott Ambler, Retrieved 22 Feb 2009 from Dr.Dobb’s Portal, www.ddj.com/architect/196603549

4 Agile Requirements Modeling
Scott Ambler, Retrieved 22 Feb 2009 from Agile Modeling, http://www.agilemodeling.com/essays/agileRequirements.htm

5 10 Key Principles of Agile Software Development
Retrieved 22 Feb 2009 from All About Agile, http://www.agile-software-development.com/2007/02/10-things-you-need-to-know-about-agile.html

6 Agile Requirements Methods
Dean Leffingwell, July 2002, The Rational Edge

7 Requirements Honesty
Francisco A.C. Pinheiro, Universidade de Brasilia

8 Requirements Documents that Win the Race
Kirstin Kohler & Barbara Paech, Fraunhofer IESE, Germany

9 Engineering of Unstable Requirements using Agile Methods
James E. Tomayko, Carnegie Mellon University

10 Complementing XP with Requirements Negotiation
Paul Grunbacher & Christian Hofer, Johannes Kepler University, Austria

11 Just in Time Requirements Analysis – The Engine that Drives the Planning Game
Michael Lee, Kuvera Enterprise Solutions Inc., Boulder, CO. 03/09

Seven Tips to Ensure Requirements Management Success

Written by Cynthia Low on March 24, 2009. Posted in Articles.

The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software. Software operates the cars we drive, the planes we fly in, the cell phones we can’t live without and the tools we use every day to get our jobs done. Software is everywhere.

As a software professional, you know all too well that software development isn’t easy. A software product is never completed. There’s always an opportunity to improve functionality and there’s no shortage of challenges to overcome along the way:

Lots of people involved in the process
Customers have difficulty articulating their real needs
Requirements constantly change
Teams are spread across multiple geographies
There’s growing pressure to release products faster
The complexity of software doubles every 2-3 years
More projects fail than succeed

Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success. And, the path to building great software goes through requirements management. Organizations that embrace this concept enjoy greater results. They experience fewer errors and frustration, faster planning and development cycles and they’re able to deliver higher quality products to their customers.

What You’ll Learn: The goal of this article is to provide you seven essential tips to help you be more successful with requirements management. For some, these tips might be new. For others, these tips will serve as a good reminder of the fundamentals that are easy to lose sight of during the heat of a project.

Tip #1. Stay Connected

You can eliminate most issues by keeping everyone connected.

Much attention is placed on the high failure rates of software projects, and for good reason. Any time there’s billions of dollars at stake and failure rates ranging between 60%-80%, people are going to pay attention. But, what you don’t hear as much about is the root cause. Last year, in The State of Requirements Management Report we polled over 200 professionals about the top challenges they faced in eliminating project failure, and the resounding theme boiled down to one thing – communication. If you can get connected and stay connected throughout the entire development process, you can eliminate the vast majority of issues.

Terminology	Simple Definition
Collaboration	Keeping your entire team connected throughout the development process
Traceability	Keeping all the requirements, artifacts and other related information connected

There are two parts to staying connected. First, there’s the connectedness of your team, which has been popularized recently as “collaboration” – new buzzword, same meaning. Analysts, project managers, developers, testers, product managers, executives, stakeholders and customers – is everyone on the same page about what you’re building and why?

Keeping everyone connected is often easier said than done, but it’s absolutely critical to the success of your project. Depending on the size and location of your team, you can do this manually through meetings, phone calls and documents or you can use a tool to help keep your team connected. It depends on your situation and the complexity of what you’re building. See Tip #7 for the tipping points when a tool might be valuable.

Second, there’s traceability – the act of connecting up the requirements and other artifacts such as use cases, test cases, tasks, defects and even user documentation – all the details that are related to each other within a project. For complex development projects, there can easily be hundreds or thousands of items involved and it’s critical to establish the traceability relationships between these items – both upstream and downstream.

For example, when a high-level business requirement changes 30 days into a project, through trace relationships you can immediately assess the impact it has on any downstream functional requirements, tasks and defects that a developer or tester might be working on. This helps minimize errors and costly rework because the team members affected are aware of the specific change and its impact.

Implementing traceability and a change control process that’s appropriate for your situation is one of the most important steps to ensuring success. As a simple first step to establishing change control, you can use a change request form manually to document changes right now.

Tip #2. Take Action Now

Don’t wait for your process to be “perfect.”

Doing something is better than nothing. It’s easy to fall victim to what you might call “process perfectitis” – a condition reached by teams that get paralyzed by process and analysis versus delivering working software. How many times have you heard someone say, “Well, we’ll get to that project as soon as we really lock down our process? ” Is any process perfect? More importantly, should that really be your team’s highest goal?

Whether your team is practicing some flavor of Agile or not, there’s one thing we can all take away from the principles of Agile – it’s that working software is the primary measure of progress. Don’t get us wrong, optimizing your process is important, very important. We’re constantly tweaking our process. However, if you have a better process and no product, you still have nothing to show your customers.

Doing something is better than nothing. Start small, identify a few critical requirements and take the approach of continuous improvement where you build, reflect, refine and repeat. Then, with each release cycle you’ll learn more about the needs of your customers and continuously improve and expand upon the software solution you deliver to them. If you think your team suffers from process perfectitis, look for these symptoms:

•· Requirements definition phase seems to drag on and on and on

•· In the last month more time when spent talking about process, while your product stayed the same

•· Lack of a decision-maker to make the call when to move forward with development

Tip #3. Eliminate Ambiguity

Successful requirements management begins with writing good requirements.

One of the things you can do immediately is make a “do not use” word list and post it up on the walls in your office. Visual reminders will help you to avoid using ambiguous terms when writing requirements. Karl Wiegers, a well-respected requirements management consultant, in his book Software Requirements provides a good list of ambiguous terms to avoid in requirements specifications. Here’s a snapshot of a few them.

Ambiguous Terms	Ways to Improve Them
fast	Specify the minimum acceptable speed which the system performs some action.
flexible	Describe the ways in which the system must change in response to changing conditions or business needs.
acceptable, adequate	Define what constitutes acceptability and how the system can judge this.
simple, easy	Describe system characteristics that will achieve the customer’s needs and usability expectations.
shouldn’t	Try to state requirements as positives, describing what the system will do, instead of what it won’t do.
robust	Define how the system is to handle exceptions and respond to unexpected operating conditions.

Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

Tip #4. Reconnect with Your Customer

You don’t have to be an expert to capture the voice of your customer – just committed.

This may sound obvious, but it’s easy to lose sight of customer needs as a project gets underway and the team gets to work building the solution. Keep in mind, we use the word “customers” to refer the end-users of the product you’re building – these customers could be external consumers for commercial products or internal users in the case of internal IT systems where other departments and employees are your customers.

Capturing the voice of the customer isn’t a one-time effort. Most project teams do a thorough requirements gathering session at the beginning of a project, but rarely does the customer interaction carry through to the end. Successful requirements management practices include constant communication with customers. Otherwise you risk falling into the classic trap of delivering a product that end-users reject because it doesn’t resonate with how they expect to use it.

There’s definitely an art to eliciting feedback and requirements from customers and clearly some people are better at it than others. There’s a plethora of books and courses out there to provide training for this specific skill. However, you don’t need to be a requirements management expert to capture the voice of your customers. The fundamental skill required is commitment. Commit to picking up the phone every week and talking to customers. Commit to getting out of your office and sitting down with customers in their real environments. These are things everyone on the team can do, and should do. Even in Agile it’s not always possible to have an on-site customer present, so you have to commit to getting that feedback other ways.

Here’s a quick list of Dos and Don’ts to follow as reminders for how to stay connected to your customers.

Dos	Don’ts
Be a journalist – ask open-ended questions	Think you know best what customers want
Talk to your customers every week	Assume past experience is representative of current needs
Be open and flexible to change	Assume customer needs are static
Just pick up the phone and call customers	Elicit requirements & feedback only at the start of a project
Listen with an open mind during elicitation	Sell customer on your idea for how a solution should work
Sit with a customer and watch how they work	Assume customers know how to articulate their exact needs
Close the loop with customers when their feedback has been implemented in the product	Forget to capture and share the evidence you gather with your team

Tip #5. Prioritize Objectively

Avoid building functionality that customers don’t need and may never use.

Development time is so valuable. There’s nothing more frustrating for everyone than wasting time building features that customers don’t actually use and don’t provide value back to your company.

This is where requirements prioritization is essential. You need to avoid the common pitfalls of building features that seem cool or that someone thought a customer might need. Too often, requirements prioritization happens subjectively. The team holds a meeting and in a debate over the requirements the loudest voice wins; or a request comes in from a salesperson who just spoke to a customer and the most top-of-mind request becomes the hottest priority du jour. With each new feature request or high-level requirement, ask these questions to determine if this is a must-have or a nice-to-have feature:

What percentage of our customers will benefit from it?
Does it fit our brand values and enhance a competitive differentiator?
What is the trade-off if we prioritize this ahead of other requirements?

It’s best to establish an objective prioritization model that quantifies the variables that matter most and that each high-level requirement gets evaluated against. That way, by getting agreement on the scoring model, it’s easier to get consensus on the highest priority requirements your team should focus on, objectively.

Tip #6. Minimize Overhead Select the right tools to get the job done.

If you’re a small team in the same office developing a fairly straight-forward product, you can use a whiteboard, task cards and daily face-to-face meetings to manage requirements. A specialized tool in this case could create unnecessary overhead. Likewise, if your team is building a product where the requirements are all agreed upon upfront and won’t change much throughout the course of development, then documents and periodic status meetings may work just fine.

As projects grow in complexity and teams grow in size and geography, so do the communication challenges and overhead of trying to keep everyone and everything in sync. It’s in these scenarios, where a requirements management tool can add value because the overhead of using the tool is far less than the manual overhead it takes to keep track of changes, manage trace relationships, update documents and communicate with everyone on the team.

Here’s a checklist of a few common tipping points where a specialized tool makes sense and can help reduce overhead by automating the process of keeping people and all the related information connected.

Variable	Tipping Point	Benchmarks
Complexity	The more complex the project, the greater the need. If you have over 100 requirements.	72% of teams have projects that on average have 100+ requirements.
Team Size	The bigger the team, the greater the need. If you have over 25 people involved.	Over 40% of teams have at least 25 members and stakeholders.
Location	The more geographically distributed the team, the greater the need. If 10%+ are virtual.	Over 60% of teams have at least 10% of their team working in different locations.
Change	The more changes, the greater the need. If you spend 10% or more of your time managing changes to requirements.	Over two-thirds of teams spend 10% or more of their time managing change.
Traceability	If traceability is a priority for meeting standards or government regulation, a tool is valuable for automating the management of trace relationships, change control and version history.

Benchmarks: The State of Requirements Management Report by Jama Software and Ravenflow, 2008

Tip #7. Don’t Reinvent the Wheel There are many existing templates and resources you can leverage right away.

Even though every company, project and team is unique, the resources needed to help you be successful, in most cases, already exist. In minutes you can do a search on Google and find a wealth of best practices information. As a starting point, here’s a link to more resources from Jama Software and Karl Wiegers for free companion resources to this article: http://www.jamasoftware.com/requirements_management_resources.php

Eric Winquist is CEO and founder of Jama Software. In March 2006, Eric founded Jama with the vision of providing customers a more collaborative way to develop new products and eliminate the common frustrations with traditional approaches to requirements management. Eric is an accomplished entrepreneur, business analyst and project manager with over 14 years experience working with a wide range of organizations. Previous to Jama, Eric founded Redside Solutions, a software development consulting firm.

John Simpson is director of customer outreach, Jama Software. John represents the voice of the customer and leads Jama’s product strategy and communications. John has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. He has contributed to several books, whitepapers and presentations.

They can both be reached through the following: 503.922.1058 [email protected] I www.jamasoftware.com 3/09

Real Reuse for Requirements

Written by Cynthia Low on March 9, 2009. Posted in Articles. 2 Comments on Real Reuse for Requirements

A telecommunications company in a hotly competitive market needs to deliver the next generation of cell phone to its customers quickly, and at the lowest possible cost. The company wants to adopt a baseline set of requirements for the next generation project, but must make necessary modifications to leap ahead of the competition.

An automotive supplier must produce embedded software components consistently and reliably for its OEM clients. To do so, the supplier’s development process must account for the slight variations required by each manufacturer.

Requirements reuse provides organizations, like those illustrated in the scenarios above, with the unique ability to share a requirement across projects without absorbing unnecessary duplication of artifacts within a repository. This is a critical capability that accelerates time to market and cuts development costs. Shared requirements can either track to the ongoing change made by the author or they can remain static if the needs of the project dictate. Further, change to a shared requirement can be made by anyone and the system handles the branching and evolution of that requirement appropriately.

The concept of reuse is a familiar notion within the software development realm, but less common when considered in the field of requirements management. There are various definitions and use cases which must be taken into consideration when implementing a solution to address requirements reuse.

This whitepaper discusses the elements that make up a requirement and establishes common understanding of how requirements evolve, how that evolution is retained, and how organizations can reuse requirements to speed business innovation, reduce complexity and control costs.

Dissecting a Requirement

To understand the concept of requirements reuse, we must first look at the various parts of a requirement: data, metadata and relationships.

Data
Describes an object, and is relevant to the object itself. An example of data may be a summary or description of a requirement.

Metadata
This is data about the data, which aids in organizing or using the object within a process. It typically describes the current state of the object, and has the same scope as the data itself. For instance, metadata may describe the State/Stage within a requirement workflow (i.e., Approved, Rejected, Satisfied, and Tested).

Relationships
This characteristic of a requirement allows you to model:

structure (i.e., Consists Of, Includes);
history (i.e., Revision Of, Derived From);
conceptual links or traces (i.e., Satisfies);
references (i.e., Defined By, Decomposes To);
security (i.e., Authorized By, Enables).

Any given requirement can have information in each of the data, metadata and relationships categories. When requirements are reused, any or all of the information can also be reused.

An organization’s chosen requirements management tool needs to have an underlying architecture and the user capabilities that support the strategic level of reuse dictated by the demands of the organization. Since reuse can occur at a number of different levels by leveraging the data, metadata and relationship elements of a requirement, flexibility is also critical to solving the reuse challenge.

History, Versions and Baselines

When implementing a complex reuse scenario, or even a system where requirements persist release after release, one must be able to identify significant points in that requirement’s evolution. In the development world, these significant points are called “versions.” This term may mean different things to different people, so we will begin with a definition of the term “version” as it applies to requirements reuse and show how it relates to similar terms like history, baselines and milestones.

Consider a system where requirements are captured within requirements documents but are stored as individual items within the repository.

History is the term used to describe the audit trail for an individual item or requirement. All changes made to the item, whether it is to data, metadata or its relationships are captured in its history. History answers to the who, when and what questions with respect to changes to that item.

Version represents a meaningful point in an individual item’s history. Not all changes to an item are significant and warrant a new version of the item. For example, the reassignment of a requirement from Nigel to Julia would not require a specific version identifier. The change is recorded to the item’s history, but a new version is not created.

Baseline is a very similar concept to version but has a much different scope. Individual items are often organized into groups or sets. In the requirements management domain these sets are called documents and a baseline is a meaningful point in a document’s history. Some organizations use a slightly different definition for baseline. Rather than being a snapshot in time for a given document, a baseline, as defined here in the context of requirements reuse, is a goal to work towards. For the purposes of this discussion we will call the goal-oriented baseline a milestone in order to distinguish between the two.

Requirements management claims to allow for the versioning of individual requirements. Many tools support versioning by way of cloning or copying the entire requirement. Even fewer solutions relate the copy to the original requirement.

Although related, versioning and reuse are not the same. The concepts of versioning are often confused with that of reuse. In the next section, we will explore various reuse scenarios to illustrate the differences (and the benefits) of versioning and reuse.

Reuse or Not Reuse? – The Many Flavors of Requirements Reuse

Requirements Reuse without Reuse – Share

The ability to share an item between projects, documents or other work efforts could be considered a form of reuse. Under this definition all of the projects that are sharing the item see, and can possibly even contribute to, the evolution of the item. The metadata on the item is shared as are all the relationships and the data.

This is not real reuse. I question whether to call this reuse at all, but it is included here for completeness.

Requirements Reuse without Heritage – Copy

As mentioned previously, copying an object from one place to another can also be considered a form of reuse. In fact, this is the form of reuse that Microsoft Word (or any other non-Requirements Management tool) supports. When an analyst opens a document, selects some content and performs a copy/paste gesture into another document, they are reusing that content for a new purpose. This form of reuse has no knowledge of heritage or “where did I come from” and of course changes in one document have no impact on changes in the other. In fact, changes are completely independent and one document has no knowledge that change occurred in the other, let alone what the change might have been.

This is also not real reuse. Any flavor of reuse must minimally include a pointer to where the original content came from.

Requirements Reuse with Heritage

Given the above scenarios, let us assume you can answer the “where did I come from” question. Augmenting the copy with the pointer back to its origin provides several options for reuse. It is the manner in which this link is leveraged that will differentiate each of the following reuse models. Most RM tools available today have some notion of links or relationships – if not at the individual requirement level, at the document level. Document level links are better than nothing, but they are not very powerful. In the long run, they don’t really answer the traceability question in sufficient detail to be meaningful.

Having a link to an item’s origin is the start of real reuse though it is certainly not the end.

Requirements Reuse with Change Notification

In this situation, a requirement and all related information (data, metadata and relationships), is reused in its entirety. Project state determines the state of the requirements at the time of reuse, and any change to requirements in a reuse scenario causes a ripple effect, flagging all artifacts related to those requirements as suspect.

Requirements Reuse with Change Control

Reuse with Change Control is similar to Reuse with Change Notification in that data, metadata and relationships are reused in their entirety. This seems, and in fact is, the same as the Share topic discussed above, however, there is one significant difference; the two projects sharing the same requirement only share it until the point in time where one project needs to change it. When the information changes a new version/branch is created and only items referencing that new version are declared suspect. All other projects or documents are unaffected.

Requirements Reuse with Annotations

In the two reuse paradigms above, the requirements and related information (data, metadata, and relationships) are reused in their entirety. In Reuse with Annotations, only some of the information belonging to a requirement is identified as a candidate for sharing and reuse. The rest of the information is specific to the project or document. The shared information is held in the repository while the other information belongs to the project or document reference. Each instance of the requirement being reused has its own metadata and relationships. The project or document state is, or can be, independent of the state of the requirements that are contained within it. New versions of the requirement are automatically created when the shared information in the repository is changed. These changes that trigger new revisions can suspect other references, as well as other items in the system, by the ripple effect of that change. For example, changes to requirements may affect test cases or functional specifications downstream.

Once you have project or document independence in terms of the metadata, you have the ability to model both a dynamic (share) and static (reuse) form of reuse at the same time. The project manager or analyst decides if they want to remain consistent with the evolving requirement in a dynamic way or if they want to lock the requirement down such that the impact of change does not affect their project.

Requirements Reuse with Annotations and Change Management

Applying change and configuration management paradigms onto the requirements management discipline in a single integrated and traceable solution can bring the power of reuse to a new level. By incorporating a process on top of reuse and controlling how and when requirements can be modified and reused enables you to reap these benefits without unnecessarily branching and versioning objects unless it is authorized and appropriate to do so. Requests for Change (RFCs) come in, get filtered and are directed by various review boards. Some of these RFCs get approved and assigned to users to affect the requested changes. Ideally, this change management process can define what types of changes can be made; whether it is modification, branching, applying a baseline or other gestures. Only when an approved RFC is associated with a requirement can an analyst modify the requirement, causing the system to version and branch accordingly, and notifying the related constituents appropriately.

There are clearly, additional reuse models that are not described herein – Component level reuse, documents reuse and various combinations of these with annotations and change management for example. This paper provides only a sampling. The business needs and strategic goals within the group, business unit or business as a whole will help determine which model is most effective for the project or organization.

Is Requirements Reuse Right For Your Organization?

Requirements reuse is not for everyone. There is a broad spectrum of need in terms of requirements management tooling in the market today, and organizations first need to know where they lie on the requirements maturity curve.

¹ The requirements maturity curve is not really a curve at all but a measurement of the current process and tools used and/or needed within an organization when it comes to requirements management. As organizations evolve along the curve, the need for more capabilities – such as change management, process and workflow, traceability, reuse, etc. – within their requirements management framework exists.

Many companies are still in the infancy of requirements management. They have not yet adopted a requirements management tool, and are currently using business productivity applications such as Microsoft Word or Microsoft Excel to capture and track requirements. They may look for capabilities such as ease of document import, rich text support, and downstream traceability to ease business adoption. These organizations are not yet at a point of requirements sophistication where reuse support is necessary – or maybe they are but have not found a tool to support their needs.

However, if an organization has progressed on the maturity curve with respect to requirements management, and is managing multiple projects and thousands of requirements in parallel and seeking to reduce complexity, lower cost of development, and shorten innovation cycles, then requirements reuse is a concept that should be investigated.

Let’s face it, regardless of where an organization falls on the curve, reuse in its most basic form will provide a boost to productivity. Rather than re-writing requirements, copy them and modify them for the needs of each project – you will save keystrokes as well as leverage the structure and organization these requirements were managed under in the past. After all, how many different ways can the requirements for logging in to an application be specified really? Ok, likely quite a number, but within any one organization the need to standardize and streamline application access exists and leveraging requirements from one application to another to provide this similar type of functionality can only be a good thing™ (Martha Stewart).

In any case, concentrate on the problem domain before jumping into the question “is requirements reuse right for me?” What challenges is the organization facing in terms of requirements management? Here is a list of sample questions an organization can ask to determine if reuse is a concept that could be leveraged and if it is, which flavor of reuse is best suited to the need.

Doug Akers is a Product Manager at MKS Inc., (www.mks.com) the global application lifecycle management (ALM) technology leader, that enables software engineering and IT organizations to seamlessly manage their worldwide software development activities. through a single enterprise application, resulting in better global collaboration and higher roductivity. MKS supports customers worldwide with offices across North America, Europe and Asia. Doug Akers can be reached at [email protected]