Tag: software

Why non-requirements are “more” important than requirements

quality attributesWhen I was studying more deeply software architectures, I learned about the most important thing to consider in an architecture (after stakeholders), the non-functional requirements. Yes! Not the functional requirements, but the non-functional requirements.
Before I explain this more careful, let me say what “I” call requirements and non-requirements. (I will use requirements from now on, meaning functional requirements and the same applies for non-requirements)
Requirements are the features the final customer wants. Something like, I want an intranet portal where all the enterprise information is presented, where the users can consult news about the company and where the users can request material, etc. Preference, very detailed, the project manager and all the developers thank you for that.
Non-requirements are the “features”/attributes not related with the business, but very important, like performance, reliability, modifiability, security, auditing, transactional, availability, interoperability, testability, usability and others.
Sometimes people mix requirements with non-requirements, and sometimes they are right. If I want to build a race car, probably performance is a requirement.
The non-requirements are also called quality attributes because they give quality to the architecture. You can build an ugly/raw intranet portal with all the requirements in there. You will have all the information and all the requirements you requested to be implemented, but as soon you present the final product to the end users you will find why the non-requirements are so important. Probably you will call soon a designer to bring some quality to the web pages, Usability. Then you will start to hear some complaints about the performance, a user opens a page and all that information takes a long time to appear. It is time to for the non-requirement, Performance. The users they need important information available on the portal, to do their work along the day, so you will want Availability. The portal should access information available in other systems, and then again, Interoperability, and we can go on and on about this.
Why is this important, and really important? These non-requirements or quality attributes change the way something is built. They should be considered before the development, for many reasons: technical, time, resources and financial, to say at least. Technical, because the architect should consider them in the design and development process. Time, because it will take more time to implement them that just code the raw functionality. Resources, because you will need to consider people expert in some areas, like designers, integration, etc. Financial, as a consequence of the others.
For instance, for usability you should consider experts in that area, like designers. For security, one of the most intrusive quality attributes, you probably need an expert in that difficult area, or consider what blocks of code or modules should be protected and how. It can be a demanding task. For interoperability, you will have to consider what information to consume and provide, protocols, security, etc. If you work in financial software, you will surely want to test deeply the software, so the code and the architecture should be testable, the code will be organized for testability, and a lot of extra code will be implemented for testing purposes.
When you buy a house, the attributes you will take into your decision are more about quality than the living ones. If you follow only the living ones, any space with some blocks adjacent to each other will be enough for living! But, you will consider the access (security), how easy is to move around the house (usability), how strong are the house, like walls, material, etc. (reliability), and if the house is custom build for you, most of the time you will be speaking to the architect to consider this and that quality attribute, you will not be telling him that the house if just for living there, sleep, being and eat. You will want more, you will want quality, you will want a house based, above all, in non-requirements, responsible for making your expected requirements richer.
Curiously, the acceptance of any project, will be based on how the requirements were implemented served by the richness brought by the non-requirements. At least if you want a customer happy.
Without the non-requirements, the requirements will, paradoxically, not be “acceptable” by the final customer.

Architecture – Its all about Stakeholders – Part II

<">viewpoints views

In the previous post, we have seen the importance of the stakeholders in the development of an architecture. Because stakeholders aren’t all fluent in technical language we must find a common ground to communicate.

Views and Viewpoints

An architecture is a very complex system. If you try to create one big diagram to show all the elements of the architecture and its relations, it will be a big document, only useful for the ego boost of the architect. The stakeholders don’t need do know everything about the architecture, just the parts with interest to them. For instance, users of a bank application, they are more concerned with the user interface, performance, available information and in many cases with security. They don’t care how the database server exists or how is it connected with web services, integration tiers, etc. The architect should create a set of views of the system, for each set of concerns of the stakeholders. To this set of views, we call it Viewpoint, a part of the architecture. One view always belongs to a Viewpoint, and a Viewpoint can have multiple views. Examples of viewpoints are information, development, concurrency, functional, deployment and so on. We can observe there is a set of stakeholders with an interest in each of these viewpoints.

Let’s see an example. When building a house, you don’t want a unique blueprint with every element of the house, the exterior, the interior, the materials, the flow of the light, water, electricity, streets around, halls, etc. You expect to have several views of the house. You will have some views for the exterior like front view, side view on the afternoon, or if you want to see how the interior will look, you have a view of the living room, another for the kitchen, rooms, toilets, and so on. Other concerns could be how you circulate inside the house, and you expect to see views from the entrance, hall, the accesses between rooms and living room and toilets, etc.
The views about the accesses are a viewpoint related to the circulation of people inside the house. The other views are more related to the context, how the house is presented from outside, for instance.
The house is the same, but the views are different, and directed to specific concerns and different persons (stakeholders). When the architect talks to you, shows how the house will be at the end, but when he talks to the company that builds the house, the concerns will be completely different, they are interested in exact measures, materials, ground, time. These diagrams will have information you don’t care because they are too technical.

Again, the stakeholders are the fundamental piece of the architecture, besides the project being developed for them, even the management activities are around them and depend on them. Your strategy as an architect should have the stakeholders as the main actor on the scene, and all the tactics should include them in every decision.

Now, we know how to talk with stakeholders during the development process of the architecture, it is time to include in these views quality attributes, or sometimes called cross-cutting concerns, like security, performance, cache, etc. We call them perspectives (it is not a consensual term in the architecture community, but the main idea exists and is shared). We will see more about this in Part III of this article.

Architecture – Its all about Stakeholders – Part I


In this three parts article, I will introduce the concept of how the success of an architecture depends on the relation with the Stakeholders. Part I will describe the influence of Stakeholders in the success of an architecture, then Part II e III will describe how to communicate and create a common ground between the architect and the Stakeholders.


A Stakeholder is: “individual, team, organization, or classes thereof, having an interest in a system” (ISO/IEC 42010).

From the definition, we can observe something all Stakeholders have”…interest in a system”. This interest can be from a perspective of the customer who is buying the system and follows closely all the steps in the creation of the product, until someone, anonymous, who just uses it, like a person or system buying a ticket to a game. So, the objective of an architect should be building a system maximizing the satisfaction of all Stakeholders.

An architecture is, therefore, built around the Stakeholders needs. The majority of the Stakeholders are people, so the human variable enters in scene very strongly in the construction of the system. Things like negotiation, agreements, meetings, communication, expectations management, are skills the architect should dominate.

An architect is not a Project Manager but should work very closely with him. The success of a project from the Project Manager perspective is the satisfaction of the Stakeholders, as so for the architect. That’s the reason, for some many times we see the architect as a project manager too.

The process of developing an architecture evolves thinking, technical skills and a lot of communication with Stakeholders. The Stakeholders, usually are persons who don’t understand technicalities. It is necessary, for the architect, to create a way to expose his/her views to them, to create a common language of understanding. For that, we need Views and ViewPoints, something I will talk about on the Part II of this article.

Do you have architects or senior developers?


Why there are very few good Java Architects?

Well, most people will say to me, that this isn’t true, they have Java Architects in their team. I believe, but most of them are Senior Programming Developers with some experience, but not real Architects! Sorry.

As a Java and J2EE trainer I have a lots of students learning Java, Java Programming, EJB, Servlets, JSF, JSP, Web Container, JPS, ORM, along the year. But in the last 2 years I have taught only one time a course about IT Architectures! Even people with 3-5 years of experience they became to my classes learning about Java Programming, some of them team leaders, “experienced” team leaders! After some questions about patterns, cohesion, density, coupling, etc.… 99% of them they just… ahhnn?? That’s when I know, that most of the team leaders are just Senior Developers!

modern-architecture-2A good final Java Product its about thinking in commercial aspects like: audience, final stakeholders, customers, commercial sensibility; and technical like: Load Balancing, Patterns, the 3 dimension of an architecture, density, cohesion, coupling, security, layers, tiers (which its different than layers, by the way), scaling, sessions, performance, etc.. Not only programming! Programming are the bricks, it doesn’t matter how knowing how to put bricks if they aren’t in the right place and in the right way, with a specific commercial goal in mind!
Poor decisions at the start of development will reflect in a weak product which probably will need maintenance in the future! Then the company will train or consult real Java Architects, or sometimes they just keep pushing the “Senior Developers” to try to increase the quality of the product…

So, if you are a company developing Java Products, besides people know about Java, train them in topics like:

– Patterns

– Architectures

These topics are not about Java, but they really improve the quality and the performance of any product development, including Java! And then you will have better Senior Developers, with some commercial sensibility (yes, architectures it’s about commercial sensibility too, one of the most important aspects in most cases), and after a while you probably have Java Architects, and you will have a great team to develop great products! (Well, there are the human factor to consider here.. .but that’s another story )

NDepend – You must have this tool!


I’m a .NET developer since v1.0 at 2002, and as you may guess, I’ve used a lot of tools to help me doing my job. How many times you realize that you are always doing the same thing over and over, in the same way, and sometimes you don’t even notice that you are letting some “little” bugs or “little” bad practices that in the long run will damage your code? And, how about projects with lots of assemblies, methods, complex behaviors, is this familiar to you? If it is, you want to check this tool NDepend

The first thing you probably note it’s the name, which lead us to think that this tool its about dependencies between components, assemblies, methods. Well, its true! But its much more than that! How many of us don’t need to visualize the dependencies from all angles in our project? How much do you value seeing the relations between your classes, assemblies, methods? How great its to know which method it’s the more complex, or more used, or more critical? Probably this “.net method” should be the more unit tested and optimized! In a team, a tool like this has great value, either for developers either for team leaders who want to know how the technical aspects of the project are going.

But this tool, its not only about dependencies, its about code complexity, metrics and very good warnings and advices to improve your code quality, too. In some tests I’ve made with this tool in one of my projects, I discovered that some of my code should be improved (almost saying fixed!), NDepend has show where there was some source code problems and why they were problems! I’m learning from this tool, besides my senior professional experience as a team leader, developer and Certified Trainer!

In NDepend you will find a lot of interactive visual graphs, matrix, trees of your code and its relationships, but besides the visual features of this tool, which are great, you have access to an advanced tool CQLinq(Code Query Linq) which allows you to build Linq queries to query YOUR CODE! Yes, querying your code!

I think it’s a beautiful feature, and a pertinent add-on to any tool which aspires to analyze code.

An example:

A Linq query to return all my public methods with more than 30 lines of code!

You can use all the Linq operators, such as Take, Except, and have access to a very rich API to query your code by a lot of different metrics, such as:

What are the 10 most complex methods?

As a first experience with this tool, I was very impressed, it’s a very productive tool, improves the quality of my code and of my team developers too. This tools its used by a lot of great companies like: ThoughtWorks, Microsoft, HP, Siemens, Google, Redgate and hundreds of others, they are not wrong about choosing it!

I’ will keep exploring this tool for my projects, my first impressions were great, so, why stop? If you are a professional developer I think you should give yourself an opportunity to improve the quality of your projects trying this wonderful tool! You can use it as either a Visual Studio Extension or as an Application outside Visual Studio.

For now I’m really enjoying what I have seen so far. In the future, I will certainly dig more deeply in specific features of this tool and post about my experiences,

Bad Behavior has blocked 127 access attempts in the last 7 days.

Hyper Smash