Articles
In this page, there are some articles on various fields of business. All articles represent the view of
the Metodi Consulting. Some articles may be downloaded as PDF files, some may have been published in
other medias as well. All right reserved by the author unless otherwise stated.
Importance of Requirements Specification 26.05 2008
The Role of Software in Customer’s Operations
The modern IT infrastructure with its various software tools is an inseparable part of most companies operations, regardless of the field of business. The role of software is that of a tool: the customer needs to produce something needed in the business process of providing products or services to end customers. So, the tool must be perfect for the job – like an artists’ brush must be perfect for the type of painting to be produced.
The customer primarily seeks out for commercial off-the-shelf (COTS) software to boost productivity, to ease and streamline work processes and to gain cost benefits. The problem with COTS software is that their functions are general and do not offer customer specific features. Other situation might be that the customer is seeking for solution to get the legacy software products to ”discuss with each other”, that is, automatically share information between each other. Then there is enterprise-level software providers who provide partly customized solutions based on modular software, which includes both ready-made software components and some custom-made ones. Or, the customer does not find any practical solutions from the markets, and is in need of fully customized software solution.
Excluding the case of COTS, all other cases will include a software development project where one phase will consist of requirements gathering, specification and analysis. And this is the phase which defines the success of your software project.
Casual problems of Software Development Projects
Providing products and services using various project techniques is nowadays a common practice. In the field of software business, the projects are too often either late, over their budget, or the results are not what the customer expected. The customer seldom receives any compensation of failed projects.
A software development project, where the customer has made a
contract to get a customized solution, is rather complicated one to
provide – but it isn’t quantum mechanics, either. When both the target
and the end results are known, and how the project will be managed, it is
proven that all these factors of the project can be met. The customer
will get just what she wanted if, through adequate requirements
specification, there’s a common understanding of the goal and results
between the customer and the provider.
Understanding the Customer’s Business Process
To succeed in a software project – or in the acquisition of a customized software solution – a common understanding of the goal and end results of the project is needed. Since the software will be a tool for some work process within the customer’s business process, the provider must have an adequate insight to that business process to be capable of designing and producing a solution that suits the customers business and work process.If these processes haven’t been yet modeled, you should start the project with modeling both the business process and the work process concerned. This has two immediate benefits: a common understanding of the project goal and end results is achieved between the stakeholders while an opportunity to process development arises. This will not only ensure that customer gets what she initially desired, but in addition, she may get a lot better solution by first rehauling the work process.
Another benefit from modeling the processes is that it helps user training in the deployment phase. For the employees, the old process can be visualized together with the new process, and how the use of the software will affect that.
Requirements: The Most Important Phase of a SW Project
Why the emphasis for requirements? Will it not be the testing phase? Or design? How about project management? Yes’ they’re all important. When you think about the cornerstone of any project you find one common criteria for success: the goal (of the project) must be unambigous and clear for all stakeholders. In software projects this includes a clear vision and common understanding of the end results – what the software will do and how it is supposed to perform. If the stakeholders do not share this vision, this common understanding, it will be revealed in the testing phase at latest – and that’s when it is too late for the project to succeed. The requirements must be respecified and corrections will need to be designed, implemented and tested – it’s almost starting all over again. Of course, this means additional work effort, and the target schedule will not be met.The goal and description of end results are presented in the requirements specification in a way that a shared vision and common understanding is achieved between the stakeholders. All other phases in the project rely on this, and the information gathered in the requirements phase. The both the design and testing rely on requirements specification, and it gives a description of the project goal for project management. If requirements fail, all other phases and elements of the project will fail.
Benefits vs risks
In general, requirements phase is about 10 % of total costs of a software development project. The construction phase including design, implementation and testing consists 60 % of total costs. For example, in a small project of 20 000 euros this means 2 000 euros for requirements and hefty 12 000 for construction. If major defects derived from inadequate or bad requirements arise during testing which need half of the effort already spent in construction, this means an additional cost of 6 000 euros – 30 % of the project budget! And it will mean more days and weeks to be spent, so the deadline will not be met. Going over schedule may mean additional costs, depending on the project and customer’s field of business.As stated, the cost allocation presented above is a general one, reflecting the common allocation in software business. The risk may be greater or less; each project is unique. In larger projects the problems arising from requirements may cause more diverse problems and the total additional cost and effects to schedule may be a lot greater. Putting an extra effort to requirements will save the customer a lot of money, and it will provide additional benefits in form of process knowledge, development and cost-efficiency!