What does your application portfolio look like today and where does it need to be to respond to your customers in an “instant on” world? Development and testing is feeling the impact from the convergence of Agile, Cloud, and Mobile and understanding the complexity of IT modernization is fundamental to driving your application strategy now and into the future.

HP DISCOVER 2011 VIENNA is right around the corner and you will have the opportunity to join HP Software product experts for a special demonstration that will showcase the latest capabilities from the applications portfolio.  Join us on Wednesday, November 30 at 8:30 a.m. CET to observe an end-to-end delivery scenario that will give you the best practices for how the various roles across your team can work in concert to overcome the challenges of modern application delivery to achieve faster, higher-quality outcomes.

Title: Mastering the Application Lifecycle: a live demo of the latest IT Performance Suite innovations for apps

Day/Time: Wednesday, November 30 at 8:30 a.m. CET

Session ID: TB4411

Location: Session Room 15

We recently produced a new white paper on the  Seven best practices for building applications that meet business requirements.

This is a very robust topic and can be discussed at the theoretical level and at the practical level.  But to call out one interesting point from the paper is that a good requirement “must incorporate feedback

from multiple stakeholders.”  So, who are these stakeholders that are going to have relevant input and comments as to how successful your requirement is, and how it addresses their needs.  And, is this feedback based on fact or opinion?  HP is coming at requirements as a larger component of the overall lifecycle of the application .  The reason that we are such big advocates of this is that we believe traceability allows for other parties in the feedback cycle to have relevant information about requirements that makes their feedback relevant to you.  So, relevancy is the theme here.  Don’t spend your time getting feedback and input from groups that are not seeing the big picture of what your business requirement is meant to do, the need it fulfills, and how it performs in practice.  Gain that feedback before, during and after development and that will increase the success of your individual requirement and your requirements in general over time. 

For a customer point of view on traceability, please listen to our webinar with Novartis at http://www.bitpipe.com/detail/RES/1307975911_949.html?asrc=CL_PRM_HPSOFT

For a copy of our new white paper please visit us at www.hp.com/go/rm

Learn about ALM 11.00, the new Requirements Management features from HP and how they can help you!!

by Genefa Murphy

Whenever you need investment in anything from acceptance of an idea to investment of dollars for the purchase of a new piece of software no matter how strong your proposal is people allows seek justification that that the idea is valid or that the tool purchase will eventually attain a Return of Investment (ROI).  So the question now becomes as the “requestor” how I can I provide this justification?

Hi All,

So here is a bit of a deviation from my usual RM posts to a subject which whilst important for RM is also important across the Application Lifecycle – Reporting (we all love printing out those large word docs)!!

I would like to introduce Ravit Danino, Ravit manages the Application Lifecycle Management functional Architects team, responsible for Quality Center and Performance Testing products as part of the R&D group.

Both Ravit and her colleagues from R&D are trying to research and explore customer’s challenges around reporting. In particular there are two areas currently being investigated: Firstly reporting the data as a raw data for internal usage and for future tracking, and secondly reporting the status of requirements, testing, defects, releases and project status, etc’ to other stakeholders and management level.

Each one of these areas impose different challenges regarding the level of the data you want to expose,  the format you want to use, the aggregation level you want to get and many more. We would like to learn about the challenges you are having with the above, and what are your main needs around reporting and how do you use the current solution (QC or not J)?  We would greatly appreciate if you could spend a few minutes answering the following survey at:

http://www.surveymonkey.com/s/HP_QC_Reporting_Survey

Thanks and we look forward to hearing your feedback.

BTW - in my next post I will be recommending some common metrics and reports to track as part of a healthy approach to RM: traceability, change etc...

So here is the fourth and final part of my 4 part series on Agile challenges in requirements – this post will focus on Control and Visibility.

Challenge: Control and Visibility With so many moving parts, user stories, tasks, code, builds, manual tests, automated tests, etc., you start to run into the challenge of how to make sure you know who is doing what and when and who should be doing what and when.

Solution: It is not only the SCRUM Master who wants to track the projects progress. Having a tool which provides both the SCRUM Master with control of project status and all other stakeholders with visibility and traceability between agile assets will mean greater sustainability and facilitate the presence of “t-shape” competencies in Agile teams. For example, in order to be successful at Agile you need to have both a high level understanding of the other stakeholder roles for team participation while at the same time being a specialist in a particular area (i.e. QA, user stories for the BA, Dev etc). HP Quality Center (leveraging the HP Agile Accelerator) is a central repository for all stakeholders. It has clear domains for the BA, tester, SCRUM Master etc, meaning the SCRUM Master can monitor the teams progress from a central location (because all data is stored in a single repository) and provides you with the necessary tools to do your specialist jobs.

Thanks for reading the series

Genefa

Hi All,

As I have been writing my series on agile requirements and in particular the use of wikis for requirements definition it has got me thinking as to which methods and tools are currently most common and popular when it comes to requirements elicitation. If you have a few seconds please complete this survey to let me know what you are using: http://www.surveymonkey.com/s/NWFTDPD

BTW – part 4 in my 4 part series will come soon.

Thanks

Genefa

Here is Part 3 of a 4 part series on Agile challenges in requirements. You can read Parts I and II - Dynamic Requirements and Tests and Prioritization in my posts from February 2nd and February 16th respectively. So Part III is going to focus on the challenges caused by not involving all parts of the business in the shift to agile. Challenge: Lack of Communality Teams who are used to working in silos with their own processes, tools, languages and hierarchy are now being asked to work as a single team within a common framework. This is likely to create conflict, mistrust and miscommunication. What can we do to resolve this? Solution: Agile is all about doing things better, faster and ultimately getting the value stream to the market quicker than before. However, we need to remember that whilst agile may be driven by one team (in most cases dev) you need to ensure that the process is absorbed by all the other stakeholders in both the SDLC and further on down the line the wider organization. A good analogy someone once told me was to consider dropping a low performance engine / tires / etc. into a “high performance” car. For example, put a Honda Civic engine into a Ferrari or you $50 tires on a Lamborghini. The car wont perform and it won’t handle the corners. It will look great, but it won’t win any races or even outperform your average car on the road. If you want the car to be better, you need to make sure you upgrade all the parts – and the same applies to Agile.

In order to truly realize the ROI of agile, you need to make it a team effort – that’s dev, the business and QA. In order to do this – and again if the hope is to scale agile in an enterprise organization – I recommend implementing a “management of change” program to go alongside the shift in process. This means educating all teams involved in the SDLC what Agile is and also educating people on the outside the SDLC (e.g. legal, finance etc). The reason we want to educate those outside the SDLC is that even though the application development team is working on Agile, the corporate policy for a product lifecycle may still be waterfall and corporate will still be expecting waterfall deliverables such as full requirements specs, etc even though the agile team may not have these. So to stop the extra pressure on agile teams – enterprise education is a necessity. Look out for Part IV in the coming weeks – this will highlight the importance of Control and Visibility.

So i am back on the blogging trail and here is part 2 of my 4 part series on Agile challenges in requirements. You can read Part I (Dynamic Requirements and Tests) in my blog posted on February 2^nd. Again, Part II discusses Prioritization, Part III will focus on Lack of Communality and Part IV will highlight Control and Visibility.

Challenge: Prioritization

Part of the planning of Agile is knowing which user stories are going to be implemented when and subsequently what will be tested in which iteration. Often because of the flexibility and fast pace of agile – QA do not have all the info up front that they need to do objective prioritization (such as dependencies, technological limitations). This makes prioritization and test planning even harder. Furthermore, from a QA perspective prioritization can manifest itself in not only what to test and when but also if using automation when and what to use this for. Traditionally automation in agile is used for regression suites, but the question arises – if we want to do things more quickly, should we automate sooner and if so, which parts of the application under test can we automate?

Solution:

Using test automation tools such as HP Unified Functional Testing (a combination of HP QuickTestProfessional and HP Service Test) allows you to start to implement automation as soon as an element of the application becomes stable enough. Regardless of the application being complete. i.e. In iteration 6 SOA elements or components such as dll may be stable but there is no GUI to test with. Having a tool which can “headless test” will allow agile teams to test more, test earlier, enhance coverage and find bugs easily that were very hard to find before.

Part I: Requirements Challenges Agile Teams Face and How to Overcome Them

I will be posting a 4 part series on challenges (and solutions) Agile teams come up against regarding requirements over the next month. Part I covers Dynamic Requirements and Tests, Part II will discuss Prioritization, Part III will focus on Lack of Communality and Part IV will highlight Control and Visibility. When we look at the challenges of agile in most cases we have to remember that a lot of the challenges we see agile teams facing today are not unique to agile, it is just that due to the nature of agile a lot of these challenges have been accelerated and/or magnified. Let’s look at the first challenge.

Challenge: Dynamic Requirements and Tests There are 2 challenges with requirements: Not only do the BA and QA have to get used to a new way of writing requirements (moving from detailed functional requirements to user stories) where there has to be a balance between the level of detail in the user story (enough to start developing and testing) and defining them in a timely manner and teams have to accept that requirements can change after each iteration depending on the feedback from the customer – all this change in requirements is consequently reflected in the code and the tests that QA have to develop – which if not handled correctly can lead to a large amount of re-work

Solution: In my opinion wikis are a great way to do the initial phase of your user story definition as they provide a means by which multiple stakeholders can work together to define requirements in an easy to access and easy to document manner where collaboration is not only supported but encouraged by the nature of the technology itself. Using wikis in the planning phase of user stories will support the dynamic nature of the agile requirement. However, I believe that once as a team a consensus has been reached on what each requirement means we should move to more traditional tools to manage those user stories and move them through the development lifecycle. My reasoning for this is because whilst wikis can be great for scoping of requirements / user stories, as long as user stories remain in a form which is not easy to integrate with other phases of the lifecycle (such as test and development) the benefits of creating "solid and sound" user stories is lost. i.e. if we can't easily link user stories to other assets in the development lifecycle (which would not be that easy to do from a wiki and maintain full downstream traceability) then we are no further along in advancing our requirements processes than we were when we still used Microsoft Word or Microsoft Excel – and if we want agile to work on a large scale using post its, Word and Excel is not realistic. 

Requirements Definition (RD), Requirement Management (RM), Requirements Visualization, Requirements Elicitation, Requirements Engineering, Requirements Analysis........the list is endless and there many ways by which we can define the process of defining and managing requirements throughout a product or applications lifecycle.

One of the terms gaining greater popularity in today's marketplace is Requirements Definition Management (RDM). Essentially RDM encapsulates all of the approaches outlined above and is a streamlined way of defining the process associated with requirements capture and management (see I can't even redefine RDM without repeating my words).  The foundations of RDM are based on 3 principles:

• - Collaborative Definition: multiple stakeholders working together to define requirements using a variety of different techniques from text to visualizations.


• - Continuous Management: tracking changes to requirements as they move throughout the SDLC


• - High Level Specifications: project managers should try and understand at least 70% of the requirements at a high level in order to be able to assess how the requirements will impact budget and time estimates.

Essentially, RDM like RD and RM as standalone disciplines before it is something we must be aware of, because the costs of not weaving effective RDM into our SDLC can be detrimental to our overall project and organizations finances. In some cases costs can double and delivery rate can overrun by 40%.

RDM like many other of the development trends currently driving our initiatives means that we are moving from a siloed model to a collaborative model - and this in itself provides many new challenges as we all well know.

To find out more about how to make RDM effective for you - HP has produced a Whitepaper called "Requirements Definition Management - How to make it work". If you are looking to meet business demands, reduce time, cost and frustration and build effective RDM processes into your next project take a look and let me know how it goes.

You can find the WhitePaper attached here...

I would like to say hot on the heels of my last blog - but I know it has been a while!!!

In this blog I want to invite you to listen to a recent webinar and discussion panel I hosted with one of our requirements definition partners Blueprint and two of our joint customers JPMC and Paetec.

The webinar follows quite nicely from my last blog entry around requirements visualization as it part talks to the benefits and savings that these two companies had as a result of implementing Blueprints Requirements Definition solution to enable visualization of requirements. For example, as you will hear JPMC saved an estimated $1.2M in work effort as a result of using enhanced requirements definition techniques such as visualizations and simulations.

In addition to talking about the benefits of requirements visualization, I also introduce the concept of the Requirements Lifecycle and discuss what role this plays in the wider Application Lifecycle - touching on how HP's ALM POV is concerned with managing a series of strategic control points which help the business to gain visibility into what is taking place throughout an applications lifespan.

So enough talk from me....here is the link, let me know what you think??!!!!

Genefa

How many times have you been in a meeting discussing a set of requirements, a methodology, or a project plan etc and someone has gotten up from their chair and said "where's the whiteboard let me draw what I mean"?

 I can tell you for me it has been plenty!!!!

Whilst requirements specifications are a great way to document the detailed information related to a new or existing product's functionality we all live in a time poor society and few of us have the time to trawl through large documents and extract the information we need and then start the seemingly endless e-mail threads to discuss the individual use cases associated with each requirement consisting of many messages that start and end with "what did you mean by X?", " I meant X and Y but I think you thought I meant Z!" Instead why don't we adhere to the adage of a picture tells a thousand words and instead of page after page of documents create a visual representation of those requirements - hopefully communicating a thousand words in a single picture.

However, what we must remember is that visualization of requirements can vary in its meaning. For example, some people may view requirements visualization in the same context as simulation diagrams, whilst others interpret visualization to mean simple use case diagrams or business process flows typically created in a MS Visio type tool. For me, all of these usage contexts can represent visualization, so instead of trying to classify visualization into one genre I thinking it is best to view it on a scale with simple flows at one end and high end simulations at the other - and the user selects which method is most appropriate for them at any given time. For example, if you are trying to show how a user will move through an application to make a purchase then using MS Visio to define process flows may be enough. However, if you are trying to envisage how a new UI (User Interface) may look then mockups and more rich content visualizations would serve you better. Whichever method is selected there are a number of benefits that come from visualization these include:

• Flexibility and Usability - flow diagrams can be easier to navigate helping to find content


• Mistakes can be easier to identify in a visualization


• Easier to identify potential parallelisms between requirements and business processes


• Easier to spot missing Use Cases in business process


• Increase understanding of the requirements themselves


• Increase understanding of the dependencies between requirements


• Visualization of business flows can provide a first bridge to Business Process Models or SOA repositories

Now that we have explored some of the benefits of visualization the question now becomes when should it be used? Should we visualize every requirements we write or just some and if we are going to be selective which requirements should we chose?

In my opinion there are a number of questions we can ask ourselves which can help to determine when to and when not to visualize. These include (and there are many more):

• Type of development method - we need to ask ourselves the question do requirements visualizations fit in with the need for more agile and rapid requirements definition or will they add more time to the development process?


• Complexity of the requirement - if a requirement has too many sub requirements will this create a "spiders web" diagram which may overcomplicate the definition of the requirement?


• Type of requirement - should we visualize the user story only and define the functional requirements associated with this user story as text or do we want to visualize all requirements?


• Risk level of the requirements - should only high priority or high risk requirements be candidates for visualization?

It is important to note that I am not saying that requirements visualization is a "panacea" for enabling effective business and IT communication but what it will do is act as a good facilitator to help initiate a better degree of communication and understanding between the two parties.

So now the decision is yours - why not try visualizing requirements and feedback to the group how things go.....

Until next time.....

Genefa

In this week's blog I would like to invite you to listen to a recent podcast I conducted in conjunction with one of our key partners Blueprint. The podcast covers some great topics focused around the theme of "Maximizing IT Value". Subjects we discuss include: The value of effective Requirements Definition (RD) and Requirements Management, What are requirements? How RM links to other phases of the Application Lifecycle and my thoughts around the future of the RD / RM market.

For me RD is a multifaceted discipline which covers anything from the capture of textual requirements through to Business Process Simulations and application mock-ups - and the extent to which a customer adopts these different methods is dependent upon the application that they are developing and the level of communication they want to instigate between the business and IT. Some customers chose to elicit requirements in purely textual form and this is perfectly acceptable whilst others chose to add an additional level of detail and add visual elements such as pictures, business process flows, Visio docs etc - they don't say "a picture tells a thousand words" for nothing.

In fact in 2006 IDC produced a report arguing the benefits of visualization for Information Management - stating that success will be achieved in IM for content providers who make information easier to navigate and understand. I believe this same principal can apply to the requirements domain as essentially requirements are just pieces of interconnected data and the more we do to make them easier to understand the greater the chances that the IT will deliver what the business demands. 

In fact later in the same year IDC produced another report stating that requirements simulation is going to be one of the emerging trends in the market to help business and IT alignment - a trend that now in 2008 /2009 we are now seeing coming to the forefront (shown via the increasing market presence of RD vedors such as:  iRise, Blueprint, RavenFlow amongst others).

As I said before the level of visualization that customers do is directly correlated to need. However, what I think is essential is that once we have captured these requirements we make sure that they are managed in the right way. So that we:

• - Baseline requirements - achieve a sign off agreement on the content of the requirements both between business analysts and between the business and IT


• - Prioritize requirements - once requirements are locked down the business should clearly define which the highest priority requirements are. This helps to ensure that critical functional is completed in adequate time - a factor especially important in agile development when requirements need to be assigned to sprints.


• - Track changes to baselined requirements against a pre-defined threshold i.e. if the number of changes exceeds a certain amount we mark this requirement and send it back to the Business Analyst for review. If that many changes are being made - the requirements may have been poorly defined.

Hopefully this brief discussion in RD and the podcast will spark some thoughts in your mind and help you to understand how effective RD and RM can help your organization maximize its IT value.  

Wikis and other Web 2.0 technologies are fast becoming commonplace in the workplace - but can they be leveraged for fast and effective requirements definition and management?

Forrester Research found that in 2008 nearly 50% of enterprise organisations were planning to invest in some form of collaboration technology or best practice associated with this genre. Indeed within HP itself the use of Web 2.0 technologies such as wikis, blogging, bookmarking and other social sharing initiatives is becoming more commonplace - hey this blog itself is part of that trend. However, the question becomes whilst wikis and other collaboration technologies provide obvious benefits can they really be leveraged by more traditional disciplines such as requirements definition where the focus is less on open commentary and more on rigour. After all, we all know that poorly defined requirements lead to poorly developed products so can we really use these flexible technologies to define robust requirements specifications.

In order to answer this lets look at some of the common advantages and disadvantages of wikis for requirements:

Advantages

• They are simple and it is very easy to learn how to use and create content


• There is nothing to install on a client machine


• They are platform independent


• They help to keep conversations in sync - no fear of dropping a participant of an e-mail thread


• Users can easily create links to other pages, attachments etc to identify source requirements or supporting data


• Open access to wikis means participants beyond the initial project group can get access to information meaning more rounded requirements are created


• Wiki content is often searchable in internal and external search engines


• Built-in version control system so you can see complete requirement history (not just the last set of changes)


• As they are often hosted on a centralized server, the information is always avaliable and is less likely to get lost or accidentally deleted (if it does it can be easily restored)

Disadvantages

• Because of their simplicity users might not be able to create content in the manner and format they might like. So for those of you wanting to develop rich requirements (with images, pictures, use case diagrams etc) this might not be that easy


• It can be difficult to capture content in a medium outside of the wiki for distribution


• Wikis are a new technology which may encounter resistance from stakeholders


• Can't always create traditional requirements views such as traceability matrix etc


• If the server is unavailable, no one can access any information


• Security can be an issue depending on where the wiki is hosted or if an external wiki resource is used

What's the ideal?

In my opinion wikis are a great way to do the initial phase of your requirements specification process as they provide a means by which multiple stakeholders can work together to define requirements in a easy to access and easy to document manner where collaboration is not only supported but encouraged by the nature of the technology itself.

However, I believe that once as a team a consensus has been reached on what each requirement means we should move to more traditional tools to manage those requirements and move them through the development lifecycle. My reasoning for this is because whilst wikis can be great for scoping of requirements as long as requirements remain in a form which is not easy to integrate with other phases of the lifecycle such as test and development the benefits of creating "solid and sound" requirements is lost. I.e. if we can't easily link requirements to other assets in the development lifecycle (which would not be that easy to do from a wiki and maintain full downstream traceability) then we are no further along in advancing our requirements processes than we were when we still used MS Word or MS Excel.

Hints and Tips to wiki Acceptance

If you do decide to go ahead and adopt wikis as your primary means of requirements elicitation it is important to remember that wikis are just a tool and just because you use a wiki it doesn't guarantee a project's success or that collaboration will occur (although it will probably be much more likely). In light of this if you do decide to go ahead and adopt wikis as your primary means of requirements elicitation what should you look out for in terms of gaining the acceptance of your Business Analysts (BA) to use this medium???

According to both academic researchers and practitioners in the field there are 4 key factors which will affect how a new technology (such as wikis) gets accepted by end users - and if we as an organisation can influence these factors we can make the first step in leveraging the power of the wiki within our requirements processes:

Effort

Highlight the ease of use of the wiki to the BA - use the advantages listed above

Performance

Make sure the BA understands that they can access their wiki anywhere and as long as the web works they work

Social

Emphasize the "coolness" of wikis - let the BA know they are just as dynamic as the rest of the stakeholders in the development lifecycle, they are using the latest technology, and they are on trend. See Gartner's hype cycles which promote wikis and Web 2.0

Resources

Leverage existing RM wiki tools to kick-start your wiki process, thereby taking the effort out of adoption, examples include: WikiSolutions, TWiki, OpenCollective

For me the key to successful requirements definition and management is remembering that it's not just about leveraging the latest and greatest technologies but more about ensuring that as an organisation you develop the right methodologies and practices to support successful requirements specifications - and once you have this you can leverage the latest and greatest technologies and tools in the safe knowledge you will be capturing the right information and using it in the right way.

That's all from me for now - tune in another time for more RM blogging!!!!

Thanks

Genefa

Why do we do Requirements Management (RM)? If we look at what the analysts say it is because effective RM helps to maximize the likelihood that an application delivers the functionality that is desired.Whilst this is true and we are all aware that poor requirements lead to wrongly or mis-developed functionality - in today's current economic climate it is vital that not only do we look at the impact of poor RM on the end-user but also that we look at the financial impact this has on our operations.

According to Voke's recent BA Survey a software development project can cost anything between $1million and $20 million - and an average project will typically have the following profile:

• 
  
  People per project - 75


• Project duration - 17.2 months


• Cost per project - $3.2 million

According to IAG Consulting, a leading Business Requirements Analysis Company this is fine if RM is properly implemented but if it is not then the likelihood is that a project will:

• 
  
  Be more likely to deliver a marginal project or outright failure than a success


• Have 50% chance of being a run-away i.e. deliver <70% of the required functionality


• Take an extra 39% of the time to deliver


• Overspend by 49%

So based on an average project spend of $3 million and factoring in the estimated affect of poor RM an average project could end up costing as much as $5.87 million. Furthermore - if we estimate that this happens in 5 out of 10 major projects per year - that's an estimated cost of nearly $30 million - now who can afford to lose that???

In fact in an economy where every dollar counts it is vital that we do everything to make sure we maximise how we do business and whilst investment in downstream activities such as test and development is reasonably significant (whether this be tooling or purely level of man effort) - acting and investing in the test and development phases is to too late - if we want to make sure we produce the right applications without sacrificing our budgets the time has come to invest in effective Requirements Management!!

If we trawl the web we will see many articles on RM, dedicated organisations such as the International Institute for Business Analysts (IIBA), RM consultancies such as the Atlantic Systems Guild and many other sources of RM information. However, in reality few companies rarely invest the time and effort in the discipline. In fact a report by IAG Consulting found that whilst organizations recognize that requirements are important to project success, 68% did not take effective action on strategic projects to ensure the RM process was governed and ultimately successful.

So let's get this party started and let's invest in RM - let's not focus on what it costs us but what it can save us!!! Lets remember that it's not just about tools, but investing in best practices, its not just about innovative capturing of requirements - but back to basics - what do we need to do to make sure we have the right requirements both when they are under development and review by the BA and when they are picked up by other stakeholders in the SDLC. In my opinion the route to savings can be found by investing in the following key RM areas:

• Capturing requirements in one place and having a "single version of the truth"


• Collaborating on requirements to make sure the right thing is being captured


• Linking requirements to other development assets - tests, defects, code....


• Standardising requirements so that everyone works in a common way

Effective RM is a key way to help ensure that not only is the money we are investing in projects well spent but it is spent at the right point in the project lifecycle so that the end goal is not only achieved but is achieved without sacrificing our IT budgets!!

Thanks

Genefa

Upcoming blog topics:

• Requirements Definition and RM are the genres merging?


• Wikis for RM - can we have flexibility and structure?

Hello and welcome!!!!

This is my introductory entry to the new Requirements Management Blog written by me - Genefa Murphy, Product Manager for Requirements Management (part of HP Quality Center)!!!!

I am going to keep it short and sweet so I will let you know that the purpose of this blog is for me to share my thoughts and views with you and you to share your thoughts and views back – all on the wonderful topic of RM!!!

HP’s move into the RM space has been gradual over the past 7 or 8 years and now we are at a point where in my opinion we have a comprehensive and compelling RM solution. In fact with our upcoming release at the end of the month QC 10.00 – we have some really exciting new features and functionality that will help you our customers to achieve greater success through RM!!!

However, it’s not all about product (really) and one of the main aims of this blog is for me and the wider QC team to put some ideas out there about the current trends we see in the Requirements Marketplace. For example:

- Are the requirements definition and requirements management markets merging?

- What role do requirements play in agile development?

- How can RM help you to deal with the current economic crisis?

- What new ways are there to elicit and manage requirements?

These are just some of the topics I will be looking to cover in this new blog and it would be great to get your feedback and comments – and lets face it I am sure you will have thoughts of how we can improve our current RM offering so please send them my way as they will all help in making our future RM solutions as compelling and useful as possible!!!

This blog and other RM initiatives we are planning in ’09 are really important to the future of QC4RM – so your participation is encouraged and greatly appreciated!