Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Requirements Management, Resource Management
Experience PMs: What is Requirements Documentation?
Network:495



I know the book definition - but as I am transitioning and pivoting in my career; I was hoping to get some REAL WORLD examples of Requirements Documentation to assist me in fully grasping it when I am asked about it.

Thanks
Sort By:
Page: 1 2 next>
Network:364



In my field it's very extensive. We have government requirements which are generally very broad, as well as a program level set of Design Requirements and Objectives (DR&O) that govern all designs where we decompose broad industry requirements into specific measurable requirements. Those are decomposed and elaborated on by function, system (SR&O), subsystem and part down to the commodity/part level, we have Specification Control Documents (SCDs) which describe the detail level requirements for suppliers.

The assembly drawings the mechanics use to install parts are requirements for the completed work. There is a manufacturing plan with requirements for how things are assembled, and quality requirements embedded into the plans for what must be verified.

On top of the requirements definition side, there is also a very robust process to verify the requirements have been met and show compliance to government regulations.
...
1 reply by William Washinski II
Dec 27, 2018 9:35 PM
William Washinski II
...
Thank you -- the fact that it is extensive is maybe why I am struggling to wrap my arms around it when asked.
Network:495



Dec 27, 2018 7:19 PM
Replying to Keith Novak
...
In my field it's very extensive. We have government requirements which are generally very broad, as well as a program level set of Design Requirements and Objectives (DR&O) that govern all designs where we decompose broad industry requirements into specific measurable requirements. Those are decomposed and elaborated on by function, system (SR&O), subsystem and part down to the commodity/part level, we have Specification Control Documents (SCDs) which describe the detail level requirements for suppliers.

The assembly drawings the mechanics use to install parts are requirements for the completed work. There is a manufacturing plan with requirements for how things are assembled, and quality requirements embedded into the plans for what must be verified.

On top of the requirements definition side, there is also a very robust process to verify the requirements have been met and show compliance to government regulations.
Thank you -- the fact that it is extensive is maybe why I am struggling to wrap my arms around it when asked.
...
1 reply by Keith Novak
Dec 28, 2018 1:18 PM
Keith Novak
...
Bear in mind that I am giving you perhaps the most complex case where the requirements documentation outweighs physical product. If you are looking to move to something that is very heavy in requirements, there are whole departments dedicated to it. For smaller projects or less regulated fields, it is quite a bit different, but the theory side of requirements generation, validation (are they right and are they complete) and verification (did we meet the requirements), is largely the same.
Network:34



On a simpler explanation you can mention the document which is created by taking input from customer specifications + Safety ( Regulatory)+ Non functional (Design & performance).

It purely based on the field it is related to.

On more point you can add is about tractability . For example - System to software requirement. which is also a part of requirement management.
Network:1703



William -

On a predictive project, one tends to see the creation and baselining of a formal requirements document (E.g. BRD) whereas on adaptive projects, it might be more beneficial to consider the use of a requirements management tool (either a "True" RM product like Blueprint or a work management tool like JIRA combined with Confluence).

Key attributes which apply regardless of the form the deliverable takes include:
- coverage of all required functional, control and non-functional requirements to "sufficient" detail to ensure shared understanding
- traceability between different levels of requirement and the ability to trace forward to downstream outcomes (e.g. test cases)
- evidence of review & approval as required by organization standards and regulatory requirements

Kiron
Network:2431



Good response from Kiron.

Requirements documentation is the 'What' from the client. It has a little 'Why' sprinkled in for backstory and context. For example, when I was a business analyst, for each requirement, I would add the rationale behind it. This helped to 'complete the circle' of the requirement, mapping it to a tangible problem to be solved.

There are a number of different elicitation techniques to get the information to produce the requirements document; observation, workshops, interviews, questionnaire. The document can be socialized during or once completed for verification. This then becomes an authoritative document from which the project is based. In my experience, this document would then be used by the developers to build out a design document - the 'How'.
...
1 reply by Ralph Azzi
Jun 21, 2019 11:41 AM
Ralph Azzi
...
Excellent response.
Network:126



This is very a interesting topic. Thanks to William for posting it and all those that are contributing providing their insight.

Sometime, we deal with these applications in our projects management process, but do not identify it as a define process, so its becomes more of a routine operation or coordinated activities than a specified project management process that is define as a requirement in the project lifestyle.

I am looking to read more about it, to enhance my ability to identify this application/process or tool when ever I am working on projects business or none business related.

Thanks to you all!
Network:364



Dec 27, 2018 9:35 PM
Replying to William Washinski II
...
Thank you -- the fact that it is extensive is maybe why I am struggling to wrap my arms around it when asked.
Bear in mind that I am giving you perhaps the most complex case where the requirements documentation outweighs physical product. If you are looking to move to something that is very heavy in requirements, there are whole departments dedicated to it. For smaller projects or less regulated fields, it is quite a bit different, but the theory side of requirements generation, validation (are they right and are they complete) and verification (did we meet the requirements), is largely the same.
Network:746



There are also some really good templates on PM.com for:
- Traceability matrices
- Formal rqmnts documents

Check these out as they will help you understand some of the concepts the experts outlined above.
Network:2559



All requirements are coming from stakeholders, they are are a request to the projects. Since not all stakeholders are aligned, and they might wish for more than time and cost constraints allow, the scope statement is the answer from the project what requirements will be fulfilled, given the balance of scope/time/cost.

Requirements can be documented in statements with 3 parts:
As a (stakeholder) I want to (requirement) in order to (expected benefit).

In agile environments that is also the form in which backlog items are often documented.

Requirements management for certain industries is a serious business and supported by standards and sophisticated tools, like in automotive (Doors) or construction (BIM).
Network:85



Dec 28, 2018 8:45 AM
Replying to Andrew Craig
...
Good response from Kiron.

Requirements documentation is the 'What' from the client. It has a little 'Why' sprinkled in for backstory and context. For example, when I was a business analyst, for each requirement, I would add the rationale behind it. This helped to 'complete the circle' of the requirement, mapping it to a tangible problem to be solved.

There are a number of different elicitation techniques to get the information to produce the requirements document; observation, workshops, interviews, questionnaire. The document can be socialized during or once completed for verification. This then becomes an authoritative document from which the project is based. In my experience, this document would then be used by the developers to build out a design document - the 'How'.
Excellent response.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

We are ready for any unforeseen event that may or may not occur.

- Dan Quayle

ADVERTISEMENT

Sponsors