Why do I need requirements again?
Requirements
Perhaps not the most eye catching of blog titles, however this is an area I see problems with time and time again. Perhaps it is human nature to get excited and eager, in wanting to skip the requirements phase of any project and jump straight to the solution. It’s something that I’ve been guilty of in the past. Certainly, it is something I’ve anecdotally observed across sectors, industries and technologies.
So, what is the problem? To skip the requirements phase is to run the risk of missing the goals of the project. To skip to the solution, to not capture the Business, Data, Application, and Technology (BDAT) requirements, risks not fulfilling some or all the stated goals of the project.
Great news if you want to have another go later, perhaps not such good news if you are signing the cheques.
Within the TOGAF Architectural Development Method (ADM) requirements are kept central throughout the ADM cycle.
Requirements from one phase of the ADM cycle feed into the architectural work of the next, where yet again requirements are captured and feed into the next, and so on.
Requirements are central to the TOGAF ADM and these are first captured during the Vision phase.
Whilst the Vision phase is part of the ADM cycle, it is in effect running a high-level iteration through the ADM cycle to capture requirements from different views and viewpoints (BDAT).
The Vision phase is described as having the following objective.
To develop an aspirational Vision of the capabilities and business value to be delivered.
That’s a bold objective to start with. It could be framed slightly differently to, what at a conceptual or high-level needs to be delivered and why. It sounds a lot like a high level or conceptual design. It avoids making technology decisions and focuses on describing what is to be delivered in terms of requirements.
To complete and capture the information for the Vision, cycle and iterate through the ADM phases as many times as required.
To deliver the Vision there should be a dialogue to discover the stakeholders. Discussion to understand what their concerns are and to capture their requirements. These requirements can be fed through the BDAT phases, perhaps enabling the capture of further specific requirements, gaps or missing capabilities.
Stakeholder information can be combined with knowledge and research of business principles, existing capabilities, goals, drivers and constraints. Where applicable these can be expanded upon, to identify why they are relevant.
In the Vision phase the readiness for change or transformation can be addressed. It could be argued that a Vision is only as good as its ability to be implemented. This is a useful device for recognising any gaps, any building blocks or capabilities that must first be addressed or if you like it’ll help identify the correct starting point.
During this process the Vision is being captured, articulated and developed through iteration of the ADM. It still isn’t describing architecture in technology terms, the requirement takes precedence over technology.
The work undertaken in capturing the information outlined above provides a baseline environment and the Vision provides the target environment. This provides a device to assist in setting scope.
The scope is where we can start describing the level of detail, characteristics, what architectural, disciplines or specialist areas need to be covered and any time pressures. Of equal importance, it also defines what isn’t in scope.
None of this names any technology. If when completing this phase, it has been captured that the requirement is for specific technologies or applications, then it isn’t dealing in requirement it is dealing in solutions!
Completing each of the BDAT phases at a high-level provides the completed Vision and coming back to point provides the requirements to complete subsequent iterations. Keeping the discussion away from the solution or design means that each requirement can be considered without it having to fit a preconceived notion of the target environment.
The BDAT method within the ADM in effect helps set a precedence for requirements. It is enforcing a view that business requirements are primary. This can better be described as; technology supports the application which supports the data which in turn supports the business. Therefore, the business requirements guide the data requirement which in turn guides the application requirement which guides the technology requirement.
By avoiding technology decisions this whole process should be quicker than you might think. Could be conducted by a single individual that spanned domains. With the aim to feedback and gain agreement of the requirements and Vision with whomever is signing the cheques!
I’ve seen the completed Vision phase become the high level or conceptual design or I’ve seen it kept isolated as a requirement capture document. Either way functions to provide a solid based for further solution design work.
Further iterations of the ADM cycle conducted at a lower level of detail, will help to complete the low level or logical design and the build configuration or physical designs. At the next levels of design, technology decisions will be made. However, they’ll be being made against a complete set of requirements. Having the initially captured requirements should help to ensure that any future design work will meet desired goals.
Happy requirement gathering!
Simon