Featuring Accenture Partner Randy Vogel
The cost of rework, poor quality, and the associated delays in realizing return on investment continue to plague IT organizations. Getting the requirements right is critical to solving these problems.
This webinar, drawing on years of practical experience at Accenture, will describe how applying standardized techniques and enabling users through tools and usage guidance helps reduce costs, increase quality, and deliver applications sooner.
Join this webinar to learn:
• Key requirements gathering techniques
• How requirements techniques can be used effectively together
• How an integrated set of tools can be used to automate and enable the techniques
Presenter: Randy Vogel
Randy Vogel is a Partner at Accenture with over 21 years of experience in IT and software development. Randy has been responsible for delivering applications across a broad spectrum of platforms and technologies using globally distributed development teams. Randy currently leads Accenture’s strategic tools program focused on standardizing the tools and processes used globally to deliver high-quality solutions to Accenture clients.
Adam
Hi,
do you complete testing for each BR even if you don’t have any SI developpement?
Is there an assumption that requirements definition precedes development? We see this as a dialog (some definition, some development, some more detail, more development) which addresses both requirements capture and change.
Requirements definition should precede development. With Agile approaches you’ll start to see a bit of a blur between the two, but it’s still critical to capture the requirements first so as you start to implement your iterations you can be sure you’re focusing on the highest priority items and touching on them in a way to achieve the expected result.
I’ll precise my idea.
We used to do testing only for br that need IT developpement but we want to implement testing for all BR and i would like to get you opinion on that.
I think it is good even if that require more time on each project.
what are your thoughts on team roles involved in requirements gathering/management? dedicated requirements roles (business analysts) vs broad team training on req mgt?
It’s a good idea to have dedicated roles focused on requirements to ensure the business needs are accurately and effectively addressed. You’ll likely have other non-dedicated roles also involved in requirements such as designers and developers to help drive out feasibility and approaches but they’ll work in conjuction with the business analyst role.
BR always comes before development but not always and i’m talking about the one that doesn’t need development. We’ve seen that those change are usually been ok but sometimes, we’ve seen that those change were giving more impact than expected so we though about testing all of them.
For exemple, we want that the representative understand the business rule under 5 sec.
The focus of the presentation was on requirements when application development is involved and touched on the specific interactions throughout the development process, however generally speaking all business requirements should be tested.
Can the speaker define “Business Requirements”? Some companies define them to mean something more akin to the business objectives (e.g., increase throughput 20%, spread load over a pool of servers, etc.), whereas others define it to mean something more akin to software requirements (i.e., features, functions, UI mock-ups, etc.).
I was referring to all levels of requirements. Initially the requirements will be at the business level as you described but through refinement will become lower level detailed requirements such as application or performance support. The techniques and tools based around text, use cases, and even process models are applicable across all types of requirements. The visual-based techniques are more appropriate as you start to work through application-type requirements.
Can the speaker address whether requirements should always be “required” and when “optional” or “High, Medium, Low” rankings can/should be used?
If I understand the question correctly, requirements will generally have a ranking associated with them to help guide the prioritization. This priority will allow you to define releases/iterations for how to introduce and sequence the new functionality.
Are there any techniques that may benefit decentralized teams (geo dispersed)?
Which of these techniques / tools is recommended for Agile development?
We’ve found that the techniques that leverage visualization, even use case visualization through RAVEN, are very helpful for distributed teams. Text-based requirements can too often introduce ambiguities that are even more pronounced when the teams are geographically distributed.
The techniques can be applied to Agile. Probably the biggest difference when using for Agile purposes is the level of detail that’s provided. Although Agile approaches provide for flexibility, it’s important to have a clear target for what’s expected as the outcome.
One of the things we struggle with is that our business associates will begin doing design while giving us requirements. DEFINING “requirements” for the business user might a good starting point (as another poster noted above).
The caution here is to fully understand what’s expected before getting too deep into the design. You’ll continue to refine the requirements to get to an appropriate level of detail and clarity and this can start to blur the line with design, but make sure the requirements are well understood so when design really begins the team is designing for the right outcome.
From what Randy mentioned throughout the second stage of the presentation, it seems that his team at Accenture use a lo of tools: Raven Flow, ARIS, Rational, Axure and then MS office package. With these, it seems that there is not one tool (or at least 2) for requirements. I am trying to convince uppermanagement to pick Raven or anything close and in the same price range but I will be very careful to mention that Raven will not do all. That is important since my company is very frugal.
We’ve found that there isn’t 1 sole tool that can be used. It’s similar to what you might see from Microsoft Office where you have a tool for word processing, a tool for spreadsheets, and a tool for presentations; you’ll likely use all of these tools in your daily work. The key will be to determine where you’ll get the most bang for your buck and go with that. For example, if your projects make use of use cases and you don’t have lots of visual-intensive updates RAVEN would be a good choice.
Hi
how do you trade data between the tools you use (Raven/Axure/Composer etc)? How do you ensure that there is no loss of data or information AND that the flow is consistent across each tool?
We’re currently not sharing data at a detailed level. We use Rational Requirements Composer as the central repository to store all the artifacts and can link at the artifact level for traceability. From this traceability, we can link a use case to a storyboard or simulation and the team can then reference the use cases as they’re building the storyboard or simulation.
Requirements traceability is vital for supporting consulting deliverables, but what value does it add if the development is internal and the software is accepted (passes acceptance testing)? Traceability, which assumes that development is built from requirements, seems to be a method for explaining mistakes rather than preventing them. Wouldn’t test driven development provide quality assurance with less overhead?
Traceability also helps to assess changes to scope and subsequent enhancements. The intent is that throughout the process the team always ties back to the requirement so that whatever they’re doing, whether design, build, or test, is synced back to the requirements.
How do you derisk the people factor in the whole?
We’ve leveraged functions of the tools as well as checklists to “derisk” to some degree, but the skill of the people is a critical factor that shouldn’t be overlooked or minimized.
What is the normal length of time for requirements completion? Or is there a general timeframe?
The duration will be dependent on the characteristics of the project. One of the studies I shared showed the impact of the requirements process to cost overruns. The 2 data points highlighted showed that projects spending 8-14% on requirements will have cost overruns <70%, while projects spending <8% will show overruns of 70-200%.
The speaker promotes many tools to facilitate the requirements engineering process. Then all the output is fed to Req. Composer, and then again translated to RequisitePro. It seem to me as many translations during which the original message could be lost. How do you ensure that all the req. sources are in sync?
The process doesn’t require translation of content so there’s no concern about losing messages. We use the different tools to capture the requirements in different formats and then those formats are stored in their native format in Rational Requirements Composer as the repository. The traceability provided in Requirements Composer allows you to link the different content so it ties together. Once the requirements are fairly solid, we then link with Rational RequisitePro which takes the text into RequisitePro; this is not a translation as the text comes over verbatim.
Great webinar? How do you handle the mechanics of transitioning your Word and Excel based text requirements artifacts into Rational? How is this managed?
Thanks. Joe.
Rational has a standard interface to allow importing Word and Excel documents directly into RequisitePro. The import will create distinct requirement entries for the content.
Are all Accenture business analysts expected to work with Aris Business Architect, Axure RP, Rational Requirements Composer, and Ravenflow or do the analysts specialize in a software tool?
It’s more of a specialization approach, although most business analysts will make use of RAVEN and our Word-based plug-in for highlighting problem words and phrases.
Just a comment. I found the webinar very interesting and Randy answered my questions before I managed to type them out….every time! The set of tools, although too complex for an organisation whose primary focus is not software projects, does close the gap between functional and informational requirements gathering and modelling for me. Thanks for an informative presentation.
OK, now the webinar is finished I can clarify my previous question. It appears that you use one tool per method, but if more than one method is used to elicit requirements (1) how do you trade data between those tools to ensure that the data/information/process is consistent between the tools and (2) what data/information/process is fed to the repository? This is important since the repository maintains traceability and if that’s compromised the developers/testers/BAs/PMs won’t know what’s required and the whole exercise is wasted
Check my response to Katarzyna about how we pull the different tool content together.
After reading the comments above, I see that some people have similar questions about synchronizing artifacts when multiple tools are used. How does Accenture ensure that the requirements numbering is reflected in the use case numbering, wireframe numbering, and testing scenario numbering?
You mentioned that there are supporting documents that list the 6 or 7 steps that accompany the tools depicted in the slide. Would you please send those?
This was a highly valuable webinar. I anticipate interviewing for a position with a a large project and need to understand how everything comes together for reuqirements gathering. This was perfect. Who knows, should I join the project perhaps they will need these tools! Well done!
Thank you.
The detailed steps get into our Accenture intellectual property and I’m not able to share that level of detail.
Hi,
I would like to know for what kind of projects, business process modeling should be used for requirements process.
Business process modeling is generally called for when doing a large custom project or when implementing an ERP package, especially SAP or Oracle. You’d also want to consider business process modeling if you intend to used the models for BPEL execution.