A software developer wrote to me: “We had several project failures.
Customers were angry but the project manager told us that they were
customer’s faults because they kept changing requirements. We are
starting a new project but I am afraid that we will make the same
mistake again. What can we do to avoid this problem? Please advice.”
Answer: If the customers keep changing requirements then you need to have a requirements engineer or business analyst to spend time with customers to obtain better requirements. This is an important role in software development but many companies do not pay attention. If the requirements are wrong than everything will be wrong no matter how good you can design or code. If your company does not have someone to do this then they should hire people who could do that job. When a project fails, your manager should not blame the customers but should identify the cause and fix it so it will not happen again. When customers are not happy then it is bad business. No company can survive if their customers are not happy. When a project is late, it takes more time, more money, and more efforts than previously planned. It means the company has to pay for these extra works and it means losing more money.
Changing requirements is a common problem in software industry. It is usually due to the lack of knowledge on software requirements. Many project managers think that they understand what the customers need and proceed to development without any customer validation. Many developers presume that they know all the features customers need then start design and code without any customer review. Progress is measured by each line of code built throughout the process until requirements begin to change. Fixing software after building is costly and time consuming. It often causes huge effort waste with hundreds of hours unproductive and hundred lines of code changes. This is why you need someone who understands requirements to work closely with customers to get the right requirements so you do not make the same mistake again.
There are different views of requirements. A manager’s view of requirements is often a high-level concept of a product or a business problem that must be solved. A user’s view of requirements is mostly the functions, the interface, and the navigation of screens. If the requirements are mostly functional, the project team may not understand various information hidden under the view of functionality. As a result, customer’s expectations may not be achieved.
To avoid this issue, project team must understand several views of requirements. The highest level view is the business requirements, representing the objectives of the customer. This is really the vision and the scope of your project. The second level view is the user’s requirements, which describe all the tasks that users must do when using the software. These are best captured in the form of use cases, which are scenarios of typical interactions between the user and the system. This is the architecture of the system with hardware, software interface and the navigation of screens. However, use cases alone do not provide enough detail for developers to know what to build. Therefore, you need the third level view or the functional view which derive from the use cases. The functional requirements clearly define specific things the software must do. This is the design of the system with each function clearly identified. However, there is another view called the non-functional view or the quality attributes which does not come from customer but from developers that deals with the quality of the software such as performance, efficiency, usability, or scalability etc.
By understand different views, developers can organize their work systematically to meet customers’ expectation and develop better software product.
Answer: If the customers keep changing requirements then you need to have a requirements engineer or business analyst to spend time with customers to obtain better requirements. This is an important role in software development but many companies do not pay attention. If the requirements are wrong than everything will be wrong no matter how good you can design or code. If your company does not have someone to do this then they should hire people who could do that job. When a project fails, your manager should not blame the customers but should identify the cause and fix it so it will not happen again. When customers are not happy then it is bad business. No company can survive if their customers are not happy. When a project is late, it takes more time, more money, and more efforts than previously planned. It means the company has to pay for these extra works and it means losing more money.
Changing requirements is a common problem in software industry. It is usually due to the lack of knowledge on software requirements. Many project managers think that they understand what the customers need and proceed to development without any customer validation. Many developers presume that they know all the features customers need then start design and code without any customer review. Progress is measured by each line of code built throughout the process until requirements begin to change. Fixing software after building is costly and time consuming. It often causes huge effort waste with hundreds of hours unproductive and hundred lines of code changes. This is why you need someone who understands requirements to work closely with customers to get the right requirements so you do not make the same mistake again.
There are different views of requirements. A manager’s view of requirements is often a high-level concept of a product or a business problem that must be solved. A user’s view of requirements is mostly the functions, the interface, and the navigation of screens. If the requirements are mostly functional, the project team may not understand various information hidden under the view of functionality. As a result, customer’s expectations may not be achieved.
To avoid this issue, project team must understand several views of requirements. The highest level view is the business requirements, representing the objectives of the customer. This is really the vision and the scope of your project. The second level view is the user’s requirements, which describe all the tasks that users must do when using the software. These are best captured in the form of use cases, which are scenarios of typical interactions between the user and the system. This is the architecture of the system with hardware, software interface and the navigation of screens. However, use cases alone do not provide enough detail for developers to know what to build. Therefore, you need the third level view or the functional view which derive from the use cases. The functional requirements clearly define specific things the software must do. This is the design of the system with each function clearly identified. However, there is another view called the non-functional view or the quality attributes which does not come from customer but from developers that deals with the quality of the software such as performance, efficiency, usability, or scalability etc.
By understand different views, developers can organize their work systematically to meet customers’ expectation and develop better software product.
Prof John Vu
Carnegie Mellon University
Original source:http://www.segvn.org/forum/mvnforum/viewthread_thread,1602
Original source:http://www.segvn.org/forum/mvnforum/viewthread_thread,1602
0 comments:
Post a Comment