You are here

RA Task 1 Plan of Attack

Plan of Attack

The objective of this task is to learn how to develop user and other software requirements. There are many techniques for developing user requirements, and in this task you will have the opportunity to use storyboards, user interface mockups, and use case models.

Regardless of which technique you adopt, requirements engineering techniques serve three purposes:

  1. they help analysts and engineers to work with users and other stakeholders to bridge the gaps between what they think users want, what users need, and what is possible.
  2. the techniques facilitate communication between the customer and your team so that the customer’s vision can be fully realized by ensuring that the architects and engineers know exactly what to build.
  3. these techniques help to manage the customer’s expectations about what the system will (and won’t) do and how they will interact with it.

As you work on this, remember that one of the common pitfalls of requirements development is to begin to specify specifically how the system will meet the customer’s needs (design) instead of describing what the system must do (requirements). Therefore, the key to success in this task is to avoid overly specific requirements that will unnecessarily constrain our developers by making design decisions which might best be deferred.

Task-level Learning Objectives

  • Ability to identify and prioritize user and customer needs
  • Ability to use Scenarios, Storyboards, Use Cases, and other artifacts to derive, analyze, and document requirements
  • Ability to separate what the system should do from how the system will do it.


Task 1 has three parts that overlap in their deliverables and submission dates:

1) Refined and validated requirements for your product using storyboards, use case models, and/or user interface mockups.  If you create user interface mockups, you must also deliver one of the other two models

2) Evaluation of requirements tools for producing storyboards, use case models, UI mockups, and/or requirements management. Each team member should perform a brief evaluation of at least one tool.  You should use some (not necessarily all) of those tools in completing the models and documents in Parts 1 and 3.

3) Pulling together the validated requirements along with non-function requirements into a document that can serve as the basis for competitive evaluation and definition of the features and functions of the first version of your product.

The deliverables include

  • A storyboard illustrating the key task(s) the proposed system will support  and a series of requirements validation interviews
  • A memo reporting on the results of your validation interviews
  • (Individual task) Evaluation and selection of one or more tools for storyboarding, UI prototyping, use case modeling, and requirements management
  • User Requirements Document (URD) which includes
  1. Description of the system in context
  2. Enumeration of key users and other product stakeholders
  3. Enumeration of possible use cases which correspond to “basic-level” (or “sea-level” to use Cockburn’s term) goals for each key user
  4. Prioritization of potential use cases
  5. Elaborations of high-priority use cases (one basic-level use case per team member plus any included use cases)
  6. Any additional functional, business, and technical requirements associated specifically with particular use cases
  • Supplementary Requirements Specification (included as an appendix to the URD or as a separate document) which includes
  1. Enumeration of key nonfunctional requirements, including a product-specific definition of each requirement and how each will be measured or observed with respect to the product
  2. Any other global requirements (e.g., business rules, general business requirements, and global technical requirements) not captured by the use cases or specifically associated with them

Develop a Learning Plan (for your own personal use)

  • Begin by reviewing all of the tasks in this course to form a clear understanding of everything you must do
  • Develop a schedule to complete the readings. Be aware that this task has a lot of reading; read strategically, considering which readings can be skimmed and which should be read carefully.
  • Discuss how scenarios, storyboards, and use cases can be used to develop user requirements
  • Discuss additional requirements you will need to document which are not adequately captured by use case

Plan your Approach

  • Decide which task(s) to storyboard and how to conduct validation interviews
  • Decide how to identify potential use cases
  • Decide how to prioritize potential use cases for elaboration
  • Decide if additional interviews (or other requirements gathering techniques) will be required to prioritize and then elaborate use cases
  • Review the outline on pp. 13-14 of Cockburn, the outline on p. 191 of Wiegers, and IEEE standard 1362-1998 to see examples of what can be in a URD (We recommend adopting Cockburn's outline for your task.)
  • Make a plan to identify, define, and document other (e.g., nonfunctional) requirements
  • Make a plan for allocating the work. Keep in mind that we would like each team member to develop at least one use case. (As always, team review of individual work is encouraged.)

Create a Storyboard and Conduct Validation Interviews

  • Before diving into production of a user-requirements document, it’s a good idea to revisit your vision for the system and to validate it via a few focused interviews. Begin by creating a storyboard illustrating the most central task or tasks that the system will support
  • Conduct (at least) three validation interviews in which you walk potential “key users” through the storyboard to ensure that the task flow and general “sketches” of interaction with the system make sense to them
  • Revise your ideas concerning user requirements based on the results
  • Write a memo reporting on what you learned from the interviews

Note that previous teams have gotten very bogged down in this task! It is intended to provide a quick validation and slight elaboration of your product vision, not to become a springboard to complete reconceptualization of the vision.

Identify Potential Use Cases (or revisit your earlier identification)

  • Review the affinity diagram, Contextual Design models, user scenarios, and product vision document that you developed during Software Product Definition. Also consider any revisions suggested by your storyboard-based validation interviews
  • Identify all primary and secondary users (Now may be the time to consider finer distinctions among users than you made previously.)
  • Enumerate each type of user’s “basic-level” (or in Cockburn’s terms “sea-level”) goals for interaction with the system in this context; each goal corresponds to a potential use case.

Create the User Requirements Document

  • Select a format for your URD. As previously noted, we recommend adopting Cockburn's outline, but you may devise your own format as long as your URD adequately captures all essential details
  • Determine how to obtain and document all of the required information
  • Generate the agreed upon description of the system in context, enumeration of key users and stakeholders, use cases, and other appropriate material for the URD

Create a Supplementary Requirements Specification

  • Select a format for your supplementary requirements. You may want to devise your own format appropriate to the scope of what you have been asked to produce
  • Determine how to obtain and document all of the required information
  • Generate and document the agreed upon requirements, including defining each in a product-specific way (e.g., if “performance” is an important quality attribute, how should it be defined specifically in the context of this product?)

Submit your draft work for feedback

Formally submit the user requirements document and supplementary requirements specification with appropriate introduction and explanations


(Task 1a) The tool evaluation is an individual task that is worth 20% of your overall grade. (Task 1b) The URD and supporting material is a team task that is worth 30% of your overall grade.  (Task 1c) The requirements validation is a team task that is worth 10% of your overall grade.