A Matter of Perspective
I was recently working with a client that develops and deploys large-scale, complex solutions. Their product consists of custom and COTS hardware, embedded software, networks, and server-side installations.
At one point, we entered into a discussion that included the age-old requirements vs. design concern, the idea of system decomposition, and the nature of responsibility between the analyst and the architect for their systems. Each of these ideas were a source of debate within their organization, and with no final decision, the waters were sometimes murky.
Through discussion with the team, it gradually became clear that this complex mass of topic could indeed be sorted out. The core of the matter is the area of system decomposition, and once we get a handle on how the organization needs to manage that, everything else falls into place.
For the systems they build (and for any large-scale, complex product), it makes sense to consider first the requirements of the system as a whole. The end user is far less concerned that the product contains this widget or that doodad, they are concerned primarily that the system meets their overall needs. We need to perform that analysis to ensure we have identified and prioritized their needs, and captured the features we will be providing as embodied in our product. We do this analysis as if our system is a black box, without regard to the internal makeup of the system (unless there are specific constraints that may drive some elements).
Once we are clear on what we need to build, we get to the point where much of the confusion arises. To this point, we have solely been in the domain of analysis, and generally it is the analyst that drives the show. From here, though we need to start to break apart that black box, and devise an architecture for our system that will meet our end user’s needs. We layout the division of responsibility between hardware and software, identify firmware components and network architecture. We are performing a system design, and the architect is generally driving the show here.
The key thing to note here, though, is that in performing a system design, we are in turn specifying the subsystem requirements at a high level. Each subsystem that we identify in this design activity inherits a collection of the system-level requirements that we originally analyzed and specified. At times, several subsystems will need to share and collaborate to support these system requirements, at times a subsystem will be able to manage a higher level requirement on its own. We are simultaneously designing the system and analyzing the requirements of the subsystems. It is not an either-or, it is both in conjunction, depending on your perspective (am I architecting the system, or am I analyzing the subsystem?).
For those subsystems that we need to develop internally, this will kick off a sub-project that starts with a fleshing-out of the requirements for that component, be it hardware or software. There is potential, if the system is comprehensive enough, that this subdivision needs to be performed recursively until we get to a point where we can bite off a chunk and say “I can go build this”. For some subsystems, the allocated requirements will become purchasing criteria for COTS products, or selection criteria if we have a standard library of reusable components to draw from.
Who is responsible for this at any point in time? While it is simpler in theory to try to suggest that the analyst starts the ball rolling, then hands off to the architect, this is not a reasonable reflection of reality. It is much more a coordinated effort throughout, with each participant taking responsibility for one portion of the effort. Initially, the analyst will drive things to ensure that the system as a whole is identified to meet the end-user’s needs, but this is done in conjunction with the architect, who will have better insight into concerns such as feasibility, existing components that can be leveraged, and so on. Indeed, to do the job right, the analyst will rely on representatives from all stakeholder communities to ensure all their needs are met.
When we get to the point of decomposing the system into its components, the architect will take the lead to ensure that the components will all work together effectively to support the system needs, but the analyst will be right there to ensure that each component is reasonably specified. It is not simply a matter of passing requirements down to their respective subsystems here. As the system is subdivided, we are actually creating new interfaces, and deriving interface requirements between these components that the analyst must capture.
As an example, if the system needs to shut down when it gets too hot, this gets allocated down to a hardware sensor somewhere in the system and the software that needs to monitor the temperature and perform a controlled shutdown when necessary. On top of that, though, we discover new requirements that are not part of the system analysis. That software needs to know what register to check to read the temperature, it needs to know how to convert that reading to an actual temperature for comparison, it needs to talk to other software components or other systems on the network to tell them to shut down or provide status, and it needs to be able to read the register and not be blocked by other processes along the way. All requirements, derived at this subsystem level.
The analyst and architect need to work closely for all this to be identified, and so it goes throughout the development of the product. There should never be a handoff over the wall to the ‘next group’ it is an ongoing dance of participation along the way. The key thing discovered here, though, is that based on your perspective, design at one level drives further analysis at another level. – JB