Why do organisations struggle to improve their approach to managing requirements.
Essentially because the industry doesn't present a common view of best practice - and frequently doesn't distinguish between different approach to requirements management i.e. high level vs low level, and approaches for low level requirements management.
Ideally at a high level enterprises should have a common way of defining requirements (and assessing that they are met). At lower levels the methods should diverge depending on how the requirements are to be met - and the role enterprise needs to be play.
We could think the ways that requirements might be met under four broad headings: development (where major components of software are developed), integration (where a number of essentially existing components are integrated), package customisation (where essentially an existing solution is customised, configured or extended) and package off-the-shelf (OTS)
Development may be when enterprise builds a solution inhouse e.g. developing in Java, C# etc. (the solution will fit like a glove i.e. and is bespoke). This is usually done when no OTS packages meets the requirements and/or the business seeks to achieve unique market differentiation based on the solution (software). This may or may not involve an adjustment to how the business operates.
Package customisation is where a package or service (such as SAP) is purchased and it is customised, configured or extended (as little as necessary). In this case there is also usually some recognition that some adjustment to how the business operates may be entailed (as presumably the package reflects industry best practice).
Package OTS is where a product or service is used as purchased (no changes a made) for example MS Word. This is usually done where an enterprise does not seek to achieve competitive advantage through the use of the tool e.g. few business seek to differentiate themselves based on how well they use a word processor.
Integration may involve all of the above and how different components (including external services) from each area work in concert.
It should be clear that the ideal approach to requirements in each of these fours area differs. The failure in most requirements management approaches is that the lower level methods pollute the higher level approach to requirements management (by way of analogy - the way the plumber or electrician, or block layers needs to define what they doe, and how they notate their detailed designs, is foisted upon people who wants to describe that they want a new garage).
The approach to requirements management also needs to align with the approach to project management. This introduces another issue i.e. project management in IT.
This failure is matched with failures to recognise the difference between project management in IT vs project management for buildings. The reality is that in IT the requirments and specifications often evolve right to the end. This because what people want to do with the technology elements is partially determined by what the technologies can do i.e the technologies change behaviour. To pick to generic consumer oriented examples: a GPS navigation phone changes how one navigates, a video conferencing phone changes how one communciations (as does a texting/SMS phone, instant messaging etc.), Google et al changed how one finds things. If we constrast this with buildings this is far less the case i.e. we pretty well know exactly how we want to use say: a toilet, a door, a bed, a bed room and lift.
In IT delivery a great deal of the time is focused on understanding precisely the requirements are, and therefore what the design is (including engineering calculations), and what construction is required, and how things should be tested. In buildings the requirements are far more precisely understood at the start, the design is well articulated and precise before construction starts, the testing is usually more obvious (or it is covered fairly well defined industry conventions), etc. In buildings the scope very well defined and the focus on project in buildings is far more on costs, time and variance - whereas in IT the scope is seldom well defined at the start, and the focus in project management is on management the refinement of scope (and cost, time).
Asking most organisations for whom this not their main focus how the they want to manage requirements is probably unrealistic i.e. it is a bit like a building architect asking a home owner how the plans should be drawn up, or an electrician asking the home owner how the electrical diagrams should be drawn.
So what is needed is to show some leadership with clients in explaining how requirements can be managed - and how this related to detailed SDLCs, approaches to project managment, and approaches to aspects of enterprise architecture (e.g. standards compliances, skills management etc.).
A starting point for requirements must be how the business operates or seeks to operate. This in turn needs to be ground in the business drivers and constraints (which include technological, organisational and environmental considerations).
