The requirements can be divided in two general groups:
- External requirements – those are the functionality specs for the solution, normally provided in marketing requirements, in tender documents etc.
- Internal requirements – those and the requirements related to quality of the system and are mostly non functional requirements like maintenance, redundancy, scalability etc.
There is a large difference in the weight of the requirements: external requirements are well specified and they are the basic scope of the solution but internal requirements reflect the quality of the solution and attention to the longevity. Thus it’s preferably to understand and put the quality attributes first and then put on top the functional requirements.
This methodology is the core or motto of my blog as it puts the design part: where the quality attributes are analyzed, understood and incorporated getting to the small details of the minute requirements.
I want to make this site different by looking at a system as a whole not as something made of small parts like seen in most programmer sites ( code horrors, .net, )
The functionality requirements are more easily understood as they are normally well described and exhibit some business logic. Thus implementing the functionality requirements is normally done by applying some logic and trying to reuse some basic infrastructure.
A the end, the most important role of a system engineer is to be a designer, where he sees the architecture and can merge the different forces into a aesthetically pleasing solution very much like an artist or a craftsman. Unfortunately, there are very little resources for understanding the complexity of moderns systems, just basic design patterns for some basic problems.
I’ll try to look in this blog at the requirements from a larger perspective, trying to show a different approach for designing and understanding, not only micromanagement of requirements.