• Initiation
• Requirements Complete
• Commit
• Functionality Complete
• QA Complete / Release

• Project Data Sheet
• Project Plan
• External Specification
• User Requirements
• Internal Specification
• Quality Plan
• Configuration Management Plan
• Memorandum of Understanding
• Official Process Image

The purpose of User Requirements is to identify the user-level requirements and usability requirements which need to be in the product in order to meet user needs. Defining requirements is the process of turning the higher level problem statement or high level product definition into a more specific statement of product functions. 

In the past, requirements documents were typically a laundry list of high and low level features, functions, wants etc. We want to evolve our requirements documents to reflect both user requirements and system requirements in more systematic manner. User requirements should be reflected as they relate to users' tasks and goals. User requirements are generated from data compiled from task analyses, user visits and or phone interviews, surveys, field input and/or competitive product analysis. Technical and/or system requirements are technical functions which must be part of the product, but are not exposed to the user. They should be reflected in an Internal Requirements document. User requirements eventually translate into the External Specification Document. Internal requirements translate into the Internal Specification Document. 
 

Key Areas to Understand and Document:

Within the process of defining requirements, there are a number of areas which the team (or subteam) should understand and document. These may be included in the actual requirements document or can be referenced as supporting documents.

Identify and Profile End Users of Proposed Product 

• Role descriptions: 
• Skills: 
• Education: 
• Experience with similar products: 

Identify the End Users' Environment

• Platforms: 
• Operating Systems: 
• System: 
• Disc space: 

Identify User Goals
Describe user-focused goals which relate to the user tasks and product functionality. These can be high level goals, which can later be converted to measurable objectives for usability testing. 

Identify Primary Use Cases 
Use cases are a description of the primary purposes that the product is used for. This does not include corner cases. The use cases can be used for object-oriented modelling. 

Understand the user's tasks 
This should be a task analysis of relevant tasks obtained through task-focused user interviews, use cases and user scenarios. This can be a link and does not have to appear in the Requirements Document itself.) The team may start with their understanding of the users' tasks, as long as they indicate the confidence level that these tasks reflect customer tasks. Ideally, task flows should be generated with customers and minimally, task flows should be validated with customers. The team should also begin to extrapolate to the future task flow. The product requirements should relate to how the product will be improved in the future to facilitate the user's overall future flow and goal attainment. 

Document user's needs and wants (optional)
This can be a supporting document which feeds into the final Requirements list. This can be a list of needs and wants which were requested by user's either through surveys, visits, interviews, support calls and field information. Needs and wants are entered into the requirements list based on their priority. Priorities for needs and wants should be determined based on the frequency of the request and the degree to which it relates to task success and/or competitive parity/advantage. Needs may be better stated in relationship to tasks (see next item). 

Task/Needs-Wants Matrix (optional)
Although it is not required, a task to needs/wants matrix can be a useful cross-reference tool to 1)identify tasks which may have been overlooked and/or 2)needs/wants which do not relate the task domain and therefore are probably beyond the scope of the current project. They may imply tool interactivity issues or follow-on products. 

Tasks/Functions Matrix (optional)
Also not required, but can be a useful cross-reference tool to 1) identify functions which should be in the product to support a task and/or 2) to identify functions which do not related to the task domain the therefore are probably beyond the scope of the current project. Same implications as above. 

Competitive Requirements
Competitive requirements can come from competitive analyses or from customer input. If the goal is to reach parity with a competitior, than the task/functions supported by the competitive product should be listed. If the goal is to go beyond the competition, than added-value or functional opportunities should be identified. . 
 
 

Final User Requirement's List:

List of Required Functions
The actual Requirement's List may or may not include the associated tasks, as long as there is a good understanding of user's tasks and a link to a task document. Requirements should be stated as functions which user's need to carry out tasks to solve the targeted problems. They can be stated as features, although final features are not typically decided upon until the Design Phase. It is useful if the requirements are functionally grouped by high level task categories. 

Prioritization
The Requirement's List must include a prioritization between Musts, High Wants and Wants. The source of the requirement should be listed using a key. Musts are functions which must be in the product in order for it to be viable. The product should not ship, if musts are not done. If this occurs, it should only be done with sign-off by the manager and the risk to customer satisfaction should be assessed. 

Assumptions
These include key "givens" that the team assumes as a foundation for proceeding with product design and development. Any questionable assumptions should be validated. For example, all users have PCs with Windows 95 running. Sometimes assumptions should be verified with customers. 

Constraints 
These are typically technical constraints and their potential impact on users. For example, the product will not run on Unix. Does this representative a risk for customer acceptance? 
Risks (required)