Functional requirements capture the behavior of a system whereas non functional requirements capture the quality of a system that determines the level of satisfaction that the stakeholders expect from the system. Non functional requirements (NFRs) aka Quality of Service (QOS) requirements (sometimes also called technical requirements) are requirements that have no visible impact on end users but these are requirements that satisfy the stakeholders typically the business or the organization that is implementing the system. NFRs is very important from an architect’s/designer’s perspective to decide upon the environment and the design of the system to meet those requirements. NFRs are typically quantified by the stakeholders when they are defined. The following are some of the typical NFRs.

• Availability/Reliability/Fault Tolerance - System availability to the end user at any given time. Example: 99.99% availability (that translates to a system downtime of 52 minutes per year)
• Usability - System ease of use and navigability to a layman user. Example: Should not take more than 3 mouse clicks to reach any feature/screen in the system.
• Performance - Throughput, response time requirements. Example: A sub-second response time from the moment after the user triggers an action in the system and until the system responds back to the user.
• Security - How secure the system is from hackers (in case of a web application) and unauthorized users. Example: The system should be secure and the communication between the clients and the server should be encrypted and signed.
• Portability - System’s ability to adopt to different environments. Example: The system should be able to work with the following RDBMS as the data source - MySQL, Oracle, DB2, MS SQL Server.
• Scalability - The system’s ability to scale and support number of active users at a given point of time. Example: The system should support 10000 concurrent users.

Non Functional requirements are SMART requirements where SMART refers to Specific, Measurable, Attainable, Realizable and Traceable. Sometimes two NFRs might be mutually exclusive meaning if one requirement is met, it affects meeting another requirement. For example the scalability requirement will affect the performance requirement given the infrastructure supporting the system. In order to attain both of these requirements, the architect might suggest the business to invest in additional infrastructure that can help scale the system to meet the number of concurrent users and also meet the performance requirement. If the business does not want to invest more in the infrastructure then a tradeoff has to be made between scalability and the performance requirement. Tradeoff’s are typically done with the business and architects/designers meeting and working together. The stakeholders jointly decide and prioritize on the non functional requirements under the following categories.

• Must haves - These requirements are absolutely necessary and cannot be compromised.
• Should haves - These requirements are necessary but could be compromised on the margins if it conflicts with the must haves.
• Like to haves - These requirements would be good to have but would be the lowest priority compared to the must haves and should haves.

Once the NFRs are categorized as above, the architect/designer could point out conflicts and work with the business to do tradeoffs. NFRs are equally important as functional requirements because it determines the stability and quality of the system. These requirements should be attacked early on and have an huge impact on architectural decisions.

Mergere has published a guide titled “Better builds with Maven“. The guide contains a complete walkthrough of how to use Maven 2 for building and deploying J2EE applications.

PS: Please click here for the complete Build Automation series of posts.

Google has launched a new tool “Google Notebook“.  Once added as a firefox extension, whenever you browse through sites, you can select a passage, right click and select  “add it to google notebook”.  Once added you can apply Google’s core strength, searching through the information you have collected. You can also publicize the items you have created in the notebook.  Another feather to the Google cap.

Singleton pattern is the most simplest and easiest of the design patterns that any designer/developer would be aware of. The purpose of a singleton pattern is to make sure that there is only one instance of an object throughtout the application’s life. Once an instance is created, the design makes it in a way that only that instance is used even if the program tries to create a new instance of it. The singleton object itself is lazily loaded meaning it is loaded only when the first use of the object is encountered. In essence Singleton objects have an application scope.

I was thinking that if I follow the design principles behind the singleton pattern I have a singleton object until I read through the JDC Tech Tips published in January this year. I thought this would be worth mentioning since I mentioned about class loaders few days back. According to the tip, if you are using a singleton pattern in your application and your application is a web application then which class loader in the application server loads the singleton class plays an important role in deciding really whether your class is a singleton or not. If the System class loader loads the singleton class and that instance is shared by all the other class loaders, then it is really a singleton object. If multiple class loaders were able to load the same class, then you dont really have a singleton object. Makes sense to me.

My friend Rajesh Kannan forwarded me a list of URL’s that has links to e-books/articles/tutorials to various technologies. I have added them to my del.icio.us. Thanks Rajesh for forwarding the links to me. Hope this would be come handy.
Enjoy.

If you have read the book “Agile project management with Scrum” by Ken Shwaber, then you would have understood what I am talking about. Throughout the book he refers to two sets of people, pigs and chickens. Pigs are those people who are committed to the project and work towards completing the project successfully. Chickens are those who are interested to know about the project but are not accountable for the outcome of the project, so they are prone to interfere unnecessarily in the project. But why call them pigs and chickens? Here is an old joke that the author recalls in the book.

A chicken and pig are walking down the road. The chicken says to the pig, “Do you want to open a restaurant with me?” The pig considers the question and replies “Yes, I’d like that. What do you want to call the restaurant?” The chicken replies, “Ham and Eggs!” The pig stops, pauses, and replies, “On second thought, I don’t think I want to open a restaurant with you. I’d be committed, but you’d only be involved.”

:-) The author mentions that distinguishing chickens and pigs is important in Scrum. I think it is very much valid not just in Scrum but in any project, to be clear on who is accountable in the project and who are just well wishers and audeince interested in knowing what the project is. And many a times these chickens would offer help, but watch out if that help turns out to be a nuisance. And remember that they are not accountable hence the impact will be on you, the pig.

dontclick.it is a site that doesn’t require a mouse click and a page refresh. It is really good to navigate through this site, though we are so used to mouse clicks that you might have to navigate through this application consciously by not clicking the mouse. Sometimes you have to pass across another link before you can reach the link you want to navigate to, but the application already takes you to the link that you didn’t wanted to go. This site was done in Flash, but I think a lot of these concepts could be applied to a rich UI application with AJAX features.

Class loading is a fundamental aspect of the Java programming language. A Java programmer should definitely understand the lifecycle of a class, when it gets loaded, linked, intialized and unloaded. Class Loaders are primarily responsible for handling these. The JVM has a bootstrap loader that takes care of this. Custom Class loaders could be created and could be loaded by the bootstrap class loader from which point onwards the custom class loader can customize and handle the default class loader’s functionalities. For example the AppletClassLoader is responsibe for loading the applets over the net and displaying them on the browser. This class loader is loaded by the JRE on the browser system whenever an Applet tag is encountered in the page. The class loader architecture in JVM (Java Virtual Machine) is well explained by Bill Venners in “Inside JVM” book. You can take a look at the class loader architecture in the introduction chapter of the book available here in artima.

Class Loaders play an important role in application servers determining where to look for a class. The ability to create custom class loaders has paved way in the advancement of specialized containers in application servers. Most likely you would have heard of web container and ejb container, they all have custom class loaders to manage the classes specific to the containers. A key problem in the J2EE arena is to solve the class loading problems or to put it crude, the CNFE’s (ClassNotFoundException). The J2EE application structure has different components. When deployed to an application server, these are loaded by different class loaders. If you have deployed a J2EE application, you might have already set some classpath’s, system classpath’s and application class path’s. How the class loading happens? How is the path resolved? This wonderful article on “J2EE Class Loading Demystified” talks about the class loaders in the Websphere application server and how it works.