Skip to main content

Requirement alternatives and SRS document

Short answer

Alternatives include traditional SRS, structured analysis, prototyping, user stories, JAD workshops, and use-case-driven approaches. An SRS for IOE exam system following the Unified Process covers use cases like exam form submission, admit card generation, marks entry, result publication, with performance, security, and reliability non-functional requirements, and iterative development.

What are requirements process alternatives before having OO Analysis? As you are already familiar with IOE exam processes, prepare a brief SRS document following unified process in OOAD.

Requirement process alternatives before OO analysis

Before OOA starts, requirements may be obtained and recorded in different ways, which are alternatives to (or inputs of) use cases:

  1. Traditional SRS (IEEE 830) - A document listing functional and non-functional "The system shall ..." statements.
  2. Structured analysis - Requirements as DFDs, data dictionary and process specifications.
  3. Prototyping - Quick mock-ups shown to users to clarify requirements.
  4. User stories (agile) - Short statements "As a ..., I want ..., so that ...".
  5. Joint Application Development (JAD) / workshops - Requirements agreed in group sessions.
  6. Use case driven approach - Used in the Unified Process; describes functionality as scenarios of actor-system interaction.
  7. Interviews, questionnaires, observation, document study - the sources for all of them.

Brief SRS following the Unified Process: IOE Exam Management System

1. Introduction

  • 1.1 Purpose: Specify requirements for the system used by IOE to conduct examinations and publish results.
  • 1.2 Scope: Registration of exam forms, exam routine, roll number and admit card, marks entry and result publication.
  • 1.3 Definitions: ECD (Exam Control Division), Campus, Examiner.
  • 1.4 References: IOE examination rules, IEEE 830.

2. Overall description

  • Product perspective: web-based, standalone with a central database.
  • Users (actors): Student, Campus Officer, Examiner, ECD Staff, Administrator.
  • Constraints: must support thousands of students concurrently on result day; data kept secure.
  • Assumptions: internet available at campuses.

3. Use cases (functional requirements)

  • UC1 Submit Exam Form (Student). UC2 Generate Admit Card. UC3 Prepare Exam Routine (ECD). UC4 Enter Marks (Examiner). UC5 Process Result (ECD). UC6 Publish and View Result (Student). UC7 Manage Users (Admin).
  • Each use case has actor, pre-condition, main flow, alternate flows, post-condition (in detail document).

4. Supplementary (non-functional) requirements

  • Performance: result page loads in under 3 s.
  • Security: role-based login; audit of mark changes.
  • Reliability: 99% availability in exam periods; daily backup.
  • Usability: usable on mobile browsers.

5. Domain model (glossary): Student, Exam, Subject, Mark, Result, Campus.

6. Iteration plan: Iteration 1 - UC1, UC2; Iteration 2 - UC4, UC5; Iteration 3 - UC6, UC3.

Related questions

All Object Oriented Analysis and Design chapter 2 questions →