Throughout the 1990’s and 2000’s enterprises undertook many large and complex projects that often spanned multiple years before reaching end users. The time it took to define the requirements was measured in months and sometimes years. Today’s business environment is fast paced, highly competitive, web-enabled, mobile, and increasingly social. Add to this the extreme pressures of competition, cost reduction, and regulatory compliance, and the long delivery cycles of the last two decades have become unacceptable to business stakeholders.
With 34% of approved projects now sitting in backlog and IT unable to respond quickly enough, demand for cycle time reduction has reached record levels. Immediate business impacts include lost opportunity to drive top-line revenue and reduce expense, and ultimately lost competitive advantage and long-term business viability.
Download Blueprint's new paper, define better, together, that shows how business and IT collaboratively define applications, improve requirements and unblock the backlog.
Posted by Tony Higgins on 05/08 at 09:23 AM in
(0)
Comments
Requirements Toolkit has ranked Blueprint number one among requirements tools against an exhaustive set of criteria reflecting features that are important to business analysts.
From the report: "The Blueprint requirements management tool is a dynamic tool suite that includes the full spectrum of requirements development and management deliverables from elicitation of detailed requirements to UI mock-ups and test generation. The advantage is user-defined traceability across the board from every business input through every deliverable on the project."
Download your own free copy of the report here.
Tags:
Posted by Tony Higgins on 03/28 at 08:37 AM in
(0)
Comments
Forrester released a tremendous report recently entitled “High-Value Requirements Are Changing App Dev and Delivery”, by Tom Grant. In this report Tom discusses the recent ‘quiet revolution’ that’s been happening with requirements definition and management, and the ripple effects this is having in the rest of the software development lifecycle.
The report makes the point that we’re living through a requirements revolution where inputs are more broad (now encompassing social media), and we’re more deeply delving into the underlying business problem more deeply and how users will leverage the application. Requirements are being expressed in new, rich, innovative ways, and that all this is having ripple effects in the rest of the lifecycle.
“Great requirements are force multipliers, not unpleasant necessities”
Some net effects of this revolution is that new, innovative tools have emerged in response to this shift, the bar is raising for business analysts and product managers skill sets and experience in this era of increased emphasis on demand and value, and the once separate disciplines of requirements definition and requirements management have essentially melded into one.
“Teams that want to take advantage of these changes must go beyond the sincere desire to understand the customer more deeply to an understanding of how fundamentally requirements writing has changed and appreciate the resulting changes in related software development processes.”
Copies are available from Forrester.
Tags:
Posted by Tony Higgins on 12/14 at 02:04 PM in
(0)
Comments
On typical software projects there are many changes that occur to requirements. These changes are not all equal and knowing how to deal with the different kinds of changes is a key requirements management practice, and can make a huge difference in the overall performance of the project. But what are the different kinds of changes? How should requirements changes be categorized?
Some categorize based on the nature of the change – whether it is a new requirement, a requirement modification, or a requirement removal. Some categorize according to the impact and effort it would take to implement the change. Others categorize based on the reason for the change such as due to market pressures, product strategy or vision, hardware/software environment, , or testability. Some categorize based on domain of the change such as ‘Screen change’, ‘Report change’, or ‘Data Change’ for example. Others categorize based on degrees of volatility, or how often the requirement changes. There are many more categorization schemes and of course combinations of these too.
In a recent paper researchers studied how requirements changes are categorized by software practitioners and found that most change requests had little information about the reason for the change, and not enough information to effectively analyze its importance. These researchers then proceeded to use the Card Sorting Method to study how different practitioners categorized their requirements on a globally distributed software project. Perhaps not surprisingly the team members had different categorization schemes, each biased by their own concerns (e.g. the architect categorized according to effort required, the project manager by schedule impact, and so on). Overall the study the participants found that focusing on a requirements categorization approach helped:
-
Control and manage the requirements changes
-
Assess the impact of requirements changes in a reliable way
-
Promote a common understanding of what the change actually meant
-
Identify risks associated with the individual change, and with the group of changes
You can read about there study here in along with several references to more on categorizing requirements changes.
Posted by Tony Higgins on 12/05 at 09:20 AM in
(0)
Comments
