Requirement Documentation, Review & Management of User Needs in Software Engineering
Collecting requirements is only the beginning. After understanding what users need, software teams must document those needs clearly, review them carefully, obtain agreement, track their status, and manage every change throughout the project. A requirement that is understood today may change tomorrow because of user feedback, business policy, technology, budget, regulation, or project scope. This is why Requirement Documentation, Requirement Review, and Requirement Management are essential parts of professional Software Engineering. In this chapter, we will understand how raw user needs become controlled, reviewed, traceable, and maintainable software requirements.
Requirement Documentation converts user and stakeholder needs into a clear written form. Requirement Review checks whether those documented requirements are correct, complete, consistent, feasible, understandable, and testable. Requirement Management controls requirement status, versions, priorities, traceability, and changes throughout the software lifecycle.
In very simple words:
Documentation = requirement ko clearly likhna.
Review = check karna ki requirement sahi likhi hai ya nahi.
Management = project ke throughout us requirement ko control aur track karna.
What is Requirement Documentation?
Requirement Documentation is the process of writing software requirements in an organised, understandable, and usable form.
During elicitation, users may say things in natural language such as:
Raw User Need
“Website fast hona chahiye.”
Documented Requirement
“The system shall return the requested dashboard page within 2 seconds under the defined normal operating load.”
The first statement communicates an idea, but it is difficult to test because the word fast can mean different things to different people.
The second statement is much more useful because expected behaviour is clearer and measurable.
Requirement documentation converts informal user expectations into requirements that developers, testers, customers, analysts, and managers can understand and use consistently.
From User Needs to Software Requirements
A user need and a software requirement are related, but they are not always written at the same level.
User Need
Describes what the user wants to achieve, usually in simple business or user language.
Example:
“Student should be able to recover a forgotten password.”
System Requirement
Describes what behaviour the system must provide to satisfy that need.
Example:
“The system shall allow a registered student to request a password-reset link
using the verified email address associated with the account.”
Requirement Engineering therefore works like a translation process:
User Problem → User Need → Analysed Requirement → Documented Requirement → Design → Code → Test
Pictorial Process: Documentation, Review and Management of User Needs
Notice that requirement management does not finish after approval. Requirements continue to be monitored until the project is completed and often beyond it.
Requirement Documents and Artifacts
Requirements may be documented in different forms depending on the size, process, organization, and type of software project.
Business Requirement Document
Describes high-level business goals, problems, expected outcomes, and project objectives.
User Requirement Document
Describes the system from the user's point of view using language that users can understand.
SRS
Software Requirement Specification contains detailed functional and non-functional system requirements.
Use Cases
Describe how actors interact with the system to achieve specific goals.
User Stories
Short requirement statements commonly written from a user perspective.
Acceptance Criteria
Conditions that explain when a requirement or user story can be considered successfully satisfied.
Requirement Traceability Matrix
Connects requirements with their sources, design elements, implementation, and tests.
Glossary
Defines domain-specific words, acronyms, abbreviations, and terms used in the requirement documents.
Models and Prototypes
Diagrams, wireframes, workflows, prototypes, and process models support written requirements.
Every project does not require every document listed above. The documentation should match project complexity, development process, risk, and stakeholder needs.
How to Document Requirements Properly
Requirement documentation should not simply copy everything the client says. Raw statements should first be analysed and then written in a form that reduces misunderstanding.
Step 1: Give Every Important Requirement an Identifier
Example:
REQ-LOGIN-001
A unique ID makes tracking, discussion, review, testing, and change management easier.
Step 2: Write One Main Requirement Clearly
Avoid mixing several unrelated behaviours inside one long sentence.
Weak Requirement
“System should be fast, secure, easy to use and should send messages properly.”
Better Approach
Separate performance, security, usability, and notification requirements so that each can be analysed and tested independently.
Step 3: Avoid Ambiguous Words
Words like these can create confusion:
- fast,
- easy,
- good,
- quickly,
- user-friendly,
- normally,
- as soon as possible.
Whenever possible, define measurable or observable conditions.
Step 4: Mention Source and Priority
The team should know:
- Who requested the requirement?
- Why is it needed?
- How important is it?
Step 5: Add Acceptance Conditions
Requirement documentation should help the team determine later whether the requirement has actually been satisfied.
Good Requirement Documentation Format
The exact fields differ between projects, but requirement attributes like these help maintain control.
Requirement Documentation Through SRS
One of the most important formal requirement documents is the Software Requirement Specification (SRS).
An SRS acts as a shared reference between different project participants.
Typical SRS Information
General Information
- Purpose
- Scope
- Definitions
- System context
- Assumptions
- Dependencies
Detailed Requirements
- Functional requirements
- Non-functional requirements
- User/interface requirements
- Data requirements
- Business rules
- Constraints
The SRS should help answer: What system are we building, what should it do, under what conditions, and what constraints must it satisfy?
Use Cases, User Stories and Acceptance Criteria
User Story
A common user-story format is:
Example:
As a student, I want to view my attendance percentage so that I can check whether I meet the minimum attendance requirement.
Acceptance Criteria
Acceptance criteria explain the conditions that must be true before the requirement is considered complete.
- Student must be logged in.
- Percentage should be calculated from approved attendance records.
- Current subject-wise percentage should be visible.
- If no attendance data exists, the system should show an appropriate message.
Use Case
A use case provides more detailed interaction between an actor and the system.
It may contain:
- actor,
- goal,
- preconditions,
- main flow,
- alternative flow,
- exceptions,
- postconditions.
What is Requirement Review?
Requirement Review is a systematic examination of documented requirements before or during development.
Its purpose is to find requirement problems as early as possible.
Check Meaning
Does everyone understand the requirement in the same way?
Check Completeness
Is any important information or condition missing?
Check Feasibility
Can the requirement actually be implemented within project constraints?
Check Testability
Can testers verify whether the requirement has been satisfied?
Requirements should ideally be reviewed by more than one role because different people notice different problems.
Typical Review Participants
- business analyst,
- customer representative,
- end user,
- developer,
- tester,
- architect,
- project manager,
- domain expert where required.
Requirement Review Techniques
Peer Review
Requirement document is checked by colleagues or team members to find mistakes and unclear statements.
Walkthrough
The author or analyst explains requirements step by step while reviewers ask questions and identify issues.
Formal Inspection
A more structured review with defined roles, preparation, issue logging, and follow-up.
Stakeholder Review
Customers and users confirm whether documented requirements represent their actual needs.
Prototype Review
A prototype or wireframe is reviewed alongside written requirements to reveal misunderstandings.
Test-Case Review
Attempting to derive tests can reveal requirements that are vague, incomplete, or impossible to verify.
Requirement Review Checklist
A review checklist helps the team examine each requirement systematically.
What is a Requirement Baseline?
After requirements have been reviewed and approved, a project may establish a requirement baseline.
An agreed version of the requirements that becomes the controlled reference for development and future change management.
Baseline does not mean requirements can never change.
It means changes should no longer happen informally. They should go through the project's change-control process.
Before Baseline
Requirements are still being discussed, refined, reviewed, and corrected.
After Baseline
Significant changes should be recorded, analysed, approved, and reflected in relevant project artifacts.
What is Requirement Management?
Requirement Management is the continuous process of controlling requirements throughout the project.
It includes much more than storing a document.
Main Requirement Management Activities
- identifying each requirement,
- recording requirement attributes,
- tracking status,
- setting priorities,
- maintaining versions,
- controlling changes,
- analysing change impact,
- maintaining traceability,
- communicating updates,
- keeping requirements synchronized with design, code, and tests.
Requirement Management ensures that project requirements remain known, controlled, traceable, updated, and agreed throughout software development.
Requirement Change Control Process
Requirement changes are normal. The real problem begins when changes happen without control.
Requirement Impact Analysis
Before accepting a requirement change, the team should understand what else will be affected.
Suppose a college says:
“From next month, attendance should also include biometric verification.”
This does not affect only one requirement.
Possible Impact
- database structure may change,
- biometric device integration may be needed,
- privacy and security requirements may change,
- UI screens may change,
- APIs may change,
- test cases may change,
- deployment setup may change,
- project cost and schedule may increase.
The study of how a proposed requirement change affects other requirements, project cost, schedule, architecture, design, code, testing, documentation, and risk.
Requirement Traceability
Requirement traceability allows the project team to follow a requirement from its origin to implementation and verification.
Forward Traceability
Follows a requirement forward into design, code, tests, and release.
Backward Traceability
Allows a design element, code feature, or test to be linked back to the original requirement or user need.
Why Traceability Matters
- helps find missing implementation,
- helps find unnecessary features,
- supports change impact analysis,
- supports test coverage,
- supports audit and project control.
Requirement Version and Status Management
As requirements evolve, teams should know both which version they are using and what state each requirement is currently in.
Example Requirement Status Flow
Depending on the organization, other statuses may include rejected, deferred, cancelled, under review, or changed.
Why Versioning is Important
Suppose Version 1.0 of a requirement said:
“User shall log in using email and password.”
Later Version 1.1 may add:
“Administrator accounts shall also require an additional verification step.”
Version history makes it possible to understand how the requirement evolved and why.
Requirement Prioritization During Management
User needs are not always equally important. Requirement management therefore keeps track of priority.
Must Have
Critical requirement without which the release is not acceptable.
Should Have
Important requirement but can sometimes be delayed temporarily.
Could Have
Useful feature if resources and schedule allow.
Not Now
Requirement intentionally left outside the current release.
Prioritization helps prevent every stakeholder request from automatically becoming an immediate development task.
Requirement Volatility and Scope Creep
Requirement Volatility
Requirement volatility means requirements continue changing during the project.
Some change is natural because:
- business rules change,
- users learn from prototypes,
- technology changes,
- laws or policies change,
- new competitors or market needs appear.
Scope Creep
Scope creep happens when project scope keeps expanding without proper control over cost, schedule, resources, and agreed objectives.
Uncontrolled Change
“Bas ye ek feature aur add kar do.”
Repeated many times, such requests can seriously affect the project.
Controlled Change
Record → analyse impact → prioritize → approve → update plan → implement.
Useful Attributes Maintained for Requirements
| Attribute | Purpose | Example |
|---|---|---|
| ID | Unique identification | REQ-PAY-004 |
| Description | Explains expected behaviour | User can view transaction history |
| Source | Shows where requirement came from | Finance department |
| Priority | Shows business importance | Must Have |
| Status | Shows lifecycle state | Approved |
| Owner | Identifies responsible stakeholder/team | Payments team |
| Version | Tracks changes | 2.1 |
| Dependencies | Shows related requirements | Authentication required |
| Rationale | Explains why it exists | Needed for account transparency |
| Acceptance Criteria | Defines successful completion | Last 12 months of records available |
Real-Life Example: Managing User Needs in an Online Exam System
This example shows why requirement management is much more than keeping a Word document.
Common Mistakes in Requirement Documentation & Management
Writing Vague Requirements
Words such as fast, easy, good, or secure are used without measurable meaning.
No Requirement ID
Requirements become difficult to discuss, track, and link to test cases.
No Stakeholder Review
Documentation may be technically clear but still represent the wrong user need.
Informal Changes
Developers change behaviour without updating requirements and related artifacts.
No Traceability
Team cannot identify why a feature exists or whether every requirement has been tested.
Ignoring Requirement History
Team loses information about why important decisions and changes were made.
Requirement Documentation vs Requirement Management
| Basis | Requirement Documentation | Requirement Management |
|---|---|---|
| Main Purpose | Record requirements clearly. | Control requirements throughout their lifecycle. |
| Main Focus | Content and clarity. | Status, version, priority, change, traceability. |
| Output | SRS, use cases, user stories, acceptance criteria, models. | Controlled requirement set and change history. |
| Time | Strongly performed during requirement definition. | Continues throughout software development. |
| Key Question | What exactly should the system do? | What changed, why, who approved it, and what does it affect? |
Memory Tricks for Exams
- D – Document
- R – Review
- A – Approve / Baseline
- M – Manage Changes
- T – Trace
Remember: “Document, Review, Approve, Manage, Trace.”
Change-Control Trick: R I D U C- R – Request
- I – Impact Analysis
- D – Decision
- U – Update
- C – Communicate
How to Write This Topic in Semester Exam
For 2 Marks
Requirement documentation records user needs clearly, requirement review checks their quality, and requirement management controls their changes and traceability throughout the project.
For 5 Marks
- Definition
- Need for documentation
- Requirement review
- Requirement management
- Short change-control flow
For 10 Marks
- Introduction
- User needs vs requirements
- Requirement documentation
- SRS / artifacts
- Review process & checklist
- Baseline
- Requirement management
- Change control
- Traceability
- Example & conclusion
10 Mark Ready Answer
Requirement Documentation, Review, and Management are important activities of Requirement Engineering. Requirement Documentation converts user and stakeholder needs into clear written requirements that can be understood by developers, testers, managers, and customers.
Requirements can be documented using SRS documents, use cases, user stories, acceptance criteria, process models, interface specifications, and requirement traceability records.
After documentation, requirements are reviewed to check correctness, completeness, consistency, clarity, feasibility, necessity, and testability. Reviews may be conducted through peer review, walkthrough, inspection, stakeholder review, and prototype review.
Once reviewed and approved, requirements may be baselined. Requirement Management then controls their priority, status, versions, dependencies, traceability, and future changes.
Whenever a requirement changes, its impact on cost, schedule, design, code, testing, and other requirements should be analysed before approval.
Therefore, documentation makes requirements clear, review improves their quality, and management keeps them controlled throughout the software lifecycle.
Scoring Conclusion
Good requirement management ensures that the software team always knows what users need, what has been approved, what has changed, why it changed, and how that change affects the final software.
Quick Revision Notes
Requirement Documentation: Writing user and system needs clearly.
Requirement Review: Checking requirement quality before implementation.
Requirement Management: Controlling status, priority, version, change, and traceability.
Important Artifacts: SRS, use cases, user stories, acceptance criteria, models, RTM.
Good Requirement: Correct, complete, consistent, clear, feasible, necessary, testable, traceable.
Baseline: Agreed controlled version of requirements.
Change Control: Request → Impact Analysis → Decision → Update → Communication.
Impact Analysis: Checks effect of a change on cost, schedule, design, code, tests, and risks.
Traceability: Connects user need → requirement → design → code → test → release.
Scope Creep: Uncontrolled expansion of project scope.
Requirement Volatility: Degree to which requirements keep changing.
Memory Trick: DRAMT = Document, Review, Approve, Manage, Trace.
Important Viva Questions
It is the process of recording software requirements clearly and systematically.
It helps detect incomplete, incorrect, ambiguous, conflicting, infeasible, or untestable requirements early.
It is the process of controlling requirement status, versions, changes, priorities, and traceability throughout the project.
It is an agreed and controlled version of the approved requirement set.
It studies how a proposed change will affect other requirements, design, code, testing, cost, schedule, and risk.
It is the ability to track a requirement from its source through implementation and testing.
Scope creep is uncontrolled expansion of project scope through repeated or unapproved changes.
They allow requirements to be referenced, tracked, reviewed, changed, and linked to tests without confusion.
Frequently Asked Questions
No. SRS is an important requirement document, but requirement documentation may also include use cases, user stories, acceptance criteria, diagrams, prototypes, business requirements, glossaries, and traceability records.
Yes. Approved requirements can change, but the change should be controlled, analysed, documented, and communicated.
No. Change is normal in software projects. The goal is not to stop all changes; the goal is to understand and manage them properly.
Testers can identify requirements that are vague or difficult to verify, helping improve testability before development is completed.
Review is one technique used to examine requirement quality. Validation is the broader activity of confirming that requirements correctly represent stakeholder needs and describe the right system.
Conclusion
Requirement Engineering does not finish when requirements are collected. User needs must be converted into clear documentation, reviewed by the right people, approved, traced, versioned, and managed throughout development.
Requirement Documentation creates clarity. Requirement Review finds mistakes before they become expensive. Requirement Management keeps the project under control when requirements change.
Traceability connects every important need to the software that implements it, while change control helps the team understand the effect of new requests before accepting them.
The complete idea can be remembered in one simple flow:
If these activities are performed properly, developers know what to build, testers know what to verify, managers know what has changed, and users receive software that is much closer to their real needs.
Quick Recall: Document → Review → Approve → Manage → Trace
