Follow That Requirement

What is a traceable web requirement?

In simple terms, a web requirement is a statement of purpose for what a website must provide users. For example, “The site must allow someone to log in securely.” The statement may represent a desired user action, a feature or function, or a specific content type.

So, what makes a web requirement traceable? A web requirement is traceable when you can track the initial statement (business requirement) and show how it changes (functional specification) and is ultimately confirmed as complete (system/user acceptance testing) at the end of the project.

From 30,000 feet

At the start of a project, you’ll want to identify all high-level business requirements to ensure a clear understanding of what must be included in the website you’re building. Time constraints often hamper your ability to get into more detail, so your high-level requirements will evolve as the project proceeds. This is where requirement traceability begins. Your client thinks in terms of high-level requirements, not the nitty-gritty details. Connecting the high-level requirements to their associated features and functions allows you to connect what the customer wants with what has to be built.

The first step is to get business requirements down on paper. For instance, I capture the following:

• Requirement ID – a unique value that identifies the requirement throughout the project
• Requirement description – a single statement, written in natural language, that defines the business need it fulfills
• Category – a group identifier for similar requirements that all project resources will understand
• Priority – we use the MoSCoW method to help clients identify importance
• Page type – if applicable, requirements may be assigned to specific page types you plan to build
• Notes – a place to capture questions (yours or the client’s) that will surface as a requirement evolves

At Happy Cog, our goal is to have all of the project’s high-level business requirements documented and confirmed by the end of the project definition phase. We expect the requirements to evolve as we move into subsequent phases of the project, which is where the challenge begins. If we fail to capture how the details coming out of our UX/IA or aesthetic design work relate to the business requirements previously defined, we risk missing our clients’ expectations.

An example of what a high-level business requirement might look like at the end of project definition, and how it might evolve as the project progresses, follows:

Your customer has expressed the need for a blog in the new website. You document this need like so:

• Req_ID: 1.00: Website has a blog that will allow subject matter experts to publish content regularly. Fresh, authoritative content will increase site traffic.

Req_ID 1.00 is a clear statement of purpose with a business value, but there is hardly enough detail to make an informed decision about what the experience should be, or what technologies may be best to accomplish it.

Getting to granularity

During the next project phase, whether it is UX/IA or aesthetic design, we continue to ask the client questions:

• Will users be able to comment on blog posts?
• Will blog content need to be archived?
• Will posts be sharable via social media?

Let us assume the customer responds with a “yes” to these questions. Our single high-level business requirement has just ballooned into three or more functional requirements. The customer still thinks, “we need a blog,” but the team at Happy Cog now knows there is definitely more to it. We’ve identified functions, and those functions need to tie back to the business requirement.

Our business requirement now looks like this:

• Req_ID: 1.000: Website has a blog that will allow subject matter experts to publish content regularly. Fresh, authoritative content will increase site traffic.
  • Req_ID: 1.100: Provide site visitors with ability to comment on blog content and increase site interaction and site visits.
    • Req_ID: 1.1001: Comment content is limited to 300 characters.
    • Req_ID: 1.1002: Comment content must include username.
    • Req_ID: 1.1003: Comment content must include date/timestamp to identify when comments were posted.
    • Req_ID: 1.1004: Comment content must be moderated before being published.
    • Req_ID: 1.1005: Comment content must be able to be shared to Facebook and Twitter.
  • Req_ID: 1.200: Blog content should be archived and available for reference by site visitors from the blog landing page.

Here’s the key: capturing the requirement for your client. You can document the evolution in your original business requirements document (Google Apps is great for this because you can notify the shared recipients of the change in real time), or as an annotation in a UX/IA or design artifact. If the latter, I recommend referencing the Req_ID and description in the annotations to mark a clear connection between the business requirement and its functional equivalent.

Confirm as you go

When the time comes to build and test your website, each document used to inform development will contain a link between the business requirement and its associated feature or functional requirement. Once you confirm that all features and functions are working as needed, you’ve also confirmed that all business requirements have been satisfied.

As you get deeper and deeper into a project, it is easy to lose sight of business requirements because you’re focusing more and more on features and functions. Creating a link between business requirements and functional requirements makes them manageable and traceable. It also protects you from the risk of assumptions on all sides. And you know what they say about assuming…

Do you create traceable web requirements where you work? What methods do you use to keep track of them all?

Back to Top