Requirements process and documentation

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


Requirements process and documentation are one of the most vital steps in Ambridge Software Limited. This report concentrates on emphasizing key activities and methods for validating and managing gathered information, as well as offering new approach for requirements management and ideas for improving the transfer and recording of educed information.

From the research, various forms of problems were discovered in the requirements validation, requirements traceability and change control process of the company. A valuable solution of written test cases, prototyping and enhanced checklist was used in overcoming the validation issues whilst a requirements management policy which constitutes a traceability lists, change control board and a document server was used in resolving the requirements management issues. Furthermore, a future recommendation of a continuous repeatable process improvement was offered.


This report looks at the current requirements process and documentation practise being used at Ambridge Software Limited (ASL). The aim of the report is to identify deficiencies in the process and provide a cost effective solution to issues found.

The elicitation and analysis technique have being carried out successful being that a paper prototype of the system under constructing was used amongst other techniques to elucidate requirements from various stakeholders whilst the analysis was also carried out through the means of a checklist.

The inappropriate procedures that ASL are currently practising in their requirements process are inadequate traceability due to requirement evolvement and volatility; the validation techniques used do not pick out inconsistency, missing, vague and incomplete requirements. More so, the process had no change control policy.

The next section of this report provides various means of resolving the issues mention above with the cost and benefits attached to each technique. In section 3, the implementation of solution found based on long term benefits. Finally section 4 concludes the report with future recommendations.

2.0 Resolution of issues in Requirements Engineering Process and Documentation.

2.1 Requirements Validation

Validation at ASL is predominantly dealt with by a checklist. Due to lack of conciseness checklist does not check for completeness, consistency and unambiguity of requirements (Sommerville and Sawyer, 1997, p.201). To overcome the vagueness issue of the checklist, ASL have to adopt various validation techniques and rectify the checklist issues as well. In order to rectify the checklist issues, ASL will have to reduce the content of the checklist and relate the checklist questions to the whole systems rather than asking specified questions.

One of the various ways of validating a system is through the use of test cases (Sommerville, 2007, p.159). If requirements are not testable then there are issues with the requirements in terms of clarity (Kotonya and Sommerville). The costs of writing test cases to exercise the requirements are relatively cheap and they can later be used for system verification. Another way of looking for thoroughness in validation process is through requirements inspection (Kamsties et al. 2001).

Since elicitation was regarded as successful the paper prototype system used during the elicitation process has to be enhanced and used during the validation stage with selected test scenarios for execution (Kotonya and Sommerville, 1998, p.101). The cost of re-introducing the prototype will be very moderate as it was already used during the elicitation process, and it should be accompanied with a set of description written by the technical writer describing what can be achievable, how to use the prototype and the constraint associated with it.

Another useful technique during validation is system modelling; a model of the system via data-flow, semantic data and object oriented approach will help pick out conflicting and inconsistent requirements (Kotonya and Sommerville, 1998, p.103).

2.2 Requirements Traceability

Changing one aspect or more of the system requirements without a link to other related requirements will result in incomplete, missing and redundant requirements. It is a known fact that all software projects requirements are not completely captured before commencing (Wiegers ,2003, p.328), so requirements will continue to emerge and be volatile as stakeholders get a better understanding of the system (Ramesh and Jarke 1999). The current traceability method being used does not link requirements together even though they are uniquely labelled. As it is known, one of the most important issues of requirements traceability are evolving and unstable requirements that are not properly managed (Gotel et al. 1994).

Changes that hinder requirements traceability will have an adverse effect on the requirements engineering process (Sutinen et al. 2000), this will leave a gap in the requirement specification documents. ASL will overcome this by adopting some of the various traceability techniques. One of the most common techniques is the matrix table; the matrix table helps in mapping requirements in a one-to-one, one-to-many and many-to -many interactions among system elements (Wiegers, 2003, p.360). More so, test cases written during validation are associated to the matrix table for test coverage.

Another form of ensuring traceability in the requirement process is through the use of traceability lists, which is similar to the matrix table and more effective in managing large requirements unlike the matrix table (Sommerville and Sawyer, 1997, p.229).

Furthermore, requirements can be managed in a data repository (database) for automatic linkage (Sommerville and Sawyer,1997, p.236). The cost of a requirements traceability database is far greater than that of matrix table or traceability lists

During elicitation, different stakeholders will propose all sorts of requirements due to their understanding, these requirements are analysed based on relevancy and they are either accepted or rejected. Therefore, it's essential to keep a record of rejected requirements and the reasons for rejections (Sommerville and Sawyer, 1997, p.252).

2.3 Change management and documentation

A simple requirement change to the system without an assessment of its impact on the overall project will have a negative outcome in terms of cost, scheduling, and resources, when requirements are added, deleted or modify out of a controlled environment within the system (Karl Wiegers, 2003, p.328). The current change management practice in operation is not controlled at ASL, more so the business analyst does not communicate changes to the software developers.

As requirements evolve during and after elicitation, its important to manage the changes being made to the requirements document (Nuseibeh and Easterbrook 2000). In order to manage and control changes effectively a change control policy process has to be established. This will ensure that changes are analysed in terms of cost, scheduling, resources and estimation of completion, more so it provides a means of communication among the project stakeholders (Karl Wiegers, 2003, p.332).

Change control has to be done via the change control board. However, the cost of introducing a change management policy is relatively high.

In order to control and manage existing and evolving requirements, the software requirements document has to be baselined. This will ensure that the customer and ASL have an understanding of what the end product of the system will be like and any proposed changes will need to be formally agreed through the control board. Furthermore, all the documents created during the requirements process has to be uniquely identified as soon as the draft of that document becomes available.

3.0 Implementation of process improvement

The primary objective of ASL is to deliver a system that meets the need of their stakeholders. In order to achieve these objectives, ASL has to implement process improvement to their requirements engineering process and documentation.

3.1 Validation

Though the initial cost of a prototype for the system under built is moderate the benefits during validation are invaluable in that it gives the stakeholders a brief overview of what the system will look like. More so, as stakeholders interact with the prototype system further questions are raised about how the system should operate. This can lead to the discovery of missing requirements that were not captured during elicitation.

Another useful validation technique that has to be incorporated in the validation process to support the system prototype is an enhanced checklists and test cases.

3.2 Requirements Management and documentation

As changes occur it's important to manage requirements efficiently. ASL will implement a change control process, a traceability policy and install a document server.

The change control process will be done via a change control board with a change impact analysis checklist .This will ensure that proposed changes are analysed, planned for and relevant version controlled documents are updated. Traceability lists will be used in linking existing and evolving requirements. The traceability lists will be stored in the document server. A record of rejected requirements will be stored in a version controlled document.

The document server will act as a management tool for controlling and linking of documents, tracking proposed changes so that the latest information can be acted upon by all the project stakeholders.

4.0 Conclusion and Recommendation

This report has critically reviewed the current requirements process and documentation being practised at ASL. From the research carried out it was observed that requirements validation and management are the current challenges being faced by ASL's process. As requirements engineering management is based on documentations, a requirements management policy which constitutes a traceability lists, change control board and a document server was recommended to overcome this issue. Furthermore, a prototype of the system was adopted with a written test case for coverage to ensure the validity of the system requirements. The proposed process improvement will take time and effort, though the reward will be ripped once the improvements have been established in that it will become a repeatable process. More so, ASL will need to set a continuous process improvement targets.


  • Al-Rawas, S. Easterbrook, February 1996 Communication problems in requirements engineering: a field study, Proceedings of the 1st Westminster Conference on Professional Awareness in Software Engineering, London, pp. 47-60. Available: [accessed 18 November 2009]
  • Atwood ME., Burns B., Gairing D., and Girgensohn A., 1995. Facilitating Communication in Software Development. In: Symposium on designing interactive systems, pp 65- 73. Available: [accessed 19 November 2009]
  • Boehm, B., and In, H., 1996. Identifying Quality-Requirement Conflicts. Available: [accessed 13 November 2009]
  • Cleland-Huang, J., Settimi, R., Duan, C., and Zou, X. 2005. Utilizing Supporting Evidence to Improve Dynamic Requirements Traceability, Requirements Engineering, 2005. Proceedings. 13th IEEE International Conference. Pp 135-144. Available: [accessed 13 November, 2009]
  • Easterbrook, S., 1994. Resolving Requirements Conflicts with Computer-Supported Negotiation. Available: [accessed 15 November 2009]
  • Easterbrook, S., and Nuseibeh, B., 1996. Using ViewPoints for Inconsistency Management. Software Engineering Journal [online], 11(1), 31-43. Available: [accessed 19 November 2009]
  • Finkelstein, A., 1994. Requirements Engineering: A Review and Research Agenda. Proceedings of 1st Asia-Pacific Software Engineering [online]. Available: [accessed 6 November 2009]
  • Gotel, O. and Finkelstein, A., 1994. An Analysis of the Requirements Traceability Problem. Proceedings of the First IEEE International Conference on Requirements Engineering,Colorado springs. 18-22 April. pp. 94-101. Available: [accessed 17 November 2009]
  • Gottesdiener, E., 2001. Collaborate for Quality. The Software Testing and Quality Engineering Magazine. pp. 1-8.
  • Gottesdiener, E., 2003. Requirements by Collaboration: Getting it Right the First Time. IEEE Computer Society. pp 52-55.
  • Kotonya, G., & Sommerville, I. (1998). Requirements Engineering: Processes and Techniques.New York: Wiley.
  • Letelier, P., 2005. A Framework for Requirements Traceability in UML-Based Project, 1st International Workshop on Traceability. Available: [accessed 12 November, 2009]
  • Niazi, M. K., 2002. Improving the Requirements Engineering Process through the Application of a Key Process Areas Approach. AWRE'02. Pp 125-139. Available: [accessed 17 November 2009]
  • Nikula, U., Sajaniemi, J., and Kälviäinen, H. 2000. A State-of-the-Practice Survey on Requirements Engineering in Small- and Medium-Sized Enterprises. Telecom Business Research Centre Lappeenranta. Available: [accessed 11 November 2009]
  • Nuseibeh, B., and Easterbrook, S. 2000. Requirements Engineering: A Roadmap. Proceedings of International Conference on Software Engineering (ICSE-2000) [online], pp 1-10. Available: [accessed 11 November 2009]
  • Paetsch, F., Eberlein, A., and Maurer, F. 2003. Requirements Engineering and Agile Software Development. IEEE, Linz, Austria [online]. Available: [accessed 7 November 2009]
  • Palo, M., 2003. Requirements Traceability. Seminar Report [online]. Available: [accessed 6 November 2009]
  • QAdvantage, 2008. Mind Mapping Improves Software Requirements Quality, Communication and Traceability. Available: [accessed 4 December 2009]
  • Ramesh, B., and Jarke, M. 1999. Towards Reference Models for Requirements Traceability, office of Naval Research the European Commission [online]. Available: [accessed 11 November 2009]
  • Robertson, S., & Robertson, J. (1999). Mastering the Requirements Process.Harlow, England: Addison Wesley.
  • Sawyer, P., Sommerville, I., and Viller, S. 1997. Requirement Process Improvement through the Phrased Introduction of Good Practice. Copeative Systems Engineering Group, 3(1), pp 19-34. Available: [accessed 19 November 2009]
  • Sawyer, P., Sommerville, I., and Viller, S. 1999. Capturing the benefits of requirements engineering. IEEE Software, 16(2), pp 78-85. Available: [accessed 20 November 2009]
  • Sharp, H., Finkelstein, A., and Galal, G. 1999. Stakeholder Identification in Requirements Engineering Process. Centre for HCI Design [online]. Available: [accessed 10 November 2009]
  • Sidky A. S., Sud R. R., Bhatia S., and Arthur J. D. 2002. Problem Identification and Decomposition within the Requirements Generation Process. 6th World Multiconference on Systems, Cybernetics, and Informatics, 8(1), pp 333-338. Available: [accessed 21 November 2009]
  • Sommerville, I. (2007). Software Engineering (8th ed.). Harlow: Pearson.
  • Sommerville, I., & Sawyer, P. (1997). Requirements Engineering: A Good Practice Guide:Wiley.
  • Sommerville, I., 2001. Software Documentation. pp 1-19. Available: [accessed 1 December 2009]
  • Sutinen, K., Almefelt, L., and Malmqvist, J., 2000. Implementation of Requirements Traceability in Systems Engineering Tools, Machine and Vehicle Design Chalmers University of Technology. Available: [accessed 2 December 2009]
  • Van Lamsweerde, A., Darimont, R., and Letier, E.1998. Managing conflicts in goal-driven requirements engineering. Software Engineering, IEEE, 24(11), pp 908-928. Available: [accessed 20 November 2009]
  • Westfall, L., 2009. Bidirectional Requirements Traceability, The Westfall Team. Available: [accessed 29 November 2009]
  • West Pole Inc, 2005. Use Case and Interviewing Techniques for Focused Requirements Capture, A White Paper by West Pole Inc [online]. Available: [accessed 29 November 2009]
  • Wiegers, K., 2009. Requirements When the Field Isn't Green. Available: [accessed 30 November, 2009]
  • Wiegers, K. 2003 Software Requirements [2nd edition] Microsoft Press, Washington.