Software Requirements - The No 1 Critical Success Factor for any Software Projects - Part 1

Software Requirements - The No 1 Critical Success for any Software Projects - Part 1

I started off writing this article titled "Critical Success Factors for Software Projects", and continued to list down the factors, which went like "Scope", "Requirements gathering", "Requirements Elicitation", "Requirements analysis", ... which made me realize that there are so much to write just about Requirements... and that's why its called "Requirements Engineering". And all the good memories of requirements issues and how we solved it came running to me.. so here goes:

What they forgot to teach you at Software Engineering 101:

This is what they forgot to teach in school. Requirements is the single most important factor in any software project. This becomes even more important when its pure customized or bespoke software development and deployment project. (now, the below requirements are on the waterfall model, as other Agile model's issues are slightly different. The reason waterfall model was chosen for this discussion is because it is still the number one model used for most of the government software development jobs out there!)

To understand how and why is Requirements important, lets look at how it plays a part in Software Development Life-cycle project delivery and deployment.

Stage 1 - The Project Proposal (something like the marriage proposal)

It all starts at Project Proposal. Think of it like a guy proposing to his new found girlfriend, with a shiny diamond. In this case the Project Proposal is the diamond! Yes that's how most project proposals are designed. The scope and cost and timeline factors are made so attractive to the client, that it is usually written in a way where:

1. It either makes the software features promised look too good  (hence over promising)
2. Or hides certain critical information (which causes assumption or room for scope creep later). And it gets better if the client

If the client is experienced and does a thorough review, hidden information will surface. But most client are just too happy and tends not to dwell into details, as long as the scope and price looks good. (something like the wedding proposal - as long as the diamond and guy looks good!). At the most, clients tend to negotiate pricing. And vendors may even start to water down the requirements, scope and features based on this revised pricing. Quality lost at the expense of price? Possible. And this is the start of Requirements issue....

Stage 2 - The Requirements Process

Now that both parties (client and vendor) has entered into a contract, the formal requirements gathering happens, and in a strict requirements engineering discipline, the following sub-process would be followed:

1. Requirements identification
• Ideally, high level requirements are identified. One way of getting this done would be to list down the major use cases in the system.
2. Requirements analysis and negotiation
• This would a high level exercise, cross checking the scope, identifying missing gaps and so on.
3. Requirements specification (Software Requirements Specification)
• documenting the requirements in a requirements document
4. System modelling
• deriving models of the system, often using a notation such as the Unified Modelling Language
5. Requirements validation
• checking that the documented requirements and models are consistent and meet stakeholder needs
6. Requirements management
• managing changes to the requirements as the system is developed and put into use

For this round in this article, I am going to write in bullet form, some of the issues face in the above requirements engineering, will go in detail in the next round of requirements discussion. (1 article is not enough for this topic).

Requirements (Problems and Answers)
Usually, based on the project proposal's scope, the major use cases are extracted, and presented here as a system model, as below:

Now, this looks good. Well structured and drawn. But that's where the issue lies:
(I try to keep the solution to each solution simple, and straight to the point - in blue text).

1. This is done based on the Project Proposal - a scope too high level - subject to personal interpretation and may not provide a full understanding to the System Analyst who is doing this System Model.
• Solution:
• Spend enough time at the time of Project Proposal, detailing out the requirements
• Get the major use cases done and documented in the project proposal.
• Do not wait until the time and cost gets frozen in the project proposal, and then start doing the formal requirements gathering.
• Both party - vendor and client must spend enough time reviewing and clearing out any doubts on the requirements
• Get a proof of concept done at the project proposal done based on this major use cases.
• The POC should be a clicke-able HTML / WireFrame screens based on the major use cases
• I do this all the while, it takes time, but I get it right, from the Project Proposal onwards!
2. Question: Who is the best person to do this? A system analyst who just got introduced to the project (probably he or she can be a domain specialist in the business, but every business is different, and this is specially true, when this is a business / enterprise application - which may not have any particular standard compliance - making the standard operating procedure extremely agile - according to the whims and fancies of the end user?).
• Now, I am not saying that a 20 years experienced System Analyst in the healthcare industry (an example) would not be able to come up with the major use cases of hospital operations. My point is that each hospital can be different, and the System Analyst would have to know exactly how this hospital works in order to satisfy the Medical Director, CEO, Head of Finance, etc (each having their own perception and needs and wishlist).
• Solution:
• JAD - Joint Application Development. (http://en.wikipedia.org/wiki/Joint_application_design) - This has been found to be VERY effective in getting input as well as support from all level of users. Wikipedia adds this, which is very true : " It consists of a workshop where “knowledge workers and IT specialists meet, sometimes for several days, to define and review the business requirements for the system.”^[1] The attendees include high level management officials who will ensure the product provides the needed reports and information at the end. This acts as “a management process which allows Corporate Information Services (IS) departments to work more effectively with users in a shorter time frame.”^[2]
• Change Management is never easy for any level of users. This is even more true for the people on the ground - the end users of the system.
• Providing them an oppurtunity to be apart of the change management, not only boosts their moral, but also provides a good method for the vendor to get early acceptance from the end users for the system.
• Simply by listening to them and incoporting some of their ideas into the system design based on years of of their experiance (and trust me, we will have a lot to learn from them!).
• This makes the User Acceptance Testing less difficult, and chances of getting your system rejected is a lot lesser.
• It took us about 5 months to do the SRS (Software Requirements Specification) for a 3 Million dollar software project. But once software deployed, it was the users who was proud of it, and showing their colleagues the screens they helped to design, and how good it looks now. A world of a difference!
• 
  

To be continued.... (so many more to add!!!!)

Use the right requirements tool. Save your projects infographic

Software Engineering needs to be made cool again!

Hi all. This is probably the funniest thing I have done in my professional life – trying to make Software Engineering exciting ? Why you make ask… or how you may ask… well, as usual, I’ve got a short answer and a long answer. The short answer is to ensure that  I myself am exciting about this piece of art (yes, not science, day by day I am discovering there software engineering is more art than science, hence making the word engineering more of an oxymoron!) and rediscover the very reason I got into this it – my passion!

The long answer is pretty long… so long that its gonna span few articles – which will be the articles I’lll be writing in the next few weeks or months (I hope). I hope to cover various topics in Software Engineering… but not from the technical point of views… I believe that there are tons and tons of technical papers out there to last a life time of humans (before they kill themselves and this planet!).

The objective of these articles are to discuss the day to say issues, risks, progress, and anything got to do with our dear SDLCs – yes, Software Development Life Cycle. The fact that we are still using waterfall model lifecycle just blows my mind! Did you know that waterfall model was first introduced in 1956 by a guy called Herbert? (http://en.wikipedia.org/wiki/Waterfall_model). I am not saying that waterfall model cant be used, but the fact that many projects still use the 57 year old waterfall or modified waterfall model to develop "cutting edge" 21st centry solution is really mind blowing.

Does the Famous SDLC Waterfall Model work?
Nevertheless waterfall makes Software Engineering more comprehensible to the non-IT people out there.
Or is it otherwise? Well, before you can commet, it is best to understand what is Waterfall model?
I am quoting my friend - Shah Newaz Alam's excellent article on the pros and cons of the fall (waterfall):

The Waterfall Model

The most important aspect of the waterfall model is that unless a particular stage is complete, the next stage cannot be started off with. Here, in this article, we will try to understand a simple waterfall model, broken into six stages. Let us try to understand each of these stages one by one.

Stage 1: Requirement Phase

Whether you design a small program to add two numbers or you are into developing a software system for the automation of an entire airline company, this is the first stage which can never be overridden. Unless you know what you are going to design, you cannot approach the problem. Here, the specifications of the output or the final product is studied and marked.

Stage 2: Specification Phase

With all the requirements and constraints in hand, a final view of how the product should exactly be, is decided. The exact way in which the software should function is mentioned in this stage.

Stage 3: Design Phase

Here the actual work begins. Every type of resource which will be required for the smooth designing of the software, is mentioned here in this phase. What type of database will be required, what type of data should be supported, etc. are some of the important aspects that are decided in this phase. The algorithm of the process in which the software needs to be designed, is made in this phase. This algorithm forms the backbone for the actual coding process, that takes place in the next phase.

Stage 4: Implementation and Testing Phase

Now starts the coding. Here, the software is coded as per the algorithm. Hence it becomes very important that the algorithm should be properly designed. The software designed, needs to go through constant software testing and error correction processes to find out if there are any flaw or errors.

Stage 5: Integration and Testing Phase

Here the various codes designed by different programmers are integrated and is tested if the software works as per the specifications provided. The setup of the final software which needs to be installed at the clients system, is also designed and tested, so that the client does not face any problem during the installation of the software. The product is then handed over to the client.

Stage 6: Maintenance Phase

The cycle of software development does not end with handing the software to the client. Software designers may have to constantly provide support to the client to resolve any issues which may arise. During the maintenance phase, support and debugging is provided for all such problems.

Advantages and Disadvantages

Advantages

The waterfall model is the oldest and most widely used model in the field of software development. There are certain advantages of this model, which makes it, one of the most widely used models as yet. Some of them are:

• Being a linear model, it is very simple to implement.
• The amount of resources required to implement this model are minimal.
• Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
• After every major stage of software coding, testing is done to check the correct running of the code.

Disadvantages

• The question that must be bothering you now is that with so many advantages at hand, what could be the possible disadvantages of the waterfall model? Here are a few:
• Ironically, the biggest disadvantage is one of its greatest advantages. You cannot go back a step; if the design phase has gone wrong, things can get very complicated in the implementation phase.
• Often, the client is not very clear of what he exactly wants from the software. Any changes that he mentions in between, may cause a lot of confusion.
• Small changes or errors that arise in the completed software may cause a lot of problems.
• Until the final stage of the development cycle is complete, a working model of the software does not lie in the hands of the client. Thus, he is hardly in a position to inform the developers, if what has been designed is exactly what he had asked for.
• So this, in short, was all about waterfall model advantages and disadvantages. In spite of the cons, the many pros of this model ensure that it remains one of the most popular models used in the field of software development.

.

.
.