Tag: BABOK

Be Expressive – Improve the Clarity of Your Requirements

Written by Tony Higgins on October 6, 2009. Posted in Articles.

Click on all images to enlarge

Make Sure Everyone’s on the Same Page

If you were somehow able to hold a requirement in your hand and ask, “Why do I need this? What is its purpose?” I would offer that you’re holding an agreement. A requirement is how two (or more) people have chosen to express their agreement regarding what is needed from a software application. The assumption is that all parties have the same understanding or interpretation of these written words. Quite often this assumption proves to be false – different stakeholders in fact have different ideas in their minds regarding these same words, and confidently think that others share their vision as they warmly smile and shake hands over the agreement. If only we could have a “Vulcan mind-meld” ala Star Trek, a lot of our requirements issues would be gone.

These issues are possible with each and every written requirement. When you multiply this by hundreds, or sometimes thousands, of requirements and then consider how the requirements must combine to paint a picture of the whole solution, it’s quite understandable why there can be so many surprises in the latter parts of a software project.

The fundamental problem is that traditional legal-type textual requirements are simply not very expressive, which tends to leave a lot open to interpretation. Very often, requirements authors attempt to compensate for this lack of clarity by adding even more legal-style text to elaborate and constrain what they’re trying to communicate. Sometimes this can lessen the range of interpretation as desired; but just as often, it can actually do the opposite, as these new words themselves may contain ambiguities, inconsistencies, or redundancies. These additional words are added to areas where misinterpretation has been detected. But what about all the hidden areas of misinterpretation that have yet to be detected? They simply remain hidden, lying in wait to rear their heads later on in the development cycle.

Stakeholders directly involved in defining the requirements through elicitation, authoring, or review, have the benefit of sometimes hours of discussion and debate that go into formulating the requirements. This rudimentary form of Vulcan Mind-Meld is really quite valuable in avoiding misinterpretation of the written requirement. But what of the requirements consumers who did not have a seat at the definition table, and didn’t have the benefit of all this undocumented communication? It is crucial that developers, testers, outsourcers, sub-contractors, and others who consume requirements understand what they are being asked to build, test and manage. The risk of requirements miscommunication among these key individuals is magnified, since they’re even more likely to misinterpret the original intent.

So in addition to serving as an agreement between parties, the requirements have another key purpose: to communicate what is needed completely, precisely, and unambiguously to others who may not have been intimately involved in their definition.

Have you ever noticed what someone does when they’re having difficulty communicating a thought or concept? They become animated. They start using their hands. They make sketches on the whiteboard. They start pointing at the computer screen and say things like “so imagine this”. In short, they reach out for other, more expressive forms of communication. As they do this, they often expose other areas of misconception or misunderstanding. One by one they tackle these new areas, again with various forms of expression. The same is true with requirements. Increasing the expressiveness of your requirements actually exposes additional areas of miscommunication you never knew were there – in other words, areas where you need to be even more expressive. This effect can be very powerful, and can help to raise the quality of requirements dramatically.

Some go so far as to replace textual statements altogether in favor of other more expressive forms of specification. Personally, I’ve found a combination of the two offers the best solution, and this is the approach I’ll describe.

Setting Context

Software requirements express what is required of the application in order to fulfill some higher-level business need. Requirements could describe how to provide customers with an online flight booking capability to fulfill the business need of increased sales for the airline, or how to withdraw cash to fulfill my business need of going to a movie. Regardless, this business need must be expressed along with the associated business process so that this world in which the software application will function is:

Understood by all team members, and
Used as a reference for the project to ensure it stays focused on addressing the business need.

This business context can be expressed as a combination of textual statements with a set of business process diagrams. The textual statements can be categorized according to an appropriate taxonomy (e.g. business need, business goal, business objective, business rule, business requirement, etc). There are various taxonomies in use, and I won’t use this forum to debate their merits. Business processes are best expressed using business process diagrams. There are numerous notations in use for this, from fill-blown Business Process Modeling Notation (BPMN), with its plethora of symbols, to very light-weight notations suitable for sketching processes. Since the purpose of the diagrams is to simply provide context for the software requirements – we’re not trying to re-engineer the business – I generally opt for the simpler notations. All I look for is ability to support:

Roles. In other words, who is performing the activity? This is commonly represented using swimlanes.
Activities. The tasks performed by the role.
Decisions. The ability to identify the decisions made by the roles and to specify associated conditions.
Start & End. Clear notation of where the process begins and ends, with ability to specify any pre or post conditions.
Nesting. The ability to abstract or “nest” portions of a process and denote it with a special symbol.
Free Form Notes. The ability to add unrestricted notes (i.e. text of any size and position).

I’ve found with these essentials, I’m able to illustrate most processes, and in the odd case where I can’t, I simply augment with notes.

The business need and the process, as you can imagine, are related. In areas where the relationship between the two is noteworthy or illustrative, it makes sense to somehow maintain this relationship via a traceability relationship using whatever requirements tool/platform you have. Conceptually, the context may therefore appear as in Figure 1.

Figure 1 Business Context

Generally, I ensure the business needs are exhaustive in terms of breadth – meaning if there’s a need, I want it to be specified. On the other hand, I selectively apply business process diagrams in areas where the process is business-critical, high-risk, or complex. This is admittedly a fairly simple approach, but I find it adequate in a surprisingly large number of situations. Of course, it can be extended where necessary.

Defining Expressive Requirements

As with the business context, I typically begin with textual statements describing application requirements. I mostly use a categorization scheme and traceability espoused by Rational Unified Process (RUP), which originated at HP, grouping requirements into five main categories: Functional, Usability, Reliability, Performance, and Supportability. Each of these has numerous sub-categories which some people use and others don’t. Another popular approach is that promoted by Karl Weigers in his book Software Requirements. This approach arranges User Requirements, Business Rules, Quality Attributes, System Requirements, Functional Requirements, External Interfaces, and Constraints into a hierarchical traceability strategy. As with categorization of business needs, there are numerous taxonomies for categorizing software requirements, along with many strategies for tracing the relationships among them. You need to decide on one that’s appropriate for you. Regardless, this is simply a way to organize your textual statements, and does little to improve their expressiveness.

Example legal-style text requirements list:

The system shall allow the user to book a flight
The system shall allow the user to choose the departure and destination airport
The system shall allow the user to specify multiple passengers
The system shall allow the user to specify for each passenger whether they are an adult, senior, or child.
The system shall allow the user to select either a one-way flight or a round-trip.

One of the most popular ways to improve expressiveness is to think like a user and imagine how they’d use an application. User stories are one way to do this. Another is use cases, which I’ll discuss briefly here.

Instead of a list of capabilities or features to be provided by the application, use cases describe the various scenarios of how the application will be used to accomplish some goal. As an example, imagine an online airline application for booking flights and other common traveler functions. Consider a couple of scenarios:

Book a round-trip from Dallas to Chicago for two adults
Book a one-way flight from Toronto to Atlanta for one adult, and one senior

These are different scenarios and will likely entail some different requirements. For example, in the first scenario, we actually have to handle two flights instead of one, because it’s a round-trip. In the second, there may be special requirements for seniors and perhaps senior discounts involved. Furthermore, the second example is an international flight, so there are likely some special requirements around that as well. However, you can look at these two scenarios, and probably think up several more, which are all variants of Booking a Flight, the goal of the user. To describe these various scenarios, we would create a use case called Book a Flight, and within it stipulate in detail how flights get booked. We do this in a dialog style such as …

Step 1. User chooses to book a flight

Step 2. System allows user to choose one-way or round-trip

Step 3. User chooses round-trip

Step 4. System allows user to specify departure location and destination

Step 5. User chooses departure location and destination

Step 6. System allows user to specify number and type of travelers as adult, child, or senior

Step 7. Etc.

Figure 2 Sample Use Case Steps

This is a quite different style than the legal-style text list shown earlier. This dialog describes the same functionality, but from an alternative perspective and style. Just having this alternative vantage point can itself shed new light on the requirements, help communicate what is truly needed, and help expose hidden issues. I would further argue that this form is more expressive than the legal-style text list. First, it is from the perspective of the user, which will allow existing and future end-users to consume it more readily. Further, notice that each statement makes sense only in context of those around it. If you move Step 4 to the end of the list, it will make no sense. In this style, it is quite easy to spot when things are missing or out of place, thereby ensuring completeness and integrity of the requirements.

Take a look at the requirements for an application screen below:

The screen must allow users to select meals for optional purchase
The screen must allow the user to purchase up to three extra luggage pieces
The screen must allow for the display of six different meals
The screen must display the totals of any and all optional purchases
The user must be able to select and re-select any options on the screen as many times as desired before submitting
The screen must prominently display the standard luggage allowance
The screen will inform the user at all times that their credit card used for ticket purchase will be billed for optional meal purchases
The screen must prominently display the price for meals

These are just a few of the requirements that could be specified for a particular screen. These requirements don’t even get into the various constraints on layouts and appearance that are commonplace when specifying screens.

Also notice the use case steps shown earlier in figure 2. The system steps describe many things that the screen will need to support.

Instead of relying exclusively on interpretation of this written text, what tends to be far more effective is to provide a screen mockup as shown below.

Figure 3 GUI Mockup

While some requirements authors dispense with the written requirement entirely, most generally favor maintaining some combination of textual statements and screen mockups.

A picture definitely is worth a thousand words, and this approach to visualizing what’s needed is indeed quite powerful. Supported by various visual requirements tools available today, there are some very effective approaches in practice. Just a sampling:

Wireframes: Simple wireframe mockups of user interfaces, like the one above, are fast and easy to create. Their simplicity means that they often can be updated in real-time during a review session. Another good thing about them is that they don’t look like real screens, so people don’t get confused and think that the wireframes represent a finished product. Keeping the fidelity low, at the level of wireframe, also provides silent guidance to the requirements author to stay at the level of screen concept, and not stray into designing the actual screen.
High Fidelity Screens: More richly defined screens that actually resemble the end product are at times warranted. Sometimes this happens in high-risk or complex areas of the application and often in collaboration with a user interface designer.
Screen Markups: Very common in situations where you’re enhancing an existing application, taking a screen-shot and applying markups and annotations is an effective way to quickly communicate what’s needed, and to highlight subtle points.
Screen Overlays: Similarly powerful in situations where you’re enhancing an existing application, Screen Overlays take a screen shot of the current application, and add screen controls that represent the enhancement. Modern requirements tools will provide an editor allowing you to do this, and a simulation engine allowing those overlays to become live during a requirements simulation.
System Interfaces: In areas where there’s no user interface, there’s still room for visualizations. Event or sequence diagrams are excellent visuals for illustrating behavior of a system interface.

Integrate different forms of expression

The use cases discussed earlier provide a narrative description of how the user interacts with the system each step of the way. In addition, the visualizations mentioned above illustrate what the user will actually see along the way. It only makes sense that these be integrated. While this could be accomplished manually by perhaps creating links between your use case steps and the visuals with office-automation applications, a far more effective solution is to use a modern requirements definition tool that supports this linkage, and provides other associated benefits. The most powerful of these tools allows you to have a mixture of visualization approaches associated with the use cases, as illustrated in the picture below:

Bring Data into the Picture

Data is an inherent part of any application. In some systems, it’s not very dominant; in other data-intensive applications, data occupies most of the mind-share. By adding visuals (GUI mockups) to the steps in a use case, we were effectively illustrating how the user interface is affected by actions of the user (use case steps). Data is similarly influenced by actions of the user, and this behavior should be specified as well as part of the requirements.

With things like user screens, you can specify them entirely using text or use visualizations, as discussed earlier. This of course isn’t new since many make sketches or mockups outside of the requirements definition process today, using a variety of graphics programs. One of the key values in what was discussed is making these visualizations an inherent part of the requirements, and associating them with the discrete steps of the use cases at points where they’d appear to the user.

Something very similar is possible with data. You could choose to express data elements only using textual statements or tables. Today, outside of the requirements, many create prototypes with various tools like Microsoft Excel to actually perform data operations and evaluate results. This allows requirements authors not only to validate their data requirements, but also to communicate them more effectively. As with visualizations, modern requirements toolsets allow you to bring data operations within the realm of the requirements and, like the visualizations, associate them with specific steps of the use cases where they will be performed. Below shows conceptually where data operations are being associated with use case steps, similar to how the visualizations were earlier.

Figure 4 Data Incorporated in a Use Case

By adding visuals to the steps, we’re able to illustrate how user interfaces presented by the system are influenced by user actions. Similarly, by adding data operations to steps, we’re able to show not only how data is influenced by user actions, but also how data can influence system behavior.

Pull it Together

So there are multiple ways you can express requirements. Of these, textual lists are typically the least expressive. As discussed earlier, I tend to use these alternate forms to augment rather than replace text lists. However, I typically don’t use them on all parts of the application. One criterion that tends to guide how I express requirements is requirements complexity; successfully communicating highly complex requirements demands these more expressive forms. Another criterion is risk. If the risk associated with getting the requirements wrong in a certain area of the application is particularly severe, I want to be as expressive as possible with the requirements, thereby reducing the possibility of miscommunication. The graph below provides an example of this:

While all areas of the application are covered by textual requirements at a high-level, I go to the greatest level of detail in those areas that are complex and risky. The functionality of virtually all areas would be illustrated with use cases. Most of those would have wireframe mockups, with a very few, the highest risk and most complex areas, having higher-fidelity renderings. Also in these important areas, I would leverage data operations on the use case steps. In summary, the highest risk/complex areas are specified to the greatest level of detail and in the most expressive manner, while the lowest risk/simple areas are specified much more simply.

Even though it is possible to do this manually with spreadsheets, drawing tools, and other point-solutions, this is where an integrated requirements workbench really shines in its ability to not only support all these forms of expression, but also to maintain requirements integrity, ensure consistency across them, and manage traceability. The diagram below gives a high-level overview of a traceability strategy for this information, including traceability back to the business context. Tracing back to business reference is vital to ensure that all business needs are being addressed. Conversely, a complete traceability strategy ensures that every application functionality that is being specified has an explicit business need.

Using Expressive Requirements

Defining expressive requirements can dramatically improve the outcome of software projects if only in the uncovering of latent errors early and a reduction in miscommunication. Expressive requirements can release even more value if modern requirements toolsets are leveraged. The following are just a few examples of the benefits you can derive by using a modern requirements toolset.

Generate Documents. A requirements workbench will allow you to generate requirements documents automatically from the information in the requirements model. This can be a significant shift for a more traditional requirements organization in that time is spent focused on the requirements themselves, making them more expressive, analyzing them and improving their quality as opposed to being focused on the mechanical tasks of producing and maintaining a document. You still get the document, just without the effort.

Generate Simulations. A requirements workbench will allow you to transform a requirements model into an animated, live simulation. Simulations with expressive requirements make reviews far more effective, quite frankly, enjoyable. The simulations will leverage all the content in the model including the textual requirements, the use cases, the visualizations, and the data, integrating them into a single “vision” of the future application. Traceability is a vital part of the review process. When reviewing requirements, you must be able to relate them back to the original business need on-demand. Comprehensive requirements workbenches available today expose this traceability not only during requirements authoring tasks, but also during the simulations used for analysis and review.

Comments, feedback, discussions often result from simulation sessions. These are useful exchanges of ideas that also need to be recorded and managed such that they’re not missed, that they’re accessible, and that you can always refer back to them. A modern requirements workbench will record this informal input alongside the comments during simulation and make it accessible throughout the workbench so people are aware of these discussions and so authors can effect change based on them.

Generate Tests. A requirements workbench will allow you to automatically generate tests from the requirements defined in the model. These tests will cover all possible usage scenarios throughout the model and express for each step in the test any relevant screens, data, or externally referenced materials.

The importance of traceability continues through to the tests as well. Each test generated has complete traceability information in its header that identifies which requirements it helps to prove. As I’m sure you can imagine, this ability to generate tests is hugely valuable to the QA professionals on a software project.

Integration with Development and Test Tools. Practitioners, such as developers and testers who consume the requirements, base their work products ultimately on the requirements. It’s therefore very important that the requirements information be available to their toolsets as well. Today’s requirements workbench will integrate with popular UML design toolsets as well as QA testing toolsets to provide them with high-quality, expressive requirements content.

Managing Requirements Change

With more expressive requirements, most change will occur at the beginning of the project when alterations are inexpensive. The modern requirements workbench provides several capabilities to help manage change. Some of these include:

Traceability: As discussed at several points earlier, the modern requirements workbench supports traceability among all requirements artifacts, provides mechanisms to create relationships that are fast and easy, makes traceability information available as you work, and provides sophisticated and filterable views into traceability for deeper analysis. Traceability is very important for analyzing impact as part of requirements change.
Versioning: The modern requirements workbench will version all requirements elements such that you can always go back in time to see them as they existed at points in the past.
History: The modern requirements workbench will provide a comprehensive historical record detailing who changed what, and when they did it.
Difference: The modern requirements workbench will allow you to select any two versions and instantly see the precise differences between them, for all requirements elements regardless of the form of expression.

Summary

The key problem for software requirements historically has been less-than-perfect requirements. One of the main reasons for poor quality requirements is miscommunication of requirements, owing to a lack of requirements expressiveness. Multiple forms of expression for requirements can remove this miscommunication. At the same times, integrating these multiple forms in a single unified model allows them to be manageable and scalable. The modern requirements workbench makes this approach for practical, expressive requirements possible.

Don’t forget to leave your comments below

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].

Building and Managing a Requirements Center of Excellence. Part I.

Written by Tony Higgins on September 22, 2009. Posted in Articles.

Maximize Application Quality; Minimize Cost and Time-to-market.

The phrase “the world runs on software” is almost cliché now. Everyone’s life is a daily testament to this adage. Software is ubiquitous and is without question business critical. Virtually every modern-day business has some, if not all, of their business-critical functions implemented in software. In the software game, if you “get it right” the benefits of implementing business in software can be tremendous. If you don’t “get it right” you can find yourself out of business.

Errors in a software development projects have to be confronted if you are to deliver a product with any degree of quality – it isn’t a matter of “if” you fix them, it’s a matter of “when”. Most errors in a software development project originate very early in a project during requirements definition – 68% in fact [Standish]. This represents a huge opportunity to improve software project performance since it is well known that errors are exponentially cheaper to fix when detected earlier in the development life-cycle. But how do we find errors at this early stage and/or prevent them altogether? How do we unambiguously communicate the requirements to developers, testers, and support personnel in a language they understand? Once these questions are answered, how then do we make this a core-competency of our software development capability across all projects? This is what a Requirements Center of Excellence (CoE) is intended to address. It is an investment to capitalize on what is one of the largest opportunities related to software development, and therefore business, today.

In short, a Requirements CoE is the consolidation and centralization of Requirements expertise, knowledge, process, and tools, so that it may be continually improved and leveraged to maximum advantage across all projects in an organization. With a Requirements CoE, valuable new lessons from one project, instead of taking months or years to propagate “organically” can be quickly leveraged across the organization thereby driving rapid improvement.

Just some of the benefits from implementing a Requirements CoE include:

Cost Savings. Early error detection and correction dramatically reduces rework

Efficiencies. Consolidation of disparate requirements initiatives

Reduced Time to Market. Reduced rework results in finished products sooner

Product Predictability. Early error detection reduces risk, improving predictability

Quality. Higher quality requirements and automatically generated inputs for Developers and Testers means less rework and higher quality results

Rapid Improvement. Requirements investments are leveraged across the organization much faster

One of the most promising aspects of a Requirements CoE is that it allows for consistent measuring performance from the perspective of business and end-user results across the organization – not just measuring systems and components at a project or departmental level. With all projects addressing requirements with a consistent approach, common metrics can be established and directly related to business objectives.

A Requirements CoE can be built incrementally with return on investment measured at every stage. For the more risk-averse you can start small, consolidating and leveraging existing requirements resources, and expand as the value is proven.

A Requirements CoE can dramatically reduce the cost of software development for the organization and provides mechanisms to make the benefits sustainable.

What is a Requirements Development Center of Excellence?

A Requirements CoE is an internal group focused on optimizing the quality of requirements produced for all software development projects, ensuring that the requirements reflect true business needs and that they can provide the basis for efficient and effective product development.

The types of activities a Requirements CoE performs include:

Requirements tool evaluation, standardization, purchase for the organization
Requirements process definition, standardization, and tailoring
Requirements Metrics definition, automation, collection, storage, reporting
Requirements Training and mentoring services for company staff
Project “Startup” services (assess, recommend tools, process, training, mentoring)
Requirements component reuse storage, repository, cataloguing, and guidance
Requirements model review and consulting services for projects
Requirements guidelines, standards, and best practices
Representation in industry Requirements community
(a more comprehensive list is provided later in this article)

Through the Requirements CoE approach, project teams are able to take advantage of all of the expertise, process, toolsets, and best practices the Requirements CoE has developed and consolidated. This section provides an overview of the Requirements CoE and examples of the services it can provide. The next section takes a closer look at the business value of implementing a Quality CoE

Traditionally every project team is an island with its own staff, tools, and practices. The Requirements CoE model centralizes the expertise and processes, brings Key Performance Indicators (KPIs) to requirements initiatives, and can actually reduce total headcount needed to develop, test, and deliver higher quality applications.

Checklist:

You Should Transition to the Requirements CoE Model soon if you have

Chronic overruns of project budget or schedule, or regularly change scope of application to meet targets
Inability to estimate the cost and schedule impacts of proposed changes during development
Different approaches to expressing requirements from project to project
Project success seemingly dependent on involvement of a few key individuals
No perceptible improvement in predictability of projects from one to the next
Applications that are difficult to modify or customize, and expensive to maintain
Incomplete or inaccurate technical documentation for an application

How a Requirements CoE works: Five Simple Examples

The examples below contrast how an organization might respond to real-world situations with and without a Requirements CoE.

Example 1: A key employee with several years’ experience in business analysis leaves the company mid-way through a critical project

With a Requirements CoE.: The company’s best practices for Requirements Development are defined and shared through the Center of Excellence. All Requirements Center models and sub-models developed by the Analyst over the years are immediately available from the Requirements repository maintained by the Requirements CoE. The Requirements CoE can provide short-term relief to the current project with Business Analysis skills, and/or help ramp up a replacement with any training and mentoring that may be required.
Without a Requirements CoE. The project scrambles to find a replacement and then ramp up that replacement on the manner in which this project works with requirements. Information, notes, emails, and any other bits of information found are gathered in an attempt to reconstruct requirements in their current state. Co-workers and past colleagues are polled to find historical knowledge from the employee.

Example 2: Acquire a Company

With a Requirements CoE. All projects of the “host” company develop requirements in a consistent and effective fashion in accordance with the company’s best practices for Requirements Development as defined and shared through the CoE. CoE experts assess the acquired company’s Requirements Development capabilities and make recommendations for transition and any modification to existing assets (eg. Project Start-up packages, courses, packaged services, etc.). Training and mentoring packages of the CoE are used as part of a transition plan to educate staff of the acquired company. Project Start-up packages, maintained and delivered by the CoE, are used to launch new projects within the acquired company or as a basis to plan transition of projects in progress, where appropriate. A focused transition with well-defined “end-state” where all expectations of host and acquired staff can be managed effectively. Acquired staff gets a sense they are transitioning to a well-managed environment.
Without a Requirements CoE. Host organization differs in Requirements Development approach from project to project, with low level of consistency. Not clear what acquired company should transition to, if to transition at all. Result is perpetuating acquired company’s requirements approach thereby creating yet another “stovepipe” in the organization, inhibiting integration of the acquired company and the efficiencies that should have been gained because of it. With no clear “end-state” for the requirements discipline the expectations of acquired staff are difficult to manage and they lack a sense of moving to something better. Instead they have a sense of being assimilated into a chaotic environment. Morale diminishes among the acquired staff increasing turnover, reducing productivity, and increasing risk of failed acquisition.

Example 3: External party (customer, prospect) to review or audit software development capability.

With a Requirements CoE. Requirements Development process including best-practices, sample artefacts, templates, guidelines are maintained by the Requirements CoE and made accessible to all projects. Project performance measures collected analyzed and reported on by the CoE are also available. Any mappings of adherence to industry models (CMMi, ISO, etc.) are also be maintained by the CoE. All this information is available for review by the external party and can be explained and discussed with experts from the CoE. Projects in progress can be shown to adhere to the standard process and any can be chosen as an example for further examination.
Without a Requirements CoE. An effort is launched to canvas projects seeking the “nicest” examples of requirements artifacts. Any process descriptions are similarly gathered or created in order to explain how requirements activities are performed. Directories for old projects are scanned, again seeking good examples of requirements artifacts. Metrics on performance are gathered where they exist, and attempts made to normalize and reconcile them in order to extract some meaning.

Example 4: A new, business-critical project initiative is being considered and accurate estimates of time and cost are required in order to make a decision to proceed.

With a Requirements CoE. Requirements models for past projects in the repository are examined for reusable models and sub models. Metrics on past project performance are analyzed. A high level, abstract Requirements Center model is created and supplemented with any reusable sub-models found. This model, along with performance metrics gathered, is used as key basis for estimating the new initiative.
Without a Requirements CoE. Pull most knowledgeable, senior people from current assignments together and collect subjective impressions from past projects of similar nature, magnitude and complexity, if they exist. Estimate for new initiative is based on these impressions and personal experience.

Example 5: A new project is being launched, and the “environment” consisting of process and tools needs to be established.

With a Requirements CoE. The Project Manager notifies the CoE of the new project. Experts from the Requirements CoE deploy the “Project Start-up” packaged service. They assess the project to deduce best fit, given project type, complexity, duration, budgets, people, etc. CoE experts deliver training and mentoring, deploy and configure the toolset, and put process in place. The CoE experts assist with project launch and deliver mentoring with emphasis during early stages of Requirements Development, ensuring staff are proficient with process and tools. Initial artifacts are reviewed by CoE experts to help staff converge on the optimal solution. CoE experts are involved in every major project review and are on call to provide “Just in Time” mentoring and assistance. CoE experts liaise with tools manufacturers as “single point of contact” for special requests and support on behalf of all projects.
Without a Requirements CoE. The Project Manager tries to secure time with process “experts” from wherever they may be in the company. Experts and senior project staff do “process engineering”, typically under project budget, to identify desired approaches, tools, templates, guidelines, etc. for the project. The results of this activity are highly dependent on the personal experience of the individuals involved. The project then puts all in place, must devise means of educating staff, acquires and deploys/configures tool(s). Interfacing with vendor is often done by designated project staff. When issues arise with process, tools, advice is sought in informal manner from whatever source might be available.

Start Small and Grow Organically

One of the key advantages of a Requirements CoE is that it can be established incrementally and show incremental returns on investment. A Requirements CoE can be built on a small scale initially with minimal capital expenditure and you can scale up its resources, services, and capabilities incrementally as its value is proven.

Initially the Requirements CoE could focus on the standardization of requirements artifacts including notations and formats. This can be followed by, or deployed in conjunction with, standardization of tool support for defining requirements. In time, the process by which requirements are developed based on the notations and automation can be formalized and tuned. The standardized process would include aspects made possible only by automated tool support, such as immediate validation of requirements using simulation and testability assurance. Still later a centralized repository for requirements artifacts to facilitate reuse could be added followed by a formal requirements metrics program to provide the basis for continual requirements improvement.

Therefore the CoE can grow both in capability and breadth of adoption across the enterprise at a rate that fits the constraints of the organization.

Requirements CoE Resources and Services

The Requirements CoE has the potential to become a competitive advantage for any company whose business relies on software. Since requirements are the cornerstone of the software development process with all other disciplines dependent on its artifacts and with 68% of all errors being introduced at this point, there is tremendous potential for cost-savings and quality improvement. The nature of the services that can be provided by a Requirements CoE include:

“Project Start-up” Services with Respect to Requirements

Leverage the growing Requirements Development knowledge and experience base
Provide expert assistance in assessing and devising best approach for tools, process, and training/mentoring needs for the project
Assist in setting up environment including project guidelines, standards, templates, and other assets
Deliver training and mentoring in Requirements Development process and tools

To be a Cross-product/divisional “Communication Hub” for Requirements

“harvest” business assets and make reusable
- Business cases and studies to make it easier for other divisions to adopt
“harvest” technical assets and make reusable
- Best practices in Requirements Development across projects
- Reusable Requirements components
- Reusable Requirements Training components
Establish mechanisms to foster communication in Requirements Development
- Newsletters, bulletin boards, interest-group meetings

Requirements Development Tool Expertise

Single point of liaison with Requirements Development tool vendor. Promote organization’s interests, enhancement management, beta participation
First-line support for Requirements Development tool
Experts in tool configuration for specific project usage and application
Development of, and repository for examples templates that support process
Best Practices in tool usage for specific applications

Requirements Development Process Expertise

Generation and maintenance of standard Requirements Development process
Expertise to tailor and adapt the standard process to suit specific projects
Collection of empirical data and metrics to facilitate continual process improvement
Expertise to teach and mentor project staff in Requirements Development process

Education and Awareness of Requirements Development to the Larger Organization

In early stages this new discipline will be largely unknown to most. This center should be capable of fielding requests for information and providing introductory education
Should also be in a position to deliver demonstrations, learning sessions, and similar as part of awareness efforts

To Liaise with Industry Associations and Represent the Organization in these Forums

In order to “harvest” best-practices and approaches found by others, and to monitor trends in the discipline
In order to contribute organizational learning

To provide these services the Requirements CoE should maintain a core staff, whose levels will depend upon how aggressively the organization chooses to grow the discipline. Initially this could involve a part-time manager and single domain expert but could scale over time to support an enterprise.

In this article, we have discussed what a Requirements CoE, is and how it works. Stay tuned for next issue’s follow up, on why organizations should adopt a Requirements CoE, and step-by-step lessons on how to build one.

Don’t forget to leave your comments below

Using the Requirements Creation Process to Improve Project Estimates

Written by Curt Finch on September 1, 2009. Posted in Articles.

Estimation can be one of the most difficult parts of a project. Important questions must be asked in order to form the right figures and plans. How long will the project take? How many resources will it consume? Consultants may also ask the following question: What is the appropriate amount to bid on this project? These questions are not easy to answer at the outset when one generally has only a vague idea of what will be required throughout the project.

The good news is that there is a fairly simple way to improve project estimation and, consequently, the bidding process. Most people do not realize that the requirements creation process can lend insight into the length and scope of a project. Let me give you an example of how this method works and then explain how you can implement it within your own company.

The Story

Back in 1992, I was working for a consulting company named The Kernel Group (TKG). During this time, I was put in charge of porting Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating system. The project was to be done under a fixed bid, and consequently, we at TKG knew that estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that if Tivoli didn’t make the project hard for us in some unspecified way, we could port the million or so lines of code in about a weekend. I told him that he was nuts – that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks just to be safe. We also decided, rather smugly, not to report our padding of the schedule to evil upper management.

As a result, evil upper management drastically expanded the project bid to $325,000, and my coworker and I thought that this was a ridiculously high price. We believed that we were gouging the customer and that they would never accept it.

Yet they did accept it, and once the project began, we proceeded to discover how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but a whole lot more on top of it.

The Formula

Now our consulting company was religious about tracking employee time on a per-project basis, and so we broke every project into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. This project was no different in that respect; we broke it down into its respective phases as well.

Just before we started working on the project in question, I read a book called Practical Software Metrics for Project Management and Process Improvement by Robert B. Grady. (By the way, this is a truly fabulous book that I would highly recommend to anyone who is managing software development projects.) According to the book, one of Grady’s rules of thumb is that 6-8% of every software project is usually eaten up in the requirements/specification phase.

One of the conclusions that Grady comes to in his work is that you can use this fact to estimate total project size. In other words, if it took 60 hours to do the specification, that’s probably 6% of the job and the job will be 1000 hours. Following such logic, a six hour specification implies a 100 hour job. Since the specification always comes first in any project, you can get some pretty reliable estimates from this method alone. In fact, in my experience as both a programmer and the CEO of a software company, I have found it to be incredibly accurate and useful.

A second way to triangulate this project estimate is to ask experts in the area for their opinions – hopefully they will be better at project estimation than my coworker and I were that first time. A third way is to select an appropriate metric for estimation. For example, one could use line of code counts or function points in estimating the length and scope of software projects. For architecture projects, you might use number of pages in the drawings or square feet planned as similar analogies. Every project has some gross measure of its size that is available at the outset and can be used to plan the overall project in addition to this method I’ve described of tracking time against the earliest phases.

So back to the story. We really blew it on estimating and bidding on that first project for Tivoli, but when the next one came around, we had data on the portion of the overall project that the requirements phase had taken up. This allowed us to use Grady’s ratio to predict overall project size, and we found that on this second project, we came up with a very accurate project estimate. This worked very well for all of the subsequent fixed-cost consulting work we did for Tivoli.

Partially due to the strength of the solution and how well it ran on IBM’s AIX operating system, Tivoli was able to eventually sell their company to IBM for 743 million dollars in 1995.

For a consultancy that is doing fixed-cost projects, this concept of using the standard ratio of requirements phase to overall project length is a very powerful project estimation technique. It can eliminate erroneous bidding and its resulting costs, which is a major concern for such companies.

Accurate Bidding

Overbidding on a consulting job means that you won’t get the work in the first place, because the potential customer will give it to your competitor at a cheaper price. Underbidding, however, means you will win the deal and lose money. Neither situation is acceptable for businesses today, and yet, most consultancies do a poor job in this area. One way to make more precise bids is to use a key performance indicator, which is a tool used to measure progress towards a strategic business goal. For example, the number you want to minimize in this situation is defined by the formula [(E-A)/E], where:

E = estimated hours to complete the project
A = actual hours spent to complete the project

It is important to keep this KPI value as close to zero as possible, which indicates that you are bidding on projects more accurately.

Just tracking this number is a great first step towards better bidding, and you can get the necessary data to calculate it from any timesheet system, including a paper one. Automated timesheet systems, however, are generally even more effective in this area because they often have reports to calculate the KPI figure for you.

Improving adherence to your estimate can be difficult for some companies until they understand the ratio concept described above. An example of this is illustrated in the following diagram, which shows how the formula can work for any business. Your company’s magic number may not be 6-8% like Grady’s, but once you determine your own ratio for specification to total project length, you can use it again and again.

Making it Work

I currently run a software company, Journyx, and I can assure you that this project estimation technique continues to be successfully employed by many of our customers to their great advantage. It is easy to implement and you can do it too. Once you do, you will start producing laser sharp estimates before you know it. And that’s a result we can all feel good about requiring.

Happy estimating!

Don’t forget to leave your comments below

Curt Finch is the CEO of Journyx. Journyx offers customers two solutions to reach the highest levels of profitability: Journyx Timesheet – a timesheet and expense management solution for the entire enterprise – and Journyx ProjectXecute – a solution that unites project and process planning with resource management. Journyx has thousands of customers worldwide and is the first and only company to establish Per Person/Per Project Profitability (P5), a proprietary process that enables customers to gather and analyze information to discover profit opportunities. Curt is an avid speaker and author, and recently published “All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource.” Curt authors a project management blog and you can follow him on Twitter.

Projects without Borders; Gathering Requirements on a Multi-Cultural Project

Written by Elizabeth Larson on August 11, 2009. Posted in Articles.

Co-authored by Richard Larson

One of the most difficult tasks project managers and business analysts face is obtaining customer requirements. Even when business customers and the business analyst work in the same building, misunderstandings are bound to arise. And as more and more businesses expand beyond their borders, different terminology and ways of doing things the risk of things going awry gets even greater. It’s a challenge to ask the right questions, get the right people involved, and document unambiguous requirements, regardless of the backgrounds of those participating. When the project includes multi-cultural stakeholders, particularly if they comprise a virtual team working in geographically dispersed areas, often thousands of miles, time zones and oceans apart, the job becomes much harder.

Some of the challenges facing project managers and business analysts are not unique to multi-cultural projects. However, personal agendas, conflicts about roles and priorities, and availability worsen the situation. In addition, recent studies have shown that almost half of the typical project budget is spent reworking requirements defects. While there are many underlying reasons for this rework, dealing with a group of multi-cultural business customers and/or project team members can create significant hurdles.

The Challenges

Physical Distance of Stakeholders

Although many of the challenges exist even when the team and business customers are located on the same floor in the same building, the difficulties in dealing with them increase with physical distance. Time zones make meetings hard to schedule. Business analysts on today’s global projects have learned that the standard eight-hour work day doesn’t exist. If we are truly customer-focused and interested in building relationships to capture requirements, we schedule meetings at a time convenient to our customers, not to us.

Few meetings on global projects are face-to-face, making the assessment of non-verbal communication nearly impossible. Since most business analysts pay a great deal of attention to non-verbals as part of the elicitation process, not being able to see them diminishes the communication and therefore the ability to capture requirements. Finally, although there are alternatives to face-to-face meetings, neither video conferencing nor “net” meetings is ideal. Video conferences usually lack some spontaneity and the audio lag can be distracting. Facilitating large groups over a video conference is quite challenging, since multiple conversations, dominance of one group or individual, and other facilitation difficulties abound. With both video-conferencing and net meetings, there are often equipment issues which hinder the requirements elicitation.

Roles and Responsibilities

Unclear roles and responsibilities can be the bane of project mangers and business analysts everywhere. When they are unclear, tasks invariably fall through the cracks and finger-pointing ensues. Unfortunately when stakeholders are removed from each other, it takes longer to find omissions and the resulting errors are harder to correct. Trouble usually occurs if a business analyst expects the business client to define the requirements, but the business client thinks they have already provided the solution and the rest is up to the business analyst. With differing cultural attitudes towards conflict, it can take even longer to perceive that there is a difference of opinion, let alone resolve it.

Language

Language barriers across cultures are numerous. The difficulties caused by differences in languages and even pronunciation among the stakeholders is well-known. In addition, most people have different levels of understanding and expressing both written and oral languages that are not in their tongue. For example, some people can understand another language when spoken, but have difficulty writing it. Others can understand better than they speak and write better than they understand. In order to elicit the requirements, project managers and business analysts need to work with business customers whose language differs from theirs to assess the comfort with both written and oral communications.

Finally, we need to consider the use of TLAs (three-letter acronyms), humor, euphemisms (powder room, passed away, downsizing), and sports analogies (ballpark estimate, coming out of left field, long shot) that can cause confusion and misunderstanding.

The Cultural Landscape

Another barrier is assuming that all team members, whether or not they are collocated, approach the project with the same cultural perspective. For example, I was managing a project that included a male team member who appeared uncomfortable taking direction from a woman. The more I discussed the importance of meeting deadlines, communicating status, and teamwork, the more uncommunicative and uncooperative he became. Finally I realized that the real problem was that I had done nothing to build trust and a strong relationship with him. His cultural work ethic dictated the importance of relationships. Therefore, he completed tasks because of the relationship, not because tasks appeared on a work breakdown structure.

Tips and Techniques for Making it Work

As organizations take on more global projects or projects that include a diverse set of business customers, they need to establish a corporate mindset of acceptance, inclusion, and learning that crosses borders. In addition, the project team needs to understand its inter-dependency in order to have project success. Synergy between the business customers and the project manager or business analyst is required to ensure that the end product is successful. Therefore, each party, the project manager, business analyst, sponsor, and all the business customers have an obligation and a stake in making this cultural diversity work. Without the project manager, the organization will spend more time and money on failed projects. Without the business analyst, the end product will not be usable. Without strong sponsorship and actively engaged business clients, the true requirements will not be discovered, and the end product will not be viable.

Although each party has its responsibility for making the project and end product successful, there are some things that the project manager and business analyst can do that help bridge the cultural gap.

Build Relationships and Trust

Building relationships and trust is important on all projects. There are a myriad of ways business customers can sabotage a project if they are afraid that the end result will jeopardize or dramatically change their jobs, or when the local requirements are not taken into account. With good relationships, issues surface more easily and can be resolved quicker.

The different requirements elicitation venues promote team-building to a greater or lesser degree.

For example, the use of surveys does little to promote mutual understanding.
Facilitated sessions (which may have to be net meetings on global projects) can help build teamwork, but it could take weeks or months for a virtual team to solidify.
One-on-ones serve to build relationships and help navigate the political and cultural landscape. By meeting individually, the project manager or business analyst can assess commitment to the project, discuss individual concerns, gather requirements from those who may not speak up in meetings, and gather requirements related to local needs of the global business experts. One-on-ones can also more easily promote understanding of team members from various cultural backgrounds, because language differences are the least problematic and personal stories and experiences can be more easily shared.

Define Roles and Responsibilities Using a Matrix

One technique that can aid in avoiding the pitfalls of unclear roles and responsibilities is to document them using some form of matrix, such as the Responsibility Assignment Matrix or the RACI chart. These tools use minimal text, so they are easier to understand than textual descriptions. In addition, in order to complete them, valuable discussion needs to occur. By facilitating this discussion, the project manager can help ensure that the fine distinctions between such things as a role and responsibility can be cleared up earlier rather than later in the project.

Example RACI Chart

(Responsibility for doing the work, Accountability for decisions, Consult with on the work, Inform that the work has completed)

Task/Phase	R	A	C	I
Project Plan	Martha	Mary	PMO	Team
Requirements List	Martha	Client	Requirements Consultant	Team Client’s Staff
Modeling (Process, Use Case, and Data)	Ying, Susan, David	Mary	DBA	Team
User Interface Requirements/Prototyping	Martha, David	Mary	Usability Lab	Team
Programming	Sunil, Shashi	Mary	All BAs	Team
User Acceptance Testing	Martha	Client	Sunil, Shashi

Model the Requirements

One of the best ways to elicit requirements is to use various models to represent the requirements. Models, such as process models, usage models, and prototypes can provide a structure that encourages asking questions to find hidden requirements and more quickly document a complete set of requirements. Models have a number of advantages in general, and for cross-cultural projects in particular:

Models have the advantage of needing few words, so the language issues can be more easily overcome. They also have the advantage of promoting a two-way translation of requirements, from business customer to the model and back to the business customer, again with a great deal of structure and a minimum use of words. Models should be created so that they are clear and for the most part understood and used by the business clients.
Models are the most effective way to avoid having different members of the group have different mental pictures of the requirements. They are, for the most part, culturally independent. They can be created using several of the requirements venues including facilitated sessions, one-on-ones, and observation.
Models can help traverse the cultural landscape because they produce unambiguous requirements. That is, there is little room for misinterpreting them. Regardless of the birth countries of the business customers, business analyst, and team, cultural interpretations of the requirements are minimized by using pictures instead of text.
Finally models can be used whether or not the business customers are local or dispersed. Technology now permits models to be easily shared in-person, by email, with video-conferencing, and with net meetings. Because models can be viewed by all, there is less chance for miscommunication of requirements.

Summary

A large, multi-national U.S.-based pharmaceutical client of ours regularly experiences the challenge of cross-cultural requirements gathering. The following are some anecdotes to summarize a few of the key points in this article.

A conference call with a Tokyo client took twice as long to review a process flow as with domestic clients. The analyst kept asking “is there anything else” because of not wanting to omit something important. (Conclusion: plan for extra time when working cross-culturally.)
A similar group of Japanese clients insist on spending time at the beginning of a project getting to know their IT counterparts. They frequently and repeatedly ask that the IT staff come over to Japan to meet and visit with them. When the groups do meet in person, each meeting ends with a glass of sake to celebrate. (Conclusion: relationships are more important than the work in some cultures than others, even to the extent of delaying work. Projects will be stalled until relationships are established, and trust may be even more difficult to establish.)
A cross-cultural team of American, French, and British clients spent two hours talking about an industry term that the three groups swore had three different meanings. They later discovered the terms were really the same and then had to agree on which one to adopt. (Conclusion: language differences will be a challenge, so take the time to define key terms and record them in a glossary during projects.).
A project manager made an onsite visit to a client from Latin America on a project. The project manager had written in an email that he had found a restaurant to go to, but you had to BYOB. The client was confused and asked when they got together: “who is ‘bee-yob’?” (Conclusion: be careful with and define all acronyms!)

In sum, gathering requirements on a multi-cultural project has numerous challenges. To avoid or lessen the affects of these pitfalls, project managers and business analysts should spend time developing relationships, clarify roles and responsibilities in a chart format to ensure understanding by all, use terms and language carefully, and model the requirements to help ask questions. The ultimate goal is to uncover requirements in a way that is easier for all stakeholders, regardless of their language and culture.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Attendees immediately learn the retainable real-world skills necessary to produce enduring results. Between them they have presented workshops, seminars, and training classes on three different continents to over 15,000 attendees. Their speaking history includes repeat appearances at Project Management Institute (PMI®) North American, European, and Asia-Pacific Congresses, and at Business Analyst World conferences around North America. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP®) through the International Institute of Business Analysis (IIBA®) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK®). They are also certified Project Management Professionals (PMP®) and are contributors of the section on collecting requirements in the upcoming 4th edition of the Project Management Body of Knowledge (PMBOK®).

Requirements; How Do I Know When I’m Done?

Written by Keith Ellis on June 16, 2009. Posted in Articles.

This is one of the most common and controversial questions amongst business analysts and project managers: “When are requirements done?” The most common response to this question, “When the customer signs off,” frankly makes me want to tear my hair out. The focus has to be on what you can control – defined levels of quality, timeliness, completeness, accuracy, clarity, or communication – not, what you can not control. But that still begs the question – “How do I KNOW when I’m done?” – what’s the definitive if-I-have-“X”-I-am-sure-I’ve-not-missed-anything-and-I’ll-get-a-pat-on-the-back?

Here’s the issue for everyone looking for a silver bullet: requirements are never done – at least not in the business information systems world. Trying for ‘absoluteness’ (to make up a new and cool consulting word) will more likely lead to process failure than success. As you cascade past business requirements and get into increasingly detailed iterations of specification documentation, the line between what is a requirement and what is a solution gets increasingly fuzzy.

Now before all the agilists out there start whooping it up in agreement: ‘absenting’ requirements (you need to be equal opportunity about making up consulting words!) will lead to incredible performance inconsistency – at an individual resource level, at a long term asset management and integrity level, and at a corporate expectation management level. I can even prove it: low requirements maturity agilists perform terribly in on time/budget/success performance versus high requirements maturity agilists (if you want the data, send me a note through the editor or the www.iag.com site and ask). The issue of requirements quality is common across all development approaches: You MUST define what are “clear, accurate and complete requirements” for your situation, if you expect to materially change project performance and success rates.

Therein lies the answer: defining “complete” means a company has to describe all three of:

the state of requirements (quality of information),
the format of requirements (template and techniques used for visualizing requirements), and
the process through which these artifacts are achieved.

Doing this defines what ‘done’ is for analysts and project managers. The question of “Am I done?” only really arises at companies where there is weakness in one of the requirements state, format or process attributes. Deal with these three attributes, and the company starts itself down that path of maturing requirements practices and materially changes its ratio of on-time/on-budget/success performance on projects.

OK! Get up and stretch – for those of you saying “Hey, he’s ducking the question!” – there’s more.

Not everyone can deal with the long term fix. We sometimes have to do quick fixes as a reality of day to day management. Here are four simple tests to assess if requirements are not done to a reasonable or sufficient degree of quality. These are Business Requirements level tests that work and will improve your requirements quality irrespective of delivery methodology:

If the requirements lack context. Requirements always exist to support “what” the business wants to do, not “how” it wants to do it. The “what” part of this is the context of BUSINESS PROCESS. No understanding of what business processes are impacted by requirements means someone has no idea of how requirements impact each other, the impact of removing requirements, or the ability to assure that the requirements collectively are complete or will meet a specific business objective. The way a company applies context in its documentation also creates the STRUCTURE of the documentation. Here is one technique example – Use Cases. As a technique Use Cases give both context and structure to requirements and help an analyst assure that the scope of the project is both well described and sequenced.
If the interdependency is not evident: How do you look for proof that interdependency is documented? Look for a section in the material called “dependencies”, check the “issues list”, look for an analysis technique called a context diagram (every line on a context diagram is an interdependency). Why is interdependency so important? There are two aspects to scope: internal to the system (e.g., its functionality, the workflow and information flow, etc), and external to the system (e.g., how this system needs to interact with other systems, how the workflow being automated hands off across other departmental units). In the absence of knowing the interdependencies, you only ever know HALF of the story on scope, so it becomes probable that you will encounter significant scope shift on any system of any degree of complexity.
Unclear business objectives: Objectives must be Specific, Measurable, Achievable, Results-oriented, and Time Bounded (easy to remember as ‘SMART’). The absence of objectives eliminates the ability to assess solution tradeoffs, makes difficult the prioritization of functionality, and etc. other problems. You can test if a particular function meets needs with user acceptance tests. You cannot test if the collective system meets needs unless you have clear objectives.
You cannot tell from the description of business need how information is going to move. I need $10 for every time I’ve seen business requirements expressed as a process flowchart. This is a nice (albeit somewhat inefficient) first step but here’s the problem: when you get to the ‘decision diamond’ in the picture that says “approve the policy (Y/N)” how do you expect developers to know what this means? The only way to elaborate this is to ask the questions, “What information do you need to know to approve that policy?”, “what do you do with that information?”, “where do you get the information from?”, “who else do you give the information to?” etc. The more detailed the description of WHAT the business wants to do, the more the description of process will center on how information needs to move in support of the business process. Until you get to the level of detail that is expressing information movement, you have no idea from the documentation what the business intent is. It’s easy to test – just look for the NOUNS. Lots of nouns used consistently when describing a step in a process, mean you’re probably OK.

I’ve given everyone these above four tests because they always apply. Even at the executive level in the organization, these things should be deemed important. They are clear, auditable and technique-independent traits that can be assessed, whether you are plan-driven, prototype, vendor-supplied method, agile, or whatever.

How does this view of “Done” change when you’re a business analyst?

From a business analyst perspective, it is your job to dig deeper and be accountable for quality. I’ll give you a few thoughts as take-aways especially for you:

There are techniques that can help an analyst test requirements completeness and uncover missing business logic. Look at CRUD diagrams as an example of a commonly known test and technique. Look at an entity relationship diagramming (ERD) as a lesser known test (a bit of trivia here: any time there is a null relationship between entities in an ERD, you need to ask the question “What do you do … ” to flesh out what happens in the circumstance of, for example, a lead is never assigned to an agent). Look at some of these techniques to improve your ability to be proactive and identify issues before they arise as missed requirements. Factor the time to do some of this activity into your assignments.

From an analyst perspective the bar is quite a bit higher on what constitutes quality. You are “done” when the requirements have quality. To have requirements quality, requirements must be:

Correct – the requirement is an accurate elaboration of a documented business objective or goal
Unambiguous – the requirement has only one interpretation
Complete – the requirement is self contained with no missing information
Consistent – the requirement is externally consistent with its documented sources such as higher-level goals and requirements
Ranked – the requirement is prioritized for some purpose
Verifiable – the requirement is usable (e.g., testable) by the testers who must verify and validate it
Modifiable – the requirement specifies only one thing
Traceable – the requirement has its own unique identifier that can be used for tracing purposes

Friends, my rant is a little long this month but I hope a few ideas here bring clarity or a new perspective on a troublesome topic. “Done” never happens; reasonable happens. Your perspective on what to look at to assess requirements “quality” depends on your role, and you can educate the organization about how each level of the organization plays a role in assessing whether or not requirements are reasonably clear, accurate and complete. Check out http://www.iag.biz/resources/webinars/microcast–executive-guide-to-evaluating-requirements-quality.html for a quick example of how you might educate executives.

I wish you all, great success.

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.