all bits considered data to information to knowledge


Do system architects dream of business analysts?

The following represents my answers to the questions posed by a Ph.D. aspirant in search of the thesis   🙂

1. Q: Do you agree that architecture design and requirements elicitation are usually in parallel or have a big time overlap? In other words, Architectural design usually starts before requirements elicitation ends, and usually a big time overlap exists between these two activities.

 A:  No, requirements’ gathering starts first. Even a simple sentence stating “I’d like to have a system that..” constitutes a requirement in my opinion. There are aspects such as existing Enterprise Architecture that require Solution Architecture to align with; it might exist prior to requirements gathering for a specific software-intensive solution.

2. Q: Do you agree that when performing architectural design, making some decisions depends on the outcome of some other decisions? I other words, a sequence/order exists for the set of architectural decisions need to be made.

 A:  Yes. Some of the decisions predicated upon the others, therefore there is a hierarchical structure, a decision tree.

3. Q: Do you agree that, in most cases, for a particular architectural decision, only a [s]mall portion of the whole requirements actually influences the decision making? In other words, there is mapping exist from the architectural decisions you need to make and the requirements required when you make those decisions.

 A:  No. There are architecturally significant requirements, requirements that affect the decision only marginally, and everything in-between. Moreover, they affect the solution architecture on different levels: system architecture, software architecture, information architecture, infrastructure architecture etc.

4. Q: Do you agree that requirements engineers usually do not know clearly what items/aspects of requirements are architectural significant (i.e., it is not easy to distinguish architectural significant requirements from normal non architectural significant requirements)? Thus, they may ignore/miss some items of requirements (some of them may just look like trivial details) that are actually architectural significant during their requirements elicitation.

 A:  Yes, to certain extent. Not being trained to architect a system, business analysts (the “requirements engineers” in your question) cannot decide which requirements are architecturally significant, and which are not. It is up to solution architect to reconstruct the missing links from the requirements gathered like a paleontologist might reconstruct a dinosaur’s skeleton by just a few broken bones

5. Q: Do you agree that requirements engineers usually are not aware of which items/aspects of requirements are required urgently by architects and which items/aspects of requirements can be scheduled a bit later to elicit? Thus, they may first elicit the requirements required for making the decisions in the tail of the decision making sequence, and schedule the elicitation of requirements required for the architectural decisions in the front of the decision sequence to the end of the requirement elicitation phase.

 A:  Ditto. See answer to Q.4

6. Q: Do you agree the following statement: If the requirements engineers are informed of what items/aspects of requirements are required and when they are required by the architects for making architectural decisions, the requirements engineers will be able to properly schedule their requirements elicitation activities and elicit the required requirements in enough detail and precision. So they will have higher chance to provide the required requirements to the architects before the architects make those architectural decisions.

 A:  Yes. Business Analysts (aka “requirements engineers”) need to work with all stakeholders, including Solution Architects, to solicit and refine requirements for a software intensive system