Architectural requirements Q&A
Architectural requirements Q&A
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
A few days ago I was contacted by Lianping Chen a doctoral researcher from the Irish Software Engineering Research Centre. Lianping is doing research on “how to elicit architectural significant requirements” and he asked me a few questions, which I though, might be interesting to a wider audience.
1. 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.
While it seems to me Lianping is thinking mostly about large waterfall (or waterfall-ish) projects. I’d say this is true for all kinds of projects (agile, lean, iterative and waterfall). The tradeoff usually is waiting for some unknown point in time where the requirements will be set, known, approved and whatnot and starting to move forward. Architecture usually needs to start rolling when the data (in the sense of what exactly the architectural requirements are) is incomplete. This is exactly why I think Architecture should evolve over time (see the previous two posts on “Evolving Architectures” – part I, part II).
In my experience, in large projects, it is beneficial for the architects to be part of the requirements elicitation team. It is true some architectural requirements can be derived from “pure” functional requirements. However most of the architectural requirement can (and in my opinion, should) be formed by a deliberate effort. I personally, like the scenario based approach of creating a utility tree. Note that this does not contradict the point above, which says that some of these requirements will probably be off of the real requirements which will surface during the project.
2. Do you agree that when perform architecture 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.
Yes some architectural decisions depends on others. For example, technological choices can change other architectural decisions – after all technologies usually come with their own set of architectural decisions made by the people that created them. On the other hand, it is important to understand that some decisions can progress or be made in parallel as well. For example, UI architecture design can progress and form while the distribution architecture is still being debated.
3. Do you agree that, in most cases, for a particular architectural decision, only a 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.
Right, most of the functional requirements drive design and the implementations. Only a relatively small part of the requirements drive the architecture.
4. 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.
Yes, this is natural. “Requirement engineers” (or product owners in agile projects) are mostly concerned with the business aspects of the system - and rightfully so. It is important to have architects involved in analyzing requirements. Also, as I mentioned in a previous answer, it is even more important to have architects work with the different stakeholders (req engineers included) to specifically elicit architectural requirements. Sessions dedicated to quality attributes and forming them as scenarios in the system can help bridge this gap (the scenarios provide the connection to the functional reqs, and architectures are build around quality attributes)
5. 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.
I am not even sure architects are fully aware which items and requirements are important :) . In any event, as mentioned above,there are basically two types of architectural requirements. The first kind is requirements that can be elicited by direct, intentional analysis of the system from quality attributes perspective (thinking about scenarios where security, availability, scalability etc. come into play). For example in my current system (xsights) one requirement under extensibility – effort to change (data) we have the scenario “Under normal conditions, refreshing the system’s data (links, interactions etc.) shall not require a system restart.”
The other type of architectural requirements are derived from functional requirements i.e. specific functional requirements whose implementation can have significant implications on the system. For example in a previous version of our system we had the requirement to handle 3G video call. Components that participate in this need to be stateful (as there is constant streaming of video in and out)
The conclusions are that, again, architects needs to be involved in the requirement gathering effort; architects need to lead specific session(s) that involve eliciting requirements based on quality attributes analysis. Architectures need to evolve over time as requirements significant to the architecture may (and a lot of times do) pop up during the development effort
6. 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.
Yes to some extent, but architects involvement as mentioned above, would probably yield better results (in my opinion of course)
7. What are the main issues in eliciting architectural significant requirements? What researchers can do to solve these issues
I think I already answered that – but if not feel free to ask for clarifications
Published at DZone with permission of Arnon Rotem-gal-oz , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.