5. 需求和需求管理的目的
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?
7. 需求的层次(2)
Level 1:
Why the project is being
undertaken
Level 2:
What users will be able
to do with the product
Level 3:
What the developers
need to build
34. 用户故事和用例建模
用户故事
As a [User Role], I want to [Goal] so I can/because [Reason]
Example: As a registered user, I want to log in so I can access
subscriber-only content
38. 业务流程建模
BPM相关概念
• 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
and relationships.
• 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.
40. 业务流程建模
BPMN建模语言
Business Process Model and Notation (业务流程模型与符号)
是一套流程建模的标准,主要目标是提供一套被所有业务用户容易理解的符号,
支持从创建流程轮廓的业务分析到这些流程的最终实现,直到最终用户的管理
监控
提供了清晰而精准的执行语义来描述元素的操作
确保设计为业务流程执行的XML语言(如WS-BPEL),能够用这套以业务为中
心的符号所可视化表示
49. 需求编写的技巧
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
understand it.
50. 需求编写的技巧
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
specification)
Common imperative definitions;
“Shall” Definition
“Shall” denotes a mandatory and contractual requirement. “Shall” requires metrics to quantify
and requires a verification process.
“Will” Definition
“Will” denotes a mandatory and contractual requirement. It is similar to “shall” but does not
require metrics or verification.
“Should” Definition
“Should” denote a design goal, an objective the system tries to meet.
51. 需求编写的技巧
Adequate
As Appropriate
Bad
Better
But not limited to
Correct
Easy
Effective
Ideal
Large
Maximize
Minimize
Most
Must
Necessary
Normal
Quick
Rapid
Readily
Relevant
Satisfactory
Shall not
Small
Sufficient
Suitable
Timely
Typical
User friendly
Was
3: Do not use weak phrases and subjective words.
Following are words and phases not to use when writing a requirement:
52. 需求编写的技巧
4: Use continuations carefully, they make traceability and verification
difficult. Use when all items are to be verified by the same method at the
same time.
Example:
– 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.
53. 需求编写的技巧
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
systems level.
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.
54. 需求编写的技巧
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.
55. 需求编写的技巧
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
so correctly.
– 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
56. 需求编写的技巧
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
shall…”
12: Overspecification leads to unfunded requirements, and can add duplicate
requirements.
– The length of a requirement should not be excessive.
57. 需求编写的技巧
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]
Example:
When signal x is received [Conditions] , the system [Subject] shall set
[Action] the signal x received bit [Object] within 2 seconds [Constraint].
59. 功能性需求描述方法
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
use case.
1.3 Actors
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
“end-of-month.”
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.)
60. 功能性需求描述方法
1.5 Post-Conditions
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:
2.5–2.9.”
1.7 Priority
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
Coded: 2005/07/20
Tested: 2005/08/10
Internally released: 2005/09/15
Deployed: 2005/09/30
61. 功能性需求描述方法
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
Basic Flow
2.1 (Insert basic flow steps.)
Alternate Flows
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.
Exception Flows
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.
62. 功能性需求描述方法
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.
63. 功能性需求描述方法
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.
69. Product backlog
用场景描述的用户需求(User Story)列表
经过优先级排序和工作量评估的
优先级越高,User Story描述粒度越细
是一个业务计划
ID STORY / FEATURE / REQUEST CATEGORY TYPE
Relative
Benefit
Relative
Penalty
TotalValue
Value%
Estimate
Cost%
***Priority
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
PRODUCT BACKLOG
70. User Story描述
As a <USER ROLE>,
I want a <FUNCTIONALITY>
So that I can get
<BUSINESS VALUE>.对比基于目标和场景驱
动的用例需求分析方法,
是否似曾相识呢?
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