Inadequate requirements. They’re the #1 cause of project failure.
While we’ve come a long way from massive, antiquated requirements documents, requirements (or epics and user stories) still provide a GPS for your product.
So, how do you make sure requirements:
-Communicate your true vision?
-Keep your project lean and on track?
-Adapt to change without adding risk?
-Transform into a quality product?
Join us for this webinar to learn essential tactics for better requirements management — from discovery to review and testing.
We’ll cover:
-Common signs of poor requirements management.
-Principles of modern requirements.
-Essential communication tactics for results-driven development.
-Ways to streamline the requirement review process.
-Tips for adapting to changes in requirements.
-Templates for organizing your requirements.
-PLUS, get concrete tips from ACTUAL requirements management tool makers.
36. Follow us for news and insights!
Visit www.perforce.com
Notas do Editor
Nico is a Technical Sales and Professional Services Manager for Helix ALM. He specializes in technical guidance and product development efficiency for global organizations. An expert in software development, he is dedicated to helping customers drive quality product strategy.
Requirements are lowest cost to correct errors, highest cause of project failure. You’re requirements can either be cheap or expensive
Collaborative: yesterday’s reqruiements mgmt. documents were massive massive RM written solely by BAs perhaps and they trickled toward the development organization. Today’s requirements need to be much more collaborative, they need input from a variety of sources. Customers. Support team. Even sales from prospects & marketing can provide helpful input.
Well-communicated, documented, understood. Always been true, This is particularly important for modern global teamwork, where we’re communicating in different time zones and with sometimes with different primary languages.
Just enough & just in time. We need to deliver the right thing to market and as leanly as possible. So don’t overdo requirements in terms of quantity and don’t overdo them in terms of time, don’t plan Requirements that won’t be implemented soon, because times change.
Not compromised by change. Change is a given. How do you make sure that change doesn’t break or compromise your product. These days everyone needs to stay aligned, when change happens you need to make sure that who matters knows (for example, when a requirement changes, does the tester know about it in enough detail to rewrite tests?).
Keep in mind that different kinds of requirements can have different processes/stakeholders/reviewers/etc.
Different people understand words,
“Test this” provides good transition to QUALITY section
Larger teams? Individuals speaking different languages? Too easy to think we communicated something when we did not! Have a discussion in which we walk away and one of us writes it up in our requirments doc, but diden’t means
This is a tightrope, because there’s a risk of undercommunicating and a risk in overcommunicating.