Requirement No. . For reference and traceability across other . Unique # never changes
Target Release . Urgency . Current, Next, Future
Prioritization . Importance for final inclusion . MoSCoW: Must, Should, Could, Won’t
Statement/Description . One sentence statement of the intention of the requirement
User Story . Fit Criterion: A quantification of the requirement use to determine whether the solution meets the requirement . Rationale: Why the requirement is important or necessary.
Customer Attractiveness . Desire to have the requirement
Customer Disappointment . Dissatisfaction if not implemented
Category/Type . PRD section
Product Use Case No. . Origin of the requirement
Source . Who raised the requirement, when
Notes (further details) . Dependencies: other requirements with a change effect . Conflicts: requirements that contradict this one . Supporting Materials: reference to other information . History: Origin and changes to the requirement
Requirements and Requirement management need to do two things:
1) Validate - Make sure you are building the right product:
Are we doing the right thing?
2) Verify - Make sure you built the product right:
Are we doing the thing right?
• Business Process - A set of one or more linked procedures or activities
which collectively realize a business objective or policy goal, normally
within the context of an organizational structure defining functional roles
• Workflow - The automation of a business process, in whole or part,
during which documents, information or tasks are passed from one
participant to another for action, according to a set of procedural rules.
• Process Definition - The representation of a business process in a form
which supports automated manipulation, such as modeling, or
enactment by a workflow management system. The process definition
consists of a network of activities and their relationships, criteria to
indicate the start and termination of the process, and information about
the individual activities, such as participants, associated IT applications
and data, etc.
Enterprise Process Framework
Business Process Model and Notation (业务流程模型与符号)
1: Use the simplest words appropriate to state a complete requirement.
– An eloquently written requirement is probably not a good one.
– A requirement must be written so many different people can
2: Use requirement imperatives correctly.
– Use company/program defined list.
– If requirements are from a non-company source, make sure you know the
meaning of these words. (Definitions should be included in Section 1 of the
Common imperative definitions;
“Shall” denotes a mandatory and contractual requirement. “Shall” requires metrics to quantify
and requires a verification process.
“Will” denotes a mandatory and contractual requirement. It is similar to “shall” but does not
require metrics or verification.
“Should” denote a design goal, an objective the system tries to meet.
But not limited to
3: Do not use weak phrases and subjective words.
Following are words and phases not to use when writing a requirement:
4: Use continuations carefully, they make traceability and verification
difficult. Use when all items are to be verified by the same method at the
– The system shall report software status to the host interface under the following conditions:
• At system initialization.
• When the status of an external interface has changed.
• When a report has been requested.
5: Use examples, tables, figures etc., they are a great source of
information and clarification.
– Make sure examples and notes are clearly marked as such (not part of requirement).
– For tables; specify if all, some or none of the cells are requirements.
– Clearly indicate if a figure or part of the figure, is part of the requirement, or is information.
6: Be consistent with names; always call the same entity by the same name.
– Example: If in some requirements the subject is called “the System,” and in others “ the URQ-65”, the
names are not consistent.
– Always use the correct name for the level of specification. You can not verify a sub capability at a
7: If you use a TBD or TBR, have a plan. You must state who is responsible for
the information, and when the it will be completed.
8: Make sure a requirement contains all the qualities of a good requirements
– Concise: Minimal, easily understood, a complete expression of a single thought, non-ambiguous; only
one possible interpretation.
– Correct: An absence of errors of fact.
– Consistent: No conflicts between individual requirements, parts of a single requirement complement
each other. Connectivity exists between the requirements; consistent words and terms
– Traceable: Know source of requirement and be able to allocate it, Uniquely identified for life. Never re-
used identification on Project.
– Verifiable: Method (Test, Inspection, Demonstration, Analysis, Certification) Understand how
requirement can be verified, and determine criteria for acceptance.
– Necessary: Can the system be complete without this requirement?
– Attainable: Is this requirement technically feasible within given time and cost?
– Modular: Will a change to this requirement have a big impact on the system? Can this requirement be
easily used and monitored by other programs if needed?
– Restrictive – The requirement should written in such a way as to not limit implementation. Make sure the
requirement states what needs to be done not how.
9: Conjunctions. There should be only one requirement per statement.
– A requirement should not contain “and” or “or”.
– Requirement which contain “and”, “or” or “and/or” probably contain more than one requirements. These
hard to trace and completely verify.
10: Make sure that if a requirement references another document, that it does
– State if reference is information or part of the requirement.
– Make sure references are listed in applicable document section and state what part of reference applies
11: Make sure Acronyms are used correctly.
– Place the acronym in the acronym list in the specification.
– Spell out the complete phrase followed by the acronym in parenthesis the first time used.
– The next time just use the acronym.
– Example: first use: “The SATCOM Antenna Interface Unit (SAIU) shall…”, second use “The SAIU
12: Overspecification leads to unfunded requirements, and can add duplicate
– The length of a requirement should not be excessive.
13: Use the requirement template
There are four major parts to a requirement:
– Entities –
• Subject of the requirements (noun)
• Object of action (noun)
– Actions – What the subject does, contains imperative (verb)
– Conditions – What must be in place in order for this action to take place
– Constraints– Qualifies the action, performance
The following is the structure of a basic requirement:
[Conditions] [Subject] [Action] [Object] [Constraint]
When signal x is received [Conditions] , the system [Subject] shall set
[Action] the signal x received bit [Object] within 2 seconds [Constraint].
Use-Case Description Template
1. Use Case: The use-case name as it appears on system use-case diagrams
Perspective: Business use case/system use case
Type: Base use case/included/extending/generalized/specialized
1.1 Brief Description: Describe the use case in approximately one paragraph.
1.2 Business Goals and Benefits: Briefly describe the business rationale for the
1.3.1 Primary Actors: Identify the users or systems that initiate the use case.
1.3.2 Secondary Actors: List the users or systems that receive messages from
the use case. Include users who receive reports or online messages.
1.3.3 Off-Stage Stakeholders: Identify non-participating stakeholders
who have interests in this use case.
1.4 Rules of Precedence
1.4.1 Triggers: Describe the event or condition that “kick-starts” the use
case (for example, “User calls Call Center; inventory low”). If the
trigger is time-driven, describe the temporal condition, such as
1.4.2 Pre-Conditions: List conditions that must be true before the use
case begins. (If a condition forces the use case to occur whenever it
becomes true, do not list it here; list it as a trigger.)
1.5.1 Post-Conditions on Success: Describe the status of the system after
the use case ends successfully. Any condition listed here is guaranteed
to be true on successful completion.
1.5.2 Post-Conditions on Failure: Describe the status of the system after
the use case ends in failure. Any condition listed here is guaranteed
to be true when the use case fails as described in the exception flows.
1.6 Extension Points: Name and describe points at which extension use cases
may extend this use case.
1.6.1 Example of Extension Point Declaration: “Preferred Customer:
1.8 Status: Your status report might resemble the following:
Use-case brief complete: 2005/06/01.
Basic flow + risky alternatives complete: 2005/06/15
All flows complete: 2005/07/15
Internally released: 2005/09/15
1.9 Expected Implementation Date
1.10 Actual Implementation Date
1.11 Context Diagram: Include a system use-case diagram showing this use
case, all its relationships (includes, extends, and generalizes) with other use
cases, and its associations with actors.
2. Flow of Events
2.1 (Insert basic flow steps.)
2.X.a (Insert the Alternate Flow Name): The alternate flow name should
describe the condition that triggers the alternate flow. “2.X” is the step
number within the basic flow where the interruption occurs. Describe the
steps in paragraph or point form.
2.Xa (Insert the Exception Flow Name): The exception flow name should describe
the condition that triggers the exception flow. An exception flow is one
that causes the use case to end in failure and for which “post-conditions
on failure” apply. “2.X” is the step number within basic flow where the
interruption occurs. Describe the steps in paragraph or point form.
3. Special Requirements: List any special requirements or constraints that apply
specifically to this use case.
3.1 Non-Functional Requirements: List requirements not visible to the user
during the use case—security, performance, reliability, and so on.
3.2 Constraints: List technological, architectural, and other constraints on
the use case.
4. Activity Diagram: If it is helpful, include an activity diagram showing
workflow for this use case or for select parts of the use case.
5. User Interface: Initially, include description/storyboard/prototype only to
help the reader visualize the interface, not to constrain the design. Later,
provide links to screen-design artifacts.
6. Class Diagram: Include a class diagram depicting business classes, relationships,
and multiplicities of all objects participating in this use case.
7. Assumptions: List any assumptions you made when writing the use case.
Verify all assumptions with stakeholders before sign-off.
8. Information Items: Include a link or reference to documentation describing
rules for data items that relate to this use case. Documentation of this sort is
often found in a data dictionary. The purpose of this section and the following
sections is to keep the details out of the use case proper so that you do not
need to amend it every time you change a rule.
9. Prompts and Messages: Any prompts and messages that appear in the use
case proper should be identified by name only, as in “Invalid Card Message.”
The “Prompts and Messages” section should contain the actual text of the
messages or direct the reader to the documentation that contains text.
10. Business Rules: The “Business Rules” section of the use-case documentation
should provide links or references to the specific business rules that are active
during the use case. An example of a business rule for an airline package is
“Airplane weight must never exceed the maximum allowed for its aircraft
type.” Organizations often keep such rules in an automated business rules
engine or manually in a binder.
11. External Interfaces: List interfaces to external systems.
12. Related Artifacts: The purpose of this section is to provide a point of reference
for other details that relate to this use case, but would distract from the overall
flow. Include references to artifacts such as decision tables, complex algorithms,
and so on.
ID STORY / FEATURE / REQUEST CATEGORY TYPE
1 As the system I want to be able to capture image files from disk Imaging Feature 9 9 18 22.2 10 10.4 2.13
7 As a user when I enter a non alphanumeric character when logging in an error occurs Login Bug 2 1 3 3.7 2 2.1 1.78
2 As a user I want to be able to view the metadata for an image Index Feature 7 3 10 12.3 8 8.3 1.48
3 As the system when an image appears on disk I want to automatically capture it Imaging Feature 8 9 17 21.0 15 15.6 1.34
4 As a user I want to be able to login to the system Login Feature 3 5 8 9.9 8 8.3 1.19
5 As a user when I have logged in I want to view my inbox Desktop Feature 9 2 11 13.6 21 21.9 0.62
6 As a user I want to be able to view a scanned document Imaging Feature 8 6 14 17.3 32 33.3 0.52
TOTALS 46 35 81 100 96 100
As a <USER ROLE>,
I want a <FUNCTIONALITY>
So that I can get