Skip to main content

10 Ways to Explain Things More Effectively

Written by Global Knowledge on . Posted in Articles.

In the course of your work as a business analyst eliciting requirements, you may sometimes need to explain technical concepts to colleagues, sponsors and customers. Having them understand you is important not only for technical reasons, but also to ensure a successful outcome for the project. Here are a few tips to help make your explanations understandable and useful.

1. Keep in Mind Others’ Point of View

You’ve probably seen the famous illusion that looks like either a young woman or an old woman. Two people can look at that same picture, and they can have opposite views of what they’re seeing. Keep this idea in mind when explaining a concept. Something that might be perfectly understandable to you might be incomprehensible to someone else. Don’t be the person customers complain about as using “geek speak.”

2. Listen and Respond to Questions

It’s easy to become annoyed when someone is asking questions. However, try to resist that reaction. A better attitude is to be happy that the other person is interested enough to ask questions. To minimize confusion and misunderstanding, try to paraphrase or summarize a question before you answer it. This step is particularly important if you’re in a group setting, and you’ve just taken a question from someone in the audience. Repeating the question for the entire group helps everyone better understand your answer.

3. Avoid Talking over People’s Head

When you explain things to people, do their eyes glaze over? Chances are it’s because you’re talking over their head. Symptoms of such behavior include the use of jargon and acronyms. Remember, the people you’re talking to may lack your specialized knowledge, so you should use common, readily understandable terms.

The same goes for acronyms. They’re important, but if you use them, define them in “longhand,” followed by the acronyms in (parentheses), so that everyone’s clear. Doing so avoids the scenario of situation normal, all fouled up (SNAFU).

Even within IT, the same acronym can mean different things. For example, both “active server page” and “application service provider” have the acronym ASP. A story from the Vietnam War era further illustrates this point. A young woman brought her boyfriend home to meet her father, a retired military officer. The woman was nervous because the boyfriend was a conscientious objector. When the father asked the young man to talk about himself, the latter replied, nervously, that he was a CO. The father clapped the young man on the back and congratulated him, thinking the latter was a commanding officer.

4. Avoid Talking Down to People

Avoid the other extreme as well. Don’t insult people by assuming that they’re only as intelligent as a three-year-old. An attendee at one of my communications training classes described it aptly as “Barney communications.”

Greek mythology has references to two monsters, Scylla and Charybdis, who sat on opposite sides of a narrow strait of water. If a ship sailed too close to Scylla, it was destroyed and the sailors eaten up. If the ship sailed too close to Charybdis, it was destroyed by a whirlpool that Charybdis created. The ship had to go right between them to survive. Follow that same principle with your customers: Make your explanations neither too complicated nor too simple.

5. Ask Questions to Determine People’s Understanding

The people you’re talking to shouldn’t be the only ones asking questions. You should be asking questions as well, to make sure they understand. Your questions can be open ended, which gives people a chance to provide detailed information, or they can be close ended, which generally calls for a simple yes/no response. In either case, asking questions tells people that you’re interested and concerned that they understand.

6. Focus on Benefits, not Features

What’s the difference? A feature is some inherent property of an object. A benefit, on the other hand, is a way the feature helps a person. For example, one of the features of a Styrofoam cup, because of the material used, is insulation. Someone who’s planning a party probably doesn’t care how the cup provides insulation. That person is more interested in the fact that such a cup keeps hot things hot and cold things cold – the benefit.

In the same way, try to focus on benefits of technology rather than features of technology. This distinction becomes more important the higher the level of the person you’re talking to. The CFO probably has little need to know about the specific commands and steps involved in setting up database mirroring. That person will want to know, however, that such a practice reduces the chances of data loss.

7. Use Analogies to Make Concepts Clearer

An analogy involves explaining an unfamiliar concept in terms of a familiar one. For example, in drawing an analogy between a firewall and a bank teller, you could say that people don’t just go directly into a bank and take money out. They go to the teller and identify themselves; the teller makes sure they have enough money; and then gives them the money. Similarly, a firewall ensures that people who want access to a system really are permitted to have that access.

When choosing an example for an analogy, first figure out the general principle you’re trying to explain. Then, choose something from real life that illustrates that principle. Say, for example, that you’re trying to explain memory leaks. Suppose you conclude that the principle involved is that of taking without giving back completely. An example/analogy might be the consequences of pouring a cup of pancake batter into successive measuring cups, or the consequences of lending money to your brother-in-law.

8. Compare New Concepts to Familiar Ones

Another illustrative technique is to use a familiar or existing product as a comparison. If you’re explaining a new release of a software product, the comparison is easy. Simply discuss the additional capabilities it has over the previous one or how key features are different. If the person hearing your explanation is also an IT person and is familiar with different or older technology, try explaining in those terms if you can

9. Use the Concepts of Subsets and Supersets

Brooklyn is a subset of New York City, because all of it is a part of that city. Conversely, New York City is a superset of Brooklyn, because the former contains, in addition to all of the latter, other boroughs as well. These concepts are helpful in describing, for example, a “lite” versus a “professional” version of a software product. If the latter does everything the former does, plus more, it truly is a superset of the former, and the former is a subset of the latter. Be careful, though: If the “lite” version does even one thing that’s missing from the professional version, there’s no longer a subset/superset relationship.

10. Confirm that Your Explanation Makes Sense

Once you’ve finished explaining your point or answering a question, ask a final question yourself. Make sure the people who heard your explanation truly did understand it. Consider asking them to give you the explanation in their own words, just to double-check.

Don’t forget to leave your comments below

Calvin Sun works with organizations in the areas of customer service, communications, and leadership. His Web site is http://www.calvinsun.com and his e-mail address is [email protected]. For information about Global Knowledge or to register, visit www.globalknowledge.com or call 1-800-COURSES.

Copyright ©2009 Global Knowledge Training LLC All rights reserved.

Creating Compelling Executive Summaries in Seven Easy Steps

Written by Peter Dillon-Parkin on . Posted in Articles. 1 Comment on Creating Compelling Executive Summaries in Seven Easy Steps

Today’s fast-paced business environment is rife with quick digital communication in the form of e-mails, texts, tweets and sound bites. Unfortunately, this has had a negative effect on traditional reading, resulting in a great deal of frustration for anyone trying to get a document-any document-read by individuals in their organization or by prospective clients. However, the executive summary is the one part of any business document that is guaranteed to be read and is therefore your most effective tool for communicating your message. Whenever you have anything at stake, it’s critical that your executive summary delivers the goods.

Let me illustrate my point as to how crucial a well-prepared executive summary can be: Pat was asked to investigate a new replacement program for her company’s PCs. Pat researched the topic thoroughly, wrote and rewrote her report until she was happy with it and presented it to management. And then…nothing, even though she had pointed out there was only a small window of opportunity to take advantage of the initiative.

Curious to know what happened, Pat sought feedback. The comments she heard suggested that none of the managers who had received the report had actually read much of it. Furthermore, even those who seemed to have some idea of what the report was trying to convey didn’t have a complete understanding of the actions required or the benefits. That’s because Pat hadn’t gotten the most critical part of her report right-the executive summary.

At the root of the problem was Pat’s misunderstanding of the purpose of the executive summary. She thought it was simply meant to be an “overview” of the document. It’s not, and this is a common error. Think of it this way: the executive summary is a one-page proposal for the rest of your document-the section of the document that gives your readers all the information they need to understand both your point and your recommended course of action. Sadly, few executive summaries ever deliver the value that both readers and writers want.

Fortunately, Pat was able to resubmit the report. This time, she did her research and identified a seven-step method that would help her create an effective, persuasive executive summary.

The executive summary of your report or proposal isn’t just a summary-it’s your one chance to quickly and concisely get your message across to your readers. It should get their attention, let them know why the document is important to them so they keep reading, act as a guide so they can discern which parts of the report or proposal are relevant to them and, most importantly, it should sell your conclusions. Applying these seven steps to your next executive summary will help you achieve precisely those results:

Step 1: Give Your Summary a Meaningful Title

Don’t call your summary “Executive Summary”. With any proposal or report you would write, let the title indicate what the content is. Pat’s new title was: “Two-Year Computer Replacement Programme”.

Step 2: Give It a Benefit-Oriented Subtitle

Add a subtitle that gives your readers a reason to care about this proposal. They’re more likely to read more of what you wrote if they believe you’re going to deliver something of value. Just the same, if they can identify that they aren’t interested, or aren’t impacted, they can stop reading. Pat used “Saving Money and Increasing Workplace Morale”.

Step 3: Identify Your Objective

Now bring out the key pain point or opportunity that your document addresses and back it up with two or three other points. Don’t worry if you can’t explain everything in just a few bullet points-this is a summary, after all. For the PC replacement program, Pat described the primary change in the company’s purchasing program and two features of the plan:

  • Buy “last year’s model” to save money with no loss of functionality
  • Give 90% of our workers a new PC every two years

  • Limit PC functionality to what’s required by our business

Step 4: Give Recommendations

Now it’s time to provide the casual reader with enough information to understand what you’re recommending or documenting. Pat described how the new process would work: “We currently replace a low percentage of PCs each year with the standard model of our supplier. It would be cheaper to replace half of our PCs each year by buying low-end models in bulk. The software we use runs on the lowest specification PC available, so buying a higher specification is pointless and expensive. Our staff will be happier with the increased stability offered by a more frequent replacement program. After two years, the PCs can be donated to the ‘Computers For Schools’ program for a tax deduction higher than the PCs’ depreciation”.

Step 5: Financial Details and Downsides

After those details, summarise the associated costs or saving. Don’t try to hide them. No one is going to purchase an unpriced item and readers will not appreciate having to dissect your report to find your costs. Pat summed up the financials in one sentence: “Because we are buying low-end PCs that suppliers want to dispose of, replacement costs will drop by $5K in the first year”. If there is a downside to the issue, this is also the time to tell your reader. Telling your reader any bad news up front makes your readers more likely to trust you. Pat had recognised one potential problem: “We will have to buy when stock is available, not whenever we want to”.

Step 6: Status

If there is an urgency associated with the situation, you should address it at this step. Pat made it clear that management needed to act immediately: “We have negotiated agreements with several potential suppliers to take on their end-of-cycle surplus. The new program can be started as soon as a budget is available”.

Step 7: Action

Finally, tell readers what to do next. If you don’t tell your readers what must be done, they may do nothing, which is what happened to Pat the first time through. This time Pat finished the summary with specific direction: “A budget needs to be set for the IT department to purchase the first job lot of PCs if we are to maximise value for this financial year”.

After reading the new summary, management knew:

  • What Pat proposed
  • What the benefits to the business were
  • What the cost or saving was
  • What the urgency level was
  • What to do next

And this time, Pat’s report was acted upon.

Don’t forget to leave your comments below

Peter Dillon-Parkin is a business analyst/consultant working with clients in Europe, the U.S. and the Middle East. Peter has written Learning Tree Course 212, “Building an Effective Business Case”, Course 901, “Introduction to Business Intelligence”, Course 219, “Business and Report Writing”, and Course 221, “Writing for the Web”. He also teaches courses in Learning Tree’s business analysis curriculum. Learning Tree International is a leading global provider of truly effective training to management, business and information technology professionals. Since 1974, over 13,000 public and private organizations have trusted Learning Tree to enhance the professional skills of more than 1.9 million employees. For more information, call 1-800-843-8733 or visit www.learningtree.ca.

Can a Person Function as both BA and PM on the Same Project?

Written by Elizabeth Larson on . Posted in Articles.

One of the most frequently asked questions I still get from my clients is whether or not one person can be both a PM and a BA on the same project. The answer, of course, is yes, they can. A related question, though, is whether or not they should. I think there are really two different answers to two different questions.

If the question is could the BA and PM play the same role on the same project, my answer is that I can think of many situations where a single person could perform both functions. For example, if the organization does not recognize the importance of either role, if it doesn’t have enough resources for both roles, if a project is known to be “small,” when the team has worked together and is a high-performance team, one person could play multiple roles. Functioning in both roles on one project can work, especially when it is clear to everyone which “hat” is being worn at any given moment.

On the other hand, we might ask under what circumstances would it make sense for the BA and PM to play the same role. For me this is a harder question to answer. Here are some considerations:

  1. Generally speaking, there is an inherent difference of objectives between the two roles. The PM’s role is to meet the project objective (PMBOK® Guide Fourth Edition Section 1.6). The BA’s role is to help organizations to reach their goals (BABOK® Guide 2.0 Section 1.2). This is a subtle but important difference. Organizations usually complete projects to help them meet their goals. Project objectives are more specific than organizational goals. Put another way, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.
  2. Another difference is one of focus. The PM typically focuses on the project-creating baselines and managing project constraints, communications about the project, resolving issues about the project, getting the resources working on activities and tasks. The BA typically focuses on the end product. However, those lines are not always clear- cut. According to the BABOK® Guide 2.0, BAs do need to focus on the project when they plan and monitor the business analysis work, which is part of the project. That is, planning how the business analysis work will be completed, how formal the work will be, what documents, if any, will be produced, what approach will be taken, how the work will be tracked and reported etc. is project work. The focus is on the project, not the end result.

    However, doing project work as part of business analysis does not mean that the roles of PM and BA overlap. The project manager gets input from a variety of people on the team including the BA and uses that information to manage the project.

Although the PM may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. It seems to me that:

  1. It takes time to do both jobs well. Certainly on “large” projects, it is a full-time job to manage the project and to manage the end product requirements. Trying to do both will usually mean increasing the risk and compromising the quality of both the project and the end product.

    One of our clients recently completed a study on separating the two roles, which had previously been combined. This assessment was undertaken in part because during different phases of the project, the PM role was neglected, and during other phases the BA role was. They concluded that on most projects both roles were needed and recommended the separation.

  2. Because there is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want to deliver the end product on time and within budget. Business analysts want to ensure that customers can actually use the end product once it has been implemented.

    I can almost hear an internal conversation the combined PM/BA might have: the PM voice, sitting on one shoulder, says “But this has to be complete by Jan. 15th so we need to take these shortcuts.” The BA voice, sitting on the other shoulder, says “But we need to take time to do this right. If we put this into production now, it will cause defects, rework, workarounds…” The PM voice replies “if we don’t meet the date, we’ll destroy all their trust in us.” The BA voice says, “If we don’t get this right, we’ll destroy all their trust in us.” When we wear multiple hats, which voice do we listen to?

Personally, I have found it helpful to have both roles on projects, even when the project is “small.” So although it may not be necessary to have both a PM role and a BA role on every project, it sure makes sense on most.

Don’t forget to leave your comments below.

Elizabeth Larson, PMP, CBAP,CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].

Business Analysts Need to be Project Managers

Written by Kupe Kupersmith on . Posted in Articles.

I know what you’re thinking. Kupe has lost his mind…he’s a flip-flopper! In my last post, What?! You Don’t Want to Be a Project Manager, I gave my view on why companies need to have career paths for their BAs other than to become a Project Manager. I sit here today still defending that position. But, I do feel BAs with project management experience have a slight advantage. As some of you know, earlier in my career, I went from an accountant to business analyst. What you may not know is I took a project manager role at one point in my career. I was one of those new guys trying to move up that company ladder and thought all my happiness would come from being a PM. Wrong! The good part of that experience was that I was formally trained and had the opportunity to work with a great mentor. My last year and a half as a PM I had to play both roles, PM and BA. I found myself spending more time on the analysis side of things, therefore neglecting some important PM tasks. It was at that time I realized my true love was business analysis. I found an opportunity to go back to business analysis full time and never looked back.

With every situation I try to find the positive. For me, gaining PM experience made me a better business analyst. In the spirit of this week’s US holiday, Thanksgiving, here are the top three reasons I am thankful for being a project manager.

Planning

I am thankful for understanding the basic concepts of a work breakdown structure. As business analysts, it is our responsibility to plan our activities. Then working with the project manager our plan gets incorporated into the overall project plan. When developing my plan I am able to layout my schedule with proper dependencies and include adjustments for my working time and my stakeholder’s working time. With the help of MS Project I can see where I need to add or where I can reduce time. For this I am thankful that I have PM experience.

Project Lifecycle

I am thankful for understanding the full project lifecycle. As business analysts, everything we do impacts all phases of a project lifecycle. As a PM I was able to get better insights into the needs and challenges for development, testing and implementation. Every project we work on is a change to the people for which we implement solutions. As a PM, I learned to work closely with the business stakeholders to develop strategies to help the user community implement and adjust to the new or enhanced system. For this I am thankful I have PM experience.

Leadership/Motivation

I am thankful for being able to lead and motivate teams. As a business analyst and a project manager, you have to lead and motivate without authority. My approach as a project manager was to lead and motivate by building a strong trusting team. By coming together early in the project and determining the tasks needed to accomplish our goals, everyone was bought-in to the project approach. Together we were accountable for our successes and failures. As a business analyst, I find the need to motivate my business stakeholders to participate in the analysis approach every now and then. In my post, Mr. Business Analyst, You’re Not a Good Fit!, @gbusby commented that a senior level BA role requires selling. I agree 100%. Many times stakeholders still want to give a few statements about their needs and then let the project team work their “magic.” That approach almost guarantees failure, so we need to find creative ways to get these stakeholders to fully participate. As a BA you may not be leading the entire team, but at senior levels you will find yourself leading a team of BAs on a project. You need to be able to lead and motivate this group. For this I am thankful I have PM experience.

Even though I do not want to be a project manager, I found my experience helped me become a better business analyst. What role(s) did you have in the past that helped you become a better business analyst? What are you thankful for?

Thank you for reading and leaving your comments,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

Requirements; They Can Make or Break a Project

Written by Richard Frederick on . Posted in Articles.

Every project an organization undertakes has requirements. It doesn’t matter if it’s building hardware solutions, developing software solutions, installing networks, protecting data, or training users – for the project to be a success, knowing what the requirements are is an absolute must.

Requirements exist for virtually any components of a project or task. For example, a project may require specific methods, expertise levels of personnel, or the format of deliverables. This article will discuss the various kinds of information technology requirements, their importance, the different requirement types, the concept of requirements engineering and the process for gathering requirements.

It’s an area that every business analyst is very familiar with but, to paraphrase an old saying, “familiarity sometimes breeds contempt” so it’s well worth taking the time to look back on what requirements are all about and how we’ve been handling them since we first learned about them. Let’s get back to some basics.

What Are Requirements?

The IEEE Standard 1233-1998, IEEE Guide for Developing System Requirements Specifications, defines a well-formed requirement as a statement that:

  • States system functionality (a Capability)
  • Can be validated
  • Must be met or possessed by a system
  • Solves a customer problem
  • Achieves a customer objective
  • Is qualified by measurable Conditions and bounded by Constraints

Specifically, a well-formed requirement should contain:

  • Capability
  • Condition(s)
  • Constraint(s)

According to the Oxford American Dictionary:

Capability as a noun is defined as the capability of doing something; or a power or ability, e.g, “the capability of bringing the best out in people” or “the capability to increase productivity.” However, when used with an adjective, a capability describes a facility on a computer for performing specific tasks, e.g., “the computer has a graphics capability.”

Condition as a noun is defined as the state of something, especially with regard to its appearance, quality, or working order, e.g., “the wiring is in good condition,” or “the bridge is in an extremely dangerous condition.” A condition can also be a state of affairs that must exist or be brought about before something else is possible or permitted, e.g., “for a member to borrow money, three conditions have to be met,” or “all personnel should comply with this policy as a condition of employment,” or “I’ll accept your offer on one condition.”

Constraint as a noun is defined as a limitation or restriction, e.g., “the availability of water is the main constraint on food production” or “time constraints make it impossible to do everything.”

Wherever There are People, There are Problems.

Different institutions are created to solve these unique, large-scale problems: government, healthcare, transportation, telecommunications, etc. These institutions, utilizing a “systems approach” for planning, organizing, and controlling resources, initiate projects to focus on “specific objectives” or components of their problems.

Importance of Requirements

Requirements are the documented needs of a project that are gathered to identify the specific constraints (scope) of each project component and act as the foundation for everything else that occurs in a project.

Project Failure

Requirements are considered by many experts to be the major reason projects do not achieve the triple constraint of “on-time, on-budget, and high quality.” Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies have shown that failure to meet requirements is the biggest problem in projects. Most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality projects on-time and on-budget.

The Problem

Since the invention of computers, there have been three primary issues to meeting project requirements.

First, the technology learning curve is advancing much faster than the business learning curve. In other words, while technology concepts are changing rapidly, business management concepts have not changed at the same pace.

Second, there is a huge disconnect in the language between business people and technology people. Each group has its own taxonomy (glossary) for how to operate.

Third, because businesses are so reliant on technology, it is more important than ever that the two environments align to insure that the systems being built match the requirements of the business needs.

Alignment

An institution’s ability to efficiently align resources and business activities with strategic objectives can mean the difference between succeeding and just surviving.

The world is cut-throat. To achieve strategic alignment, institutions are “projectizing” their business to monitor performance more closely and make better business decisions about their overall work portfolio.

Governance

Because of errors and omissions on the part of institutions in the public trust, (e.g., government agencies and publicly held corporations) the U.S. Congress has passed legislation to require transparency throughout organizations to eliminate opportunities for fraud.

Transparency is the ability of an institution’s governing body to see through the organization. The way to see through an organization is by documenting – creating a paper-trail – all of the transactions that occur. Today, institutions utilize their information systems and IT departments to insure that the electronic paper-trail exists and is working correctly.

The costs of non-compliance are very large and can include incarceration for the institution’s executives. However, the benefits to be derived from transparency should be the dream of every executive; transparency will bring about the ultimate goal of executives having access to “any data, on any part of the business, from anywhere, and at any time.”

Re-Work

Due to the “time value of money,” all institutions must put their financial resources to work. If there are errors in requirements, they increase the need for re-work and decrease an institution’s operational efficiency. This works against every institution’s goal of managing for value.

Therefore, the earlier requirements problems are found, the less expensive they are to fix. The best time to fix them is when you are involved in gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The Challenge

The requirements phase is considered by many experts to be the most difficult part of any project. The hardest requirements problems to fix are those that are omitted.

This really becomes the requirements analyst’s dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn’t ask, the stakeholder doesn’t state requirements.

Types of Requirements

Business Objectives

The overall business goals and guidelines for the project are the business objectives. Business objectives help provide the foundation for a project and are obtained normally from management or from existing company documents. For example: Company XYZ will increase sales domestically by 50 percent within two years.

Business Requirements

Requirements from stakeholders are business requirements. These requirements can include business processes the system needs to support; various constraints such as cost, resources, schedule; and more.

Business requirements often come from managers, although workflow processes (how people do their jobs or should do their job, if you are trying to optimize business processes) will probably come from those actually doing the work or end-users of the system.

Stakeholder Requirements

A stakeholder is anyone with a vested or substantive interest in the project. Stakeholder requirements include the needs of stakeholders both internal and external to the organization. The challenge of any project is to accurately identify all of the stakeholders, and to elicit and understand their needs.

End-User Requirements

Needs from those who will directly or indirectly interact with the system are called end-user requirements. These include requirements for the documentation and user interface, which can be very complex and are often a source of error.

System Requirements

System requirements come from analyzing the business objectives and stakeholder requirements. While business objectives and stakeholder requirements are written in business terms and are from a real-world perspective, system requirements are more rigorous, more formal, and are written in systems (technical) terminology. For example, a stakeholder requirement might refer to “Company XYZ Monthly Sales Report,” while a system requirement might refer to that same thing as “XYZMoSalesRept.doc.”

System requirements are high-level requirements for an entire system. Systems may include subsystems (for example, hardware subsystem, operating subsystem, software subsystem [or subsystems], or network subsystem).

Software Requirements

Software requirements, such as the functionality necessary for operating within a harsh physical environment or the graphical user interface needed between the user and the machine, are detailed, specific requirements written for a software system (or subsystem).

Requirements Engineering

According to the IEEE Software Engineering Body of Knowledge® (SWEBOK®), requirements engineering includes four processes: elicitation, analysis, specification, and validation.

Elicitation

Requirements elicitation is concerned with where project requirements come from and how the analyst can collect them. It is the first stage in building an understanding of the problem the project is required to solve. It is fundamentally a human activity, and is where the stakeholders are identified and relationships established between the project team and the customer. It is variously termed “requirements capture,” “requirements discovery,” and “requirements acquisition.”

One of the fundamental tenets of good project management is good communication between users and the engineers. Before development begins, requirements specialists may form the conduit for this communication. They must mediate between the business domain of the users (and other stakeholders) and the technical world of the engineers.

Analysis

Analysis is the process of:

  • Detecting and resolving conflicts between requirements
  • Discovering the bounds of the project and how it must interact with its environment
  • Elaborating system requirements to derive software requirements

The traditional view of requirements analysis has been that it be reduced to conceptual modeling, using one of a number of analysis methods such as the Structured Analysis or Design Technique (SADT).

While conceptual modeling is important, analysis includes the classification of requirements to help inform trade-offs between requirements (requirements classification) and the process of establishing these trade-offs (requirements negotiation).

It is important to describe requirements precisely enough to allow the requirements to be validated, their implementation to be verified, and their costs to be estimated.

Specification

For most engineering professions, the term specification refers to the assignment of numerical values or limits to a product’s design goals. Typical physical systems have a relatively small number of such values. Typical software has a large number of requirements, and the emphasis is shared between performing the numerical quantification and managing the complexity of interaction among the large number of requirements.

So, in software engineering jargon, “software requirements specification” typically refers to the production of a document, or its electronic equivalent, which can be systematically reviewed, evaluated, and approved.

For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: concept of operations, system requirements, and software requirements.

Validation

The requirements documents may be subject to validation and verification procedures. The requirements may be validated to ensure that the software engineer has understood the requirements. It is also important to verify that a requirements document conforms to company standards, and that it is understandable, consistent, and complete.

Formal notations offer the important advantage of permitting the last two properties to be proven (in a restricted sense, at least). Different stakeholders, including representatives of the customer and developer, should review the document(s).

Requirements documents are subject to the same software configuration management practices as the other deliverables of the software life cycle processes. It is normal to explicitly schedule one or more points in the requirements process where the requirements are validated. The aim is to pick up any problems before resources are committed to addressing the requirements.

Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right software (that is, the software that the users expect).

Requirements Process

Identify what information is needed. What are the goal(s) and the purpose? Identify who or what is likely to have this information. A coverage matrix, a spreadsheet showing stakeholders and the information needed, can be a useful tool for this step.

Determine effective techniques to get this information from this person or these people. Write out the questions. Even if you are only job-shadowing, you are still observing in order to answer questions.

  • Obtain the information.
  • Process the information.
  • Refine and confirm the information through storyboarding and prototyping.

  • Write the stakeholder’s requirements document.

Progressive Elaboration

The concept of Progressive Elaboration states that the more we know about something, the better we are able to manage it.

Here is what we know:

Projects begin with “1% of what we know about what WE KNOW,” and “1% of what we know about what WE DON’T KNOW.” HOWEVER, the remaining 98% is “what WE DON’T KNOW about what WE DON’T KNOW” until we begin.

Iteration

Iteration can be considered as “loops around the track” (i.e., how many times should you repeat a process before you are done?) This course will go through the requirements elicitation (and analysis, specification, and validation portions of requirements engineering) sequentially. However, in reality (for large projects, especially), the process is much more iterative. You may need to iterate among the various stakeholders. For example, you may interview the department director, and then, after interviewing her staff, realize you have more questions for her.

You may need to iterate among the processes. For example, you may be writing the requirements specification and realize you omitted an important end-user.

Management

Requirements management is a supporting or infrastructure process that goes on throughout the entire life cycle. Requirements management, or managing requirements, usually involves three major components: Managing change, tracing from stakeholder needs all the way through delivered software, and identifying needed attributes on each requirement – things such as status, author, and priority.

Testing

Requirements are the foundation for testing.

Acceptance Testing

Acceptance testing should be based on stakeholder requirements. System testing is based on system and software requirements. Integration testing (plugging together the parts of the system) is based on architectural or high-level design; and unit or module testing is based on the design specifications (not the code itself).

What are some of the implications?

First, it’s impossible to do effective testing if the front-end documents do not exist or are not well-written. Second, all requirements must be testable.

How do you ensure they are testable?

The best way is to have the tester create the test cases while the requirements documents are in draft mode, nearing completion. If the tester cannot create a valid test case, the requirement is not testable and, therefore, should be rewritten now rather than weeks or months after this requirement was used for analysis, design, and coding, and then fails during testing.

Remember

The earlier you find defects, the cheaper they are to fix. This is one reason to find defects early.

How do you write a testable requirement?

First, requirements should be written in the form “A user shall…” (for stakeholder requirements, substituting any role for “user”), or “The system shall…” (for system and software requirements). Second, measurable terms must be included, such as “The system shall return a prompt within three seconds…,” not, “The system shall return a prompt as quickly as possible.”

Don’t forget to leave your comments below

Richard Frederick, PMP, MCP, MSF is a graduate of Southern Methodist University (SMU) Cox School of Business, a Project Management International (PMI®) certified Project Management Professional (PMP®), a Microsoft® Certified Professional (MCP) and Microsoft Solution Framework (MSF) Practitioner. Richard “Ric” Frederick gained his broad range of experience by treating problems as opportunities and creating innovative solutions. With work in government at the Superconducting Super Collider laboratory, in education with Apple Computer, Inc. and in business with Assured Solutions (his own consulting company), Ric has earned and applied the necessary techniques to achieve both tactical and strategic goals. His efforts to simplify complex issues and turn losing projects into winners have met with outstanding success. Ric, a distinguished speaker and teacher, periodically shares his expert knowledge of industry standard techniques in Program and Project Management Seminars. His insights reveal how to bring order and success to the often-times chaotic program management process.

Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge courses:

Business Analysis Essentials and Requirements Development and Management

For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a sales representative.