• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Requirements process

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Requirements process

    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?

    #2
    Originally posted by DieScum View Post
    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.

    Comment


      #3
      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.

      Comment


        #4
        Originally posted by original PM View Post
        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
        "Ask not what you can do for your country. Ask what's for lunch." - Orson Welles

        Norrahe's blog

        Comment


          #5
          Originally posted by norrahe View Post
          WHS - almost straight out of the Prince 2 manual
          And I am Agile trained too...

          Comment


            #6
            Originally posted by original PM View Post
            And I am Agile trained too...
            Ooooooh! smarty pants
            "Ask not what you can do for your country. Ask what's for lunch." - Orson Welles

            Norrahe's blog

            Comment


              #7
              Originally posted by norrahe View Post
              Ooooooh! smarty pants
              Indeed - got any jobs???

              Comment


                #8
                Originally posted by original PM View Post
                And I am Agile trained too...
                Are you house trained and toilet trained?

                Comment


                  #9
                  Originally posted by original PM View Post
                  Indeed - got any jobs???
                  the radiators need bleeding
                  Always forgive your enemies; nothing annoys them so much.

                  Comment


                    #10
                    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
                    Knock first as I might be balancing my chakras.

                    Comment

                    Working...
                    X