REQUIREMENTS TRACE-ABILITY AND USE CASES

How can requirements be traced to use cases? This is a simple question, yet opens up the question of how requirements are expressed as use cases.

Requirements Statements

Requirements (or "high level requirements") are nothing more than a Christmas wish-list of user's wants. Here are some requirements for a website that will "display my digital photos on the web":

Requirements wish list: Display my photos on the web:
Requirement
Id
User Requirement (want) Priority
SRS0001 Terry Organizes photos into galleries High
SRS0002TerryGalleries include thumbnails.High
SRS0003TerryThumbnails can be expanded into full sized photos,with description such as camera used, f-stop, shutter speed, focal length and artistic comment.High
SRS0004TerryMay contact photographer with feedback by email.High
SRS0005TerryIncludes a picture of myself and bio, contact information.Medium
SRS0006TerryEasy to upload photos, create galleries and enter info about the photo.High
SRS0007TerryWebsite should cost $100 or less per year to host.High

In the professional world, most requirements are not as clearly stated as above. Requirements are often written as large paragraphs of text. Recommended is to take the written paragraphs underlining "requirements statements" and give each one a numerical identifier.

Here's an example.

The website should order photos into galleries (SRS0001). The visitor can review a thumbnail(SRS0002) and request to see the full image (SRS0003). The full image will have description such as camera used, f-stop, shutter speed, focal length and artistic comment.(SRS0003) My bio and contact information is available(SRS0005) as well as email(SRS0004). I should be able to upload photos, thumbnails and descriptions easily(SRS0006). The website should cost less than $100 to host(SRS0007).

A list of requirements in table format is much easier to read that in paragraph format. If you're faced with requirements in paragraphs, put a table of requirement statements at the end of the document.

Use Case

To arrive at use cases, I usually review the requirement statements, extracting noun and verb pairs as use case "candidates".

Here are some use case candidates.

I will expand only one use case into "actors" and "steps" to give you a feel for the level of detail in a use case.

Use Case: Upload Photos
Actor Step
Photographer Selects photo to be uploaded.
Photographer Selects gallery that photo should be uploaded to or creates a new gallery.
Photographer Provides photo details such as camera, f-stop, shutter speed, focal length and artistic comments.
Photographer Reviews posting.
Photographer Changes or approves the posting.
Photographer Reviews posting on website.
Photographer Changes or deletes posting, if necessary.

I will use the following matrix to "trace" requirements statements to this use case.

Trace-ability Matrix: Requirement to Use Cases
Requirement IDUse Case
SRS0006Upload Photos

The above trace-ability matrix tells me that the use case "Upload Photos" satisfies the requirement SR0006 (Easy to upload photos, create galleries and enter info about the photo).

Requirement id's can also be traced to use case steps:

Use Case: Upload Photos
Actor Step Rqt ID
Photographer Selects photo to be uploaded. SRS0006
Photographer Selects gallery that photo should be uploaded to or creates new gallery. SRS0006
Photographer Provides photo details such as camera, f-stop, shutter speed, focal length and artistic comments. SRS0006
Photographer Reviews posting.SRS0006
Photographer Changes or approves the posting. SRS0006
Photographer Reviews posting on website. SRS0006
Photographer Changes or deletes posting, if necessary. SRS0006

The above example shows every step fulfilling the same requirement. Often one use case can fulfill several requirements.

We would then go on to create all the use cases for "display my photos on the web" and cross reference the use cases or use case steps to each requirement statement.

Sometimes a requirement does not have a corresponding use case. This is called a "non-functional requirement". Requirements that deal with the cost of a solution, or a technical requirement (must be web-hosted or must fulfill a technical standard) often do not find their way into use cases.

Make sure that no use cases are missing that may be needed to fulfill a requirement. Also make sure that to add any new requirements that "emerge" as a result of analyzing the actor and step detail. Tracing requirements to use cases works as a nice "fine tuning" of requirements and use cases.

After requirements and use cases have been created and cross-referenced, its time to architect the software product features.

Software Product Features

A software product feature is some software functionality that will be provided to support use cases. The "display my photos on the web" software product features will likely become one or more web pages that support the use cases.

Look for nouns and verbs in the use cases to draw out "candidate" product features.

Looking at the use case "Upload Photos", here are some candidate software product features:

I came up with nine candidate product features. Now I will cross-reference these product features to use cases:

Use CaseProduct Feature
Upload PhotosSelect Photo
Upload PhotosSelect gallery
Upload PhotosCreate New Gallery
Upload PhotosProvide Photo Details
Upload PhotosReview posting
Upload PhotosChange posting
Upload PhotosApprove posting
Upload PhotosReview website posting
Upload PhotosDelete posting

I can cross reference the software product features to use case steps as follows:

Use CaseStepProduct Feature
Upload PhotoSelects photo to be uploaded.Select Photo
Upload PhotoSelects gallery that photo should be uploaded to or creates new gallery.Select gallery,
Create new gallery
Upload PhotoProvides photo details such as camera, f-stop, shutter speed, focal length and artistic comments.Provide photo details.
Upload PhotoReviews posting.Review posting.
Upload PhotoChanges or approves the posting.Change posting, Approve posting.
Upload PhotoReviews posting on website.Review website posting.
Upload PhotoChanges or deletes posting, if necessary.Change posting,
Delete posting.

Make sure each product feature can be mapped to a use case. Itís important to make sure that all product features have been created that will be needed to fulfill the use cases. Cross-referencing makes sure that no product features have been missed.

Here's a cross-reference of software product features to use cases.

Requirement IDProduct Feature
SRS0006Select Photo.
SRS0006Select gallery.
SRS0006Create new gallery.
SRS0006Provide photo details.
SRS0006Review posting.
SRS0006Change posting.
SRS0006Approve posting.
SRS0006Review website posting.
SRS0006Change posting.
SRS0006Delete posting.

All "upload photo" product features map to requirement SRS0006 (Easy to upload photos, create galleries and enter info about the photo).

Sometimes use cases and requirement statements must be revisited because of the analysis of software product features.. For instance, the ability to "review website posting" prior to posting a photo to the website was never mentioned as a requirement. However, if the requirement were to be reviewed with the customer, the customer would likely agree that it's a good requirement.

Cross-referencing requirements, use cases (or use case steps) and product features should result in a reexamination and "fine tuning" all three. Eventually, requirement statements, use cases and product features are all adjusted until a harmony of is achieved. All parties agree that the three work together to express the whole of the user's requirements. This is "art" of requirements management.

Tracing Requirements to Test Plans

I'm an advocate of creating test plans and test cases during requirements gathering. The fastest way to create a test plan is to add a few columns to the use cases. Here is an example with use case Upload Photo:

Test Case 1: Upload Photos

ActorStepInputExpected ResultPass/Fail
PhotographerSelects photo to be uploaded.C:/my photos/soccer1.jpgPhoto should be selected. 
PhotographerSelects gallery that photo should be uploaded to or creates new gallery.Select gallery "Soccer"Should be able to select a gallery. 
  Add new gallery "Soccer 4/15/2004"Should be able to create a gallery. 
PhotographerProvides photo details such as camera, f-stop, shutter speed, focal length and artistic comments.Camera:Fuji Finepix 602,F-stop:2.8Shutter Speed:1/500Focal length=40mmArtistic Comments: Panned across following movement of player.Should be able to enter camera, f-stop, shutter speed, focal length and artistic comments. 
PhotographerReviews posting.Gallery="Soccer 4/15/2004"Should be able to see thumbnail in Gallery list. 
  Select "soccer1.jpg"Should be able to select thumbnail and review full image and previously entered details. 
PhotographerChanges or approves the posting.Select "approve"  
PhotographerReviews posting on website. Posting should now be available on website. 
PhotographerChanges or deletes posting, if necessary.Select "change" Change camera to: Nikon D70Focal Length=18mmAdd new gallery "Soccer 4/18/2004" Artistic comments: none.Should be able to change all details with changes reflected on website. 
  Select gallery 4/18/2004. Select soccer1.jpg  
  Select delete.Both picture, thumbnail and gallery should no longer appear on website. 

I have turned the use case into a test case by adding columns Input, Expected Result and Pass/Fail. Each of my use cases could become test cases in my test plan. The cross-referencing of use cases to test cases is easy: there is one test case for each use case.

Creating a test case may result in revisiting the use case. The above use case, as a test case, does not read that well. That's because the use case "upload photo" could probably be decomposed into several use case "scenarios":

If creating test cases result in revisiting the use cases, it stands to reason that the requirements and product features may have to be adjusted as well. That's why I'm a great advocate of creating test plans and test cases as the use cases are constructed.

Tracing Requirements to Technical Specifications

I usually create one technical specification for each product feature. It's very easy to cross reference product features to technical specifications: it's a one to one mapping!

At the top of the tech spec, its not a bad idea to list the requirements, use cases (or use case steps) and the product feature the tech spec is addressing. Also include references to the test plan.

Here is an example:

Technical Specification for software product feature: Select Photo
Requirement Addressed(SRS006) Easy to upload photos, create galleries and enter info about the photo.
Use Case/Step AddressedUpload Photo: Selects photo to be uploaded.
Test CaseRefer to test case "upload photo".

Beginner Advice

For a neophyte (beginner) analyst, I would recommend trying your hand at a relatively small project like "Display my photos on the web". This very small website requirement gives rise to half a dozen requirements, several use cases, several test cases, and numerous technical specifications.

After you have a few small projects under your belt (preferably personal projects) try your hand at a large project with real live users. I would view a large project as having 30 or more requirement statements, ten or more use cases and thirty or more product features. Start with small projects and work your way up to the big five million dollar budget projects.

Additional Questions

Feel free to email me (Terry Reiber) with your questions at terry@softreq.com

"Requirements Trace-ability and Use Cases" by Terry Reiber
Copyright Terry Reiber 2004
Reproduced with permission.

RETURN TO LESSONS FROM EXPERTS