Hi PPT (or anyone else is welcome to comment too),
Do you mind providing feedback on the below questions? Thanks.
Describe the main steps in the requirements management process? Make four points in your answer.
1. Capture – liaise with the diverse stakeholder group to ensure that all their requirements have been communicated and captured. The requirements are high level views the stakeholder needs, not necessarily what is needed. The method of capturing the requirements is dictated by the organisations governance (methods include, user case, brainstorming, pre-project documentation, prototyping etc).
2. Analyse – requirements are analysed against 4 criterion: Value, Priority, Time, Process. They are as follows: Value, what value (benefit) will the requirement add to the organisations goals? Priority, how important is this requirement compared to others? Time, when does this requirement need to be met? Process, how will this require be delivered/satisfied/fulfilled?
3. Test – Test that all the requirements stated cover all the views of the diverse stakeholder group, ensuring comprehensiveness. Requirements are tested once they have been constructed & also during the project too. Different audiences might need to validate different layers of requirements, represented in V-shape model.
4. Document – formally document each requirement in the PMP. During scope definition, the high-level requirements are then decomposed into more granular requirements giving more accuracy/clarity. Requirements will be categorised into 4 groups: user, system, functional, technical. Once documented, the requirements are then under formal change control & need approval before changing.
c
What might happen if the requirements are not properly managed on the project? Make 5 points in your answer.
1. Excessive changes – Incorrectly documenting (or excluding) the requirements originally might lead to excessive changes. By utilising stakeholder engagement & concisely documenting the requirements initially will help mitigate excessive change requests.
2. Poor Quality – If the project does not deliver products the client defines as ‘fit for purpose’ then project will be a failure. Quality is achieved through understanding Stakeholder requirements & delivering them all in the project products.
3. Schedule overruns – The project may exceed schedule through having to rework products if the initially requirements are not delivered the first time. The saying ‘doing the right things, the first time around’ should be adopted with requirements to avoid overruns.
4. Enhancing/introducing risk – Incorrect management of requirements will not only enhance risks, but might introduce new ones too. If the requirements are ambiguous then there is a risk of the project costing more & delivering a substandard product.
5. Incorrect prioritisation – The wrong requirements could be prioritised over requirements which will deliver more business benefit. It is important to ensure delivering the key requirements that add the most benefit first.
Kit these answers are ok, however remember they want two or three sentences. I would recomend turning your first heading into a sentence. For example
One of the most critical impacts of poor requirements are excessive changes in the project late in the day. The are caused by incorrectly documenting (or excluding) the requirements originally might lead to excessive changes. By utilising stakeholder engagement & concisely documenting the requirements initially will help mitigate excessive change requests.
Thanks Paul. Just to confirm, do you need to add an example to every describe type question?
These are ok answers, if you could add an example to each the they would be perfect. So for example you could say that a user workshop is a good way of capturing requierments for a IT system.
Have a very merry Christmas