Software Requirements Management: Challenges and Approaches

Introduction

For software projects to enjoy full and requisite customer satisfaction, the people responsible for the making of the software must have a good definition of the requirements and good management to avoid such shortcomings. This helps in the avoidance of unwanted rework on the software. If managers have a close look at the realm of their organizations, they get to achieve identification of the pain points on the elicitation, analysis, specification, validation, and management of software requirements1.

The engineering of software requirements is an activity that requires a lot of intensity in communication. This has to involve the development team, analysis team, the stakeholders involved and the consequent end users of the software systems. To be able to effectively communicate in the software development process, there has to be skilled analysis of the requirements involved, the definition of the requirements, and the sourcing of the right tools which will be required for the development process.

If the communication requirements are followed in the book, misunderstanding between all the parties involved in development is avoided. In this paper, there will be a discussion of the requirements that are essential for the development of almost all major and minor software. There will be an insight into the essential strategies that lead to the development of good software solutions, issues on the traceability matrix, change management, and lastly the requirements which are put in place for management.

Requirements analysis and principles and practices of management2

For the development of any kind of software, there is a requirement for approximately 50% of tasks by practitioners. Such tasks include the actual coding process, testing of the product; documentation, and the rest of the processes are communicated by the stakeholders. In the requirements chain of software development, a breakdown in the links between the chains leads to some quite serious problems in development. If there happened to be some communication breakdown at the analysis level and also in development, there is bound to be dissatisfaction from the customers.

Communication chain in a software development process.
Diagram 1: Communication chain in a software development process.

In case of any errors in the placing of the requirements in the process of developing particular software, then it means that more time is likely to be wasted in the process of reworking. This means that there to be preciseness in the requirements statement which has been known to take over 50% of software malfunctions. The total cost of such an error can go up to 80%. If some of the problems are corrected in the requirements definition, then there is bound to be more saving of time.

There are various issues that impact requirements that should be kept into consideration by all developers and future software developers.

  • If the involved teams do get mistakes in the definition of the requirements, then any level of preciseness in the future level is futile. The definition of the requirements is the key to a proper consideration of the right tools for use by the team.
  • Definition of the requirements is an event that takes into consideration a vast amount of invention and also some discovery. This is more of an elicitation process that includes a lot of invention and brain work from the concerned analysts in order to deliver what is required by the end-users. This process has to be validated through feedback from the stakeholders.
  • The customer has to be involved in the development of the software or else it will lead to potential failure of the software. Involving the customer in the development problems erases the probability of rework.
  • Change management is a must in any development process considering that most of the time it is inevitable. The main objective of this process is identifying and incorporating the right requirement management processes. In this process, the right issues are brought up such that the project meets its objectives. This helps the teams to save costs of disruption and the costs that would have been to the stakeholders. Prior change at the requirements level inhibits latter change to the system which is very expensive.
  • Requirements are never perfect or complete and it is always good to look back at the specifications to enhance that they fall right in place. The best way to approach such an issue is not putting a deadline to requirements definition but on the other hand requiring a control process which will prove doable.

Requirements processes

There needs to be good practices in the development of requirements for the acceleration of the process of software development. In the definition of the requirements for the business, the stakeholders involved in the business share their goals, visions and also some of their expectations. If the users are substantially involved in the establishment and also the management of the changes to some requirements which are agreed upon, there is an increase in the accuracy of the requirements and also in making sure that the end-users will benefit from the functionality of the systems which are built-in enhancement of the business tasks that they are required to. In the realm of software engineering, there are main domains that make up the field.

  • Requirements definition: – this is a process that involves collaboration in the collection, validation, and documentation of the requirements that are main and part of the agreement or consensus reached to by the stakeholders in the project. In the definition of requirements in a project, there are further subdivisions which include eliciting, analyzing, specifying and validating the processes. In this process of project design, there is a goal towards achieving requirements that are validated by the users in the proceeds of designing, testin,g and constructing the software at levels that are acceptable in managing the risks.
  • Requirement management: – this is the process of working with the requirements that were preset that in the production process for the software under development to be perfect. This process involves change management in the software production lifecycle. In this process of managing the requirements changes which are incorporated ensure that the final product is not adversely affected in any way.

If the management and definition of the requirements is to be effective, the organization will have created a solution that is not only complete but should also that is accurate. In this case, the organization will have been assisted in the creation of good solutions that will align the IT department with the required objectives of the business and also its needs. This sets up categories that are required for the industry in the best way possible and also the required tools which boost up the activities of the requirements.

Requirements traceability matrix

The traceability matrix is a manuscript which is basically a table that is used to two documents that do have a baseline and many relationships and is used to determine how a particular project will be finished. The high-end requirements which are put in this document are in most cases details of the requirements needed for certain software such that the product is able to match with the high-end design, its details and the testing procedures.

This matrix can be applied in checking the complacency of the design and development team with the predefined documents. In the usage of this document, items in the first document are put to the left side of the document. The other papers has some recognizing objects which are placed on the top line where if a matching object is found, a spot is put in position. Addition of the row values and the column values which hold some marks is a mapping of the items. A very large value indicates a complication in the relationship and thus deserves simplification.

Requirements traceability is actually about the documentation of the whole process of requirements. In this process, there should be an inclusion of the ability to trace to the root, all the requirements and any changes which are affected to them. The use of these requirements should also be made possible. When the process is done properly, the people who required a certain requirement during elicitation get to be known.

Diagram 2: The following diagram is a sample template for a traceability matrix

REQUIREMENTS-TRACEABILITY MATRIX REQUIREMENTS TRACEABILITY MATRIX
Project Name: – Project Name:
National Center: – National Center:
Project Manager’s Name: Project Manager Name:
Project Description: Project Description:
ID Assoc
ID
technical assumption(s)
and/or customer need(s)
Functional-
Requirements
Status Architectural/Design
Document
Technical
Specification
System
Component(s)
Software
Module(s)
Test Case
Number
Tested In Implemented In Verification Additional
Comments
001 1.1.1
002 2.2.2
003 3.3.3
004 4.4.4
005 5.5.5
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033

Change request management

Change management is an indispensable process in the development of any software. The changes happen for the betterment of the final product as discussed in the key issues for software requirements definition. The process of managing changes in the development of any software is a crucial process that requires some processes3.

The first process in the management of change is the communication of the need for a change of requirements. In this case it is wise to communicate the level of the change request and implementation approvals. In the document, it is good to include the validity of the change and whether or not it was in the initial agreement4.

The next step is for the support to log this request such that it can be able to follow up on the proceeds of the request and hence be able to communicate duly to the customer. The requests for any changes are either raised by the customer or from the development team. This is the chief reason for the support to follow up on the changes.

The development team can then acknowledge that it has received the request and from then identify and inform all the areas that are likely to be impacted by the change. The areas should then assess the needed changes and the impacts on the project and inform on the effects. This should include the financial estimates which should be communicated to the customer so that he/she can give a go ahead. The request should be duly closed when the customer fails to approve. The last bit, when approved, is to complete the made request and also to keep the customer updated on any progress.

The process of change request.
Diagram 3: the process of change request.

In change management5, there must be an elaborate procedure for how the projects are managed at the organizational level. This process must be formal as all the parties must be in accord in managing all the risks and implications of the change management process1.

The request for the aforementioned changes must also be formal. The organizations ought to have to provide essential software in the sustenance of the project managing processes. For small organizations, automation can be through simple word processors which will help in the automation of the minor procedures. Another procedure which should be followed is the review of the changes. This can be through some models of workflow which can be through certain setup criteria for the procedures. Such procedures of workflow can be exemplified by risk consideration where some projects may require deep scrutiny whilst some procedures require just simple scrutiny of risks.

In the management of change, care should be taken on the delivery of the project as well as the enhancement of the changes in a well and timely manner. This will not have attempted to stop the changes from being enhanced but will have checked on the probable risks and also the way out. In the reporting of the status of the changes, the reason for a possible rejection should be communicated effectively. This should be in line with the importance of the previous change and so.

It should be wise to consider that changes have the ability to bring on disruptions, failure of some budget figures, and compromising of some of the features. If people get to include some changes which are not properly considered, there is a probability of failure in the projects. To avert such a circumstance, the organizations require a preset process for change management.

Requirements management tools

There is a variety of tools which can be used to manage requirements in the market today. The most common tools a based on the web and also some desktop tools. The requirement tools that are web based can be installed at the data centre of the customer or at times offered as a management platform which is based on demand. Such platforms are in most cases offered free of charge.

The tools which can be installed include the modeling languages such as SysML which stands for “System engineering Modeling Language”. This language has a requirements illustration which assists the developer of a system in the management, organization and tracing of the requirements in the software development process.

The “on demand requirements management platforms” are always hosted on the web for free with the host machine requiring just good internet access. The normal services which are offered include specified hardware and software for the management process. Others include the inclusion of technological processes for data security. This data security is against physical damages and unwarranted access. There is also an assurance of availability at any time and that the service is dynamic thus can change with changing applicability6.

With an increase in the difficulty that is found in the engineering process, the sophistication calls for an investment in databases which aid in storage of information. An example of a commercially available tool is the Borland “TeamDefine”. Some of such tools come accompanied with a simulation and a graphical display which give the user more applicability.

Conclusion

Software development is a process that calls for the cooperation of all the required stakeholders in order for the process to be efficient. The management of this process needs effective communication such that all the critical factors are required. Some of the critical factors which are part of this diverse procedure include management of the principles and practices that are relevant for collection of requirements, management of the requests for changes, tracing of the requirements and use of the necessary management tools for the management process. This paper has looked into all the issues stated giving necessary explanatory diagrams where applicable.

If the stated processes and procedures are clearly followed and adhered to in the process of software development, then organizations, practitioners and students would have a smooth process of software development. This will lead to production of better software at a faster rate and a minimized cost in the end27.

References

Basili, H.D. & Rombach, ‘The TAME Project: Towards Improvement-Oriented Software Environments’, IEEE Transactions on Software Engineering, vol 14 (1988), p.758-773.

Boehm, B.W. Software Engineering Economics, New York: Prentice Hall, 1981.

Gotel, O. ‘An Analysis of the Requirements Traceability Problem’ Proc. of First International Conference on Requirements Engineering, 1994, pp 94-101.

Hood, C. et al Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007.

Jarke, M, ‘Requirements Tracing’, Communications of the ACM, Vol. 41, No. 12, 1998, pp. 32-36.

Pfleeger, S.L ‘Lessons learned in Building a corporate metrics program,’ IEEE Software, vol. 10, no. 3, 1993, pp. 67-74.

Software Engineering Institute, ‘The Capability Maturity Model’. Guidelines for Improving the Software Process, Addison-Wesley, 1995.

Footnotes

  1. Basili, H.D. & Rombach, “The TAME Project: Towards Improvement-Oriented Software Environments”, IEEE Transactions on Software Engineering, vol 14 (1988), p.758-773.
  2. Hood, C. et al Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007.
  3. Software Engineering Institute, “The Capability Maturity Model”. Guidelines for Improving the Software Process, Addison-Wesley, 1995.
  4. Gotel, O. An Analysis of the Requirements Traceability Problem Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101.
  5. Boehm, B. Software Engineering Economics, New York: Prentice Hall, 1981.
  6. Pfleeger, S.L “Lessons learned in Building a corporate metrics program,” IEEE Software, vol. 10, no. 3, 1993, pp. 67-74.
  7. Jarke, M “Requirements Tracing”, in Communications of the ACM, Vol. 41.