Project Management

Project Management Central

Please login or join to subscribe to this thread
Standard Process for Requirements Gathering Project
I'm managing a project where we are writing requirements for a future applications, we derive the requirements from a government policy and meet with the policy SMEs then we develop a BRD out of those discussions. I'm trying to find a standard process to better manage the project but when i research online, all i see is how to write requirements. (that's not what i need)

I need a step by step process to come out with a better quality of product, manage expectations with deadlines and also proper time management with the business analysts

So far, this is what i have
1. Requirements gathering with policy SMEs
2. Develop process flows
3. Develop workflows
4. Write BRDs
5. Obtain feedback from policy SMEs
6. Update BRD as necessary


I would appreciate any feedback to make this process much better. Thank you
Sort By:
Philomena -

The steps you have identified seem reasonable, however, depending on how conceptual the end state is and how long until the actual implementation projects get launched, there could be significant variance between the "as documented/agreed" and "as actually necessary" requirements.

Kiron
I suggest you search for "requirements decomposition techniques". It is a significantly involved systems engineering subject.

Derived requirements are often generated as part of an iterative process that includes the physical, functional, and logical architectures of a system so they can't be created in a vacuum.
Philomena,

what I understand you try to optimize is the requirements elicitation step. You could look up how a Business Analysis handbook describes it, either PMI's BA standard or BABoK. Maybe get in contact with a certified business analyst.

I myself used joint application design (JAD) some years ago to make sure SMEs are involved in finding and verifying requirements: https://en.wikipedia.org/wiki/Joint_application_design

Also, look into industries with excellent requirements management, like automotive. A good example (from Germany) is https://www.automotivespice.com/fileadmin/...PICE_PAM_31.pdf
My recommendation is taking a look to Business Analisys documents created by the PMI. Adding to that take a look to CMU SEI Institute and IEEE Standards. All these have to be included into your requirements management process. Do not take decisions about this in isolation, that´s my recommendation.
Kiron is correct: using what has been done as your "requirements" is the proverbial paving of the cow path.

Try to drive requirements from the expected benefits, not the expected deliverables. Requirements for increasing revenue or market share is a lot different than requirements for yet another app.
On paper, it makes sense. However, I do agree with Kiron's comment.
Considerations for your list:
- Alternate flows
- Exception flows
- Data flow & transformation

With regards to time management for business analysts, is there a clear understanding/agreement of the artifacts they need to produce and the effort/duration needed to produce them?

My experience with BAs (working with them and being one) is that most people don't see everything BAs produce or understand the time it takes to create the various artifacts that are used to make decisions, write code, build interfaces, etc... or the back and forth that is needed, with the accompanying delays when you have to work asynchronously because people are "too busy" to spend two hours together and end up spending 4 hours over two weeks working asynchronously, instead. True story, more than once. I'm not bitter, you're bitter. ;-)

To get to the point, one of the factors in managing BA time is understanding the work and what it takes to complete it. It's managing time AND perception, not just time. Is there a time management problem, a perception problem, or both?
Some good inputs, including places to look for processes and standards. A word of caution: make sure you understand how the terminology is used in those standards.

"Derived" requirement has a specific meaning in engineering. Government requirements are typically high level such as a product must perform functions X, Y, and Z within the following limitations.

A derived requirement is not just adding more specificity to a high level requirement. It relates to the specific system architecture. If the customer has a policy to save data at specific intervals, a derived requirement would be how much data storage is required based on your specific system.

Business analysts and IEEE standards may use that term very differently. Using the same word in different ways often leads to great confusion.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"He felt that his whole life was some kind of dream, and he sometimes wondered whose it was and whether they were enjoying it."

- Douglas Adams

ADVERTISEMENT

Sponsors