Where is the Requirement Document?

This blog is on an obvious topic. But for those who are still using a Requirement Specification document it can be an interesting read.

When I started with my first project in year 2001 we had a 200+ pages SRS - System Requirements Specifications document. Till year 2007 I worked on several large projects/products and each had a fairly huge Requirement document.

Few months back during a conversation I realized that I have not seen a SRS document from year 2007. These projects were much larger and were Enterprise scale with geographically distributed teams. So, then what happened to the Requirement Document? What led to collapse of Requirement document and what replaced it?

Giving it a thought I think a shift to agile methodology provided clients the flexibility to change the requirements. Maintaining requirement documents along with code with short iterations is a tough job and often the effort would go waste when requirements would evolve or change in subsequent iterations. Following drawbacks of keeping requirements in a document were evident:

• Frequent changes require revisiting entire related requirements. Relating requirements in a document was not an easy task either.
• Changes in Requirement would affect not only code, but Technical design document, test cases document, etc. and keeping traceability between Requirements and these artifacts is not again an easy task that can be accomplished via documents.
• Change to Requirements also affects Project plan and getting a real time report for this required a lot of efforts

Clearly, evolved the need for a tool sophisticated enough to accomplish above tasks. There are several tools available in market that would capture the requirements in form of User Stories and then link test cases to these along with any technical design and could also link code committed to a particular user story. Requirements could be categorized, prioritized; defects could be associated with Requirements. These tools would also integrate the estimates to accomplish the change and provide on-demand and live reporting with most features entailing entire Software Development Lifecycle. When required, the tools will filter the data as desired and export it in many different formats.

  

This tool completely replaced the need for a requirement document.

But does it mean that requirement capturing techniques like conducting workshop, interviewing clients, use case diagrams are also out of picture. Answer to this is a big NO. Requirement capturing is THE most important aspect of the project as this is the way you define and redefine what the end user actually need. Only that you document the requirements in a tool which allows traceability and visibility than using a stale document which will become obsolete by the next iteration.

Closing this blog, I also recall that I have not seen a Technical Design document from Year 2007 onwards. Few important very complex things where various components are interacting did require some sort of technical design document, but then I did not see a Tech design for many complex functionalities. A self-organizing strong team would infer the design from the code. So, code is the only documentation we had from a long time now. Do you also work in similar pattern these days? Do you like it? Probably this will need another blog to talk about this.

 

Agile Development – Change is constant!

Often I see that whenever there is a change in requirements from the client, the developers tends to get de-motivated.. unwilling to change the codebase.. I hear comments like: 

• They are not clear on what they want 
• They should first define their requirements and then move forward with this 
• Our marketing team would accept just everything that client wants without pushback 
• Frequent changes will destroy the design

.. all pointing that we developers are unhappy and someone there is not doing the job correctly.

Times have changed and we are agile. Change is reality; business is changing every second. Think as if you have your own business - would you not like to make changes as you go, may be your vision changes with market, may be you want to do something different based on your competitors or based on some new innovative ideas and so on.. When your customer is asking for a change, it means a lot to them. It means a lot to the value to end-users that will be offered by the product you are eventually helping them to create. By buying into this change you are helping a wider community.

Agile methodology is all about accepting the fact that - change is constant. Agile helps to manage change. Does agile then mean that we keep changing things? I guess no. We should definitely reason and demand that why there is a change. We should evaluate and suggest the client if the change is not for good or if there are better alternatives. However, we should also understand that why someone wants to change and if this is genuine change, then we should embrace it.

Ten tips for Clients and developers involved:  

1. Reasons for change should be conveyed. People should buy into the idea. It also will help you validate and understand implications of the change and also invite other cheaper/better ways to have that incorporated. 
2. Frequent changes means that something could be going wrong. May be vision has a problem. May be execution strategy is not concrete, may be this is not the right time to start... And yes, implementing a change does costs something. 
3. A change control board (CCB) consisting of client stakeholder (Product owner and others) and vendor management/arch/lead responsible for change management should be trusted.
4. Change needs time to implement, this should be scoped well and included in the plan.
5. Developer’s can fix a problem as a hack or can provide proper desirable fix. If time will not be provided to implement the changes, changes can still be done but will involve hacks. Hacks will deteriorate the overall quality making system costlier and difficult to change as month’s passes by.
6. Design a flexible architecture which meets the current spec out requirements. Don’t overdesign and do accept the fact that design will change.
7. You can minimize the efforts by using appropriate design patterns, by following design principles.
8. Follow agile, follow refactoring, follow TDD... They will ease changing code.
9. Enjoy changing code, see how your design handles the change, you will definitely learn new ways of refactoring and also newer ways to design your next system.
10. Refactoring is fun. Once you achieve it and then when you see cleaner code you feel happy about it. And once change is delivered and it’s making difference in end-users life, that’s the real reward you get.

Next time you are facing a change, do question it and once answered, embrace it with affection. Change is good.

 

AOP using Unity2.0

AOP using Unity 2.0: http://www.codeproject.com/KB/architecture/aopusingunity2.aspx

ASP.Net Web Application Migration to Windows Azure

My blog - Web Application Migration to Cloud - http://blogs.globallogic.com/aspnet-application-migration-to-windows-azure

My SOA Mindset

Intention of this article is to demonstrate that unknowingly we replicate a lot of code in enterprise which can actually carefully can be isolated as independent services to form a integral part of SOA Enterprise architecture.

By reading this, may be next time you will have a different outlook on day-to-day code that we write.

Recently I was developing a ASP.Net site that would allow searching of users from Active Directory and adding them to the application after assigning a Role.

This application is for a enterprise that has around 20-30 existing applications in use.

With SOA buzz around, here are few thoughts I have put in..

Why not create a Web service which returns users from Active Directory based on some filter. This web service can then be used across applications and so several applications using such a search would not have individual code to test/maintain. Someday if enterprise wants to move away from Active Directory then all they have to do is change this one web service (instead of applications using them). Also, if there is a new version of AD api with some optimizations then its only one place where we need to change. Clearly creating components as services has benefits.

While assigning roles to the users, again the SOA buzz'd me. I think almost all applications would have users and would have roles, in the enterprise. If we have a common component that assigns roles to a user, and going further does user role management then this common service can be used across enterprise. One big advantage I see is a centralized user repository and single user management module. One can also cache (with dependency) roles and user/roles association (as I guess Role assignment is not a matter of frequent change activity). This provides optimized, enterprise-wide access to User / Role functionality.

Progress Control in WPF

My article on Code project http://www.codeproject.com/KB/WPF/wpfprogressringcontrol.aspx

Read XML with Namespace resolution using XLinq.XElement

My article on Code project http://www.codeproject.com/KB/linq/xelementns.aspx

Thinking QA Automation

Introduction
This article will help you get started about thinking from an high level on QA Automation process and QA Automation Framework expectations.

Background
I was asked to attend a QA lead meeting for discussing QA Automation process and framework. I have never been a QA resource but with my previous interactions with few QA teams and browsing thru several articles on net I could get an overall understanding of QA Automation.
As in our case we knew that we will use Selenium tool as it was already being used in some existing projects and as it is open source (and free) and offers several advantages, so I have also listed few findings around Selenium tool.

QA Automation process will involve thinking on following

1. Capture Business Requirements and maintain traceability between Requirements and test cases to ensure that you have test cases against each requirement.


2. Write manual test cases against each requirement. Manual test case writing will help as a pseudocode for writing automation tests. Moreover you might not want to write automation tests for functionality which is still not finalized. Also there will be cases (due to limitations of automation testing tools) where you will have to rely on manual testing.


3. Think about What interfaces does your tooling need to interface with. For instance, do you need to drive a browser, send SOAP/ REST requests and validate its responses, validate email notifications, do database validations, do document or image validations etc.


4. Choose a tool based on your requirements. There are high end tools available like QTP which are costlier and then there are widely accepted feature rich open source tools also.


5. Identify tests that can be automated vs manual tests


6. Grouping test scripts by Module / Use Case


7. Identify Recovery Scenarios / Execution Conditions when a test script will fail


8. Integrate Test Automation Scripts in Build process


9. Choose QA Automation framework. Action Driven / Data Driven / Record & Playback. Data Driven Frameworks are maintainable for mid-large size projects.

Considerations for developing a QA framework include

1. Error Logging when a script fails. This will indicate a test failure or will indicate a test script change


2. Notification Rules


3. Automatic Defect Logging in case of any failure


4. Storing Test Data in Excel or DB and writing utility functions around retrieving it


5. How to minimize propagating errors following a failure in one of the scripts


6. Monitoring of memory consumption, disk space, etc as applicable.


7. A set coding conventions and best practices for writing test scripts


8. You can write functions to select a menu choice, pull up a dialog, set a value for a variable, or issue a command. If the UI changes how one of these works, you change how the function works.

Few facts around Selenium

1. Selenium automation tool is absolutely free. Selenium allows writing and executing test cases in various programming languages including C#, Java, PERL, Python, PHP and even HTML.


2. Selenium can test Silverlight applications using a extension -http://code.google.com/p/silverlight-selenium/


3. Selenium weak point is that it can test only web applications. Selenium cannot test Web Services, REST and JSON. Please correct me here if I am wrong.


4. Selenium supports AJAX testing using waitForxxx functions


5. Selenium can be integrated with Build process and continuous integration tools like Hudson and Cruise Control


6. Selenium supports Data Driven Framework

Some Good links that I browsed

1. Improving the Maintainability of Automated Test Suites - http://www.kaner.com/lawst1.htm


2. Introduction to Selenium (Good and Bad points): http://www.qaautomation.net/?p=4


3. This links says that WebTest (another open source tool) is better than Selenium in few things - http://mguillem.wordpress.com/2007/10/29/webtest-vs-selenium-webtest-wins-13-5/

History
Please suggest additions to this article based on your experience and thoughts and I will update the article accordingly.