Question

The Gartner article, "Use Business Process Modeling to Visualize and Bring Clarity to Requirements Analysis", describes a scenario where the company avoided requirements gathering and documentation, feeling the requirements documents were useless, incomplete, and inaccurate, causing more work for developers in the end, with little utility. If you've been involved in a project at work where a similar anti-requirements mind set played out to non-optimal results, including project failure, please share your experiences with the class.

Answer 1

Being a part of software deployment team where the software requirements were not thoroughly gathered from customer, I learnt a lot about the importance of requirement gathering and analysis. Lack of requirement gathering and analysis lead the project failure at the end.

The software started with a small number of requirements which were not thoroughly defined by customer and the management team ignored the analysis of the requirements stating it will waste the time and not mandatory for a good project delivery.

While working on this type of software process, I experienced below aspects:

1. Assumptions: With lack of detailed requirements, the software development was started with a lot of assumptions about the requirements. Later, the assumptions were not same from one developer to other developer which created a lot of code conflicts.
2. Requirement errors in later phases of development and rework: One of the main roles of requirement analysis is to remove the requirement related issues in the early phases of development. But due to lack of requirements, these issues were faced in the later phases of the development. It needed rework on the code to meet the expected behaviour which could have been ignored if the developers where assigned detailed requirements in initial phases of development.
3. Missing Functionalities: Due to lack of requirements analysis, many requirements were left undiscovered by project management team. As a result, the project created was not having completed requirements expected by the customer.

Example: Customer required the support for multiple language selection in the project, but the same was not implemented.

4. Incorrect implementation: Number of implementations developed in the development was not same as expected by customer.

Example: Customer required the user authentication by email, but the implementation was made to authenticate user with a username.

5. Unnecessary requirement implementations: Number of implementations was developed in the project, which was not required by the customer.

Example: Project was implemented with the feature of sharing the account details on social media, but the customer didn’t require the same in the project.

6. Use cases didn’t meet with the software: As the requirements were not specified properly, the use cases left undiscovered. As a result, the software developed didn’t meet the use cases.
7. Project went beyond the timeline: As the implementations kept on changing till the end of the project development, it included lots of rework in the process. As a result the team was not able to provide the project on time.
8. Project went beyond the budget: The rework in the project required more resources, which lead the project to go beyond the planned budget.
9. Integration issues: The developers worked on the assigned modules having assumptions in their mind. The variable types, locations, coding structures defined for different modules produced integration errors.
10. Software Rejection: As the project was not developed as per the customer as well as timeline didn’t meet, the same was rejected by the customer.

After having the above experience, it is clear that requirements give a vision to the development of the software. Project should always build up based on the detailed requirements gathered from the customer. This phase should consider gathering of requirements as well as detailed analysis of the provided requirements. A good software development process should find the answers to the below queries before starting the actual implementations:

1. Are the requirements complete?
2. Can the specified requirements be implemented?
3. Can we deliver all requirements within the timeline?
4. Are the requirements compatible with each other OR is there any requirement which is contradicting the other requirement?
5. Can the requirements be implemented with available resources?

A software development process started with above inputs will help the team to deliver a quality project on time with complete requirements implemented in it.