Tag: Lean

Use cases are becoming more mainstream as a method for capturing requirements, as evidenced by the endorsement of big companies and methodologists such as Booch, Rumbaugh, and Coad. One benefit of use cases is that each one encapsulates a set of requirements. This encapsulation lets you easily manage and track the use cases individually and provides a better alternative to prose requirements.

There is more to effectively using use cases than just capturing them and putting them into diagrams. As you implement use cases, you need to validate them, determine their size, and establish a plan for implementation. Then, you need to incorporate the use cases into your system design and turn them into code and documentation. Throughout this process, you must also be aware of the status of each use case. This article will discuss ways to do all these things.

Validating Requirements with Use Cases

Once you’ve captured a use case, you need to confirm whether it accurately describes the system and is truly needed by the system’s users. Sometimes, in the course of development, you realize some of the requirements you’ve created are unnecessary or peripheral to the main purpose of the system. You must identify these as soon as possible, so you can work on the functionality that is the most valuable to the customer. But how do you determine which use cases are most important to your users? You use a method called Quality Function Deployment (QFD).

QFD helps you weigh use cases to determine which ones are important and which can be discarded. To use QFD, users representing each group in the actor catalog are given a list of the abstract use cases and $100 in virtual cash to spend on the ones they think are the most important. The amounts are then tallied to determine which features are the most desired.

When using QFD, it’s important to keep one caveat in mind: make sure you include on the list all the obvious features the users will expect in the system, because it’s very likely these features will not come up while you’re gathering use cases. For example, in the banking program, users would obviously require a “transfer funds” use case. However, because they expect this feature to exist, they might not consider it important and not allocate funds for it. It’s important to allow for this and include the basic functions of the system into the QFD.

Sizing

Because use cases describe functionality from the user’s point of view, they can be directly converted to function points. Assigning function points to use cases helps us understand how large a use case is and the associated effort needed to produce it.

We can use this knowledge in iterative development to divide the iterations into roughly equal sizes and determine earned value. Some companies use earned value to recognize revenue. You can do this by dividing the estimated cost of a program by the number of function points, which yields a cost per function point. Each use case then becomes part of the executable. Multiply the number of function points associated with each use case by the cost per function point. The result is the amount of revenue recognized. You can use this same technique for project tracking by using the number of function points delivered to determine the progress on the project.

Iterative Development

Determining the implementation order of requirements involves several conflicting factors: the needs of the customer, the needs of the development team, and the needs of management. The customers would like to see the parts of the program they want implemented first. The development team needs to work on the most complex parts of the program first, so it can move from high complexity to low complexity. Management would like to work on the parts with the highest risk, so they can move from high risk to low risk.

So, how do you balance all three concerns? The customer’s needs are known through QFD. If you deliver the iterations based on the QFD scores, you ensure customer satisfaction. But to also satisfy the needs of the development team and management, it’s best to rank each use case for complexity and risk as well. Here’s one way to do this: Rank complexity on a scale from one to five, with one being very simple, four being very complex, and five unknown. Rank risk similarly, with one being marginal, four being high risk, and five unknown. Once you’ve rated all the use cases, multiply complexity, risk, and the QFD percentage to get a weighted value that takes into account customer satisfaction, complexity, and risk.

Design

Use cases can help you create your system design and also serve as the foundation of design reviews. Use cases can be readily converted to object, interaction, and event diagrams and used as a basis for CRC cards. In a design review, use cases force designers to show how each use case is enabled by the design, and which elements of the design are not part of any use case. This ensures all requirements are implemented and no unnecessary work is done.

Testing and Documentation

Use cases are the backbone of testing and documentation. If the use cases are clearly stated and testable, they form the basic system test plan. They are also well suited for acceptance testing, in which users test all use cases on the system and approve the system’s performance of each one. Because use cases represent the user’s perspective, they can form the initial user manual, online documentation, or help file. Some divisions of Microsoft use a similar technique; they write the user manual first and it becomes the specification for the program.

Use Case Tracking

To make sure you deliver what the customer has asked for, you need to know the status of each use case. Knowing where each use case is within the software life cycle is valuable for managing the project and determining status. You can accomplish this goal by assigning each use case a Work Breakdown Structure (WBS) in the project plan. Then, as you track the project, you also track each use case. This also yields a method for determining WBSs.

As your project progresses, you need to manage and control your use cases. A repository makes this possible. One method is to keep the data in a groupware database product such as Lotus Notes and include the following information on each use case:

• A short descriptive name of the use case in the form of an action verb and noun, such as “export to spreadsheet”
• A detailed description of the action the use case performs
• The preconditions: other activities that must take place before this use case executes
• The post conditions: the actions that will happen to the use case after it executes
• The exceptions: what happens if the use case fails
• The pattern name from Coad, Gamma, and so on
• The Work Breakdown Structure (WBS)
• The number of function points required
• The location of the design files for the use case
• The location of code files for the use case
• The modifications made to the system, the date the modifications were made, and the name of the person who made them.

Use cases are a valuable tool for capturing and managing requirements. You can use them in all facets of the software development life cycle. As you move throughout the different phases of your next project, think of how use cases could be involved and how you would manage them. If you manage and track use cases well, you’ll be able to use them to their fullest.

Don’t forget to leave your comments below

---

Todd Wyder is Vice-President Product Management and Development at COE Truman Technologies, Inc., a 25 year old information firm that provides software products and professional services to a wide range of industries. Todd is a goal-oriented executive with experience in planning, developing and implementing cutting-edge information solutions to address business opportunities

Reprinted courtesy of Dr. Dobb’s www.ddj.com. Copyright 2009. All Rights Reserved.

In my job, I get to hang out with a lot of very senior people and talk with them about requirements and business analysts. The one complaint I hear over and over: “Our BAs are not proactive”. Maybe some in the organization are being a bit passive, but the executives I talk with are most concerned that the BAs are order takers, rather than being seen by the business as really driving the process. You need to ATTACK requirements. Be proactive! And, know the right questions to ask to motivate stakeholders to get you the right kinds of information. Here’s the problem – many analysts get in the way of their own success.

Remove the Barriers

It’s easy to fall into the role of order taker and think the customer can drive the requirements process; particularly in the face of an assertive executive with a fairly clear vision of what they want. I humbly submit, if you roll-over and become an order taker, you’re dead. The requirements on the project will likely be incomplete with significant functional areas missing, and there is likely to be no consensus between executives in the areas of interdependency. Think value-add! The analyst is the one that needs to fill the gap between what the business can articulate for itself, and what the technology department needs as input for successful development. Get people on board with the idea that there is a gap in content that needs to be filled, and remove both the barriers to participation and the barrier to being proactive. If you show you can add value to articulating business needs, you are taking the bull by the horns and being proactive.

Have a ‘Go To’ Process that Always Works

Analysts get caught up in self-flagellation because they have no personal expertise in the business process they are reviewing. Get over it! You cannot possibly be expert in every process and system in the company. Candidly, it’s a fool’s game to try! Even the SVP operating the division must rely on their experts running the subcomponents of the business, as these in turn rely on their subordinates. How can an analyst portray themselves as more expert in every area of operation of the company than these executives without annoying their stakeholders with their arrogance? The analyst is not there to define optimal business practices for the business. The analyst is there to optimize the process used by business leaders to achieve consensus in their practices. The analyst also knows how to take concepts from high level understanding, to clear, accurate and complete documentation.

Before everyone gets angry at me…you absolutely can be expert at doing requirements and getting executives to consensus without being a business area subject expert. Analysts can absolutely be successful where they have a ‘go-to’ process for eliciting business requirements that is easy for participants, and adds value to their thinking process.

First and foremost you cannot get hung up on problem definition. You can do all the problem definition, analysis of issues and look-back reviews in the world and still have massive problems articulating a solution, especially when dealing with something complex. Watch out for the trap people fall into all the time! You cannot consistently jump from problem to solution so spending too much time on getting better resolution on the problem will not get the business closer to solution.

Situation or problem definition can be insightful, but only in so far as it helps bring clarity to the correct needs, objectives and goals. With a solid understanding of objectives and goals, it is not a large step forward to ask: “To achieve these objectives and goals, how must the business process change?” Discovering, eliciting, and describing the processes that change in response to meeting an objective business is the goal of an analyst. The ability to be a great analyst is to have the right kit bag of techniques to draw on to help the business articulate these changes in a systematic, clear, accurate and complete way.

ATTACK the Detail

There are lots of ways to break down projects into reasonable chunks using scenarios, user stories, use cases, or any number of techniques. These only get the surface information. To be a proactive analyst, you need to attack the detail and ask the questions that proactively pulls this information out of stakeholders. To attack the detail, think SIPOC (SIPOC stands for suppliers, inputs, process, outputs, customers). It’s a concept the six sigma folks hijacked, but it’s a great tool for business analysts when you use it to describe how information moves in the business process:

For the scenario “price an order” (starts with confirm item details, and ends with provide quote to customer) ask SIPOC in this order:

1. Input: What information do you need to know to be able to price an order so you can provide a quote to a customer?
2. Process: What do you do with that information?
3. Output: What typically happens once you’ve priced the order?
4. Customer: Does anyone else need to know about the priced order?
5. Supplier: Is all of this information coming from you, or do you need input from someone else?

Uncovering how information needs to move to support the business process and ultimate business objectives motivating change is the detail an analyst needs in order to get clear, accurate and complete business requirements. We’re in information technology remember!

Ponder Points

Here are some closing thoughts to consider – or maybe comment on – as you get back to the daily grind:

• As the analyst, YOU are accountable for the process of getting the requirements. If you are accountable for anything, it is to be proactive.
• Being proactive doesn’t require you to be an expert at all things business. It does mean knowing techniques that add value and can take you from problem to solution.
• There are a lot of blind alleys out there! Be sure to that you select and adopt techniques that accelerate you along the path from problem to solution in incremental steps, rather than requiring you to take giant leaps from problem to solution.

Don’t forget to leave your comments below

---

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.

Co-author Richard Larson

One of the most difficult phases of a project is gathering business requirements from stakeholders. Under the best circumstances requirements are often vague, because it is difficult for customers to articulate their needs before they see the end product. In addition, some customers have personal agendas, which make identifying the true needs difficult. When the business customers and project team have a relationship built on trust, they can more quickly work together to produce a product of value to the organization.

Go Away, Please!

What happens, though, when that trust factor is missing? Sometimes the clients’ resentment manifests itself openly. If you’ve ever heard the following in response to setting up requirements meetings, you have probably encountered open resistance:

• “We’ve always done it this way”
• “If it ain’t broke, don’t fix it”
• “The tool or technique that I’m using now works just fine, thank you”
• “I’m busy right now. Go away please!”

All of these responses imply not only that things are working well as is, but that the change is less than welcome. Because the change is not apt to be readily accepted, resistance to it can contribute to an undesirable project outcome. The underlying cause of resistance will be discussed later in the paper.

Resistance is not always evident to the project manager and/or business analyst. It can be couched in friendly terms. If you’ve encountered the following, you may have run into what we call the “Missing Trust Factor.”

• “Did I tell you that last week? I’m terribly sorry but that was wrong.”
• “Boy, I sure don’t remember telling you that.”
• “Oh, I’m so sorry, but I forgot to tell you…”
• “There is no way I ever said that,” when trust is really absent

Overt resistance is easier to handle than behavior that appears to be cooperative, but which prevents the project from moving forward. This article focuses on resistance to business requirements elicitation and discusses how building relationships and trust can help overcome it.

What are Business Requirements?

To understand why it is difficult to get business requirements, particularly when stakeholder relationships are weak or absent, it is necessary to define the term. A business requirement is a description of the features and functions of a product (something you will deliver) that satisfies a want or need enabling people to do, know, operate, or have something new or in a new way. This description usually is in the form of text, but could be documented in a graphical model. The features of the product describe characteristics and functions describe what the product needs to do.

Marketing Example:
The new brochure will include:

Features
Company name and tag line
Company branding and identity
New program
Related products
Benefits
Customer testimonials

Functions
Introduce company to new customers
Provide credibility to new customers
Provide a consistent message and image
Provide speaking points during customer visits and presentations

System Example:
The new order system will include:

Features
Reports rolled up by:
Customer, product ordered, date
Product, price, cost
Discounts
Special promotions

Functions
The system shall:
Adjust suggested retail for profitable customers
Apply discounts by dollar amount or percent off
Allow for specific sale price to be entered

Requirements Solve Business Problems

Before the formal requirements gathering begins, it is important to discuss the business context of the project with the sponsor. Requirements need to be gathered and managed in relation to the organization’s vision and strategic direction. They need to link to business goals and objectives. When requirements do not have this linkage, which we call upwards traceability, there is a high likelihood that customers will request features and functions that are not only out-of-scope, but may also promote their own personal agendas.

In addition to meeting business objectives, requirements usually work together to solve business problems. One of the most common complaints from business analysts and project managers who gather requirements is that their customers often bring them solutions. The underlying need for the solution, however, is neglected, often resulting in a product or service that goes unused. Some questions to ask to uncover this business problem are:

• What is the problem and the resulting business pain?
• What is currently limiting you?
• What were some things that made you realize the status quo wasn’t good enough?
• What opportunity arose?
• What compliance or regulatory requirement is this project addressing?

Initial meetings with the sponsor to discuss the business and project vision, as well as the business problem(s) can be a helpful way to establish rapport and begin to build trust. When sponsors and business experts realize that the project manager is going to help them reduce the pain in their current environment, acceptance can begin. Focusing on the business need and vision also demonstrates business acumen, which in turn builds respect, and leads to trust.

Once the business problem, project objectives, and deliverables are documented, we can begin to gather our high-level requirements.

Trust and How Requirements are Gathered

Facilitated Sessions

 

There are a variety of techniques that are typically used in requirements elicitation. One of the most common is the facilitated session, in which a facilitator encourages key stakeholders to articulate their requirements in a formal meeting session. This approach has many advantages, including using the synergy of the group to help build relationships and trust.

On the other hand, the dynamics of the attendees can have a significant effect on the facilitator’s ability to elicit requirements, as well as the group’s ability to provide the information sought. The following are just a few behaviors that can contribute to an unsafe environment, thus impairing the group’s effectiveness in articulating their requirements:

• Dominant participants, particularly when they have more positional power than others in the group
• Lack of respect on the part of participants towards other participants and/or the facilitator
• Unclear roles and responsibilities related to the session. The most common issue is having the facilitator, such as the project manager, also be responsible for the outcome of the meeting, This important topic of separating the meeting results from the meeting process is widely misunderstood. Not clearly separating these two important responsibilities often creates an uncomfortable environment, which can stifle requirements elicitation and often skews the results.
• Unclear ground (meeting) rules, which guide the group’s behavior. Unless each participant actively agrees to each ground rule, there is the risk that a variety of dysfunctional behaviors will prevent the group from reaching its desired outcome and, in the process, create an unsafe environment.

One-on-Ones

Another common technique is the “one-on-one.” This technique is a way for business analysts and project managers to meet individually with stakeholders. Through these individual meetings trust can be built in several ways:

• Assess commitment. Some stakeholders do not like to make decisions or agree to decisions in meetings. One-on-ones provide a safer venue to discuss real needs behind the stated-and unstated-needs.
• Address individual concerns. Some individuals are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-ones, rather than in large groups. When elicitation is limited to facilitated sessions, these concerns go largely unaddressed.
• Address negative behavior. Sometimes stakeholders either dominate meetings or demonstrate various types of behavior that negatively impact the group. By meeting individually, analysts and project managers can focus on the behavior and, together with the individual, determine ways to reduce its impact.
• Recognize individual achievement. There are individuals who are not comfortable with public recognition. With these stakeholders, individual accomplishments are better recognized in private.

Each of these individual meetings is a chance to establish rapport and ultimately build relationships and trust.

Barriers to Elicitation

There are many barriers to effective elicitation, including (just a few):

• Distance of stakeholders. Ideally all key stakeholders would be collocated, that is, officed on the same floor or in the same building. The further removed the business experts and sponsor are from the analyst and project manager, the more difficult requirements elicitation will be. Each of the most commonly used technologies for elicitation, teleconferencing, video conferencing, and net meetings presents significant challenges which can be overcome, but which make the process cumbersome.
• Inadequate discovery time. Whether we want to acknowledge it or not, it takes time for business experts to discover their requirements, particularly the details of those requirements. For example, homeowners can discuss certain aspects of the house they want to build, but rarely can they articulate all their detailed requirements at the first meeting with the architect and builder. This is true for all business requirements, regardless of the project size. Complexities arise when different stakeholders have different requirements that must be reconciled and finalized.
• Having a project and product requirements that don’t fit into the organization’s goals and objectives. When this happens, stakeholder availability tends to evaporate. Poor or late attendance at meetings, coming to meetings unprepared and unanswered voice and emails are all symptoms.
• Not understanding the political “landscape.” Analysts and project managers who begin projects without having a clear picture of any politics involved will struggle, and the project is likely to take longer than expected.
• Reluctant or even hostile participants. If a project is meant to automate, streamline, or downsize an operation, people often fear losing their jobs. Trust is difficult to establish and complete requirements are hard to gather when providing the details may cost someone their job.

The Most Difficult Barrier – Distrust

Perhaps the most difficult barrier to overcome is stakeholder distrust of the people, project, or end product. There are many reasons why key stakeholders may not want the end product, and they may try any number of sabotage techniques. Analysts and project managers need to understand the fundamental association between the ability to gather requirements and the relationship with the stakeholders who have the requirements.

The most common reason for stakeholder caution and concern is distrust, caused by one or more of the following:

• Fear that the end product, such as a new system, will dramatically change or eliminate their jobs
• Fear that the end product will impede or slow their workflow in the name of trying to improve it
• Fear that familiar software (existing system or Excel spreadsheets) will be incomplete, inaccurate, or difficult to learn
• Fear of loss of value or stature in the organization. A new process may be less cumbersome than the old. A new system may be faster and may provide more information. And, a new product may be enormously valuable for the company. Despite all this, an individual’s business process will change, and the affected employee will have that uncomfortable lack of familiarity. Stakeholders are usually reluctant to relinquish their knowledge and expertise in an organization, and distrustful of those they perceive as taking it from them (project managers and business analysts).

Without an established relationship and trust, it will be very difficult for analysts and project managers to elicit the necessary requirements.

Risky Business

What happens to the when trust has not been established? The risk of having a less than positive outcome greatly increases. Some possible impacts include:

• Unhappy sponsors. Sponsors do not usually like having their client representatives or project managers make a habit of asking for additional time and/or funds. They also are not fond of hearing their staff complain about unsatisfactory products. When requirements are not clear from the beginning of the project, both tend to occur. An effective partnership between sponsor and project manager is the best way to address these possibilities. And the most important component of an effective partnership is trust.
• Added scope. Business clients and sponsors will figure out a way to get the features and functions they want and expect, even when they have never articulated them.

Sometimes this additional work is authorized, but more often business clients put .

• Schedule delays. It will almost always take longer to gather requirements when relationships have not been established. Each time that requirements are given to sponsors and business clients to review, more time is needed for turnaround and approval. There will most likely be more time required for revisions, as well.
• Team issues. It is easy to fall into “blame mode” when new requirements surface late in the project. Imagine this conversation:

Project manager: “This widget was not part of the approved project scope.”
Business client: “Yes it was. Right here where it says provide all necessary widgets.”
Project manager: “But you never specified this particular widget. You said all necessary widgets. This seems more like a want than a need.”
Business client: “Well, I need to have it because I’ll have to create workarounds without it.
…

What is Trust?

Trust can be thought of as “acceptable uncertainty,” and has been said to be “the big issue of the 21^st century,”). A recent survey (Golan/Harris Trust Survey, February, 2002). found that 69 percent of Americans say “I just don’t know whom to trust anymore.” Yet trust is the foundation of effective partnerships and collaboration. Building trust requires acting consistently and with integrity over time. According to the Golin/Harris Trust Survey, the top things organizations can do to build trust are:

• Be open and honest
• Communicate more openly, honestly, and straightforwardly

In addition, for parties to trust each other, each must:

• Communicate bad news as needed
• Act with integrity and honesty
• Acknowledge mistakes
• Give credit where credit is due
• Value each other’s input
• Make and meet commitments
• Be competent within the domain of expertise

Trust usually takes time to develop. We may initially trust or not trust those involved on our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgments. Analysts and project managers don’t always have or take time to let relationships develop, so here are some things that can be done to build trust quickly:

• Discuss the project objectives openly. For example, if reducing headcount is a business objective and the project in question may contribute to meeting that objective, the project manager or analyst needs to communicate the possibility to the stakeholders if asked. Trust will not be built by avoiding the conversation or asking the stakeholders to discuss it with their bosses. Such an open conversation can lead to one about the advantages to the employee of actively participating to help the organization meet its goals.
• Communicate bad news. If the project is behind schedule or needs more resources or if lack of stakeholder participation is slowing the project, it is important for project managers and analysts to address these issues with the sponsor and other appropriate team members.
• Encourage laughter. There is a strong correlation between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) builds a sense of team and a desire to work together towards a positive project outcome.
• Define clear roles and responsibilities. When not defined, not only do tasks overlap, but more commonly fall through the cracks, which invariably leads to finger-pointing, blame, and lowered morale. Clear definition helps prevent territorial squabbling and decreases the chance of misunderstanding and the resulting project delays.
• Deliver on what is promised. As the saying goes, “talk is cheap,” but trust is built on delivering what was promised and agreed on. Since trust is about expectations, find some “quick hits” you can deliver on quickly. It will help build trust for the outcomes that take longer to deliver on.

Maintaining Trust over Time

Once trust is established, it can lead the team members through project difficulties. However, once broken, it cannot easily be regained. Some things that are guaranteed to break the trust are:

• Disclosing confidential information. While we do want to encourage open communications, we cannot disclose information given to us and accepted in confidence. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communications guidelines, such as if the information is confidential, you will say so.
• Creating a competitive environment. Competition by its very nature produces winners and losers. While some stakeholders can be positively charged by competition, for others it can be viewed negatively, with resentment and even anger, leading to a weaker relationship.
• Communicating within a hierarchy, rather than having team-based communications. When we keep the entire team informed, we reduce the likelihood of gossip, speculation, and low morale.
• Micromanaging. Hovering in its various forms can give the impression that the micromanager does not trust the “trustee.” In turn the person being micromanaged will also develop a mistrust of the micromanager.
• Not making decisions. Being indecisive can be destructive to the team looking for leadership. Being decisive does not mean making all the decisions or being authoritarian. It does mean taking appropriate action to resolve real issues, remove project barriers, and move the project forward.

Summary

In conclusion, requirements elicitation requires building relationships and trust among the project stakeholders. When trust is absent, the requirements elicitation process will take longer, be incomplete, and lead to lower morale. Although building relationships takes time and effort, it can actually shorten project time and result in improved project performance. Finally, a good relationship between project manager and sponsor, built on trust, goes a long way to resolve the inevitable project issues that surface and help ensure positive project results.

References:
Golan/Harris Trust Survey (February, 2002). Retrieved 14/03/05 from http:/www.golanharris.com. O’Hara, K. (2004) Trust from Socrates to Spin Icon Books Ltd, retrieved on 06/07/05 from http://www.trustenablement.com
Trust Enabling Strategies, retrieved on 06/07/05, from www. http://www.trustenablement.com

---

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals of Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

Have you noticed the obesity epidemic plaguing North America? Hey, I’m not talking about the kind you get when eating the wrong foods – I’m talking requirements obesity. Generating fat, hulking, documents that look terrible on the shelf gathering dust is not at all conducive to enjoying the summer fun. Here are a few ideas for slimming-down those requirements. Not only will you experience the joy of actually being ‘done’ and getting into the sunshine, people will better understand what the business wants, and projects get to be more successful. How cool is that as a win-win for everyone?

1. Split requirements documents into three: scoping, business requirements, and detailed requirements. Most people don’t make this separation and end up spending way too much time detailing functionality that will never see the light of day, or in detail levels that are completely unnecessary for the task at hand. Remember – iterate.
2. Separate the WHAT from the HOW. Get clear on WHAT the business wants to do before you start to detail HOW it is going to do it. Over and again, I find myself mired in a review of details that are not only clearly inappropriate, but inconsistent, because there was just too much about how some technical aspect of the system was going to be ____________ [fill in the latest technical jargon term]. Get people back to basics here and you’ll find both faster cycle times on projects, AND, vastly simplified requirements documents.
3. Concentrate on just the right information. Business requirements fall directly out of understanding the desired state of the process flow, data flow, and business rules of the business. The actual ‘requirements’ are the structured statements describing the gap between current state and future state in these areas. Can we agree that this is Business Requirements? If so, why blather on about business case, or get into interface design, or have an opus on the history of compliance. It’s not really necessary. Sure, you need to have some additional pieces like a data dictionary if you hope to have everyone on the same page when you use the term “Customer”, but we’re not dealing with a lot of additional information.
4. I’m willing to bet, in North America, more projects have managed to kill their intended benefits by failing to identify and manage interdependency than pepperonis have been killed to make pizzas. Business professionals need to have interdependency drawn out for them because this is the stuff where executives actually have to make decisions and love you for bringing it to their attention. Get into using context diagrams – every line on that diagram is an interdependency; or, at least have a section for this in your documentation
5. Negotiate the details. Every project is different and needs different detail to bridge from business requirements to system design. It’s natural that a system selection/implementation will have fundamentally different dynamics than an off-shore design/build. In the face of high quality business requirements, the nuance of what detailed requirements should be for this project at this time can be negotiated amongst the project team. You’ll invariably end up with a tighter definition of what is needed, and better project momentum with recipients when you deliver what they’ve asked to receive.
6. Remember – ALL YOUR STAKEHOLDERS ALSO WANT TO BE IN THE SUN TOO. Make the process efficient for everyone.

This is not about being lazy – this is about being hyper-efficient when it comes to projects. In candor, executives respect analysts that can make them, and their project team, more proactive and productive. Driven to extreme, you can wallow in requirements detail until the winter months start blowing frozen air over the corpse of your project. But, is this valuable – or can you get to the right information more efficiently; get better process around developing the information, and yield successful results faster? I’ll tell you – absolutely, yes, you can! Take a look at the base of www.iag.biz research – you can be iterative, reduce time to get requirements by 58%, AND STILL have documentation quality high enough to drive down change requests by 75%. So, what do you do with the 58% less time? Why, it’s summer. Go to the beach!

I bet every experienced analyst out there knows where to chop out fat without sacrificing requirements quality. I’d encourage you to share your stories of obese requirements – or fat-chopping solutions.

---

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.

Requirements gathering techniques include the easy to send, but sometimes hard to develop, survey method to obtain data from a wide variety of people located anywhere. Surveys, however, are notorious for many faults such as ambiguity and a lack of response.

But surveys can produce a large volume of information for the gathering parties to peruse and collate, so developing good surveys is important for both the respondents who have to understand the questions and for the collators to get useful data.

Statistics Prove “IT”

It has been said you can prove anything with statistics if you ask the right question. Obviously, you need to ask the right questions to get the right data. Right?

Reality can be different. The interpretation of an ambiguous question, an open-ended question, a leading question, or a question made up of words most people do not understand, can be very detrimental to getting the answers you need.

For instance, if the requirements were related to virtualization of your datacenter equipment, you should avoid being too general or assume too much knowledge on the part of the respondent.

Ambiguous Question examples:

How does it help?
Who can use this?

Open Ended Question examples:

Why do you need this feature?
What services would help you?

Leading Question examples:

If this service were to fail, who would be affected?
Without web based access to this device, what can be done?
Who amongst your group has the necessary required certifications?

The “Right” Questions

So what is the right question to ask? You do not want to insult your respondent nor do you want to assume they understand the situation or concepts entirely.

How can you ask the right question? Ask an eight year old. Or rather, pretend the audience is eight years old. Assume they do NOT have a vast knowledge of the topic, a slanted knowledge of the world, or possibly a jaded view of the system. Use simple language that is less likely to be interpreted differently.

Provide respondents with some background information or assumptions at the beginning of the survey, or point them to relevant documents or websites they can use to clarify the concepts and issues.

Avoiding Acronyms and Industry Jargon

Often times, in the technical world, we have developed our own jargon or acronyms for the myriad technologies, services, applications, and such that we developed and/or have to deal with every day. For instance, SMB is one acronym that has vastly different meanings depending on your perspective. A recent book had this acronym within the title, and it was very confusing for the network specialist who later found out the book was meant for a general business type audience. What does it mean to you? In the book context, it was Small- to-Medium Business, to the technician, Server Message Block. To my kids on their instant messaging service, it meant So Much Better.

The standard axiom of KISS (or, Keep It Simple, Stupid), applies for questions – keep them short and simple but clearly to the point. In some cases, a preliminary paragraph stating the base assumptions will help to clarify the premise for the questions.

In Requirements Gathering

A common method of gathering requirements from many stakeholders, when interviewing or workshops are not prudent, is to send a general topic survey of questions in the early phase of discovery. These general questions should lead toward more specific questions as the discovery phase progresses. This is when specific questions become more critical. The questions must be very topical or delivery-oriented, maybe even very technical in nature, and yet they must ensure the respondent clearly understands both the premise and concepts.

For instance, a general trend today is toward using virtualization. Most people have no idea what this really means or even implies. To make your survey results more coherent, you may need to include references to websites, local or external, that explain the concepts. Have multiple people within your organization peruse these materials to assess their usefulness, and employ a wide cross-section of people to gauge if the content is technical in nature. You should not rely exclusively on technicians for feedback.

Survey Says …

The right questions on a survey may not always be enough. In some cases, the options to respond and/or the choice of responses can affect your survey results.

Fixed answers, such as in multiple choice, should give the reader plenty of leeway for their decision. Be as wordy as necessary for each choice, without too many overlapping or confusing variations of the same request.

Assumptions

Surveys have to assume some level of knowledge for the respondent, but that is not always achievable when dealing within different technical or managerial staffing levels.

For instance, the following question assumes a great deal of knowledge on the part of the respondent:

Q. How would your department benefit from using virtualization?

This is a rather open-ended question requiring the respondent to be very familiar with the topic and critical about the lack of virtualization use for a long time. To improve this question, provide some options that will make sense rather than have the respondent come up with all the answers:

Q. In an effort to reduce our data-center footprint, the company has been looking into the possibility of moving toward the use of specialized hardware that maintains the separate host services on a centralized, redundant virtual computing platform. Each current host that meets all the criteria (see website //xxx/criteria for details) for being virtualized will be transitioned to the virtual environment. How would your department benefit from using virtualization?

Redundancy [ ] Backups [ ] Ease of recovery [ ] Availability [ ]
Reduce licensing requirements [ ] Reduce number of physical boxes [ ]
Reduce management overhead [ ] Reduce resources [ ]
Expand service levels [ ] Ease of testing [ ] Ease of deployment [ ]

This may be too limiting, instead provide a range of responses

Q. [same intro] How would your department benefit from using virtualization?
(Scaled response with 1 being the least important and 5 being the most important)

This might be followed-up later with questions that specifically define some of the key attributes for switching to a virtualized platform or not.

Q. Select all that apply to your server:

Server provides: [ ] file [ ] print [ ] dns [ ] AD [ ] other _____
Comments: _________

Service must be: [ ] kept separate [ ] own IP [ ] behind firewall
Comments: _________

Setup requires: [ ] Win2K [ ] Win2K3 [ ] Win2K8 [ ] XP [ ] Linux
Comments: _________

Survey Choice Option Default Settings

Surveys often provide a scale for their responses. Some include as few as three options, while others may have 10 or more within the range. There is no best answer, although five to eight choices are probably more than adequate for most ranges.

Imagine a now defunct restaurant asked you to fill out their web-based survey as you left the restaurant. They failed, however, to put an easy-to-find link to the survey on their website. After searching the entire main page, and a few subsequent pages, a small, bottom menu link was eventually found. Within the survey web page, there was a simple explanation of their scale being from 1 to 5, for the 10 questions presented. Each question ended with the same simple drop down list. The default drop down value was preset to 1 for all 10 questions. This may have been planned or not, but it might produce a lot of low results.

Common survey choice ranges include:

“Excellent, Good, Fair, Poor, N/A”

“Strongly Agree, Agree, neutral, Disagree, Strongly Disagree”

“1=Very Bad to 5=Excellent”

“1 is worst, and 10 is best”

Clearly, each of these ranges requires questions that would elicit such a response from the expected target audience. However, do not expect that you will get the top-level choice. How often are you told you are doing an “excellent” job as apposed to a “good” job? Probably not very often. So why would you expect the general public to give a 5 or 10, an Excellent or Best response? Why would you then assume anything else is unfavorable if you have not clearly defined to the respondent what each choice represents?

Do Ranges Reflect Expectations?

The option “Good” could mean many things to many people such as: good, good enough, acceptable, expected norm, at least as good as you expect, etc. This is especially true when the “Excellent” response is the only one good enough. If anything other than “Excellent” is not good enough, ensure the respondent knows that they have to explain why they did not select “Excellent.”

In many hotels, you are given a document requesting that you call the local manager if there is anything that is not to your liking at any time. They want to provide you with a “10 out of 10” experience every visit. They conveniently provide a survey form for when you leave. What do you think happens if you do not fill out the survey for your stay? Perhaps an automatic “10” for that visit?

In some local grocery and department stores, they now have “Outstanding Service” forms you can fill out to honor anyone who has gone out of their way to provide exemplary service for you. No mention of where to enter complaints.

Can you remember your last few visits to a restaurant and a large department store? What was your experience? What was your expectation? What would you expect to be asked? Which range would you expect for the answers?

Surveys Everywhere

Surveys are now ubiquitous throughout the world and we have developed a love-hate relationship. We love to send them but hate to respond to them. We, and this is a collective “we,” tend to ignore most surveys unless there is something in it for us. There are companies on the Internet that offer rewards for filling out surveys from their clients.

Many years ago, a former boss had a great philosophy about surveys done by large groups of customers. He would sort them according to rank, from best to worst, and then ignore the first and last to get the average. He assumed that there was always one in the crowd who had a weird idea of what “good” meant, and he balanced this against those who just quickly gave a general “good” or “excellent.”

There are lots of ways to interpret survey results – many of them bad!

The professional sports teams have all sorts of methods, or “improvements,” to make their stats look good. There are rules for how stats are accepted and interpreted. They usually keep a running total, not just the single events. Keep this in mind when you are working on your results. Taken in small groupings, there can be wide swings in averages. Taken in gross, these averages of averages are more consistent.

In Summary

The usefulness of a survey is in the responses that are received. Be as helpful as possible to the respondents by ensuring they have sufficient information and knowledge to complete the survey. Strive to provide a reasonable and clearly stated range if used. Restrict the space for open-ended questions and keep the questions as simple and succinct as possible, so that anyone can understand each question. Adding an incentive for respondents to complete the survey quickly may also speed up the process. Surveys can take a long time to prepare, collect, and collate but with careful planning, a well-executed survey can simplify the process of gathering requirements.

---

David Egan is a Course Director and developer of content for more than 20 Global Knowledge courses. David has more than 20 years of teaching experience including more than five years of teaching ‘on-line’ virtual classes over the Internet using Centra, Interwise and iLinc virtual classroom services. David has also written technical books and delivered adult learning seminars on UNIX, Linux, Microsoft Operating Systems and Services, as well as Business Process Analysis and Project Management since 2005. David and his family live in a suburb of Vancouver, B.C. This article was originally published in Global Knowledge’s Management in Motion e-newsletter, Business Brief. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training.

Copyright © Global Knowledge Training LLC. All rights reserved.