Building Requirements

Building Design and Engineering is not possible without requirements for the building. We know requirements are important, but how should we capture, store, check and maintain them?

To test the Agile Prototypes we develop in this course it is important that we have clearly defined requirements. This can be challenging as we are ‘designing in the future’. Therfore the requirements for your project, like the futures you are designing them in, are unknowable. That is why in A1 we have asked you to define your near, mid and far futures.So to support this process in this course we have asked you to describe and then ‘freeze’ your three futures to give you a chance to design to those futures.

This however runs the danger of reinforcing a fixed requirements mindset missing the opportunity to use the requirements as a living document that learns from the design interation result what the client ‘really wants’. What methodology supports us to get from a sea of ‘unknown unknowns’ in the early stages of the design to ‘what the client really wants?’

On the one hand we could choose a traditional approach such as Requirments Engineering which is outlined below, but that would not help you once the ‘training wheels’ of this course are released and you need to manage building design requirements in real projects with uncertain futures. Agile methodologies that inform the methodology for this course are not naturally strong on requirements engineering, therfore lets start by looking the strong requirments methodology of requirements engineering.

Requirements Engineering (RE)

Requirements Engineering frames the elicitation, analysis, modelling, specification, validation and management of design requirements as the focus of a design process. Although some Agile purists may regard this as ‘out of step’ to the Agile priniciples, parts of it maybe useful in our [Agile Prototyping] approach.

Strengths

It does encourage stakeholders and developers to meet even if only in the pre design stages.
The methodological focus on requirements can indeed lead to better requirements - supporting higher quality design, if the requirements are well captured and do not change.
Explicitly modelling requirments in UML as supported by RE would support automated checking and increase the quality of automated feedback and guidance in the deisgn process (before it is too late to make changes).

Challenges

RE focuses on capturing static requirments fails to challenge the classical engineering mindset (tell me the problem and then shut up and let me fix it), that worked in a classical sense but is not as effective in the complex multi faceted work of 21st century deisgn and engineering.
It does not support changes in the requirements (as much as agile does). this also means that it is more difficult for the design team to absorb each others changes and advice, reducing design integration.

Agile Requirements?

Unlike in Agile methodologies where frequent meetings are required, RE tries to capture ‘high quality’ requirements following the acceptance of the draft requirements at the requriements validation stage. It is then not normally deemed necessary to question the requirements.

This is similar in some ways to traditional building design, wherein the requirements of the client and stakeholders are captured in the initial stages of the design process and then synthesised into a design model whose engineering is then tested.

Unlike in a true Agile Process which appropriated elements of participatory design, the traditional building requirements disconnect the client, user, design team and stakeholders in the design process, until they have a result they would like approved by the client.

An alternative approach is further complicated by the context of ‘designing in the future’.

This is what we will look at in Assigngment 2