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:

Purpose

To collect all requests for work that will potentially be taken on within the project, so work can be prioritized, effort estimated and progress tracked.

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