Modified on by VijaySankar
There have been interesting thoughts on how requirements and should requirements be managed in agile projects. Some believe that requirements management is meaningless; some believe they are still a critical factor irrespective of the methodologies one follow. Here we bring to you an interview with Mary Gorman, an Agile Business Analysis Expert at EBG Consulting where she argues that business analysis is essential for agile success.
Mary Gorman, CBAP, CSM, is VP of quality and delivery at EBG Consulting, whose experts help deliver high-value products that delight customers. Mary works with global clients, speaks at industry conferences, and writes on requirements topics for the business analysis community. In addition to serving on the IIBA® Business Analysis Body of Knowledge® Committee for four years, Mary helped create the first certification exam for the Certified Business Analysis Professional™ (CBAP®).
We've heard comments like "you can throw away all that requirements and analysis stuff now we're going Agile." Have you come across this and what's your view?
It's a common misconception. In fact, requirements drive agile teams! At EBG Consulting we find when agile teams collaboratively analyze requirements, they can speed development and delivery of high value products. The ability to be focused, nimble and disciplined about your requirements is essential for successful agile delivery.
So how does business analysis change as you adopt Agile practices?
You plan and analyze regularly to support a steady flow of product delivery, a hallmark of successful agile teams. On agile projects, we plan to re-plan. A plan represents your allocation of requirements—really options for satisfying product needs—to delivery cycles. Rather than trying to acquire all the possible requirements upfront at the start and create one big plan, you plan continually, using feedback from prior deliveries to adjust your plan. This in turn means you are continually analyzing requirements to discover high value options for the next delivery. Planning and analysis are interdependent and synergistic. See this article for more details.
Agile analysis is done just-in-time—you want your requirements to be “fresh”. You adjust the precision and granularity of requirements taking a just-enough approach. You make use of good analysis tools and techniques. For example, you might sketch a context diagram to quickly visualize the interfaces needed for a release, a minimum marketable feature, a use case or a story. Or organically explore requirements using a data model or state diagram. For more ideas to tune analysis for agile, visit Agile Analysis Challenges
What about the role of the business analyst in Agile?
In our forthcoming book, my co-author, Ellen Gottesdiener (EBG’s founder and president), and I write about a product partnership that collaborates to discover and deliver valued products. The partners include diverse perspectives from the business, customer and technology communities. We have found this partnership is critical for agile product success. (The book’s title is Discover to Deliver: Agile Product Planning and Analysis. Read more about it here.
Often business analysts ask us where they ‘fit’ in this partnership. Our response is to ask, “What are your skills?” An agile team needs strong skills in analysis, modeling, elicitation, facilitation, risk analysis, prioritization, strategic thinking, verification and validation along with a sound understanding of the product’s domain. The person who possesses a combination of such skills will be a valuable and valued team member.
Who should attend the webcast on How Business Analysis is Essential to Agile Success and what will they gain from it?
The webinar’s content has broad applicability. It may benefit someone involved with planning, analysis, valuation, validation and verification; teams and organizations transitioning to agile; product champions and product owners who have the responsibility for making decisions about what product options to deliver, anyone on an agile team who recognizes that user stories, user story maps, personas are often not enough to communicate product needs. The webinar provides ideas for holistically exploring and evaluating product options within a framework the agile team can use to reach a shared understanding of high value product needs.
Mary will be joining with us on Wednesday, June 27, 2012 for a webinar where she will expand on the below discussions to build a case that business analysis is your key for
Discovering product options
Collaborating to create Agile plans
Conversing daily about what to deliver
Adapting your product with each delivery cycle to respond to changes in business needs
Maintaining a constant flow of business value
Register for the webinar here
A replay will also be posted in case you missed the webinar on Wednesday. We believe this interview gave an insight into why business analysis is critical to agile projects. For more interactive discussion join us in the webinar.
What you think about requirements in agile? What level of requirements management/analysis do you follow in your agile projects?
There is no doubt that the evolution of computing has moved into the era of the mobile device and any business that wants to remain competitive in an increasingly difficult economic environment needs to embrace this with the care and attention it deserves.
With over a million devices being activated every single day it is predicted that by 2013 mobile phones will overtake the PC as the most common web access device worldwide!
Companies that simply try and tweak their existing web sites to run in mobile browsers are missing a trick as users expect very sleek interfaces that make use of their devices capabilities such as Geo-location and camera. With this in mind the perceived quality of the application comes from both its functionality and perhaps more importantly the design. The design of the applications user interface is also critical when trying to improve brand loyalty and therefore businesses are keen to see their brand image extended to mobile devices where they can reach a much wider audience.
So where does Requirements Management fit in?
Well, a good requirements management process that is incorporated into the wider development life cycle will allow the business to communicate exactly what is required of the mobile application; enabling the development team to be clear on what needs to be created, and for testers to begin writing test cases earlier in the lifecycle. With the need for good user interface design it is important that requirements are not purely textual and so with tools like Rational Requirements Composer
, Business Analysts can model Use Cases, Business Processes and also visualize the user interface through UI Sketches, Screenflows and Storyboards. This means the business can be very clear on what the expected result should be and remove any unnecessary ambiguity that only slows down development and ultimately prevents applications going to market quickly.
One significant trend in the development of mobile apps is the adoption of Agile methodologies such as Scrum, which fits in well with the short timescales and rapid change and release management that mobile apps have. This makes it even more important for the Requirements Management process to also be agile and allow greater collaboration not only within the Business Analysts team, but also with the other teams involved such as development and testing. A web based requirements management tool like RRC encourages wider engagement with stakeholders and also provides dashboards with live information, collaborative reviews and reporting to promote visibility and allow decisions to be made quickly and effectively.
Traceability is one of the corner stones of good Requirements Management, because without it you cannot determine if the resulting product has actually satisfied the original requirements outlined by the business. RRC is a part of the wider solution called Collaborative Life cycle Management and allows the requirements to be linked to the resulting development work items and associated test plans, test cases and defects. This means that from any given requirement you can see exactly what development task is going to implement it, which test case is going to test it and what defects were found in relation to that requirement.
In summary, mobile application development is an exciting and important part of any business plan and due to its inherent complexity you really need the right tools to make it a success.
In this post Jim Hays
writes about the various options available in testing how the requirements are met in IBM Rational DOORS.
Jim works as a Senior Systems Engineer at IBM. Jim started his career in 1982 working for software providers. Jim’s career history is an interesting one; he hasn’t worked for many software companies over the course of his career. He worked for Applied Data Research (7 years) that eventually got bought by Computer Associates. He then moved to Goal Systems, that got bought by Legent (6 years). Legent, then got bought by Computer Associates. He then spent almost 10 years at Sterling Commerce that just got bought by IBM. After Sterling Commerce he joined Telelogic where he got into the ALM market that eventually got purchased by IBM Rational (7 years).
I’ve been involved with DOORS for over 7 years, and absolutely love the tool. My job at IBM is to technically support our sales team, and our customers, not only for DOORS but many other solutions we offer. I have had a lot of experience working with our DOORS customers understanding how they use DOORS, and even though DOORS is a requirements management solution there are other types of information being put into DOORS other than just requirements. An example of that is the fact that customers will put in test data into a DOORS module, and enable easy linking between the requirements and their related validation/verification results.
Note: Please click on the screenshots for a better view
Provided below is an example showing that. In this DOORS View we see traceability between 4 modules:
User Requirements>Functional Requirements>Functional Test Plan>Functional Test Cases
DOORS has had in it for years a capability called the Test Tracking Toolkit. This enables one to capture in a DOORS module test results by duplicating attributes based upon creating a new test run to store test run results for each run uniquely. This over time will create a lot of attributes in order to capture and store test run results per run. Both of these described usages of capturing tests and test results enable quite easy linking between the DOORS requirements and their related tests and test results. Below are the options available utilizing the Test Tracking toolkit.
(Read in clockwise from top left)
So what are the positives and negatives of both of these usages of DOORS modules to capture test, validation, and/or verification information. The positive is the ability to store and easily link requirements to testing results using standard DOORS linking. If requirements change that are linked to test-based modules, then standard DOORS “suspect links” would notify the folks maintaining the test-based DOORS modules of that requirement change to see if they need to update their test plan and or have to retest the test case. The other question is who is maintaining/updating the DOORS test-based modules? Are the actual testers going into DOORS to update the test results? Are the testers using a spreadsheet to capture test results and giving that to a DOORS user to update in DOORS? It is my opinion that either one of these scenarios discussed are fine for projects that only do manual testing, and don’t have a lot of testing (i.e. test runs) to perform. The other issue is that the actual testing can be occurring on different environments. For example if one built an application that is web-based and will run on different operating systems, then one would need to test all of those types of configurations . If one is building an embedded software device or a software application, then one might want to not just do manual
testing, but instead automate the execution and capturing results via automated
In my opinion I think a solution like DOORS for requirements management is great for that; whereas, I believe the folks that are in charge of Quality and/or performing the task of testing should have a solution that is suited for the role they play in a project-Test Management. So the final option for testing I will discuss is how DOORS (managing requirements) can integrate to IBM’s Test Management solution called Rational Quality Manager (RQM). RQM can provide a nice environment for the support of both manual and automated testing.
Provided below are an example “dashboard” that users can configure based upon what they would like to see and an example of a RQM Test Plan.
Provided below is an example of how one used a DOORS View that would be a view of requirements from DOORS that are known by this particular RQM project. Requirements driven testing enable requirements from DOORS to be used to automatically generate Test Cases and build specific links between the DOORS requirements to specific test cases.Screenshot provided in the right show the results of that link creation automation by showing traceability between test cases to DOORS requirements, and also could show development software assets.
The integration between DOORS and RQM is utilizing the OSLC (Open Services for Lifecycle Collaboration). Below is showing a “rich hover” ability to see details about linked items without actually having to navigate the link. One can also see the results of the test execution (pass or fail)
As the testers are doing their work then the requirements from DOORS can map data from RQM into DOORS-based attributes. Below is an example showing the traceability between DOORS requirements and the testing side of things in DOORS. I can see that the latest test case run passed.Provided below are screenshots showing coverage analysis relating the DOORS requirements to the Test Plan and associated test case.
Finally, provided below screenshot shows the test case execution results that were performed via RQM. These are mapped to DOORS attributes via the bi-directional integration and regular DOORS sorting and filtering can be used. For example if I wanted to see what Test Cases failed and or passed.
Hope the blog post was useful. Feel free to contact Jim @ haysji[at]us.ibm.com if you have any queries regarding the options for testing in DOORS.
Also, Jim will be hosting a webinar on the same topic in which he will go in depth the ideas presented in this post about the options related to testing in conjunction to using DOORS. Register for the session here - http://bit.ly/DOORS-Testing_Options
Date: September 7, 2012 (Friday)
Time: 1PM EDT
The importance of communication and collaboration in developing and managing good requirements were discussed in our earlier post on How to enable effective requirements communication and collaboration
. In this guest blog post, Melissa Robinson - a Senior Technical Specialist at IBM writes about how Rational DOORS addresses this aspects with Discussions. Melissa started her career at Telelogic enabling Product Management with technical support around requirements management. Melissa spent 3 years supporting clients getting started with Requirements management at Telelogic. After IBM acquired Telelogic in 2008, Melissa transitioned roles to support clients with Enteprise Architecture initiatives. She received the Carnegie Mellon certification in Enterprise Architecture in 2008 and is TOGAF certified. Melissa now supports clients getting started with evaluating and implementing both requirements management and enterprise architecture solutions.
Note: Please click on the screenshots for a better view
Why did we make this decision? Who made this decision? Who approved this requirement?
These are some of the questions we can help answer with effective collaboration messaging with DOORS. Collaboration messaging is now enabled in DOORS and DOORS Web Access (DWA) with the addition of DOORS Discussions. Discussions allow users to contribute and add comments to requirement objects or requirement modules, users can even add comments to base-lined requirements. Discussions offer a method of having a conversation on requirements. DOORS discussions really break the communication barrier by allowing users to easily make comments or start a discussion on any requirement, including read-only requirements. Discussions can be created in DOORS or DWA and viewed in both DOORS and DWA. Both DWA Editor and DWA Reviewer roles can contribute to Discussions. Discussions capture comments so that you can later review ancillary information about your requirements. Discussions allow everyone to contribute comments and provide a full understanding of requirements.
Here is a simple scenario for using DOORS Discussions. A DWA Reviewer user creates a Discussion on a requirement. A DOORS user then reviews this comment and contributes a comment on the requirement. The DWA user reviews the latest comment and closes the Discussion.
A DOORS user, Susan, reviews the current Discussion created by a DWA Reader user, Kavita. Susan can open the requirements module with a pre-created Discussion view to review the Discussions. Below Susan reviews the Discussion on Requirement AMR-STK-66.
Susan can contribute a comment to the open Discussion.
Kavita reviews the new Discussion comment in DWA. Notice that Kavita is a Reviewer in DWA. As a Reviewer, she can create and add comments to Discussions. Kavita can also close Discussions that she started. Later, Kavita can contribute another comment to the open Discussion.
As the person who first opened the Discussion, Kavita can close this Discussion.Later, in DOORS, Susan can review the latest status of the Discussion using the Discussion Thread view. As a Database Manager role, Susan can choose to re-open the closed Discussion at any time.
Discussions open up the communication thread between several different types of DOORS users. Discussions allow requirements reviewers to exchange views and comments about the content of a requirements module or the content of a requirement object in a module.
We believe the post gave you a sneak preview of how DOORS Discussions help in effectively collaborating and communicating between various stakeholders during requirements management. Feel free to contact melissarobinson[at]us.ibm.com if you have any queries about the topic. Melissa will be discussing the topic in detail in an upcoming webcast on October 5, 2012. Don't miss the opportunity to watch the action live.
Register now @ http://bit.ly/DOORS_Discussions
Eric has worked in the software development industry for over 20 years and is co-author of UML for Database Design and UML for Mere Mortals both published by Addison Wesley. Eric is currently responsible for capabilities marketing of Rational’s application lifecycle management solutions including Agile Software Delivery, Quality & Test Management, Requirements Management and Collaborative Lifecycle Management. He rejoined IBM in 2008 as the team leader for InfoSphere Optim Solutions and later was responsible for Information Governance Solutions. Prior to rejoining IBM, he worked for Ivar Jacobson Consulting as VP of Sales and Marketing. Before joining Ivar Jacobson, he was director of product marketing for CAST Software. Previously working for IBM, Eric held several roles within the Rational Software group including program director for business, industry and technical solutions, product manager for Rational Rose and team market manager for Rational Desktop Product. He also spent several years with Logic Works Inc. (Acquired by Platinum Technologies and CA), as product manager for ERwin.
As I think about IT today, there comes a rebirth in some ways of the importance of architecture and requirements. We are in an era of “ANY” -- meaning that applications and data can be accessed from anywhere, by anyone, and at any time.
Looking back at the applications of yesteryear (two or three years ago), we didn’t expect much from the web or mobile-based applications. We could view, run some reports or do some basic tasks, but to do the real work, we needed to go to the fat-client. Now, in today’s era of any, the user interface may look different, but the capabilities had better be the same since we expect near full capabilities no matter our device or interface.
This puts a new found set of requirements on applications and their development, and is making modeling and requirements (analysis and design) relevant again, but with a new twist – AGILITY. It is no longer a question of “what platform am I developing for” – the question is how quickly can we get it up and running on the latest version of Apple, Android, HTML 5 and whatever other platforms our clients expect the application to run on … and it had better run on all of the latest versions, with no delays, when updated operation systems come out.
And the question that I often receive now, however, is “can I be agile and meet these needs at the same time”? The plain answer is, yes, you can. However, agility doesn’t me you cannot ignore requirements and design. I am not talking about write-once, run-anywhere, rather instead understand the true requirements so that the various development teams can articulate them in code brought to life as features for the users, as they expect to see them. Users are looking for the application to be specific to their hardware/OS (iPad/AppleOS, Droid/Android…) as the hardware has become the platform for not just running the application, but the expected look, feel and usability of it now, too. This often means different developers for different deployment platforms, certainly at the User Interface level.
Designing applications requires that we are prepared. Architectures must be solidified and communicated. Requirements must be consistent and shared. We must model architectures so that developers can build to the designs and not recreate their own, wasting time and resources, and we must share those designs across the team.
Does this get in the way of agility? NO, it will speed agility. By sharing designs, assigning tasks based on architecture needs, we can speed time to market and our ability to deliver high quality software. In the era of any, we may have multiple teams working on the same front-end capabilities for different platforms even though the back-end is the same. But the more they can share, the faster they can be deployed and having the right requirements from users, the more satisfied they will be. We see people changing their desired platform as employers, vendors and suppliers change requirements, so we need to be prepared for the customer who is using an iPad today to be using an Android device tomorrow with the same requirements on the application. Just look at how the world of Blackberry has evolved.
So, as you think about your next project, don’t skimp on requirements and architectures or you may be limiting your agility in the future rather than speeding your time to satisfied clients.
Neal Middlemore has over 14 years of experience in requirements management, this encompasses the associated disciplines of change management of requirements and validation/verification. Neal comes from an avionics systems engineering background and has been working with the DOORS product for over 10 years.
One of the most fundamental benefits that businesses want to get from using requirements management tools is consistent traceability. It doesn’t matter if it is an IT system being developed or an aircraft carrier, the levels of complexity being dealt with determine that traceability across multiple levels of requirements, from stakeholder requests to detailed implementation, is not simple to maintain manually.
Further hurdles are put in our way by the need to comply with legislative requirements, so many different industries these days have requirements placed upon them by government and international standards bodies along with internal corporate standards.
To prove compliance with these legislative rules it is necessary for projects to not only prove that requirements are being managed but also to provide the how and where of their management. What features relate which stakeholder request? What aspects of the solution satisfy safety regulations? Has the realization of the requirement been tested and by whom on what platform?
To answer these questions it is necessary to utilize the traceability capabilities provided by modern tools but it’s not enough to let a tool decide how things relate to each other, it isn’t enough to let individual users decide these relationships. Traceability needs to be considered in the larger context of how you report on it to answer the very questions that led you to consider traceability for in the first place. It’s more than ‘does object A relate to object B?’.
An initiative to define an information architecture of your governance solution will assist in defining your process artifacts and their relationships to one another. Traceability becomes an asset rather than an overhead. A good way to begin such an initiative is having a workshop attended by all project stakeholders i.e. those who have a vested interest in ensuring project success. Most likely these attendees will have a good understanding of the process and what the project needs to deliver. Undoubtedly each will also bring differing perspectives and understanding of what information is required.
The test manager may want to see traceability from individual test artifacts through to the requirements being tested or to determine regulatory compliance has been achieved and whether verification methods have been agreed.
A subject matter expert (SME) may want to see the design in the context of the system level requirements and how it relates to stakeholder requirements.
Everybody wants to see something that is applicable to their job roles, even wishing to see things outside of their typical discipline domains. By asking the questions and documenting the answers you can start to put together an information architecture that makes sense for your project. It’s likely that many information architectures will exist. Not every project is the same and these will have differing sets of required attributes, views and reports of project information and agreed structure of inter artifact relationships.
Modern tools can often create templates for this kind of information to allow the deployment of additional artifact containers as and when required. These can even enforce traceability to ensure the integrity across the project. Above all, it is vital that the needs of the project is documented and communicated alongside of the information architecture to all project members.
Anthony Kesterton is a Technical Consultant in the Financial Services Sector for IBM Rational in the United Kingdom. He has a wide experience in IT development including many years teaching, mentoring and using various IBM Rational tools, as both an end-user and as an IBM employee. He is a regular contributor on the forums on jazz.net. He is co-author of the IBM Redbook “Building SOA Solutions Using the Rational SDP”. As an IBM Community volunteer, he works on programmes dedicated to encouraging children to take an interest in Science, Technology, Engineering and Mathematics (STEM) at school. He also regularly writes in IBM Technical Field Professionals' blog here. Anthony can be reached out at akesterton[at]uk.ibm.com
One of the more interesting discussions I have had about requirements was how to indicate that a requirement must be implemented in the final system. The business wanted to make every requirement “mandatory” which gives no indication to anyone which requirements are really important. Eventually, the business analysts compromised and had levels of “mandatoriness” (I think I might have invented a new term) starting with “least mandatory” to “most mandatory”. The business was happy to accept this. To me, this showed the importance gaining agreement on the requirement attributes. It should not stop at attributes – attribute values, requirements types, traceability and document templates are also very important for a project. All this information should be part of a Requirements Management Plan.
A Requirements Management Plan has nothing to do with time and resources on the project but everything to do with structure of the requirements. A Requirements Management Plan is a way to capture the kind of requirements that will be used on the project, their attributes and other useful information. A typical Requirements Management Plan should contain the following:
- Types of requirements: For example, business requirements, system requirements, and performance requirements.
- Attributes: Important information associated with each requirement type, for example: priority, source of the requirement, or the stability of the requirement
- Attribute values and the meaning of these values: Each attribute should have a range of possible values, and these must be agreed upon and documented. For example, an attribute for priority may have a value from 1 to 5, where 1 means the highest priority and 5 means the lowest.
- Traceability between requirements: There is usually a hierarchy of requirement types. This hierarchy needs to be captured and explained. For example, a feature of the system may link to a software requirement, with the feature at the top of this hierarchy.
- Document templates: Many organizations have standard ways they present information in document form. They might have a Software Requirements Specification with a specific format and structure.
Having the discussion about this plan, and getting agreement on the content of the plan can be enlightening. It can uncover what kind of information is important to the project, how the project plans to manage the requirements (via the attributes), and most importantly, what kinds requirements where overlooked. While the plan is being discussed, be prepared for heated debates about potentially every aspect of the plan.
Spend time creating a Requirements Management Plan for your project as soon as possible. Be prepared for changes to that plan over time as the project works out the really useful attributes or even requirement types. Most importantly, get agreement on the Requirements Management Plan – it really does help a project build requirements that clarify rather than obscure the intention of a project.