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