Requirements process

[Spartacus]

Regular problem. Everyone categorises their requirement as High / Must Have as they know that if they don't it will just be thrown out at the first scoping meeting.

That's where a good BA comes in, who will winkle out what the stakeholders actually need, as opposed to just being a scribe and documenting what they say they want.

[d000hg]

Where in your myriad documents do you define what is in scope for delivery and what is out of scope for delivery.

Does the customer have a copy of this document, were they required to sign it off?


Sent from my iMinion using Tapatalk

WHS for once It's entirely normal that things initially seen as must-haves get postponed or cut entirely due to budget or they simply aren't as important as was imagined initially. But documenting which things they are would be nice if you want to make sure you get paid

[suityou01]

Where in your myriad documents do you define what is in scope for delivery and what is out of scope for delivery.

Does the customer have a copy of this document, were they required to sign it off?


Sent from my iMinion using Tapatalk

[vetran]

Indeed - got any jobs???

the radiators need bleeding

[Gruffalo]

And I am Agile trained too...

Are you house trained and toilet trained?

[original PM]

Ooooooh! smarty pants

Indeed - got any jobs???

[norrahe]

And I am Agile trained too...

Ooooooh! smarty pants

[original PM]

WHS - almost straight out of the Prince 2 manual

And I am Agile trained too...

[norrahe]

it depends on your point of view.

All requirements should really go through the Moscow rating so it is clear what is a must have and what is not.

However what I find is that ever requirements becomes a 'must have' (and the justification is often that why would they have asked for it if they did not feel they needed it?)

And so what we actually do is descope the requirements so that when the project is delivered into test it is clear what requirements are to be met and what are not.

In addition however each requirement should be able to be clearly identified as contributing towards the overall goal of the project which is why it is vital to make sure the goal is clear and concise.

WHS - almost straight out of the Prince 2 manual

[original PM]

it depends on your point of view.

All requirements should really go through the Moscow rating so it is clear what is a must have and what is not.

However what I find is that ever requirements becomes a 'must have' (and the justification is often that why would they have asked for it if they did not feel they needed it?)

And so what we actually do is descope the requirements so that when the project is delivered into test it is clear what requirements are to be met and what are not.

In addition however each requirement should be able to be clearly identified as contributing towards the overall goal of the project which is why it is vital to make sure the goal is clear and concise.

[Gruffalo]

Is it it normal to capture requirements that won't be delivered? I thought that the requirements stage was all about agreeing what would be delivered. What is the standard best practice?

Initially, yes, very normal. Conference Room Pilots (CRP's) then knock about a little more to work out what can be delivered through vanilla, where the mods are, how business critical mod-related requirements are, and eventually distills into something more developable.

Are you plugged into the RACI?

Ideally the test team will be on the case and be plugged in with the Project Management Office as part of the review process, and run an 8-point requirement test to ensure how developable and testable the requirements are, leading to greater ability to get cracking with effective and efficient test scripts.

There should be a robust, agreed workable programme method that is used.

All rather idealistic, but rarely seen, which acocunts for the amount of programmes that get canned.

[DieScum]

Very basic question but I've never really been involved with this side of things.

At current gig I have to do some documentation around delivered features.

There are BAs who create a requirements doc with requirements for a feature. Then an architect does a design. Then developers built it and testers test.

The requirements docs include a lot of requirements, approved by business and project, that haven't been delivered.

I asked the PMs about this and they told me the requirements were a wish list and the design stage would decide what gets implemented. I can understand this because some of the requirements aren't feasible.

But does this sound like a normal project workflow? Is it it normal to capture requirements that won't be delivered? I thought that the requirements stage was all about agreeing what would be delivered. What is the standard best practice?