10 Common Issues for Architects In Requirements Management

I wanted to share some common issues I see when managing requirements in large projects.

1. The blur between the Architect and Project Manager

Architects build architecture solutions, and if you read standards like ISO42010 its quite clear that designs have to meet the needs of the stakeholders and clearly stake how they do it. This means to design optimal solutions its architects that need to manage requirements. Project managers are there to track, report and guide project state. They naturally have an interest in making sure requirements are met, on time, on budget. Because of that drive I have sometimes seen project managers driving the requirements and their allocation. A good project manager complements an architect, and does not overrun them. The responsibilities between these two roles should be laid out clearly.

2. No project lead architect

In big projects with more than one architect there should always be an architect who is guiding the work of the other architects – to ensure that the different architects and teams are building to a common vision. Depending on the scope of the project that architect might be an enterprise architect or a solutions architect for example. Just because the lead architect is responsible of the solution doesn’t mean the architect cannot use other resources to help with the initial analysis. Large projects should not start without a lead architect coordinating parts, because costly mistakes can occur.

Keeping the vision on track

If you give three children three piles of Lego blocks they can end up building three different things, like a car, a giant chicken and a space ship. All great things that could be built with the same Lego blocks, but if the original idea was to build a house with a garage and car…. then you have problems. The same is true of requirements – three different architects can realize the same requirement in three different ways.

Inefficiency in design

Very often if you are running in large projects there are opportunities for synergies, and to avoid duplication of work in the design, and duplication of components in the resultant design. If one team is designing a platform for database servers, and another team is designing the solution for application servers, there are some opportunities there to reuse common elements to keep costs down.

When working in an organization with silo’s its quite common for separate product or service teams to have separate approaches to things like monitoring. If we are designing and overall cost and profitability are a concern at this point a lead architect should be looking at the feasibility of simplifying the solution. That could include talking to different architects that run the standard services. If 2 services use two different monitoring solutions, you have more complexity & more licensing costs, and need more people to support it. There’s also more things that can possibly go wrong. There’s not always a possibility do optimize down but at the very least those product service architects should be aware that such possible synergies exist.

3. Inconsistent requirements through text analysis.

If requirements are not given and have to created by analyzing text, or speaking to people its important that an architect creates a requirements list. if you do not work from one common set of requirements every paragraph of text is open to interpretation, which can lead to an inconsistent solution. An interpretation of text should be written down and agreed.

4. Unclear requirements

Sometimes requirements are vague or open to interpretation. In this case those requirements need to either be clarified by talking to the source of the requirements, or clearly documented assumptions need to be made, if for some reason there isnt an option to clarify with the source. Assume makes an “ass” out of “u” and “me”.

5. Pick your own requirements

In some projects I have seen an approach where a big requirements list exists that project managers ask the architects to pick the requirements that are relevant to them.

This needs to be done with caution. because several problems can occur. Firstly its possible that some requirements will not be managed unless the project manager is sharp. Secondly in taking this approach you can end up with an inefficient design. A good lead architect will look at all requirements together, and in understanding the principle needs of the solution will design and assign out responsibilities, and as I mentioned already will make sure that we have efficiency in our ways of working.

For example if we are looking at building a secure hosting solution and we have principles around layering security – to ensure this happens it may be that a specific set of requirements are given – and in order to get consistency throughout the whole design extra requirements may also be defined.

6. Not considering requirements hierarchy

Every project is a combination of customer requirements and internal requirements, and there needs to be a structure for requirements management to avoid a lot of conversation overhead, and to ensure we have efficiency in design.

Typically the business and customer are the priority. I like to use BDAT – Business, Data, Application, Technology as a priority. The hierarchy should be clear.

In the past i have seen service architects that are responsible for standard products in an organization say “no” to the business. Sure this can be done, but it comes at a cost, because if we cannot use standard products suddenly the cost of a solution gets a lot higher with customization. It needs to be clear within an organization that service architects are not there to say no – part of their job is to adapt standard services to meet customer needs over time. Architects have areas they are responsible for and they should be providing solutions and not problems.

A second part to this comes in when we look at the relative weight of requirements. If one requirement has to be met by three separate teams then of course each of those teams have a responsibility to show how they realize the requirement in their design, but the requirement should be managed at a level above – by either the lead architect or someone they delegate, to ensure that the realization of the requirements in design are done in a consistent fashion.

7. Unrealized Requirements

ISO42010 says something to the effect that every architecture concern needs to be framed in one or more architecture viewpoints. Effectively we are saying that every requirement needs to be handled within a design. So the design documentation needs to show exactly what is done to meet every requirement.

8. Forgotten requirements

If you are creating a solution from a request for proposal, its very easy to focus on those requirements, and not think about other requirements from other stakeholders. When building architectures we normally have a number of internal and external stakeholders, and we may be thinking about ITSM tools. When we are properly modelling motivation layers this risk can be reduced.

9. Forgotten principles.

When designing an architecture solution principles need to be applied. Often principles are given by either the organization or the customer, but sometimes when looking at requirements a lead architect will see the themes within the requirements that are given. For a good quality resultant solution it may result in project level principles that are to be considered throughout.

10. Not managing requirements

Requirements need to have a responsible person managing and owning them. in determining how to realize a requirement this is done as part of the requirements realization but also there’s a dialog that is happening between different stakeholders in the requirement. Its very important to keep track of the key decisions that are taken, any assumptions that impact the requirement, as well as the people that have made these decisions. Its something that can be key to understanding why decisions are taken in years to come.

Summing it up

You can probably see that managing requirements properly, especially on large scale projects is not an easy task – and to do it in the best way requires a good interaction between both project managers, and different architecture teams. Having a good requirements management process is not only key to ensuring projects are performed well, but also impacts the overall quality of a resultant architecture in project design.

Good architecture leadership can make or break a project.

Motivation Layer Modelling – Part 2

Following on from my last blog on motivation modelling lets look at Requirements, principles, and outcomes.

A Quick Recap

In my last blog we looked at Stakeholders drivers, assessments, values, goals and how they fit together to ensure we are meeting the needs of our stakeholders. We ended up with this view:

Figure 1 – The Complete Top Half of our motivation layer from last time

Once we focus on who we are achieving goals for we need to start to think a bit about how we achieve these goals. To keep the screen a bit clear i will create a separate view today and just start with the goals from our last example. Take a quick look at figure 2

Figure 2 – the goals portion we start with.

Putting in the first requirements

So we know our goals. the first thing i do is look at what would we need to do to realize each goal. its requirements that realize goals. In my case i drop them onto the canvas but don’t yet connect the relationships up – the reason being is because i will connect outcomes to the goals, and I haven’t done those yet.

Figure 3 – Adding the first requirements

This is really a first step. I cover requirements in other blogs. i will need to understand and document things before i am finished with the views but at the moment i just get them down, and can polish them before we complete the view. When I did my previous blog I lay out my timeline expectations in goals – for example Cloud offering must be in place by Q2.

Although I could also specify this as a requirement I didn’t when i quickly modelled this – because as a goal I know when we define the project and the roadmaps it will we represented out there. Of course I will define my motivation views in several iterations. After quickly putting requirements on the canvas I ask myself are they well defined enough that I can easily measure success. I immediately saw that “Fast training of technical resources on cloud tech” is a bad requirement – because fast is a subjective measurement – its better to say “Training of technical resources on cloud tech by end of Q1”. I only put timeline requirements in place here if they are essential.

When doing this work and creating requirements am also at the back of my mind thinking Plan, Do Check Act (PDCA). Planning something doesn’t give us value unless we actually implement it. Checking, and Acting would be an integral part of the architecture design. Also I don’t ever forget that architecture design needs to also cover the different IT Aspects – even though I have technical requirements on this view, whenever i talk about architecture design i mean we should cover all the IT Aspects. The Check & Act portions of this I would expect to be covered in the actual design.

Timing so far

Up until this point its taken me about 45 minutes to create those requirements. I am writing this blog at the same time. I would possibly engage a colleague or specialist to validate what i have written here, but its high enough level at the moment i don’t feel the need to. Stakeholders and technical resources will validate this over multiple iterations.


Figure 4 – realizing an outcome

Now I have laid out my first requirements I put in some outcomes. These are useful for validating that our requirements are actually doing what it is I need to achieve the goal, and also help for logically grouping things. I start to take a look at the requirements and what they really produce, and if they align to the goals, . take a look at figure 4. The requirements i have realize an outcome Cloud hosting product created. BUT there’s something there that bugs me. My requirement and outcome talk about the product being in place but still in my mind i was being bugged by the fact that the requirements do not capture the Q2 objective, and the outcomes haven’t captured it either. At this point just for my own peace of mind I create a constraint, even though we have covered our constraint in the goal definitions. This makes me feel a bit better because i know that I am being double safe. I have seen in some cases project managers focus on goals, and architects focus on requirements realization. By adding the constraint I minimize the risk of this important constraint getting missed.

Figure 5 shows how I filled out the outcomes now for the first goal:

Figure 5 – Requirements and outcomes done for our first goal

It made sense to me to split out design and implementation – because i know later on practically these may be run in separate project by different teams, and because I am always thinking Plan > Do > Check > Act in my head. My thinking here is that if you have an architecture process you are going to have to ensure as part of that process your delivered architectures have had some kind of benefits validated a time after things are delivered (which is where we Check if what we have done is ok, and Act upon that.. If you aren’t doing this – think about the implications. That could be a whole separate blog.

I would go through and figure out the different outcomes that each of my requirement’s are achieving and then checking my outcomes against the goals – looking for gaps. If the outcomes are not achieving everything we have as a goal, in our requiremetns we have missed something important.


I blogged on principles before. in the interests of full disclosure i am normally thinking principles in my head when i come up with requirements – and the next step i take here i normally actually do as part of the previous step. When you know your companies architecture principles its easier. Lets pick up some fictional principles.:

Figure 6 – Principles

At a company level, architecture board level, or even a project level there are principles that may need to be applied. Requirements normally realize them. We drop them onto our motivation view and start to connect them with the requirements we have in place.

Figure 7 – Attaching Principles

I am left with the principles that are not currently considered by the current requirements and goals. At this point I need to either modify the requirements i have, or add some new ones. In figure 8 you can see where I have started to add some requirements to ensure our requirements fulfill our principles. There are cases where when we may chose to not follow a principle. If that’s the case this should be documented in the design – you may even want to flag this as a risk.

Figure 8 – New requirements connected

Breaking things down

You can see that motivation views can get fairly complex. Each of them tells a story and its ok to break up things into multiple views – and connect them together via a single view at the top level. An overview is important because we have to understand the motivation in its entirety – even if the overview is only a collection of links to other views. The way I have broken things down between the first and second part of this blog could be a good logical break point, or you may chose to have one view per stakeholder, or whatever other logical split that makes sense.. The first part of the blog focused on the stakeholders and what we need and why – and this part is focusing on the things we need to do in order to realize those goals. The motivation view i have presented in this blog is typical of the kind of thing you can expect to see when engaging high level stakeholders for the first time.

Benefits vs Risks

I wanted to say a little something about why we model these different elements together for those people skeptical on taking such an approach with motivation views.

ElementBenefits of considerationRisks of not considering
StakeholderKnowing who your architecture has to provide value to makes sure you design something that meets everyone’s needsIf you miss a stakeholder its possible your architecture wont be fit for purpose or people may end up customizing things to suit the needs of people or teams you didn’t consider.
DriversUnderstanding why your stakeholders need to do things helps you ensure the goals we set actually provide valueIf you do not capture the reasons people do things, later you may have trouble understanding why choices have been made. There is a real risk that the goals that are set will not make sense and you will miss opportunities to understand synergies between your stakeholders
GoalsUnderstanding goals helps us determine both our direction, and our criteria for successNot capturing goals means badly scoped projects, unclear success criteria, which can lead to inefficiency and a loss of traceability and control of spend.
OutcomesHelp us ensure that our requirements are meeting our goalsif we dont check outcomes against our requirements is possible that our requirements do not collectively meet our goals.
PrinciplesHelp us ensure that the things that we are doing are meeting the design principles laid out by the relevant authorityPossibly creating designs that violate principles and do not work in the best interest of the company
RequirementsState the things we need to do in order to achieve our goalsNot having designed requirements may lead to designs that are not fit for purpose, due to missing essential requirements or needs.

Summing it up

Before we are finished with everything its of course important that we document our elements, so those that come after us understand what it is we say and why. This is particularly important with requirements. You can see that when i was creating this view i made some changes as i went, because i was always thinking of the readers of the views that will come later, and how these views will be used. Again, this blog wasn’t trying to fully demonstrate how i would implement a cloud hosting product, but should have given you some insight in how i think when i create these views.

Understanding What, Why, When, How and Who are an essential part of an architects job, and motivational layer model in the structured way i described help us ensure we do not do the wrong things when it comes to realizing architecture design.

I’ve spoken many times about how architecture design isnt just a set of servers connected to boxes – and ISO42010 tells us that all concerns of our stakeholders need to be framed in one or more architecture views. Having a good motivation view, or set of motivation views is the first step towards ensuring we do not have architecture solutions without problems defined.

Sure its possible to define all these things separately, spread across many documents (such as a project directive word file, a requirements excel, etc… Doing it that way can lead to a lot of unseen gaps, or risks in design. If its painful to design a motivation layer view for whatever reason, you should stop and think if you really know what it is your architecture needs to do, and if there are possibly some holes in your design. Thanks for listening.