Documenting Requirements

Documenting Requirements

Documenting requirements is a crucial step in the systems analysis and design process. It involves creating clear and detailed descriptions of what the system must do to meet the needs of its users. This documentation serves as a reference for both developers and stakeholders throughout the project.

Importance of Documenting Requirements

Accurate documentation helps ensure that all stakeholders have a shared understanding of the system's functionality. It reduces misunderstandings and miscommunication, which can lead to project delays or failures. Well-documented requirements also aid in project management, testing, and maintenance.

Types of Requirements

Requirements can be broadly classified into two categories: functional requirements and non-functional requirements.

Functional Requirements

Functional requirements describe what the system should do. They outline the specific functionalities that the system must provide. For example, if you are designing an online banking system, a functional requirement might state:

The system must allow users to transfer funds between accounts.

Non-Functional Requirements

Non-functional requirements define how the system performs a function. They include aspects such as performance, security, usability, and reliability. For instance, a non-functional requirement for the same online banking system might state:

The system must process fund transfers within 5 seconds.

Requirement Gathering Techniques

Before documenting requirements, you must gather them from various sources. Techniques for gathering requirements include interviews, surveys, and workshops. Each technique has its strengths and weaknesses.

Interviews

Interviews involve one-on-one discussions with stakeholders. They allow for in-depth exploration of user needs. For example, you might interview a bank manager to understand the requirements for a new loan processing system.

Surveys

Surveys can reach a larger audience and gather quantitative data. You might use a survey to ask bank customers about their preferences for online banking features.

Workshops

Workshops bring together multiple stakeholders to discuss and agree on requirements. They can be effective for resolving conflicts and building consensus.

Documenting Requirements

Once you have gathered requirements, the next step is to document them clearly and systematically. A common format for documenting requirements is the use of a requirements specification document (RSD).

Structure of a Requirements Specification Document

A typical requirements specification document includes the following sections:

1. Introduction: Provides an overview of the project and its objectives.
2. Scope: Defines what is included and excluded in the project.
3. Stakeholders: Lists all stakeholders involved in the project.
4. Functional Requirements: Details the specific functionalities required.
5. Non-Functional Requirements: Describes the performance and quality attributes.
6. Assumptions and Constraints: Lists any assumptions made and constraints faced during development.

Example of Documenting Requirements

Let us consider an example of documenting requirements for an online shopping system.

1. Introduction: The online shopping system aims to provide users with a platform to browse and purchase products.

2. Scope: This project includes the development of the website and mobile application. It excludes payment processing.

3. Stakeholders: Customers, system administrators, and product suppliers.

4. Functional Requirements: 4.1 Users must be able to create an account. 4.2 Users must be able to add products to a shopping cart. 4.3 Users must be able to checkout and place orders.

5. Non-Functional Requirements: 5.1 The system must support 1000 concurrent users. 5.2 The system must be available 99.9% of the time.

6. Assumptions and Constraints: 6.1 Users will have access to the internet. 6.2 The project must be completed within six months.

Techniques for Validating Requirements

After documenting the requirements, it is essential to validate them. Validation ensures that the requirements are accurate, complete, and feasible. Common techniques for validating requirements include:

Review Sessions

Organise review sessions with stakeholders to go through the documented requirements. This allows stakeholders to provide feedback and suggest changes.

Prototyping

Create a prototype of the system to demonstrate how it will function. This can help stakeholders visualise the requirements and identify any gaps.

Traceability Matrix

A traceability matrix is a tool that links requirements to their source. It helps ensure that all requirements are addressed in the final product.

Common Mistakes in Documenting Requirements

When documenting requirements, be aware of common mistakes that can lead to issues later in the project.

Vagueness

A common mistake is using vague language. For example, stating that a system should be “user-friendly” is not specific enough. Instead, define what “user-friendly” means in terms of specific features.

Overlooking Non-Functional Requirements

Another mistake is neglecting non-functional requirements. Focusing only on functional requirements can lead to a system that works but does not meet user expectations for performance or reliability.

Ignoring Stakeholder Input

Failing to involve stakeholders in the documentation process can result in missing critical requirements. Always seek input from all relevant parties.

Summary

• Documenting requirements is essential for successful systems analysis and design.
• Requirements are classified into functional and non-functional categories.
• A requirements specification document should include an introduction, scope, stakeholders, functional and non-functional requirements, and assumptions and constraints.
• Validation techniques include review sessions, prototyping, and traceability matrices.
• Avoid common mistakes such as vagueness and overlooking non-functional requirements.

Check your understanding

• What is the difference between functional and non-functional requirements?
• List the main sections of a requirements specification document.
• What techniques can be used to validate requirements?
• Why is it important to involve stakeholders in the documentation process?