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 Saving Changes...
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.
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. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
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.
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
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. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
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. Saving Changes...
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? Saving Changes...
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. Saving Changes...
Community Champion
