Why is Requirements Analysis Difficult?
Prototypes and Rapid Application Development
Development Support Tools
The software requirements phase is the period of time in the software development life cycle during which the requirements for the software product are defined and documented. This phase crystallizes a precise description of the software’s function, the exact nature of the environment in which it is to function, and the constraints on its performance. This description furnishes the basis of the contract, moral and legal, between the software developer and the user, and should be accompanied by a detailed plan for the acceptance test by which the purchaser will validate the software.
By firmly understanding the user’s needs and environment, the development team can proceed with a detailed software specification. The process of developing the software specification is done in cooperation and consultation with the client. If there are no clients (i.e., if the product is developed for the general market) then the specification is developed in consultation with the marketing department of the organization. Nothing can be worse than producing the wrong software; so communication and mutual understanding among the various groups involved is crucial for the success of the project. It is also important to establish priorities, guidelines and constraints for the different functions to guide the development team. If all the needs of the client or the customer cannot be met initially, then that fact also should be mentioned.
WHY IS REQUIREMENTS ANALYSIS DIFFICULT?
Although the leading IS departments have made great strides in establishing and using standard processes for development and maintenance, some aspects of a truly effective process are still missing. We have seen that more than 50% of defects occur due to the inaccurate requirements specifications. But there is a limit to which the requirements analysis phase can be improved, because beyond a certain point, the additional effort does not justify the amount of work to be put in. Thus solution to development effectiveness does not lie with better requirement analysis alone, although it can clearly help.
Prototypes and Rapid Application Development
An overall accelerated development process based on cheap and quick-to-build, high-quality prototypes seems to provide a better solution. Business users have proven adept at finding out defects during participative testing and during the early stages of the new software. Thus accelerated delivery of a working prototype to the user, which can be tried out, modified and hence rapidly improved to meet the changing requirements is a solution. But here the amount of end-user participation is very critical. The people who knows the business well, will be busy running it. So the people who are deputized to do the collaborative testing will be less experienced ones and may overlook some requirements or defects. One major step towards gaining the clear understanding of the user requirements is the development of Rapid Application Development (RAD) tools and the concept of prototyping. The IS departments could use a RAD tool and develop a prototype within days or weeks rather than months or years. The end-users also like this approach because they could actually see what the application looks like before it is delivered and could correct a lot of requirements specification and design defects at an early stage.
Thus it is very difficult to do a thorough requirements analysis. Without the right level of participation by the right sources of requirements, the right discovery and analysis process, good business experts, good analysts and good tools, it is unlikely to work well. Even with all these factors in place, it is not a guaranteed or risk-free process, because no one can guarantee that all the required communication processes will work effectively. Because there is no guarantee that requirements will be specified exactly and correctly, systems professionals must accept that there will be some amount of rework in design and construction and must plan for it. So the IS managers should plan for effective version control and configuration management processes beforehand.
Another important factor that hampers the development effectiveness is the project team. Selecting the team members and project leaders who have the right aptitude and orientation is a very critical but often ignored factor. For a software developer, to become effective, he need to have the right aptitude. Now most organizations conduct aptitude tests or behavioral analysis before selecting the IS professional, which is an encouraging sign. Even when effective teams are formed, IS organizations do not have a team-focused management process, nor do organizations train their IS managers in man-management. Most often leaders or managers of IS projects, progress to their jobs by virtue of their experience and technical skills rather than their man-management skills and most often ends up as failures, because in managing a team of high caliber and high performing group of people, man-management skills are more important than technical skills, although good technical skills can be an added bonanza.
Development Support tools
Development support tools play very important role in development effectiveness. But the idea of development support tools is not new. They have been in existence since the days of machine language coding. But in those days, these tools were generally aimed at supporting the individual developer rather than a project team. Thus the development support technology was a collection of single tools aimed at coding tasks. With the advent of CASE, OOPS, and client/server tools, the prominence of the role of tools in influencing productivity and quality have risen very sharply. Now there are thousands of tools available for helping the IS professional in all phases of software development from the analysis, to development, through testing and implementation.
The main problem with these tools is their number. There are many similar tools for almost any job. Users often find it very difficult to distinguish between the tools and choose the tools most appropriate for meeting their requirements. This difficulty is compounded by the widespread disparity and confusion between definitions of these tools, techniques and methods.
Even the best-integrated tools provide insufficient coverage of the complete life cycle to be used, which necessitates the use of additional tools, which in most cases will not integrate well with the existing one, resulting in performance tradeoffs. These tools require considerable training for a user to become proficient in its usage. This training is often expensive, time consuming yet incomplete. Thus in most cases the IS organizations fail to use the tools to their full potential. Tools by themselves do not create sustained high performance, even when they make high levels of performance possible. Developers must have a technical process and organizational environment within which they can make effective and efficient use of their tools.
Another key factor in development effectiveness is the amount of customer or end-user involvement in the development process. The era of using the customers as the sources of information is changing rapidly. Most successful IS organizations involve the customers throughout the development process in a variety of roles from information sources to testers. The customers are also becoming more aware of the technology and this makes the entire process easier. Some of the techniques used by IS departments or organizations to improve the customer involvement are moving the development on-site, involving the customers in all phases of the development life cycle, IS professionals working in the customer’s business to get to know what is actually happening, getting the help of consultants who are experts in both the customer’s business segment and also software development process (hybrid skills), etc. These trends are proving to be very effective and have paved the way for improving the development effectiveness.
Just as the IS organization and technology it uses have grown and changed rapidly to create a broad and diverse industry, so have people who work in IS become a broad and diverse group. Many IS professionals attained their current positions through skills that are no longer relevant. Even though many people recognize this, they are not willing to learn the new skills which will make them technologically current and up-to-date and thus setting them on a par with newer, younger and less experienced and hence less expensive entrants of the IS profession. Maintaining their morale, knowledge and experience (which are valuable and is necessary to the continuing maintenance of the existing systems) while updating their skills is a formidable challenge. IS organizations cannot do without these professionals, but cannot let them stay the way they are. If the organization has to move forward, then changes have to occur.
The IS organization has to continually evolve in order to stay at the top. Continuing investment in technology, research and changes in business environments will maintain or increase the pace of change with which all organizations have to deal. Creating an organizational culture that is not afraid but is willing to embrace new technology and learn new skill sets (the learning organization) is a must for survival. Thus a successful IS department should constantly excel, innovate, anticipate changes and should be ready for them…
Alexis Leon, DQ Week Madras, 31st March 1997.