Website Design

The Art of Requirements Gathering (w/ my Requirements Template)

Okay, back to Architecture. It’s been great to take a bit of a break but it’s time to focus and get back to the job at hand.

I wanted to talk about Requirements Gathering today. I think it’s probably the most important aspect of being an Architect, regardless of whether you are a Solution Architect or an Enterprise Architect. And, yes, I do include requirements gathering with Enterprise Architects because our strategies HAVE TO meet the needs of our stakeholders and, to meet their needs, we have to gather their requirements.

Too few Architects actually bother to do a good job of gathering requirements. They have this ego thing that blinds them into thinking that they know everything and that others should listen to them (I can think of a pair of “Enterprise Architects” that comment in my articles on a regular basis that are exactly like that). So they go into an environment, look at what’s in place, and then decide what is going to happen. But they don’t bother to talk to ALL the stakeholders and find out their thoughts. 

And that, folks, is the reason why Enterprise Architects are having to justify their position in organizations. They don’t talk to Stakeholders enough.

When you start an activity, whether it’s a project or creation of a strategy, you need to determine who the stakeholders. And don’t limit the people that you view as stakeholders. You may think that it’s only the Sustainment teams but there are others that are going to have to be involved. For example, Management will want to have reports on how a solution is doing. There are end users that are going to need to be talked to for things like functionality and user interfaces. And the Sustainment team you are thinking about isn’t necessarily the only team that needs to be talked to. I can’t count the number of Architectures that I’ve reviewed that don’t say anything about monitoring tools.

One of the ways that I get around not missing a stakeholder is that I ask a very simple question at the end of each stakeholder interview. I ask:

Who else should I be talking to? 

Simple question but so open that I’m assured of getting additional stakeholders. And once I start getting duplicated stakeholders, I know that I’ve covered off the stakeholder list.

Speaking of open ended questions, that is where the real art of Architecture comes in. You don’t ask questions that can be answered with a Yes or No answer. You ask question that don’t have any inference and allows the person you are interviewing for requirements to answer based on what they define the question as, and not what you define the question as.

That’s a fine point for you – how to ask the question. Which sounds like a more open ended question:

What are your availability requirements? 


Do you want 3 x 9’s as availability? 

How you look at Availability and how your stakeholder views availability (or any other requirement) is going look different. You may be thinking about functional and non-functional requirements like having availability at 99.9% uptime. They might be thinking “I want to be able to use the solution between the hours of 9-5, Monday to Friday”. One is very technical in nature, the other is based on business need. 

So ask the question so that the stakeholder can answer the question the way THEY think and not the way you think. And, all of a sudden, you are listening to the business. 

Let me circle back to requirement gathering for Enterprise Architects. Remember, EA strategies are supposed to support the business. So when it comes time to create or update your strategies, talk to your stakeholders and ask them what their issues are. If you ask them that question, you might get something like:

  • We want to be more tied to our suppliers to speed up delivery of our products by getting our parts faster.
  • We want to reduce our Customer Help Desk count so we want to push our customers to our Portal.
  • We want to know where, exactly, in the manufacturing process our parts are.

Notice each of these answers are focused on the business and not on the technical aspects. The business doesn’t care if you have a dedicated VPN connection to a suppliers network and that your ERP has an API link to your suppliers ERP (possible technical answer to the first business answer). They just want to know when the solution will be in place and how it will be meeting their requirements. 

Those business answers are what goes into your strategies. Your solution approaches are then put into your roadmap and should (assuming the PMO doesn’t mess with your work!) tie together as part of a 3-5 year strategy. You end up mapping business strategies to technical strategies and should know what impact a change in project scopes will have on your overall strategy and relate back to the business strategies of your stakeholders.

BTW, when I start an interview (and my individual interviews tend to last roughly 40-45 minutes in length), I always tell the person I’m interviewing that they can go anywhere they want. If they view an area as something that needs to be talked about, then go there. I’d much rather have too much information than not enough.

So what are the areas that you should ask for requirement in? Well, I have standardized template that I use to make sure that I always ask for the requirements in the various areas. If I don’t use a template, I risk forgetting about an area. My template has a scope column (ie. requirement area), scope description (ie. description of what the goal of the requirement area is), and sample questions. I then collect the requirements in raw form, in the spreadsheet.

When (and if) you create your Requirement Gathering template, you’ll have your own areas to cover but it’s good to have a template for another reason. Inevitably, one of the people you are going to interview will ask for the template so that they can prepare their answers. I don’t really want that to occur because I want an unscripted session and the session should only be with one person and not a group. 

What areas do I cover in my template? Well, here are what I talk about:

  • Architecture Restrictions
  • Availability
  • Business Continuity
  • Standards / Audit
  • Consistency (I’m thinking of dropping that one because I seldom get an answer to it)
  • Country specific regulations
  • Documentation
  • Features
  • Finance (you would not believe the amount of times stakeholders don’t have a specific budget to stay within. But they may say that they want to keep the sustainment budget the same or they may say they want the number of support people to go down. That will actually lead you to a dollar figure).
  • Interface
  • Leveraged Assets
  • Maintenance
  • Operational Environment
  • Performance
  • Portability
  • Privacy
  • Reliability
  • Reporting (this is different from Documentation but if a stakeholder starts going into reporting when you are getting documentation requirements, let them go. The interview is based on their views, not yours.)
  • Scalability
  • Security (coming from Security Architecture, I believe that Security should be built into every solution and that starts at the requirements gathering stages)
  • Staffing / Labour mix
  • Usability

23 areas for Requirements. And each time I ask about the area, I ask the question:

What are your XXX requirements? 

where XXX is replaced by one  of those terms. I don’t describe what they mean to the Stakeholder because what they believe the term means and what I believe the term means are two different things. So ask that one, simple, question and then shut up! This is NOT about you, it’s about them.

Do your requirement gathering properly and your strategies and projects should go that much smoother. Apply standard questions to both projects and strategies so that you know what your stakeholders need. You never know, you may actually learn something new if you keep an open mind.