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 |
| SRS0002 | Terry | Galleries include thumbnails. | High |
| SRS0003 | Terry | Thumbnails can be expanded into full sized photos,with description such as camera used, f-stop, shutter speed, focal length and artistic comment. | High |
| SRS0004 | Terry | May contact photographer with feedback by email. | High |
| SRS0005 | Terry | Includes a picture of myself and bio, contact information. | Medium |
| SRS0006 | Terry | Easy to upload photos, create galleries and enter info about the photo. | High |
| SRS0007 | Terry | Website 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.
- Organize photos into galleries
- Review thumbnails
- Expand thumbnail
- Contact photographer
- Upload photos
- Include bio and contact info
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 ID | Use Case |
| SRS0006 | Upload 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:
- Select photo
- Select gallery
- Create new gallery
- Provide photo details
- Review posting
- Change posting
- Approve posting
- Review website posting
- Delete posting
I came up with nine candidate product features. Now I will cross-reference these product features to use cases:
| Use Case | Product Feature |
| Upload Photos | Select Photo |
| Upload Photos | Select gallery |
| Upload Photos | Create New Gallery |
| Upload Photos | Provide Photo Details |
| Upload Photos | Review posting |
| Upload Photos | Change posting |
| Upload Photos | Approve posting |
| Upload Photos | Review website posting |
| Upload Photos | Delete posting |
I can cross reference the software product features to use case steps as follows:
| Use Case | Step | Product Feature |
| Upload Photo | Selects photo to be uploaded. | Select Photo |
| Upload Photo | Selects gallery that photo should be uploaded to or creates new gallery. | Select gallery, Create new gallery |
| Upload Photo | Provides photo details such as camera, f-stop, shutter speed, focal length and artistic comments. | Provide photo details. |
| Upload Photo | Reviews posting. | Review posting. |
| Upload Photo | Changes or approves the posting. | Change posting, Approve posting. |
| Upload Photo | Reviews posting on website. | Review website posting. |
| Upload Photo | Changes 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 ID | Product Feature |
| SRS0006 | Select Photo. |
| SRS0006 | Select gallery. |
| SRS0006 | Create new gallery. |
| SRS0006 | Provide photo details. |
| SRS0006 | Review posting. |
| SRS0006 | Change posting. |
| SRS0006 | Approve posting. |
| SRS0006 | Review website posting. |
| SRS0006 | Change posting. |
| SRS0006 | Delete 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
| Actor | Step | Input | Expected Result | Pass/Fail |
| Photographer | Selects photo to be uploaded. | C:/my photos/soccer1.jpg | Photo should be selected. | |
| Photographer | Selects 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. | |||
| Photographer | Provides 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. | |
| Photographer | Reviews 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. | |||
| Photographer | Changes or approves the posting. | Select "approve" | ||
| Photographer | Reviews posting on website. | Posting should now be available on website. | ||
| Photographer | Changes 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":
- Upload photo into existing gallery
- Upload photo into new gallery
- Deleting a photo from a gallery
- Deleting a gallery
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 Addressed | Upload Photo: Selects photo to be uploaded. |
| Test Case | Refer 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
Also, please feel free to try my free, web-based requirement management tool called SoftREQ at www.softreq.com. SoftREQ is an excellent tool to try your hand at requirements management.
"Requirements Trace-ability and Use Cases" by Terry Reiber
Copyright Terry Reiber 2004
Reproduced with permission.