Software Projects: The Issue Of Changing Requirements
Constant changes in the business world and mobile market dictate not only trends but also rules of software development.
One of these rules says that stable requirements for a software product is something like perfection in general - we always try to aspire towards it, but there's always a ways to go.
And it would be really perfect for everyone if software project requirements were stable and resolute.
This would prevent many problems and misunderstandings.
But that's not the experience that can take place nowadays.
Why can't we have firm requirements to start with? It's naive to think that everything valuable is captured at the very beginning.
The detailed understanding of software and how it works, the conditions of the client's business - all this brings new requirements and new value to the software.
Any document concerning requirements reflects the moment when it's written.
But larger projects aren't finished in a day or in a week, while things change both in technology and on the market.
That's especially difficult due to constant software and technology updates - any external change, which is hardly foreseen, can cause a problem.
On one hand, every little change can hardly be accepted; on the other hand, requirements cannot remain stagnant.
It isn't good to overfeature and overenhance the application either.
To look and think forward is a good advice, yet it's not that easy in the technical side of the mobile world.
As a result, now one of the most frequent lines on the list of merits of any software company is 'quick response to changes'.
What do these changes concern? A requirement can be missed.
There can be understanding that something that was planned, actually is not needed anymore.
A competitor may suddenly launch a product that has superior features - there might be an urgent need for fresh ideas.
These can be technical changes, applied due to new hardware/software/platform updates.
These can be changes required by the client's business - for example, adding new products, services, and offers to branded software.
Changes in requirements may vary from those that can be completed in less than a day to much more complex ones, which can happen after the development starts.
All the maintenance works, such as various fixes, don't occupy a large share of changes, if compared with functional ones.
What's the solution? For developers (a development company) it's better to treat these changes as challenges.
Thus they are able to make the software better and competitive within the dynamic environment of mobile market.
Developers must be flexible and ready for these changes in order to succeed with the project.
For the software owner, it's necessary to understand and foresee that possible changes of approved requirements may cause delays and extra budget expenses.
But that's the way to make a great software product that no competitor will be able to copy.
There are several challenges that walk side by side with advantages - uncertainty in final costs, for example.
However, the software owner anyway has control over the budget, scope and schedule, it's the software owner who makes decisions on funding the project and sets priorities.
Iterative development is one of the solutions for the issue.
If the client is ready to face these changes in terms of budget, deadlines, and time for communication with the contractor, the end result is more likely to be truly useful, in every sense of the word.
It's not that the client must simply waste more money on new useless features - that's not a recipe for a successful product.
Each iteration is the stage where requirements are generally stable.
That's why the title of this article says about 'the issue', not 'the problem' of changing requirements.
They must be managed properly in order not to make development one big problem.
The opinion that changes are bad, that they must be prevented, isn't also that much correct.
Relevant changes aren't all about adding expenses and delaying the release - there is certain value that the software product acquires, and the competitive advantage for the software owner.
The product's relevance outweighs these drawbacks, and it's one of the keys to the product's success.
One of these rules says that stable requirements for a software product is something like perfection in general - we always try to aspire towards it, but there's always a ways to go.
And it would be really perfect for everyone if software project requirements were stable and resolute.
This would prevent many problems and misunderstandings.
But that's not the experience that can take place nowadays.
Why can't we have firm requirements to start with? It's naive to think that everything valuable is captured at the very beginning.
The detailed understanding of software and how it works, the conditions of the client's business - all this brings new requirements and new value to the software.
Any document concerning requirements reflects the moment when it's written.
But larger projects aren't finished in a day or in a week, while things change both in technology and on the market.
That's especially difficult due to constant software and technology updates - any external change, which is hardly foreseen, can cause a problem.
On one hand, every little change can hardly be accepted; on the other hand, requirements cannot remain stagnant.
It isn't good to overfeature and overenhance the application either.
To look and think forward is a good advice, yet it's not that easy in the technical side of the mobile world.
As a result, now one of the most frequent lines on the list of merits of any software company is 'quick response to changes'.
What do these changes concern? A requirement can be missed.
There can be understanding that something that was planned, actually is not needed anymore.
A competitor may suddenly launch a product that has superior features - there might be an urgent need for fresh ideas.
These can be technical changes, applied due to new hardware/software/platform updates.
These can be changes required by the client's business - for example, adding new products, services, and offers to branded software.
Changes in requirements may vary from those that can be completed in less than a day to much more complex ones, which can happen after the development starts.
All the maintenance works, such as various fixes, don't occupy a large share of changes, if compared with functional ones.
What's the solution? For developers (a development company) it's better to treat these changes as challenges.
Thus they are able to make the software better and competitive within the dynamic environment of mobile market.
Developers must be flexible and ready for these changes in order to succeed with the project.
For the software owner, it's necessary to understand and foresee that possible changes of approved requirements may cause delays and extra budget expenses.
But that's the way to make a great software product that no competitor will be able to copy.
There are several challenges that walk side by side with advantages - uncertainty in final costs, for example.
However, the software owner anyway has control over the budget, scope and schedule, it's the software owner who makes decisions on funding the project and sets priorities.
Iterative development is one of the solutions for the issue.
If the client is ready to face these changes in terms of budget, deadlines, and time for communication with the contractor, the end result is more likely to be truly useful, in every sense of the word.
It's not that the client must simply waste more money on new useless features - that's not a recipe for a successful product.
Each iteration is the stage where requirements are generally stable.
That's why the title of this article says about 'the issue', not 'the problem' of changing requirements.
They must be managed properly in order not to make development one big problem.
The opinion that changes are bad, that they must be prevented, isn't also that much correct.
Relevant changes aren't all about adding expenses and delaying the release - there is certain value that the software product acquires, and the competitive advantage for the software owner.
The product's relevance outweighs these drawbacks, and it's one of the keys to the product's success.
