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?
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?
Comment