1231

Welcome back, everyone! This week we complete the “collect requirements” process by actually writing down stakeholder requirements. We’ll see that there may be several different types of requirements (project, technical, and even regulatory requirements) but that all well-written requirements share common characteristics. After examining what those characteristics are, we’ll conclude this week by describing what requirements documentation actually looks like.

1

The learning objectives for this week are deceptively simple: identify different types of requirements and how to write them. Writing a strong, measurable, “just specific enough” requirement is harder than it sounds: think about how many projects fail because (in hindsight) the project’s requirements weren’t clearly stated. Writing good requirements is a specific skill, so we’ll spend some time discussing it. You’ll also have a chance to practice writing requirements as part of this week’s discussion board activities.

2

There are no textbook readings to review in order to prepare for this week’s lecture. Instead, you’ll want to conduct some online research about how to write requirements. Some suggested internet search phrases are listed above (you’re also not limited to these phrases.)

Because it’s so challenging to write good requirements, there’s a tremendous amount of advice online about how to do so. As part of this week’s discussion board, we’re going to collectively identify and analyze the most common features of well- written requirements. To participate in the discussion board, be sure to capture the URL addresses of the websites you find most insightful about writing requirements so that others can expand their project management online reference library.

Also note there’s a benefit to posting to the discussion board early this week: the p g y sooner you post, the less likely it will be that someone else has already named the website(s) you wanted to identify.

3

The concept of requirements isn’t new to us: we spent most of the first week of the course talking about business requirements. An example business requirement we saw in week 1 is ta g about bus ess equ e e ts. e a p e bus ess equ e e t e sa ee s also identified above.

Once we’ve identified our business requirements, the next step is to explain those business requirements to our project stakeholders and ask them how that business requirement might best be fulfilled. We discussed this requirements collection process last week.

The third step – and the focus of this week – is literally how to write down what requirements the project stakeholders provide.

Before we discuss how to write down stakeholder requirements, though, it’s very important to distinguish the difference between business and other types of requirements. Recall from course week 1 that a business requirement describes a problem to be solved. Solution- focused requirements, such as project, technical, or regulatory requirements, describe the products and outputs that will solve the business problem, and also the conditions under which the project must operate.

For example: the business requirement identified above simply says we need to process more

4

tax transactions each month. The example of the corresponding solution requirement tells us exactly how many transactions must be processed (750); what types of transactions will be processed (payments, refunds, or adjustments); who is responsible for processing (the Department of Taxation); and by when the transaction count will be measured (at the end of each calendar month.)

This slide is similar to one we saw in course week 1. As it shows, however, we’ve now moved on from business requirements and are looking at other types of requirements: q g yp q solution-focused requirements.

There are three main types of requirements listed above, but note that technical requirements can be divided into two categories: user requirements and functional requirements. We’ve also added a special requirement type that may not always apply to every project: a regulatory requirement. y p j g y q

Let’s look at more examples of each type of requirement on the next few slides.

5

We when speak of requirements, stakeholders (including ourselves) are probably most familiar with technical requirements: statements that describe the way some product or output must function, what it should look like, how it should be able to be operated, and other features. If you have ever been asked what you want or need in a given situation (even when you order food in a restaurant!), you have described a technical requirement.

Technical user requirements describe what the user (stakeholder) experience will be like when the project (and product or output) is completed Any time a requirement sounds like a personal project (and product or output) is completed. Any time a requirement sounds like a personal preference, or literally involves stakeholder sensory perception (what something will look, feel, sound, or taste like) that’s a user requirement. Of the list of requirement aspects identified above, the features of a product are certainly considered a user requirement. (Depending on the specific requirement statement, the outputs of a product or process could also be driven by users.)

A functional requirement describes the technical performance or ability(ies) a product must possess. h f li bili d i i bili li d h ld b id d f i lThe performance, reliability, and maintainability aspects listed here could be considered functional

requirements.

The most important consideration in any requirements collection effort is to get the most complete and appropriate set of requirements – in the end, it doesn’t matter whether a technical requirement is consider a user or functional requirement. Thinking about these two different types of technical requirements, however, can help organize the requirements collection process – remember, different

6

requirements, however, can help organize the requirements collection process remember, different requirements collection tools have different purposes. A focus group, for example, is a good way to capture user requirements but may not be so helpful in determining functional requirements. We may want to use collection techniques such as observation or prototyping to determine what functional requirements the project output must satisfy.

In addition to technical requirements, most projects are also subject to project requirements – literally, needs that the project plan and execution must fulfill.

Consider again the triple-constraint theory: all projects must balance the scope-, budget-, and schedule-related requirements. Scope-related requirements are the same as technical requirements: what the project product or output is supposed to be. What about budget- and schedule-related requirements, however?

Requirements that the project itself must satisfy, such as requirements related to when something must be delivered; when the overall project must be completed; or budgetary limitations a particular phase (or the entire project) must remain within are considered project requirements. It’s the combination of technical and project requirements that create a project’s “triple constraints.”q p j p

Regulatory requirements are those needs imposed by laws, contracts, agreements, intellectual property limitations, and other legally-binding arrangements. The requirements themselves are usually relatively easy to collect, since they are already written in the legal language of the documents. While regulatory requirements may be easy to identify, they may not be as easy to satisfy – and most regulatory

7

y y, y y y y g y requirements are non-negotiable.

Regardless of the requirement type, all “good” requirements share some common characteristics: they are clear, easy to understand, and easy to verify whether they’ve been fulfilled. What are some other characteristics that “good” requirements share, and what are some examples?

The answer to those questions is the focus of your internet research and discussion board activity this week. Recall at the beginning of this lecture you were asked to conduct some online research about how to write requirements. Your research should help you answer the question that this slide asks: “what makes a ‘good’ requirement?”

One way (but not the only way) to write a “good” requirement is to remember the word SMART, as an acronym. Among other characteristics, “good” requirements y g g q should be Specific, Measurable, Achievable (sometimes also referred to as Attainable), Realistic, and Timely.

Including all these features in a clear, concise requirements statement can be challenging. Let’s look on the next slide at a few ways to incorporate SMART into each requirements statement we write.

8

q

This slide summarizes a few (not all) ways to ensure a requirements statement is SMART. You will also find other suggestions online, which is why we’ll summarize all these ideas in one place on this week’s discussion board.

When working with stakeholder to identify and then document requirements, what questions should you ask? Consider the following:

What level of performance will be considered “successful” (what’s the technical need?) For example, how many times will the process be error free, how many deliverables will be completed on time, or how many customer product evaluations will award a product score higher than 7?

I thi l l f hi bl ? “A hi bl ” i t ft d t i d b ki th Is this level of success achievable? “Achievable” is most often determined by asking the question “has this requirements been fulfilled by other projects or organizations in the past?”

Can this level of success be achieved within available resources? (Are the three sides of the “triple-constraint” triangle balanced?) Is money, labor, or equipment actually available to

t d i d f l l?

9

support your desired performance level?

And finally, by when should this requirement be fulfilled? This could be defined by year, month, or an important date to the customer.

When we think of requirements, many times we think of written statements that describe the desired level of performance. Sometimes, though, requirements can be more clearly expressed by using pictures – literally by including process flowcharts, or drawings of end products or features (there’s a reason “a picture is worth a thousand words” is such a commonly-used phrase.)

The potential drawback of including a picture – just a picture – in requirements documentation is that by itself, the picture is still subject to a viewer’s interpretation. When including any pictures or graphics in requirements documentation, it’s also important to call out important characteristics and key features the viewer of the picture might overlook or misinterpret.

10

At the beginning of this discussion, we noted that technical writing is a specific skill that must be learned. Technical writing is not the same writing style as standard business writing. It’s also a broader skill than simply writing good requirements: technical writing refers to the ability to write any detail-oriented, very specific, directive document.

However your write your SMART requirements statement, there are additional tips to consider. A few tips on technical writing are listed here, and none of these should be a surprise to you (but knowing how to do something is one thing; actually doing consistently it is another, wouldn’t you say?)

11

Once we’ve collected – and written down – all the requirements identified by our Once we ve collected – and written down – all the requirements identified by our stakeholders, we’re ready to finish the process we started last week, the “collect requirements” process. To do so, we’ll need to gather all the requirements statements (and graphics or pictures) we’ve collected and organize them into a single document. In general terms, this document is referred as “requirements documentation”.

12

“Requirements documentation” actually consists of two parts: a descriptive list of the technical, project and regulatory requirements a solution must satisfy in order to be complete and acceptable, and a prioritization of those requirements.

Most projects have limited resources to apply to requirements. This means, at some point during the project, we may be required to choose between requirements. Rather than making that choice as the project progresses, which can be a haphazard way to select which requirements we’re going to fulfill, it’s important to prioritize requirements before the project begins.

The easiest way to prioritize requirements is to divide requirements into three categories: (1) requirements we must satisfy; (2) requirements we should satisfy; and (3) requirements it would be nice to satisfy.

Who should be responsible for prioritizing requirements? This is a good question, and often where requirements collection becomes very difficult. No two projects prioritize requirements exactly the same way You may find it helpful to refer back to your stakeholder analysis to identify stakeholders same way. You may find it helpful to refer back to your stakeholder analysis to identify stakeholders that are particularly involved, influential, or interested in the project, and include those stakeholders in the prioritization process.

At a minimum, the Project Sponsor is usually included in the final requirements approval process, to include approving how requirements are prioritized. The Business Lead and Technical Lead should also be included in requirements prioritization, since those two stakeholders are best able to make sure

13

business and technical requirements are appropriately considered.

The “requirements documentation” that contains all our prioritized requirements can also be known as a Business Requirements Document (which is somewhat misnamed because it includes more than just business requirements.) Let’s look at this document on the next slide.

Note that basic features of requirements documentation were described in last week’s reading within the PMBOK® Guide (review pages 110-111 for reference.) We’ll also see that some projects create a separate Business Requirements Document and some do not: some projects simply incorporate requirements documentation into another deliverable known as a Scope Statement. We will not be producing a Business Requirements Document in this course but we will incorporate each of the BRD sections listed above into next week’s homework assignment, which happens to be a Scope Statement.

You’ll quickly notice that the first two sections of a Business Requirements Document are repeated from You ll quickly notice that the first two sections of a Business Requirements Document are repeated from the project’s business case and charter, and this is appropriate. We need to include an Executive Summary and a restatement of the business requirements in all our project deliverables in order to (a) ensure the reader has sufficient background to understand the document they’re reading and (b) to help ensure we do not lose sight of the our business needs as the project progresses.

The largest section of a Business Requirements Document focuses on our list of technical, project, and regulatory requirements. This “Solution Requirements” section not only lists all requirements, but also groups them in priority order. Finally – and we’ll discuss what’s meant by “success criteria” in more detail next week, we must describe how we’ll verify that each requirement has in fact been met.

Finally, to be sure we clarify any potential stakeholder assumptions or misinterpretations about the project’s scope, it’s important to identify any technical, project, or regulatory requirements that will not be addressed by this project These exclusions often arise due to budget or time limitations or there are

14

be addressed by this project. These exclusions often arise due to budget or time limitations, or there are simply some requirements that do not satisfy any larger business need. Specifically identifying these exclusions – and discussing them as a stakeholder group – is an especially effective way to ensure all stakeholders have a common understanding of the project’s scope: what the project will and will not do.

This concludes the lecture for lesson 3. There’s no individual written assignment for this week but you do have two (rather involved) discussion board topics to respond to, and keep in mind your first post to both topics is due by Wednesday. You should also know that your written assignment for next week will require you to write a set of requirements for your individual case study project, so you may want to begin thinking about those requirements sooner rather than later.

Enjoy your week in the meantime!

15