Copyright Beaver 2000/2003
A solution? - To learn about the requirements management process, download a free requirements engineering primer, and find out about our DOORS and DXL addins and our on and off site requirements services see here, or here for our ready made DOORS information models.
|Requirements management is at the core Beavers service offerings. Requirements management centers round the agreement and communication of what is to be delivered between the client and supplier. This covers all layers in the chain chain, for example, between the business and the product or system supplier, the supplier and its software and hardware teams, and between the supplier and its sub-contracts.
Good requirements management is central to each project, to ensure that requirements documents and specifications deliver the business case or vision, that the suppliers know what is needed, that the supplier is delivering just that, and the organisation is making other related preparations ready to introduce the changes and realise the business benefit. Early iterations of the requirements process may produce the ITT, and support pre-qualification activities of potential suppliers, and completing product inquiries so as to evolve the user requirement document or system specification. Requirements management links to other activities - analysis, development, testing, configuration management, and project management to name a few. These activities either gather and discover requirements, test them, design against them, or co-ordinated them. Requirements do not appear out of thin air. In fact the process has already started from the business analysis work flow.
The Standish Groups Chaos
report emphasised that inadequate requirements management is the main
reason for failure but if done properly is one of the key success factors.
Yet few recognise this and provide a formal requirements management
function, regardless of it being a small or large project.
The requirements process starts with stakeholder and user needs - which outline the goals of the project and the services that need to be delivered. Next is a period of refining and developing requirements which deliver the stakeholder requirements and often involves trawling for baseline and derived requirements though various related analysis, prototyping, and testing activities which may include scenario analysis and use case work shops, existing systems studies, review of SLA's, and performance base lining and and analysis of future market demands. Requirements analysis also may look at the customer base to establish what they like, dislike, want, and how importantly each of these factors is to them, accurately and unambiguously recording these details and building up the bigger picture. This helps clarify the future vision. When this complete picture is established stakeholder and user needs are then traded and negotiated as for example some will conflict or are not be realisable in the times scales and need rescheduling for a latter project, this continues until a set of "requirements" are agreed, as until that point what's being dealt with are requests or wishes. The focus is on what is needed, how well it must be delivered, and details of any constraints. This defines the context or solution space
Once agreed these requirements form the basis of the ITT or user specification which is flowed down to the in-house or external designer and supplier, and are again negotiated and agreed, perhaps raising changes which impact on the business case and model and the systems model and design. Through the use of systems analysis methods, including methods such as prototyping, system requirements are established and the design progressed, leading to built products. This activity is reviewed further on our systems analysis and build page.
A feature of this process is that it is repeated though a number of iterations, and the end of each iteration the risks and uncertainty in requirements and the solution are reviewed, and the next iteration planned in detail taking account of changes, and additional features to be developed to fulfil the migration strategy. User and system specifications can be paralleled. As requirements are flowed down though each level of specification the integrity of the business solution can be assured it the analysis, simulation or prototype satisfies the higher level requirements, and the components of the analysis, simulation or prototype for example, become the derived requirements to be flowed down to the next level. The requirements are traced between stakeholder, user, and system specifications, the business benefits, the design solution, and to the test specifications and results, so building a barometer of health for the project, and implementing validation and verification best practice. Any non-agreed or unstable requirement at the higher level can be traced to the next level and a decision made whether to proceed at risk or not. Requirements reporting such as this can confirm the breadth and depth of coverage that is achieved and link into an issues raised and traced to a project risk log.
One thing is certain though, changes will occur for all manor of good reasons, perhaps the market or technology changes meaning the actual business benefits are jeopardised, or technical or process innovations can be used to provide advantage over your competitors, or due to external regulatory requirements. Freezing requirements is a classic response, particularly where a waterfall rather than iterative development model is used, but often this causes more problems and merely acts as a cosmetic decoration.
Managing changes and establishing if these changes are appropriate is critical, ensuring changes are fully considered, and if agreed the change is rippled through the design, training, and other preparatory measures via the configuration management activity which ensures each version, release, and location is known and that they are consistent with each other. This approach controls changes to an advantage : features do not creep in or get left in when changes are made and features are not lost and so fail to be developed. All the time the focus is on the business need and realisation of the business benefit. Requirements are an integral part of the configuration set allowing impacts and traces to be performed.
At the supplier level we may act for you in analysing a clients requirements, the context of them, identifying those that are ambiguous, unrealistic, non-testable, overlapping or conflicting. Often ITT's benefit from a restructuring. Then from the early days of the proposed solution, we map and track to show how the solution meets the requirements, and the issues surrounding them. Visually we can show how the proposal is compliant, how it traces to the products, and the cost build up.
Good requirements management, commercial and technical between the client and suppliers, smoothing the way for a good partnership. Verifying and validating and building confidence for both parties. Longer term the requirements and configuration act as the basis for life cycle management of the service or product - fault management, service level agreement management through to whole life management. To see an overview of our requirements capability see here and for information on our requirements process model and free requirements primer download see here. For our configuration and change control capability see here. To read about systems analysis, design and solution construction click here or to return to our solutions development page click here.