Re-sending
Ben
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ben Williams
Sent: 12 March 2007 16:12
To: Eclipse Process Framework Project Developers List
Cc: Mark.Dickson@xxxxxxxxx
Subject: RE: [epf-dev] Prioritizing requirements
Mark
Well raised, I think this is an area that needs
clarification.
Maybe I’m having a bad sight day, but I’m in the same
boat as you……
First of all, I don’t think there is any explicit mention
of prioritizing requirements as an entity, but prioritizing items in the WIL
(including requirements) is covered partially.
Certainly the Project Manager, as primary performer of
Task: 'Plan Iteration' uses the Stakeholder prioritization as a necessary input
into that task, but the steps in the task itself could be interpreted in a
couple of different ways.
Note my highlighting in Red below.
Define
the iteration objectives
|
At the beginning of an iteration, the Role: Project Manager works
with the team to define 1-5 objectives. These objectives should be a
refinement of the iteration objectives found in the Artifact: Project Plan,
and should provide high-level direction to what should be targeted for the
iteration. The objectives should be driven based on Role: Stakeholder priorities,
and will be revised as the iteration plan is finalized. The objectives
are usually defined as high-level capabilities or scenarios that need to be
implemented and tested during the iteration. |
Produce
detailed plan
|
The Role:
Project Manager works with the rest of the team, and
especially the project stakeholders, to identify the high-priority work
items from the Artifact: Work Items List to be addressed
within the iteration. The high-level objectives provide guidance on what work
items should be considered. The team should break down work items so they fit
within the iteration as necessary. Actual effort to complete each Work Item
should be estimated. When a team has decided to take on a Work Item, it will
assign the work to one or several team members. Ideally, this is done by team
members signing up to do the work, since this makes people motivated and
committed to doing the job, but based on culture, you may instead have the
project manager assign the work. |
With the first step, it is ambiguous (to me at least) as
to whether the prioritization has already occurred elsewhere or not.
With the second step, it is implied that that the
prioritization is happening here in this step (or why would we need to work
with ‘especially the project stakeholders’?)
The following exists within Task: ‘Define Vision’:
Define
features of the system
|
Work with stakeholders to capture a
list of features
that stakeholders want in the system, briefly describing them and giving
attributes to help define their general status and
priority in the project. |
The Task: ‘Find and Outline Requirements’ contains:
Update
the Work Items List
|
Capture references to the
requirements in the Artifact:
Work Items List, so that you can prioritize the
work. The WIL artifact of course has the following Purpose
field: |
|
|
|
And the following exists in the Main Description of the WIL
artifact:
·
It provides one list of all the work to be prioritized, estimated, and assigned within
the project. The risk list is prioritized separately.
In summary, I think prioritization of items in the WIL should
be an explicit step somewhere (perhaps in ‘Plan Iteration’ ?), and other
references to prioritization should be cleaned up.
Ben
> -----Original Message-----
> From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Mark.Dickson@xxxxxxxxx
> Sent: 12 March 2007 14:26
> To: epf-dev@xxxxxxxxxxx
> Subject: [epf-dev] Prioritizing
requirements
>
> Quick question;
>
> Can someone tell me briefly where in OpenUP/Basic we
describe
> requirements
> prioritization? Who is the primary performer and
what Task is it
> described
> in? I've flipped though the obvious places in the
content but I may have
> missed it.
>
> Traditionally in the Unified Process it is something
that the Architect
> has
> been responsible for within Requirements workflows,
hence my interest.
>
> thanks
>
> Mark
>
> Mark Dickson
> Executive Consultant
> EAS Practice
> m 0780 1917480
> w www.xansa.com
> e mark.dickson@xxxxxxxxx
>
>
> Whilst this email has been checked for all known
viruses, recipients
> should undertake their own virus checking as Xansa
will not accept any
> liability whatsoever.
>
> This email and any files transmitted with it are
confidential and
> protected by client privilege. It is solely
for the use of the intended
> recipient.
> Please delete it and notify the sender if you have
received it in
> error. Unauthorised use is prohibited.
>
> Any opinions expressed in this email are those of
the individual and not
> necessarily the organisation.
> Xansa, Registered
Office: 420 Thames Valley Park Drive,
> Thames Valley Park,
Reading, RG6 1PU, UK.
> Registered in England
No.1000954.
> t +44 (0)8702
416181
> w www.xansa.com
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
--------------------------------------------------------------------------------
Telelogic Lifecycle Solutions:
Helping You Define,
Design & Deliver Advanced Systems & Software
Learn More at www.telelogic.com
Ben Williams
Product
Manager, Lifecycle Solutions
Telelogic UK Ltd, Northbrook House, Oxford Science Park, Oxford, OX4 4GA, United
Kingdom
Phone: +44 (7710) 637 067
Fax: +44 (1865) 784 286
Mobile phone: +44 (7710) 637 067
Ben.Williams@xxxxxxxxxxxxx
http://www.telelogic.com
Telelogic
- Requirements-Driven Innovation!
-------------------------------------------------------------
The
information contained in this e-mail, including any attachment or enclosure, is
intended only for the person or entity to which it is addressed and may contain
confidential material. Any unauthorized use, review, retransmissions,
dissemination, copying or other use of this information by persons or entities
other than the intended recipient is prohibited.
